Re: Compaq built-in ncr tl controllers with 4.0
Mr. Rabson- Sorry it's been so long for me to get back to you about the patch you sent. The machine is located accross country 3 time zones away, so coordinating with the people at the console has been tedious. In any case, the patch worked brilliantly. The machine is now running a 4.0 generic kernel and is in the process of building and installing the SMP kernel. I would suggest that the patches make their way into the 4.0 and 3.1 source trees, although I have yet to test them on a machine that was not affected by the PCI bus probe problem. I'll incorporate the patch into a more conventional 4.0 machine later today and let you know the results. We want to thank you so much for your quick response. The owners of the machine are quite gratified that they will be able to take advantage of the second processor after all. The dmesg from the machine appears below, in case you find it interesting. -Ben Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sat Feb 20 16:51:12 PST 1999 bhle...@server.mediumlook.com:/usr/src/sys/compile/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Pentium II (299.53-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping=3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO V,MMX real memory = 16777216 (16384K bytes) avail memory = 13316096 (13004K bytes) Preloaded elf kernel kernel at 0xf0342000. Probing for devices on PCI bus 0: chip0: Ross (?) host to PCI bridge rev 0x01 on pci0.0.0 vga0: S3 Trio graphics accelerator rev 0x43 int a irq 11 on pci0.13.0 chip1: PCI to ISA bridge (vendor=0e11 device=a0f3) rev 0x0c on pci0.15.0 ide_pci0: PCI IDE controller (busmaster capable) rev 0x0a int a irq 15 on pci0 .15.1 chip2: Ross (?) host to PCI bridge rev 0x01 on pci0.17.0 Probing for devices on PCI bus 1: tl0: Compaq Netelligent 10/100 Proliant rev 0x10 int a irq 11 on pci1.7.0 tl0: Ethernet address: 00:80:5f:85:97:2e tl0: autoneg complete, link status good (half-duplex, 10Mbps) ncr0: ncr 53c875 fast20 wide scsi rev 0x04 int a irq 11 on pci1.9.0 adv0: AdvanSys ASC3150 Ultra SCSI controller rev 0x02 int a irq 11 on pci1.10. 0 adv0: AdvanSys Ultra SCSI Host Adapter, SCSI ID 0, queue depth 16 Probing for devices on PCI bus 2: Probing for PnP devices: CSN 1 Vendor ID: ESS1868 [0x68187316] Serial 0x Comp ID: @@@ [0x ] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 ed0 not found at 0x280 fe0 not found at 0x300 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 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 (atapi): CD-ROM CDU571-Q/1.1a, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked wdc1 not found at 0x170 wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 ie0: unknown board_id: f000 ie0 not found at 0x300 ep0 not found at 0x300 ex0 not found le0 not found at 0x300 lnc0 not found at 0x280 ze0 not found at 0x300 zp0 not found at 0x300 cs0 not found at 0x300 adv0 not found at 0x330 bt0 not found at 0x134 aha0 not found at 0x134 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da1 at adv0 bus 0 target 4 lun 0 da1: iomega jaz 1GB J.83 Removable Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15) da1: Attempt to query device size failed: NOT READY, Medium not present da0 at ncr0 bus 0 target 0 lun 0 da0: COMPAQ WDE4360W 1.52 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) -- Benjamin Lewis bhle...@gte.net -or- bhle...@purdue.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
On Sun, 21 Feb 1999, Benjamin Lewis wrote: Mr. Rabson- Sorry it's been so long for me to get back to you about the patch you sent. The machine is located accross country 3 time zones away, so coordinating with the people at the console has been tedious. In any case, the patch worked brilliantly. The machine is now running a 4.0 generic kernel and is in the process of building and installing the SMP kernel. I would suggest that the patches make their way into the 4.0 and 3.1 source trees, although I have yet to test them on a machine that was not affected by the PCI bus probe problem. I'll incorporate the patch into a more conventional 4.0 machine later today and let you know the results. We want to thank you so much for your quick response. The owners of the machine are quite gratified that they will be able to take advantage of the second processor after all. The dmesg from the machine appears below, in case you find it interesting. I've committed the fix to both branches, thanks for the feedback. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
Sorry it's been so long for me to get back to you about the patch you sent. The machine is located accross country 3 time zones away, so coordinating with the people at the console has been tedious. In any case, the patch worked brilliantly. The machine is now running a 4.0 generic kernel and is in the process of building and installing the SMP kernel. I can confirm that the patch solved the PCI bus problem here too. The machine here is now running 3.1-STABLE. I have included the dmesg output at the end of this message. As for SMP, we're not quite there yet. First, generic SMP kernel panics because it finds 50 INTRs. After building a new kernel with 50 INTRs, we got a new panic: assign_apic_irq: inconsistent table. I can't say I'm surprised, because I *know* there are problems with the Compaq mptable (from earlier message about MP Proliants). So I'm now digging into the Compaq mptable - which is also included at the end of this message. Steinar Haug, Nethelp consulting, sth...@nethelp.no -- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #2: Sun Feb 21 17:10:46 CET 1999 t...@newsfeed1.telia.no:/usr/src/sys/compile/NEWSFEED1 Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 332803853 Hz CPU: Pentium II/Xeon/Celeron (332.80-MHz 686-class CPU) Origin = GenuineIntel Id = 0x651 Stepping=1 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,b24 real memory = 603979776 (589824K bytes) avail memory = 584593408 (570892K bytes) Preloaded elf kernel kernel at 0xf02a5000. eisa0: CPQ561 (System Board) Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: Ross (?) host to PCI bridge rev 0x03 on pci0.0.0 vga0: Cirrus Logic GD5430 SVGA controller rev 0x22 int a irq 255 on pci0.6.0 chip1: PCI to EISA bridge (vendor=0e11 device=0001) rev 0x07 on pci0.15.0 chip2: Ross (?) host to PCI bridge rev 0x03 on pci0.17.0 Probing for devices on PCI bus 1: ncr0: ncr 53c875 fast20 wide scsi rev 0x14 int a irq 9 on pci1.4.0 ncr1: ncr 53c875 fast20 wide scsi rev 0x14 int b irq 10 on pci1.4.1 fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 10 on pci1.7.0 fxp0: Ethernet address 00:90:27:13:f6:21 tl0: Compaq Netelligent 10/100 rev 0x10 int a irq 5 on pci1.8.0 tl0: Ethernet address: 00:08:c7:1e:a7:35 tl0: autoneg complete, link status good (half-duplex, 100Mbps) Probing for devices on PCI bus 2: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0: failed to get data. psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A 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 (atapi): CD-ROM CDU571-Q/1.1a, removable, accel, dma, iordis acd0: drive speed 1378KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface ccd0-3: Concatenated disk drivers Waiting 5 seconds for SCSI devices to settle changing root device to da0s3a da0 at ncr0 bus 0 target 0 lun 0 da0: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da2 at ncr0 bus 0 target 4 lun 0 da2: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da2: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da3 at ncr0 bus 0 target 5 lun 0 da3: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da3: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) da1 at ncr0 bus 0 target 1 lun 0 da1: COMPAQ HD0093172C 3207 Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8678MB (17773500 512 byte sectors: 255H 63S/T 1106C) -- === MPTable, version 2.0.15 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000f4ff0 signature:'_MP_' length: 16 bytes version: 1.4 checksum:
Re: Compaq built-in ncr tl controllers with 4.0
On Wed, 17 Feb 1999, Benjamin Lewis wrote: Hello- I've been trying to get 3.1 or 4.0 to run on a Compaq Professional Workstation 6000 with dual PII-300s, using the built-in symbios 53c875 SCSI controller, and the built-in ThunderLan ethernet adapter. The machine works perfectly with 2.2.8, but we'd like to get it running 3.1 (or 4.0 if necessary) to take advantage of the second CPU. We have been able to complete a make upgrade with freshly cvsupped 3.1 source, to the point where the new kernel boots. While booting, the GENERIC kernel does not find the ncr or tl devices, and of course fails to mount root. I'd include dmesg from those boots, but it doesn't get far enough to write it anywhere. The new bootblocks seem to be working fine, and are able to boot the kernel, but it fails with a cannot mount root message and then panics. We then tried to boot with the 3.1 and the 4.0 boot floppies. Neither was able to find the SCSI controller or the ethernet device. Of course, we find it odd that 2.2.8 found the devices ok, but newer releases do not. As far as I can tell, the hardware is supported by CAM, etc. (I have a Tekram 390F 53c875-based card in another 4.0 machine that works great). The installs failed with the complaint that no disks could be found to install on. A search through the mailing list archives yielded little information that still seemed relevant (apparently, the tl0 driver wasn't around in 2.2.6 or earlier but that obviously changed before 2.2.8). I've included the 2.2.8 dmesg output below. I'm hoping that someone out there will see something in them that I cannot and will provide us with the magic incantation needed to get this thing running 3.1 or 4.0. Our suspicions are on the PCI bridge, since both the unfound devices are on pci bus 1, while the detected devices reside on bus 0, but we don't know what to do about that. By the way, the unidentified storage device that doesn't get a driver assigned on pci1:10 is a Jaz Jet card, apparently with an Advansys chipset, that 2.2.8 doesn't grok, but 3.1+ should find ok. It doesn't get detected by 3.1 or 4.0 kernels either. Thank you in advance, -Ben As Michael Reifenberger r...@nihil.plaut.de suggested, it might be something to do with the fact that all of these devices are behind a pci-pci bridge. In the 2.2.8 boot, you can see the bridge as chip1 in log. Can you tell me if the 3.1 kernel detects this bridge properly and what the probe message is for it. Try a verbose boot (boot -v) to get the pci code to print more about what it is doing. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
On Thu, 18 Feb 1999, Michael Reifenberger wrote: Hi, On Wed, 17 Feb 1999, Benjamin Lewis wrote: ... We then tried to boot with the 3.1 and the 4.0 boot floppies. Neither was able to find the SCSI controller or the ethernet device. Of course, we find it odd that 2.2.8 found the devices ok, but newer releases do not. As far as I can tell, the hardware is supported by CAM, etc. (I have a Tekram 390F 53c875-based card in another 4.0 machine that works great). The installs failed with the complaint that no disks could be found to install on. I have the same symptoms with an Compaq Proliant 1600. The cause seems to be that these machines have more than one PCI-Busses which lay behind on PCI-PCI-Bridges and only one gets probed/found under 3.*, 4.*. Furthermore under 2.2.7 the Busses seems to get probed but in an different order than the BIOS does because the ncr for the internal disks (which gets probed first by BIOS) is probed last by the Kernel and im my case the BIOS-drive C: gets da2. Verry annoying if Disks get added into the cabinet... :-( Do the symptoms trigger some Ideas by someone? It may be that we aren't detecting the bridge properly in the 3.1 pci code. On the subject of probe ordering, I know about this. We probe the pci bus tree in breadth first order (i.e. we finish probing all the devices in the top bus before probing bridges attached to it). I guess most other systems (including your BIOS) use a depth first order which means that the contents of the bus behind the bridge is probed before it goes onto the next device at the top level. I may end up changing this so we probe in a depth first order due to some other changes I am making to the pci code. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
On Thu, 18 Feb 1999, Doug Rabson wrote: ... It may be that we aren't detecting the bridge properly in the 3.1 pci code. dmesg under 2.2.7 shows: ... eisa0: CPQ553 (System Board) Probing for devices on the EISA bus DPT: EISA SCSI HBA Driver, version 1.4.3 Probing for devices on PCI bus 0: chip0 Ross (?) host to PCI bridge rev 3 on pci0:0:0 vga0... ncr0... ... chip1 generic PCI bridge (vendor=0e11 device=0001 subclass=2) rev 7 on pci0:15:0 chip2 Ross (?) host to PCI bridge rev 3 on pci0:17:0 Probing for devices on PCI bus 1: ... ncr1... sd0... st0... ... Hmm. a quick: `cvs diff -u -r1.40.2.1 -r1.40.2.7 pcisupport.c` showed that the occurances of config_Ross went in in 1.40.2.7 to pcisupport.c by se. Seems we have some functtionality missing in the -current. May I ask you to merge the missing routines over? ... I may end up changing this so we probe in a depth first order due to some other changes I am making to the pci code. Would be nice. Thanks. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Compaq built-in ncr tl controllers with 4.0
On Thu, 18 Feb 1999, Michael Reifenberger wrote:
On Thu, 18 Feb 1999, Doug Rabson wrote:
...
It may be that we aren't detecting the bridge properly in the 3.1 pci
code.
dmesg under 2.2.7 shows:
...
eisa0: CPQ553 (System Board)
Probing for devices on the EISA bus
DPT: EISA SCSI HBA Driver, version 1.4.3
Probing for devices on PCI bus 0:
chip0 Ross (?) host to PCI bridge rev 3 on pci0:0:0
vga0...
ncr0...
...
chip1 generic PCI bridge (vendor=0e11 device=0001 subclass=2) rev 7 on
pci0:15:0
chip2 Ross (?) host to PCI bridge rev 3 on pci0:17:0
Probing for devices on PCI bus 1:
...
ncr1...
sd0...
st0...
...
Hmm. a quick: `cvs diff -u -r1.40.2.1 -r1.40.2.7 pcisupport.c` showed that the
occurances of config_Ross went in in 1.40.2.7 to pcisupport.c by se.
Seems we have some functtionality missing in the -current.
May I ask you to merge the missing routines over?
...
I may end up changing this so we probe in a depth first order due to some
other changes I am making to the pci code.
Would be nice. Thanks.
I'm working blind here but it seems to me that this patch might fix it.
It might probe one too many busses but that can be fixed by removing the
+1 in fixbushigh_Ross().
Index: pcisupport.c
===
RCS file: /home/ncvs/src/sys/pci/pcisupport.c,v
retrieving revision 1.92
diff -u -r1.92 pcisupport.c
--- pcisupport.c1999/02/13 17:51:46 1.92
+++ pcisupport.c1999/02/18 22:34:59
@@ -204,7 +204,17 @@
tag-secondarybus = tag-subordinatebus = subordinatebus;
}
+static void
+fixbushigh_Ross(pcici_t tag)
+{
+ int secondarybus;
+ /* just guessing the secondary bus register number ... */
+ secondarybus = pci_cfgread(tag, 0x45, 1);
+ if (secondarybus != 0)
+ tag-secondarybus = tag-subordinatebus = secondarybus + 1;
+}
+
static void
fixwsc_natoma(pcici_t tag)
{
@@ -388,6 +398,11 @@
return (NEC 002C PCI to PC-98 C-bus bridge);
case 0x003b1033:
return (NEC 003B PCI to PC-98 C-bus bridge);
+
+ /* Ross (?) -- vendor 0x1166 */
+ case 0x00051166:
+ fixbushigh_Ross(tag);
+ return (Ross (?) host to PCI bridge);
};
if ((descr = generic_pci_bridge(tag)) != NULL)
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Compaq built-in ncr tl controllers with 4.0
Hello- I've been trying to get 3.1 or 4.0 to run on a Compaq Professional Workstation 6000 with dual PII-300s, using the built-in symbios 53c875 SCSI controller, and the built-in ThunderLan ethernet adapter. The machine works perfectly with 2.2.8, but we'd like to get it running 3.1 (or 4.0 if necessary) to take advantage of the second CPU. We have been able to complete a make upgrade with freshly cvsupped 3.1 source, to the point where the new kernel boots. While booting, the GENERIC kernel does not find the ncr or tl devices, and of course fails to mount root. I'd include dmesg from those boots, but it doesn't get far enough to write it anywhere. The new bootblocks seem to be working fine, and are able to boot the kernel, but it fails with a cannot mount root message and then panics. We then tried to boot with the 3.1 and the 4.0 boot floppies. Neither was able to find the SCSI controller or the ethernet device. Of course, we find it odd that 2.2.8 found the devices ok, but newer releases do not. As far as I can tell, the hardware is supported by CAM, etc. (I have a Tekram 390F 53c875-based card in another 4.0 machine that works great). The installs failed with the complaint that no disks could be found to install on. A search through the mailing list archives yielded little information that still seemed relevant (apparently, the tl0 driver wasn't around in 2.2.6 or earlier but that obviously changed before 2.2.8). I've included the 2.2.8 dmesg output below. I'm hoping that someone out there will see something in them that I cannot and will provide us with the magic incantation needed to get this thing running 3.1 or 4.0. Our suspicions are on the PCI bridge, since both the unfound devices are on pci bus 1, while the detected devices reside on bus 0, but we don't know what to do about that. By the way, the unidentified storage device that doesn't get a driver assigned on pci1:10 is a Jaz Jet card, apparently with an Advansys chipset, that 2.2.8 doesn't grok, but 3.1+ should find ok. It doesn't get detected by 3.1 or 4.0 kernels either. Thank you in advance, -Ben Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.8-STABLE #0: Wed Feb 17 09:02:09 GMT 1999 bhle...@server2.mediumlook.com:/usr/src/sys/compile/CALVIN CPU: Pentium II (299.53-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping=3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO V,MMX real memory = 536870912 (524288K bytes) avail memory = 524316672 (512028K bytes) Probing for devices on PCI bus 0: chip0 Ross (?) host to PCI bridge rev 1 on pci0:0:0 pci0:9:Compaq, device=0xa0f8, class=serial, subclass=0x03 int a irq 11 [no d river assigned] vga0 VGA-compatible display device rev 1 int a irq 11 on pci0:13:0 chip1 generic PCI bridge (vendor=0e11 device=a0f3 subclass=1) rev 12 on pci0:1 5:0 pci0:15:1: Compaq, device=0xae33, class=storage (ide) int a irq 15 [no driver as signed] chip2 Ross (?) host to PCI bridge rev 1 on pci0:17:0 Probing for devices on PCI bus 1: tl0 Compaq Netelligent 10/100 Proliant rev 16 int a irq 11 on pci1:7:0 tl0: Ethernet address: 00:80:5f:85:23:8b tl0: autoneg complete, link status good (half-duplex, 10Mbps) ncr0 ncr 53c875 fast20 wide scsi rev 4 int a irq 11 on pci1:9:0 ncr0 waiting for scsi devices to settle (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15) (ncr0:0:0): COMPAQ WDE4360W 1.52 type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): WIDE SCSI (16 bit) enabled sd0(ncr0:0:0): 40.0 MB/s (50 ns, offset 15) 4094MB (8386000 512 byte sectors) pci1:10:vendor=0x10cd, device=0x1300, class=storage (scsi) int a irq 11 [no driver assigned] 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 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 not found at 0x mse0 not found at 0x23c psm0 at 0x60-0x64 irq 12 on motherboard psm0: model Generic PS/2 mouse, device ID 0 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 (atapi): CD-ROM CDU571-Q/1.1a, removable, accel, dma, iordis wcd0: 1378KB/sec, 128KB cache, audio play, 256 volume levels, ejectable tray wcd0: door open, unlocked wdc1 not found at 0x170 uha0 not found at 0x330 aha0 not found at 0x330 aic0 not found at 0x340 nca0 not found at 0x1f88 nca1 not found at 0x350 sea0 not found wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 npx0 flags 0x1 on motherboard npx0: INT 16 interface -- Benjamin Lewis bhle...@gte.net -or- bhle...@purdue.edu To Unsubscribe: send mail to
Re: Compaq built-in ncr tl controllers with 4.0
Hi, On Wed, 17 Feb 1999, Benjamin Lewis wrote: ... We then tried to boot with the 3.1 and the 4.0 boot floppies. Neither was able to find the SCSI controller or the ethernet device. Of course, we find it odd that 2.2.8 found the devices ok, but newer releases do not. As far as I can tell, the hardware is supported by CAM, etc. (I have a Tekram 390F 53c875-based card in another 4.0 machine that works great). The installs failed with the complaint that no disks could be found to install on. I have the same symptoms with an Compaq Proliant 1600. The cause seems to be that these machines have more than one PCI-Busses which lay behind on PCI-PCI-Bridges and only one gets probed/found under 3.*, 4.*. Furthermore under 2.2.7 the Busses seems to get probed but in an different order than the BIOS does because the ncr for the internal disks (which gets probed first by BIOS) is probed last by the Kernel and im my case the BIOS-drive C: gets da2. Verry annoying if Disks get added into the cabinet... :-( Do the symptoms trigger some Ideas by someone? Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
