Hi Oldrich,
It might happen that you too have GPE storm on your machine. The patch
to workaround it was placed in 9998 and 10724 bug reports.
So, for a start you could check if the last patch in 9998 makes any difference.
We probably could drop wait_event_timeout() as the last resort.
Regards,
Alex.
Oldrich Jedlicka wrote:
On Thursday 04 of September 2008 at 14:18:20, Andi Kleen wrote:
On Tue, Aug 26, 2008 at 01:57:34PM +0800, Zhao Yakui wrote:
Subject: ACPI: Avoid bogus timeout about SMbus check
>From : Zhao Yakui <yakui.zhao@xxxxxxxxx>
In the function of wait_transaction_complete when the timeout happens,
OS will try to check the status of SMbus again. If the status is what OS
expected, it will be regarded as the bogus timeout. Otherwise it will be
treated as ETIME.
http://bugzilla.kernel.org/show_bug.cgi?id=10483
I added it for 2.6.27 thanks (since it seems to be a regression)
Hi all,
the problem in bug 10483 isn't solved, unfortunately the patch applied to
2.6.27 isn't the one I tested.
The problem I face is that wait_transaction_complete() in sbshc.c doesn't take
at most "timeout" time (=one second), but it rather often takes very long
time to complete on my system (several minutes) - notebook Acer TravelMate
4502WLMi.
To describe the problem I need to go into wait_event_timeout() macro as used
in wait_transaction_complete(): it first calls the user method
smb_check_done() to check if the loop should end and if not, it waits for at
most "timeout" time. The wait can be woken-up by a wake_up() method and if
so, it remembers the remaining "timeout", repeats the call to user method
smb_check_done() and possibly continues with wait (with the
remaining "timeout"). This is done in a loop.
Now my problem: the wait_event_timeout() loop takes several minutes instead of
one second (as specified by the parameter "timeout"). The reason for that - as
I think - is this:
1. The smb_check_done() method called each loop takes some time to execute,
but this time is not included into the overall timeout.
2. The wait_event_timeout() is woken-up by smbus_alarm() very early each
loop, so the remaining "timeout" gets lower very slow (I think it is so, but
I haven't verified this hypothesis yet).
So my question is what I shoud do now? If you want to see some logs (and the
original patch), please go to my bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=10483
Thanks.
Note: I'm building my house after my normal work, so I don't have much time
left, but I will do my best to try whatever you suggest. And sorry for my
english :-)
Regards,
Oldrich.
--
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
