When I run /usr/lib/xscreensaver/hufo_tunnel I get a solid freeze (have to power off, no sysrq) as soon as I move the mouse (touchpad). If I don't touch it runs nicely for minutes. I tried to remove RADEONSetDynamicClock and RADEONForceSomeClocks as suggested in bug 11434 but it doesn't seem to help. Versions: xserver-xorg-video-ati 6.7.192-1ubuntu1 xserver-xorg-core 1.3.0.0.dfsg-12ubuntu3 (includes backports from 1.4) libgl1-mesa-dri 7.0.0-0ubuntu2 (and 7.0.1 in gutsy) It happens both on kernel 2.6.20 (feisty) and 2.6.22 (gutsy tribe 5). I can try going back to previous versions and try to narrow it down. Should I focus on the ati driver or xorg-server?
Created attachment 11370 [details] Xorg.0.log X700 There is nothing in the server log, it probably freezes to quickly anyway. I tried ssh-ing in and watching /proc/kmsg but saw nothing special, also using debug=1 on the drm module. The card is: ATI Technologies Inc Radeon Mobility X700 (PCIE)
ati 6.6.3 works fine, but 6.6.192 freezes. (argh - I just cleaned away all these intermediate builds I had laying around a few days ago...)
are you using different versions of mesa with each driver?
does reverting commit 31c1be420d5277dd15505bd73e6144827a0580cd help?
(I was using both 6.6.3 and 6.6.192 with the same mesa 7.0.0) Reverting commit 31c1be420d5277dd15505bd73e6144827a0580cd works ! Thanks for the quick response!
(In reply to comment #5) > (I was using both 6.6.3 and 6.6.192 with the same mesa 7.0.0) > > Reverting commit 31c1be420d5277dd15505bd73e6144827a0580cd works ! Thanks for > the quick response! > does reverting that commit cause a freeze when moving the mouse between heads if you enable dualhead?
I don't have a second screen handy, so it will take some time before I can test it.
I am struggling with dual-head, but I got the desktop cloned on the two displays at least. They have different display resolutions, the internal is 1680x1050, so on the external display (1280x1024) the right hand side of the desktop was cut-off. When I moved the cursor so far as to quit the 1280 screen I got a solid freeze.
(In reply to comment #8) > When I moved the cursor so far as to quit the 1280 screen I got a solid freeze. 'Solid freeze' as in the machine doesn't respond to ping?
> 'Solid freeze' as in the machine doesn't respond to ping? I didn't try ping (I had no screen for the other computer...) but it didn't react to sysrq or power-button, so I had to keep the power button down for 10s to power-off.
I verified it was a solid system freeze by having an aplay running in a loop on a virtual console, which stopped. After putting commit 31c1be420d5277dd15505bd73e6144827a0580cd back, it did not crash (when I moved the cursor outside the "smaller" screen).
Does it also freeze if you disable silken mouse (-nosilk or Option "SilkenMouse" "off", though I forget which section that needs to go in; verify with grep -i silken /var/log/Xorg.0.log)?
To clarify, I mean with that commit reverted.
(==) RADEON(0): Silken mouse enabled I guess this means the option should go into the "Device" section? It is not documented in radeon(4), nor xorg.conf(5) or mousedrv(4). Again, it will take some time before I can try it out. If you have any other things I can try out at the same time, please tell me.
Disabling SilkenMouse (and reverting commit) works! At least in clone mode (which is all I am able to test due to bug #12295). I can run hufo_tunnel and move the cursor outside the "small" screen without crashing. BTW I am now running xserver-xorg-video-ati 6.7.192-1ubuntu2 which is up to date with git per today.
Created attachment 11460 [details] [review] Possible fix Does this patch against current GIT work?
> Does this patch against current GIT work? Tried the patch, it worked for a while (testing with hufo_tunnel, haven't tried dual-head yet, but I guess dual screen is fine now that I put commit 31c1* back in). But after 10-20 seconds the screen froze, except for the mouse pointer which I could move without problems. Then I tried sysrq-K and everything froze solid. This was without any xorg.conf, so SilkenMouse was enabled.
(In reply to comment #17) > (testing with hufo_tunnel, haven't tried dual-head yet, but I guess dual screen > is fine now that I put commit 31c1* back in). The patch reverts the commit but attempts to ensure the DRI lock is held before waiting for idle. Please test all cases.
Yes, I have now successfully tested dual-head. The default "clone" and moving the cursor outside the screen worked fine. I also got the extended desktop working with "xrandr --right-of" after I added Virtual x y to xorg.conf, and could move from screen to screen without problems. I had hufo_tunnel running in both cases, and moved that window around everywhere. This time I didn't experience any crash at all, so either I didn't let hufo_tunnel run long enough, or the card was in a funky state in comment 17.
Patch pushed to GIT. Reopen if you can still reproduce.
Unfortunately, I had to revert the patch again because taking the DRI lock in these paths isn't safe in general, see e.g. bug 13005. Until we have a better solution for this, hopefully disabling silken mouse is an adequate workaround.
Now it froze even with silken mouse disabled... /var/log/Xorg.0.log.old:(**) RADEON(0): Option "SilkenMouse" "off" /var/log/Xorg.0.log.old:(**) RADEON(0): Silken mouse disabled
Created attachment 12388 [details] [review] Possible fix, take 2 Do the freezes still occur with this patch?
> Possible fix, take 2 > > Do the freezes still occur with this patch? With the patch, everything works perfectly. Thanks a lot!
Fix pushed to Git.
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.