Summary: | Switching to virtual console while using X sometimes freezes system | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Frank T. Lofaro Jr. <ftlofaro> |
Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED UPSTREAM | ||
Severity: | critical | CC: | bensberg |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://bugs.freedesktop.org/show_bug.cgi?id=3473 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Frank T. Lofaro Jr.
2005-05-24 17:03:06 UTC
(In reply to comment #0) > CFLAGS="-O9 -march=pentium2 -fomit-frame-pointer -fno-guess-branch-probability > -fsignaling-nans -mieee-fp" That's cute. Try using flags that aren't so wack. Also please unmask and try 6.8.99.8 to see whether that fixes your problem. Which driver are you using? (In reply to comment #1) > (In reply to comment #0) > > CFLAGS="-O9 -march=pentium2 -fomit-frame-pointer -fno-guess-branch-probability > > -fsignaling-nans -mieee-fp" > > That's cute. Try using flags that aren't so wack. Well it happens to my friend with normal CFLAGS (-O2 and selecting Pentium 4 arch), no ~X86 ACCEPT_KEYWORD and a Pentium 4 CPU, and it happens to me with my "wack" CFLAGS, ~X86 ACCEPT_KEYWORD and a Pentium 2 CPU, so I think something other than my "wack" CFLAGS or my setup in general is the reason - I think it is probably a bit more universal than that. > > Also please unmask and try 6.8.99.8 to see whether that fixes your problem. I am emerging that now with just -O2 CFLAGS, it'll take a while (see my CPU, above :) I wanted to get the above and the following info on my driver out there in the mean time. I'll post again when I test it after it is done. > Which driver are you using? Straight from /etc/X11/xorg.conf: Identifier "Card0" Driver "mga" VendorName "Matrox Graphics, Inc." BoardName "MGA G200 AGP" BusID "PCI:1:0:0" Also, the bug completely kills my machine - no network, etc. Shouldn't we suspect a kernel bug too? Any idea how that happens? And also if there is kernel involvment why panic=3 doesn't help? No, X directly accesses hardware etc so it can lock up your machine without any extra help. (In reply to comment #4) > No, X directly accesses hardware etc so it can lock up your machine without any > extra help. Strangely enough, it NEVER, EVER crashed on shutdown of X, only on a VC switch - doesn't it do the same stuff to the HW (switch back down to text) in each case? When it crashed it ALWAYS had the display in a text mode with a blank screen and a good text mode (640x400x70 Hz) signal, so it seemed to get the HW mode restore done as far as I could tell. Could there be possibly be some interaction with the kernel VC switch code? I emerge'd the version of X you suggested and compiled it with just -O2 and it seems to be working so far - but the bug has a low reproducibility so I don't think of myself as out of the woods yet. Both chvt and ctrl-alt-f# used to crash the system on occasion so I am testing with both - so far so good. I am doing provocative testing now - switching to occupied VCs, unoccupied ones, under no load, under high load, etc. Anything I should be doing to make any bug express itself? I'll try to get my friend with the same issue to try this fix also. His solution was to not switch VCs while in X. :) It just now crashed using your X version compiled with just -O2, during a VC switch. I run kde, so shutting down X means a lot of stuff has to shutdown, and is probably generating a lot of disk I/O and memory access (I only have 128M) and it never crashes then but it does on a VC switch which is a much faster, simpler case. Could it be a race condition? It's more likely X not handling the save and restore of its state properly. Are you using framebuffer consoles? If so, which framebuffer? Try without framebuffer if you have it on now, or try vesafb. I am using normal text mode consoles. I'll try the vesafb consoles next, any particular mode I should use? During the night I had a shell loop running which would switch VC's back and forth every 5 seconds (also run date and sync and I am running ext3). The machine did 2056 switches from X to text and didn't crash once. I had swap disabled for this test. I stopped the shell loop, added swap and let it run again, it had crashed after 195 switches. No, if you're using normal that should be good. It goes roughly like this in order of bad ideas: 1) text mode 2) vesafb 3) custom fb Is there a reasonable way to lock X in memory so it can't get swapped out at all? I can run my stress test on X and see if that helps. It has never crashed when no swap is configured. That might help you narrow it down. It crashed one time with swap off, but free memory was very low. I think the kernel might've throw out pages of X, thinking it can swap them in later. I was thinking of using mlockall to lock X in memory - but I don't want to have to recompile all of xorg to do so just for a temporary workaround. Is there an easier way to do that? I think I'll take this upstream on June 2, this is probably not a gentoo specific issue anyway. Alright, post the URL of the upstream bug here when you do so please. (In reply to comment #13) Posted bug to upstream (bug 3473 on bugs.freedesktop.org): http://bugs.freedesktop.org/show_bug.cgi?id=3473 "Complete system lockup on switch from X to text mode virtual console" URL added here and marked as such. You should reference the upstream bug to this one so that they have everything that has been discussed here. |