Date: Fri, 21 Jan 2011 18:21:06 +0200 From: Alexander Motin <mav@FreeBSD.org> To: "G. Paul Ziemba" <pz-freebsd-scsi@ziemba.us>, freebsd-scsi@freebsd.org Subject: Re: rescan causes offlined tape to reload Message-ID: <4D39B272.7050909@FreeBSD.org> In-Reply-To: <mailpost.1295587503.4089618.94565.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw> References: <mailpost.1295587503.4089618.94565.mailing.freebsd.scsi@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
G. Paul Ziemba wrote: > mj@feral.com (Matthew Jacob) writes: > >> My recollection is that when you 'eject' a DLT, unless you operate the >> handle, or it's part of a changer unit that does it for you, any >> subsequent Test Unit Ready will reload it. > >> Other than that, there are couple of candidate changes in the XPT layer >> in the time frame you talk of which may be inducing this behavior. Any >> way you can get a trace of the SCSI commands sent? > > Hmm. The same drive did not reload the tape upon rescan before I > upgraded to FreeBSD-stable from Jan 11, so I do not think Test Unit > Ready is causing it. > > I rebuilt the kernel to set CAMDEBUG. The kernel and userland are > still the code from FreeBSD current as of 2011-Jan-11. > > It looks as if "camcontrol rescan" generates a command specifically > to load the media (distinct from the TEST UNIT READY). > > # uname -a > FreeBSD hairball.ziemba.us 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Thu Jan 20 20:28:21 PST 2011 root@hairball:/usr/obj/usr/src/sys/GPZ-110111-camdebug i386 > > # camcontrol debug -c 0:4 > Debugging enabled for 0:4:-1 > # camcontrol eject sa0 > Unit stopped successfully, Media ejected > > Jan 20 21:07:26 hairball kernel: (pass2:sym0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 2 0 > > # camcontrol rescan all > > Jan 20 21:08:40 hairball kernel: (probe4:sym0:0:4:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > Jan 20 21:08:44 hairball kernel: (probe4:sym0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 3 0 > Jan 20 21:09:34 hairball kernel: sym0:4:control msgout: 80 6. > Jan 20 21:09:34 hairball kernel: (probe4:sym0:0:4:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > Jan 20 21:09:34 hairball kernel: (probe4:sym0:0:4:0): INQUIRY. CDB: 12 0 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe4:sym0:0:4:0): INQUIRY. CDB: 12 1 0 0 ff 0 > Jan 20 21:09:34 hairball kernel: (probe4:sym0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:1): INQUIRY. CDB: 12 20 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:2): INQUIRY. CDB: 12 40 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:3): INQUIRY. CDB: 12 60 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:4): INQUIRY. CDB: 12 80 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:5): INQUIRY. CDB: 12 a0 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:6): INQUIRY. CDB: 12 c0 0 0 24 0 > Jan 20 21:09:34 hairball kernel: (probe0:sym0:0:4:7): INQUIRY. CDB: 12 e0 0 0 24 0 For the full picture it would be nice to see responses device sent. I suppose that in response to TUR device returns some status that implies tray closing/load. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D39B272.7050909>