[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