Created attachment 110568 [details] xorg.log Hi, I have a dual-screen setup with Debian wheezy and every hour and 7 +/-1 minutes the main screen starts kinda like quickly zoom in and out twice and after the other screen does the same twice too. After upgrading to Debian jessie the same "zooming" happens but changed now to every ~16 minutes, sometimes only laptop screen once, sometimes external once. It happens in KDE but also if I log out and am in console. It's not happening when external display is not plugged in. Is there a way to log something like that? Cuz can't find anything in the logs lookin right after it occures. Searching the net for this kinda error led me to someone mentioning it could be upowerd, but I monitored D-Bus and nothing showed up as the zooming occured. I also checked out /var/log and .xsession-errors but nothing. I cannot try it with fglrx because it seems the VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV516/M64-S [Mobility Radeon X2300] [1002:7188] isn't supported anymore. dmesg: [ 10.957112] [drm] radeon kernel modesetting enabled. [ 10.957491] radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used) [ 10.957494] radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0x0000000027FFFFFF [ 10.957587] [drm] radeon: 128M of VRAM memory ready [ 10.957589] [drm] radeon: 512M of GTT memory ready. [ 10.958174] [drm] radeon: power management initialized [ 10.969654] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 10.970400] radeon 0000:01:00.0: WB enabled [ 10.970403] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000008000000 and cpu addr 0xff68c000 [ 10.970415] [drm] radeon: irq initialized. [ 11.020383] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/R520_cp.bin [ 11.020525] [drm] radeon: ring at 0x0000000008001000 [ 11.028019] [drm] radeon atom DIG backlight initialized [ 11.357820] fbcon: radeondrmfb (fb0) is primary device [ 11.537435] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [ 11.537437] radeon 0000:01:00.0: registered panic notifier [ 11.544056] [drm] Initialized radeon 2.39.0 20080528 for 0000:01:00.0 on minor 0 Thanks for your time.
Please attach your full dmesg output after it happens as well. What secondary connector are you using (VGA, DVI)? It may be an issue with the drm display polling for non-hotplug capable displays (likfe VGA). Does adding drm_kms_helper.poll=0 on the kernel command line in grub help?
Created attachment 110574 [details] dmesg.log
xrandr: Screen 0: minimum 320 x 200, current 2918 x 1024, maximum 8192 x 8192 VGA-0 connected 1280x1024+1638+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.02*+ 75.02 1280x960 75.04 60.00 1152x864 75.00 1024x768 75.08 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 640x480 75.00 72.81 66.67 60.00 720x400 70.08 LVDS connected primary 1440x900+0+6 (normal left inverted right x axis y axis) 303mm x 190mm 1440x900 60.00*+ 1280x854 59.89 1280x800 59.81 1280x720 59.86 1152x768 59.78 1024x768 59.92 800x600 59.86 848x480 59.66 720x480 59.71 640x480 59.38 DVI-0 disconnected (normal left inverted right x axis y axis) Using VGA port, the laptop doesn't have a DVI port. Is there a way to turn its detection off temp. like with TV out (options radeon tv=0)?
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-686-pae root=UUID=2cd070f6-4787-48b3-b904-9a4d4e0a7d50 ro drm_kms_helper.poll=0 quiet did not fix it, I've been waiting to see if anything changed timerwise, but it still occurs every ~16 minutes.
Does it happen in single user mode? KDE for example had some daemon process that used to poll Xrandr for the display status at regular intervals (e.g., every 30 or 60 seconds) rather than listening for hotplug events from the kernel. The problem with polling Xrandr is then when it called the randr detect interface, it would try and do load detection on the analog displays which caused flickering.
Same in single user mode. Does the radeon driver have some kind of "very verbose" mode? I'd like to see what there will be logged right as it happens. Or is there anything else i could activate to get more verbose logging, kinda like a system wide logging service that shows everything tagged with ns timestamps if it has to be..
(In reply to freenode from comment #6) > Does the radeon driver have some kind of "very verbose" mode? I'd like to > see what there will be logged right as it happens. You can write 1 to /sys/module/drm/parameters/debug to enable driver debug messages in dmesg and 0 again to disable them. > Or is there anything else i could activate to get more verbose logging, kinda > like a system wide logging service that shows everything tagged with ns > timestamps if it has to be.. The systemd journal is supposed to be something like that, though it can't log something that isn't printed in the first place either. :)
I wonder about two things tho: 1. it only happens when external display is connected. 2. every 16 minutes?! There must be some piece of code somewhere containing this number. That code seems not to be in the KDE package, as far as i understand that, because it happens in single user mode too. So what could be left that only activates when an external display gets/is connected to the VGA port with a 16 minutes timer?! VGA driver, Power Management maybe? Anything else?
(In reply to freenode from comment #8) > I wonder about two things tho: > > 1. it only happens when external display is connected. > 2. every 16 minutes?! There must be some piece of code somewhere containing > this number. That code seems not to be in the KDE package, as far as i > understand that, because it happens in single user mode too. > > So what could be left that only activates when an external display gets/is > connected to the VGA port with a 16 minutes timer?! VGA driver, Power > Management maybe? Anything else? There's nothing in the radeon driver that does anything at 16 minute intervals.
-- 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/xorg/driver/xf86-video-ati/issues/120.
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.