Re: kernel panic

[Joe Talbott <josepht@xxxxxxxxxx>]

On Fri, May 11, 2007 at 05:50:07PM -0700, Matthew Dillon wrote:
> 
> :There is a small delay <2s.  I ran a loop that switched between two
> :IPs for about 15 minutes and nothing happened.  
> :
> :The kernel buffer output in the corefile was from months ago.  I only
> :remembered because I did the same thing this time; shutdown now;
> :umount /home; ifconfig re0 ...  I don't know how this can be in a dump
> :months after the fact unless there is stale data in my swap partition
> :from my last coredump that hasn't been overwritten since I don't do
> :very much swapping.  This idea may be completely wrong.  I am 100%
> :certain that I'm not looking at a stale dump as strings on the kernel
> :and vmcore show them as being from May 9, 2007.  I am also certain
> :that I was not ifconfig'ing any interface when this happened.
> :
> :Joe
> 
>     Sometimes the BIOS clears memory, sometimes it doesn't.  If it doesn't,
>     then sometimes the dmesg text from previous boots will remain in
>     memory and be available.  That's all.  Power cycle and it all goes poof.

This is a laptop that has been power cycled at least a hundred times
since that took place so it seems to me there's no way it was coming
from memory.  When my re(4) troubles were happening I had hw.physmem
set to 256M to get manageable coredumps.  After my troubles were
resolved I removed that entry from my loader.conf.  So this time my
dump consisted of 1.5GB as did several re(4) related coredumps prior
to my setting hw.physmem.  I assume that the swap space isn't zero'd
or otherwise initialized prior to a page being written to it.  I also
assume that a coredump is written sparsely to disk so old data could
remain across coredumps.  I guess I'll read the code and see if I can
learn a bit more rather than making assumptions.

Joe

> 
>     I've googled similar bug reports on FreeBSD, Linux, NetBSD, etc.  I
>     have not found much information other then this:
> 
>     http://lists.freebsd.org/pipermail/freebsd-bugs/2003-September/003012.html
> 
>     Which seems to indicate that it might be DRM/DRI related.. or perhaps
>     just video/DRI related as this person triggered it simply by restarting
>     his X server a few times.
> 
>     BUT, our flush code already uses the changes made to FreeBSD, i.e.
>     uses ~(1 << 7), so I am somewhat at a loss.
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>