Bernd Walter writes:
> On Wed, Nov 29, 2000 at 02:47:54PM -0500, Andrew Gallatin wrote:
> >
> > Bernd Walter writes:
> > >
> > > trap entry = 0x2 (memory management fault)
> > > a0 = 0xfffffbf1e0000018
> > > a1 = 0x1
> > > a2 = 0x0
> > > pc = 0xfffffc0000557a10
> > > ra = 0xfffffc000055791c
> > > curproc = 0xfffffc000062f118
> > > pid = 0, comm = swapper
> >
> > Bernd,
> >
> > Note the faulting address. It is not a k0seg address. This means
> > something went negative, most likely in the LCA_CFGOFF macro. Here's
> > why..
>
> What is k0seg?
> How can I see that it's not one?
Everything from 0xfffffc0000000000-0xfffffdffffffffff is in k0seg, so
its easy to see from the first 6 hex digits. K0SEG is a direct map of
physical addresses into kernel virtual address space.
<...>
> Just to be clear the values given to lca_read_config were:
> b=0, s=20, f=0, reg=0, width=4
> That means b in LCA_CFGOFF is false and the second formular will be applied.
> The first part is 1<<n while n is calculated to be 31 in our case and
> this makes -1 for int - your theory seems to be right.
> But are you shure that changing our variables to unsigned will help?
> Don't we need to make '1' unsigned?
I thought so at first too, but it was never unsigned and it worked
until recently.. And the same fix fixes a nearly identical panic on
another platform, so I'm betting this is it ;)
<..>
> I will test it tommorow.
Thanks!
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
