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
Created attachment 12329 [details]
Log file, retrieved after reboot.
Created attachment 12330 [details]
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?
> 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.
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]
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.