Multiseat with Appian Jeronimo Pro
Federico Heinz
fheinz at vialibre.org.ar
Fri Dec 30 13:03:25 PST 2005
I trying to set up a multiseat machine with an Appian Jeronimo Pro card.
This is a large PCI card, which actually contains four Permedia cards
behind a PCI bridge. The 'lspci' program reports it like this:
0000:01:01.0 VGA compatible controller: 3DLabs Permedia II 2D+3D (rev 01)
0000:01:05.0 VGA compatible controller: 3DLabs Permedia II 2D+3D (rev 01)
0000:01:09.0 VGA compatible controller: 3DLabs Permedia II 2D+3D (rev 01)
0000:01:0d.0 VGA compatible controller: 3DLabs Permedia II 2D+3D (rev 01)
I have gotten the system to work, following instructions scattered all
over the web. Only thing that was different from other people
experiences was that everybody recommends to use the "NoInt10" option,
to avoid cards stepping over each other on initialization. If I use
"NoInt10", the display is garbled, so I left it out.Once I get the four
graphical login managers up, everything works very robustly.
Unfortunately, the startup sequence is... ermmm... sub-optimal. The
problem is that, each card will lock up the first server that tries to
access it, badly (can be killed only with SIGKILL). In other words: when
gdm tries to bring up the first seat, the seat's server will lock up. If
I log in remotely and restart gdm, the first seat will come up, but the
second one locks. I restart gdm again, and seats #1 and #2 come up, but
#3 locks. You can apply induction from there.
I have tried starting the system without gdm, then probing the seats
individually (with -probeonly), which locks them up, of course, and then
killing them. After that procedure, gdm will come up fine. I guess I
could try to automate this process in a startup script, but the idea of
starting up a program knowing that it will wedge and with the intention
of SIGKILLing it a few seconds later from the same script is way too
crufty for my delicate stomach.
Stracing the server, the last portion of the output is:
# strace /usr/X11R6/bin/X -br -audit 0 -layout 'Multiseat Session #2' :1
vt8 -sharevts -novtswitch -probeonly
[...lots of stuff omitted...]
write(0, "(II) Truncating PCI BIOS Length "..., 41) = 41
open("/dev/mem", O_RDONLY) = 7
mmap2(NULL, 32768, PROT_READ, MAP_SHARED, 7, 0xf9d70) = 0xb7cbc000
munmap(0xb7cbc000, 32768) = 0
close(7) = 0
lseek(5, 48, SEEK_SET) = 48
write(5, "\0\0\327\371", 4) = 4
brk(0x86c8000) = 0x86c8000
lseek(5, 4, SEEK_SET) = 4
write(5, "\4\0\220\2", 4) = 4
lseek(5, 4, SEEK_SET) = 4
write(5, "\4\0\220\2", 4) = 4
lseek(5, 4, SEEK_SET) = 4
write(5, "\7\0\220\2", 4) = 4
lseek(5, 4, SEEK_SET) = 4
write(5, "\7\0\220\2", 4) = 4
rt_sigprocmask(SIG_BLOCK, [IO], [], 8) = 0
vm86old(0x8570aa8) = -1 ENOSYS (Function not implemented)
vm86old(0x8570aa8) = -1 ENOSYS (Function not implemented)
vm86old(0x8570aa8) = -1 ENOSYS (Function not implemented)
vm86old(0x8570aa8) = -1 ENOSYS (Function not implemented)
vm86old(0x8570aa8) = -1 ENOSYS (Function not implemented)
This last line repeats MANY, MANY times, and then the output just stops.
Any ideas on what may be causing the problem and/or how to handle it?
Fede
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20051230/59d7d0e1/attachment.pgp>
More information about the xorg
mailing list