Bug 498131
| Summary: | Visiting webpage causes system lockup, except mouse cursor | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Andy Lawrence <dr.diesel> | ||||||||
| Component: | xorg-x11-drv-intel | Assignee: | Kristian Høgsberg <krh> | ||||||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | rawhide | CC: | ajax, bnocera, brentley, cra, dcantrell, dhaval, fedora.bugreports, henrik, itamar, james, kernel-maint, lex.lists, mail, martin.sourada, mcepl, mclasen, mishu, mschick, nicubunu, quintela, scottt.tw, selinux, sundaram, todd.martin, wtogami, wwoods, xgl-maint | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2009-05-22 17:42:33 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 446451 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Andy Lawrence
2009-04-29 01:42:20 UTC
Confirmed system seems to lockup when you visit this page in firefox on rawhide x86_64. VT switch fails, but you can still move the mouse cursor. I'm pretty sure this isn't a kernel bug. Assigning to X, it can be reassigned from there. I see the same on 965GM, x86_64 as well. Not sure if this is related, I get a similar hard lock when trying to play any kind of video file (Ogg Theora, DivX) on any player (Totem, VLC, Mplayer, the Totem plugin in Firefox) with only two exceptions: - flash videos in the browser; - Ogg Theora videos in Firefox (probably using the build in Theora decoder) (fully updated Rawhide, Intel 965). I see the same behaviour. Intel GM965/GL960 here. Disabling KMS seems to workaround the problem. Can others here confirm this? I can see the same problem , My card -- VGA: compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller Created attachment 341725 [details]
/var/log/dmesg
Created attachment 341726 [details]
/var/log/Xorg.0.log
Created attachment 341727 [details]
/var/log/messages
Yeah can reproduce handily :( here as well! With Thinkpad X200, I do NOT get freeze with "nomodeset nopat" on boot line, and running latest fc11 updates and compiz. 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) But I do see this in /var/log/messages: Apr 29 06:18:18 tlondon kernel: Machine check events logged Do not recall seeing "Machine check events logged" message before..... Same problem here ;-/ The lock happend with openoffice and firefox. Reproducible with epiphany (xulrunner backend), but not with midori (webkitgtk) here. Didn't try without KMS. It think it's really a soft lock, music continues to play. i586 Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) I have seen the same for some time. Intel GM965 chipset. For the record, this bug was discussed on the mailing lists, and summarized here: http://fedoraproject.org/wiki/FWN/Issue174#Fedora_11_Preview_Xorg_.22Lock-up.22 Note that this isn't (strictly speaking) a full lockup, it's just taking a very long time to draw a large image - the web page(s) in question are typically using a background image that's 15000 pixels tall or something ridiculous like that. The bug's being actively chased and (if all goes well) should have a fix sometime soonish. Not sure that's the entire story. While it's true that I have only seen this while using Firefox, it's for me more random. On some sites I visit frequently I get this kind of "lockup" maybe once every 3 days.. But maybe some of those web sites have coding errors triggering rendering requests like that. I can confirm the random lockups Henrik mentioned as well. I can ssh into the box when it's locked as well as move the mouse, but it's completely unresponsive from X. Killing the usual suspects (firefox, compiz, gnome-session) does nothing, but I can do a clean reboot. I'd attach logs, but there's nothing in the way of warnings or errors in either the X or system logs. On my Intel G33(8086:29c2), after updating to: kernel-2.6.29.3-155.fc11.x86_64 libdrm-2.4.6-7.fc11.x86_64 xorg-x11-drv-intel-2.7.0-6.fc11.x86_64 visiting http://www.wthitv.com in firefox no longer locks up(It used to). I can confirm that after update to versions from comment #18 firefox (and desktop also) from F11 no longer locks up. Thanks for confirming, rpms are in F-11 now. *** Bug 502252 has been marked as a duplicate of this bug. *** Hmm... I think I just ran into this with all the updates: libdrm-2.4.6-7.fc11.i586 kernel-2.6.29.4-167.fc11.x86_64 xorg-x11-drv-intel-2.7.0-7.fc11.x86_64 There was an Xorg page allocation failure earlier, and I'd been suspending/resume a few times. Have also seen this "hang" once after all the updates, random clicking on a web page I frequently use.. I kind of suspect there is two issues with the same visible symptoms (X "hang" except for mouse pointer movement), one which is (was) easily reproducible by visiting a particularily misdesigned webpage, another which is more random in nature.. Unfortunately I do not have any logs to post of the event, but will make sure to collect some if/when it happens again. All the times this has happened to me there's been nothing in either the kernel or X logs, and X itself isn't stuck in a loop; it's just sleeping except for pointer movement. |