Re: NTFS directory read lockup
Joseph M. Malicki (malicki.1@osu.edu)
Sun, 17 Jan 1999 12:10:12 -0500
On Sun, 17 Jan 1999, Stanislav Meduna wrote:
>An update:
>
>I cannot reproduce the crash if I'm doing the find
>only in the NTFS root. If I do it from /, it comes
>quite reproducibly (but this is probably only
>a coincidence).
>
>> >>EIP: c6825100 <cleanup_module+307c/10fc8>
>> Trace: c6825bfd <cleanup_module+3b79/10fc8>
>> Trace: c68269b1 <cleanup_module+492d/10fc8>
>> Trace: c6825be4 <cleanup_module+3b60/10fc8>
>> Trace: c6826004 <cleanup_module+3f80/10fc8>
>> Trace: c682bd60 <cleanup_module+9cdc/10fc8>
>> Trace: c6826bf2 <cleanup_module+4b6e/10fc8>
>> Trace: c6828c37 <cleanup_module+6bb3/10fc8>
>> Trace: c682bd60 <cleanup_module+9cdc/10fc8>
>> Trace: c0126e26 <sys_newlstat+e/64>
>
>Oops - now i see the offsets, ksymoops either
>guessed something wrong or the right symbols
>are not exported from ntfs (ksymoops says
>something similar).
>
>The dumped code snippet is in support.o,
>function ntfs_memcpy and the manually
>computed call trace (using nm ntfs.o)
>approximately (e.g. find_attr does not give
>much sense here):
>
>ntfs_memcpy
>ntfs_put
>ntfs_readwrite_attr
>ntfs_decodeuni
>ntfs_find_attr
>??? (outside ntfs.o)
>ntfs_read_attr
>ntfs_getdir
>??? (outside ntfs.o)
>
>Regards
>--
> Stano
>
Since you used ksymoops, I'll guess this probably was an oops.
find_attr should be there, it's to get the $DATA attributute from the
dirrectory..... the odd thing is that i can't see how decode_uni
would be calling readwrite_attr..... Could you add -DDEBUG to
the EXTRA_CFLAGS in linux/fs/ntfs/Makefile, then echo 1 >
/proc/sys/fs/ntfs-debug on boot and see if you get any odd
log messages?
Joseph Malicki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/