KDL when I turn off the laptop: SMAP Violation user-mapped address

[atomozero]

When I restart my laptop everything works perfectly, otherwise when I turn it off the system goes into kernel debug land, presumably because of the ACPI drivers. I am using a nightly build of Haiku (hrev57564) and I cannot say when this problem started.

[waddlesplash]

If you can type at the KDL prompt, can you please run "area <address>" on the address from the initial message ("SMAP violation at ...")?

[korli]

Area info

[korli]

I've the same problem (warning: text recognition is a bit incorrect)

kdebug area contains 8xffffffff823058d8

AREA: 0xffffffff80b88e78

name:

owner:

id:

base:

acpi_physical_nem_area"

8x1

8x9a35

Bxffffffff82305000

size:

0x1000

protection:

Bx30

page_protection:0x0000000000000000

wiring:

8x2

memory_type:

0x10808800

cache:

Bxffffffff806930f0

cache_type: cache_offset:

device

8x8

cache_next: 0x0000000000000000

cache_prev:

page nappings: 0

kdebug

[waddlesplash]

Strange, that area is mapped with KERNEL permissions only: ​https://xref.landonf.org/source/xref/haiku/src/add-ons/kernel/bus_managers/acpi/ACPICAHaiku.cpp#472

And 0x30 is only those two kernel protections; plus page_protection is NULL as expected. So what's going on here? How is this an SMAP violation?

[atomozero]

area 0xffffffff825630aa

[waddlesplash]

Uh, unless I am missing something, neither of the areas returned by "area contains" (both from korli and atomozero) actually contains the address in question; both are too small. That seems very strange?

[korli]

Replying to waddlesplash:

Uh, unless I am missing something, neither of the areas returned by "area contains" (both from korli and atomozero) actually contains the address in question; both are too small. That seems very strange?

I don't get it. Size is 0x1000 The areas actually contain the addresses in question.

[waddlesplash]

Ah, I was looking at the wrong field, you're correct.

But there still remains the question of how we are getting a SMAP violation on an area that doesn't appear to be user-mapped.

[korli]

I see the area in question wasn't allocated yet before initiating the shutdown process.

[pulkomandy]

I'm looking at src/system/kernel/arch/x86/arch_int.cpp and I see we have a long list of if/else to decide what type of fault it is. It could be that the conditions for deciding that it is a SMAP violation somehow end up being verified when they shouldn't, and it's just another type of fault.

For example, Linux checks the U bit in the fault error code, but we check only the P bit

​https://elixir.bootlin.com/linux/latest/source/arch/x86/mm/fault.c#L1277

According to the comments they added this because of the WRUSS instruction which introduces a special case where the code is running from the kernel, but actually explicitly trying to write to userspace:

​https://www.felixcloutier.com/x86/wrussd:wrussq

I don't see why we would be using that, but maybe there are some other edge cases here. Did you have a look at the disassembly of the crashing code to see exactly what it is doing?

[waddlesplash]

I think this may not really be a SMAP violation except by coincidence. I've encountered "SMAP violations" before that didn't make much sense, but when I "co"'d, I got a standard page fault, if memory serves. Can someone who can reproduce this problem try that and see if you get a second, different, KDL?

[atomozero]

If you tell me what commands to give, I'll be happy to try them tonight. :)

[pulkomandy]

The command is "continue", or "co" for short

[atomozero]

KDL 1° Screenshot

[atomozero]

KDL 2° Screenshot - 1° Continue

[atomozero]

KDL 3° Screenshot - 2° Continue