Date: Sun, 10 Dec 1995 00:32:55 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Rob Mallory <rmallory@wiley.csusb.edu> Cc: scsi@freebsd.org Subject: Re: ncr[01] conflicts..? Message-ID: <199512092332.AA17178@Sysiphos> In-Reply-To: Rob Mallory <rmallory@wiley.csusb.edu> "ncr[01] conflicts..?" (Dec 8, 23:18)
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 8, 23:18, Rob Mallory wrote: } Subject: ncr[01] conflicts..? } OK, I took the "easy" way out,,throw more hardware at it apporach:) } } I finaly found (through a tech at symbios) how to successfully get } both a ncr825 and 810 in my asus p55tp4xe with 3.07 ncr bios. } } the tyan 825 had a 3.04 rom, complete with geometry bugs which } prevented me from installing slowaris-2.5 and freebsd on the same disk. } the tech suggested that the 810 be installed in a lower slot than the } 825 so it booted first. the 825, now romless, would 'use' the 3.07 } bios which was incarnated by the 810 from the asus bios. it follows } that the 810 would have to contain the boot drive. Why can't you update both SDMS ROMs to the same software release level ? I'd be surprised if the slot numbers would make any difference with respect to which ROM is choosen. But I guess you made sure it works as advertised ? (I.e.: Did the SDMS line show that the new BIOS was in fact the one being used ?) There was a message with regard to a mixed 810/825 system recently, and it claimed, that the BIOS did always prefer the 810 as the "MAIN" controller, i.e. no matter which slots the 810 and 825 are put into, the 810 should always get the DOS drive C: ... This is different from what the BSD init code does: The PCI bus is scanned from low to high bus numbers and from low to high slot numbers, and controllers are assigned to drivers in the order they are found. } well, this is where it gets fun. the 810 has a 2 way jumper on it that } says '2nd'. it does what it implies, and moves its mem-base(?) somewhere } else(i guess). see the following boot messages: } } (chopped up for readability) } [conflicting with the 825] } Dec 8 21:58:16 kickme /kernel: Probing for devices on the PCI bus: } Dec 8 21:58:16 kickme /kernel: chip0 <Intel 82437 (Triton)> rev 1 on pci0:0 } Dec 8 21:58:16 kickme /kernel: ncr0 <ncr 53c810 scsi> rev 1 int a irq ?? on pci } 0:6 } Dec 8 21:58:16 kickme /kernel: pci_map_mem failed: device's memrange 0xff00-0xf } fff is incompatible with its bridge's memrange 0x4000000-0xffffffff There is something wrong ... !!! The NCR seems to have been mapped into the memory range of the last 256 bytes just below 64KB. This would be the fault of the BIOS. The FreeBSD PCI code does currently respect these values, even if it considers them badly choosen (and complains) ... * Could you please send **verbose** boot messages (obtained * by booting with "-v" entered at the "Boot: " prompt). * I need all lines starting at "pcibus_setup()" and until * the final PCI ressource report. } Dec 8 21:58:16 kickme /kernel: CACHE TEST FAILED: reg dstat-sstat2 readback fff } fffff. This is a sign, that the NCR does not see the same data as the CPU. That's not surprising, if the memory region 0xff00 to 0xffff in fact has been assigned to the NCR's registers. That region most likely is covered by a WB secondary cache, and the NCR doesn't see the data written before the corresponding cache lines get flushed to RAM. } Dec 8 21:58:16 kickme /kernel: CACHE INCORRECTLY CONFIGURED. } Dec 8 21:58:16 kickme /kernel: chip1 <Intel 82371 (Triton)> rev 2 on pci0:7 } Dec 8 21:58:16 kickme /kernel: vga0 <VGA-compatible display device> rev 0 int a } Dec 8 08:45:56 kickme /kernel: ncr1 <ncr 53c825 wide scsi> rev 2 int a irq 11 o } n pci0:11 } Dec 8 08:45:56 kickme /kernel: (ncr1:0:0): "TOSHIBA MK537FB 6261" type 0 fixed } Dec 8 08:45:57 kickme /kernel: sd0(ncr1:0:0): Direct-Access } Dec 8 08:45:57 kickme /kernel: sd0(ncr1:0:0): FAST SCSI-2 100ns (10 Mb/sec) off } } ...boots off ncr(1), the 825, sd0. Does it in fact work, even though the cache test warned about the lack of coherency ? ??? } [not conflicting boots off ncr1, but of course, the kernel says root on sd0] } Dec 8 08:50:37 kickme /kernel: Probing for devices on the PCI bus: } Dec 8 08:50:37 kickme /kernel: chip0 <Intel 82437 (Triton)> rev 1 on pci0:0 } Dec 8 08:50:37 kickme /kernel: chip1 <Intel 82371 (Triton)> rev 2 on pci0:7 } Dec 8 08:50:38 kickme /kernel: ncr0 <ncr 53c825 wide scsi> rev 2 int a irq 11 o } Dec 8 08:50:38 kickme /kernel: (ncr0:0:0): "TOSHIBA MK537FB 6261" type 0 fixed } Dec 8 08:50:38 kickme /kernel: sd0(ncr0:0:0): Direct-Access } ... } Dec 8 08:50:40 kickme /kernel: ncr1 <ncr 53c810 scsi> rev 1 int a irq 14 on pci } 0:12 } Dec 8 08:50:40 kickme /kernel: ncr1 waiting for scsi devices to settle } Dec 8 08:50:40 kickme /kernel: (ncr1:0:0): "CONNER CFA540S 13B0" type 0 fixed S } Dec 8 08:50:40 kickme /kernel: sd4(ncr1:0:0): Direct-Access } Dec 8 08:50:40 kickme /kernel: sd4(ncr1:0:0): FAST SCSI-2 100ns (10 Mb/sec) off } } sd4 is a 2.1R disk which was probed by sdms at boot, and the bootblocks } were read, a kernel read, and then tried to switch root to sd0. As I wrote above, the SDMS code will prefer the 810 as the boot controller. FreeBSD doesn't, it sees the 825 on PCI bus 0 slot 11 and the 810 on bus 0 slot 12 ... } i noticed how they switch posisions when i jumper the '2nd' jumper.. Do you know, what this "2nd" jumper is supposed to do ? Does it just disable accesses to the cards BIOS ROM ? } my question is,, Why does the ncr probe look backwards to me? } if the 810 is hooked first and booted, and the sd4 kernel is read that } device, why does the kernel call the 810 ncr1? That's because FreeBSD finds it in the higher numbered slot. } ...has anyone else run into this? is there a valid reason for this } being default? ...give me a 'FLIP_NCR_PROBE' option flag! :-) Hmmm, well, have you tried flipping the cards ? Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512092332.AA17178>