Kurt Alstrup wrote:
Apologies for late response, wanted to check the code again.
On 10/07/2010 10:03 AM, Alan Cox wrote:
Alan Cox wrote:
At a high-level, I agree with much of what you say. In particular, if
pmap_enter() is applied to a virtual address that is already mapped by a large
page
Apologies for late response, wanted to check the code again.
On 10/07/2010 10:03 AM, Alan Cox wrote:
> Alan Cox wrote:
> At a high-level, I agree with much of what you say. In particular, if
> pmap_enter() is applied to a virtual address that is already mapped by a large
> page, the reported pan
Kurt Alstrup wrote:
Up front disclaimer: I may very well be wrong on this..
At a high-level, I agree with much of what you say. In particular, if
pmap_enter() is applied to a virtual address that is already mapped by a
large page, the reported panic could result. However, barring bugs,
Dave Hayes wrote:
Alan Cox writes:
When you build your kernel for this ISO are you increasing the value of
NKPT?
No. I was under the impression that this value auto-tunes on amd64,
is that correct?
After initialization, yes. However, the kernel starts out with just
NKPT page ta
Alan Cox writes:
> When you build your kernel for this ISO are you increasing the value of
> NKPT?
No. I was under the impression that this value auto-tunes on amd64,
is that correct?
--
Dave Hayes - Consultant - Altadena CA, USA - d...@jetcafe.org
>>> The opinions expressed above are entirely
Dave Hayes wrote:
Alan Cox writes:
[snip]
Is this problem reproducible? I don't recall if you mentioned that
earlier.
Sort of.
It seems that everytime I generate a bootable FreeBSD ISO, a die is
rolled. If it comes up a certain number then it crashes, otherwise it's
fine. ;)
My
Up front disclaimer: I may very well be wrong on this..
This looks like a pmap bug I ran into a recently on a pre-release of 8.0. It's
still present in stock 8.0, but I have not looked at 8.1 (see disclaimer).
The bug was caused by a combination of a shortcut in pmap_unuse_pt() which
didn't wipe
Alan Cox writes:
> There are two pieces of information that might be helpful: the value of
> the global variable "kernel_vm_end" and the virtual address that was
> passed to pmap_enter().
I'm afraid I don't have enough experience with this debugger to get
these values with offhand commands. I c
Dave Hayes wrote:
Alan Cox writes:
I'm afraid that I can't offer much insight without a stack trace. At
initialization time, we map the kernel with 2MB pages. I suspect that
something within the kernel is later trying to change one those mappings.
If I had to guess, it's related to the mfs
Alan Cox writes:
> I'm afraid that I can't offer much insight without a stack trace. At
> initialization time, we map the kernel with 2MB pages. I suspect that
> something within the kernel is later trying to change one those mappings.
> If I had to guess, it's related to the mfs root.
Here is
On Sat, Oct 2, 2010 at 9:11 PM, Dave Hayes wrote:
> What does the above mentioned panic mean? I'm booting from
> an mfsroot off of a DVD with a loader.conf like this:
>
> autoboot_delay="5"
> mfsroot_load="YES"
> mfsroot_type="mfs_root"
> mfsroot_name="/mfsboot"
> vfs.root.mountfrom="ufs:md0
What does the above mentioned panic mean? I'm booting from
an mfsroot off of a DVD with a loader.conf like this:
autoboot_delay="5"
mfsroot_load="YES"
mfsroot_type="mfs_root"
mfsroot_name="/mfsboot"
vfs.root.mountfrom="ufs:md0"
vfs.root.mountfrom.options="rw"
kern.ipc.nmbclusters=32768
net
12 matches
Mail list logo
