[gm45] Xorg freeze on Firefox on one particular page

There has been some progress upstream with respect to GPU hangs after Lucid was released. We would like to find out if this is one of those bugs or if it is still present in the latest code. In the former case we may test patches and see if it is possible to find one or more that fixes the problem. In the latter case, we will report the problem to the intel developers.

In order to test the newer code, please add the xorg-edgers PPA [1] and the newest 2.6.35-rcX mainline kernel from [2] (see also [3]). Note that since this is very recent code it may contain other bugs. Install the package ppa-purge from xorg-edgers PPA to remove it again with the command `sudo ppa-purge -p xorg-edgers`.

If the computer still freezes with the newest code, please install the openssh-server package which enables ssh login. Add the kernel parameter drm.debug=0x02 [4]. When the computer freezes, ssh in from another computer and run the following commands (copy and paste if you want):
datestr=$(date +%Y%m%d)
mkdir dri_debug-$datestr
cd dri_debug-$datestr
intel_error_decode >intel_error_decode.txt
dmesg > dmesg.txt
cp /var/log/Xorg.0.log .

Then attach the files in dri_debug_2010MMDD (where MM and DD are month and date) to this bug report.

In Maverick we will hopefully start generating bug reports with this information automatically soon. There is some general information about this kind of bugs at [5].

[1]: https://launchpad.net/~xorg-edgers/+archive/ppa
[2]: http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D
[3]: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[4]: You can bring up the boot menu by holding shift during boot. Select the kernel and press 'e' to edit the kernel command line and Ctrl+X to boot with that command line. Another way is to add it in /etc/default/grub, add it to GRUB_CMDLINE_LINUX_DEFAULT and run `sudo update grub`.
[5]: https://wiki.ubuntu.com/X/Troubleshooting/Freeze

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Confirmed : https://bugs.launchpad.net/ubuntu/+source/libflash/+bug/152551

Same problem for me with my laptop equiped with an intel video card.
www.pagesjaunes.fr is almost unusable with Firefox (3.6.12 on Ubuntu 10.04).

Confirmed on my Vaio laptop (lucid 32bit), but not on my desktop with Nvidia graphics (64bit).
The bug is specific to Firefox (3.6.13 currently) since no crash occurs on the pagesjaunes.fr website with Chromium.

same problem with my 64-bits computer (ubuntu 10.04) and latest Firefox version
total freeze visiting pagesjaunes.fr

We can reliably reproduce this bug here too. You can connect by shh, but the graphical interface appears completely frozen (except for the cursor). The Xorg process spins at 100%.

