From owner-freebsd-bugs Wed Jul 14 11: 1:15 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from blaubaer.kn-bremen.de (blaubaer.kn-bremen.de [134.102.38.17]) by hub.freebsd.org (Postfix) with ESMTP id 422EC153CF for ; Wed, 14 Jul 1999 11:01:08 -0700 (PDT) (envelope-from nox@saturn.kn-bremen.de) Received: from saturn.kn-bremen.de (uucp@localhost) by blaubaer.kn-bremen.de (8.9.1/8.9.1) with UUCP id TAA17179; Wed, 14 Jul 1999 19:57:32 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.9.3/8.8.5) id TAA33765; Wed, 14 Jul 1999 19:53:53 +0200 (MET DST) From: Juergen Lock Date: Wed, 14 Jul 1999 19:53:53 +0200 To: Matthew Jacob Cc: Juergen Lock , 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> References: <199907130010.RAA87312@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Matthew Jacob on Mon, Jul 12, 1999 at 05:33:51PM -0700 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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: 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 (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