Re: Weird bug in kernel (invalid operand?)

[Andrew Morton]

Carlos Laviola wrote:
> 
> invalid operand: 0000
> CPU:    0
> EIP:    0010:[<c48fb709>]
> EFLAGS: 00010282
> eax: 00000019   ebx: 00000000   ecx: c1272000   edx: c3f7bc20
> esi: 00206c60   edi: c3ca5240   ebp: c0695aa0   esp: c1273e68
> ds: 0018   es: 0018   ss: 0018
> Process snarf (pid: 324, stackpage=c1273000)
> Stack: c48fe965 c48fea27 00000045 000001f0 00000200 00040d8c c1273ec0 c012cf56
>        c3ca5240 00206c60 c0695aa0 00000001 000001f0 c1273f64 00040d8c 000002e5
>        c0605000 c0695aa0 00000200 00206c60 00000000 c0695aa0 0000004b 0000004b
> Call Trace: [<c48fe965>] [<c48fea27>] [<c012cf56>] [<c012d553>] [<c48fb6ac>] [<c48fcf1c>] [<c48fb6ac>]
>        [<c012179a>] [<c48fb7d2>] [<c48fb7b0>] [<c012ac5a>] [<c0106a63>]
> 
> Code: 0f 0b 83 c4 0c b8 fb ff ff ff eb 6d 8b 87 8c 00 00 00 0f b7
> 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