Hi!
I'm really willing to help the APM developers to track down this bug
but don't have a clue how to debug this kind stuff.
What APM developers? There are none as far as I know.
Hmmm ... So once again the Tooth Fairy and Santa Claus :-) ?
At least a
grep '<.*@' /usr/src/linux-2.6.6/arch/i386/kernel/apm.c | sed 's/.*<//' | sed 's/>.*//'
gives me:
<snip>
Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx
...
chen@xxxxxxxxxxxxxx
</snip>
This is pretty much for no one. And I guess you knew since you're on
the list yourself. But I think you're right when meaning
that there is not much of active maintenance anymore. Which at
least I find a little bit discouraging when looking of the state
of the ACPI support.
Yes, that's pretty much what I meant. ACPI has ~5 people actively
working on it, some of them probably full-time. That's a lot of
manpower, compared to APM.
And ACPI is in pretty good state, btw, unless you want
suspend-to-RAM. Unfortunately you want suspend-to-RAM.
Try removing calls to device_* in apm.c. Better yet become APM
developer.
It seems like I'm on my way to do so (still reluctantly). As I stated
in my previous mails I'm not born as a hardware/BIOS hacker (more the
application C++/Java stuff) but I'm willing to learn. When I'm
grown up I definitely want to be linux kernel hacker :-) ...
Currently I ripped down the 2.6.6 kernel to almost nothing
and add one module after the other checking for proper
suspend/resume behavior....
The most suspicious candidates on my list are currently the
USB-UHCI driver and the ALSA sound system, which is my #1 candidate
since it has not been an integral part of the 2.4.x (x<=20) kernels.
So if anybody out there could give me guidance on how the apm code
might interact with the ALSA sound system it would be highly
appreciated....
device_suspend() will propagate all the way to alsa.
Pavel