Description of problem: Version-Release number of selected component (if applicable): How reproducible: Every time I use opengl or compositing Steps to Reproduce: 1. Start an opengl program 2. Watch it crash and burn within seconds to a couple of minutes 3. Actual results: Crash, hard lockup Expected results: Additional info:
Nexuiz lock ups the computer within 1-2 minutes giving [driAllocateTexture:635] unable to allocate texture Ouch! vram_validate failed nexuiz-glx: r300_mem.c:820: bufmgr_classic_post_submit: Assertion `!batch_bo->pending_count' failed.
Extreme Tuxracer crasches, but does not lock up the system, with: Internal error or hardware lockup: bo_map: buffer is still pending.
This could be a duplicate of Bug 465760 ...
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. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Ok, here comes the Xorg.0.log; This is with nomodeset passed to the kernel and no xorg.conf. Nexuiz seems to be much more stable now as does compiz. Extreme tux racer still locks up hard (se attached log).
Created attachment 324569 [details] Xorg.0.log without xorg.conf and with nomodeset
Created attachment 324570 [details] etracer > etracer.log 2>&1 No clues in this one i'm afraid
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
There hasn't been any movement on this bug for a while, so I thought I'd add my experiences. I'm finding anything that uses OpenGL will lock the entire computer up (no mouse, no keyboard, no ssh connections). I've tried several apps including compiz, glxgears, and a couple different games, including tux racer. All with the same result; a total lock after just a couple seconds. I've tried booting with nomodeset, but had the same result. I'm using a R480 with xorg-x11-drv-ati-6.9.0-61.fc10.x86_64
(In reply to comment #10) > There hasn't been any movement on this bug for a while, so I thought I'd add my > experiences. > > I'm finding anything that uses OpenGL will lock the entire computer up (no > mouse, no keyboard, no ssh connections). I've tried several apps including > compiz, glxgears, and a couple different games, including tux racer. All with > the same result; a total lock after just a couple seconds. > > I've tried booting with nomodeset, but had the same result. > > I'm using a R480 with xorg-x11-drv-ati-6.9.0-61.fc10.x86_64 I am seeing that too. Hard and immediate system locks. I must use the reset button to recover. It is likely going to drive me back to Fedora 9 soon since it seems to happen at least once per day when I invoke something OpenGL without meaning to. xorg-x11-drv-ati-6.9.0-63.fc10.x86_64 # lspci -vv 05:00.0 VGA compatible controller: ATI Technologies Inc R480 [Radeon X850XT Platinum (PCIE)] (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device 0b12 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, Cache Line Size: 16 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at dffe0000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at e000 [size=256] Expansion ROM at dffc0000 [disabled] [size=128K] Capabilities: [50] 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: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <2us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Address: 0000000000000000 Data: 0000 Kernel modules: radeon 05:00.1 Display controller: ATI Technologies Inc R480 [Radeon X850XT Platinum (PCIE)] (Secondary) Subsystem: ATI Technologies Inc Device 0b13 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, Cache Line Size: 16 bytes Region 0: Memory at dfff0000 (64-bit, non-prefetchable) [size=64K] Capabilities: [50] 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: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <2us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
(In reply to comment #10) > I'm finding anything that uses OpenGL will lock the entire computer up (no > mouse, no keyboard, no ssh connections). I've tried several apps including > compiz, glxgears, and a couple different games, including tux racer. All with > the same result; a total lock after just a couple seconds. > > I've tried booting with nomodeset, but had the same result. My problem is exactly like he described. glxgears locks up after a few seconds. I came from Fedora 8, that worked well. I've a clean Fedora 10 install, no /etc/X11/xorg.conf I'm using R480 [Radeon X800 GTO (PCIE)] with xorg-x11-drv-ati-6.9.0-63.fc10.i386
Same problem here with glxgears (and other GL apps). Using xorg-x11-drv-ati-6.9.0-63.fc10.i386 on an ATI Radeon X800 XL (R430) (PCIE) card in an Athlon64-based system with nforce4 chipset. Logs show nothing strange, but system locks up hard.
Same problem here with ATI redeon X700 Mobility, up to date Fedora 10 i386. PCIE / 64MB Pentium M740 + Centrino Laptop reference: Acer Aspire 5502WXMi xorg-x11-drv-ati-6.9.0-63.fc10.i386 I have no xorg.conf. I tried with a Xorg.conf from my previously working F9 (upgrade from F9 to F10) to force radeon driver and get the same lock up. Then tried a fresh install of F10 without xorg.conf and with my working F9 xorg.conf: same lock up. Logs show nothing, but running a GLX app (ie glxgears or enabling desktop effects) locks up the computer after 2 or 3 seconds of working time. The lock up is total: no keyboard/mouse/input device working, no ping response, no ssh, no HDD light anymore. Only a hard reset or power off "fixes" the issue. It used to work like charm until I upgraded from Fedora9 to Fedora10 2 days ago. Note that I never use GLX apps, I just wanted to try the Desktop Effects on F10, so I don't know if the issue was happening on F9 just before upgrading: I'm sure that it used to work a month or so ago on F9. I found several other maybe-related-bugs: https://bugzilla.redhat.com/show_bug.cgi?id=476590 https://bugzilla.redhat.com/show_bug.cgi?id=474963 http://bugs.freedesktop.org/show_bug.cgi?id=19008
forgot about my kernel: 2.6.27.12-170.2.5.fc10.i686
I did some testing and comparison with an up-to-date Fedora9 installation (xorg-x11-drv-ati-6.8.0-19.fc9.i386 with kernel-2.6.27.9-73.fc9.i686 ) yesterday on the same computer and found out: - 2D movie watching on F10 is slower than F9: watching a movie gets really annoying because of many frame dropping and glitches (video and sound stops for half a second) just as if computer was overloaded but it's not the case (just a display issue) - moving windows is slow on F10 and it takes time to redraw screen (not much time but you can see it) - 3D is 10 times slower on F10 than on F9: glxgears displays 200fps before freezing the computer (2000fps on F9) So 3D definitely works on F9 (up-to-date fresh install) and all is OK with Video and 2D display. So I downgraded to F9 for now and will install F10 on a new partition on my HDD to make some testing from time to time. Hope those informations will be useful.
Davis, Dag, Could you try with nomodeset in the kernel command-line ? Alternatively, could you try the latest xorg-x11-drv-ati build in Koji : http://koji.fedoraproject.org/koji/buildinfo?buildID=80819 Thanks in advance
Hi François, I tried "nomodeset" at boot, and: - it deactivated the 'graphical "solar" boot' - 2D is faster - 3D is only 2 times slower than on Fedora9 (so it's much better but still it sometimes hangs for a few 1/10th of a second (lag) ) - glxgears doesn't freeze the computer (at least for 5 minutes) when the window is at it's normal startup size (which may be 200x200), I tried to hide/unhide, move the window, minimize, etc... no freeze. - BUT: glxgears freezes the computer if its window is maximized (not fullscreen) and you hide/unhide the glxgears' window with some other software (I used a Firefox maximized window to hide/unhide the glxgears' maximized window): after a few hide/unhide the computer completely freezes everytime, sometimes displaying a completely black screen. This issue is not reproducible on Fedora 9 (same computer, with versions I've already given). - I did not test fullscreen glx app So, nomodeset definitely improves stability and speed of the 2D and 3D display with radeon driver for me. I'll try the Koji driver later this week-end probably. bye for now
Hi again! I tried the Koji package (xorg-x11-drv-ati-6.10.0-2.fc10.i386.rpm) and (without nomodeset): - glxgears freezes the computer "only" after the mouse or a window gets over it (partially or completely) so it's kind of an "improvement" - no improvement on speed (2D or 3D) with nomodeset, it's the same as the F10 official radeon driver (see my post above this one). So, it's a bit better than the official driver without nomodeset, but it's still unusable. bye for now.
Hello, I am having a hard time too with the ati open driver in Fedora 10 - AMD64. My card is a ati x600. When I boot the system, it goes somewhat normal (a little slow but usable). But as time and use goes (15 minutes or less sometimes) it begins to lock the system up (mouse freezes and returns). Sometimes the freezes lasts over a minute, and return. Nothing wrong in logs. When the machine is "freezed", I can ssh there, and nothing seems wrong, so I suppose the bug is in Xorg only. Here is my excellent glxgears results: 374 frames in 5.0 seconds = 74.653 FPS 925 frames in 5.0 seconds = 184.671 FPS 364 frames in 5.0 seconds = 72.698 FPS 359 frames in 5.0 seconds = 71.771 FPS 189 frames in 7.0 seconds = 26.899 FPS 113 frames in 6.9 seconds = 16.416 FPS 7 frames in 6.0 seconds = 1.160 FPS 4 frames in 6.0 seconds = 0.666 FPS 11 frames in 6.1 seconds = 1.804 FPS 5 frames in 6.0 seconds = 0.829 FPS 6 frames in 6.0 seconds = 0.998 FPS With a ubuntu live cd I can get over 1300 fps as a glxgears result. Is there anything I can do?
ufa, this is probably a different bug, please file it separatedly. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Maybe, but I am having unstability too, i.e., I just launch some opengl game and in about 20 seconds it freezes my X or reboots the machine :(
Just upgraded to F11 and the issues keep on.
I have the same problem on F11. Starting Google Earth crashes with the splash page still showing with this message on the terminal: CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7 CS section end at (r300_cmdbuf.c,emit_cb_offset,264) interesting about ...offset,254 and offset,264 above - typo somewhere? kernel 2.6.29.4-167.fc11.x86_64 xorg-x11-drv-ati-6.12.2-14.fc11.x86_64 Card is: (--) PCI:*(0@1:0:0) ATI Technologies Inc RV505 CE [Radeon X1550 64-bit] rev 0, Mem @ 0xd0000000/268435456, 0xfe9f0000/65536, I/O @ 0x0000b000/256, BIOS @ 0x????????/131072 This is a fresh install, no xorg.conf. I upgraded from F10 because GE (and Second Life) had a different problem...
Ah, got this: BUG: unable to handle kernel NULL pointer dereference at 00000000000003da IP: [<ffffffffa005d5d2>] radeon_gem_ib_free+0x21/0xc4 [radeon] PGD cccf7067 PUD ccd7a067 PMD cccd7067 PTE 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/virtual/net/virbr0/statistics/collisions CPU 0 Modules linked in: vfat fat fuse ipt_MASQUERADE iptable_nat nf_nat rfcomm bridge stp llc bnep sco l2cap sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath kvm_intel kvm uinput snd_hda_codec_realtek snd_hda_intel snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_hda_codec snd_cs8427 snd_hwdep snd_ac97_codec snd_pcm snd_timer ac97_bus snd_i2c snd_mpu401_uart snd_rawmidi snd_seq_device snd i2c_i801 r8169 iTCO_wdt iTCO_vendor_support pata_pdc2027x soundcore snd_page_alloc btusb bluetooth pcspkr usb_storage mii ata_generic pata_acpi radeon drm i2c_algo_bit i2c_core [last unloaded: microcode] Pid: 3036, comm: googleearth-bin Not tainted 2.6.29.4-167.fc11.x86_64 #1 G33T-M2 RIP: 0010:[<ffffffffa005d5d2>] [<ffffffffa005d5d2>] radeon_gem_ib_free+0x21/0xc4 [radeon] RSP: 0018:ffff8800ccd1bcc8 EFLAGS: 00210246 RAX: 0000000000000010 RBX: 000000000000000a RCX: 0000000000000000 RDX: ffff8800ccd1bdd8 RSI: 00000000fffffff2 RDI: ffff8800ccd1bd28 RBP: ffff8800ccd1bcf8 R08: ffff880028029af0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012cc70800 R13: ffff8800ccd1bd28 R14: 0000000000000000 R15: ffff88012cc70e38 FS: 0000000000000000(0000) GS:ffffffff817b7000(0063) knlGS:00000000f7fa6700 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 00000000000003da CR3: 00000000ccc99000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process googleearth-bin (pid: 3036, threadinfo ffff8800ccd1a000, task ffff8800ccda5c00) Stack: ffff88012cc70800 ffff88012d0ad000 0000000000000000 ffff88012cc70800 00000000fffffff2 ffff880105c99800 ffff8800ccd1bdb8 ffffffffa005fb29 ffff8800ccd1bd38 0000000000000004 0000000000000524 ffff8800ccc86000 Call Trace: [<ffffffffa005fb29>] radeon_cs_ioctl+0x35e/0x3ad [radeon] [<ffffffff811828b7>] ? avc_has_perm+0x5c/0x71 [<ffffffff810b3b5f>] ? unmap_vmas+0x826/0x83b [<ffffffffa005f7cb>] ? radeon_cs_ioctl+0x0/0x3ad [radeon] [<ffffffffa0012b7e>] drm_ioctl+0x20e/0x2c1 [drm] [<ffffffff810c0239>] ? free_pages_and_swap_cache+0x26/0x80 [<ffffffff810cb93f>] ? virt_to_head_page+0xe/0x31 [<ffffffff811843a7>] ? file_has_perm+0x83/0x8e [<ffffffffa00727ed>] radeon_compat_ioctl+0x6c/0x83 [radeon] [<ffffffff81109f85>] compat_sys_ioctl+0xc8/0x367 [<ffffffff810dca60>] ? path_put+0x22/0x26 [<ffffffff81088462>] ? audit_syscall_entry+0x11e/0x14a [<ffffffff813ab88d>] ? trace_hardirqs_off_thunk+0x3a/0x6c [<ffffffff81034bb7>] sysenter_dispatch+0x7/0x4b [<ffffffff813ab851>] ? trace_hardirqs_on_thunk+0x3a/0x3c Code: 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 56 41 55 41 54 53 48 83 ec 10 0f 1f 44 00 00 48 8b 1f 48 8b 57 30 45 31 f6 49 89 fd <4c> 8b a3 d0 03 00 00 49 8b 84 24 28 06 00 00 48 8b 08 48 39 51 RIP [<ffffffffa005d5d2>] radeon_gem_ib_free+0x21/0xc4 [radeon] RSP <ffff8800ccd1bcc8> CR2: 00000000000003da ---[ end trace a689487942536e2c ]---
Sami, Could you file a bug against xorg-x11-drv-ati on F11 ? Please include me in CC. Thanks --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Opened bug 504631 against xorg-x11-drv-ati on F11.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.