Date: Wed, 9 Feb 2000 21:24:24 -0700 (MST) From: "Aaron Gifford" <agifford@infowest.com> To: freebsd-scsi@freebsd.org Subject: 4.0 fails to boot - sym troubles Message-ID: <20000210042424.B5E5720F78@infowest.com>
next in thread | raw e-mail | index | archive | help
Hello,
I've got trouble. 4.0-CURRENT won't boot my system because of a
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.
Here are the gory details:
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
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!
PROBLEM:
--------
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:
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
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:
Waiting 15 seconds for SCSI devices to settle
sym0: SCSI parity error detected: SCR=1 DBC=72580000 SBCL=af
(noperiph:sym0:0:-1:-1): SCSI BUS reset detected.
The 25 Jan. 2000 kernel (which I stole from the current.freebsd.org
snapshot kernel floppy "kern.flp") works perfectly on this same box:
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)
QUESTIONS:
----------
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.
So now I ask:
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?
OR
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?
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.
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.
Has anyone else with the Tekram 390U2W controller had any troubles
with the sym driver lately?
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.
Thanks in advance for any/all tips, pointers, answers, additional
information, ideas, thoughts, etc.
Aaron out.
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?20000210042424.B5E5720F78>