[REGRESSION] i915 VT switch with AIGLX causes X lock up

[REGRESSION] i915 VT switch with AIGLX causes X lock up

[Sitsofe Wheeler]

Hi,

With 2.6.29rc5 and xorg-server 2:1.4.1~git20080131-1ubuntu9.2 switching
to a VT after starting compiz causes X to nearly lock up.

Steps to reproduce:
1. Start X
2. Run compiz
3. Switch to VT1 via ctrl-alt-f1
4. Switch back to X via ctrl-alt-f7

The result is that X will remain displaying a black screen from then on
(the mouse cursor is visible and still moves). Switching to a VT after
this locks up the keyboard. When compiz is not running this bug does not
occur. I am not using kernel mode setting and booting with nomodesetting
made no difference. This problem was not present in 2.6.28. The problem
is reproducible every time.

Graphics card is an i915 in an EeePC 900:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)

This might be http://bugzilla.kernel.org/show_bug.cgi?id=12264 but I
can't reopen that bug and this bug might turn out to be different. Might
also be related to
http://marc.info/?l=linux-kernel&m=123499984611624&w=2 .

-- 
Sitsofe | http://sucs.org/~sits/

Re: [REGRESSION] i915 VT switch with AIGLX causes X lock up

[Sitsofe Wheeler]

On Sat, Feb 21, 2009 at 03:38:22PM +0000, Sitsofe Wheeler wrote:
> With 2.6.29rc5 and xorg-server 2:1.4.1~git20080131-1ubuntu9.2 switching
> to a VT after starting compiz causes X to nearly lock up.
> 
> Steps to reproduce:
> 1. Start X
> 2. Run compiz
> 3. Switch to VT1 via ctrl-alt-f1
> 4. Switch back to X via ctrl-alt-f7
> 
> The result is that X will remain displaying a black screen from then on
> (the mouse cursor is visible and still moves). Switching to a VT after
> this locks up the keyboard. When compiz is not running this bug does not
> occur. I am not using kernel mode setting and booting with nomodesetting
> made no difference. This problem was not present in 2.6.28. The problem
> is reproducible every time.
> 
> Graphics card is an i915 in an EeePC 900:
> 
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)
> 
> This might be http://bugzilla.kernel.org/show_bug.cgi?id=12264 but I
> can't reopen that bug and this bug might turn out to be different. Might
> also be related to
> http://marc.info/?l=linux-kernel&m=123499984611624&w=2 .

Still here in 2.6.29-rc6.

-- 
Sitsofe | http://sucs.org/~sits/

Re: [REGRESSION] i915 VT switch with AIGLX causes X lock up

[Jesse Barnes]

On Monday, February 23, 2009 2:32:26 pm Sitsofe Wheeler wrote:
> On Sat, Feb 21, 2009 at 03:38:22PM +0000, Sitsofe Wheeler wrote:
> > With 2.6.29rc5 and xorg-server 2:1.4.1~git20080131-1ubuntu9.2 switching
> > to a VT after starting compiz causes X to nearly lock up.
> >
> > Steps to reproduce:
> > 1. Start X
> > 2. Run compiz
> > 3. Switch to VT1 via ctrl-alt-f1
> > 4. Switch back to X via ctrl-alt-f7
> >
> > The result is that X will remain displaying a black screen from then on
> > (the mouse cursor is visible and still moves). Switching to a VT after
> > this locks up the keyboard. When compiz is not running this bug does not
> > occur. I am not using kernel mode setting and booting with nomodesetting
> > made no difference. This problem was not present in 2.6.28. The problem
> > is reproducible every time.
> >
> > Graphics card is an i915 in an EeePC 900:
> >
> > 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> > 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)
> >
> > This might be http://bugzilla.kernel.org/show_bug.cgi?id=12264 but I
> > can't reopen that bug and this bug might turn out to be different. Might
> > also be related to
> > http://marc.info/?l=linux-kernel&m=123499984611624&w=2 .
>
> Still here in 2.6.29-rc6.

Can you get a backtrace of the hung process, maybe by logging in from another 
machine and using gdb on the Xorg process?
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [REGRESSION] i915 VT switch with AIGLX causes X lock up

[Sitsofe Wheeler]

On Tue, Feb 24, 2009 at 08:44:09AM -0800, Jesse Barnes wrote:
> Can you get a backtrace of the hung process, maybe by logging in from another 
> machine and using gdb on the Xorg process?

