Date: Tue, 27 Aug 1996 13:42:54 -0400 (EDT) From: Dave Chapeskie <dchapes@zeus.leitch.com> To: tinguely@plains.nodak.edu (Mark Tinguely) Cc: FreeBSD-hackers@freebsd.org Subject: Re: kernel vm_page_alloc_contig() can indirectly cause kernel page faults Message-ID: <199608271742.NAA14487@ale.zeus.leitch.com> In-Reply-To: <199608250327.WAA26323@plains.nodak.edu> from Mark Tinguely at "Aug 24, 96 10:27:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Tinguely wrote:
> I reported this panic last summer when I started writing the Meteor driver.
> THe work around I used wast to start the allocation starting at the
> first Meg mark, at that time I speculated it was treating the low memory
> and the first meg as being contiguous even though there is a memory
> hole between them. Starting contiguous allocation at/after the first
> meg never caused anymore panics, so I left it at that.
>
> --mark.
Interesting. It was from your driver that I found the
vm_page_alloc_contig() call and I use the same low and high range
as you.
I have found one strange problem with my fix however. At one
point the contiguous memory gets mmaped into user space (via the
devices d_mmap hook), if the process forks after this point the
pmap gets screwed up once the child exits. I can walk through the
kernel_map and find the virtual address range still wired and
pointing to the same vm_page's but vtophys() and pmap_kextract()
both give 0. Does anyone have any ideas of how to track this one down?
--
Dave Chapeskie, x2358
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608271742.NAA14487>