--text follows this line--
Matthew Dillon <[EMAIL PROTECTED]> writes:
> :I induced the crash by running "make clean; make buildworld" in one
> :infinite loop and "portsdb -Uu" in another. That string occurs in a
> :bunch of makefiles in /usr/ports. Some of the occurences in the core
> :are clearly from them, but many of them are surrounded by binary
> :data. I recursively grepped /usr/{src,obj,bin,ports} and
> :/usr/local/{bin,lib} and didn't find any binary files with that
> :string. My guess then is that it's from the memory image of a make
> :process.
> :
> :--
> : Brady Montz
>
> This is soooo weird. The corruption is occuring in the vm_page_t itself,
> at least in the crash you sent me. The vm_page_t is a locked-down
> address in the kernel. It is not effecting the vm_page_t's around the
> one that got corrupted. The corruption does not appear to be on a page
> or device block boundry. I am at a loss as to how its getting there.
>
> Could you try playing with the DMA modes on your IDE hard drive? Try
> turning DMA off, for example, and see if the corruption still occurs.
I'd had that thought as well. Seems a reasonably way for a misbehaving
driver to corrupt memory. I'll try that tonight.
However, being a recent convert to BSD, I don't know how to turn of
DMA. How do I?
--
Brady Montz
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
