[Bug 29643] Display switches to console when kernel logs a line

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Aug 25 13:42:53 PDT 2010


https://bugs.freedesktop.org/show_bug.cgi?id=29643

--- Comment #7 from Aleš Smodiš <smodisa at gmail.com> 2010-08-25 13:42:53 PDT ---
I've been running the machine for 8 days straight now and I have some more
details to report about the bug. First, it's not correlated with kernel
logging, I'm sorry about that. The thing is both monitors have a builtin usb
hub, both of which are connected to the computer, and to one of which an usb
disk is occasionally connected, and monitors get turned on and off
occasionally, thus causing the said kernel logging about new devices and adding
to (my) confusion.

When the monitor on the secondary card is put to sleep via DPMS and remains
there for a long time (my experiments show it has to be at least 1 hour to
consistently trigger the bug, sometimes only half an hours suffices), and then
a mouse drag triggers it to be woken up, then the display on the primary card
is switched to display the console. The mouse and keyboard dedicated to the
second display are a wireless usb combo, meaning both are connected with the
same usb cable. I don't know whether that matters, but the thing is that if I
wake up the monitor on the secondary card with the keyboard by pressing a key,
the secondary display is woken up without switching the primary display to
console. But afterwards the first mouse action on the secondary display will
switch the primary display to console. I've tried this combined action (first
keyboard, then mouse) about 5 times now, and I've tried only a mouse drag for
at least 30 times now, and I've consistently had the same results I just
described.

Sometimes, very rarely, the primary display would enter DPMS sleep in the
middle of my work, and no mouse drag or keyboard action would get it out of the
sleep, only a blind or remote "xset -dpms". That never happens on the secondary
display.

Sometimes, not so rarely, the computer's load in the middle of a video playback
would increase so much that video wouldn't playback smoothly anymore, and that
would go on for about 3 to 5 minutes, then load suddenly decreases and video
playback goes back to normal.
Here's how things look like during normal playback:

top - 21:55:18 up 8 days,  2:34,  6 users,  load average: 0.61, 0.57, 0.67
Tasks: 408 total,   2 running, 406 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.3%us,  0.7%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  2.0%us,  0.3%sy,  0.0%ni, 97.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  1.7%us,  1.3%sy,  0.0%ni, 97.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  3.6%us,  0.3%sy,  0.0%ni, 96.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6120404k total,  5808616k used,   311788k free,   451616k buffers
Swap: 10490364k total,     3436k used, 10486928k free,  3067668k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 8668 aless     20   0  447m  40m  17m R    5  0.7  13:02.51 konsole            
10456 aless     20   0 1105m 731m  29m S    3 12.2 109:26.94 opera              
23454 aless     20   0  286m  18m  10m S    2  0.3   0:04.31 mplayer            
 3645 root      20   0  179m  39m 5616 S    1  0.7  97:34.46 Xorg               
16599 ziva      20   0 1003m  82m  39m S    1  1.4  25:18.03 plasma-desktop     
16629 ziva      20   0  642m  72m  34m S    1  1.2  32:55.08 ktorrent           
20911 aless     20   0 19376 1556  928 R    1  0.0   0:06.92 top                
 3636 root      20   0  172m  38m 4648 S    0  0.6  64:25.90 Xorg               
16593 ziva      20   0  503m  37m  26m S    0  0.6  37:13.40 kwin               
    1 root      20   0  8400  720  676 S    0  0.0   0:07.54 init               
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd           
    3 root      20   0     0    0    0 S    0  0.0   0:02.30 ksoftirqd/0        
    4 root      RT   0     0    0    0 S    0  0.0   0:00.83 migration/0        
    5 root      RT   0     0    0    0 S    0  0.0   0:00.41 migration/1        
    6 root      20   0     0    0    0 S    0  0.0   0:02.62 ksoftirqd/1        

And here's how things look like during one of such "load attacks":

top - 21:19:39 up 8 days,  1:58,  6 users,  load average: 5.16, 3.23, 1.85
Tasks: 414 total,   3 running, 411 sleeping,   0 stopped,   0 zombie
Cpu0  : 11.1%us, 61.1%sy,  0.0%ni, 27.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  2.4%us, 22.0%sy,  0.0%ni, 75.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 11.8%us, 76.5%sy,  0.0%ni, 11.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us, 75.0%sy,  0.0%ni, 25.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.9%us,  3.6%sy,  0.0%ni, 95.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us, 25.0%sy,  0.0%ni, 75.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  : 33.3%us, 55.6%sy,  0.0%ni, 11.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  7.1%us,  7.1%sy,  0.0%ni, 85.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6120404k total,  5581688k used,   538716k free,   448916k buffers
Swap: 10490364k total,     3436k used, 10486928k free,  2820020k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
19086 aless     20   0  286m  18m  10m S    1  0.3   0:21.23 mplayer            
 3645 root      20   0  179m  39m 5616 S    1  0.7  97:10.31 Xorg               
 8668 aless     20   0  446m  40m  17m S    1  0.7  11:39.50 konsole            
16629 ziva      20   0  642m  72m  34m S    1  1.2  32:43.17 ktorrent           
 3636 root      20   0  172m  38m 4648 S    0  0.6  64:22.22 Xorg               
10456 aless     20   0 1104m 731m  29m S    0 12.2 107:57.18 opera              
16543 ziva      20   0 24788 2324  640 S    0  0.0   8:07.35 dbus-daemon        
16593 ziva      20   0  503m  37m  26m S    0  0.6  37:09.94 kwin               
16599 ziva      20   0 1003m  82m  39m S    0  1.4  25:09.44 plasma-desktop     
    1 root      20   0  8400  720  676 S    0  0.0   0:07.53 init               
    2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd           
    3 root      20   0     0    0    0 S    0  0.0   0:02.28 ksoftirqd/0        
    4 root      RT   0     0    0    0 S    0  0.0   0:00.83 migration/0        
    5 root      RT   0     0    0    0 S    0  0.0   0:00.41 migration/1        
    6 root      20   0     0    0    0 S    0  0.0   0:02.61 ksoftirqd/1        

I have no clue about what's causing this load, from the above no user process
appears to be responsible for it. I'm only mentioning it here because sometimes
the load increases even up to 9 or above, and then it is likely that suddenly,
during the ongoing stuttering playback, the display is suddenly put into sleep
mode (DPMS), stays there for about 3 or 4 seconds (with stutering video still
playing), and is then turned back on, then some more of the stuttering video
until the load decreases, and then everything is back to normal.

The video playback problems appear only on the primary display. Otherwise, the
two video cards are identical Radeon 4670 cards.

In the kernel log I've noticed the next line to appear 3 times in the previous
8 days of uptime (today, yesterday, and 3 days ago):

[drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but no|invalid EDID

but I'm not exactly sure what I was doing at the time, my guess is I was doing
the xrandr trick to switch back from console to X display. Also regarding this
xrandr trick, the last few days I was noticing that after the first "xrandr -o
left" I don't get a rotated display anymore, but the normal X display, only it
has the same symptoms as the console display after a switch: I can do actions
blindly, but the display stays static in the state that it was awakened in,
only the next "xrandr -o normal" puts things back to normal, where also the
results of any actions done blindly before are seen.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the xorg-driver-ati mailing list