Re: Radeon framebuffer weirdness in -mm2
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.0 +1100 +++ linux-work/drivers/video/aty/radeon_base.c 2005-01-24 14:59:14.0 +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, >init_state, 1); - + #endif + del_timer_sync(>lvds_timer); #ifdef CONFIG_MTRR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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.0 +1100 +++ linux-work/drivers/video/aty/radeon_base.c 2005-01-24 14:59:14.0 +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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
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; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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.c2005-01-21 13:02:45.0 +0100 +++ linux-2.6/drivers/video/console/fbcon.c 2005-01-21 13:03:03.0 +0100 @@ -609,7 +609,7 @@ fg_vc->vc_rows); } - switch_screen(vc_cons[fg_console].d); + update_screen(vc_cons[fg_console].d); } /** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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.c2005-01-21 13:02:45.0 +0100 +++ linux-2.6/drivers/video/console/fbcon.c 2005-01-21 13:03:03.0 +0100 @@ -609,7 +609,7 @@ fg_vc-vc_rows); } - switch_screen(vc_cons[fg_console].d); + update_screen(vc_cons[fg_console].d); } /** - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
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; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
> > > > 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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] Re: Radeon framebuffer weirdness in -mm2
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Radeon framebuffer weirdness in -mm2
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/