Description of problem: I am having a hard time tracking why occasionally (once a day seemingly at random) Xorg completely freezes. It happens non-deterministically when I scroll firefox; the length of the scroll, or the mode of scrolling (PgDn or scrollbar dragging) doesn't seem to matter, and it is ofcourse incredibly hard to reproduce. I have not experienced this with any other application. After Xorg freezes, there is no repainting of the display. The mouse cursor can still move around, but clicking has no visible effect. Nor does the keyboard have any visible effect. I can connect to the host from a different computer. The backtrace for X is as below. It seems stuck in the syscall; killing Xorg has no effect. Rebooting the host resumes normal operation. (gdb) bt #0 0x00110416 in __kernel_vsyscall () #1 0x005c6949 in ioctl () from /lib/libc.so.6 #2 0x075db6cf in drmIoctl (fd=11, request=1074029637, arg=0xbfce8474) at xf86drm.c:186 #3 0x075db984 in drmCommandWrite (fd=11, drmCommandIndex=5, data=0xbfce8474, size=<value optimized out>) at xf86drm.c:2313 #4 0x001c6ca5 in I830Sync (pScrn=0x8efbdf8) at i830_accel.c:214 #5 0x001f095a in I830EXASync (pScreen=0x8f3fd98, marker=0) at i830_exa.c:170 #6 0x0026b095 in exaWaitSync (pScreen=0x8f3fd98) at exa.c:1064 #7 0x0026c3ae in ExaDoPrepareAccess (pDrawable=0x9731c90, index=0) at exa.c:517 #8 0x002713b2 in exaCopyDirty (migrate=0xbfce86ec, pValidDst=0x9731d84, pValidSrc=0x9731d78, transfer=0, fallback_src=0x9731cc0 "N���", fallback_dst=0xb6e67af0 "�", fallback_srcpitch=12, fallback_dstpitch=16, fallback_index=0, sync=0x26b0a0 <exaMarkSync>) at exa_migration.c:252 #9 0x00271905 in exaCopyDirtyToFb () at exa_migration.c:308 #10 exaDoMoveInPixmap (migrate=0xbfce86ec) at exa_migration.c:370 #11 0x002720c2 in exaDoMigration (pixmaps=0xbfce86dc, npixmaps=2, can_accel=1) at exa_migration.c:723 #12 0x0026efd1 in exaCopyNtoN (pSrcDrawable=0x9731c90, pDstDrawable=0xa77de008, pGC=0x0, pbox=0xbfce8838, nbox=1, dx=-288, dy=-16, reverse=0, upsidedown=0, bitplane=0, closure=0x0) at exa_accel.c:480 #13 0x002744de in exaComposite (op=1 '\001', pSrc=0x9731de0, pMask=0x0, pDst=0x907ff48, xSrc=0, ySrc=0, xMask=<value optimized out>, yMask=<value optimized out>, xDst=288, yDst=16, width=11, height=10) at exa_render.c:866 #14 0x0816f6fa in damageComposite (op=252 '�', pSrc=0x9731de0, pMask=0x0, pDst=0x907ff48, 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:576 #15 0x0815818a in CompositePicture (op=1 '\001', pSrc=0x9731de0, pMask=0x0, pDst=0x907ff48, xSrc=0, ySrc=0, xMask=<value optimized out>, yMask=<value optimized out>, xDst=<value optimized out>, yDst=<value optimized out>, width=11, height=10) at picture.c:1674 #16 0x0026fc1d in exaGlyphCacheBufferGlyph () at exa_glyphs.c:481 #17 exaBufferGlyph (pScreen=0x8f3fd98, buffer=0xbfce8b44, pGlyph=0x97319f8, xGlyph=71, yGlyph=13) at exa_glyphs.c:543 #18 0x002706f2 in exaGlyphs (op=3 '\003', pSrc=0x97cf040, pDst=0x9ba73c0, maskFormat=0x8f42548, xSrc=35, ySrc=155, nlist=0, list=0xbfce9cb8, glyphs=0xbfce98e0) at exa_glyphs.c:866 #19 0x0816f9c5 in damageGlyphs (op=252 '�', pSrc=0x97cf040, pDst=0x9ba73c0, maskFormat=0x8f42548, xSrc=<value optimized out>, ySrc=<value optimized out>, nlist=1, list=0xbfce9cb8, glyphs=0xbfce98b8) at damage.c:654 #20 0x08154612 in CompositeGlyphs (op=<value optimized out>, pSrc=0x97cf040, pDst=0x9ba73c0, maskFormat=0x8f42548, xSrc=35, ySrc=155, nlist=1, lists=0xbfce9cb8, glyphs=0xbfce98b8) at glyph.c:629 #21 0x0816197e in ProcRenderCompositeGlyphs (client=0x91816d0) at render.c:1468 #22 0x0815ad75 in ProcRenderDispatch (client=0x40046445) at render.c:2097 #23 0x08085e9f in Dispatch () at dispatch.c:454 #24 0x0806b71d in main (argc=9, argv=0xbfcea124, envp=Cannot access memory at address 0x4004644d ) at main.c:441 Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.5.3-5.fc10.i386 xorg-x11-drv-i810-2.5.0-3.fc10.i386 kernel-2.6.27.5-117.fc10.i686 firefox-3.0.4-1.fc10.i386 Host is a i686 Thinkpad X41T. 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 324961 [details] /etc/X11/xorg.conf
Created attachment 324962 [details] /var/log/Xorg.0.log Xorg log while X was frozen.
Output of curl -s 'https://bugzilla.redhat.com/attachment.cgi?id=324962' \ |egrep '^\(WW|EE\)' (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled. (WW) Disabling Keyboard0 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd0000009 (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): Register 0x70024 (PIPEASTAT) changed from 0x00000203 to 0x00000000 (WW) intel(0): PIPEASTAT before: status: VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS (WW) intel(0): PIPEASTAT after: status: (WW) intel(0): Register 0x68000 (TV_CTL) changed from 0x30000000 to 0x000c0c00 (WW) intel(0): Register 0x68010 (TV_CSC_Y) changed from 0x00000000 to 0x0332012d (WW) intel(0): Register 0x68014 (TV_CSC_Y2) changed from 0x00000000 to 0x07d30104 (WW) intel(0): Register 0x68018 (TV_CSC_U) changed from 0x00000000 to 0x0733052d (WW) intel(0): Register 0x6801c (TV_CSC_U2) changed from 0x00000000 to 0x05c70200 (WW) intel(0): Register 0x68020 (TV_CSC_V) changed from 0x00000000 to 0x0340030c (WW) intel(0): Register 0x68024 (TV_CSC_V2) changed from 0x00000000 to 0x06d00200 (WW) intel(0): Register 0x68028 (TV_CLR_KNOBS) changed from 0x00000000 to 0x00606000 (WW) intel(0): Register 0x6802c (TV_CLR_LEVEL) changed from 0x00000000 to 0x010b00e1 (WW) intel(0): Register 0x68030 (TV_H_CTL_1) changed from 0x00000000 to 0x00400359 (WW) intel(0): Register 0x68034 (TV_H_CTL_2) changed from 0x00000000 to 0x80480022 (WW) intel(0): Register 0x68038 (TV_H_CTL_3) changed from 0x00000000 to 0x007c0344 (WW) intel(0): Register 0x6803c (TV_V_CTL_1) changed from 0x00000000 to 0x00f01415 (WW) intel(0): Register 0x68040 (TV_V_CTL_2) changed from 0x00000000 to 0x00060607 (WW) intel(0): Register 0x68044 (TV_V_CTL_3) changed from 0x00000000 to 0x80120001 (WW) intel(0): Register 0x68048 (TV_V_CTL_4) changed from 0x00000000 to 0x000900f0 (WW) intel(0): Register 0x6804c (TV_V_CTL_5) changed from 0x00000000 to 0x000a00f0 (WW) intel(0): Register 0x68050 (TV_V_CTL_6) changed from 0x00000000 to 0x000900f0 (WW) intel(0): Register 0x68054 (TV_V_CTL_7) changed from 0x00000000 to 0x000a00f0 (WW) intel(0): Register 0x68060 (TV_SC_CTL_1) changed from 0x00000000 to 0xc1710088 (WW) intel(0): Register 0x68064 (TV_SC_CTL_2) changed from 0x00000000 to 0x4e2d1dc8 (WW) intel(0): Register 0x68070 (TV_WIN_POS) changed from 0x00000000 to 0x00360024 (WW) intel(0): Register 0x68074 (TV_WIN_SIZE) changed from 0x00000000 to 0x02640198 (WW) intel(0): Register 0x68080 (TV_FILTER_CTL_1) changed from 0x00000000 to 0x800010bb (WW) intel(0): Register 0x68084 (TV_FILTER_CTL_2) changed from 0x00000000 to 0x00028283 (WW) intel(0): Register 0x68088 (TV_FILTER_CTL_3) changed from 0x00000000 to 0x00014141 (WW) intel(0): Register 0x68100 (TV_H_LUMA_0) changed from 0x00000000 to 0xb1403000 (WW) intel(0): Register 0x681ec (TV_H_LUMA_59) changed from 0x00000000 to 0x0000b060 (WW) intel(0): Register 0x68200 (TV_H_CHROMA_0) changed from 0x00000000 to 0xb1403000 (WW) intel(0): Register 0x682ec (TV_H_CHROMA_59) changed from 0x00000000 to 0x0000b060 (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state. (WW) config/hal: no driver or path specified for /org/freedesktop/Hal/devices/pnp_WACf004 (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): underrun on pipe B! (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state.
I'm experiencing the same problem on a Supermicro C2SEA motherboard, G45/X4500HD, 8GB RAM, x86_64. Current software: kernel-2.6.29-0.137.rc5.git4.fc11.x86_64 xorg-x11-drv-i810-2.6.0-6.fc11.x86_64 lspci: 00:02.0 VGA compatible controller [0300]: Intel Corporation 4 Series Chipset Integrated Graphics Controller [8086:2e22] (rev 03) (prog-if 00 [VGA controller]) Subsystem: Super Micro Computer Inc Device [15d9:b880] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 26 Region 0: Memory at fe400000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at cc00 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable+ Address: fee0300c Data: 4191 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCIe advanced features <?> Kernel modules: i915
Created attachment 332963 [details] xorg.conf
Created attachment 332964 [details] Xorg.0.log Note: There are no errors in Xorg.0.log, dmesg or /var/log/messages when the problem occurs. If I strace the Xorg process when X freezes, it appears to respond to keyboard and mouse activity, but there is not other activity.
This happens to me 4-5 times a day on my thinkpad X41t with 915GM chipset. I have not gdb'd to confirm 100%, but symptoms are exactly the same- scrolling or clicking in firefox (sometimes tab switching, it appears?) leads to a mouse cursor that moves, and a system which can be ssh'd to, but which accepts no clicks from mouse or text entry from keyboard. This is a high severity bug, per https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity: "Problem due to crashes, loss of data, severe memory, leak, etc." and should be marked as such.
I encounter this quite often as well and I have lost work due to it. I'm on a Sony Vaio VGN-TZ150N laptop, 64-bit core 2 duo [root@duo jkf]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU U7500 @ 1.06GHz stepping : 2 cpu MHz : 800.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 2127.98 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: kernel-2.6.27.19-170.2.35.fc10.x86_64 xorg-x11-drv-i810-2.5.0-4.fc10.x86_64 lspci 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) It happens often, at least once a day and more if I'm heavily using Firefox. I cannot remember it failing on a system that hasn't been through a Suspend state at least once, but most of the time I'm using a system that's been suspended at least once so that may not be significant. It usually happens when running Firefox but the last time (a few minutes ago) it happened while running vi (with Firefox running but not the active window). In this case rather than the screen freezing the screen went black with horizontal rectangles of color seemingly vibrating on the screen. Again no keyboard command was recognized.
After the last round of (rawhide) updates, I've now gone 25 hours without an X lockup. It's the longest I've gone so far. Software versions: $ rpm -qa | grep "^kernel-2\|^mesa\|xorg-x11-drv-intel" | sort kernel-2.6.29-0.207.rc7.fc11.x86_64 mesa-dri-drivers-7.3-10.fc11.i586 mesa-dri-drivers-7.3-10.fc11.x86_64 mesa-libGL-7.3-10.fc11.i586 mesa-libGL-7.3-10.fc11.x86_64 mesa-libGLU-7.3-10.fc11.i586 mesa-libGLU-7.3-10.fc11.x86_64 xorg-x11-drv-intel-2.6.0-14.fc11.x86_64
Oh well... I went 68 hours and 47 minutes, but it locked up again.
Problem still occurs with: kernel-2.6.29-0.244.rc7.git5.nodebug.fc11.x86_64 mesa-dri-drivers-7.3-12.fc11.x86_64 mesa-libGL-7.3-12.fc11.x86_64 mesa-libGL-devel-7.3-12.fc11.x86_64 mesa-libGLU-7.3-12.fc11.x86_64 mesa-libGLU-devel-7.3-12.fc11.x86_64 xorg-x11-drv-intel-2.6.99.902-0.fc11.x86_64
This has become such an annoyance that I've switched to the vesa driver on my G45/X4500HD. Even though vesa doesn't support 1920x1200 (apparently maxes at 1600x1200), it's preferable to the multiple X lockups a day. I have to assume that no developers are actually running the intel driver on modern hardware (as opposed to a virtual machine) or this bug would be receiving more attention. I did find I could switch to vesa without a reboot with this procedure, if anyone is interested: 1- ssh to the X hung system, su to root 2- telinit 3 3- killall -9 Xorg 4- vbetool post 5- cp /etc/X11/xorg.conf.vesa /etc/X11/xorg.conf 6- telinit 5 In step 5, I just used a default generated xorg.conf, with the driver switched to 'vesa' from 'intel'. While I can get the vesa driver to start this way, the intel driver won't start without an actual reboot (that too seems broken). If there's any reason to believe the intel driver is stable enough for retesting, please update this bug.
Froze for me three times yesterday, losing critical information on one freeze. Different applications being run when the freeze happened but scrolling may be the common factor. Note that I ran Fedora 8 on this same hardware and never had this problem. I never ran Fedora 9 so I only know the bug was introduced after Fedora 8. Fedora now reminds me of Windows 3.1 in terms of stability. This driver should be marked as non-functional until a fix is found. Please raise the Severity of this bug (and hopefully the Priority will then raise as well).
[+cc: krh, airlied, katzj] I am the original reporter of the bug. I am still experiencing the problem on Rawhide now. F10 was released with this bug, and there has been no developer activity on this bug for the last 5 months. Given critical data loss, I would like to request Blocker status for F11.
This appears to be resolved now (for me) in rawhide: kernel-2.6.29.1-52.fc11.x86_64 libdrm-2.4.5-4.fc11.i586 libdrm-2.4.5-4.fc11.x86_64 mesa-dri-drivers-7.5-0.7.fc11.i586 mesa-dri-drivers-7.5-0.7.fc11.x86_64 mesa-libGL-7.5-0.7.fc11.i586 mesa-libGL-7.5-0.7.fc11.x86_64 mesa-libGLU-7.5-0.7.fc11.i586 mesa-libGLU-7.5-0.7.fc11.x86_64 xorg-x11-drv-intel-2.6.99.902-2.fc11.x86_64 Running with KMS and no xorg.conf (UXA).
Can anyone else confirm no longer seeing this in rawhide? that's enough to get me to upgrade...
Oh, you most definitely don't want to upgrade to rawhide with your X41T. bug 489938, bug 489907, and bug 489892 means I cannot close my laptop X41T lid, dock the laptop, or disable KMS. Basically I am getting a max uptime of 3 hours with my X41T. Firefox freezing is a moot point in rawhide for me. Although, YMMV.
I am having a similar problem, but I'm not sure it's the same one. Basically, I can reproduce this every time I do the following: 1. Open Firefox, or Gnome Help 2. Select some text 3. drag the text, such that the copy icon is the cursor at this point, the cursor stays like that, and clicks have no effect, I can't switch to a VT, and ctrl+alt+del doesn't do anything. I seem to have to do a hard power-off. I'm running on a ThinkPad T61 with nVidia Quadro NVS 140m. I have all rawhide updates installed as of the time of this posting. Should I open a separate bug for this?
Maybe this bug is related to bug #474624 ? Can you try a 2.6.29-based F10 kernel from koji and boot with 'pci=msi' and see if your problems disappear? Try this kernel here: http://koji.fedoraproject.org/koji/buildinfo?buildID=96454
This does not seem to be the same bug as 474624; specifically, there is no 'interrupt storm' and it doesn't happen randomly- it always happens when dragging or otherwise moving the cursor in firefox. (Nor have I seen any SATA or irq errors, but I haven't been looking very hard.) (Anyone have any thoughts on rawhide ATM? I'm getting really, really sick of rebooting 2-3 times a day because of this.)
Never mind that question about rawhide; particularly bug 489907 would seem to make it unusable for me on this hardware right now. It pains me that when I reinstall XP today for my exams I'll have made my computer *more* stable. That's really embarassing. :(
Just a workaround hint -- the hang being in drmIoctl() suggests that it would go away if you disabled DRM, which probably wasn't doing much for you on the early Intel chipsets anyway. Of course, the bug still needs to be fixed, and I might be wrong about the DRM causation.
I'll figure out how to disable DRM and report back as soon as I can (probably not until Friday given that I'd have to go a day or two without a hang to actually confirm that is a workaround.) In the meantime, I'd note that: "Of course, the bug still needs to be fixed" is not necessarily true; it'd be a perfectly legitimate choice on RH's part to say 'there is an entirely new driver for this HW in F11 so we've chosen not to expend resources on fixing the old driver. Sorry.' possibly followed by 'if upstream fixes it, we'd be happy to package and ship that.' If that is actually the case, though, it'd be best to be up front about this, WONTFIX this bug, and tell people to focus their energies upstream or on workarounds rather than wondering when this will be fixed in F10.
Um...the bug's currently set to RAWHIDE, I was working on the assumption it's current in Rawhide. Saikat, how are things for you at present? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #25) > Um...the bug's currently set to RAWHIDE, I was working on the assumption it's > current in Rawhide. Saikat, how are things for you at present? Due to other rawhide bugs, my laptop needs to be rebooted every ~3 hours; since this bug takes ~1-2 days to manifest itself, I cannot test it on rawhide. Comment #19 however states that this bug exists in rawhide as of 4/14/09.
is that actually the same bug? the description sounds somewhat different. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hmm. I don't know. The original bug is very non-deterministic, while comment 19 sounds deterministic. James, would it be possible to get a backtrace? Or anyone else on rawhide who had the bug originally?
Adam, I was going on the grounds of comment #16 (by Mace Moneta) in saying it wasn't a rawhide issue. I can't confirm/deny since I haven't installed rawhide because of Saikat's comments. For those following along at home, do *not* use NoDRI; that hangs almost immediately (never gets through GDM) rather than hanging every several hours. ;)
While this problem doesn't occur in rawhide, there's a similar issue when running KMS+UXA (Bug 496516). You can boot with nomodeset and run X with EXA and it's stable. At least for my G45/X4500HD systems.
(In reply to comment #28) > Hmm. I don't know. The original bug is very non-deterministic, while comment 19 > sounds deterministic. James, would it be possible to get a backtrace? Or anyone > else on rawhide who had the bug originally? my problems was actually bug 489101 It has been solved by an update to xorg-x11-drv-nouveau.
If a possible fix is made I'd be willing to try it (Fedora 10, 64 bit core2 duo, sony TZ-150N laptop) I can usually get it to fail by 1. suspending to memory, 2. unsuspending, and 3. viewing twitter.com in Firefox and scrolling. It fails in other instances as well but this one seems the most reproducable.
For anyone casually reading this bug and wondering if it's the same one you're seeing: if you don't have Intel 915 or 945 hardware, then the answer is no.
So what's happening here, at least according to the initial backtrace, is that we're attempting to copy some data back into host memory so the CPU can access it, and in order to do so we're trying to wait for the GPU to complete whatever rendering it's currently doing. We emit a DRM command that should tell the GPU to send an interrupt when it's gone idle, and then emit another DRM command to wait until we get that interrupt. The problem is that the wait command is hanging forever, for some as yet unknown reason. Either the chip really is wedged, or there's some logic error in the DRM preventing us from waking up. Note that this path _only_ happens with EXA. When using KMS, UXA is the default, so you should never hit this. Bug 496516 (which happens with UXA) is superficially similar in that it looks like a lockup, but it's a fundamentally different failure mode. That bug happens as we're trying to _start_ rendering something, this one happens when we're trying to make sure it's completed.
Just to clarify a salient point from Adam's comment: what this means is that the bug exists in both F10 and Rawhide, but is mostly hidden in Rawhide because we're now defaulting to KMS / UXA. However, if you ran Rawhide with 'nomodeset', you could still hit this bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
GPU hangs (X cursor moves but nothing responds) need intel_gpu_dump output for debugging.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Confirming this bug exists in Fedora 11, and latest Rawhide (F12). xorg-x11-drv-intel-2.7.0-7.fc11.i586 kernel-2.6.30-0.97.rc8.fc12.i586 Triggered when I was writing an email in gmail. (was not scrolling)
I too am having problems with FC11 hanging, while only the mouse pointer move around. I have nothing listed as errors in my Xorg log files. (Strange...) Anyway system is HP Compaq dc7100 Dual-core Intel Pentium 4 3.2GHz 800MHz Bios: vendor: Hewlett-Packard version: 786C1 v01.05 (06/16/2004) 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04) 00:02.1 Display controller: Intel Corporation 82915G Integrated Graphics Controller (rev 04) product: 82915G/GV/910GL Integrated Graphics Controller [8086:2582] vendor: Intel Corporation [8086] bus info: pci@0000:00:02.0 version: 04 width: 32 bits clock: 33MHz capabilities: Power Management, vga_controller, bus mastering, PCI capabilities listing, extension ROM configuration: driver: i915 latency: 0 resources: irq: 16 memory: cfe00000-cfe7ffff ioport: 1800(size=8) memory: e0000000-efffffff(prefetchable) memory: cff00000-cff3ffff I didn't see the problem in 8 at all, intermittantly in fc10, and 5-9 times per day in fc11.
I also get this in my messages file: Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_object_pin_and_relocate] *ERROR* No GTT space found for object 26 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_object_pin_and_relocate] *ERROR* No GTT space found for object 26 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_object_pin_and_relocate] *ERROR* No GTT space found for object 26 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_object_pin_and_relocate] *ERROR* No GTT space found for object 26 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_object_pin_and_relocate] *ERROR* No GTT space found for object 26 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_object_pin_and_relocate] *ERROR* No GTT space found for object 26 Jun 28 04:43:51 localhost kernel: [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22 I have to reboot my system to clear the errors as well as get functionality back to my desktop. Yes please elevate this issue to the highest level.
yours appears to be a different issue, going by your output. please file a new bug. Do you use any 3D applications, or the 3D desktop?
Adam - Yes, I was using cairo-dock Opengl when this error was occurring.
figures. yes, file a new bug (and check if it happens without using cairo-dock, and include that info in the new bug).
The bug occurs on my Toshiba Satellite A200. I have GM965 and use the i915 module. Sometimes it crashes when scrolling in Firefox, but the bug seems to trigger when using other applications as well - like gxine. This morning I left my notebook for 30-40 minutes and when I came back it had crashed in exactly the same way. Only the mouse is moveable when this crash occurs, the whole graphic environment is "frozen" like a static image. When I switch to virtual terminals and back to X, the whole screen is white and only the cursor is there, still moving. Before F11 was released I was running rawhide and everything was OK. But I made a big upgrade after the stable release and now the bug occurs 5-6 times a day. I have updated all the xorg related packages and I don't using anything from the testing repo.
I have lately be restarting my laptop each time I begin serious work rather than depending on closing the lid and suspending it and un-suspending it before work. If I run my Sony Vaio VGN-TZ150N in this way I've not seen the bug. However it's not convenient to have to reboot each time. If everyone on this CC list went to this bug report and voted for this bug using all their available votes then it may have enough votes to get the attention of someone who could fix it or come up with a workaround until it's fixed.
No-one pays any attention to vote counts at present, they're not used for anything. I'm not entirely convinced these are all the same problem, actually. I think at least one cause for one of this type of problem was discussed on -devel-list and fixed a few months back. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
This appears to be resolved in F12.
we can probably close the report, then, as not much work is likely to be done on f11's intel any more, unfortunately. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This problem happens in Fedora 16... Once in a while during scrolling in Firefox, the system hangs, nothing except reboot works. Nothing shows up in dmesg or var/log/messages. Is there a fix?
almost certainly not the same bug. this was an ancient bug in the intel graphics driver. much better to file a new report for your issue. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #51) > This problem happens in Fedora 16... > Once in a while during scrolling in Firefox, the system hangs, nothing except > reboot works. Nothing shows up in dmesg or var/log/messages. > Is there a fix? So, did you file another bug for your issue? I am experiencing the same problem here.
(In reply to comment #53) > (In reply to comment #51) > > This problem happens in Fedora 16... > > Once in a while during scrolling in Firefox, the system hangs, nothing except > > reboot works. Nothing shows up in dmesg or var/log/messages. > > Is there a fix? > > So, did you file another bug for your issue? I am experiencing the same > problem here. well no.i had to look into other more pressing matters and didn't get a chance to do so. Actually I had forgotten about this and recently have switched to Opensuse 12.1 because Fedora 16 support for ATI Radeon X2300 is crappy. I tried to set up the proprietary drivers for ATI (because the opensource drivers had heat up issues) but didn't work even after a lot of tweaks. You can file a new bug report because I don't have a Fedora 16 system anymore. Sorry.
Bug still alive in Fedora 17 with Firefox 13.0.1 and Intel 845GV chipset on E-Machines model T2885. As others have been instructed, I posted this as a new bug. See bug839400
Current software: Fedora Linux 17 (32-bit) w/ LXDE only xorg-x11-drv-intel-2.19.0-5.fc17 (32-bit) kernel-3.4.4-5.fc17 (32-bit) firefox 13.0.1 (32-bit)
I had opened #818376 before. Though the problem has not happened with me for a while now, maybe some bugs can be closed as dup's.