On Thu, Jul 01, 2004 at 12:53:49PM -0400, Graham Knap wrote: > If you're interested in knowing what hardware I'm playing with, it's > right here... > > http://www.kontron.com/products/pdproductdetail.cfm?keyProduct=31518 Single-board computer. Hmm. I wonder if there's some PCI configuration space stuff going on here that the XFree86 PCI support code doesn't expect. (Just a stab in the dark.) > You could ask why I'm trying to run neverball on this, knowing that the > performance is likely to be so poor as to make it unplayable... and I'd > answer "I agree, but X shouldn't crash". No, I agree the answer is not "don't do that, then". > Okay, I got the debug X server installed and activated, then logged in on > console 1 as root, and: > > # /etc/init.d/kdm stop > # ulimit -c unlimited > # startx $(which x-terminal-emulator) > > I now have a lone, bare Konsole... Yup. > # /usr/games/neverball > > X promptly crashes with signal 11. I'm back at tty1 but now I have a > problem: the machine seems to be locked up. Nasty. > It isn't responding to keypresses and I can't seem to ssh in. The last > line I see is: > > Please report problems to submit@bugs.debian.org. > > Normally I see a shell prompt immediately after this. > > I've tried turning off swap, reducing the number of kernel modules I load > on boot to an absolute minimum, making sure I have way more free disk > space than my total RAM size, and even bypassing the Konsole and loading > Neverball directly, ie.: > > # startx /usr/games/neverball > > and X still crashes, and my machine still locks up solid when X exits. > After rebooting, there's no core dump file on the disk. Aggravating. Maybe it is going haywire in the signal handler. This might be happening if the SEGV is happening while the graphics engine is being spoken to and is left in the middle of something -- then when the VT restoration logic runs part of the signal handler, it confuses the system to death. (Another stab in the dark.) > If I skip the "ulimit" step, I don't get a lockup when X crashes, Pardon my language, but that's fucked up. I have no theory here. > but obviously I don't get a core file either. > > Any ideas? Try the "NoTrapSignals" option documented in XF86Config-4(5x). Repeat the procedure (with coredumps enabled), but before you start, have a remote shell into the machine. When it crashes, the signal handler will not run, and the video card will be left in graphics mode. You won't be able to change VTs, either, since the X server isn't alive to listen to the keyboard. If I recall correctly, you'll need to start X again from the remote shell. This should re-set up the graphics card -- if it's not too far gone to be recovered, and if you then exit the X server cleanly (not by running neverball), your text VTs should be restored all right. If you can't get a core file even with NoTrapSignals, the only resort is to actually run the X server as root from a remote shell under GDB and set breakpoints at or near where it crashes. Since you won't know that, and probably only a driver guru will be able to make educated guesses, we'll need help if things reach this point. -- G. Branden Robinson | Build a fire for a man, and he'll Debian GNU/Linux | be warm for a day. Set a man on branden@debian.org | fire, and he'll be warm for the http://people.debian.org/~branden/ | rest of his life. - Terry Pratchett
Attachment:
signature.asc
Description: Digital signature