Bug #381493 “i945 (dell d430) karmic randomly stops updating dis...” : Bugs : xserver-xorg-input-evdev package : Ubuntu

Revision history for this message

Jordan Bain (jbain-deactivatedaccount) wrote on 2009-05-28:

#1

This happens to me in Arch Linux as well, so I think it's an X11 bug. Can anyone else confirm this? Maybe try a ctrl + alt + backspace?

affects:	ubuntu → xorg (Ubuntu)
Changed in xorg (Ubuntu):
status:	New → Incomplete

Revision history for this message

Robert Collins (lifeless) wrote on 2009-05-31:

#2

no effect.
Its not a hard lockup - I have confirmed that I can ssh in.

end of dmesg(nothing seems relevant as its all old):
[ 402.099827] [drm] Initialized i915 1.6.0 20080730 on minor 0
[ 402.104830] [drm:i915_getparam] *ERROR* Unknown parameter 6
[ 403.827489] ppdev: user-space parallel port driver
[ 404.573516] [drm:i915_getparam] *ERROR* Unknown parameter 6

uptime
09:20:56 up 3 days, 1:07, 5 users, load average: 0.15, 0.10, 0.08

messages:
Jun 1 08:43:53 lifeless-64 -- MARK --
Jun 1 09:03:53 lifeless-64 -- MARK --

daemon.log
Jun 1 08:59:48 lifeless-64 last message repeated 2 times
Jun 1 09:01:41 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS
Jun 1 09:01:48 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS
Jun 1 09:03:48 lifeless-64 last message repeated 2 times
Jun 1 09:05:41 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS
Jun 1 09:05:48 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS
Jun 1 09:07:48 lifeless-64 last message repeated 2 times
Jun 1 09:09:41 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS
Jun 1 09:09:48 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS

Xorg.0.log end
(**) PS/2 Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE)
(**) PS/2 Mouse: (accel) keeping acceleration scheme 1
(**) PS/2 Mouse: (accel) filter chain progression: 2.00
(**) PS/2 Mouse: (accel) filter stage 0: 20.00 ms
(**) PS/2 Mouse: (accel) set acceleration profile 0

higher up in Xorg.0.log it has
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(WW) intel(0): drmDropMaster failed: Unknown error 18446744073709551615
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(WW) intel(0): drmDropMaster failed: Unknown error 18446744073709551615
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x0dbf4000 (pgoffset 56308)

which may or may not be relevant.

no effect.
Its not a hard lockup - I have confirmed that I can ssh in.

end of dmesg(nothing seems relevant as its all old):
[  402.099827] [drm] Initialized i915 1.6.0 20080730 on minor 0
[  402.104830] [drm:i915_getparam] *ERROR* Unknown parameter 6
[  403.827489] ppdev: user-space parallel port driver
[  404.573516] [drm:i915_getparam] *ERROR* Unknown parameter 6

uptime
 09:20:56 up 3 days,  1:07,  5 users,  load average: 0.15, 0.10, 0.08

messages:
Jun  1 08:43:53 lifeless-64 -- MARK --
Jun  1 09:03:53 lifeless-64 -- MARK --

daemon.log
Jun  1 08:59:48 lifeless-64 last message repeated 2 times
Jun  1 09:01:41 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS 
Jun  1 09:01:48 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS 
Jun  1 09:03:48 lifeless-64 last message repeated 2 times
Jun  1 09:05:41 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS 
Jun  1 09:05:48 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS 
Jun  1 09:07:48 lifeless-64 last message repeated 2 times
Jun  1 09:09:41 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS 
Jun  1 09:09:48 lifeless-64 wpa_supplicant[3481]: CTRL-EVENT-SCAN-RESULTS

Xorg.0.log end
(**) PS/2 Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE)
(**) PS/2 Mouse: (accel) keeping acceleration scheme 1
(**) PS/2 Mouse: (accel) filter chain progression: 2.00
(**) PS/2 Mouse: (accel) filter stage 0: 20.00 ms
(**) PS/2 Mouse: (accel) set acceleration profile 0

higher up in Xorg.0.log it has
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(WW) intel(0): drmDropMaster failed: Unknown error 18446744073709551615
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(WW) intel(0): drmDropMaster failed: Unknown error 18446744073709551615
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x0dbf4000 (pgoffset 56308)

which may or may not be relevant.

summary:	- i945 (dell d430) karmic random hard freeze/lockup + i945 (dell d430) karmic randomly stops updating display and responding + to keyboard/mouse
description:	updated

