KDL during git pull

[smallstepforman]

KDL during git pull, reproducible (always) Running Haiku Rev 50551 (see attachement) The last time I ran git clone was for Rev 50490, worked without any issues.

Description:
PANIC: vm_page_fault: unhandled page falut in kernel space at 0x0, ip 0x800e90b6
Welcome to Kernel Debugging Land...
Thread 2034 "team 2019" handler running on CPU 4
stack trace for thread 2034 "team 2019 handler"
kernel stack: 0x821fc000 to 0x82200000
user stack: 0x71f63000 to 0x71fa3000
frame   caller  <image>:function + offset
0 821ff47c (+32) 8014e942  <kernel_x86> arch_debug_stack_trace + 0x12
1 821ff49c (+16) 800a9ccb  <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
2 821ff3ac (+12) 801406ce  <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
3 821ff4b8 (+48) 800ab7ee  <kernel_x86> debug_call_with_fault_handler + 0x5a
4 821ff4e8 (+64) 800a9ee7  <kernel_x86> kernel_debugger_loop(0x80192c37 "PANIC: ", 0x801a98e0 "vm_page_fault: unhandled page fault in kernel space at 0x%1x, ip0x%1x", "0x821ff594 "",, int32: 4) + 0x217
5 821ff528 (+48) 800aa263  <kernel_x86> kernel_debugger_internal(0x80192c37 "PANIC: ", 0x801a98e0 "vm_page_fault: unhandled page fault in kernel space 0x%1x, ip 0x%1x", 0x821ff594 "", int32: 4) + 0x53
6 821ff558 (+48) 800abb7a  <kernel_x86> panic + 0x3a

See picture for detailed report

[smallstepforman]

Booting Rev 50490 (from USB stick) and performing a git pull doesn't go to KDL, it comes up with segment violation (see IMG 4759.jpg). The git pull/status was for haiku.

Function _sha1_block_data_order_ssse3 + 0xbf2

[smallstepforman]

A final comment - the KDL may be due to corruption while reading files across the USB bus. Haiku is running on a 2014 gen MacBook Pro, booted from external USB hard disk (50551), or memory stick (rev 50490). When running git pull from 50490 (memory stick) and using the file system on 50551 (hard disk) (both USB ports occupied, both mounted a Haiku file system), the mounted hard disk image after the segment violation appeared corrupted. Rebooting to 50551 showed that the data integrity was intact, not corrupted, hence there is the possibility that a bad read operation caused Haiku to go into KDL or segmentation fault. The error might be XHCI related (corrupt read requests, hence the KDL/segment violations).

[pulkomandy]

The crash happens in libdebug, apparently it is doing a symbol search on a NULL symbol.

[korli]

I know for sure git makes untypical disk requests (I think mmap), which are failing with the XHCI USB bus driver when they are beyond a threshold (typically 1MB). Next step would be a reduced testcase.

[smallstepforman]

Seems to be fixed in hrev51692, possibly due to commit from Augustin Cavalier <waddlesplash@…> (​https://cgit.haiku-os.org/haiku/commit/?id=019828aba71a25f9f952bc6fd51b57c77be1f8a2). Thanks Augustin.

Possibly safe to close (korli/Pulko/Augustin)

[waddlesplash]

Very interesting.... Thanks for the update!

[mmlr]

The KDL does not go through that code at all, the referenced commit does not affect this. Generally the vnode disconnect code path is used only in some very special circumstances, like forced unmounts and should be rather rare in normal usage.