(Done via sleep 30s; gdb.sh where gdb.sh contained the following:
gdb -batch-silent \
-ex 'set logging overwrite on' \
-ex "set logging file /tmp/gdb.log" \
-ex 'set logging on' \
-ex 'handle SIG33 pass nostop noprint' \
-ex 'set pagination 0' \
-ex 'run' \
-ex 'backtrace full' \
-ex 'info registers' \
-ex 'thread apply all backtrace' \
-ex 'quit' \
-p `pidof X` < /dev/null
< /dev/null

Xorg never seems happy after the above finishes and always wedged itself
after the script ran)

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb7ccea30 (LWP 2972)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGUSR1, User defined signal 1.
[Switching to Thread 0xb7ccea30 (LWP 2972)]
0xb7fe8424 in __kernel_vsyscall ()
#0  0xb7fe8424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7e3984d in select () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2  0x081b22e5 in WaitForSomething ()
No symbol table info available.
#3  0x0808d69d in Dispatch ()
No symbol table info available.
#4  0x0807471b in main ()
No symbol table info available.
eax            0xfffffdfe	-514
ecx            0x820a240	136356416
edx            0x0	0
ebx            0x100	256
esp            0xbf902cc0	0xbf902cc0
ebp            0xbf902f58	0xbf902f58
esi            0x0	0
edi            0xbf902f40	-1081069760
eip            0xb7fe8424	0xb7fe8424 <__kernel_vsyscall+16>
eflags         0x3246	[ PF ZF IF #12 #13 ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

Thread 1 (Thread 0xb7ccea30 (LWP 2972)):
#0  0xb7fe8424 in __kernel_vsyscall ()
#1  0xb7e3984d in select () from /lib/tls/i686/cmov/libc.so.6
#2  0x081b22e5 in WaitForSomething ()
#3  0x0808d69d in Dispatch ()
#4  0x0807471b in main ()
The program is running.  Exit anyway? (y or n) [answered Y; input not from terminal]

-- 
Sitsofe | http://sucs.org/~sits/

Re: [REGRESSION,BISECTED] i915 VT switch with AIGLX causes X lock up

[Sitsofe Wheeler]

The problem is still here in 2.6.29-rc7. I got around to bisecting this
and here's the commit that was fingered:

commit 14d200c5e5bd19219d930bbb9a5a22758c8f5bec
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Feb 6 13:04:49 2009 -0800

    drm/i915: capture last_vblank count at IRQ uninstall time too
    
    In dc1336ff4fe08ae7cfe8301bfd7f0b2cfd31d20a (set vblank enable flag correctly
    across IRQ uninstall), we made sure drivers that uninstall their interrupt
    handler set the vblank enabled flag correctly, so that when interrupts are
    re-enabled, vblank interrupts & counts work as expected.  However I missed the
    last_vblank field:  it needs to be updated as well, otherwise, at the next
    drm_update_vblank_count we'll end up comparing a current count to a stale
    one (the last one captured by the disable function), which may trigger the
    wraparound handling, leading to a jumpy counter and hangs in drm_wait_vblank.
    
    The jumpy counter can prevent the DRM_WAIT_ON from returning success if the
    difference between the current count and the requested count is greater than
    2^23, leading to timeouts or hangs, if the ioctl is restarted in a loop (as
    is the case in libdrm < 2.4.4).
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Acked-by: Michel Dänzer <michel@daenzer.net>
    Tested-by: Timo Aaltonen <tjaalton@cc.hut.fi>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

Reverting the above made the problem go away. Here's the bisect log:

# bad: [d2f8d7ee1a9b4650b4e43325b321801264f7c37a] Linux 2.6.29-rc5
# good: [832fb4a01ca27ded735421de2b090f03e20039fc] Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect start 'v2.6.29-rc5' '832fb4a01ca27ded735421de2b090f03e20039fc'
# good: [ac048e1734699dd98f4bdf4daf2b9592d4a4d38e] i915: fix unneeded locking in i915 LVDS get modes code.
git bisect good ac048e1734699dd98f4bdf4daf2b9592d4a4d38e
# good: [725e30ad6601d7fe443d9215d6331758a9d7e0c8] drm/i915: Skip SDVO/HDMI init when the chipset tells us it's not present.
git bisect good 725e30ad6601d7fe443d9215d6331758a9d7e0c8
# bad: [d2f59357700487a8b944f4f7777d1e97cf5ea2ed] drm/i915: select framebuffer support automatically
git bisect bad d2f59357700487a8b944f4f7777d1e97cf5ea2ed
# good: [e2f0ba97d60e59fe5c6237851933a9c38a8f9a24] drm/i915: sync SDVO code with stable userland modesetting driver
git bisect good e2f0ba97d60e59fe5c6237851933a9c38a8f9a24
# good: [7d8d58b23fd01e60ed44d8d8c10b2df86e638faa] drm/i915: Unlock mutex on i915_gem_fault() error path
git bisect good 7d8d58b23fd01e60ed44d8d8c10b2df86e638faa
# bad: [9880b7a527ffbb52f65c2de0a8d4eea86e24775e] drm/i915: add get_vblank_counter function for GM45
git bisect bad 9880b7a527ffbb52f65c2de0a8d4eea86e24775e
# bad: [14d200c5e5bd19219d930bbb9a5a22758c8f5bec] drm/i915: capture last_vblank count at IRQ uninstall time too
git bisect bad 14d200c5e5bd19219d930bbb9a5a22758c8f5bec

-- 
Sitsofe | http://sucs.org/~sits/