Re: radeonfb bug: text ends up scrolling in the middle of t

Re: radeonfb bug: text ends up scrolling in the middle of t

[Petr Vandrovec]

On 19 Nov 01 at 23:38, Dan Merillat wrote:
> > they'll shed some light on the problem.
> 
> Yes, yes.  The boot messages are normal, and typing 'reset' once I login 
> restores normal console.  The code that sets up a scrolling window below tux
> is well, missing the mark.
> 
> Tux looks like he's about 5 lines high, so lines 1-3 are tux, 4 is the one
> line of scroll, 5 is his feet, and 6-30 is the previous kernel boot
> messages.

It is known problem. At least known to me. After reboot and typing 'reset'
type 'dmesg' and then look for 'Console: switching to colour frame buffer 
device...'. Above that message you'll find couple of radeon messages - 
and you have to remove all printed during register_framebuffer() from
driver source - it looks to me like that '#if 1'-ed code in radeon_write_code
is suspect.

You must not do any output during register framebuffer. If you'll output
one line, I believe that it will still work, but if you'll do more, 
kernel output is catched in upper Tux window instead of in the bottom half 
of screen. And if you'll print really much of info during 
register_framebuffer, kernel will die...
                                            Best regards,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: radeonfb bug: text ends up scrolling in the middle of t

[Dan Merillat]

"Petr Vandrovec" writes:
> On 19 Nov 01 at 23:38, Dan Merillat wrote:
> > > they'll shed some light on the problem.
> > 
> > Yes, yes.  The boot messages are normal, and typing 'reset' once I login 
> > restores normal console.  The code that sets up a scrolling window below tu
x
> > is well, missing the mark.
> > 
> > Tux looks like he's about 5 lines high, so lines 1-3 are tux, 4 is the one
> > line of scroll, 5 is his feet, and 6-30 is the previous kernel boot
> > messages.
> 
> It is known problem. At least known to me. After reboot and typing 'reset'
> type 'dmesg' and then look for 'Console: switching to colour frame buffer 
> device...'. Above that message you'll find couple of radeon messages - 
> and you have to remove all printed during register_framebuffer() from
> driver source - it looks to me like that '#if 1'-ed code in radeon_write_code
> is suspect.

Bingo, that does it exactly.

> You must not do any output during register framebuffer. If you'll output
> one line, I believe that it will still work, but if you'll do more, 
> kernel output is catched in upper Tux window instead of in the bottom half 
> of screen. And if you'll print really much of info during 
> register_framebuffer, kernel will die...

Well, that's a good reason to get this patch into the 2.4.15-final, then.


--- radeonfb.c.orig	Tue Nov 20 12:08:54 2001
+++ radeonfb.c	Tue Nov 20 12:09:24 2001
@@ -2347,7 +2347,7 @@
 	OUTREG(CRTC_OFFSET, 0);
 	OUTREG(CRTC_OFFSET_CNTL, 0);
 	OUTREG(CRTC_PITCH, mode->crtc_pitch);
-#if 1
+#if 0
 	printk("CRTC_H_TOTAL_DISP = 0x%x, H_SYNC = 0x%x\n",
 		mode->crtc_h_total_disp, mode->crtc_h_sync_strt_wid);
 	printk("CRTC_V_TOTAL_DISP = 0x%x, V_SYNC = 0x%x\n",