josepht at cstone.net
Fri May 11 20:03:42 PDT 2007
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.
> 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.
> I've googled similar bug reports on FreeBSD, Linux, NetBSD, etc. I
> have not found much information other then this:
> 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.
> Matthew Dillon
> <dillon at backplane.com>
More information about the Bugs