On Thu, 22 Jun 2006 00:28:56 -0400 "Brown, Len" <len.brown@xxxxxxxxx> wrote: > >It looks like an ACPI problem. > > Thanks for the note, and the .config, I reproduced it here. > > CONFIG_LOCKDEP complains about this sequence: > > ... > <presumed previous acquire/release acpi_gbl_hardware_lock> > ... > acpi_ev_gpe_detect() > spin_lock_irqsave(acpi_gbl_gpe_lock,) > > spin_lock_irqsave(acpi_gbl_hardware_lock,) <stack trace is on > this acquire> > spin_lock_irqrestore(acpi_gbl_hardware_lock,) > > ... > > spin_lock_irqrestore(acpi_gbl_gpe_lock) > > It complains about this only the 1st time, even though > this same code sequence runs for every (subsequent) ACPI interrupt. > > The intent of the arrangement is that acpi_gbl_hardware_lock is for very > small critical sections around RMW hardware register access. > It can be acquired with or without other locks held, but > nothing else is acquired when it is held. > > Nothing jumps out at me as incorrect above, so > at this point it looks like a CONFIG_LOCKDEP artifact -- > but lets ask the experts:-) Yes, lockdep uses the callsite of spin_lock_init() to detect the "type" of a lock. But the ACPI obfuscation layers use the same spin_lock_init() site to initialise two not-the-same locks, so lockdep decides those two locks are of the same "type" and gets confused. We had earlier decided to remove that ACPI code which kmallocs a single spinlock. When that's done, lockdep will become unconfused. AFACIT it's all used for just two statically allocated locks anwyay. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
