Date: Wed, 15 Oct 1997 16:23:51 +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.19971015162350.009fef64@falcon.pacit.tas.gov.au>
next in thread | raw e-mail | index | archive | help
David,
looks like the changes to pmap.c didn't fix our problem. The machine
stayed up for about 30 minutes after installing the new kernel. Any other
ideas?
thanks,
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.19971015162350.009fef64>