Messages in this thread | | | Date | Mon, 29 Nov 1999 17:09:12 -0800 | From | David desJardins <> | Subject | Re: Frequent oops in shrink_mmap |
| |
Stephen C. Tweedie <sct@redhat.com> writes: > This has the footprint of hardware problems stamped all over it. > >> Nov 15 15:50:42 s17 kernel: EIP: 0010:[try_to_free_buffers+18/136] >> Nov 15 15:50:42 s17 kernel: EFLAGS: 00010202 >> Nov 15 15:50:42 s17 kernel: eax: 40000000 ebx: c029b320 ecx: 00000006 edx: 00020000 >> Nov 15 15:50:42 s17 kernel: esi: 40000000 edi: 40000000 ebp: >> c029b320 esp: c000dfa8 > > So the immediate problem is that there is a page in the page map which > has a page_map->buffers pointer of 0x40000000. That's one bit away from > a legal value of zero. That sort of single-bit error is usually a sign > of hardware trouble. It's not guaranteed, but that's the best diagnosis > just from looking at one dump.
Thanks very much; this is really helpful.
I looked at 56 of these oops messages in try_to_free_buffers, from 10 machines. 50 messages (4 machines) have %eax=80000000, and 6 messages (6 machines) have %eax=40000000. Is this consistent with the single-bit memory error, or not? If it's purely a hardware problem, should I be seeing 20000000 and 10000000 and other one-bit patterns? And should I be seeing one-bit differences from valid nonzero pointers? Or is it the case that only memory errors in the top two bits will trigger this oops, and other memory errors might remain undetected, and that the great majority of entries will be zero so that all of the errors are likely to occur on those pages?
-- David desJardins
- 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/
| |