Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Oct 1998 06:05:06 +0200
From:      Tor.Egge@fast.no
To:        sthaug@nethelp.no
Cc:        freebsd-current@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG
Subject:   Re: Problems with Digital server with P-166 and Neptune chipset
Message-ID:  <199810210405.GAA07127@midten.fast.no>
In-Reply-To: Your message of "Wed, 21 Oct 1998 02:42:24 %2B0200"
References:  <6824.908930544@verdi.nethelp.no>

next in thread | previous in thread | raw e-mail | index | archive | help
> I wrote:
> 
> > I'm trying to get FreeBSD 3.0 to run reliably on a Digital server with
> > Neptune chipset - so far without great success. (2.2.7, btw, wouldn't
> > install at all. 3.0 installed with some effort).
> 
> I now have some more info. Built a kernel with debug info, built an aout
> gdb. I have two identical machines running 3.0-RELEASE now, and both of
> them are crashing the same way (page fault in kernel mode) and in the
> same place (the zalloc inline routine in vm/vm_zone.h).


0xe01d4194 <vmspace_alloc>:     pushl  %ebp
0xe01d4195 <vmspace_alloc+1>:   movl   %esp,%ebp
0xe01d4197 <vmspace_alloc+3>:   pushl  %esi
0xe01d4198 <vmspace_alloc+4>:   pushl  %ebx
0xe01d4199 <vmspace_alloc+5>:   movl   0xe02561d0,%ecx
0xe01d419f <vmspace_alloc+11>:  movl   0x8(%ecx),%eax
0xe01d41a2 <vmspace_alloc+14>:  cmpl   %eax,0xc(%ecx)
0xe01d41a5 <vmspace_alloc+17>:  jl     0xe01d41b4 <vmspace_alloc+32>
0xe01d41a7 <vmspace_alloc+19>:  pushl  %ecx
0xe01d41a8 <vmspace_alloc+20>:  call   0xe01dfd44 <_zget>
0xe01d41ad <vmspace_alloc+25>:  movl   %eax,%esi
0xe01d41af <vmspace_alloc+27>:  addl   $0x4,%esp
0xe01d41b2 <vmspace_alloc+30>:  jmp    0xe01d41c4 <vmspace_alloc+48>


	item = z->zitems;

0xe01d41b4 <vmspace_alloc+32>:  movl   0x4(%ecx),%edx


	z->zitems = ((void **) item)[0];
0xe01d41b7 <vmspace_alloc+35>:  movl   (%edx),%eax

Here it crashed

    z (ecx) is 0xf0dd9980, cf. tf_ecx = -253912704
items (edx) is 0x7200720,  cf. tf_edx =  119539488

0xe01d41b9 <vmspace_alloc+37>:  movl   %eax,0x4(%ecx)

....

> 
> Here are two backtraces, one from each machine. These both happened at
> the same time, namely when running /etc/daily at 02.00. In both cases,
> the kernel is trying to follow a null pointer (z) at vm/vm_zone.h line 87:
> 
> 	item = z->zitems;

The fault virtual address was 0x07200720 according to the panic messages.

> 
> However, the zalloc inline routine is called from vmspace_alloc:
> 
> 	vm = zalloc(vmspace_zone);
> 
> and here the vmspace_zone seems to have a sensible value, 0xf0dd9980.
> 
> I'm going to try to recompile the kernel with DIAGNOSTIC enabled to see
> if I can get some more info. Meanwhile, can anybody suggest why z is
> null in zalloc when vmspace_zone isn't? Missing spl protection?

Looking at you dmesg output (from an earlier message), I find

	real memory  = 269221888 (262912K bytes)

instead of the expected

	real memory  = 268435456 (262144K bytes)

which indicates that the speculative memory probe stopped at 0x0100C0000, i.e.
at the end of aliased VGA memory.

I suggest adding 

	options	"MAXMEM=(256*1024)"

to your kernel config file.

Two space characters with black background and grey foreground --> 0x07200720
in screen memory.

- Tor Egge

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810210405.GAA07127>