Re: 2.6.13-rc6-rt6

From: Ingo Molnar (mingo_at_elte.hu)
Date: 08/17/05

  • Next message: yhlu: "Re: 2.6.12.3 clock drifting twice too fast (amd64)"
    Date:	Wed, 17 Aug 2005 08:47:50 +0200
    To: Steven Rostedt <rostedt@goodmis.org>
    
    

    * Steven Rostedt <rostedt@goodmis.org> wrote:

    > On Wed, 2005-08-17 at 00:20 -0400, Steven Rostedt wrote:
    > > Ingo,
    > >
    > > FYI, I ran this on my laptop (Pentium4 HT) and it locked up shortly
    > > after it started INIT. I rebooted, and now it's up and running
    > > with no problems!?! I'll reboot it a few more times to see if it will
    > > lock up again.
    >
    > With a small change it locks up all the time :-)

    unfortunately the space of "patches that break the kernel" is infinitely
    larger (and infinitely easier to generate) than the space of "patches
    that improve the kernel" - so i'll skip your patch for now ;-)

    > > Oh, I also did get the message when it started:
    > >
    > > WARNING: kstopmachine/859 changed soft IRQ-flags.
    > > [<c0149e0b>] stop_machine+0x11b/0x160 (8)
    > > [<c0149e7e>] do_stop+0xe/0x70 (32)
    > > [<c0139c5a>] kthread+0xba/0xc0 (16)
    > > [<c0139ba0>] kthread+0x0/0xc0 (28)
    > > [<c0101385>] kernel_thread_helper+0x5/0x10 (16)
    >
    > I replaced this with raw_local_irq_disable and it really locks up
    > everytime now. I need to look into how this is best done.

    how come it is stopping the machine during bootup? Or does the lockup
    occur during shutdown? changing the local_irq_disable() to
    raw_local_irq_disable() looks wrong because sooner or later we hit
    complete(). You are probably locking up earlier than that though,
    perhaps in stopmachine_set_state()?

    but stop_machine() looks quite preempt-unsafe to begin with. The
    local_irq_disable() would not be needed at all if prior the
    for_each_online_cpu() loop we'd use set_cpus_allowed. The current method
    of achieving 'no preemption' is simply racy even during normal
    CONFIG_PREEMPT.

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


  • Next message: yhlu: "Re: 2.6.12.3 clock drifting twice too fast (amd64)"

    Relevant Pages

    • Re: X unkillable in R state sometimes on startx , /proc/sysrq-trigger T output attached
      ... Box is still reachable via ssh ... > startup to reboot. ... ssh in from remote box, take SysRQ dumps, reboot ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: File access error fixed with mount -o remount ?
      ... yesterday, egrep just stopped working. ... reboot. ... Today it was "sed" that stopped being runnable with the same error message. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: amanda vs 2.6
      ... I forgot in case you aren't fam with amanda, much of it will not run ... I see after the reboot the default value is 0 now. ... Copyright 2003 by Maurice Eugene Heskett, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [2.6.x] reboot fails on AMD Athlon System
      ... > Maybe in the apic disabling code, though it looks very similar to the ... ...and it still refuses to reboot -- so the code change which ... Sascha Wilde: The sum of intelligence on earth is a constant; ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Request: I/O request recording
      ... > next reboot. ... > that everything which you will need in the subsequent boot is already in ... > pretty much a waste of time, gaining only 10% or so, from memory. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)