> Hmm. We can't restore the top 32-bits of the cycle counter, can we...
But why should it matter? Can't we just guarantee the APM code is the
first to get control after a resume and have it figure out what the new
"epoch" is by reinitializing things?
> <tangent>
> APM 1.2 implemented in the kernel, though. ;-) ] I had gotten reports that
> the BSD apm code worked in cases where the linux code didn't
The main difference I recall between the BSD and linux APM implementations
is that the BSD implementation is synchronous -- it processes one event at
a time, and doesn't queue up events like the linux code does.
At any rate this week I had my tp560 refuse to suspend for me... even with
the patch that I wrote ages ago to fix that. Something else is missing,
dunno what yet though.
I wonder, I wonder if windows uses the 32-bit protected mode interface,
the 16-bit protected mode interface, or the real mode interface to the APM
bios ... Hmm! Wild guess: the 16-bit interfaces are well debugged
because that's what win95 uses (NT 3/4 don't use APM AFAIK), but the
32-bit interface is lacking.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu