The ntfs driver appears to be broken. vol->clustersize seems to be used as
a size or as a number of blocks depending on the places.
The 2.3.30 patch seems to use it as a number of bits (in ntfs/super.c):
vol->mft_recordbits = vol->clustersize * vol->mft_clusters_per_record;
whereas ntfs/fs.c uses it as a size:
if(!(bh=bread(sb->s_dev,vol->mft_cluster+i,vol->clustersize))) {
I believe this line (from ntfs_read_super) is the one leading to the oops.
The second oops is probably related to the first problem.
Since I have no knowledge of ntfs, I can't provide the right patch.
ksymoops 0.7c on i686 2.3.30. Options used
-v /usr/src/linns/linux/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.3.30/ (default)
-m /boot/System.map-2.3.30 (default)
eip: c013a7a8
invalid operand: 0000
CPU: 1
EIP: 0010:[<c013a7d4>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 0000003e ebx: c027ab58 ecx: c022f4bc edx: c022f4b4
esi: ffffffff edi: c7f9865c ebp: 000000b0 esp: c135be80
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 53, stackpage=c135b000)
Stack: 0000004e 00000002 c7c1e200 c7f9865c c7f98600 0002be94 c013ab84 00000002
00000009 000000b0 c7f9865c c8019e44 00000002 00000009 000000b0 c7f98778
c7f98600 c7f98790 c80219ec c7f9862c c013e692 c7f98600 c7be7000 00000000
Call Trace: [<c013ab84>] [<c8019e44>] [<c80219ec>] [<c013e692>] [<c013ec5b>] [<c802044e>] [<c80219ec>]
[<c013f236>] [<c802044e>] [<c80219ec>] [<c010ba50>]
Code: 0f 0b 83 c4 0c 8d b4 26 00 00 00 00 f0 0f ba 2b 00 0f 82 d2
>>EIP; c013a7d4 <getblk+74/128> <=====
Trace; c013ab84 <bread+18/64>
Trace; c8019e44 <[ntfs]ntfs_read_super+198/300>
Trace; c80219ec <[ntfs]ntfs_fs_type+0/14>
Trace; c013e692 <read_super+10a/130>
Trace; c013ec5b <do_mount+db/17c>
Trace; c802044e <[ntfs].rodata.start+74e/1ac5>
Trace; c80219ec <[ntfs]ntfs_fs_type+0/14>
Trace; c013f236 <sys_mount+2fa/3e4>
Trace; c802044e <[ntfs].rodata.start+74e/1ac5>
Trace; c80219ec <[ntfs]ntfs_fs_type+0/14>
Trace; c010ba50 <system_call+34/38>
Code; c013a7d4 <getblk+74/128>
00000000 <_EIP>:
Code; c013a7d4 <getblk+74/128> <=====
0: 0f 0b ud2a <=====
Code; c013a7d6 <getblk+76/128>
2: 83 c4 0c add $0xc,%esp
Code; c013a7d9 <getblk+79/128>
5: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi
Code; c013a7e0 <getblk+80/128>
c: f0 0f ba 2b 00 lock btsl $0x0,(%ebx)
Code; c013a7e5 <getblk+85/128>
11: 0f 82 d2 00 00 00 jb e9 <_EIP+0xe9> c013a8bd <balance_dirty_state+35/44>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
ksymoops 0.7c on i686 2.3.30. Options used
-v /usr/src/linns/linux/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.3.30/ (default)
-m /boot/System.map-2.3.30 (default)
Unable to handle kernel paging request at virtual address 05000018
c013e2c8
*pde = 00000000
Oops: 0000
CPU: 1
EIP: 0010:[<c013e2c8>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 05000000 ebx: c7f98600 ecx: c7f9d160 edx: c7f9e400
esi: 00000000 edi: c7fe22ca ebp: 000000a0 esp: c7fe3fd0
ds: 0018 es: 0018 ss: 0018
Process kupdate (pid: 4, stackpage=c7fe3000)
Stack: c013d206 00000000 c7fe2000 c7fe2450 c013d6c9 00000f00 c126ffb0 00000000
c0108eb8 00000000 00000078 c0247fc8
Call Trace: [<c013d206>] [<c013d6c9>] [<c0108eb8>]
Code: 8b 40 18 85 c0 74 06 53 ff d0 83 c4 04 8b 1b 81 fb 0c 2d 23
>>EIP; c013e2c8 <sync_supers+5c/78> <=====
Trace; c013d206 <sync_old_buffers+62/194>
Trace; c013d6c9 <kupdate+1d9/1e0>
Trace; c0108eb8 <kernel_thread+28/38>
Code; c013e2c8 <sync_supers+5c/78>
00000000 <_EIP>:
Code; c013e2c8 <sync_supers+5c/78> <=====
0: 8b 40 18 mov 0x18(%eax),%eax <=====
Code; c013e2cb <sync_supers+5f/78>
3: 85 c0 test %eax,%eax
Code; c013e2cd <sync_supers+61/78>
5: 74 06 je d <_EIP+0xd> c013e2d5 <sync_supers+69/78>
Code; c013e2cf <sync_supers+63/78>
7: 53 push %ebx
Code; c013e2d0 <sync_supers+64/78>
8: ff d0 call *%eax
Code; c013e2d2 <sync_supers+66/78>
a: 83 c4 04 add $0x4,%esp
Code; c013e2d5 <sync_supers+69/78>
d: 8b 1b mov (%ebx),%ebx
Code; c013e2d7 <sync_supers+6b/78>
f: 81 fb 0c 2d 23 00 cmp $0x232d0c,%ebx
-- Jean-Philippe GRIMALDI
- 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/