Created attachment 37682 [details] /var/log/dmesg I use the kernel radeon driver with a Radeon Mobility R300 on a Toshiba laptop. The driver in 2.6.32 works fine and also the non-KMS driver in 2.6.34. However, when I enable the KMS driver (and disable the framebuffer drivers) in the 2.6.34 kernel, my computer freezes after a while of using X. If I don't start X the new KMS driver works fine. The outputs of dmesg, Xorg.0.log, and glxinfo are attached separately. In the case when I collected the above output, the bug manifested when I changed back to the virtual desktop of a running audio application (foobar2000 under wine). Access to the USB port with an external hard disk died at that moment. Usually the entire computer freezes (including keyboard, mouse, etc), but sometimes the bug seems to just disable the USB system. It only happens when the KMS driver is active so I file the bug here and not at the USB system or elsewhere.
Created attachment 37683 [details] /var/log/Xorg.0.log
Created attachment 37684 [details] glxinfo output
Created attachment 37685 [details] 2.6.34 kernel config (gentoo-sources-2.6.34-r1)
The card is Radeon 200, sorry for the typo.
I have the exact same card as you and kms works fine for me with the 2.6.34. I am using the latest git versions of mesa, libdrm, and xf86-video-ati, and Xorg v1.8.2. Updating those packages should fix your problem. If you are using Gentoo, an easy way of installing the git versions is to use layman and the X11 overlay.
Hmm... good to know that it works for someone else! Hopefully I can fix it on my laptop too. What versions of these packages do you use, Tom Stellard? Mine are as follows: xorg-server 1.7.7 libdrm 2.4.20 xf86-video-ati 6.13.0 mesa 7.8.2. They meet the requirements from the radeon KMS X.org information page. The only other thing that I could think of that might be to blame is that I forgot to remove the vga=791 line from the kernel parameters at boot. Could that cause the KMS driver to freeze up after a while of using DRI?
A little update... I've tried out all the different kernel options that I could think of as well as enable USB debugging output, usb_storage debugging output, ATA system debugging output, SCSI debugging output, Magic SysRq, but I can't get any reasonable traces out. The symptoms are very predictable, however. I had thought it might be same bug as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/509273?comments=all however setting pci=nomsi does not help at all in my case. In brief: If I'm using USB for e.g. external hard disk or mobile phone internet dialup, or if I play audio, and then switch to the X output with KMS modesetting enabled, either immediately or after a short while (a minute or so), all the USB devices stop working. Sometimes, the whole computer freezes and nothing works any more (not even the console or the Magic SysRq keys). If I disable KMS for the radeon driver, everything is working fine. I'm not doing any fancy things such as software suspend or hibernate. Well... if there's some way I can provide better output to help identify the cause of this problem, let me know, thanks!
I've tried out whether some kernel command-line options can solve my problem. Here's what I've found (running with the kernel that uses the KMS driver): radeon.agpmode=-1 does not fix the problem agpmode=-1 does not fix the problem radeon.modeset=0 solves the problem So I'm using that in the kernel arguments now. Of course there's no KMS support now and the console framebuffer looks very plain during boot and is absent after X has come up. But it works at least.
Another option that I've tried also didn't help: pci=nomsi did not fix the problem.
Can you try 2.6.35?
Running kernel 2.6.35-gentoo-r1 now, and I am unable to replicate the bug here. I will keep running this kernel now, and if the bug should manifest again, I'll be back! Thanks for apparently having fixed it in 2.6.35.
Created attachment 37849 [details] 2.6.35 kernel config (gentoo-sources-2.6.35-r1)
-- 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/146.
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.