From owner-freebsd-questions Tue Oct 14 21:36:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA14434 for questions-outgoing; Tue, 14 Oct 1997 21:36:25 -0700 (PDT) (envelope-from owner-freebsd-questions) Received: from falcon.pacit.tas.gov.au (falcon.pacit.tas.gov.au [147.109.1.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA14428 for ; Tue, 14 Oct 1997 21:36:20 -0700 (PDT) (envelope-from Carey.Nairn@ccd.tas.gov.au) Received: from carey.pacit.tas.gov.au (carey.pacit.tas.gov.AU [147.109.2.69]) by falcon.pacit.tas.gov.au (8.8.5/8.8.5) with SMTP id PAA17631; Wed, 15 Oct 1997 15:34:58 +1100 (EST) Message-Id: <3.0.32.19971015153249.009e7a54@falcon.pacit.tas.gov.au> X-Sender: cpn@falcon.pacit.tas.gov.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 15 Oct 1997 15:32:49 +1100 To: dg@root.com From: Carey Nairn Subject: Re: Spontaneous reboots with 2.2.1-R Cc: questions@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 > > #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); > /* > >