Date: Thu, 10 Feb 2000 21:44:24 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: Aaron Gifford <agifford@infowest.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 4.0 fails to boot - sym troubles Message-ID: <Pine.LNX.3.95.1000210211357.371B-100000@localhost> In-Reply-To: <20000210042424.B5E5720F78@infowest.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Just quoting the offending messages: On Wed, 9 Feb 2000, Aaron Gifford wrote: > sym0: SCSI parity error detected: SCR=3D1 DBC=3D72580000 SBCL=3Daf > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. The driver gets an SCSI parity error while attempting to snoop the BUS by reading directly the SCSI BUS data line bit 0...7. I have recently discovered experimentally that a spurious SCSI parity error due to the chip checking against parity for bit 8..15 can be triggerred in some special situations, for example when the WSR bit is set. The WSR bit is set when a residual byte didn't fit a previous CHMOV for a scatter entry and the target changes phase at the beginning of the next CHMOV (count) with count > 1. (For count=3D1, the WSR bit isn't set and the residual byte is transferred to memory). Since this issue cannot be cleanly worked-around, I have decided to handle things differently so that it is no longer needed to snoop the BUS by reading directly the SCSI BUS data lines. Result is sym-1.3.2-20000206 that haven't (yet?) been committed due to 4.0 release time.=20 If you could give a try with this driver version, this would help. ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= 000206.readme ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= 000206.tar.gz (The tar contains full driver files to move to src/sys/dev/sym) You may want to let me know if it fixes or not. Thanks. Regards, G=E9rard. PS: On the other hand, I seem to remember that my last commit for the `sym' driver has been done on January the 12th. So the kernel that fails should just use same `sym' driver as 4.0-CURRENT-25-January that succeeds. Btw, if the `ncr' that just ignores the WSR bit succeeds, then I may well be right. On Wed, 9 Feb 2000, Aaron Gifford wrote: > Hello, >=20 > I've got trouble. 4.0-CURRENT won't boot my system because of a=20 > problem with the sym driver and my Tekram 390U2W PCI SCSI3 controller > card. This system worked fine with 3.4-STABLE and will boot with > a 25-Jan-2000 snapshot kernel, but all attempts to boot with a GENERIC > kernel built after 3 Feb. 2000 fail miserably. >=20 > Here are the gory details: >=20 > HARDWARE: > --------- > PII-350 2/64MB RAM > Number9 Motion 771 PCI video card > Tekram 390U2W PCI SCSI3 controller card > 1 Seagate Cheetah 4 GB drive > 1 IBM UltraStore 36GB 10KRPM drive > Kingston EtheRx KNE100TX PCI 10/100 NIC >=20 > SOFTWARE: > --------- > 3.4-STABLE - Worked well and booted just fine with my hardware > 4.0-CURRENT as of 25 Jan. 2000 - Boots just fine with my hardware > 4.0-CURRENT anytime after 3 Feb. 2000 - PROBLEMS! CANNOT BOOT! >=20 >=20 > PROBLEM: > -------- >=20 > During BOOT of the the several different 4.0-GENERIC kernels I've tried > (I tried a 3 Feb. 2000 build, and a 9 Feb. 2000 build) the Tekram SCSI > controller is detected thus: >=20 > sym0: <895> port 0xc800-0xc8ff mem 0xe7001000-0xe70010ff,0xe7000000- > 0xe70000ff irq 9 at device 15.0 on pci 0 > sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking >=20 > Later during the boot, after the 15 second delay ("Waiting 15 seconds > for SCSI devices to settle") the following two lines endlessly repeat > scrolling quickly by on my console forever until I CTRL-ALT-DEL to > force a reboot: >=20 > Waiting 15 seconds for SCSI devices to settle > sym0: SCSI parity error detected: SCR=3D1 DBC=3D72580000 SBCL=3Daf > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. >=20 > The 25 Jan. 2000 kernel (which I stole from the current.freebsd.org > snapshot kernel floppy "kern.flp") works perfectly on this same box: >=20 > Waiting 15 seconds for SCSI devices to settle > Mounting root from ufs:da0s1a > da1 at sym0 bus 0 target 1 lun 0 > da1: <IBM DMVS36V 0100> Fixed Direct Access SCSI-3 device > da1: 80.000MB/s transfers (40.000MHz, offset 31, 16 bit), Tagged > Queuing Enabled > da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4662C) > da0 at sym0 bus 0 target 0 lun 0 > da0: <SEAGATE ST34371W 0338> Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16 bit), Tagged > Queueing Enabled > da0: 4148 MB (8496960 512 byte sectors: 255H 63S/T 528C) >=20 >=20 > QUESTIONS: > ---------- >=20 > I know my hardware setup works, as exhibited by the many successful > boots when I was running 3.4-STABLE and the many many hours of useful > uptime and error-free operation even under heavly disk usage. Also > the successful boot using the 4.0-CURRENT snapshot kernel from 25 Jan. > 2000 ("borrowed" from the snapshot kern.flp floppy) as mentioned > above seems to lead me to believe this is not a hardware problem. >=20 > So now I ask: >=20 > Was there a change in the sym code or the SCSI subsystem between > 25 Jan. 2000 and 3 Feb. 2000 that might account for this behavior? >=20 > OR >=20 > Is there a significant difference between the kernels built for the > installation floppies and the standard -GENERIC kernel that might > explain why the 4.0-CURRENT 25-Jan-2000 snapshot kernel taken from > the installation floppy boots just fine, but any 4.0-GENERIC kernels > I build from source CVSUPed on 3 Feb. 2000 or again on 5 Feb. 2000 > and on 9 Feb. 2000 all fail with the identical errors described above? >=20 > Since my userland is from a 3 Feb. 2000 make world, as long as I'm > booting from the older 25 Jan. 2000 floppy, things just don't quite > work right (and the differences between an GENERIC kernel and a boot > floppy kernel may explain some of the other minor troubles I see). > But I cannot get my userland back in synch. until I get a working > kernel that will boot with my Tekram controller. >=20 > Would someone be willing to build a 4.0-GENERIC kernel for me from > recent sources (say 9 Feb. 2000 or later) and make it available via > FTP or HTTP? That way I could grab a copy and try booting with it > and see if perhaps there might be a quirk on my system that is > poisoning my own builds of GENERIC kernels (like perhaps something > in my /etc/make.conf). If that kernel also fails with the same > above described messages, I'll feel more confident that it isn't > caused by something insanely stupid I'm doing whenever I build a > 4.0 GENERIC kernel. >=20 > Has anyone else with the Tekram 390U2W controller had any troubles > with the sym driver lately? >=20 > Could the problem be that the newer code isn't handling the fact > that I've got an 80MB/s LVD drive connected to the card via one > cable, and a 40MB/s UltraWide drive connected via a second separate > cable (the card has multiple connectors to permit separation of > the LVD and non-LVD drives), each terminated as each is the "end" > of the SCSI bus with the controller in the middle. >=20 > Thanks in advance for any/all tips, pointers, answers, additional > information, ideas, thoughts, etc. >=20 > Aaron out. >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.1000210211357.371B-100000>