From owner-freebsd-questions Tue Oct 14 19:31:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA06771 for questions-outgoing; Tue, 14 Oct 1997 19:31:40 -0700 (PDT) (envelope-from owner-freebsd-questions) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA06766 for ; Tue, 14 Oct 1997 19:31:36 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA02918; Tue, 14 Oct 1997 19:32:07 -0700 (PDT) Message-Id: <199710150232.TAA02918@implode.root.com> To: Carey Nairn cc: questions@FreeBSD.ORG Subject: Re: Spontaneous reboots with 2.2.1-R In-reply-to: Your message of "Wed, 15 Oct 1997 11:24:30 +1100." <3.0.32.19971015112430.006efb3c@falcon.pacit.tas.gov.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 14 Oct 1997 19:32:07 -0700 Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >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); /*