Bug 327064

So could you attach config and logfile? Especially the lines in logfile during VT switch?

in which logfile?

Is this an Xorg bug or not?

If it is an Xorg bug, then the logfile referred to is /var/log/Xorg.0.log

If this is not an Xorg bug, then do reassign.

there is no logfile, the machine locks solid. 

We are not asking for a log of the machine hanging, just a log of your X working so that we can see what it is that you are actually running and which subsystems you are using.

Created attachment 173858 [details]
Xorg.0.log

Dirk does this by any chance look like my screenshot of the initial bug #301101 ? (i.e. a kind of yellow screen?)

Reassigning to Egbert.

I gave a hp compaq nx5000 which was pretty plagued by this error to the Xorg team, so it should be in Luc's office. Egbert played around with it on Thursday.

It is quite hard to reproduce this issue on the hp compaq nx5000 and according to Egbert it's running very unstable (unrelated to this issue).

This problem seems to only surface under very special conditions. Dirk and Stefan tried to reproduce it and it looks like it only happens when the VT is switched after pulling the power plug. 
Stefan has tried several other scenarions but was unable to lock up this system.
Since the situatlions under which this error occurs are so special the current severity doesn't seem to be justified.
This bug is somewhat along the line of the infamous NX5000 bug: #290219.

so using a laptop without AC power plugged in is a special scenario?

Dirk, Stafan tried that. He was only able to trigger the problem when he vt-switched within a second or so after pulling the plug.

Dirk, the reason to set this to LATER is just the amount of time this would take to investigate. It's not possible for 10.3 any more. Please do not take this personal. This issue won't be forgotten. I appreciate the time you invested yesterday to show me how to reproduce this issue. I could reproduce this issue only once today by suspending the machine before, but no longer remember the details. :-(

this is not the only circumstance when it happens, it merely makes it easier to trigger. yesterday my machine crashed twice even though the power was connected all the time. 

this is unacceptable, so lets restart the bug for 11.0.

Dirk, I understand that this one is annoying. I will eventually look at it. But it's really hard to fix without a reliable way to trigger it.
Also systems hands are difficult to understand without intimate knowledge of the system itself.
We can try to find out where it happens. Does this box still have a parallel port?
Then we can attach a tool and scatter outb()s all over the code until we have narrowed down where it happens.
Otherwise this is hard to find if the system is dead afterwards.

ok, two weeks later and still nothing has happened. 

some observations: 

a) it happens even without pluggin/unplugging AC

b) DISPLAY=:0 xrandr trashes display when run from text mode while X server is running under :0. this only happens with intel, other chipsets work fine. it doesn't seem allright that the X server trashes my display on that command. 

c) smells like something is uninitialized. some X server runs are remarkably stable. I can switch at least a dozen time between console/X without a hitch. Somtimes its extremely unstable, and the very first switch after booting already hangs the machine. 

d) running an arbitrary application that keeps  the X server saturated with drawing seems like a good way to provoke the hang during vt switch. 

i believe that b) could be related to the actual problem, given that KDE does intensive xrandr queries, and if it does that at the wrong time during switch from/to vt, it could cause this machine hang

my hardware doesn't have a parallel port anymore but it has firewire and USB, if that helps. 

given that this has more an ultrablocker state for me than being a normal bug (essentially on bad days I have to reboot my machine 10 times a day, with lots of unsaved work that is essentially lost), is there any chance that anyone could work on this pretty pretty please?

Dirk,
I seem to recall from Stefan's investigations that this problem happens during VT switch (independently from suspend).
I'm not sure if b) is realated - but if it is it seems to be valuable hint. We has a bug report a while ago reporting a similar problem - but for some reason I list it out of sight.
Stefan, do you still have this laptop you tried to reproduce Dirk's problem with? If I may be able to look at this from remote (and your help).

Currently I don't have this laptop, but I think I can get it back from seife without any problems.

I don't think its specific to this particular laptop though, it happens with any intel hardware I've seen. 

daniel gollub has the same issue, but has a totally different laptop (although also intel gfx card)

I updated to todays factory:
# cat /etc/SuSE-release
openSUSE 10.3.1 (i586) Alpha0
VERSION = 10.3.1

and it seems like the VT switching behavior really changed, I have successfully been switching for 20 times now.

Ok. Maybe updating xorg-x11-server, xorg-x11-driver-video and xorg-x11-driver-input already fixes this issue for Dirk as well.

Same issue?

  http://lists.freedesktop.org/archives/xorg/2007-October/029534.html

regarding comment #25/#26: no, the bug is not fixed, it still happends with xorg 7.3. 

regarding comment #27: one reboot later I can confirm that the patch only makes it more reliable to crash. 

The machine is now actively used by Frank, so i'm not sure if we can give it to you.

Ok. If he doesn't stumble across this issue it doesn't make sense to investigate this issue on this machine anyway. Otherwise he probably will be happy to switch to another machine, so we can have it again for investigating. ;-)

oh, was there any interest already in debugging the issue? I'd be happy to debug it here if I know how..

another week without reply... ping..

Possibly related upstream bugs:

  http://bugs.freedesktop.org/show_bug.cgi?id=11525
  http://bugs.freedesktop.org/show_bug.cgi?id=12555
  http://bugs.freedesktop.org/show_bug.cgi?id=12356
  http://bugs.freedesktop.org/show_bug.cgi?id=11269
  http://bugs.freedesktop.org/show_bug.cgi?id=12297

Dirk, could you try current git of intel driver. I'm asking since a lot of VT switch fixes has been pushed upstream now.

do you have one that compiles? last time I tried it didn't work on the first try. 

Hmm. I submitted 2.1.99 today to STABLE. It might already contain this patch.

It contains the patch. If 2.1.99 / STABLE is not an option, please try git commit eecd3ccedee6c4acf101591f7e60673660379e62. I'll attach the patch for your convenience.

Created attachment 182906 [details]
commit-eecd3cc.diff

The patch seems to be broken.

http://lists.freedesktop.org/archives/xorg/2007-November/030128.html
http://lists.freedesktop.org/archives/xorg/2007-November/030129.html

ah, that gives a clue on why the previous patch was not working.. I'm testing the new one. 

I'm unable to get a crash after applying this typo fix to STABLE: 

--- src/i830_driver.c
+++ src/i830_driver.c
@@ -2056,8 +2056,8 @@
     * Make sure the DPLL is active and not in VGA mode or the
     * write of PIPEnCONF may cause a crash
     */
-   if ((pI830->saveDPLL_B & DPLL_VCO_ENABLE) &&
-       (pI830->saveDPLL_B & DPLL_VGA_MODE_DIS))
+   if ((pI830->saveDPLL_A & DPLL_VCO_ENABLE) &&
+       (pI830->saveDPLL_A & DPLL_VGA_MODE_DIS))
           OUTREG(PIPEACONF, pI830->savePIPEACONF);
    i830WaitForVblank(pScrn);
    OUTREG(DSPACNTR, pI830->saveDSPACNTR);

so indeed the "ubuntu fix" fixes my bug. any chance of a backport?

I'll take care of this bugreport now.

> any chance of a backport?
Would you test this, which means going back to the X.Org packages of openSUSE 10.3 + this patch?

fixed for STABLE now.

xorg-x11-driver-video.changes:
-------------------------------------------------------------------
Mon Nov 12 19:00:52 CET 2007 - sndirsch@suse.de

- xf86-video-intel
  * updated to git commit 10988c5, which fixes Bug #327064

bad news, the 10.3+patch combo does not help. there must have been other fixes in the driver which are necessary in addition. 

however, stable is stable again. (yippie!)

Ok. Closing as fixed for STABLE for now. We can still consider updating the intel driver for openSUSE 10.3 once driver release 2.2 is available. A lot of issues have been fixed since 2.1.1.