Bug 502077 - [KMS] Hangs on 82865G
[KMS] Hangs on 82865G
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
Depends On:
Blocks: IntelKMS F11XorgBlocker
  Show dependency treegraph
 
Reported: 2009-05-21 14:36 EDT by Lubomir Rintel
Modified: 2009-06-06 16:24 EDT (History)
9 users (show)

See Also:
Fixed In Version: kernel-2.6.29.4-167.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-28 07:53:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg.0.log (52.45 KB, text/plain)
2009-05-21 14:36 EDT, Lubomir Rintel
no flags Details
another Xorg.0.log (43.53 KB, text/plain)
2009-05-21 16:54 EDT, Jeff Bastian
no flags Details
sysprof-1.0.12 output (81.17 KB, text/plain)
2009-05-21 17:24 EDT, Jeff Bastian
no flags Details

  None (edit)
Description Lubomir Rintel 2009-05-21 14:36:41 EDT
Created attachment 345009 [details]
Xorg.0.log

Description of problem:

The hangs can almost certainly be triggered when you switch desktops with many windows (say firefox) quickly for a couple of times.

My hardware is:

00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

Nothing wrong suspicious in dmesg and Xorg.0.log (attaching)

Version-Release number of selected component (if applicable):

Today's f11/rawhide
kernel-2.6.29.3-155.fc11.i586
mesa-dri-drivers-7.5-0.14.fc11.i586
xorg-x11-drv-intel-2.7.0-4.fc11.i586
xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586

Actual results:

[root@bimbo ~]# strace -p 2041 2>&1 |head
Process 2041 attached - interrupt to quit
ioctl(8, 0x400c645f, 0xbfe1cdc4)        = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
ioctl(8, 0x400c645f, 0xbfe1cdc4)        = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
ioctl(8, 0x400c645f, 0xbfe1cdc4)        = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
[root@bimbo ~]#

(gdb) bt
#0  0x00743422 in __kernel_vsyscall ()
#1  0x00351239 in ioctl () from /lib/libc.so.6
#2  0x0053423a in drm_intel_gem_bo_map (bo=0x8b121c0, write_enable=1) at intel_bufmgr_gem.c:648
#3  0x00530269 in drm_intel_bo_map (buf=0x8b121c0, write_enable=1) at intel_bufmgr.c:79
#4  0x0043078d in i830_uxa_prepare_access (pixmap=0x8b1ca48, access=UXA_ACCESS_RW) at i830_exa.c:857
#5  0x00448ed4 in uxa_prepare_access (pDrawable=0x8b1ca48, access=UXA_ACCESS_RW) at uxa.c:158
#6  0x0044fa3a in uxa_check_composite (op=5 '\5', pSrc=0x8b12c20, pMask=0x0, pDst=0x8b0fe60, xSrc=104, ySrc=44, xMask=0, yMask=0, xDst=0, yDst=0, width=101, height=5)
    at uxa-unaccel.c:376
#7  0x0044dfca in uxa_composite (op=5 '\5', pSrc=0x8b12c20, pMask=0x0, pDst=0x8b0fe60, xSrc=104, ySrc=44, xMask=0, yMask=0, xDst=0, yDst=0, width=101, height=5)
    at uxa-render.c:778
#8  0x08176dbb in damageComposite (op=228 '\344', pSrc=0x8b12c20, pMask=0x0, pDst=0x8b0fe60, xSrc=<value optimized out>, ySrc=<value optimized out>,
    xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=<value optimized out>,
    height=<value optimized out>) at damage.c:643
#9  0x0816905c in CompositePicture (op=5 '\5', pSrc=0x8b12c20, pMask=0x0, pDst=0x8b0fe60, xSrc=104, ySrc=44, xMask=<value optimized out>,
    yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=101, height=5) at picture.c:1675
#10 0x0816ef0b in ProcRenderComposite (client=0x8abad58) at render.c:720
#11 0x0816bbc5 in ProcRenderDispatch (client=0xbfe3f6e4) at render.c:2086
#12 0x080864d7 in Dispatch () at dispatch.c:437
#13 0x0806baf5 in main (argc=8, argv=0xbfe3fca4, envp=0xbfe3fcc8) at main.c:397
(gdb)

Stuck in ioctl, receiving ALRM signals repeatedly and quickly.

Setting as blocker, bug #488980 makes it seem like 845 with KMS not being usable is serious enough
Comment 1 Adam Williamson 2009-05-21 15:18:33 EDT
You have an 865, not an 845...and also, other reporters in that bug don't seem to be experiencing the same hangs. Thanks for the report, though.
Comment 2 Antal KICSI 2009-05-21 15:22:55 EDT
I also have some problems with i845 KMS solution on BZ488980. I do not experience the above problems, but ocasionally at boot time the system hangs when the mouse cursor first appears on screen.

