13 Feb, 2007

1 commit

  • During kernel bootup, a new T60 laptop (CoreDuo, 32-bit) hangs about
    10%-20% of the time in acpi_init():

    Calling initcall 0xc055ce1a: topology_init+0x0/0x2f()
    Calling initcall 0xc055d75e: mtrr_init_finialize+0x0/0x2c()
    Calling initcall 0xc05664f3: param_sysfs_init+0x0/0x175()
    Calling initcall 0xc014cb65: pm_sysrq_init+0x0/0x17()
    Calling initcall 0xc0569f99: init_bio+0x0/0xf4()
    Calling initcall 0xc056b865: genhd_device_init+0x0/0x50()
    Calling initcall 0xc056c4bd: fbmem_init+0x0/0x87()
    Calling initcall 0xc056dd74: acpi_init+0x0/0x1ee()

    It's a hard hang that not even an NMI could punch through! Frustratingly,
    adding printks or function tracing to the ACPI code made the hangs go away
    ...

    After some time an additional detail emerged: disabling the NMI watchdog
    made these occasional hangs go away.

    So i spent the better part of today trying to debug this and trying out
    various theories when i finally found the likely reason for the hang: if
    acpi_ns_initialize_devices() executes an _INI AML method and an NMI
    happens to hit that AML execution in the wrong moment, the machine would
    hang. (my theory is that this must be some sort of chipset setup method
    doing stores to chipset mmio registers?)

    Unfortunately given the characteristics of the hang it was sheer
    impossible to figure out which of the numerous AML methods is impacted
    by this problem.

    As a workaround i wrote an interface to disable chipset-based NMIs while
    executing _INI sections - and indeed this fixed the hang. I did a
    boot-loop of 100 separate reboots and none hung - while without the patch
    it would hang every 5-10 attempts. Out of caution i did not touch the
    nmi_watchdog=2 case (it's not related to the chipset anyway and didnt
    hang).

    I implemented this for both x86_64 and i686, tested the i686 laptop both
    with nmi_watchdog=1 [which triggered the hangs] and nmi_watchdog=2, and
    tested an Athlon64 box with the 64-bit kernel as well. Everything builds
    and works with the patch applied.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Andi Kleen
    Cc: Andi Kleen
    Cc: Len Brown
    Signed-off-by: Andrew Morton

    Ingo Molnar
     

07 Dec, 2006

1 commit

  • When a spinlock lockup occurs, arrange for the NMI code to emit an all-cpu
    backtrace, so we get to see which CPU is holding the lock, and where.

    Cc: Andi Kleen
    Cc: Ingo Molnar
    Cc: Badari Pulavarty
    Signed-off-by: Andrew Morton
    Signed-off-by: Andi Kleen

    Andrew Morton
     

30 Sep, 2006

1 commit

  • touch_nmi_watchdog() calls touch_softlockup_watchdog() on both
    architectures that implement it (i386 and x86_64). On other architectures
    it does nothing at all. touch_nmi_watchdog() should imply
    touch_softlockup_watchdog() on all architectures. Suggested by Andi Kleen.

    [heiko.carstens@de.ibm.com: s390 fix]
    Signed-off-by: Michal Schmidt
    Cc: Andi Kleen
    Cc: Martin Schwidefsky
    Signed-off-by: Heiko Carstens
    Cc: Michal Schmidt
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Schmidt
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds