Date: Sun, 10 Dec 1995 11:07:58 -0800 (PST) From: Rob Mallory <rmallory@wiley.csusb.edu> To: se@zpr.uni-koeln.de (Stefan Esser) Cc: scsi@freebsd.org Subject: Re: ncr[01] conflicts..? Message-ID: <199512101907.LAA25763@wiley.csusb.edu> In-Reply-To: <199512092332.AA17178@Sysiphos> from "Stefan Esser" at Dec 10, 95 00:32:55 am
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 dont have an EEPROM on the 825. It's just more conveinent to u/g to the latest SDMS rev with a new MB bios upgrade. also, the 3.04 PROM I have won't drive the 810. (the tech seemed to know about this) > > I'd be surprised if the slot numbers would make > any difference with respect to which ROM is choosen. yup. they do. notice by me, and verified by a tech at symbios. I have to remove the rom, and put the 825 in slot2 (closer to the mediabus slot) and the 810 in slot1. no other way will work. the bios' step on each other.. the only thing to 'play' with at this point is the "2nd" jumper and the IRQ's in the asus pci bios setup. > > 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 ?) yep. 3.07. if I leave the 3.04 rom in, with the 810 in slot1, I get a 'DISK BOOT FAILURE' as *no* SDMS bios is found. (they step all over each other) > > > 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. is there a hack that can be dropped in for 'reverse scan' of the pci-bus for FreeBSD? > > } 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) ... My guess is that the '2nd' jumper tells the chip where to advertise itself.? one way it setps on the 825's memrange(above), and the other way works(below). > > * 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. I'll send it in another message as not to clutter -scsi..:-) Let me build a newly sup'd current-kernel first... > > > } 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 ? ??? only the 825 works, even the bootblocks are read off the 825. I guess I could make a dos floppy with sdms and scsidisk.com on it and put my (only:) dos drive on the 810 and see what happens.. > > } [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 ? see my guess above. > > } 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. the symbios tech said the SDMS will only look from low to high. and I would have to put my boot drives on the 810. I left his name/number at work, but I think his name was Gary something.. > > } ...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 ? yup. only one combo works. see above. -- Rob Mallory
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512101907.LAA25763>