We tried using Chromium instead of Firefox, and could not reproduce the problem. That seems to indicate that the problem is triggered by the Flash plugin. I tried disabling Flash altogether, but the page UI would not work without Flash at all (and would not work with Gnash either :( ).

It also crashes with Flash plugin version 10.2.152.27 (installed from upstream's tarball).

On Maverick, using Flashplayer 10.2.152.27 (installed using the flashplugin-installer package), it does not crash. So it seems to be limited to the intel driver on lucid.

Attached the information requested in comment #2.

We tested with the web site discussed in duplicate bug #545056, http://www.ardmediathek.de. We have experienced the same lockup on the machine that is locking up on pagesjaunes.fr.

Hi Etienne, thanks for providing the information that was requested.

However, you can see from the contents of intel_error_decode.txt that no data was captured in this case. The two log files also do not appear to contain relevant error messages. Please note that these things need to be collected after reproducing the issue while the system is still frozen (by sshing into it), but before rebooting. intel_error_decode may need to be run as sudo too, I don't recall if this was required on Lucid.

I attempted loading this URL in firefox on a 945 running Natty, reloading the page 30 times, as well as letting it sit idle for 20 min but did not reproduce it. Also I did 30 reloads and 20 min idle on a 965 running the same code, and did not reproduce it there either. So this supports comment #10 that the issue was likely fixed during Maverick development.

btw, linux-lts-backport-maverick in lucid-proposed is the package to install

One other thing to try if you haven't already is shutting off Compiz. In the lucid timeframe I recall there were some freeze bugs with compiz enabled which went away with it turned off. (I can't tell from this bug report whether compiz was on or off in this case.)

There is also a possibility that it is a bug in the flashplayer (which I don't have a lot of experience). Some googling suggests there is a configuration parameter which sometimes works around GPU issues that might be worth trying if you haven't already:

sudo mkdir /etc/adobe
echo "OverrideGPUValidation=true" >~/mms.cfg
sudo mv ~/mms.cfg /etc/adobe/
# http://blogs.adobe.com/penguinswf/2008/08/secrets_of_the_mmscfg_file_1.html

Apparently flash has some buggy code for determining whether it can use the GPU for acceleration or not, and this lets you bypass those checks. In theory doing this gives better flash video performance. Possibly this parameter could let you control the rendering path in general, which might let you bypass the bugged code that freezes.

If there is already a /etc/adobe/mms.cfg file present on the system with this setting, you could try setting it to false.

To elaborate on my comment #16, 90% of the time Xorg freezes are due to issues in the kernel drm. So the fact that the bug seems not to reproduce in Maverick suggests testing the newer kernel. linux-lts-backport-maverick in lucid-proposed

This will achieve two things. First it will identify if the root cause of this problem is indeed in the kernel, vs. in flash or X. Second it will provide a temporary workaround

Confirmed to be with the kernel drm. With the maverick-lts-backport kernel, we cannot reproduce the crash. Of course, it is non-deterministic, so there is always the possibility that the bug is still there, only less frequent. But after 50 refreshes of the offending page and no crash, we are pretty confident! :)

It is interesting to note that X does not write a stack trace in /var/log/Xorg.0.log when it freeze. It does not respond to kill request either (kill <pid of Xorg>, or service restart gdm).

Attached an lspci -vvnn and dmesg from an affected machine (Lenovo Thinkpad L510).

We tested the workaround from comment #18, and we can still crash X visiting the page in question. It didn't seems to help, sadly.

Bryce, I missed comment #15 earlier. The information where indeed collected from a frozen system, through ssh. IIRC, we did use sudo to run intel_error_decode.

Another thing I missed, Bryse: in comment #15, you explain that you where not able to crash X by visiting the site. It is because the crash happen on the result page. So you need to reverse-lookup a French number, which are ten digits long. Usually, after searching for 10~15 numbers, X crashes.

Which makes me think: perhaps we should contact the webmaster of the offending site.

+1
Coming from bug 152551

Having the same bug.
Happens in the past donno why but page jaune is quite doing it very often.
The newbie I am don't understand how a simple app ran as a User is able to crash a whole linux system, including blocking the magic keys. Kinda upsetting.

+1 same bug:
Ubuntu 10.04 updated, firefox 3.6.17, notebook ASUS F7F with intel graphic card, compiz desactivated, access to the same page http://www.pagesjaunes.fr/pagesblanches/?portail=PJ and random freeze after some activities on this page.
Note: every time it appens, Virtualbox was running (as often on this machine).
Note2: use of a dual screen (external sreen).

See attached Xorg.0.log
Xorg detects the bug, here is the end of the file:

(II) XKB: reuse xkmfile /var/lib/xkb/server-FC679A95A1D16D542234F8522B27A8CCAEC28E99.xkm
(II) XKB: reuse xkmfile /var/lib/xkb/server-FC679A95A1D16D542234F8522B27A8CCAEC28E99.xkm
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x3b) [0x80e955b]
1: /usr/bin/X (mieqEnqueue+0x1ab) [0x80e8d4b]
2: /usr/bin/X (xf86PostButtonEventP+0xcf) [0x80c2baf]
3: /usr/bin/X (xf86PostButtonEvent+0x6c) [0x80c2c5c]
4: /usr/lib/xorg/modules/input/evdev_drv.so (0x4c4000+0x4c67) [0x4c8c67]
5: /usr/bin/X (0x8048000+0x6d76f) [0x80b576f]
6: /usr/bin/X (0x8048000+0x122944) [0x816a944]
7: (vdso) (__kernel_sigreturn+0x0) [0xb2a400]
8: /usr/lib/libpixman-1.so.0 (0xc05000+0x4cf10) [0xc51f10]
9: /usr/lib/libpixman-1.so.0 (0xc05000+0x147e3) [0xc197e3]
10: /usr/lib/libpixman-1.so.0 (pixman_blt+0x78) [0xc3f1e8]
11: /usr/lib/xorg/modules/libfb.so (fbCopyNtoN+0x24d) [0x4b805d]
12: /usr/lib/xorg/modules/drivers/intel_drv.so (0x41c000+0x5da39) [0x479a39]
13: /usr/lib/xorg/modules/drivers/intel_drv.so (0x41c000+0x61de8) [0x47dde8]
14: /usr/bin/X (0x8048000+0xd8afb) [0x8120afb]
15: /usr/bin/X (CompositePicture+0x298) [0x8113e28]
16: /usr/bin/X (0x8048000+0xd1efd) [0x8119efd]
17: /usr/bin/X (0x8048000+0xcebd3) [0x8116bd3]
18: /usr/bin/X (0x8048000+0x2a477) [0x8072477]
19: /usr/bin/X (0x8048000+0x1ed7a) [0x8066d7a]
20: /lib/tls/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0x27abd6]
21: /usr/bin/X (0x8048000+0x1e961) [0x8066961]

