Opened 2 years ago

Last modified 2 years ago

#17427 new bug

Trashwatcher KDL on usb stick mount

Reported by: nephele Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: File Systems/FAT Version: R1/beta3
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description (last modified by nephele)

I inserted a usb drive, on mounting it i have gotten a kdl hrev55667

KERN: PANIC: ASSERT FAILED (src/add-ons/kernel/file_systems/fat/fat.cpp:444): 0
KERN: Welcome to Kernel Debugging Land...
KERN: Thread 926 "TrashWatcher" running on CPU 4
KERN: stack trace for thread 926 "TrashWatcher"
KERN:     kernel stack: 0xffffffff807ed000 to 0xffffffff807f2000
KERN:       user stack: 0x00007ff55d6be000 to 0x00007ff55d6fe000
KERN: frame                       caller             <image>:function + offset
KERN:  0 ffffffff807f1468 (+  24) ffffffff801522cc   <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16
KERN:  1 ffffffff807f1480 (+  80) ffffffff800aecc8   <kernel_x86_64> debug_call_with_fault_handler + 0x88
KERN:  2 ffffffff807f14d0 (+  96) ffffffff800b0651   <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0xf1
KERN:  3 ffffffff807f1530 (+  80) ffffffff800b094e   <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x6e
KERN:  4 ffffffff807f1580 (+ 240) ffffffff800b0cc7   <kernel_x86_64> panic + 0xb7
KERN:  5 ffffffff807f1670 (+  64) ffffffff82618058   <fat> count_clusters[clone .localalias.2] (_nspace*, int) + 0xb8
KERN:  6 ffffffff807f16b0 (+ 720) ffffffff82612976   <fat> dosfs_read_vnode(fs_volume*, long, fs_vnode*, int*, unsigned int*, bool) + 0x5c6
KERN:  7 ffffffff807f1980 (+ 128) ffffffff801043f2   <kernel_x86_64> get_vnode(int, long, vnode**, bool, int) + 0x382
KERN:  8 ffffffff807f1a00 (+  80) ffffffff80109d42   <kernel_x86_64> get_vnode + 0x32
KERN:  9 ffffffff807f1a50 (+ 688) ffffffff82611012   <fat> findfile(_nspace*, vnode*, char const*, long*, vnode**, bool, bool, bool*) + 0x1d2
KERN: 10 ffffffff807f1d00 (+  96) ffffffff82612bb0   <fat> dosfs_walk(fs_volume*, fs_vnode*, char const*, long*) + 0x80
KERN: 11 ffffffff807f1d60 (+  64) ffffffff801047ec   <kernel_x86_64> lookup_dir_entry(vnode*, char const*, vnode**) + 0x8c
KERN: 12 ffffffff807f1da0 (+ 144) ffffffff80104a8f   <kernel_x86_64> vnode_path_to_vnode(vnode*, char*, bool, int, io_context*, vnode**, long*) + 0x17f
KERN: 13 ffffffff807f1e30 (+  80) ffffffff8010512c   <kernel_x86_64> vnode_path_to_vnode[clone .constprop.138] (vnode*, char*, bool, int, bool, vnode**, long*) + 0x3c
KERN: 14 ffffffff807f1e80 (+  64) ffffffff801076cf   <kernel_x86_64> file_open(int, char*, int, bool) + 0x2f
KERN: 15 ffffffff807f1ec0 (+  96) ffffffff8010f2de   <kernel_x86_64> _user_open + 0x9e
KERN: 16 ffffffff807f1f20 (+  16) ffffffff80153ebf   <kernel_x86_64> x86_64_syscall_entry + 0xfb}}}

Change History (3)

comment:1 by nephele, 2 years ago

Description: modified (diff)

comment:2 by waddlesplash, 2 years ago

Is it consistently reproducible? It looks like this means the FAT is corrupt. Not sure what should be done about that.

comment:3 by nephele, 2 years ago

Yes, it is reproducible

Note: See TracTickets for help on using tickets.