Created attachment 58374 [details]
I have Archlinux (linux-3.2.9) running on Radeon 4550 using radeon with xf86-video-ati 6.14.3, xorg 1.12 and mesa 8.0.1.
I have two monitors attached using DVI (Dell 2408WFP) and HDMI (Toshiba TV).
xrandr --output HDMI-0 --auto
xrandr --output HDMI-0 --below DVI-0
Here is the Xorg.0.log (full log is attached):
[ 730.765] BUG: triggered 'if (!dev->valuator || dev->valuator->numAxes < 2)'
[ 730.765] BUG: getevents.c:843 in scale_to_desktop()
[ 730.765] Backtrace:
[ 730.765] 0: /usr/bin/X (xorg_backtrace+0x34) [0x5684f4]
[ 730.765] 1: /usr/bin/X (0x400000+0x471e4) [0x4471e4]
[ 730.765] 2: /usr/bin/X (0x400000+0x47db5) [0x447db5]
[ 730.765] 3: /usr/bin/X (GetPointerEvents+0x352) [0x449452]
[ 730.765] 4: /usr/bin/X (0x400000+0x152c56) [0x552c56]
[ 730.766] 5: /usr/bin/X (miPointerWarpCursor+0xce) [0x55308e]
[ 730.766] 6: /usr/bin/X (0x400000+0x6c532) [0x46c532]
[ 730.766] 7: /usr/bin/X (0x400000+0x15357e) [0x55357e]
[ 730.766] 8: /usr/bin/X (0x400000+0xf3841) [0x4f3841]
[ 730.766] 9: /usr/bin/X (0x400000+0xdf2ee) [0x4df2ee]
[ 730.766] 10: /usr/bin/X (RRPointerScreenConfigured+0x75) [0x4df535]
[ 730.766] 11: /usr/bin/X (RRTellChanged+0x122) [0x4d9282]
[ 730.766] 12: /usr/bin/X (RRCrtcSet+0x33d) [0x4da41d]
[ 730.766] 13: /usr/bin/X (ProcRRSetCrtcConfig+0x3b3) [0x4db273]
[ 730.767] 14: /usr/bin/X (0x400000+0x33cf9) [0x433cf9]
[ 730.767] 15: /usr/bin/X (0x400000+0x2319a) [0x42319a]
[ 730.767] 16: /lib/libc.so.6 (__libc_start_main+0xed) [0x2ba545a7a38d]
[ 730.767] 17: /usr/bin/X (0x400000+0x234bd) [0x4234bd]
The same behaviour is seen using xf86-video-ati-git and xorg-git.
If "--below" is changed to some other "direction" it makes no difference. But It hangs only when the screens are positioned nearby, but not when showing the same area (1920x1200 on Dell and 1920x1080 on Toshiba).
*** Bug 48174 has been marked as a duplicate of this bug. ***
Created attachment 60643 [details]
Fix for xorg infinity loop.
Xorg goes to infinity loop (delta = 548.33340590666785 and incr = 6.3659874129151343e-314). Chromium authors code not good.
Created attachment 60645 [details]
proof debug output
I had previously launched "sleep 60 && kill -n 11 xorg_pid" and caused the freeze of xorg. And when xorg killed with SEGV, I receive this debug log. Xorg freezes in infinity loop.
the main question here is why the scroll increment is 0 (or close to 0 anyways). This is the cause of the bug and shouldn't happen.
In any way, while is dangerous without additional checks and in this case are senseless when works only with delta, more useable break loop and fmod delta.
But why scroll increment so small, I don't know, and in this moment mouse scroll not used at all.
your patch fix problem, but I will now always be nervous until the "while" loop will be completely safe
the loop is safe. "increment" is initialised once by the driver and that's where the server checks for and invalid increment of 0. it's read-only after that. This bug happened because of invalid memory access, there is only so much one can do against that.
Author: Peter Hutterer <firstname.lastname@example.org>
Date: Fri Apr 27 16:31:17 2012 +1000
dix: don't emulate scroll events for non-existing axes (#47281)
Works for me now.
Xorg-server 1.12.2-1 (ArchLinux)
on Jan 16, 2017 at 15:04:11.
(provided by the Example extension).