Date: Wed, 15 Oct 1997 15:32:49 +1100 From: Carey Nairn <Carey.Nairn@ccd.tas.gov.au> To: dg@root.com Cc: questions@FreeBSD.ORG Subject: Re: Spontaneous reboots with 2.2.1-R Message-ID: <3.0.32.19971015153249.009e7a54@falcon.pacit.tas.gov.au>
next in thread | raw e-mail | index | archive | help
Thanks David,
I have rebuilt a new kernel with the pmap.c changes you gave me and have it
running. I'll let you know if we have any more grief with it.
cheers,
Carey Nairn
At 19:32 14/10/97 -0700, David Greenman wrote:
>>we are having spontaneous reboot problems with our second squid proxy
>>server since performing a hardware upgrade last weekend. The machine is
>>running 2.2.1-R and has been without fault since it was installed a few
>>months ago. The specs are as follows:
>>
>>P200
>>192MB RAM
>>SOYO SY-5BT5 motherboard
>>Adaptec 2940U SCSI controller
>>1x2GB Seagate SCSI HDD
>>3x4GB Seagate SCSI HDD (in a ccd)
>>
>>The upgrade involved adding 64MB RAM and one of the 4GB disks. In addition
>>to this we changed the squid cache from individual 4GB filesystems to a
>>striped (ccd) 12GB filesystem.
>>
>>Could this be a manifestation of the ahc driver bug and if so, can I just
>>patch the 2.2.1 kernel with the new ahc driver files rather than doing an
>>upgrade?
>>
>>If I can patch the kernel, which files do I need to get?
>
> This might be caused by a scalability bug in sys/i386/i386/pmap.c. If you
>could get the changes in rev 1.128.2.5 of pmap.c, this might fix it.
>
>-DG
>
>David Greenman
>Core-team/Principal Architect, The FreeBSD Project
>
>Index: pmap.c
>===================================================================
>RCS file: /home/ncvs/src/sys/i386/i386/pmap.c,v
>retrieving revision 1.128.2.4
>retrieving revision 1.128.2.5
>diff -c -r1.128.2.4 -r1.128.2.5
>*** pmap.c 1997/02/01 12:11:03 1.128.2.4
>--- pmap.c 1997/04/23 02:20:06 1.128.2.5
>***************
>*** 39,45 ****
> * SUCH DAMAGE.
> *
> * from: @(#)pmap.c 7.7 (Berkeley) 5/12/91
>! * $Id: pmap.c,v 1.128.2.4 1997/02/01 12:11:03 davidg Exp $
> */
>
> /*
>--- 39,45 ----
> * SUCH DAMAGE.
> *
> * from: @(#)pmap.c 7.7 (Berkeley) 5/12/91
>! * $Id: pmap.c,v 1.128.2.5 1997/04/23 02:20:06 davidg Exp $
> */
>
> /*
>***************
>*** 100,105 ****
>--- 100,106 ----
> #include <machine/specialreg.h>
>
> #define PMAP_KEEP_PDIRS
>+ #define PMAP_SHPGPERPROC 200
>
> #if defined(DIAGNOSTIC)
> #define PMAP_DIAGNOSTIC
>***************
>*** 1460,1476 ****
> /*
> * init the pv_entry allocation system
> */
>- #define PVSPERPAGE 64
> void
> init_pv_entries(npg)
> int npg;
> {
> /*
>! * allocate enough kvm space for PVSPERPAGE entries per page (lots)
>! * kvm space is fairly cheap, be generous!!! (the system can panic if
>! * this is too small.)
> */
>! npvvapg = ((npg * PVSPERPAGE) * sizeof(struct pv_entry)
> + PAGE_SIZE - 1) / PAGE_SIZE;
> pvva = kmem_alloc_pageable(kernel_map, npvvapg * PAGE_SIZE);
> /*
>--- 1461,1482 ----
> /*
> * init the pv_entry allocation system
> */
> void
> init_pv_entries(npg)
> int npg;
> {
> /*
>! * Allocate enough kvm space for one entry per page, and
>! * each process having PMAP_SHPGPERPROC pages shared with other
>! * processes. (The system can panic if this is too small, but also
>! * can fail on bootup if this is too big.)
>! * XXX The pv management mechanism needs to be fixed so that systems
>! * with lots of shared mappings amongst lots of processes will still
>! * work. The fix will likely be that once we run out of pv entries
>! * we will free other entries (and the associated mappings), with
>! * some policy yet to be determined.
> */
>! npvvapg = ((PMAP_SHPGPERPROC * maxproc + npg) * sizeof(struct pv_entry)
> + PAGE_SIZE - 1) / PAGE_SIZE;
> pvva = kmem_alloc_pageable(kernel_map, npvvapg * PAGE_SIZE);
> /*
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19971015153249.009e7a54>