Date: Tue, 09 Sep 1997 03:57:01 -0500 From: Doug Ledford <dledford@dialnet.net> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: "Daniel M. Eischen" <deischen@iworks.InterWorks.org>, aic7xxx@freebsd.org Subject: Interesting anomoly with a 2940UW Message-ID: <199709090857.DAA08442@dledford.dialnet.net>
next in thread | raw e-mail | index | archive | help
Got this in my logs tonight, thought it was interesting: Sep 8 11:31:05 news kernel: aic7xxx: Command complete near Qfull count, qoutcnt = 17. Sep 8 11:31:05 news kernel: scsi1: CMDCMPLT without command for SCB 27, QOUTCNT 0, QINCNT 0, SCB flags 0x0, cmd 0x0 Sep 8 11:31:25 news last message repeated 11 times Sep 8 11:31:25 news kernel: scsi : aborting command due to timeout : pid 45576460, scsi1, channel 0, id 6, lun 0 0x2a 00 00 54 1c 34 00 00 02 00 Sep 8 11:31:25 news kernel: (scsi1:6:0) Aborting scb 1, flags 0x1 Sep 8 11:31:25 news kernel: scsi : aborting command due to timeout : pid 45576461, scsi1, channel 0, id 6, lun 0 0x2a 00 00 6d 0d c6 00 00 02 00 Sep 8 11:31:25 news kernel: scsi : aborting command due to timeout : pid 45576462, scsi1, channel 0, id 6, lun 0 0x2a 00 00 71 d4 96 00 00 02 00 Followed by a bunch more timeouts, then eventually a bus reset, then things went back to normal. I kind of liked seeing the qoutcnt = 17, that shouldn't ever happen since I'm running with the spin lock. As a matter of fact, it looks like that 17 was the cause of the following CMDCMPLT without command for SCB statements (once we cleared the QOUTFIFO, it kept returning the same tag value for successive calls when nothing was available to retrieve). Note that in the printk for the CMDCMPLT, we don't use the qoutcnt variable we set up originally, those do independant inb() calls to the specified registers. This would seem to indicate that the 2940UW controller might sometimes get spurious garbage in the 4th bit, so that the 17 should have been a 1 instead. This then messed with the way I have the code writing out the CMDOUTCNT register and resulted in commands being forced to complete sequentially (if at all, I haven't gone entirely through the code path yet) and then resulted in the timeouts and resets as the sequencer spun locked itself into timeout death. The reset code then properly cleared everything out, but it's a shouldn't have happened situation and one I'm going to have to find a reasonable way to avoid now. -- ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * *****************************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709090857.DAA08442>