I've been seeing occasional hard locking of X when I change the size of my video player from windowed to full screen or from full screen to windowed. Here's my setup: Debian Squeeze AMD64 Kernel 2.6.30-rc5 (self compiled) Xorg 7.4 (self-compiled) Gnome 2.26.1 (debian packages) Totem 2.26.2 (debian package) radeonhd (I git pull every 2-3 days.) drm (native, built into kernel 2.6.30) Two 1920x1200 panels over DVI DVI-I_1/digital is Left Panel DVI-I_2/digital is Right Panel I've been using randr to disable the left monitor when I watch videos. This seems to be a necessary condition for the bug. I see the bug when running totem on the remaining right display. X locks hard when totem transitions between full screen and windowed mode. It happens on both directions. All keyboard input is ignored. I have to ssh in and kill X. It's always at 100% cpu utilization. This doesn't happen on every transition between windowed and full screen but it happens often enough! : ) I've been using the power switch to disable my left monitor. I want to verify that the bug happens only when randr is used to disable the left screen. It has been proven true so far. Is anyone else running a setup like mine? What's the best way to debug this? I know I need an Xorg.log, but anything else? -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Wed, Jun 3, 2009 at 10:55 AM, kristof
I've been seeing occasional hard locking of X when I change the size of my video player from windowed to full screen or from full screen to windowed. Here's my setup:
Debian Squeeze AMD64 Kernel 2.6.30-rc5 (self compiled) Xorg 7.4 (self-compiled) Gnome 2.26.1 (debian packages) Totem 2.26.2 (debian package) radeonhd (I git pull every 2-3 days.) drm (native, built into kernel 2.6.30)
Two 1920x1200 panels over DVI DVI-I_1/digital is Left Panel DVI-I_2/digital is Right Panel
I've been using randr to disable the left monitor when I watch videos. This seems to be a necessary condition for the bug. I see the bug when running totem on the remaining right display. X locks hard when totem transitions between full screen and windowed mode. It happens on both directions. All keyboard input is ignored. I have to ssh in and kill X. It's always at 100% cpu utilization.
This doesn't happen on every transition between windowed and full screen but it happens often enough! : )
I've been using the power switch to disable my left monitor. I want to verify that the bug happens only when randr is used to disable the left screen. It has been proven true so far.
Is anyone else running a setup like mine? What's the best way to debug this? I know I need an Xorg.log, but anything else?
Does the drm patch in bug 21849 help? Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Wed, Jun 3, 2009 at 11:00 AM, Alex Deucher
Does the drm patch in bug 21849 help?
I've built a patched kernel and will report back in a little while. The bug struck me 1-2 times per week on average. I have one more question for the list. My virtual terminals (Ctrl-Alt-Fn) aren't working and I haven't been able to figure out the problem. They worked fine when running stock debian (testing) packages but not since I've run the self-compiled kernel and X stack for radeonhd. My kernel .config has the following lines of interest: CONFIG_VT=y CONFIG_VT_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set Thanks. [Sorry for the double mail Alex!] -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jun 03, 09 16:04:19 -0400, kristof wrote:
I have one more question for the list. My virtual terminals (Ctrl-Alt-Fn) aren't working and I haven't been able to figure out the problem. They worked fine when running stock debian (testing) packages but not since I've run the self-compiled kernel and X stack for radeonhd.
What hardware is this? On some of the newer systems (M92 etc.) this is a
known issue.
Matthias
--
Matthias Hopf
On Thu, Jun 4, 2009 at 9:28 AM, Matthias Hopf
On Jun 03, 09 16:04:19 -0400, kristof wrote:
I have one more question for the list. My virtual terminals (Ctrl-Alt-Fn) aren't working and I haven't been able to figure out the problem. They worked fine when running stock debian (testing) packages but not since I've run the self-compiled kernel and X stack for radeonhd.
What hardware is this? On some of the newer systems (M92 etc.) this is a known issue.
Q6600 P45 HD3650 Running Debian Squeeze AMD64. VT's work fine on the same hardware with stock debian kernel (2.6.26-2-amd64) and fglrx. It's only when running my self-compiled kernel (2.6.30-rc5), self-compiled Xorg stack (7.4), and radeonhd that VT's don't work. While researching the issue I found a number of people who had this problem as a result of incorrect keyboard configuration in xorg.conf. They were all using non US keyboards though. I'm using a standard US keyboard and I don't have any InputDevice sections in my xorg.conf. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Jun 04, 09 10:44:56 -0400, kristof wrote:
I have one more question for the list. My virtual terminals (Ctrl-Alt-Fn) aren't working and I haven't been able to figure out the
Ah, I misread this. I thought you were getting a black screen.
While researching the issue I found a number of people who had this problem as a result of incorrect keyboard configuration in xorg.conf. They were all using non US keyboards though. I'm using a standard US keyboard and I don't have any InputDevice sections in my xorg.conf.
Yes, this could be due to missing or misconfigured xkb.
Matthias
--
Matthias Hopf
On Jun 03, kristof wrote:
I have one more question for the list. My virtual terminals (Ctrl-Alt-Fn) aren't working and I haven't been able to figure out the problem. They worked fine when running stock debian (testing) packages but not since I've run the self-compiled kernel and X stack for radeonhd.
same happend to me too (using "US" keyboard btw). Ctrl-Alt-Backspace didn't work either. in xorg.conf check the driver in the Section "InputDevice" for your keyboard: Driver "evdev" caused my problems, and switching to Driver "kbd" fixed them... Harald -- "I hope to die ___ _____ before I *have* to use Microsoft Word.", 0--,| /OOOOOOO\ Donald E. Knuth, 02-Oct-2001 in Tuebingen. <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// \/\/\/\/\/\/\/\/\/ Harald Koenig // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Thu, Jun 4, 2009 at 1:15 PM, Harald Koenig
On Jun 03, kristof wrote:
I have one more question for the list. My virtual terminals (Ctrl-Alt-Fn) aren't working and I haven't been able to figure out the problem. They worked fine when running stock debian (testing) packages but not since I've run the self-compiled kernel and X stack for radeonhd.
same happend to me too (using "US" keyboard btw). Ctrl-Alt-Backspace didn't work either.
in xorg.conf check the driver in the Section "InputDevice" for your keyboard:
Driver "evdev"
caused my problems, and switching to
Driver "kbd"
fixed them...
I added the following to my xorg.conf: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbLayout" "us" Option "XkbModel" "pc105" Option "Xkbvariant" "" EndSection Now I'm getting these errors in my Xorg.log: (EE) Error compiling keymap (server-0) (EE) XKB: Couldn't compile keymap (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap ... (**) Option "CoreKeyboard" (**) Keyboard0: always reports core events (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (WW) Option "XkbVariant" requires an string value (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled ... (II) evaluating device (Keyboard0) (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (EE) Error compiling keymap (server-0) (EE) XKB: Couldn't compile keymap (WW) Couldn't load XKB keymap, falling back to pre-XKB keymap I tried manually: setxkbmap -v 10 -rules xorg -model pc104 -layout us -option "" Here's the output: Setting verbose level to 10 locale is C Warning! Multiple definitions of rules file Using command line, ignoring X server Warning! Multiple definitions of keyboard model Using command line, ignoring X server Warning! Multiple definitions of keyboard layout Using command line, ignoring X server Applied rules from xorg: model: pc104 layout: us Trying to build keymap using the following components: keycodes: xfree86+aliases(qwerty) types: complete compat: complete symbols: pc+us geometry: pc(pc104) Error loading new keyboard description This is what I originally did you get my Xorg: I used Xorg's "build-from-tarballs.sh" script to build Xorg and install it to a custom prefix. I removed all debian Xorg packages and pointed everything to my custom X install. That seemed like enough to get everything working. I guess there is additional configuration needed for xkbd. I should probably take this to an Xorg list. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Wed, Jun 3, 2009 at 11:00 AM, Alex Deucher
Does the drm patch in bug 21849 help?
Apparently not. I hit the bug again even though I'm now running 2.6.30-rc5 with the radeon-test-ring patch. I was taking totem from full screen to windowed mode. X locked hard. I sshed in but was unable to kill X. It caused some interesting output in /var/log/messages when I tried. I was forced to reboot. I tried to post the logs immediately but my message was rejected by relay1.suse.de for excessive size. I even bz2'd the logs. That's not exactly optimal configuration for a development listserver. I had to wait until I had the time to open a bug: https://bugs.freedesktop.org/show_bug.cgi?id=22153 Xorg.0.log and /var/log/messages are attached. I don't think I was running with "-logverbose 7 -verbose 7" but I've added it to my gdm.conf. I should be able to produce another set of logs in a couple of days time. Most of the time my machine is running from a resume rather than a cold boot. I didn't think to mention that in my original report. I have no idea if it's significant. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (4)
-
Alex Deucher -
Harald Koenig -
kristof -
Matthias Hopf