http://bugzilla.kernel.org/show_bug.cgi?id=9147
------- Comment #39 from [EMAIL PROTECTED] 2007-11-23 08:35 ------- there are several ways ACPI driver (ac/battery/thermal...) could contact real hardware, all of them are guarded by operation regions. ACPI by itself (interpreter) supports system memory, system i/o and pci config. EC driver creates one more type of region -- ec region. In most cases drivers above will go through op. region defined by EC, just because battery, charger control and thermal sensors are connected to EC. This is why so many people asked you to disable EC driver in order to localize problem. Your case is different, as I said before -- drivers get information through op.region in system memory. It will probably be mapped to some slow hardware, not generic RAM -- may be same EC, so access to it takes some time. So far so good. Problem could arrive, if access to this memory region is guarded with spinlock inside ACPI, thus interrupts are disabled for the whole duration of the access (up to several hundred of milliseconds). I hope this amount of theory is enough for a moment, let's switch to practice: there is no kernel option which could help you; but I will to try to come up with a patch to remove the disabling of interrupts during such accesses, if it indeed happens, you just have to wait... -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
