Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ACPI sleep issues (trap 4)



Hi Maxime,

Maxime Villard wrote:

trap 4 seems to be:
#define    T_PROTFLT     4    /* protection fault */

it's possible ddb is wrong about the next function because there's
assembly/maybe inlining and it is failing at:
acpi_md_sleep_prepare-> acpi_md_sleep_enter -> acpi_md_sleep_patch

I wouldn't expect ACPI sleep to be reliable, there are several sets of
registers that are not saved & restored. By the way, there are also several
issues in ddb; as far as I remember, it sometimes miscomputes the symbol
address and gives a wrong function, the disassembler also gets confused with
opcodes, etc.

In short, very few things work in there.

The last function sounds like it may violate W^X unless it's
careful, but I'm not sure what is going on with ACPI and suspend.

A one-page vm space is created for the ACPI trampoline, and this page is
indeed RWX. But there are good reasons for this, and basically once awake the
cpu restores the previous space, so this rwx page is gone right away.

what does it mean for us practically? That analyzing crashes is not feasible to drill down what is happening?
I hope not generally meaning no chance to support things.

A bit more contest though. This is not AMD64 but i386.
I have an amd64 laptop which, except for display/intel915 issues is capable of going to sleep and also awakening again with a working WiFi. I yield a black screen and a dead wired ethernet. The approach up to now was getting a kernel panic after the other and identifying the various buggy drivers, which Maya mostly fixed.

I want then to get at least as good as here on my T31 and R51 i38 ThinkPads and thus I am testing current kernels and disabling drivers. Intel too is causing havoc on the R51, not makign the machine go to sleep at all. Disabling that I get into the crash said above, so what is broken now?

Riccardo




Home | Main Index | Thread Index | Old Index