Date: Sun, 3 Oct 1999 03:22:54 -0600 (MDT) From: "Kenneth D. Merry" <ken@kdm.org> To: mjacob@feral.com Cc: don@calis.blacksun.org (Don), alpha@FreeBSD.ORG Subject: Re: NCR Problem Message-ID: <199910030922.DAA64199@panzer.kdm.org> In-Reply-To: <Pine.BSF.4.10.9910022357410.53965-100000@beppo.feral.com> from Matthew Jacob at "Oct 3, 1999 00:00:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote... > > (da0:ncr0:0:6:0): READ(06). CDB: 8 0 0 10 0 0 > > (da0:ncr0:0:6:0): extraneous data discarded. > > (da0:ncr0:0:6:0): COMMAND FAILED (9 0) @0xfffffe000057a000. > > (da0:ncr0:0:6:0): xpt_done > > (da0:ncr0:0:6:0): camisr(da0:ncr0:0:6:0): xpt_action > > (da0:ncr0:0:6:0): READ(06). CDB: 8 0 0 10 0 0 > > (da0:ncr0:0:6:0): xpt_setup_ccb > > (da0:ncr0:0:6:0): xpt_action > > (da0:ncr0:0:6:0): extraneous data discarded. > > (da0:ncr0:0:6:0): COMMAND FAILED (9 0) @0xfffffe000057a000. > > Block 16 is attempting to be read for 0 bytes. Something is very > bogus here. There were some changes today that may or may not clear this- > see if that helps. If not, we have to figure why the hell a zero byte read > is being sent down. Why there's any dataphase at all is a mystery too. If he is using -current, then this is almost certainly because of PHK's changes. It should have been fixed by his checkin earlier Saturday. I reproduced this behavior on my test system that has an Adaptec controller. The symptoms were the same -- a READ command with a block number specified but with no length. I'm not sure why there is a data phase at all, but my guess is that the drive tries to return at least one block. In any case, cvsup again, try a new kernel and see if the problem goes away. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910030922.DAA64199>