forgot to ask:
is the debug file as requested in comment #2 still needed? other file that I can give to help?
Thanks :-)

For the record, I contacted pagesjaunes.fr through the customer contact web form over a month ago, got an automated response, but they have not followed up :(

I do not currently have a machine on hand that has the bug running lucid, but can someone test using the updated xserver-xorg-video-intel package from the X-Updates PPA? Perhaps that would help, and it would be interesting to confirm either way.

    https://launchpad.net/~ubuntu-x-swat/+archive/x-updates

Ok great, the testing done so far appears to be pinpointing this to an issue fixed with newer kernel drm code. It's possible a specific patch resulted in the fix. In that case, the next logical step is to do a git bisection search on the kernel code to locate the fix. The procedure is a little technical but is well documented at https://wiki.ubuntu.com/Kernel/KernelBisection. I'll reassign to the kernel meanwhile.

Btw, drm code can be a bit thorny, and even if the solution is narrowed to a specific git commit, extracting and backporting it might be pretty tricky. But the kernel team can follow up with advice on the issue; please contact them if you have additional questions.

I've been trying to reproduce this on a machine with a different Intel graphics chipset, but no luck.

Let's start by trying to narrow down a bit the range for the bisection. Please test the following mainline builds, starting with v2.6.33.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33/
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.34-lucid/
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-maverick/

If you find the problem is not present in v2.6.33 there's no need to test .34, and if it's not present in .34 there's no need to test .35. Please report your results back here. Let me know if you need instructions on installing these builds. Thanks!

Turns out I am able to reproduce this on a machine I have, although this machine has a different generation graphics chipset than the GM45. The symptoms are identical though, so hopefully the root cause is the same. I'll keep investigating with my machine and see what I come up with.

I have a tentative fix for this issue. A test kernel has been posted to:

http://people.canonical.com/~sforshee/lp599017/linux-2.6.32-33.66~lp599017v201106142055/

Please test and report back here with your results. Also note that this fix has only received a modest amount of testing at this point and may contain bugs. Thanks!

I've posted another kernel with a couple of more patches that improve things a bit more in my testing. It is available at:

http://people.canonical.com/~sforshee/lp599017/linux-2.6.32-33.66~lp599017v201106161605/

We did test the previous kernel (from June 14th, comment 33) with positive results and no apparent regression. I will have the kernel from the current one (from June 16th; comment 34) tested too and will report.

I have a similar problem on Natty. If I open http://www.telekom.de/ in Firefox and leave the computer alone for some time (probably needs to have the screen power saving kicking in) X freezes. Graphics controller is Intel 82G965 (rev 02) and the system is 64-bit.

On my 64-bit laptop (Intel Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)) this problem nevver occured (on both Natty and Oneiric).

Till: You might want to install the build linked to in comment #34 to see if it eliminates your issues. Thanks!

I am having this problem on Natty using 2.6.38-10-generic-pae. I also note that about every minute or two the mouse freezes briefly for about half a second. There is nothing in the logs and I don't notice any spikes in processor usage. Would it be worthwhile me going back to the kernel linked to in comment #34? Thanks, Shaun

On Mon, Aug 01, 2011 at 07:26:58AM -0000, Shaun James wrote:
> I am having this problem on Natty using 2.6.38-10-generic-pae. I also
> note that about every minute or two the mouse freezes briefly for about
> half a second. There is nothing in the logs and I don't notice any
> spikes in processor usage. Would it be worthwhile me going back to the
> kernel linked to in comment #34? Thanks, Shaun

I need some clarification of these statements. You see instances where
the user interface hangs and never seems to recover, correct? When this
happens, is CPU usage by xorg extremely high? If it's not, then you
aren't seeing the same problem and should open a new bug. Also, if you
are not using Intel graphics then you are seeing a different problem as
this one is Intel-specific.

The fixes in the kernel from comment #34 are essentially backports of
several changes that are all already present in natty, so that kernel
isn't likely to help, unless what you're seeing is a regression between
the lucid and natty kernels. And in that case it is once again probably a
different issue than the one here.

