On Sat, 1 Mar 2003, Randy.Dunlap wrote:
> This is plain vanilla 2.5.63.
Ditto, no modules enabled, gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-2mdk)
> The NTFS filesystem is mounted and I tried to cd several levels
> deep into it...and voila.
I guess it's not reproducible. I couldn't.
> Mar 1 13:35:44 midway kernel: Unable to handle kernel paging request at
> virtual address 0001029a
> Mar 1 13:35:44 midway kernel: *pde = 00000000
> Mar 1 13:35:44 midway kernel: Oops: 0002
> Mar 1 13:35:44 midway kernel: CPU: 0
> Mar 1 13:35:44 midway kernel: EIP: 0060:[__ntfs_init_inode+169/400] Not
> tainted
> Mar 1 13:35:44 midway kernel: EIP: 0060:[<c01f40f9>] Not tainted
> Mar 1 13:35:44 midway kernel: EFLAGS: 00010282
> Mar 1 13:35:44 midway kernel: EIP is at __ntfs_init_inode+0xa9/0x190
> Mar 1 13:35:44 midway kernel: eax: f6c0f080 ebx: 0000416d ecx: 00010282
> edx: f6c0f0f8
> Mar 1 13:35:44 midway kernel: esi: c040b078 edi: f6c0f0f8 ebp: f6dd1dbc
> esp: f6dd1db4
> Mar 1 13:35:44 midway su(pam_unix)[1839]: session closed for user root
> Mar 1 13:35:44 midway kernel: ds: 007b es: 007b ss: 0068
[...]
> Mar 1 13:35:44 midway kernel: Code: 89 51 18 89 51 1c 31 f6 31 c9 89 b0 80 00
> 00 00 31 f6 31 d2
0: 89 51 18 mov %edx,0x18(%ecx)
3: 89 51 1c mov %edx,0x1c(%ecx)
The only potential match is in this part of __ntfs_init_inode (gcc
3.2.2 generates totally different and overall 50% less code for
__ntfs_init_inode):
ni->seq_no = 0;
atomic_set(&ni->count, 1);
However neither the above machine code nor the edx and ecx values are
correct. How reliable is the oopser? What compiler did you use? Could
you disassemble __ntfs_init_inode?
gdb fs/ntfs/ntfs.o
gdb> disassemble __ntfs_init_inode
Szaka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:24 EST