Date: Sat, 5 Oct 1996 11:24:10 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@FreeBSD.org, hsu@freefall.freebsd.org Subject: Re: verbose but cryptic error Message-ID: <199610051824.LAA29950@GndRsh.aac.dev.com> In-Reply-To: <199610051649.SAA00599@uriah.heep.sax.de> from J Wunsch at "Oct 5, 96 06:49:31 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> As Jeffrey Hsu wrote: > > > Sure. I get > > > > mode data len: 11 > > type: 0 > > device-specific: 0 > > blkdesc len: 8 > > density: 0 > > numblk: 3450902 > > reserved: 0 > > bllen: 512 > > So the drive tells that it has 3450902 blocks with 512 bytes each, but > apparently rejects these figures when being used inside a MODE SELECT > command. It's rather unusual for a drive to report the number of > blocks in the MODE SENSE data. Perhaps this is what finally makes > your drive bitching -- scsi(8) simply passes this value on in the MODE > SELECT. Perhaps it should zero out all junk data. I think the fundemental flaw in scsi(8) here is that it should do a mode since on page 2 to check what bits are setable and use that as a mask to the mode select. I haven't looked at the code, but it sounds as if we are ignoring the -P 2 data that says what bits we are allowed to modify between a mode sense and a mode select: mode_select(mode_sense(1A, 0, 1 or 3) & mode_sense(1A, 2)); ^^ this is page from -P ^ always -P2 -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610051824.LAA29950>