|Summary:||system freeze with hufo_tunnel and moving mouse|
|Product:||xorg||Reporter:||Tormod Volden <bugzi11.fdo.tormod>|
|Component:||Driver/Radeon||Assignee:||xf86-video-ati maintainers <xorg-driver-ati>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Tormod Volden 2007-09-01 01:54:10 UTC
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 18.104.22.168.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?
Comment 1 Tormod Volden 2007-09-01 02:01:16 UTC
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)
Comment 2 Tormod Volden 2007-09-01 05:48:11 UTC
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...)
Comment 3 Alex Deucher 2007-09-01 08:22:59 UTC
are you using different versions of mesa with each driver?
Comment 4 Alex Deucher 2007-09-01 08:26:35 UTC
does reverting commit 31c1be420d5277dd15505bd73e6144827a0580cd help?
Comment 5 Tormod Volden 2007-09-01 10:18:11 UTC
(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!
Comment 6 Alex Deucher 2007-09-01 20:19:34 UTC
(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?
Comment 7 Tormod Volden 2007-09-02 02:56:15 UTC
I don't have a second screen handy, so it will take some time before I can test it.
Comment 8 Tormod Volden 2007-09-05 01:19:51 UTC
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.
Comment 9 Michel Dänzer 2007-09-05 02:04:10 UTC
(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?
Comment 10 Tormod Volden 2007-09-05 03:15:45 UTC
> '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.
Comment 11 Tormod Volden 2007-09-05 12:57:55 UTC
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).
Comment 12 Michel Dänzer 2007-09-05 23:41:06 UTC
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)?
Comment 13 Michel Dänzer 2007-09-05 23:42:12 UTC
To clarify, I mean with that commit reverted.
Comment 14 Tormod Volden 2007-09-06 01:18:06 UTC
(==) 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.
Comment 15 Tormod Volden 2007-09-07 01:10:28 UTC
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.
Comment 16 Michel Dänzer 2007-09-07 01:20:06 UTC
Created attachment 11460 [details] [review] Possible fix Does this patch against current GIT work?
Comment 17 Tormod Volden 2007-09-07 04:21:42 UTC
> 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.
Comment 18 Michel Dänzer 2007-09-07 04:27:42 UTC
(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.
Comment 19 Tormod Volden 2007-09-07 12:49:10 UTC
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.
Comment 20 Michel Dänzer 2007-09-07 15:25:42 UTC
Patch pushed to GIT. Reopen if you can still reproduce.
Comment 21 Michel Dänzer 2007-11-05 02:02:13 UTC
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.
Comment 22 Tormod Volden 2007-11-05 11:35:30 UTC
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
Comment 23 Michel Dänzer 2007-11-07 07:58:27 UTC
Created attachment 12388 [details] [review] Possible fix, take 2 Do the freezes still occur with this patch?
Comment 24 Tormod Volden 2007-11-07 15:02:57 UTC
> Possible fix, take 2 > > Do the freezes still occur with this patch? With the patch, everything works perfectly. Thanks a lot!
Comment 25 Michel Dänzer 2007-11-08 02:43:42 UTC
Fix pushed to Git.