Created attachment 32618 [details] Kernel log (dmesg) After starting Celestia under KMS on integrated Radeon RS780 card, I get hard reboot. I have tried looking in realtime (using tail) at /var/log/messages and /var/log/Xorg.0.log while starting Celestia, but there is nothing before reboot. Celestia starts, first frame is rendered (with Sun), then it looks for about 5 seconds like it is freezed (but other apps works, only Celestia freezes) and then suddenly black screen and hard reboot. I have latest Git snapshots of libdrm, mesa and xf86-video-ati from 2010-01-13 and kernel 2.6.33-rc4. I have no such problems under UMS. 3D acceleration under KMS works (even desktop effects in KDE 4), but there is this hard reboot problem (I tried it even with disabled desktop effect, but this hard reboot after starting Celestia is still there).
Created attachment 32619 [details] Xorg.0.log
Btw. these log files has been copied before starting Celestia. Celestia is opensource 3D space simulator/planetarium: http://www.shatters.net/celestia/
Update: Now I can replicate it also under UMS, but instead of immediate reboot (like under KMS) I can play with Celestia for some time (there are no freezes like in KMS), but then I also get black screen and reboot.
If you disable virtualization in your BIOS, do you still get the hard reboots? I'm also suddenly experiencing sporadic reboots or shutdowns on RS780 in various graphics applications, possibly after flipping virtualization support setting in my BIOS (Gigabyte GA-MA78G-DS3H motherboard with version F2 BIOS). All problems have occurred either with OpenGL applications or mplayer (xv output); even heavy computation does not otherwise trigger a reboot or shutdown. I'm seeing this on multiple kernels from Ubuntu 2.6.32-26 to stable 2.6.36.1, with both xorg-edgers PPA and standard Ubuntu radeon drivers (using ppa-purge). However, I'm still investigating if I'm just having a hardware (motherboard or power supply) issue; this machine has been in heavy use for a couple of years.
Can you try with recent r600g driver ?
Created attachment 44396 [details] Output of lspci -vv
xf86-video-ati 6.14.0-1 xorg-server 1.9.4-1 Hi, I was having trouble with an instant hard reboot at the moment I go to fullscreen in a video player (vlc, mplayer). The comment above about disabling virtualization in the BIOS solved the problem, no reboot occurs. My Hardware is similar: Gigabyte GA-MA78G-DS3H Mainboard ( I tried with the onboard vga (Radeon HD 3200) and with a dedicated Radeon 4850. Right now I am using xf86-video-ati 6.14.0, xorg-server 1.9.4-1 and linux kernel 2.6.37.3 on x86_64 Athlon Dual Core Processor 4850e. The reboots occurred with different versions of the software stack, I didn't have this problem for some time now, even with virtualization enabled. I doubt that it's a kernel problem, because it happened with different kernel versions before. Does anyone have an idea how to debug this and how to provide better infos? The log files provide no info of the crash, the reboot happens immediately. Best regards!
Sorry, disabling the virtualisation didn't resolve the problem, it just took 10 seconds more for the reset. But I just switched to kernel 2.6.32.32 and I got no reset playing a video in fullscreen. I read in a different bug about the same MB that a hardware / power failure is suspected, which I doubt in my case. I have no problems with this PC, the capacitors on the MB look good, I don't have any power sucking devices equipped and the Power-Supply is sufficient.
If I unload the module edac_mce_amd, no reset happens when playing fullscreen video. This is with kernel 2.6.37.3 #> rmmod edac_mce_amd
apparently, the edac_mce_amd module had nothing to do with it, I experienced another reboot in fullscreen video. I now upgraded to latest mesa, libdrm and xf86-video-ati from git and didn't experience the reboot for now. But how is it possible that such a reboot happens in my case? Shouldn't there just be a kernel oops?
Closing reopen if you still have issue with r600g ie gallium driver. As side note, reset might be the outcome of the gpu writing to something that trigger computer reset. I have seen that in the past.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.