[i945GM] X freezes typing quickly in Kmail when desktop effects are enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xf86-video-intel |
Fix Released
|
High
|
|||
xserver-xorg-video-intel (Ubuntu) |
Fix Released
|
High
|
Bryce Harrington | ||
Jaunty |
Won't Fix
|
High
|
Unassigned |
Bug Description
Binary package hint: xserver-
Since I ugpraded to Jaunty Beta, I experience common "lock-up".
When the display is "locked-up", the mouse pointer moves on the screen, but the pointer doesn't change, the keyboard doesn't do anything, and the display doesn't get any update.
I can SSH in the box and kill -9 the Xorg server. After that either nothing happens, or the screen becomes black. In all cases, the display is still non-functional. A shutdown -r usually doesn't complete either and I have to power-cycle the laptop.
This happen in various circumstances, but the most "reliable" way to trigger it is by creating a new email in Kmail and typing in the subject field very fast. It also happened in various other situations: like opening a new tab in firefox, starting up gvim, or just on my first log-in after the upgrade.
ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: xserver-
ProcEnviron:
LANGUAGE=
PATH=(custom, user)
LANG=fr_CA.UTF-8
LC_MESSAGES=
SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #38-Ubuntu SMP Fri Mar 27 09:00:52 UTC 2009
SourcePackage: xserver-
Uname: Linux 2.6.28-11-generic i686
[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03)
Subsystem: Dell Device [1028:01d8]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
Subsystem: Dell Device [1028:01d8]
Changed in xserver-xorg-video-intel (Ubuntu): | |
status: | New → Confirmed |
description: | updated |
Changed in xserver-xorg-video-intel: | |
status: | Unknown → Confirmed |
tags: | added: regression-potential |
Changed in xserver-xorg-video-intel (Ubuntu Jaunty): | |
assignee: | canonical-desktop-team → bryceharrington |
tags: | added: freeze |
tags: | added: intel |
tags: |
added: jaunty regression-release removed: regression-potential |
Changed in xserver-xorg-video-intel (Ubuntu Jaunty): | |
assignee: | Bryce Harrington (bryceharrington) → nobody |
tags: | added: compiz |
Changed in xserver-xorg-video-intel: | |
status: | Confirmed → In Progress |
Changed in xserver-xorg-video-intel: | |
status: | In Progress → Fix Released |
Changed in xserver-xorg-video-intel: | |
importance: | Unknown → High |
Changed in xserver-xorg-video-intel: | |
importance: | High → Unknown |
Changed in xserver-xorg-video-intel: | |
importance: | Unknown → High |
Hmm, nothing out of the ordinary in Xorg.0.log, although I notice some differences between the log and log.old in input device setup messages. Perhaps you just had different input devices attached in each case?
What would help in analyzing this bug is to have an error message of some sort. Not all lock-up bugs will cause an error message to be printed, but if one is, it'll help identify the problem more quickly.
Can you look in the following places for an error message, after reproducing the bug:
* /var/log/gdm/*
* /var/log/syslog
* /var/log/kern.log
* /var/log/messages
* /var/log/Xorg.0.log or Xorg.0.log.old
* dmesg
Look for some unusual message appearing at the same time that you first noticed the lock-up.