ok, so the crash is at pipe_wait+7c. Can you disassemble pipe_wait?
(shouldn't be very big) (i use gcc 3.1.1 so my assembly wouldn't match)
apparently a part of the inode got corrupted, and somebody is reading at
offset 0x20 of a structure inside the inode.
not really sure what could be the problem, it would be interesting to
see if you can reproduce it. Also if for example you enabled numa-q you
may want to try to disable it and see if w/o discontigmem the problem
goes away, if we could isolate it to a config option, it would help a lot.
> Trace; c0148180 <pipe_write+1cc/294>
> Trace; c013e308 <filp_close+9c/a8>
> Trace; c013e936 <sys_write+8e/100>
> Trace; c0108a7a <system_call+2e/34>
> Code; c648ff38 <END_OF_CODE+6196040/????>
> 00000000 <_EIP>:
> Code; c648ff38 <END_OF_CODE+6196040/????>
> 0: 60 pusha
> Code; c648ff38 <END_OF_CODE+6196040/????> <=====
> 1: ff 48 c6 decl 0xffffffc6(%eax) <=====
> Code; c648ff3c <END_OF_CODE+6196044/????>
> 4: ad lods %ds:(%esi),%eax
> Code; c648ff3c <END_OF_CODE+6196044/????>
> 5: 7d 14 jge 1b <_EIP+0x1b> c648ff52 <END_OF_CODE+61
> 9605a/????>
> Code; c648ff3e <END_OF_CODE+6196046/????>
> 7: c0 00 10 rolb $0x10,(%eax)
> Code; c648ff42 <END_OF_CODE+619604a/????>
> a: 00 00 add %al,(%eax)
> Code; c648ff44 <END_OF_CODE+619604c/????>
> c: e0 54 loopne 62 <_EIP+0x62> c648ff9a <END_OF_CODE+61
> 960a2/????>
> Code; c648ff46 <END_OF_CODE+619604e/????>
> e: ba c4 a0 73 34 mov $0x3473a0c4,%edx
> Code; c648ff4a <END_OF_CODE+6196052/????>
> 13: c6 00 00 movb $0x0,(%eax)
>
Andrea
-
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/