Created attachment 37941 [details] Kernel 2.6.35.2 configuration I'm running a multiseat core i7 machine with Debian Squeeze installed, latest xf86-video-ati from the master git branch, kernel 2.6.35.2, two Radeon 4670 cards. Every so often the X display on the primary card switches to console, and this appears to happen only after the kernel logs something to the console, but not always when the kernel logs something does this switch happen. E.g. if I plug in a USB device chances are that the X display switches to console, because the kernel logs a new device. The problem is that it appears the computer still thinks it's showing me the X display, because I can see and move the mouse pointer over the text in console, and can do actions on the X desktop with the mouse and keyboard, although blindfold. I can restore the X display if I fiddle with its settings, e.g.: xrandr -o left displays back the X display, rotated of course, so I do xrandr -o normal to get it all back to normal. My setup involves a kdm login manager configured with two X servers (running KDE 4.4.5).
Created attachment 37942 [details] dmesg section involving graphics cards initialization
Created attachment 37943 [details] xorg configuration
Created attachment 37944 [details] X server log for the primary card
can you attach the full dmesg? I think I know what is possibly causing it but I need to see if you have a lockdep warning somewhere.
Created attachment 37946 [details] Full dmesg I'm attaching the full dmesg. I've got a few switches to console (didn't count, about 3 or 4) up till now, all recovered from by logging in remotely and doing the xrandr trick. Doesn't show up in the dmesg, as far as I can tell, or in any other logs.
Here's another clue for the bug that causes switching the X display to console. Another switch to console on the primary card happened to me, but this time kernel didn't log anything. But it happened at the same time the display on the secondary card came out of the DPMS off state. It looks as if this bug isn't directly related to kernel logging afterall.
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.
I'd like to report that since I upgraded to Debian Wheezy, this bug doesn't manifest itself anymore. The same multiseat machine with two Radeon 4670 cards now works without a hitch for about a year already. Only original Debian packages are installed on the machine, nothing from separate git repositories or similar. The old xorg.conf didn't work correctly with the new kdm version for some reason, but then I found an excellent guide for configuring a multiseat machine on a Gentoo wiki page: http://wiki.gentoo.org/wiki/Multiseat . Perhaps the troubles I was having on Debian Squeeze were caused due to misconfiguration. As is described in the mentioned wiki page, now I have two separate short xorg configurations, each for a separate X server (left and right seat), and udev tagging of input devices for exclusive use with separate seats, set in each xorg configuration. I suggest closing this bug.
(In reply to comment #8) > I suggest closing this bug. You can do that yourself BTW. :) Doing so now, thanks for the followup and glad it's working for you now.
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.