[kernel] crashes by running Settlers game in DOSBox

[diver]

hrev52547, 32bit Haiku

To reproduce:

pkgmain ins dosbox
DOSBox
mount c /boot/home
c:
sett.exe

[diver]

x86_64 seems unaffected. However, DOSBox quits with this message:

Exit to error: DRC64:Unhandled memory reference

[ttcoder]

Same here. Curiously, the kernel crash goes away if downgrading the package: if I fetch an older version (revision, actually: something like dosbox 0.74-1 instead of 0.74-3, gotta check) from the "administrative" folder, and install that, I can play with 100% stability.

[waddlesplash]

int_bottom_user for 32-bit unconditionally disables interrupts and doesn't re-enable them: ​http://xref.plausible.coop/source/xref/haiku/src/system/kernel/arch/x86/32/interrupts.S#553

int_bottom_user for 64-bit never disables interrupts at all: ​http://xref.plausible.coop/source/xref/haiku/src/system/kernel/arch/x86/64/interrupts.S#244

So, it seems 32-bit int_bottom_user should just leave interrupts enabled, yes? Or is there something else I'm missing? The interrupt handler code is largely shared between 32-bit and 64-bit, so one of these is definitely a bug.

[waddlesplash]

CC mmlr: you know more about the x86 interrupt handling routines than I do, can you check my above analysis?

[mmlr]

As discussed on IRC, the panic states that interrupts were disabled at fault time, i.e. iframe flags has the interrupt flag cleared, not that they are disabled when entering the handler.

Interrupts are supposed to be disabled at/by the int_bottom_user and stay disabled into the handler functions, as the comment in the x86 version states. The pagefault handler reenables them after doing its initial checks.

The difference between x86 and x86_64 is that the latter always uses syscall/sysret instead of possibly using legacy software interrupts and the mask MSR includes the interrupt flag bit. Hence in x86_64 interrupts are always already disabled when reaching int_bottom_user and there is no need for disabling them there through cli.

[KapiX]

I've seen this when I replaced an .so used by a running program. However, I did not manage to reproduce it (got it once, most of the time it just crashes). Stack trace is not really relevant, since it crashed in border_style() (called from BWindow::task_looper).

[waddlesplash]

As per #14017, this occurs on x64 too. x64 uses SYSRET and IRET to return to userland; SYSRET gets RFLAGS from R11, whereas IRET gets RFLAGS from the stack. I didn't verify that the R11 vs. stack handling is correct in our interrupt code, but if it is, that would kick this bug into the iframe handling, I think?

[korli]

​https://review.haiku-os.org/c/haiku/+/4046

[waddlesplash]

Fixed in hrev55135.