Radeon framebuffer weirdness in -mm2

Radeon framebuffer weirdness in -mm2

[Matt Mackall]

I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Radeon framebuffer weirdness in -mm2

[Andrew Morton]

Matt Mackall <mpm@selenic.com> wrote:
>
> I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.

Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?

(cc Ben, who is the likely cuprit ;)

Which -mm2, btw?  2.6.10-mm2 or 2.6.11-rc1-mm2?

Did you try the corresponding -mm1?

Re: Radeon framebuffer weirdness in -mm2

[Matt Mackall]

On Thu, Jan 20, 2005 at 03:39:21PM -0800, Andrew Morton wrote:
> Matt Mackall <mpm@selenic.com> wrote:
> >
> > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
> 
> Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?

FB_RADEON.

> (cc Ben, who is the likely cuprit ;)

Btw, ajoshi's address from MAINTAINERS is bouncing.
 
> Which -mm2, btw?  2.6.10-mm2 or 2.6.11-rc1-mm2?

2.6.11-rc1-mm2

> Did you try the corresponding -mm1?

Nothing between that and .10 yet. Building -mm1 now.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Radeon framebuffer weirdness in -mm2

[Andrew Morton]

Matt Mackall <mpm@selenic.com> wrote:
>
> > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> 
> FB_RADEON.

Ah, OK.  Likely culprits are

radeonfb-massive-update-of-pm-code.patch
radeonfb-build-fix.patch

Re: Radeon framebuffer weirdness in -mm2

[Benjamin Herrenschmidt]

On Thu, 2005-01-20 at 15:39 -0800, Andrew Morton wrote:
> Matt Mackall <mpm@selenic.com> wrote:
> >
> > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
> 
> Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> 
> (cc Ben, who is the likely cuprit ;)
> 
> Which -mm2, btw?  2.6.10-mm2 or 2.6.11-rc1-mm2?
> 
> Did you try the corresponding -mm1?

/me curses possible BIOS crap ...

radeonfb tries to restore initial mode when the module is closed, which
wouldn't work for a VGA text thing in fact... I suspect something cause
driver remove() routines to be called on reboot, can you confirm ? Or is
it a module that gets removed ? It may well be a problem that has always
been there (regardless of the radeon driver version) and just triggered
by something the kernel does on reboot...

Ben.

Re: Radeon framebuffer weirdness in -mm2

[Benjamin Herrenschmidt]

On Thu, 2005-01-20 at 15:48 -0800, Matt Mackall wrote:
> On Thu, Jan 20, 2005 at 03:39:21PM -0800, Andrew Morton wrote:
> > Matt Mackall <mpm@selenic.com> wrote:
> > >
> > > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > > horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
> > 
> > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> 
> FB_RADEON.
> 
> > (cc Ben, who is the likely cuprit ;)
> 
> Btw, ajoshi's address from MAINTAINERS is bouncing.

The file should be updated, I am the radeonfb maintainer now.

> > Which -mm2, btw?  2.6.10-mm2 or 2.6.11-rc1-mm2?
> 
> 2.6.11-rc1-mm2
> 
> > Did you try the corresponding -mm1?
> 
> Nothing between that and .10 yet. Building -mm1 now.

Thanks.

Ben.

Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2

[James Simmons]

> > > > I'm seeing radeonfb on my ThinkPad T30 go weird on reboot (lots of
> > > > horizontal lines) and require powercycling to fix. Worked fine with 2.6.10.
> > > 
> > > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> > 
> > FB_RADEON.
> > 
> > > (cc Ben, who is the likely cuprit ;)
> > 
> > Btw, ajoshi's address from MAINTAINERS is bouncing.
> 
> The file should be updated, I am the radeonfb maintainer now.

Speaking of. Should we nuke the old radeonfb driver?
 

Re: Radeon framebuffer weirdness in -mm2

[Matt Mackall]

On Thu, Jan 20, 2005 at 04:01:23PM -0800, Andrew Morton wrote:
> Matt Mackall <mpm@selenic.com> wrote:
> >
> > > Which radeon driver? CONFIG_FB_RADEON_OLD or CONFIG_FB_RADEON?
> > 
> > FB_RADEON.
> 
> Ah, OK.  Likely culprits are
> 
> radeonfb-massive-update-of-pm-code.patch
> radeonfb-build-fix.patch

Ok, learned a few things.

Here are the symptoms:

mm2: corruption of Tux logo at boot, corruption of display at
powerdown, lockup and LCD blooming on next warm boot when radeonfb
starts. Ben suggested I try some radeonfb options, but none seemed to
have any effect.

mm1: no observed problems

mm2 - above patches: corruption still occurs but no lockup on next
warm boot.

I think I have a lead on the logo and shutdown corruption:

