Date: Tue, 14 Oct 1997 19:32:07 -0700 From: David Greenman <dg@root.com> To: Carey Nairn <Carey.Nairn@ccd.tas.gov.au> Cc: questions@FreeBSD.ORG Subject: Re: Spontaneous reboots with 2.2.1-R Message-ID: <199710150232.TAA02918@implode.root.com> In-Reply-To: Your message of "Wed, 15 Oct 1997 11:24:30 %2B1100." <3.0.32.19971015112430.006efb3c@falcon.pacit.tas.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>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?199710150232.TAA02918>