Le 19/09/2017 à 08:22, coypu%sdf.org@localhost a écrit :
hi maxv, port-amd64, Riccardo has problems with suspend (which has always been problematic for various driver reasons, too, so the cause may be something else entirely). On Tue, Sep 19, 2017 at 01:17:32AM +0200, Riccardo Mottola wrote:--- trap (number 4) --- acpi_md_sleep_prepare(3,c387f908,3,39,0,bfba1760,c353712c,dc33be80,dc33be90,c03c743a) at acpi_md_sleep_prepare+0x37 acpi_enter_sleep_state(3,dc33bf04,dc33bf00,bfba1764,dc33bf14,3,1000272,42f,74617473,65) at acpi_enter_sleep_state+0x15c sysctl_hw_acpi_sleepstate(dc33bf14,0,bfba1764,dc33bf00,bfba1760,4,dc33bf04,c46932c0,c35370cc,4) at sysctl_hw_acpi_sleepstate+0xbatrap 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. Maxime