Date: Mon, 10 Aug 1998 20:58:19 -0300 (ADT) From: The Hermit Hacker <scrappy@hub.org> To: scsi@FreeBSD.ORG Subject: CAM support for NCR controller... Message-ID: <Pine.BSF.4.02.9808102045460.314-100000@thelab.hub.org>
next in thread | raw e-mail | index | archive | help
...is essentially useless.
When the last snapshot came out (19980716), I went through the trouble of
upgrading my server to the latest snapshot, and pulled out the source tree
based on that date, so that my /usr/src was in sync.
Today, I was just forced to boot my machine using kernel.GENERIC, since
booting with my CAM kernel wouldn't work...it failed to "see" one of the
drives.
My machine looks like (6 SCSI devices on my NCR controller, all internal):
Copyright (c) 1992-1998 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 3.0-19980711-SNAP #0: Sat Jul 11 11:04:24 GMT 1998
jkh@make.ican.net:/usr/src/sys/compile/GENERIC
Timecounter "i8254" frequency 1193182 Hz cost 2429 ns
CPU: Pentium/P54C (167.05-MHz 586-class CPU)
Origin = "GenuineIntel" Id = 0x52c Stepping=12
Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
real memory = 134217728 (131072K bytes)
avail memory = 127664128 (124672K bytes)
Probing for devices on PCI bus 0:
chip0: <Intel 82437VX PCI cache memory controller> rev 0x02 on pci0.0.0
chip1: <Intel 82371SB PCI to ISA bridge> rev 0x01 on pci0.7.0
ide_pci0: <Intel PIIX3 Bus-master IDE controller> rev 0x00 on pci0.7.1
ncr0: <ncr 53c810 fast10 scsi> rev 0x02 int a irq 11 on pci0.8.0
ncr0: waiting for scsi devices to settle
scbus0 at ncr0 bus 0
sd0 at scbus0 target 0 lun 0
sd0: <SEAGATE ST32151N 0284> type 0 fixed SCSI 2
sd0: Direct-Access
sd0: 10.0 MB/s (100 ns, offset 8)
2049MB (4197405 512 byte sectors)
sd1 at scbus0 target 1 lun 0
sd1: <QUANTUM FIREBALL1280S 630C> type 0 fixed SCSI 2
sd1: Direct-Access
sd1: 10.0 MB/s (100 ns, offset 8)
1222MB (2503872 512 byte sectors)
sd2 at scbus0 target 2 lun 0
sd2: <QUANTUM LPS340S 020B> type 0 fixed SCSI 2
sd2: Direct-Access
sd2: 10.0 MB/s (100 ns, offset 8)
327MB (670506 512 byte sectors)
sd3 at scbus0 target 3 lun 0
sd3: <QUANTUM LP240S GM240S01X 6.4> type 0 fixed SCSI 2
sd3: Direct-Access
sd3: 10.0 MB/s (100 ns, offset 8)
234MB (479350 512 byte sectors)
sd4 at scbus0 target 4 lun 0
sd4: <UNISYS U0531 ST3600N 8374> type 0 fixed SCSI 2
sd4: Direct-Access
sd4: 10.0 MB/s (100 ns, offset 8)
500MB (1025920 512 byte sectors)
sd5 at scbus0 target 5 lun 0
sd5: <CONNER CFP1060S 1.05GB 243F> type 0 fixed SCSI 2
sd5: Direct-Access
sd5: 10.0 MB/s (100 ns, offset 8)
1013MB (2074880 512 byte sectors)
vx0: <3COM 3C590 Etherlink III PCI> rev 0x00 int a irq 10 on pci0.10.0
utp[*utp*]: disable 'auto select' with DOS util! address 00:20:af:f7:8f:d2
Warning! Defective early revision adapter!
vga0: <ATI Mach64-GX graphics accelerator> rev 0x00 on pci0.11.0
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
lpt0 at 0x278-0x27f irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface
lpt1 at 0x278-0x27f on isa
lpt1 not probed due to I/O address conflict with lpt0 at 0x278
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <WDC AC22500L>
wd0: 2441MB (4999680 sectors), 4960 cyls, 16 heads, 63 S/T, 512 B/S
wdc0: unit 1 (atapi): <ACER CD-910E/JAS/13N>, removable, dma, iordy
wcd0: 687Kb/sec, 240Kb cache, audio play, 2 volume levels, ejectable tray
wcd0: 80mm data disc loaded, unlocked
npx0 on motherboard
npx0: INT 16 interface
Intel Pentium F00F detected, installing workaround
changing root device to sd0s1a
I haven't tried it yet, since I want to rebuild my system without the CAM
drivers, but I also have an Yamaha SCSI-CDR that, until I switched the
system over to CAM, worked great. After CAM, I'm lucky to write 1 CD.
I'm pretty much blaming all of this on the NCR drivers, since I'm running
a production server 3 provinces away, with the 19980716 CAM drivers, but
with two Adaptec controllers in the machine, and haven't noticed any
problems with it.
As I've always been, I'm more then willing to test code and new snapshots,
but other then previous problem reports sent in (re: COMMAND FAILED
errors), I haven't got a clue where to start.
Actually, I'm going to leave the system "as is" for the next couple of
days, while I await some new hardware to arrive. If someone out there
working on the NCR drivers has suggestions on what I can try towards
providing more debug information on the problem, towards the betterment of
the CAM drivers, please speak up...I provide my system as a test bed.
Thanks...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
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.BSF.4.02.9808102045460.314-100000>