Hi,
> [...] > Another way is to find cards with a VGA-disable switch; this allows > them to be put on bus 0 and not have the BIOS run. Cards that fit this > criterion are the Millennium I's and ELSA Synergys (Permedia 2) that > we (COMPAQ) have sold in the past. Apparently, most commercial versions > (as opposed to our OEM versions) do NOT have this switch. I was aware of this. Unfortunately, the G200's don't have a switch like that. There is a little ( DOS ) utillity, that allows you to "turn off" the BIOS via software. Although - strictly technically speaking - I can imagine ways of making this work, I don't know if this really prevents the SRM-x86 emulator from touching it during POST- YMMV ;-) I have found, that the card *with BIOS disabled* does not show any video signal in an x86 machine ( as mentioned in my first posting ), but still gets touched by SRM - weird enough, it produces a Pchip error on bus 0 ( I tried it there since SRM only touches it there ) generating a PCI parity error - well, yes, this *is* weird. Unluckily, I don't have and cannot get hold of Millenium I's anymore here in Germany - believe me, I tried ;-) > One other observation: the XFree86 4.0 code is NOT clean WRT handling > cards on multiple primary PCI buses, though it can detect them (as > mentioned in previous postings). The problem area is not the > memory-mapped registers or framebuffers on other than bus 0, but the > use of explicit "legacy" VGA addresses in the code, which will be > forced to bus 0 and NOT the correct bus. We are working on patches for > this situation, and have had some success - one system with an AGP bus > plus 3 PCI buses has had an adapter on each. However, the patches are > not ready for prime time just yet, and do depend on additional kernel > patches to work. I even have some more strange bits on this: XFree 4.0 did not see the second PCI Bus at all on my UP2000, due to a bug in libscanpci - thus X -scanpci and the tool scanpci did not see *any* cards on PCI #1. Yes, /proc/pci showed all cards in #1 and they were working ( my 3com Ethernet sits there ). XFree 4.0.1 does fix this, but generates a kernel Oops on my machine. I deleved into this and found out, that they use the pciconfig_read call to get the cards from the kernel. Somehow, they got the number of available buses wrong. Thus, after successfully calling pciconfig_read for buses 0 and 1, they attemped the call for bus 2, which obviously isn't there. Just for the reference, I included the Oops below. I fixed ( kludged ;-) it, by limiting the max allowed number of PCI buses from 32 to 2 - at least that way, I got the scanpci to work correct in my setup. See (in Xfree 401 sources ): programs/Xserver/hw/xfree86/os-support/bus/Pci.h, line 89 and programs/Xserver/hw/xfree86/os-support/bus/axpPci.c The Oopses were generated on kernels 2.2.14/15/16. I haven't tried 2.3.* or even 2.4.0-test* - I feel somewhat reluctant to use unstable kernels on my *primary* server/work system, if I see Alan Cox's todo list in the kernel-mailing list 8-) However, if there are compelling reasons to believe, that my problems are fixed with 2.3.x or 2.4.0-*, I might give it a try. In the mean time, I probably will use an older x86 system as a multihead X-terminal for the Alpha, but I consider this a kludge ( my window-manager of choice, fvwm2, crashes frequently if run on a server called via X -query <hostname> , but that's another problem ;-). So, I am still open to new ideas and suggestions. Anyway, thanks for the input :-) Sincerely, Thomas Weyergraf -- Thomas Weyergraf [EMAIL PROTECTED] My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S ) "br.ret.spnt.few" - got back from getting beer, did not spend a lot.
