Most recent kernel where this bug did not occur: I have only used 2.6 kernels, and it has always showed up, with all the versions I tested, up to 2.6.14. Distribution: I'm using Debian GNU Linux from the testing archive. Tested both with vanilla kernel from kernel.org and the distribution one. Hardware Environment: Dell Inspiron 6000 with x300 radeon Video card. 01:00.0 VGA compatible controller ATI Technologies Inc 5460 00 00 Dell 2003 Problem Description: Ok. I use the console as much as I can. Most often without running X. I use the radeonfb driver. With some ncurses applications, most notably mutt, when certain operations are performed my computer completely hangs. If mp3 were running in background, they stop. sysreq+s, sysreq+... others, do not work. I need to reboot using sysreq + b, which seems to be the only one working (or pushing the power off button for 5 seconds). Once it shows up, I can reproduce the bug on a regular basis (100%). It usually shows up when I use the 'v' key to see the attachments in a mail or when browsing a deep mail thread. It usually hangs in the middle of redrawing the screen for a scroll down/scroll up event, with half the screen redrawn and the lower half still with the previous page shown. It is quite annoying. It is not funny. Don't laugh at it :), even if it saves me from many flame wars. If I try to connect to the computer while it is hanged with ssh, it does not work. If I leave the computer on, just for the curiosity to see what happens, the console does not blank, but the redrawing goes on at a really slow speed (like 10/15 minutes to see a couple more lines, which come out all together). I don't think it's a bug in mutt or in the ncurses library :-) Obviously, if I don't modprobe radeonfb, the bug doesn't show up... I haven't seen any difference with the various kernel versions. Steps to reproduce: hem.. subscribe lkml, buy a dell inspiron 6000, use radeonfb, wait for the first flame war and try to take part in the discussion. It may as well be some kind of flame hardware protection or some sort of divine punishment... If you really need to, I can provide my own muttrc. I can do whatever patching, dumping, testing, debugging, coding may become necessary to fix the problem. I have a couple mails/threads I'd really like to read from mutt which always hang my computer. I know it sounds crazy, but I have yet to figure out where the problem lies.
Try booting with video=radeonfb:noaccel. If the above doesn't help, try fbset -vyres n where n = vertical resolution of your display. Let us know what happens.
On Mon, Jan 23, 2006 at 05:24:15AM -0800, bugme-daemon@bugzilla.kernel.org wrote: > Try booting with video=radeonfb:noaccel. uhm .. passed the parameter with modprobe. With noaccel, couldn't hang the pc in anyway. I could read the whole dm versus md thread without troubles :) reboot + modprobe _without noaccel_ hanged almost immediately. Is there anything I can do to help fixing the accelerated code? Thanks, Cheers, Carlo
What if you do radeonfb.default_dynclk=0 instead of noaccel ?
On Mon, Jan 23, 2006 at 03:12:00PM -0800, bugme-daemon@bugzilla.kernel.org happily wrote: > What if you do radeonfb.default_dynclk=0 instead of noaccel ? ok, with default_dynclk set to 0, I get the same problem described in the first mail. A crash after a few mails... So: modprobe radeonfb -> crash modprobe radeonfb default_dynclk=0 -> crash modprobe radeonfb noaccel -> works fine (for every command, I verified the dmesg output to see if the option was actually accepted). Cheers, Carlo
Can you open drivers/video/aty/radeon_base.c and look for static struct fb_ops radeonfb_ops? Then replace radeonfb_imageblit|fillrect|copyarea with cfb_imageblit|fillrect|copyarea. Then put back the accelerated versions one by one so we know which of the accel functions is causing the hang.
Please reopen this bug if: - it is still present in kernel 2.6.16 and - you can provide the requested information.