Created attachment 38743 [details] dmesg after the fail Apparently random GPU lockup (ati r300), with X.org freeze. It happens more frequently if I compile and I switch over many applications (firefox, terminal, opera). Attached there is the dmesg after the fail (I could continue to work on others console - ctrl+alt+f1,2,3..).
I forgot system spec: Kernel: 2.6.35.4 X.org-server: 1.9.0 xf86-video-ati: 6.13.1 PowerPC 7447A, PowerBook G4.
Created attachment 38744 [details] Xorg log after GPU lock It re-happens, so I saved also Xorg.log.
Does radeon.agpmode=1 or radeon.agpmode=-1 help?
(In reply to comment #3) > Does radeon.agpmode=1 or radeon.agpmode=-1 help? This happens with radeon.agpmode=-1 on the kernel boot command line. Without it, the kernel doesn't boot (it freeze, without eth connection and monitor freeze on some openfirmware specification - I have no serial - when switching from openfirmware to kernel itself, I think).
(In reply to comment #4) > This happens with radeon.agpmode=-1 on the kernel boot command line. Without > it, the kernel doesn't boot (it freeze, without eth connection and monitor > freeze on some openfirmware specification - I have no serial - when switching > from openfirmware to kernel itself, I think). How about agpmode=1? There's an issue with higher transfer rates that Ben Herrenschmidt is working on fixing.
Created attachment 38780 [details] error with agpmode=1 When system load radeon modules with agpmode=1, I had this error (fortunately I found it in /var/log/messages.log at next boot). The lock happens more frequently, and give a black screen with no possibilities to switch to another console. There isn't operations which cause this lock more frequently than another: last time (this error) happens when I was scrolling an Opera window.
(In reply to comment #6) > Created an attachment (id=38780) [details] > error with agpmode=1 > > When system load radeon modules with agpmode=1, I had this error (fortunately I > found it in /var/log/messages.log at next boot). > > The lock happens more frequently, and give a black screen with no possibilities > to switch to another console. There isn't operations which cause this lock more > frequently than another: last time (this error) happens when I was scrolling an > Opera window. Another thing, which happens both with -1 and 1: at time of loading modules from my fs (yaboot->initramfs->my system->load modules) sometimes the kernel freeze. I don't know where (unfortunately there aren't any log) but I think it's related to radeon. I need from 5 to 10 try to load properly and continue boot, otherwise I need to force shutdown.
Uhm, black screen was here also with agpmode=-1, but I have no error message in logs. I was playing (for the first time) with GLX version of cairo-dock. So now for me both modes doesn't do any difference :(
I'm not 100% sure (the radeon initialization output from dmesg could confirm), but I suspect this is a duplicate of bug 28402.
Created attachment 54296 [details] Dmesg crash This also occurs to me on my system, a PowerPC 7447A PowerMac G4 with an ATI Radeon 9800 Pro AGP (128MB). Using the packages from Debian Squeeze Backports (7.10.3) with a near-Vanilla 3.1.0 kernel with radeon DRM modules built in along with firmware. However, for me it crashes about 10-20 seconds when glxgears is running, or it instantly crashes when I attempt to move or resize a window in WindowMaker. Setting agpmode=-1 fixes the problem for me.
(In reply to comment #10) > However, for me it crashes about 10-20 seconds when glxgears is running, or it > instantly crashes when I attempt to move or resize a window in WindowMaker. > > Setting agpmode=-1 fixes the problem for me. Given your slightly different symptoms, I think we have to assume it's not exactly the same problem. Please file your own report with all the relevant information (at least dmesg output pertaining to agp/drm/radeon). BTW, if you can narrow down where exactly in r300_asic_reset() the machine check happens, maybe we can fix that.
FWIW, http://lists.freedesktop.org/archives/dri-devel/2012-January/017932.html should increase the chance of recovering from a GPU lockup, or at least being able to reboot cleanly, on a big endian host.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/156.
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.