On Sun, 16 Dec 2007, Alon Bar-Lev wrote: > > So, either something is messing with ACPI in a way that causes the firmware > > to change LED state, or something in userspace is screwing off with > > thinkpad-acpi (unlikely). > > userspace is frozen at the point. I sure hope so. > Maybe firmware decides to do this... Is there any way to revert it? It is not that simple. It is nothing thinkpad-acpi does, if a change in the ACPI subsystem changed the way these things are happening, then you will have to open a bug in bugzilla.kernel.org. > > You can add debug printk commands in the LED write paths of thinkpad-acpi, > > to check if something is calling those paths after snapshot. > > This is the problem... During suspend all is frozen... it is very hard > to debug.... You get all printk when you resume. Then you will know the answer. > I am not sure if I can do printk at all... Yes, you can. > Do you use software suspend? Can you reproduce this? No, not anymore. Linux software suspend (all incarnations) under ACPI is just broken by design, and it will take a LOT of effort to fix it (the real design problem is in the resume path, which does very, very unsafe things to an ACPI system). I don't trust my data to it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