Robert Collins (lifeless) on 2009-06-01

Changed in xorg (Ubuntu):
status:	Incomplete → New

Bryce Harrington (bryce) on 2009-06-02

affects:

xorg (Ubuntu) → xserver-xorg-input-evdev (Ubuntu)

Revision history for this message

Robert Collins (lifeless) wrote on 2009-06-03: Re: [Bug 381493] Re: i945 (dell d430) karmic randomly stops updating display and responding to keyboard/mouse

#3

On Tue, 2009-06-02 at 14:02 +0000, Bryce Harrington wrote:
> ** Package changed: xorg (Ubuntu) => xserver-xorg-input-evdev (Ubuntu)

I should note that the screen freezes as well - my sysmon panels stop
updating. How does this fit with the input theory?

-Rob

Revision history for this message

Marti (intgr) wrote on 2009-06-25:

#4

Xorg log file from the crash Edit (53.4 KiB, text/plain)

Download full text (6.7 KiB)

This problem also occurs on my Dell D630 laptop, running Jaunty (9.04), packaged kernel 2.6.28-13-generic with all updates installed (as of 2009-06-25). Sometimes it happens when I'm actively working; sometimes when the computer is idle.

The symptoms seem somewhat analogous to Robert Collins, but differ in a couple of aspects (killing X with SIGTERM works).
I also tried some weird things on a locked desktop that I could think of (like the surprising response to launching xev).

X doesn't react to:
* Keyboard input, mouse clicks, laptop power button, volume buttons, etc.
* Killing application windows (like GNOME panel, individual tray processes) have no visible effect
* Ctrl-Alt-Backspace
* Even though the mouse cursor moves, mouseover effects don't work.

