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.
Matt Mackall <[email protected]> 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?
On Thu, Jan 20, 2005 at 03:39:21PM -0800, Andrew Morton wrote:
> Matt Mackall <[email protected]> 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.
Matt Mackall <[email protected]> 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
On Thu, 2005-01-20 at 15:39 -0800, Andrew Morton wrote:
> Matt Mackall <[email protected]> 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.
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 <[email protected]> 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.
> > > > 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?
On Thu, Jan 20, 2005 at 04:01:23PM -0800, Andrew Morton wrote:
> Matt Mackall <[email protected]> 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.
Matt Mackall <[email protected]> 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
Andrew Morton <[email protected]> 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
On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> Andrew Morton <[email protected]> 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.
Hi,
On Thu, 20 Jan 2005, Matt Mackall wrote:
> On Thu, Jan 20, 2005 at 08:07:11PM -0800, Andrew Morton wrote:
> > Andrew Morton <[email protected]> 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);
}
/**
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 <[email protected]> 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 <[email protected]>
---
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;
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 <[email protected]> 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
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 <[email protected]> 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.
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