Re: oops pauser.



Some comments:
1. I think this is a good idea, since serial consoles can also change
timings. I have seen several race conditions where the problem goes
away once I add a serial console.
2. Should this be a separate debugging option?
3. Shouldn't you have KERN____ in your printk statements?
4. Wouldn't printing out the message every second make the oops scroll
off the screen, defeating the purpose of the patch?

Avishay Traeger
http://www.fsl.cs.sunysb.edu/~avishay/

On Wed, 2006-01-04 at 23:52 -0500, Dave Jones wrote:
> In my quest to get better debug data from users in Fedora bug reports,
> I came up with this patch. A majority of users don't have serial
> consoles, so when an oops scrolls off the top of the screen,
> and locks up, they usually end up reporting a 2nd (or later) oops
> that isn't particularly helpful (or worse, some inconsequential
> info like 'sleeping whilst atomic' warnings)
>
> With this patch, if we oops, there's a pause for a two minutes..
> which hopefully gives people enough time to grab a digital camera
> to take a screenshot of the oops.
>
> It has an on-screen timer so the user knows what's going on,
> (and that it's going to come back to life [maybe] after the oops).
>
> The one case this doesn't catch is the problem of oopses whilst
> in X. Previously a non-fatal oops would stall X momentarily,
> and then things continue. Now those cases will lock up completely
> for two minutes. Future patches could add some additional feedback
> during this 'stall' such as the blinky keyboard leds, or periodic speaker beeps.
>
> Signed-off-by: Dave Jones <davej@xxxxxxxxxx>
>
> --- vanilla/arch/i386/kernel/traps.c 2006-01-02 22:21:10.000000000 -0500
> +++ linux-2.6.15/arch/i386/kernel/traps.c 2006-01-04 23:42:46.000000000 -0500
> @@ -256,6 +271,15 @@ void show_registers(struct pt_regs *regs
> }
> }
> printk("\n");
> + {
> + int i;
> + for (i=120;i>0;i--) {
> + mdelay(1000);
> + touch_nmi_watchdog();
> + printk("Continuing in %d seconds. \r", i);
> + }
> + printk("\n");
> + }
> }
>
> static void handle_BUG(struct pt_regs *regs)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • RE: Oops in driversasefirmware_class
    ... I have discovered a Oops in the firmware_loading_store function. ... I have tried the patch and it works for me. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: [POWERPC] Fix for assembler -g
    ... Oops! ... It looks like the patch that got committed is ... More majordomo info at http://vger.kernel.org/majordomo-info.html ... Please read the FAQ at http://www.tux.org/lkml/ ...
    (Linux-Kernel)
  • Re: [PATCH] memcg: fix stale swap cache leak v5
    ... about 600MB leak of swap cache before applying this patch, ... Oops, not 600MB but 600KB. ... Daisuke Nishimura. ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (Linux-Kernel)
  • Re: [another PATCH] Fix crash on boot in kmalloc_node IDE changes
    ... >> actual OOPS would be very useful ... Maybe we can settle on this patch until we know for sure that the hwif ... send the line "unsubscribe linux-kernel" in ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (Linux-Kernel)
  • Re: [PATCH] [revised -- version 2] Info dump on Oops or panic()
    ... On Thu, 28 Jun 2007, Kyle McMartin wrote: ... Barring any other problems with the patch, ... and informed me that my uptime was 0.38 seconds. ... * Dump out UTS info on oops / panic. ...
    (Linux-Kernel)