I also have problems with Firefox - when I place the mouse cursor in navigation bar I get some grey 1 pixel lines. These lines I noticed in web pages where the caracters where distorted by some dashed 1 pixel lines. This behaviour appears also in the terminal window. 

If I boot the same kernel-2.6.29.3-155.fc11.i586 with the nomodeset boot parameter I do not have any of the above stated problems.

So the kernel-2.6.29.3-155.fc11.i586 is a big step in the right dirrection but maybe needs a bit of attention!

VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
Comment 3 Jason Long 2009-05-21 16:31:22 EDT
>when I place the mouse cursor in navigation
>bar I get some grey 1 pixel lines.

I see this too (also Intel 82845G/GL). I think it's a separate bug, so I opened bug 502096.
Comment 4 Jeff Bastian 2009-05-21 16:54:57 EDT
Created attachment 345028 [details]
another Xorg.0.log

I'm also seeing hangs with kernel-PAE-2.6.29.3-155.fc11.i686 and an 82865G:
  00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02)

My Xorg.0.log is attached.  I was able to login and start Xfce, and then I opened a terminal window, and it hung before the bash prompt appeared.  The mouse cursor still moves, though, and I can login remotely.

Nothing particularly interesting in dmesg output:
$ dmesg | tail
Bridge firewalling registered
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
[drm] DAC-5: set mode 1024x768 f
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100: eth0 NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
fuse init (API version 7.11)
SELinux: initialized (dev fuse, type fuse), uses genfs_contexts
Comment 5 Jeff Bastian 2009-05-21 17:24:50 EDT
Created attachment 345029 [details]
sysprof-1.0.12 output

I assume that the sysprof mentioned in bug 488980 comment 39 is this?
  http://www.daimi.au.dk/~sandmann/sysprof/

If so, I ran it and here are the results.  It gathered 27 samples over a couple of minutes.  I tried moving the mouse and hitting some keys on the hung console while it was gathering samples, but that didn't seem to affect the number of samples it gathered.
Comment 6 Adam Williamson 2009-05-22 15:14:12 EDT
This issue was discussed at the QA/RelEng blocker review meeting, in co-ordination with the X developers. It was agreed that we will likely disable kernel modesetting by default for this chipset for F11 release, as a workaround rather than a fix. The bug will remain open as we must eventually ensure the chip works well with kernel modesetting, but will be downgraded from blocker status, once a build with kernel modesetting disabled is pushed.
Comment 7 David 2009-05-22 16:40:23 EDT
I'm also seeing this problem on a system that has 865G:

http://www.smolts.org/client/show/pub_45e71f52-1171-43c0-9c36-aacc87834e13

I can attach an Xorg log if requested, but it I see you already got one.
Comment 8 Neal Gompa 2009-05-25 23:25:10 EDT
Even if it is downgraded, does that mean that KMS might be reawakened on the chip after F11 release once this is fixed?
Comment 9 Adam Williamson 2009-05-26 13:46:48 EDT
yes, that would be the reason to keep it open. we must fix the KMS case in the end, because we want to kill all the modesetting code from the driver in the long run, and rely on kernel modesetting exclusively. so obviously all KMS bugs have to be fixed. disabling kms by default for F11 GA is just a short-term workaround.
Comment 10 Kyle McMartin 2009-05-26 14:17:47 EDT
Please try the scratch build here

 http://koji.fedoraproject.org/koji/taskinfo?taskID=1377794

do not add any "i915.modeset" or "nomodeset" lines and try it, it should disable modesetting on its own on your chipset.
Comment 11 Adam Williamson 2009-05-26 16:09:25 EDT
Please test ASAP, guys - we're on a very tight wire for final release. thanks a lot for your help :)

I've had feedback from one person, so far, that it works as intended - it behaves just like booting a regular kernel with 'nomodeset'.
Comment 12 Kyle McMartin 2009-05-26 21:38:29 EDT
http://koji.fedoraproject.org/koji/taskinfo?taskID=1378653

new build with a better patch, please test this one instead.
Comment 13 Jeff Bastian 2009-05-27 08:52:45 EDT
The build from comment 12 works for me: it boots in text mode with no kernel parameters.

$ uname -r
2.6.29.4-163.i8xx_nokms.fc11.i686.PAE
$ cat /proc/cmdline
ro root=/dev/mapper/VolGroup-lv_root rhgb quiet
Comment 14 Adam Williamson 2009-05-27 12:44:41 EDT
there's one other obvious test - boot it on a post i8xx system and make sure modesetting is still used :) can anyone do that? I don't have an intel adapter in any of my systems any more.
Comment 15 Adam Williamson 2009-05-27 13:04:55 EDT
Kristian apparently expressed the view that he thinks this is similar to or the same as #498131 . I don't see how that could be the case, as it seems people are encountering this problem with the packages that fixed 498131, but I thought it worth mentioning here.
Comment 16 Adam Williamson 2009-05-27 13:06:17 EDT
can anyone confirm for sure that they experience this problem with the package set which was reported to fix 498131:

