Using radeonhd my machine completely locks up when switched to the text console for more than a view minutes. Using netconsole I see no additional kernel messages and the machine is completely unresponsive afterwards, even SysRQ doesn't work.
Created attachment 12329 [details] Xorg.0.log Log file, retrieved after reboot.
Created attachment 12330 [details] xorg.conf Configuration file.
Is there anything I can do to provide more information? I tried to measure the time till the lockup by typing "i=0; while sleep 1; do echo $((i++)); done" at the shell. There doesn't seem to be a pattern: sometimes it's about 60 and sometimes it's over 1000.
Simple questions, for netconsole did you turn up the loglevel with ignore_loglevel in the command line? Is the machine pingable at all? I figure the SysRq is not working because X is stealing the keyboard.
(In reply to comment #4) > Simple questions, for netconsole did you turn up the loglevel with > ignore_loglevel in the command line? Yes. > Is the machine pingable at all? No. Also when I play music using amarok (see below) the sound stops and only repeats the last sample. I'm pretty sure it's a real lockup and not just X grabbing the keyboard. I found a quicker way to trigger the bug: I use amarok and I configured it do show current song information with its on-screen display on song change. After I switch to the text console and tell amarok to play the next song using the command line interface ("amarok -f") the machine almost certainly locks up, i.e. I only have to call the command one or two times. When I disable the on-screen display the bug can't be triggered this way. I use ion3 as my window manager so most of my windows are tiled, maybe this is also relevant.
(In reply to comment #5) > I found a quicker way to trigger the bug: I use amarok and I configured > it do show current song information with its on-screen display on song > change. After I switch to the text console and tell amarok to play the > next song using the command line interface ("amarok -f") the machine > almost certainly locks up, i.e. I only have to call the command one or > two times. When I disable the on-screen display the bug can't be > triggered this way. > > I use ion3 as my window manager so most of my windows are tiled, maybe > this is also relevant. I'm using ion3, amarok, and radeonhd. I have just run "amarok -f" ten times from the console. No hangs. ion3-20070203-6 xorg-x11-drv-radeonhd-0.0.2-0.15.20071105git.fc9 (e9c24f66..) amarok-1.4.7-7.fc8 xosd-2.2.14-10.fc8 xorg-x11-server-Xorg-1.3.0.0-33.fc8
Perhaps the difference is in your consoles. Are you both using radeonfb or vesafb as a framebuffer in the console?
(In reply to comment #7) > Perhaps the difference is in your consoles. Are you both using radeonfb or > vesafb as a framebuffer in the console? I am using the VGA text console.
(In reply to comment #8) > (In reply to comment #7) > > Perhaps the difference is in your consoles. Are you both using radeonfb or > > vesafb as a framebuffer in the console? > > I am using the VGA text console. I'm currently using vesafb. I'll try to reproduce the bug without it and report back afterwards.
I retested it without vesafb (i.e. not compiled in). The machine still locks up some time after switching to the text console but I can't trigger it with "amarok -f" anymore. With only ion3, gnome-terminal, gkrellm and amarok running it took about 180 seconds to freeze. Without amarok it took about 300 seconds. I don't know what else to do.
Created attachment 12397 [details] config-2.6.23.1 Linux kernel configuration
I can confirm this bug. Tried reproducting it, but it only locks up 1 out of about 50 tries. MacbookPro2,1 here, stock debian SID kernel (linux-image-2.6.22-3-amd64 2.6.22-5). Nothing special in the log files, no framebuffer devices.
This looks to me as something is trying to access the framebuffer when another console is active. I will take a look at it.
I *really* would like to have an 'assign to me and accept' button in bugzilla :/
I've tried to reproduce this here as described in the report. So far no success. A simple way to test if anything is really accessing the framebuffer while switched away would be to unmap the framebuffer in LeaveVT(). Then the Xserver should segfault when something accesses the framebuffer. This brute force method of course doesn't allow one to switch back to X once switched to console.
Is there something I can do? I probably can't do the unmapping thing without some hints what needs to be changed.
Any advance here?
I confirmed this bug in #12, but lately it hasn't been a problem for me anymore. I think it disappeared for me around 0.0.4 somewhere. I can not give you any more information on this one, sorry. (Running debians 1.0.0 without any problems now).
Frank? Can you test a recent version of our driver?
As of 79e016fd the problem did not reappear, so the bug can be closed for all I care. If it happens again I can just reopen the bug, if that is ok with you.
Ok.
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.