Latest working kernel version:220.127.116.11
Earliest failing kernel version:2.6.28
Hardware Environment: x86
Software Environment: GNU/Linux
Problem Description: After updating to GEM through portage while running 18.104.22.168, laptop with i830 video chip has video distortion with KDE-3.5.10. Machine also locks coming out of KDE. The machine still works as far as the network is concerned, ie ssh and nfs, but will not respond to mouse or keyboard. Pressing the power button trips acpid, which shuts off the machine.
Steps to reproduce: Boot with 22.214.171.124 kernel. Machine shows distortion in KDE-3.5.10, and locks coming out of it.
The machine in question originally would not start KDE if it was running a 2.6.28 kernel. After GEM became available, upgrading to it allowed a machine with an io915 video chip to work with 126.96.36.199. While the machine in question will start a KDE session, the video is extremely distorted (pictures to follow). The video locks up coming out of KDE. Information on machine to follow.
gen_tosh ~ # lspci
00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 03)
00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 03)
00:02.1 Display controller: Intel Corporation 82830 CGC [Chipset Graphics Controller]
00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB Controller #3 (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 41)
00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801CA/CAM AC'97 Modem Controller (rev 01)
02:04.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller
02:04.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller
07:00.0 Ethernet controller: ADMtek 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 11)
Created attachment 20110 [details]
/var/log/dmesg with 188.8.131.52 kernel
Created attachment 20111 [details]
/var/log/Xorg.0.log while running 184.108.40.206
Reassigned to DRI, marked as a regression.
Created attachment 20112 [details]
/var/log/dmesg with 220.127.116.11 kernel
Created attachment 20113 [details]
/var/log/Xorg.0.log while running 18.104.22.168
Created attachment 20114 [details]
.config file for 22.214.171.124
Created attachment 20115 [details]
.config file for 126.96.36.199
Created attachment 20116 [details]
This is how the desktop looks when things are right.
This is how the desktop looks when things are right.
Created attachment 20117 [details]
This is how the desktop looks with 188.8.131.52, note lower task bar
Created attachment 20118 [details]
This is how the desktop looks with 184.108.40.206, note side bar
Created attachment 20119 [details]
This is how the desktop looks with 220.127.116.11, note both bars and conky
Just to make absolutely clear, without GEM, the machine in question will not start X. With GEM, I get the problem described here. I have another machine that, once upgraded to GEM, now runs 18.104.22.168 properly, but would not beforehand.
Any other info needed? Just ask.
(In reply to comment #4)
> Reassigned to DRI, marked as a regression.
Wow, that was fast. Thanks.
Got similar errors with .28 here and the patches for .29-rc1 or -rc2 fixed them.
I recently grabbed 2.6.29-rc3-zen1, and while I was able to get X to start, the initial KDE-3.5.x splash screen is all messed up.
After that, I may or may not be able to exit X. If I dare to try to go for a second X run, X will start, but the WM (either KDE-3.5.10 or XFCE-4.4) will not start. The mouse moves, but even Skinny Elephants can't get it back.
I can still access the machine via ssh and nfs, and I can shut it down with one press of the power button...thank the goddess for acpid. I guess you could say it's a step ahead, but I'd prefer something that can come out of and into X as I choose.
The bug remains with .29 rc kernels. So, yes, this is still an active bug.
So is there any known working situation? What do you mean by "updating to GEM"?
(In reply to comment #19)
> So is there any known working situation? What do you mean by "updating to
Moving to mesa-7.2, and libdrm-2.4.5, which contain code for GEM. In other words, where it used to say "Failed to initialize TTM. Falling back to classic," it then said "Failed to intitialize GEM. Falling back to classic."
Known working situation, as in, does it work at all with 2.6.28.x. No, this machine will not work that way. The machine in question simply will not work properly under X with a .28 kernel. It is currently working with 22.214.171.124.
On Saturday 21 March 2009, Robert Raitz wrote:
> Yes, this bug remains for the i830. I'd like go get it fixed, if at all
> --- On Sat, 3/21/09, Rafael J. Wysocki <firstname.lastname@example.org> wrote:
> > From: Rafael J. Wysocki <email@example.com>
> > Subject: [Bug #12634] video distortion and lockup with i830 video chip and
> > To: "Linux Kernel Mailing List" <firstname.lastname@example.org>
> > Cc: "Kernel Testers List" <email@example.com>, "Bob Raitz"
> > Date: Saturday, March 21, 2009, 12:07 PM
> > This message has been generated automatically as a part of a
> > report
> > of regressions introduced between 2.6.27 and 2.6.28.
> > The following bug entry is on the current list of known
> > regressions
> > introduced between 2.6.27 and 2.6.28. Please verify if it
> > still should
> > be listed and let me know (either way).
> > Bug-Entry :
> > http://bugzilla.kernel.org/show_bug.cgi?id=12634
> > Subject : video distortion and lockup with i830 video chip
> > and 126.96.36.199
> > Submitter : Bob Raitz <firstname.lastname@example.org>
> > Date : 2009-02-04 21:10 (46 days old)
The machine that was having this issue has died. Therefore, unless someone else wishes to champion this cause, I say let the bug die with the machine.
Sorry about that, but at least we have one less i830 machine to worry about :/