kernel-2.6.29.3-155.fc11
libdrm-2.4.6-7.fc11
xorg-x11-drv-intel-2.7.0-6.fc11

or later?
Comment 17 Kyle McMartin 2009-05-27 13:15:06 EDT
https://koji.fedoraproject.org/koji/taskinfo?taskID=1379720

while we're at it, please test this, it may or may not work with full kms/gem on i855/865/845. Please try it with no "nomodeset" passed. X should, in theory, work.

This needs to be done asap, as we're down to the wire and will otherwise have to disable it by default.
Comment 18 Kyle McMartin 2009-05-27 13:29:49 EDT
AdamW, I have tested it on 965 and 945... where's the trust?
Comment 19 Adam Williamson 2009-05-27 14:27:12 EDT
kristian reports that his i865 does not suffer from this issue. That gives us three people seeing hangs on systems with an i865, and one not.
Comment 20 Jeff Bastian 2009-05-27 15:10:45 EDT
I tried the latest kernel from comment 17 (2.6.29.4-163.i8xx.fc11.i686.PAE) with and without 'nomodeset' and it seems okay both ways.  I didn't see any hanging even with KMS enabled.  I didn't test for very long (just a few minutes), but previously it would hang within ~10 seconds of logging in.  I was able to login, start Firefox, go to a handful of sites, do some file management, and logout with no hangs and KMS enabled.
Comment 21 Adam Williamson 2009-05-27 15:20:02 EDT
Thanks for the feedback, Jeff.
Comment 22 Lubomir Rintel 2009-05-27 15:44:25 EDT
(In reply to comment #19)
> kristian reports that his i865 does not suffer from this issue. That gives us
> three people seeing hangs on systems with an i865, and one not.

I bet he did not try hard enough ;)
(/me actually seeing it on two different pieces of i865 hardware)

(In reply to comment #17)
> https://koji.fedoraproject.org/koji/taskinfo?taskID=1379720
> 
> while we're at it, please test this, it may or may not work with full kms/gem
> on i855/865/845. Please try it with no "nomodeset" passed. X should, in theory,
> work.
> 
> This needs to be done asap, as we're down to the wire and will otherwise have
> to disable it by default.  

Works like a charm. No hang even after a couple of minutes of aggressively switching desktops with lots of windows which previously lead to a crash in a couple of seconds. Even subjectively feels a bit snappier than without modesetting. Thanks a lot!
Comment 23 Lubomir Rintel 2009-05-27 16:04:55 EDT
(In reply to comment #22)
> Works like a charm.

Even compiz works beautifully and I could play some supertux. Yay \o/
Comment 24 Adam Williamson 2009-05-27 17:10:52 EDT
The final kernel that we will compose with is now being built:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1380684

please test that, once it's ready, and confirm that the issue is resolved. thanks a lot!
Comment 25 Adam Williamson 2009-05-27 17:13:13 EDT
grr. correction: http://koji.fedoraproject.org/koji/taskinfo?taskID=1380686
Comment 26 Jeff Bastian 2009-05-27 23:12:01 EDT
Re-confirming that the latest kernel, comment 25, still works for me, and I have KMS enabled.

$ uname -r
2.6.29.4-167.fc11.i686.PAE
$ cat /proc/cmdline
ro root=/dev/mapper/VolGroup-lv_root rhgb quiet
Comment 27 Matěj Cepl 2009-05-28 07:53:44 EDT
Thanks a lot guys, based on comment 23 and comment 26 let's claim that it has been closed. If anybody is of different opinion, please, reopen the bug with additional information.
Comment 28 Jeff Layton 2009-05-28 07:54:32 EDT
Latest packages are working much better for me as well. I also have KMS enabled:

kernel-PAE-2.6.29.4-167.fc11.i686
libdrm-2.4.6-7.fc11.i586
xorg-x11-drv-intel-2.7.0-6.fc11.i586

...only one X lockup so far, but at the time I was trying to reenable compiz (and did something a little weird with it). So I can't really attribute that to the same problem.
Comment 29 Adam Williamson 2009-05-28 11:21:33 EDT
correct resolution...matej, read the workflow ;)
Comment 30 Lubomir Rintel 2009-06-06 16:24:56 EDT
Oh God, I've wasted the whole week playing with wobbly windows, thank you so much mister McMartin.

Note You need to log in before you can comment on or make changes to this bug.