Date: Wed, 14 Jul 1999 19:53:53 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Matthew Jacob <mjacob@feral.com> Cc: Juergen Lock <nox@jelal.kn-bremen.de>, freebsd-bugs@FreeBSD.ORG Subject: Re: kern/11945: tape problems on -stable, mt bl(ocksize), mt erase and hanging SCSI bus Message-ID: <19990714195352.A33275@saturn.kn-bremen.de> In-Reply-To: <Pine.BSF.4.05.9907121713080.8020-100000@semuta.feral.com>; from Matthew Jacob on Mon, Jul 12, 1999 at 05:33:51PM -0700 References: <199907130010.RAA87312@freefall.freebsd.org> <Pine.BSF.4.05.9907121713080.8020-100000@semuta.feral.com>
index | next in thread | previous in thread | raw e-mail
On Mon, Jul 12, 1999 at 05:33:51PM -0700, Matthew Jacob wrote:
>
> Okay- I took the time to analyze this better. Sorry for the delay.
>
> This bug report mentions several items.
>
Yup.
>
> > 1. mt bl(ocksize) stopped working, regardless what blocksize
> > i try i only get
> >
> > mt: /dev/nrsa0: blocksize: Invalid argument
> >
> > and on the console:
> >
> > Apr 27 16:00:47 saturn /kernel: (sa0:ncr0:0:5:0): MODE SELECT(06).
> >CDB: 15 0 0 0
> > c 0
> > Apr 27 16:00:47 saturn /kernel: (sa0:ncr0:0:5:0): ILLEGAL REQUEST
> >asc:26,0
> > Apr 27 16:00:47 saturn /kernel: (sa0:ncr0:0:5:0): Invalid field in
> >parameter lis
> > t sks:8f,4
>
> Clearly this works for me and others in a variety contexts.
I thought so :)
> The key
> point here is to try and figure out why this particular tape drive/tape
> doesn't like this- this is offset 4 of the parameters, and this is the
> mode data:
>
> 0x00 0x00 0x10 0x08 0x7f 0x00 0x00 0x00 0x00 0x00 0x02 0x00
>
> So, this so called SCSI-2 device,
>
> sa0: <WANGTEK 5525ES SCSI 73Y1> Removable Sequential Access SCSI-2 device
>
> can't cope with the SCSI-2 density code that means "use the same density
> as was set before". This is around line 2520:
>
> if (params_to_set & SA_PARAM_DENSITY) {
> mode_blk->density = density;
> } else if (softc->scsi_rev > SCSI_REV_CCS) {
> mode_blk->density = SCSI_SAME_DENSITY;
> } else {
> mode_blk->density = softc->media_density;
> }
>
> try changing the code to:
>
> if (params_to_set & SA_PARAM_DENSITY) {
> mode_blk->density = density;
> } else {
> mode_blk->density = softc->media_density;
> }
>
> and see what happens.
>
Thanx, that fixes it!
Index: scsi_sa.c
===================================================================
RCS file: /home/cvs/cvs/src/sys/cam/scsi/scsi_sa.c,v
retrieving revision 1.16.2.7
diff -u -u -r1.16.2.7 scsi_sa.c
--- scsi_sa.c 1999/06/24 15:22:40 1.16.2.7
+++ scsi_sa.c 1999/07/13 18:09:04
@@ -2479,8 +2479,10 @@
*/
if (params_to_set & SA_PARAM_DENSITY) {
mode_blk->density = density;
+#if 0
} else if (softc->scsi_rev > SCSI_REV_CCS) {
mode_blk->density = SCSI_SAME_DENSITY;
+#endif
} else {
mode_blk->density = softc->media_density;
}
@@ -2622,8 +2624,10 @@
*/
if (params_to_set & SA_PARAM_DENSITY) {
mode_blk->density = current_density;
+#if 0
} else if (softc->scsi_rev > SCSI_REV_CCS) {
mode_blk->density = SCSI_SAME_DENSITY;
+#endif
} else {
mode_blk->density = softc->media_density;
}
>
> >
> > 2. mt erase fails similarly (I don't have the syslog right
> > now, sorry)
>
> Possibly due to the same cause.
>
Yup, its working now as i type.
> >
> > 3. depending on factors i haven't found out, trying to read
> > after a BLANK CHECK on some tapes ends up hanging the entire
> > SCSI bus, printing this on the console:
> >
> > ncr0: SCSI phase error fixup: CCB already dequeued (0xf07e1200)
> >
> > followed by several of
> > ncr0: timeout nccb=0xf0xxxxxx (skip)
> >
> > and
> >
> > vm_fault: pager read error, pid xxx (process)
>
>
> This sounds like a bug in the ncr driver to me.
>
Hmm, i don't have another SCSI card to test that guess...
> >
> > CAMDEBUG tells me on the tapes where it hangs it does
> > five LOAD UNLOAD commands (the first rewinds the tape) while
> > normally it does only one LOAD UNLOAD. I can send the full
> > CAMDEBUG output of the working case if that helps...
>
> This was an attempt to try and rerun commands that *can* be rerun if they
> fail. All of the commands that have a known tape position at the end of
> the command can do this, but perhaps should not.
>
An idea: how long a timeout does the LOAD UNLOAD command have?
maybe thats the reason why it `fail's on some tapes, depending on
how long the rewind takes. tho that doesn't explain why 4 more of
them also fail, they appeared in quick succession, when the tape has
rewound fully...
Regards,
--
Juergen Lock <nox.foo@jelal.kn-bremen.de>
(remove dot foo from address to reply)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990714195352.A33275>