Re: suspend-to-RAM intel-x86 issues and tests

[maya%netbsd.org@localhost]

On Tue, Oct 09, 2018 at 01:12:31AM +0200, Riccardo Mottola wrote:
> acpi0: entering state S3
> flushing disk caches: 16 done
> fatal protection fault in supervisor mode
> trap type 4 code 0 eip 0xc0135ea3 cd 0x8 eflags 0x210046 cr2 0xdac2b0c4
> ilevel 0x8 esp 0xc1210c80
> curlwp 0xc36422c0 pid 658 lid 1 lowest kstack 0xdb8702c0
> panic: trap
> cpu0 Begin traceback...
> vpanic (.....) at netbsd:vpanic+0x132
> snprintf(....) at netbsd:snprintf
> trap_tss() at netbsd:trap_tss
> --- trap via task gate ---
> netbsd: cpu_info_primary:

Hey, useful info!
cpu_info_primary isn't a function though, which is weird.
eip 0xc0135ea3 is also an interesting thing to note and we should search
by hand if it is in a function too

what does
gdb /path/to/netbsd
gdb> disas 0xc0135ea3

say?

osdev wiki says:

Invalid TSS (this might be the right one)

An Invalid TSS exception occurs when an invalid segment selector is referenced as part of a task which, or as a result of a control transfer through a gate descriptor, which results in an invalid stack-segment reference using an SS selector in the TSS.
When the exception occurred before loading the segment selectors from the TSS, the saved instruction pointer points to the instruction which caused the exception. Otherwise, and this is more common, it points to the first instruction in the new task.

Error code: The Invalid TSS exception sets an error code, which is a selector index. 

so that says it's expected that the eip won't be useful. I'm currently
trying to see (with my limited x86 clue) what code is touching tss.

does anyone have a better clue how to debug this?