Hi folks,
I use kernel 2.4.2. If I try to access files on a 640 MB MO (2048 bytes
hardware sector size) and the MO is using FAT fs I only got messages
like these:
Unable to handle kernel NULL pointer dereference at virtual address
00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00000000>]
EFLAGS: 00010286
eax: 00000000 ebx: c798d740 ecx: 00000003 edx: c798d740
esi: ffffffea edi: 00000000 ebp: 00004000 esp: c576bf88
ds: 0018 es: 0018 ss: 0018
Process cat (pid: 458, stackpage=c576b000)
Stack: cc993428 c798d740 0804b220 00004000 c798d760 c012d465 c798d740
0804b220
00004000 c798d760 c576a000 00004000 0804b220 bffff994 c0108d43
00000003
0804b220 00004000 00004000 0804b220 bffff994 00000003 0000002b
0000002b
Call Trace: [<cc993428>] [<c012d465>] [<c0108d43>]
Code: Bad EIP value.
Segmentation fault
There are no problems if I use ext2fs, exept that I can't use them for
data exchange with Windows. It also works with 2.2 kernels but the MO
drive will be much slower.
Tino
On Thursday, 8. March 2001 17:42, Tino Keitel wrote:
> Hi folks,
>
> I use kernel 2.4.2. If I try to access files on a 640 MB MO (2048 bytes
> hardware sector size) and the MO is using FAT fs I only got messages
> like these:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000
> CPU: 0
> EIP: 0010:[<00000000>]
> EFLAGS: 00010286
> eax: 00000000 ebx: c798d740 ecx: 00000003 edx: c798d740
> esi: ffffffea edi: 00000000 ebp: 00004000 esp: c576bf88
> ds: 0018 es: 0018 ss: 0018
> Process cat (pid: 458, stackpage=c576b000)
> Stack: cc993428 c798d740 0804b220 00004000 c798d760 c012d465 c798d740
> 0804b220
> 00004000 c798d760 c576a000 00004000 0804b220 bffff994 c0108d43
> 00000003
> 0804b220 00004000 00004000 0804b220 bffff994 00000003 0000002b
> 0000002b
> Call Trace: [<cc993428>] [<c012d465>] [<c0108d43>]
>
> Code: Bad EIP value.
> Segmentation fault
>
> There are no problems if I use ext2fs, exept that I can't use them for
> data exchange with Windows. It also works with 2.2 kernels but the MO
> drive will be much slower.
>
> Tino
Ok, I did some debug work. Here are the results:
Writing to the MO doesn't cause an "Oops", but the file will contain trash.
'cat "test" > file' results in a file that contains 0x1a 0xf7 0xa3 0xdb 0x86
The lines
printk("fat debug: *i_sb: %u\n", inode->i_sb);
printk("fat debug: *cvf_file_read: %u\n",
MSDOS_SB(inode->i_sb)->cvf_format->cvf_file_read);
in fs/fat/file.c:fat_file_read() shows this:
fat debug: *cvf_format: 3365518688
fat debug: *cvf_file_read: 0
In fs/fat/cvf.c I found this:
struct cvf_format bigblock_cvf = {
0, /* version - who cares? */
"big_blocks",
0, /* flags - who cares? */
NULL,
NULL,
NULL,
bigblock_fat_bread,
bigblock_fat_bread,
bigblock_fat_brelse,
bigblock_fat_mark_buffer_dirty,
bigblock_fat_set_uptodate,
bigblock_fat_is_uptodate,
bigblock_fat_ll_rw_block,
default_fat_access,
NULL,
default_fat_bmap,
NULL,
^^^^^
default_fat_file_write,
NULL,
NULL
};
cvf_file_read is set to zero and will be never changed, but cvf_file_write is
set to default_fat_file_write.
Tino