> > > There seem to be chipsets which can get this wrong (especially after > a kexec > > boot on Linux). > > <recording> > > As kexec is fundamentally unreliable by design, > why should reliable software be modified for its beneift? > > </recording> > The problem isn't just with kexec. The lock is acquired by acpi_ev_global_lock_handler() when a global lock release SCI occurs, even when the OS doesn't want it, which sets the "owned" bit on the first SCI and then the "pending" bit on the second SCI. This prevents the global lock from working correctly, even though we're only seeing the OS hang waiting for the semaphore because of this when a kexec boot is attempted. -- 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