Thanks Seth. No, I do not have Intel graphics, I have Nvidia. There are two problems:
1) The mouse hangs for about half a second exactly every ten seconds, and then continues on. The mouse pointer does not seem to buffer any movement that occurred in that half second.
2) Occasionally the complete user interfaces hangs and never recovers. The mouse pointer continues to work but the keyboard does not nor does anything on the screen update.
I will set up my install so that I have ssh access and next time it occurs I will check for network connectivity and if able to, CPU usage. After that I suppose I will submit a new bug.

Thanks, Shaun

I posted a new build based on the current lucid proposed kernel (2.6.32-33.72). This build is available at:

  http://people.canonical.com/~sforshee/lp599017/linux-2.6.32-33.72~lp599017v201108031621/

This bug is awaiting verification that the kernel for Lucid in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lucid' to 'verification-done-lucid'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

I'm unable to reproduce with 2.6.32-34.74.

Hi all,
We had this bug with only some pcs (Lenovo with intel graphics chipset) on lucid.
Now, no crash at all with kernel 2.6.32-34.74, even after been trying 50 times on the page: "Annuaire inverse".
Thanks

This bug was fixed in the package linux - 2.6.32-34.77

---------------
linux (2.6.32-34.77) lucid-proposed; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #849228

  [ Upstream Kernel Changes ]

  * Revert "drm/i915: Remove BUG_ON from i915_gem_evict_something"
  * Revert "drm/i915: Periodically flush the active lists and requests"
  * Revert "drm/i915/evict: Ensure we completely cleanup on failure"
  * Revert "drm/i915: Maintain LRU order of inactive objects upon access by
    CPU (v2)"
  * Revert "drm/i915: Implement fair lru eviction across both rings. (v2)"
  * Revert "drm/i915: Move the eviction logic to its own file."
  * Revert "drm/i915: prepare for fair lru eviction"

linux (2.6.32-34.76) lucid-proposed; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #836914

  [ Upstream Kernel Changes ]

  * Revert "drm/nv50-nvc0: work around an evo channel hang that some people
    see"
  * Revert "eCryptfs: Handle failed metadata read in lookup"
  * Revert "tunnels: fix netns vs proto registration ordering"

linux (2.6.32-34.75) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #832332

  [ Upstream Kernel Changes ]

  * drm/i915: Remove BUG_ON from i915_gem_evict_something
    - LP: #828550

linux (2.6.32-34.74) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #828375

  [ Upstream Kernel Changes ]

  * proc: fix oops on invalid /proc/<pid>/maps access, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020

linux (2.6.32-34.73) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #824148

  [ Tim Gardner ]

  * SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
    - LP: #805494
  * [Config] Add enic/fnic to udebs
    - LP: #801610

  [ Upstream Kernel Changes ]

  * tty: icount changeover for other main devices, CVE-2010-4076,
    CVE-2010-4077
    - LP: #720189
    - CVE-2010-4077
  * fs/partitions/efi.c: corrupted GUID partition tables can cause kernel
    oops
    - LP: #795418
    - CVE-2011-1577
  * ftrace: Only update the function code on write to filter files
    - LP: #802383
  * kmemleak: Do not return a pointer to an object that kmemleak did not
    get
    - LP: #802383
  * CPU hotplug, re-create sysfs directory and symlinks
    - LP: #802383
  * Fix memory leak in cpufreq_stat
    - LP: #802383
  * powerpc/kexec: Fix memory corruption from unallocated slaves
    - LP: #802383
  * powerpc/oprofile: Handle events that raise an exception without
    overflowing
    - LP: #802383
  * mtd: mtdconcat: fix NAND OOB write
    - LP: #802383
  * x86, 64-bit: Fix copy_[to/from]_user() checks for the userspace address
    limit
    - LP: #802383
  * ext3: Fix fs corruption when make_indexed_dir() fails
    - LP: #802383
  * jbd: Fix forever sleeping process in do_get_write_access()
    - LP: #802383
  * jbd: fix fsync() tid wraparound bug
    - LP: #802383
  * ext4: release page cache in ext4_mb_load_buddy error path
    - LP: #802383
  * Fix Ultrastor asm snippet
    - LP: #802383
  * x86, amd: Do not enable ARAT feature on AMD processors below family
    0x12
    - LP: #802383
  * x86, ...

Actually it's not fixed, the patches were reverted. Moving back to In Progress.

I am fairly sure this bug can now be marked Fix Released. Seth?

Yes, it's fixed in 2.6.32-35.78. For whatever reason the buglinks were all changed to bug 843904 when the patches were reapplied, so the status didn't changed automatically.