If I do a reboot(8) from inside X, I get switched to vt 0, but the
shutdown messages come out on vt 7, where X was running. As I'm
sitting on vt 0 during shutdown, I see character cells changed to
something like "_" (last two scanlines filled) slowly marching down
the screen corresponding to the shutdown messages.

So the logo corruption is probably getty popping up on the
other vts at the end of init. The timing and the screen placement seem
to agree.

Photos for the curious (be sure to see "executioner Tux" glitch):
http://selenic.com/radeon

-- 
Mathematics is the supreme nostalgia of our time.

Re: Radeon framebuffer weirdness in -mm2

[Andrew Morton]

Matt Mackall <mpm@selenic.com> wrote:
>
> Here are the symptoms:
> 
>  mm2: corruption of Tux logo at boot, corruption of display at
>  powerdown, lockup and LCD blooming on next warm boot when radeonfb
>  starts. Ben suggested I try some radeonfb options, but none seemed to
>  have any effect.
> 
>  mm1: no observed problems
> 
>  mm2 - above patches: corruption still occurs but no lockup on next
>  warm boot.

So we have multiple bugs?

Next suspects would be:

+cleanup-vc-array-access.patch
+remove-console_macrosh.patch
+merge-vt_struct-into-vc_data.patch

Re: Radeon framebuffer weirdness in -mm2

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
> Next suspects would be:
> 
>  +cleanup-vc-array-access.patch
>  +remove-console_macrosh.patch
>  +merge-vt_struct-into-vc_data.patch
> 
> 

Make that:

+cleanup-vc-array-access.patch
+remove-console_macrosh.patch
+merge-vt_struct-into-vc_data.patch
+vgacon-fixes-to-help-font-restauration-in-x11.patch

and the fbdev updates, maybe:

+radeonfb-set-accelerator-id.patch
+vesafb-change-return-error-id.patch
+intelfb-workaround-for-830m.patch
+fbcon-save-blank-state-last.patch
+backlight-fix-compile-error-if-config_fb-is-unset.patch
+matroxfb-fb_matrox_g-kconfig-changes.patch

Re: Radeon framebuffer weirdness in -mm2

[Matt Mackall]

On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Next suspects would be:
> > 
> >  +cleanup-vc-array-access.patch
> >  +remove-console_macrosh.patch
> >  +merge-vt_struct-into-vc_data.patch
> > 
> > 
> 
> Make that:
> 
> +cleanup-vc-array-access.patch
> +remove-console_macrosh.patch
> +merge-vt_struct-into-vc_data.patch
> +vgacon-fixes-to-help-font-restauration-in-x11.patch

It's something in this batch. Which is good, as I'd be a bit
disappointed if the "vt leakage" were somehow attributable to the fb
layer. More bisection after dinner.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Radeon framebuffer weirdness in -mm2

[Roman Zippel]

Hi,

On Thu, 20 Jan 2005, Matt Mackall wrote:

> On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> > Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > Next suspects would be:
> > > 
> > >  +cleanup-vc-array-access.patch
> > >  +remove-console_macrosh.patch
> > >  +merge-vt_struct-into-vc_data.patch
> > > 
> > > 
> > 
> > Make that:
> > 
> > +cleanup-vc-array-access.patch
> > +remove-console_macrosh.patch
> > +merge-vt_struct-into-vc_data.patch
> > +vgacon-fixes-to-help-font-restauration-in-x11.patch
> 
> It's something in this batch. Which is good, as I'd be a bit
> disappointed if the "vt leakage" were somehow attributable to the fb
> layer. More bisection after dinner.

Could you try the patch below. I cleaned up the logic a little in 
redraw_screen() and the code below really wants to do a update_screen().
The old switch_screen(fg_console) behaved like update_screen(fg_console).

bye, Roman

Index: linux-2.6/drivers/video/console/fbcon.c
===================================================================
--- linux-2.6.orig/drivers/video/console/fbcon.c	2005-01-21 13:02:45.000000000 +0100
+++ linux-2.6/drivers/video/console/fbcon.c	2005-01-21 13:03:03.000000000 +0100
@@ -609,7 +609,7 @@
 				   fg_vc->vc_rows);
 	}
 