X reacts to:
* Moving the mouse also moves the cursor on screen
* Kernel and non-X-related applications work (ssh, daemons, hotplug)
* (Re-)attaching a USB mouse can be seen in Xorg.0.log (using evdev) -- after attaching, this mouse also moves the cursor
* 'killall -9 X' shows "black and blue noise", and after a couple of seconds brings me back to GDM. Everything works fine after I log in again
* After killing the gnome-panel in a crashed Xorg, launching 'DISPLAY=:0 xev' from ssh makes the gnome-panel disappear (whoa, X isn't dead -- it suddenly updates the screen!). However, xev itself doesn't appear.
* Ctrl+Alt+Shift+F1 successfully switches to the text mode. After switching back (Alt+F7), all windows are blank (though windows are colored differently from the desktop), and icons on the desktop are no longer visible. The gradient background, however, is still visible.

Possible clues:
* I'm using the suspend feature quite often
* The laptop has an Intel X3100 (GM965) graphics chip (like Robert Collins); "eye candy" is turned off.
* I'm often connecting and disconnecting a second DVI screen in a dual-head setup, using xrandr to adjust X desktop.

dmesg and /var/log/messages contain no clues.

Xorg.0.log has some interesting lines (but no timestamps, GRR!):
% egrep EE\|WW /var/log/Xorg.0.log
(II) Loading extension MIT-SCREEN-SAVER
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd0000009
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x70024 (PIPEASTAT) changed from 0x00000000 to 0x00000207
(WW) intel(0): PIPEASTAT before: status:
(WW) intel(0): PIPEASTAT after: status: VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
[ ... above line repeats 37 times ... ]
(EE) Logitech USB-PS/2 Optical Mouse: Read error: No such device
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.
(EE) Logitech USB Optical Mouse: Read error: No such device

Mouse read error...

This problem also occurs on my Dell D630 laptop, running Jaunty (9.04), packaged kernel 2.6.28-13-generic with all updates installed (as of 2009-06-25). Sometimes it happens when I'm actively working; sometimes when the computer is idle.

The symptoms seem somewhat analogous to Robert Collins, but differ in a couple of aspects (killing X with SIGTERM works).
I also tried some weird things on a locked desktop that I could think of (like the surprising response to launching xev).

X doesn't react to:
* Keyboard input, mouse clicks, laptop power button, volume buttons, etc.
* Killing application windows (like GNOME panel, individual tray processes) have no visible effect
* Ctrl-Alt-Backspace
* Even though the mouse cursor moves, mouseover effects don't work.

X reacts to:
* Moving the mouse also moves the cursor on screen
* Kernel and non-X-related applications work (ssh, daemons, hotplug)
* (Re-)attaching a USB mouse can be seen in Xorg.0.log (using evdev) -- after attaching, this mouse also moves the cursor
* 'killall -9 X' shows "black and blue noise", and after a couple of seconds brings me back to GDM. Everything works fine after I log in again
* After killing the gnome-panel in a crashed Xorg, launching 'DISPLAY=:0 xev' from ssh makes the gnome-panel disappear (whoa, X isn't dead -- it suddenly updates the screen!). However, xev itself doesn't appear.
* Ctrl+Alt+Shift+F1 successfully switches to the text mode. After switching back (Alt+F7), all windows are blank (though windows are colored differently from the desktop), and icons on the desktop are no longer visible. The gradient background, however, is still visible.

Possible clues:
* I'm using the suspend feature quite often
* The laptop has an Intel X3100 (GM965) graphics chip (like Robert Collins); "eye candy" is turned off.
* I'm often connecting and disconnecting a second DVI screen in a dual-head setup, using xrandr to adjust X desktop.

dmesg and /var/log/messages contain no clues.

Xorg.0.log has some interesting lines (but no timestamps, GRR!):
% egrep EE\|WW /var/log/Xorg.0.log
(II) Loading extension MIT-SCREEN-SAVER
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd0000009
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x70024 (PIPEASTAT) changed from 0x00000000 to 0x00000207
(WW) intel(0): PIPEASTAT before: status:
(WW) intel(0): PIPEASTAT after: status: VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
[ ... above line repeats 37 times ... ]
(EE) Logitech USB-PS/2 Optical Mouse: Read error: No such device
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.
(EE) Logitech USB Optical Mouse: Read error: No such device

Mouse read errors are me detaching the USB mouse.

"ESR is 0x00000001" and "Existing errors found in hardware state." are a result of switching between text mode and Xorg.

SSH'ing in and stracing the X process reveals that it's spinning in the select() loop with a 33ms timeout (generating 30 CPU wakeups per second in powertop -- it doesn't do that usually!). Input events make the select() return and X successfully read()s the events from fd 27.

Here's me pressing "a" on the keyboard:

select(256, [1 3 5 12 13 47], NULL, NULL, {0, 33000}) = ? ERESTARTNOHAND (To be restarted)
--- SIGIO (I/O possible) @ 0 (0) ---
select(28, [14 15 16 17 18 19 27], NULL, NULL, {0, 0}) = 1 (in [15], left {0, 0})
rt_sigprocmask(SIG_BLOCK, [IO], [IO], 8) = 0
select(1024, [15], NULL, NULL, {0, 0})  = 1 (in [15], left {0, 0})
read(15, "a\273CJ\0\0\0\0\341O\2\0\0\0\0\0\4\0\4\0\36\0\0\0"..., 24) = 24
select(1024, [15], NULL, NULL, {0, 0})  = 1 (in [15], left {0, 0})
read(15, "a\273CJ\0\0\0\0\367O\2\0\0\0\0\0\1\0\36\0\1\0\0\0"..., 24) = 24
select(1024, [15], NULL, NULL, {0, 0})  = 1 (in [15], left {0, 0})
read(15, "a\273CJ\0\0\0\0\373O\2\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 24) = 24
select(1024, [15], NULL, NULL, {0, 0})  = 0 (Timeout)
rt_sigreturn(0x1)                       = -1 EINTR (Interrupted system call)
poll([{fd=12, events=POLLIN}], 1, 0)    = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(11, 0x6458, 0)                    = 0
select(256, [1 3 5 12 13 47], NULL, NULL, {0, 11000}) = 1 (in [5], left {0, 10967})
ioctl(5, TCFLSH, 0x2)                   = 0
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(11, 0x6458, 0)                    = 0
select(256, [1 3 5 12 13 47], NULL, NULL, {0, 10000}) = 0 (Timeout)

Mouse moves and also mouse *CLICKS* (!?) are written to fd 28 after being read; here's a mouse click:

select(256, [1 3 5 12 13 47], NULL, NULL, {0, 33000}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(11, 0x6458, 0)                    = 0
--- SIGIO (I/O possible) @ 0 (0) ---
select(28, [14 15 16 17 18 19 27], NULL, NULL, {0, 0}) = 1 (in [14], left {0, 0})
rt_sigprocmask(SIG_BLOCK, [IO], [IO], 8) = 0
select(1024, [14], NULL, NULL, {0, 0})  = 1 (in [14], left {0, 0})
read(14, "T\274CJ\0\0\0\0\332\376\2\0\0\0\0\0\1\0\20\1\0\0\0\0T\274CJ\0\0\0\0\342"..., 64) = 48
select(1024, [14], NULL, NULL, {0, 0})  = 0 (Timeout)
rt_sigreturn(0x1)                       = 0
select(256, [1 3 5 12 13 47], NULL, NULL, {0, 28000}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
writev(28, [{"\4\1\260h\206/!\4\336\0\0\0\246\0 \1\0\0\0\0\215\3\3\1\215\3\3\1\f \1\0"..., 32}], 1) = 32
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(11, 0x6458, 0)                    = 0
select(256, [1 3 5 12 13 47], NULL, NULL, {0, 0}) = 0 (Timeout)
setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [IO], [], 8)  = 0
rt_sigprocmask(SIG_UNBLOCK, [IO], NULL, 8) = 0
writev(28, [{"\5\1\260h\267/!\4\336\0\0\0\246\0 \1\0\0\0\0\215\3\3\1\215\3\3\1\f!\1\0"..., 32}], 1) = 32
setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
ioctl(11, 0x6458, 0)                    = 0
select(256, [1 3 5 12 13 47], NULL, NULL, {0, 16000}) = 0 (Timeout)

Revision history for this message

Marti (intgr) wrote on 2009-06-25:

#5

Two corrections to the above bug report:
* Original reporter has i945, I have i965
* X actually *doesn't* die with SIGTERM for me either.

Bryce Harrington (bryce) on 2009-09-02

tags:

added: karmic

Revision history for this message

S. Christian Collins (s-chriscollins) wrote on 2009-10-28:

#6

I am also experiencing this bug. Here are my specs:

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Ubuntu 9.10 RC 1 w/ all updates as of 10/27/09

Revision history for this message

S. Christian Collins (s-chriscollins) wrote on 2009-10-28:

#7

I'm starting to suspect that the lockups might be happening sometime after resuming from suspend mode. I'm going to not use suspend on my system for a while to see if the freezes go away.

Revision history for this message

S. Christian Collins (s-chriscollins) wrote on 2009-11-23:

#8

Okay, so the freezes are definitely related to suspend mode. If I don't suspend my laptop, it never freezes, but I am almost guaranteed a freeze sometime after resuming from suspend. Unfortunately, the freezes still happen with the 2.9.1 Intel drivers.

Revision history for this message

Bryce Harrington (bryce) wrote on 2010-03-09:

#9

(Putting 'keyboard/mouse' in the title triggered a script to move this to -evdev, but really it is probably a bug in the Intel kernel drm)

Robert, I've deployed some new code to catch when freezes happen and capture certain debugging data which is necessary for troubleshooting these kinds of issues. Because this bug report has lacked this information we've not been able to move forward with it. I don't know if you're still having this problem on Lucid but if so hopefully the new debugging tools will catch it and help you in filing a new report. If not, please see http://wiki.ubuntu.com/X/Troubleshooting/XFreeze for directions on collecting this information manually.

To everyone else on this bug report, please understand that X freezes can be caused by a wide variety of different underlying problems, and there is no guarantee that the freeze you're seeing is the same as the one Robert reported, especially where you differ even slightly in hardware or steps to reproduce. Thus, if you want your problem investigated it is wisest to make your own report, because we generally only examine one person's freeze per bug report.

Changed in xserver-xorg-input-evdev (Ubuntu):
status:	New → Invalid

Revision history for this message

Robert Collins (lifeless) wrote on 2010-03-09:

#10

On Tue, 2010-03-09 at 00:59 +0000, Bryce Harrington wrote:
> (Putting 'keyboard/mouse' in the title triggered a script to move this
> to -evdev, but really it is probably a bug in the Intel kernel drm)
>
> Robert, I've deployed some new code to catch when freezes happen and
> ...directions on collecting this information manually.

Lucid seems to have sorted the hangs out (but given me a while new set
of 'toys' to play with :). I suspect this is a
fixed-release-but-who-knows-why situation.

-Rob

Bryce Harrington (bryce) on 2010-03-09

Changed in xserver-xorg-input-evdev (Ubuntu):
status:	Invalid → Fix Released

Ubuntu
xserver-xorg-input-evdev package

i945 (dell d430) karmic randomly stops updating display and responding to keyboard/mouse

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntuxserver-xorg-input-evdev package

i945 (dell d430) karmic randomly stops updating display and responding to keyboard/mouse

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
xserver-xorg-input-evdev package