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>