Bug 510169 - System hangs hardly when using video
Summary: System hangs hardly when using video
Keywords:
Status: CLOSED DUPLICATE of bug 509519
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 11
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-08 02:13 UTC by Luis A. Florit
Modified: 2009-08-02 16:52 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-08-02 16:52:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Luis A. Florit 2009-07-08 02:13:01 UTC
Description of problem: Yesterday I copied 700MB from disk to my pen drive, and memory began to swap badly, until system froze. Booting back, I read MTRR errors in /var/log/messages:

[drm] MTRR allocation failed. Graphics performance may suffer.

Seeing this, I tried foobillard that I know uses lots of video. It opened fine, but when pressing ESC to quit, the system locked hard *instantly*, with the following trace:

Kernel failure message 1:
------------[ cut here ]------------
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:2136!
invalid opcode: 0000 [#1] SMP 
last sysfs file: /sys/devices/platform/coretemp.3/temp1_input
Modules linked in: aes_i586 aes_generic cbc fuse cryptoloop coretemp hwmon sunrpc iptable_nat nf_nat ipt_LOG xt_limit ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq nls_utf8 dm_multipath uinput joydev usb_storage snd_hda_codec_realtek wacom snd_hda_intel snd_hda_codec snd_hwdep iTCO_wdt iTCO_vendor_support snd_pcm snd_timer i2c_i801 r8169 mii snd soundcore snd_page_alloc ppdev parport_pc parport pcspkr ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan]
Jul  7 22:28:20 Orion kernel: Pid: 12230, comm: foobillard Not tainted (2.6.29.5-191.fc11.i686.PAE #1)         
EIP: 0060:[<f83b5a9b>] EFLAGS: 00210202 CPU: 1
EIP is at i915_gem_object_get_fence_reg+0x229/0x605 [i915]
EAX: 001ef17c EBX: ccec5a80 ECX: f639c000 EDX: 00000010
ESI: e22ecd00 EDI: f702e000 EBP: d3bcbd7c ESP: d3bcbd48
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process foobillard (pid: 12230, ti=d3bca000 task=e84e5860 task.ti=d3bca000)
Stack:
00000010 ccec5a80 001ef17c e22ecd00 f702e144 f702e144 cce66000 e22ec880
f639c000 00000004 e22ec880 d3bcbde8 ccec5a80 d3bcbdac f83b75b8 b69d0000
b69d0000 f702e000 01200246 dece3d68 f639c000 f639c014 e4006da0 00000001
Call Trace:
[<f83b75b8>] ? i915_gem_fault+0xa0/0x102 [i915]
[<c0491e32>] ? __do_fault+0x52/0x39b
[<c0425c59>] ? kmap_atomic_prot+0x200/0x206
[<c04924c1>] ? handle_mm_fault+0x346/0x81e
[<f83b4ee2>] ? i915_gem_object_set_to_gtt_domain+0x48/0x76 [i915]
[<c0718580>] ? do_page_fault+0x307/0x7ec
[<c056446f>] ? prio_tree_insert+0x15f/0x1d4
[<c048c892>] ? vma_prio_tree_insert+0x1f/0x8c
[<c0494460>] ? __vma_link_file+0x53/0x55
[<c0494b6b>] ? vma_link+0x5e/0x85
[<c0716959>] ? unlock_kernel+0x28/0x2b
[<c04b265a>] ? vfs_ioctl+0x64/0x76
[<c04b2f06>] ? do_vfs_ioctl+0x480/0x4ba
[<c0496103>] ? do_mmap_pgoff+0x24f/0x29f
[<c04aed55>] ? path_put+0x1a/0x1d
[<c0718279>] ? do_page_fault+0x0/0x7ec
[<c0716a07>] ? error_code+0x77/0x7c
Code: ff 85 c0 0f 84 a8 fe ff ff e9 f1 03 00 00 89 75 d8 8b 5d d0 83 7e 10 00 75 11 8b 4d dc 8b 09 89 4d e0 f7 41 44 be ff ff ff 74 04 <0f> 0b eb fe 8b 7d ec 8b 75 e0 8b 87 ec 00 00 00 8b 56 20 85 c0 
EIP: [<f83b5a9b>] i915_gem_object_get_fence_reg+0x229/0x605 [i915] SS:ESP 0068:d3bcbd48
---[ end trace e334bf443c3a43fe ]---


Version-Release number of selected component (if applicable):
Same bug with both 2.6.29.5-191.fc11.i686.PAE and 2.6.29.4-167.fc11.i686.PAE.
I use no xorg.conf file. From what I've googled, I strongly suspect that this has to do with the 4GB of memory and my DG41TY Intel motherboard (dmesg attached). In fact, cat /proc/mtrr doesn't look right to me:

reg00: base=0x000000000 (    0MB), size= 4096MB, count=1: write-back
reg01: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back
reg02: base=0x0bdd00000 ( 3037MB), size=    1MB, count=1: write-through
reg03: base=0x0bde00000 ( 3038MB), size=    2MB, count=1: uncachable
reg04: base=0x0be000000 ( 3040MB), size=   32MB, count=1: uncachable
reg05: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable

Hardware:
- 4GB of memory
- DG41TY motherboard
- Intel Core2 Quad CPU Q8300  @ 2.50GHz stepping 0a

How reproducible:
Start foobillard, and press ESC: immediate hang.

Additional info:
dmesg attached

Comment 1 Thomas Spura 2009-07-11 17:04:31 UTC
This should be a duplicate of bug #509519

Comment 2 Luis A. Florit 2009-07-11 20:03:10 UTC
(In reply to comment #1)
> This should be a duplicate of bug #509519  

Quite probably, since I downgraded to mesa 7.5-0.14 and foobillard does not hang system anymore.

Just a warning: The downgrade broke KDE, because /usr/lib/libGLU.so.1 linked to libGLU.so.1.3.070600 that didn't exist. Reinstalling mesa-libGLU from the DVD solved the issue, because it creates a libGLU.so.1.3.070300 which /usr/lib/libGLU.so.1 links to.

Thanks!
L.

Comment 3 Thomas Janssen 2009-08-02 16:52:54 UTC

*** This bug has been marked as a duplicate of bug 509519 ***


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