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>