Date: Tue, 12 Dec 1995 21:28:34 +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: <199512122028.AA26804@Sysiphos> In-Reply-To: Rob Mallory <rmallory@wiley.csusb.edu> "Re: ncr[01] conflicts..?" (Dec 10, 11:07)
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 10, 11:07, Rob Mallory wrote:
} Subject: Re: ncr[01] conflicts..?
} > 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)
Well, I have no trouble with 3.04 and an 810,
whatever that means ... :)
} > 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.
Well, I'd like to know, what this "2nd" jumper does ...
} > 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)
They really shouldn't. They should be mapped to quite
different addresses ...
} > 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, you could of course change the order in the PCI
code ...
See line 376 of /sys/pci/pci.c:
for (device=0; device<pci_maxdevice; device ++) {
Change this into
for (device=pci_maxdevice -1; device>=0; device--) {
And the bus is scanned from hich to low slot numbers ...
} > } 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).
Well, but 0xff00 and up is an IMPOSSIBLE address on every PC.
} I'll send it in another message as not to clutter -scsi..:-)
} Let me build a newly sup'd current-kernel first...
Yes, thanks, received them and replied already ...
} > } 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.
} 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..
Well, the 810 will NEVER work at the 0xff00 memory address.
} > } 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..
Well, it seems that it does prefer to boot from the 810, no
matter which slot you put it in ?
This is at least how I understood your comments in the messages
under the subject "bootverbose #1/2" ...
Ok. As I wrote in my other message, you'll most probably get
your system to work with the NCR_IOMAPPED option.
Or you could reverse the probe order, and make the system
find the 810 at the higher slot first ...
I think either way will make your system use both controllers
and is a valid work around ...
The 0cff00 mapping is the real culprit, and you really should
find a way to get rid of it (by upgrading the system's PCI BIOS).
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?199512122028.AA26804>