-	switch_screen(vc_cons[fg_console].d);
+	update_screen(vc_cons[fg_console].d);
 }
 
 /**

Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2

[Antonino A. Daplas]

On Friday 21 January 2005 11:57, Matt Mackall wrote:
> On Thu, Jan 20, 2005 at 04:01:23PM -0800, Andrew Morton wrote:
> > Matt Mackall <mpm@selenic.com> wrote:

> If I do a reboot(8) from inside X, I get switched to vt 0, but the
> shutdown messages come out on vt 7, where X was running. As I'm
> sitting on vt 0 during shutdown, I see character cells changed to
> something like "_" (last two scanlines filled) slowly marching down
> the screen corresponding to the shutdown messages.

Confirmed that this also occurs with vesafb.

This corruption (underscores) is due to the cursor of a not visibile console
being drawn on the foreground display. The console layer should decide when
and where to draw the console but, for now, a simple workaround is to
disallow drawing of the fbcon cursor if the console is not visible.

Signed-off-by: Antonino  Daplas <adaplas@pol.net>
---

 fbcon.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
--- a/drivers/video/console/fbcon.c	2005-01-21 20:15:20 +08:00
+++ b/drivers/video/console/fbcon.c	2005-01-22 00:31:30 +08:00
@@ -1087,7 +1087,7 @@
 	int y = real_y(p, vc->vc_y);
  	int c = scr_readw((u16 *) vc->vc_pos);
 
-	if (fbcon_is_inactive(vc, info))
+	if (fbcon_is_inactive(vc, info) || !CON_IS_VISIBLE(vc))
 		return;
 
 	ops->cursor_flash = 1;

Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2

[Antonino A. Daplas]

On Friday 21 January 2005 20:33, Roman Zippel wrote:
> Hi,
>
> On Thu, 20 Jan 2005, Matt Mackall wrote:
> > On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> > > Andrew Morton <akpm@osdl.org> wrote:
> > > > Next suspects would be:
> > > >
> > > >  +cleanup-vc-array-access.patch
> > > >  +remove-console_macrosh.patch
> > > >  +merge-vt_struct-into-vc_data.patch
> > >
> > > Make that:
> > >
> > > +cleanup-vc-array-access.patch
> > > +remove-console_macrosh.patch
> > > +merge-vt_struct-into-vc_data.patch
> > > +vgacon-fixes-to-help-font-restauration-in-x11.patch
> >
> > It's something in this batch. Which is good, as I'd be a bit
> > disappointed if the "vt leakage" were somehow attributable to the fb
> > layer. More bisection after dinner.
>
> Could you try the patch below. I cleaned up the logic a little in
> redraw_screen() and the code below really wants to do a update_screen().
> The old switch_screen(fg_console) behaved like update_screen(fg_console).
>

Probably does not matter as this particular code is never invoked during
framebuffer initialization (unless one uses fbcon=map:n option). 

Tony

Re: Radeon framebuffer weirdness in -mm2

[Matt Mackall]

On Fri, Jan 21, 2005 at 01:33:39PM +0100, Roman Zippel wrote:
> Hi,
> 
> On Thu, 20 Jan 2005, Matt Mackall wrote:
> 
> > On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> > > Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > > Next suspects would be:
> > > > 
> > > >  +cleanup-vc-array-access.patch
> > > >  +remove-console_macrosh.patch
> > > >  +merge-vt_struct-into-vc_data.patch
> > > > 
> > > > 
> > > 
> > > Make that:
> > > 
> > > +cleanup-vc-array-access.patch
> > > +remove-console_macrosh.patch
> > > +merge-vt_struct-into-vc_data.patch
> > > +vgacon-fixes-to-help-font-restauration-in-x11.patch
> > 
> > It's something in this batch. Which is good, as I'd be a bit
> > disappointed if the "vt leakage" were somehow attributable to the fb
> > layer. More bisection after dinner.
> 
> Could you try the patch below. I cleaned up the logic a little in 
> redraw_screen() and the code below really wants to do a update_screen().
> The old switch_screen(fg_console) behaved like update_screen(fg_console).

Same behaviour.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Radeon framebuffer weirdness in -mm2

[Benjamin Herrenschmidt]

On Thu, 2005-01-20 at 22:09 -0800, Matt Mackall wrote:

> 
> It's something in this batch. Which is good, as I'd be a bit
> disappointed if the "vt leakage" were somehow attributable to the fb
> layer. More bisection after dinner.

Regarding the radeonfb reboot problem, can you try this patch on
top of -mm2 ?

--- linux-work.orig/drivers/video/aty/radeon_base.c	2005-01-24 12:19:09.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_base.c	2005-01-24 14:59:14.000000000 +1100
@@ -2435,13 +2435,16 @@
  
 	radeonfb_pm_exit(rinfo);
 
+#if 0
 	/* restore original state
 	 * 
-	 * Doesn't quite work yet, possibly because of the PPC hacking
-	 * I do on startup, disable for now. --BenH
+	 * Doesn't quite work yet, I suspect if we come from a legacy
+	 * VGA mode (or worse, text mode), we need to do some VGA black
+	 * magic here that I know nothing about. --BenH
 	 */
         radeon_write_mode (rinfo, &rinfo->init_state, 1);
- 
+ #endif
+
 	del_timer_sync(&rinfo->lvds_timer);
 
 #ifdef CONFIG_MTRR