Re: Potato/Xfree401/mutlihead problems
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 kirk@colinet.de
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.
Reply to: