Bug 11947

Can you capture the dmesg from after the failure, maybe by ssh'ing into the box before you crash it?

Also, this is filed against console/framebuffers.  Are you running intelfb or vesafb drivers?  Did you notice them as the problem somehow?

I have collected dmesg (at boot) for the two kernels, see dmesg-*.txt file
attached. I have collected a syslog file too, during the lock, by doing a
sysrq-t sysrq-s before rebooting, see syslog-*.txt. It seems that the problem
starts around line 1761:

[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled
pipe 0

but that's only a wild guess. I think I have no vesafb nor intelfb on, I'll attach a lsmod output too

Created attachment 18639 [details]
syslog after the crash

Created attachment 18640 [details]
boot dmesg with 2.6.27.4 kernel

Created attachment 18641 [details]
boot dmesg with 2.6.28-rc3 kernel

Created attachment 18642 [details]
config for 2.6.28-rc3

Created attachment 18643 [details]
lsmd with 2.6.27.4

Sorry, I do no have a lsmod with 2.6.28-rc3 now, so I attached a config (it was made by make oldconfig from the 2.6.27.4 one, modulo some lock debug). 

Have to go now (late in the night here), tomorrow I will try to help some more. 

Hmmm. It seems like bug#10892 could be related... I am booting since then with nosplash, but in this case it didn't help (and it is a slight different issue, I think, it happens only after a VC switch now. But symptoms are very similar). 

Another very similar issue was with bug#10620. 

Ok, so it looks like Xorg is waiting for a vblank event:

Nov  3 19:39:23 rukbat kernel: [  345.123844] Xorg          S f65fdde8     0  5211   5205
Nov  3 19:39:23 rukbat kernel: [  345.123844]  f65fde00 00003046 00000002 f65fdde8 f65fddf0 00000000 f65fdda4 00003046
Nov  3 19:39:23 rukbat kernel: [  345.123844]  00000000 c04223c0 c04bd500 f65fddf0 f65fddec f65fdde8 c04fbc00 00003286
Nov  3 19:39:23 rukbat kernel: [  345.123844]  f6609120 f6609274 00000000 00002bdc 00000000 f65fddc4 c015152e c04fbc00
Nov  3 19:39:23 rukbat kernel: [  345.123844] Call Trace:
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c015152e>] ? trace_hardirqs_on_caller+0x10e/0x160
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c033b029>] ? _spin_unlock_irqrestore+0x39/0x70
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0136c12>] ? __mod_timer+0xc2/0x110
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0338d6f>] schedule_timeout+0x7f/0xe0
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c033b045>] ? _spin_unlock_irqrestore+0x55/0x70
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0136580>] ? process_timeout+0x0/0x10
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0338d6a>] ? schedule_timeout+0x7a/0xe0
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<f84688b6>] drm_wait_vblank+0x186/0x410 [drm]
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c010b6fe>] ? restore_i387_fxsave+0x6e/0x80
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c015152e>] ? trace_hardirqs_on_caller+0x10e/0x160
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c015158b>] ? trace_hardirqs_on+0xb/0x10
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c01245e0>] ? default_wake_function+0x0/0x10
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<f84662b8>] drm_ioctl+0xe8/0x2f0 [drm]
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c010643a>] ? show_interrupts+0x1ea/0x4e0
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<f8468730>] ? drm_wait_vblank+0x0/0x410 [drm]
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c01a4961>] vfs_ioctl+0x71/0x80
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c010643a>] ? show_interrupts+0x1ea/0x4e0
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c01a49ce>] do_vfs_ioctl+0x5e/0x490
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c01039f0>] ? restore_sigcontext+0x100/0x150
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0103bee>] ? sys_sigreturn+0xce/0x170
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0137ced>] ? sys_rt_sigaction+0x6d/0xa0
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c01a4e39>] sys_ioctl+0x39/0x70
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c0103f15>] sysenter_do_call+0x12/0x35
Nov  3 19:39:23 rukbat kernel: [  345.123844]  [<c010643a>] ? show_interrupts+0x1ea/0x4e0

You might try building a kernel from the Intel DRM git tree to see if the problem still happens there:
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git branch drm-intel-next

I think 10892 is probably a separate bug related to mode programming in general.

Hmmm... I will need a bit more git guidance. Now I have cloned Linus' tree and i git pull it. Should I

git clone <your tree>
git checkout drm-intel-next

and compile it (I mean, it's a complete kernel) or should I make some git remote magic? 

Well, tomorrow now. I have really to go...

But hey, reading it up, bug#10620 really seems the same problem.

Right:
  $ git clone <url>
  $ cd drm-intel
  $ git checkout -b drm-intel-next --track origin/drm-intel-next
then build it with your favorite .config.

As for 10620 there could be a relationship, but please try the drm-intel bits; this area has seen many changes & fixes.

Done. No joy.

The behavior is very similar. The only differences are: 

* after a log while from hitting ctrl-alt-f1, this time I can switch back to the 
  VC and shutdown from there
* sysrq-t produces nothing (? I used the same config as before...)

This time the screen is not everytime black; at a point I had a couple of windows drawn but X is still inoperative. 

I'll attach dmesg and syslog of this test. 

Created attachment 18650 [details]
dmesg at boot with 2.6.28-rc3-drm-intel

Created attachment 18651 [details]
syslog during the session with 2.6.28-rc3-drm-intel

Ths one shows the same VBLANK error message...

Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>

I have pretty much the same issue with an GM965 chipset on Ubuntu Intrepid 8.10 with more recent Xorg intel drivers (2.5.0~git20081023).

My report is tracked as bug#11984

I tested -rc3 and -drm-intel tip. Should I test -rc4 or better I wait for some patch to test? I have both trees now, so I can test patches versus -linus or -drm-intel. 

On Tuesday, 11 of November 2008, Romano Giannetti wrote:
> Rafael J. Wysocki wrote:
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=11947
> > Subject             : 2.6.28-rc VC switching with Intel graphics broken
> > Submitter   : Romano Giannetti <romano.giannetti@gmail.com>
> > Date                : 2008-11-03 12:10 (7 days old)
> > Handled-By  : Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> Still here in 2.6.28-rc4. Complete lock switching back from a VC to X.

Is this thing fixed in RC5?

(In reply to comment #23)
> Is this thing fixed in RC5?
> 

Yes this is still happening with RC5, on an apple macbook with intel GM945 graphics.

When switching back to X from a VT, only the cursor on a black screen is shown.

*** Bug 11984 has been marked as a duplicate of this bug. ***

Notify-Also : Bernhard Schmidt <berni@birkenwald.de>

Notify-Also : Johan Bilien <jobi@via.ecp.fr>

More data: it locks in 2.6.28-rc5 too, bu I restricted it to 3D. If I start X, then disable "Visula effect" (no composite, no compiz) then it works ok - I can switch back and forth from the VC. Enabling visual effects again causes the lock. 

Last hour notice: it's not a lock. It's simply 2 minutes of delay. I discovered it because I had to do another thing and X came back automagically. So: it's a 2 minutes delay when switching back from a VC when 3D is on. I have these messages over 3 tries:

(0)rukbat:~% dmesg -s 20000000 | grep i915
[   41.027994] [drm] Initialized i915 1.6.0 20080730 on minor 0
[  162.718798] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
[  281.616778] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
[  425.802808] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

On the other hand, it completely locks on resume from RAM. Sigh.

Experienced same VC switch issue once, on A110L on -rc5, also full machine lockup on resume (not sure whether caused by this or something else).

(In reply to comment #29)
> Last hour notice: it's not a lock. It's simply 2 minutes of delay. I
> discovered
> it because I had to do another thing and X came back automagically. So: it's
> a
> 2 minutes delay when switching back from a VC when 3D is on. I have these
> messages over 3 tries:
> 
> (0)rukbat:~% dmesg -s 20000000 | grep i915
> [   41.027994] [drm] Initialized i915 1.6.0 20080730 on minor 0
> [  162.718798] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank
> count
> for disabled pipe 0
> [  281.616778] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank
> count
> for disabled pipe 0
> [  425.802808] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank
> count
> for disabled pipe 0
> 

I am seeing the same messages in dmesg. My problem seems to be intermittent.I get it while switching VTs or while logging out of KDE 3.5 and even sysrq refuses to work.

I am not using any KDE effects, vesafb or uvesafb. Both vesafb and uvesafb give a repeatable lockup if i915 is loaded and VT switch is done.

Without vesafb/uvesafb, I am not seeing the lockup after resume from RAM. Only intermittent lockup while switching VTs or logging out of KDE.

Changed to video/DRI, because I think it's drm related. Compiling -rc6 now, but I do not think a lot changed in this field.

Still here with us for -rc6. Black screen on VC switch. 

Notify-Also : Andreas Mohr <andi@lisas.de>
Notify-Also : devsk <kernel-bugs.dev1world@spamgourmet.com>

Yup, -rc6 behaviour seems identical to -rc5: Have to wait a random 30 to 45 seconds after switch back to X until blank screen with cursor is gone.
GNOME/Compiz setup with PAT and MTRR cleanup enabled here (MTRR cleanup _does_ help here BTW, only 6 entries allocated instead of overcapacity error!).

dmesg sometimes shows
[   79.971895] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

Xorg.0.log shows:

(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4

^^^ this is logged until the moment we end up in non-X tty...

...then when switching back to X:

(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x00800000 (pgoffset 2048)
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x00c00000 (pgoffset 3072)
(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x01800000 (pgoffset 6144)
(II) intel(0): xf86BindGARTMemory: bind key 3 at 0x01c00000 (pgoffset 7168)
(II) intel(0): xf86BindGARTMemory: bind key 4 at 0x02000000 (pgoffset 8192)
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x0061ffff: compressed frame buffer (6144 kB, 0x000000005f820000 physical
)
(II) intel(0): 0x00620000-0x00620fff: compressed ll buffer (4 kB, 0x000000005fe20000 physical
)
(II) intel(0): 0x00621000-0x0062afff: HW cursors (40 kB, 0x000000005fe21000 phys
ical
)
(II) intel(0): 0x0062b000-0x00632fff: logical 3D context (32 kB)
(II) intel(0): 0x00633000-0x00633fff: overlay registers (4 kB, 0x000000005fe33000 physical
)
(II) intel(0): 0x007bf000:            end of stolen memory
(II) intel(0): 0x00800000-0x00bfffff: front buffer (4096 kB) X tiled
(II) intel(0): 0x00c00000-0x017fffff: exa offscreen (12288 kB)
(II) intel(0): 0x01800000-0x01bfffff: back buffer (4096 kB) X tiled
(II) intel(0): 0x01c00000-0x01ffffff: depth buffer (4096 kB) X tiled
(II) intel(0): 0x02000000-0x03ffffff: classic textures (32768 kB)
(II) intel(0): 0x10000000:            end of aperture
(WW) intel(0): ESR is 0x00000001, instruction error
(WW) intel(0): Existing errors found in hardware state.
(II) intel(0): using SSC reference clock of 96 MHz
(II) intel(0): Selecting standard 18 bit TMDS pixel format.
(II) intel(0): Output configuration:
(II) intel(0):   Pipe A is off
(II) intel(0):   Display plane A is now disabled and connected to pipe A.
(II) intel(0):   Pipe B is on
(II) intel(0):   Display plane B is now enabled and connected to pipe B.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output LVDS is connected to pipe B
(II) intel(0): [drm] dma control initialized, using IRQ 16
(II) Synaptics Touchpad: x-axis range 1472 - 5472
(II) Synaptics Touchpad: y-axis range 1408 - 4448
(--) Synaptics Touchpad touchpad found
(II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472
(II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448
(WW) SynPS/2 Synaptics TouchPad can't grab event device, errno=16
(--) SynPS/2 Synaptics TouchPad touchpad found
(II) AT Translated Set 2 keyboard: Device reopened after 10 attempts.
(II) Video Bus: Device reopened after 10 attempts.



Resume is complete no-go as usual, end up with completely locked-up box, no backlight, no keyboard, nothing.

On Monday, 24 of November 2008, Romano Giannetti wrote:
> 
> Rafael J. Wysocki wrote:
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=11947
> > Subject             : 2.6.28-rc VC switching with Intel graphics broken
> > Submitter   : Romano Giannetti <romano.giannetti@gmail.com>
> > Date                : 2008-11-03 12:10 (20 days old)
> > Handled-By  : Jesse Barnes <jbarnes@virtuousgeek.org>
> > 
> 
> Still with us on -rc6, nasty, reproducible, no clues on what can be.
> 
> VC switch locks or delay the systems minutes, resuming from suspend locks
> hard 
> the machine.
> 
> 2.6.28-rc is unusable here.

This sound a lot like a bug that was fixed by:
http://lists.freedesktop.org/archives/intel-gfx/2008-November/000614.html

I'll ping Eric to make sure the fix makes it upstream quickly.

 That patch does not apply cleanly to 2.6.28-rc6, because in
i915_irq.c::i915_driver_irq_postinstall there is an additional line, namely 

/* Set initial unmasked IRQs to just the selected vblank pipes. */      
        dev_priv->irq_mask_reg = ~0; 

So i applied it manually deleting this line too, I hope I am doing things ok. 
Compiling now.

It works! VC switching is fixed. I will attach the patch I have used on top of
v2.6.28-rc6-7-ged31348.

Tested-by: Romano Giannetti <romano.giannetti@gmail.com>

Will test later and report about resume lock...

Created attachment 19013 [details]
real patch applied on top v2.6.28-rc6-7-ged31348 fixing VC switch

And it fixes resume from ram too! 

Tested-again-by-happy-user: Romano Giannetti <romano.giannetti@gmail.com>

Please push upstream. 

OK, success as well (if partial), on A110L: with Romano's "cooked" patch on -rc6, VC switching fully works, however S2R resume weirdly still fails (complete lockup of box).
I'm suspecting that it's for a different reason, though. Now that the DRM resume issue is fixed, maybe I can properly detect the _other_ reason for the lockup (unload several drivers and retry).
So a thumbs up from me for pushing this mainline, quickly.

OK, resume lockup for me was a different regression after all (Intel microcode module, see bug #12100).
Tried -rc5 again (with microcode module unloaded this time), VC switching was broken there, but DRM resume lockup did NOT occur with this unrepaired version for me! (just to submit this minor/unimportant piece of data).

Patch applied on top of rc6 fixes VC switch for me, good job.

Unfortunately, S2R and S2D still fail, I have a black screen with cursor and sometimes a monitor icon and an blue cross. Everything else seems to work (SSH server up, dmesg and xorg logs silent). Killing X by SSH works, but after relaunching X, VT switching is impossible (black screen or random color pixels, killing X again is the only solution).

I use no microcode module.

It looks like I am not alone: http://lists.freedesktop.org/archives/intel-gfx/2008-November/000648.html

I have a GM965, I use compiz. Please ask me if you want more information.

Strange issues here still after fixed -rc6, after another resume (maybe the third one?): extreme load (up to 4, X.org and compiz and some other X apps taking as much CPU as they can get), everything bloody slow (to be measured in dozens of seconds), then switched to tty1, load settled down and appeared normal, switched back, _VERY_ unresponsive again and trying to switch back to tty1 didn't even work, I got annoyed thus killed the box and rebooted
(would have attached gdb otherwise, maybe remote login would have been a good idea).

Can anyone having this problem carry out bisection to identify the exact commit that caused it to happen?  That would greatly help identify the root cause of the problem.

I have my problem since 2.6.28-rc1. I now use 2.6.28-rc6 patched (the patch totally fixed VT switching *before* S2R or S2D). All the 2.6.27.x releases work for me, with VT switching, S2R and S2D.

Here is exactly what happens:

VT switching works before suspend. After wake up, I have a black screen with unmovable cursor, sometimes a monitor icon under the cursor. Everything else works. I can kill X (-9) from SSH, X restarts. After this, switching to a VT gives me random color pixels, even from gdm without composite. X can be killed again from SSH. Killing X with ctrl+alt+backspace gives me random color pixels during a couple of seconds, then reboot.

I tried to keep logs. dmesg is silent. I thougth that Xorg was silent too, but I have in fact these lines:

[normal start]
[…]
(II) intel(0): EDID vendor "AUO", prod id 33140
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x800"x0.0   71.11  1280 1328 1360 1440  800 803 809 823 -hsync -vsync (49.4 kHz)
(II) intel(0): EDID vendor "AUO", prod id 33140
[suspend and wake up]
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) No APM support in BIOS or kernel
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x0cd40000 (pgoffset 52544)
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x0e000000 (pgoffset 57344)
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x00000fff: power context (4 kB)
(II) intel(0): 0x0077f000:            end of stolen memory
(II) intel(0): 0x0077f000-0x0cd3ffff: DRI memory manager (202500 kB)
(II) intel(0): 0x0cd40000-0x0dffffff: exa offscreen (19200 kB)
(II) intel(0): 0x0e000000-0x0fffffff: classic textures (32768 kB)
(II) intel(0): 0x10000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x0077f000:            start of memory manager
(II) intel(0): 0x0079f000-0x00ddefff: depth buffer (6400 kB) Y tiled
(II) intel(0): 0x00f9f000-0x015defff: back buffer (6400 kB) X tiled
(II) intel(0): 0x01800000-0x01e3ffff: front buffer (6400 kB) X tiled
(II) intel(0): 0x0179f000-0x0179ffff: overlay registers (4 kB)
(II) intel(0): 0x017a0000-0x017b5fff: exa G965 state buffer (88 kB)
(II) intel(0): 0x017c0000-0x017c7fff: logical 3D context (32 kB)
(II) intel(0): 0x017c8000-0x017d1fff: HW cursors (40 kB)
(II) intel(0): 0x0cd40000:            end of memory manager
(WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled
(WW) intel(0): Existing errors found in hardware state.
(II) intel(0): using SSC reference clock of 96 MHz
(II) intel(0): Selecting standard 18 bit TMDS pixel format.
(II) intel(0): Output configuration:
(II) intel(0):   Pipe A is off
(II) intel(0):   Display plane A is now disabled and connected to pipe A.
(II) intel(0):   Pipe B is on
(II) intel(0):   Display plane B is now enabled and connected to pipe B.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output LVDS is connected to pipe B
(II) intel(0):   Output TV is connected to pipe none
(II) intel(0): [drm] mapped front buffer at 0x41800000, handle = 0x18300000
(--) AlpsPS/2 ALPS GlidePoint touchpad found

Note that I always had "Open ACPI failed (/var/run/acpid.socket)", even before 2.6.28.

Do this problems exist in the current Linus' tree?  It contains several important DRM fixes.

Wow, last updates about VT switching and DRM have been added 15 minutes ago… I'll test these fixes during the next days and give news.

Linus' tree now includes the VT switching patch:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=52440211dcdc52c0b757f8b34d122e11b12cdd50

But bad news, I can't switch back from VT to X even *before* suspending. There are lots of drm changes and I don't really know where to find the source of the problem.

Can anybody try Linus' tree to confirm that our original VT switching bug is not fixed even if the patch is applied?

I'm now trying to apply some of the new DRM patches to the rc6…

I tried it. For me v2.6.28-rc6-184-gd9d060a is working ok: VC switching before and after S2R, and S2R itself are ok. I didn't try S2D (since ages). 

Guillaume, did you test the Linus' tree, actually?

current git head works fine for me, both for VC switching and S2R

I confirm that VT switching, for me:

- 2.6.28-rc6 does not work
- 2.6.28-rc6 + "patch" works
- 2.6.28-rc7 does not work

By "patch", I mean the patch posted here, committed to the Linus' tree with label "drm: move drm vblank initialization/cleanup to driver load/unload".

The code causing my (new?) bug is in the commit "drm/i915: Manage PIPESTAT to control vblank interrupts instead of IMR". rc6 + "drm vblank init patch" works. rc6 + "drm vblank init patch" + "pipestat patch" does not work.

Sorry :)

The lockup has become so annoying and for me happens mostly when logging out of KDE, that I have decided to just go without i915 for now.

Well, well, well… Quite good news!

2.6.28-rc7 does not work for me, X "freezes" after a VT switch (including suspend). But here is a little patch transforming the freeze to a hang up. I have to wait about 1 minute (actually between 30 and 100 seconds, random) with a black screen and movable cursor, then the screen is redrawn and everything works fine.

S2R works the same, I suppose that S2D too. I can switch again and again, as long as I wait 1mn each time.

The lines added in the patch had been removed between rc6 and rc7.

I don't know why it works, don't ask me (I'm just damned lucky). This is not a solution, just an ugly workaround. I'd be glad if an intel-guru-like-guy found a real solution, I can give anything to help (dmesg, Xorg logs, credit card number, hardware config, whatever).

Created attachment 19135 [details]
2.6.28-rc7 freeze2hang patch

Last two things:

- S2R works but S2D gives me xorg freeze with monitor-and-blue-cross icon or kernel panic.

- @Romano: you related a 2 minutes delay in comment #29, that sounds like my situation now. Do you still have this delay?

I need to sleep a little bit…

For me it works ok with v2.6.28-rc7-105-gfeaf384 (note that I skipped the nasty watchdog bug that creeped into -rc7).

@Guillaume: no, no delay now, since the vblank patch. 

I'm tired… 2.6.28-rc7 works very well with metacity (2.24, composite) instead of compiz. VT switch and S2R are OK. I'm not sure that my bug is a kernel bug. I'll test compiz 0.8 later, I keep metacity now.

Thanks a lot for your help. We may close that bug, resolved with the vblank patch in rc7.

Hi,

I think that, on one hand, the original problem is solved for me; on the other hand, if Guillaume has a configuration that works on 2.6.27 and fails now, it's a regression in y opinion. So... I think Jesse and Rafael will decide on it, but if we close this bug, we should open another one for x+compiz+2.6.28. 

Just my 2 cents. 

I'm going to close it now, and Guillaume, if the problem you're observing with compiz turns out to be a kernel issue, please open a separate bug entry for it.