On Tue, 22 May 2001 22:52:47 +1000, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Carlos Laviola wrote:
> >
> > invalid operand: 0000
[ ... oops here ... ]
> > Segmentation fault
> >
> > This seems to be a bug in the kernel, maybe because the file is too big,
> > and VFAT partitions don't like that.
>
> It used to be that fatfs would hit the second BUG() in fat_get_block()
> when a file reaches two gig. But I can't make that happen in testing,
> because the s_maxbytes stuff restricts it to 2gig-1. What you *should*
> have seen was `wget' locking up because of a different bug :)
>
> Are you sure you got this with 2.4.4? If so, please run the
> output through
>
> ksymoops -m System.map < oops-text
Well, in fact, I was using 2.4.5-pre1 when I had this problem. However, since
it doesn't seem like anything within the VFAT subsystem has changed from 2.4.4
to 2.4.5-pre1, 2.4.4 is probably buggy too. The relevant output from ksymoops
is below.
>>EIP; c48fb709 <[fat]fat_get_block+5d/dc> <=====
Code; c48fb709 <[fat]fat_get_block+5d/dc>
00000000 <_EIP>:
Code; c48fb709 <[fat]fat_get_block+5d/dc> <=====
0: 0f 0b ud2a <=====
Code; c48fb70b <[fat]fat_get_block+5f/dc>
2: 83 c4 0c add $0xc,%esp
Code; c48fb70e <[fat]fat_get_block+62/dc>
5: b8 fb ff ff ff mov $0xfffffffb,%eax
Code; c48fb713 <[fat]fat_get_block+67/dc>
a: eb 6d jmp 79 <_EIP+0x79> c48fb782
<[fat]fat_get_block+d6/dc>
Code; c48fb715 <[fat]fat_get_block+69/dc>
c: 8b 87 8c 00 00 00 mov 0x8c(%edi),%eax
Code; c48fb71b <[fat]fat_get_block+6f/dc>
12: 0f b7 00 movzwl (%eax),%eax
Thanks,
Carlos.
--
_ _ _| _ _ | _ . _ | _ carlos.debian.net Debian-BR Project
(_(_|| |(_)_) |(_|\/|(_)|(_| uin#: 981913 (icq) debian-br.sf.net
Linux: the choice of a GNU generation - Registered Linux User #103594
Shah, shah! Ayatollah you so!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
