From bg@bg.sics.se  Mon Feb  7 11:06:57 2000
Return-Path: <bg@bg.sics.se>
Received: from bg.sics.se (bg.sics.se [193.10.66.124])
	by builder.freebsd.org (Postfix) with ESMTP id AD028442D
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  7 Feb 2000 11:06:48 -0800 (PST)
Received: (from bg@localhost)
	by bg.sics.se (8.9.3/8.9.3) id UAA19100;
	Mon, 7 Feb 2000 20:07:43 +0100 (CET)
	(envelope-from bg)
Message-Id: <200002071907.UAA19100@bg.sics.se>
Date: Mon, 7 Feb 2000 20:07:43 +0100 (CET)
From: Bjoern Groenvall <bg@bg.sics.se>
Reply-To: bg@bg.sics.se
To: FreeBSD-gnats-submit@freebsd.org
Cc: bg@sics.se
Subject: How to crash FreeBSD 4.4
X-Send-Pr-Version: 3.2

>Number:         16568
>Category:       kern
>Synopsis:       How to crash FreeBSD 4.4
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bde
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb  7 11:10:02 PST 2000
>Closed-Date:    Sun Apr 30 01:27:32 PDT 2000
>Last-Modified:  Sun Apr 30 01:30:44 PDT 2000
>Originator:     Bjoern Groenvall
>Release:        FreeBSD 3.4-RELEASE i386
>Organization:
SICS
>Environment:

pao$ dmesg | head -15
Copyright (c) 1992-1999 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California. All rights reserved.
FreeBSD 3.4-RELEASE #1: Wed Dec 22 12:16:23 CET 1999
    root@pao.sics.se:/usr/src/sys/compile/PAO
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 598840712 Hz
CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x612  Stepping = 2
  Features=0x81f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX>
  AMD Features=0xc0400000<<b22>,<b30>,3DNow!>
real memory  = 134217728 (131072K bytes)
avail memory = 127496192 (124508K bytes)
Preloaded elf kernel "kernel" at 0xc02c5000.
Pentium Pro MTRR support enabled

>Description:

The attached program almost reliably crashes FreeBSD 3.4. By "almost"
here is ment that usually you get a crash on the first run, sometimes
you have to try twice. Other times it is even necessary to do some
compilations and then try crash.c again. Usually there is a crash on
the first or second try.

We have tried this program on other machines too with different CPUs
and they crashed to. If you need more info, just ask.

>How-To-Repeat:

Compile and run the following program. If you don't get a panic on the
first try, Ctrl-C and rerun.

#include <stdio.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/wait.h>

void
qerror(const char *msg)
{
  perror(msg);
  exit(10);
}

int
main()
{
  int fd;

  /* Get a numerically large fd. */
  fd = dup2(0, getdtablesize() - 10);
  if (fd < 0)
    qerror("dup2");

  fprintf(stderr, "fd = %d\n", fd);

  while (1)
    switch (fork()) {
    case -1:
      qerror("fork");
    case 0:
      write(2, ".", 1);
      exit(0);
    default:
      wait(0);
      break;
    }
}


>Fix:
	
Unknown.

>Release-Note:
>Audit-Trail:

From: Torbjorn Granlund <tege@swox.com>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/16568
Date: 07 Feb 2000 20:45:13 +0100

 I have reproduced this on K6, PentiumII, and Athlon systems.  (This
 problem originally popped up on a 3.3 system using ssh-agent from
 ossh-1.2.17, but Bjrn's tiny crash.c program only seems to crash
 3.4.)
 
 To us, this problem is very critical indeed.  It has made us lose two
 developer weeks during a very critical project.  Perhaps we trust
 FreeBSD *too* much (we've had extremely little problems during the 4
 years our business has using FreeBSD for all development and server
 machines).  When the present problem popped up, we simply assumed it
 was a hardware problem.  We even got ourselves a new server, which
 didn't make much difference...
 
 -- 
 Torbjrn
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: bg@bg.sics.se
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, bg@sics.se
Subject: Re: kern/16568: How to crash FreeBSD 4.4 
Date: Wed, 16 Feb 2000 10:39:31 +0200

 On Mon, 07 Feb 2000 20:07:43 +0100, Bjoern Groenvall wrote:
 
 > Compile and run the following program. If you don't get a panic on the
 > first try, Ctrl-C and rerun.
 
 It looks like an obfuscated fork-bomb, which is nothing new and can be
 controlled with the maxproc capability in login.conf(5).
 
 Could you please try this in a session for which "max user processes"
 (as reported by ulimit -a) is limited to some sane number and provide
 feedback?
 
 Ciao,
 Sheldon.
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Thomas David Rivers <rivers@dignus.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/16568: How to crash FreeBSD 4.4 
Date: Wed, 16 Feb 2000 14:39:15 +0200

 On Wed, 16 Feb 2000 07:12:17 EST, Thomas David Rivers wrote:
 
 >   Even if it is a modified fork-bomb - should FreeBSD panic?  I wouldn't
 >  think so...
 
 Panic?  I don't see any panic described in the PR.  Oh, _there_... he
 mentions a panic under How-To-Repeat.
 
 Well, it'd be swell if he'd show us the panic.  Meantime, I'll try to
 read slower. :-)
 
 Ciao,
 Sheldon.
 

From: Thomas David Rivers <rivers@dignus.com>
To: rivers@dignus.com, sheldonh@uunet.co.za
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/16568: How to crash FreeBSD 4.4
Date: Wed, 16 Feb 2000 08:25:57 -0500 (EST)

 > 
 > 
 > On Wed, 16 Feb 2000 07:12:17 EST, Thomas David Rivers wrote:
 > 
 > >   Even if it is a modified fork-bomb - should FreeBSD panic?  I wouldn't
 > >  think so...
 > 
 > Panic?  I don't see any panic described in the PR.  Oh, _there_... he
 > mentions a panic under How-To-Repeat.
 > 
 > Well, it'd be swell if he'd show us the panic.  
 
  I suppose so, although the how-to-repeat is there.  Perhaps there's an
  expectation that someone will repeat the problem.
 
  But, I agree - more information is very rarely the wrong thing to do.
 
 >                                                 Meantime, I'll try to
 > read slower. :-)
 
  Yeah, I know exactly what you mean :-)  
 
 	- Dave Rivers -
 
 

From: Bjoern Groenvall <bg@sics.se>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, tege@swox.se
Subject: Re: kern/16568: How to crash FreeBSD 4.4
Date: 16 Feb 2000 14:50:44 +0100

 Hi Sheldon,
 
 First off I would like to apologize for the "FreeBSD 4.4" typo, this
 is about *3.4*. I'm sorry about that!
 
 Sheldon Hearn <sheldonh@uunet.co.za> writes:
 
 > On Mon, 07 Feb 2000 20:07:43 +0100, Bjoern Groenvall wrote:
 > 
 > > Compile and run the following program. If you don't get a panic on the
 > > first try, Ctrl-C and rerun.
 > 
 > It looks like an obfuscated fork-bomb, which is nothing new and can be
 > controlled with the maxproc capability in login.conf(5).
 
 Please note that there is a wait(0) under case 0: it's not a fork
 bomb. The problem seems to be related to trashing the struct filedesc
 and only happens when it is large. I.e, have at least one large
 numbered file descriptor.
 
 > Could you please try this in a session for which "max user processes"
 > (as reported by ulimit -a) is limited to some sane number and provide
 > feedback?
 
 Now limited with ulimit -u 50 as per example below. Note that it took
 three tries before it paniced.
 
 Script started on Wed Feb 16 14:32:51 2000
 mummel$ telnet pao
 Trying 193.10.66.61...
 Connected to pao.sics.se.
 Escape character is '^]'.
 [ Trying mutual KERBEROS4 ... ]
 [ Kerberos V4 accepts you ]
 [ Kerberos V4 challenge successful ]
 pao$ ulimit -u 50
 pao$ a.out
 fd = 4126
 ...........................................................<deleted>
 pao$ a.out
 fd = 4126
 ...........................................................<deleted>
 pao$ a.out
 fd = 4126
 ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... ................................................................................................................................................................................................................................................................................................................................................................Connection closed by foreign host.
 mummel$ exit
 exit
 
 script done on Wed Feb 16 14:36:06 2000
 
 bash# gdb -k kernel.6 vmcore.6 
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "i386-unknown-freebsd"...
 (no debugging symbols found)...
 IdlePTD 2977792
 initial pcb at 2646a4
 panicstr: page fault
 panic messages:
 ---
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x181b0
 fault code              = supervisor write, page not present
 instruction pointer     = 0x8:0xc014a31f
 stack pointer           = 0x10:0xc7260f08
 frame pointer           = 0x10:0xc7260f2c
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 14828 (a.out)
 interrupt mask          = 
 trap number             = 12
 panic: page fault
 
 syncing disks... 26 25 20 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
 
 dumping to dev 40401, offset 316196
 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
 ---
 #0  0xc01514ff in boot ()
 (kgdb) bt
 #0  0xc01514ff in boot ()
 #1  0xc0151784 in at_shutdown ()
 #2  0xc0216aa5 in trap_fatal ()
 #3  0xc0216783 in trap_pfault ()
 #4  0xc0216426 in trap ()
 #5  0xc014a31f in fdcopy ()
 #6  0xc014c5f7 in fork1 ()
 #7  0xc014c0b7 in vfork ()
 #8  0xc0216ce7 in syscall ()
 #9  0xc020a40c in Xint0x80_syscall ()
 #10 0x8048509 in ?? ()
 (kgdb) 
 
 Note that maxusers is set to 128, as a side effect of this large
 struct filedesc are enabled.
 
 #
 #	$Id: PAO,v 1.1 1999/12/22 11:15:51 root Exp $
 
 machine		"i386"
 cpu		"I686_CPU"
 ident		PAO
 maxusers	128
 
 options		MATH_EMULATE		#Support for x87 emulation
 options		INET			#InterNETworking
 options		FFS			#Berkeley Fast Filesystem
 options		FFS_ROOT		#FFS usable as root device [keep this!]
 options		SOFTUPDATES
 options		MFS			#Memory Filesystem
 options		NFS			#Network Filesystem
 
 options		"COMPAT_43"		#Compatible with BSD 4.3 [KEEP THIS!]
 options		SCSI_DELAY=1000		#Be pessimistic about Joe SCSI device
 options		UCONSOLE		#Allow users to grab the console
 options		FAILSAFE		#Be conservative
 options		USERCONFIG		#boot -c editor
 options		VISUAL_USERCONFIG	#visual boot -c editor
 
 # This allows you to actually store this configuration file into
 # the kernel binary itself, where it may be later read by saying:
 #    strings -aout -n 3 /kernel | grep ^___ | sed -e 's/^___//' > MYKERNEL
 #
 options         INCLUDE_CONFIG_FILE     # Include this file in kernel
 
 config		kernel	root on da0s1a
 
 controller	isa0
 controller	eisa0
 controller	pci0
 
 controller	fdc0	at isa? port "IO_FD1" bio irq 6 drq 2
 disk		fd0	at fdc0 drive 0
 disk		fd1	at fdc0 drive 1
 
 options		ATAPI		#Enable ATAPI support for IDE bus
 options		ATAPI_STATIC	#Don't do it as an LKM
 device		acd0		#IDE CD-ROM
 device		wfd0		#IDE Floppy (e.g. LS-120)
 
 # A single entry for any of these controllers (ncr, ahb, ahc) is
 # sufficient for any number of installed devices.
 controller	ncr0
 controller	ahb0
 controller	ahc0
 controller	isp0
 
 # This controller offers a number of configuration options, too many to
 # document here  - see the LINT file in this directory and look up the
 # dpt0 entry there for much fuller documentation on this.
 controller      dpt0
 
 controller	adw0
 
 controller	scbus0
 
 device		da0
 
 device		sa0
 
 device		pass0
 
 device		cd0	#Only need one of these, the code dynamically grows
 
 # atkbdc0 controlls both the keyboard and the PS/2 mouse
 controller	atkbdc0	at isa? port IO_KBD tty
 device		atkbd0	at isa? tty irq 1
 device		psm0	at isa? tty irq 12
 
 device		vga0	at isa? port ? conflicts
 
 # splash screen/screen saver
 pseudo-device	splash
 
 # syscons is the default console driver, resembling an SCO console
 device		sc0	at isa? tty
 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
 #device		vt0	at isa? tty
 #options		XSERVER			# support for X server
 #options		FAT_CURSOR		# start with block cursor
 # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
 #options		PCVT_SCANSET=2		# IBM keyboards are non-std
 
 device		npx0	at isa? port IO_NPX irq 13
 
 device		sio0	at isa? port "IO_COM1" flags 0x10 tty irq 4
 device		sio1	at isa? port "IO_COM2" tty irq 3
 device		sio2	at isa? disable port "IO_COM3" tty irq 5
 device		sio3	at isa? disable port "IO_COM4" tty irq 9
 
 # Parallel port
 device		ppc0	at isa? port? net irq 7
 controller	ppbus0
 device		nlpt0	at ppbus?
 device		plip0	at ppbus?
 device		ppi0	at ppbus?
 #controller	vpo0	at ppbus?
 
 # Order is important here due to intrusive probes, do *not* alphabetize
 # this list of network interfaces until the probes have been fixed.
 # Right now it appears that the ie0 must be probed before ep0. See
 # revision 1.20 of this file.
 device fxp0
 
 pseudo-device	loop
 pseudo-device	ether
 pseudo-device	sl	4
 pseudo-device	ppp	4
 pseudo-device	tun	4
 pseudo-device	pty	16
 pseudo-device	gzip		# Exec gzipped a.out's
 
 # KTRACE enables the system-call tracing facility ktrace(2).
 # This adds 4 KB bloat to your kernel, and slightly increases
 # the costs of each syscall.
 options		KTRACE		#kernel tracing
 
 # This provides support for System V shared memory and message queues.
 #
 options		SYSVSHM
 options		SYSVMSG
 options		SYSVSEM
 
 #  The `bpfilter' pseudo-device enables the Berkeley Packet Filter.  Be
 #  aware of the legal and administrative consequences of enabling this
 #  option.  The number of devices determines the maximum number of
 #  simultaneous BPF clients programs runnable.
 pseudo-device	bpfilter 8	#Berkeley packet filter
 
 
 Cheers,
 Bjrn
 
 -- 
   _     _                                               ,_______________.  
 Bjorn Gronvall (Bjrn Grnvall)                        /_______________/|     
 Swedish Institute of Computer Science                  |               ||
 PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
 Email: bg@sics.se, Phone +46 -8 633 15 25              |      Cat      |/
 Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 
 

From: Bjoern Groenvall <bg@sics.se>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, tege@swox.se
Subject: Re: kern/16568: How to crash FreeBSD 4.4
Date: 16 Feb 2000 14:50:44 +0100

 Hi Sheldon,
 
 First off I would like to apologize for the "FreeBSD 4.4" typo, this
 is about *3.4*. I'm sorry about that!
 
 Sheldon Hearn <sheldonh@uunet.co.za> writes:
 
 > On Mon, 07 Feb 2000 20:07:43 +0100, Bjoern Groenvall wrote:
 > 
 > > Compile and run the following program. If you don't get a panic on the
 > > first try, Ctrl-C and rerun.
 > 
 > It looks like an obfuscated fork-bomb, which is nothing new and can be
 > controlled with the maxproc capability in login.conf(5).
 
 Please note that there is a wait(0) under case 0: it's not a fork
 bomb. The problem seems to be related to trashing the struct filedesc
 and only happens when it is large. I.e, have at least one large
 numbered file descriptor.
 
 > Could you please try this in a session for which "max user processes"
 > (as reported by ulimit -a) is limited to some sane number and provide
 > feedback?
 
 Now limited with ulimit -u 50 as per example below. Note that it took
 three tries before it paniced.
 
 Script started on Wed Feb 16 14:32:51 2000
 mummel$ telnet pao
 Trying 193.10.66.61...
 Connected to pao.sics.se.
 Escape character is '^]'.
 [ Trying mutual KERBEROS4 ... ]
 [ Kerberos V4 accepts you ]
 [ Kerberos V4 challenge successful ]
 pao$ ulimit -u 50
 pao$ a.out
 fd = 4126
 ...........................................................<deleted>
 pao$ a.out
 fd = 4126
 ...........................................................<deleted>
 pao$ a.out
 fd = 4126
 ............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................... ................................................................................................................................................................................................................................................................................................................................................................Connection closed by foreign host.
 mummel$ exit
 exit
 
 script done on Wed Feb 16 14:36:06 2000
 
 bash# gdb -k kernel.6 vmcore.6 
 GNU gdb 4.18
 Copyright 1998 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type "show copying" to see the conditions.
 There is absolutely no warranty for GDB.  Type "show warranty" for details.
 This GDB was configured as "i386-unknown-freebsd"...
 (no debugging symbols found)...
 IdlePTD 2977792
 initial pcb at 2646a4
 panicstr: page fault
 panic messages:
 ---
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x181b0
 fault code              = supervisor write, page not present
 instruction pointer     = 0x8:0xc014a31f
 stack pointer           = 0x10:0xc7260f08
 frame pointer           = 0x10:0xc7260f2c
 code segment            = base 0x0, limit 0xfffff, type 0x1b
                         = DPL 0, pres 1, def32 1, gran 1
 processor eflags        = interrupt enabled, resume, IOPL = 0
 current process         = 14828 (a.out)
 interrupt mask          = 
 trap number             = 12
 panic: page fault
 
 syncing disks... 26 25 20 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up
 
 dumping to dev 40401, offset 316196
 dump 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 
 ---
 #0  0xc01514ff in boot ()
 (kgdb) bt
 #0  0xc01514ff in boot ()
 #1  0xc0151784 in at_shutdown ()
 #2  0xc0216aa5 in trap_fatal ()
 #3  0xc0216783 in trap_pfault ()
 #4  0xc0216426 in trap ()
 #5  0xc014a31f in fdcopy ()
 #6  0xc014c5f7 in fork1 ()
 #7  0xc014c0b7 in vfork ()
 #8  0xc0216ce7 in syscall ()
 #9  0xc020a40c in Xint0x80_syscall ()
 #10 0x8048509 in ?? ()
 (kgdb) 
 
 Note that maxusers is set to 128, as a side effect of this large
 struct filedesc are enabled.
 
 #
 #	$Id: PAO,v 1.1 1999/12/22 11:15:51 root Exp $
 
 machine		"i386"
 cpu		"I686_CPU"
 ident		PAO
 maxusers	128
 
 options		MATH_EMULATE		#Support for x87 emulation
 options		INET			#InterNETworking
 options		FFS			#Berkeley Fast Filesystem
 options		FFS_ROOT		#FFS usable as root device [keep this!]
 options		SOFTUPDATES
 options		MFS			#Memory Filesystem
 options		NFS			#Network Filesystem
 
 options		"COMPAT_43"		#Compatible with BSD 4.3 [KEEP THIS!]
 options		SCSI_DELAY=1000		#Be pessimistic about Joe SCSI device
 options		UCONSOLE		#Allow users to grab the console
 options		FAILSAFE		#Be conservative
 options		USERCONFIG		#boot -c editor
 options		VISUAL_USERCONFIG	#visual boot -c editor
 
 # This allows you to actually store this configuration file into
 # the kernel binary itself, where it may be later read by saying:
 #    strings -aout -n 3 /kernel | grep ^___ | sed -e 's/^___//' > MYKERNEL
 #
 options         INCLUDE_CONFIG_FILE     # Include this file in kernel
 
 config		kernel	root on da0s1a
 
 controller	isa0
 controller	eisa0
 controller	pci0
 
 controller	fdc0	at isa? port "IO_FD1" bio irq 6 drq 2
 disk		fd0	at fdc0 drive 0
 disk		fd1	at fdc0 drive 1
 
 options		ATAPI		#Enable ATAPI support for IDE bus
 options		ATAPI_STATIC	#Don't do it as an LKM
 device		acd0		#IDE CD-ROM
 device		wfd0		#IDE Floppy (e.g. LS-120)
 
 # A single entry for any of these controllers (ncr, ahb, ahc) is
 # sufficient for any number of installed devices.
 controller	ncr0
 controller	ahb0
 controller	ahc0
 controller	isp0
 
 # This controller offers a number of configuration options, too many to
 # document here  - see the LINT file in this directory and look up the
 # dpt0 entry there for much fuller documentation on this.
 controller      dpt0
 
 controller	adw0
 
 controller	scbus0
 
 device		da0
 
 device		sa0
 
 device		pass0
 
 device		cd0	#Only need one of these, the code dynamically grows
 
 # atkbdc0 controlls both the keyboard and the PS/2 mouse
 controller	atkbdc0	at isa? port IO_KBD tty
 device		atkbd0	at isa? tty irq 1
 device		psm0	at isa? tty irq 12
 
 device		vga0	at isa? port ? conflicts
 
 # splash screen/screen saver
 pseudo-device	splash
 
 # syscons is the default console driver, resembling an SCO console
 device		sc0	at isa? tty
 # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
 #device		vt0	at isa? tty
 #options		XSERVER			# support for X server
 #options		FAT_CURSOR		# start with block cursor
 # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
 #options		PCVT_SCANSET=2		# IBM keyboards are non-std
 
 device		npx0	at isa? port IO_NPX irq 13
 
 device		sio0	at isa? port "IO_COM1" flags 0x10 tty irq 4
 device		sio1	at isa? port "IO_COM2" tty irq 3
 device		sio2	at isa? disable port "IO_COM3" tty irq 5
 device		sio3	at isa? disable port "IO_COM4" tty irq 9
 
 # Parallel port
 device		ppc0	at isa? port? net irq 7
 controller	ppbus0
 device		nlpt0	at ppbus?
 device		plip0	at ppbus?
 device		ppi0	at ppbus?
 #controller	vpo0	at ppbus?
 
 # Order is important here due to intrusive probes, do *not* alphabetize
 # this list of network interfaces until the probes have been fixed.
 # Right now it appears that the ie0 must be probed before ep0. See
 # revision 1.20 of this file.
 device fxp0
 
 pseudo-device	loop
 pseudo-device	ether
 pseudo-device	sl	4
 pseudo-device	ppp	4
 pseudo-device	tun	4
 pseudo-device	pty	16
 pseudo-device	gzip		# Exec gzipped a.out's
 
 # KTRACE enables the system-call tracing facility ktrace(2).
 # This adds 4 KB bloat to your kernel, and slightly increases
 # the costs of each syscall.
 options		KTRACE		#kernel tracing
 
 # This provides support for System V shared memory and message queues.
 #
 options		SYSVSHM
 options		SYSVMSG
 options		SYSVSEM
 
 #  The `bpfilter' pseudo-device enables the Berkeley Packet Filter.  Be
 #  aware of the legal and administrative consequences of enabling this
 #  option.  The number of devices determines the maximum number of
 #  simultaneous BPF clients programs runnable.
 pseudo-device	bpfilter 8	#Berkeley packet filter
 
 
 Cheers,
 Bjrn
 
 -- 
   _     _                                               ,_______________.  
 Bjorn Gronvall (Bjrn Grnvall)                        /_______________/|     
 Swedish Institute of Computer Science                  |               ||
 PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
 Email: bg@sics.se, Phone +46 -8 633 15 25              |      Cat      |/
 Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 
 

From: Bruce Evans <bde@zeta.org.au>
To: Bjoern Groenvall <bg@bg.sics.se>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, bg@sics.se, alc@FreeBSD.ORG
Subject: Re: kern/16568: How to crash FreeBSD 4.4
Date: Tue, 22 Feb 2000 20:01:30 +1100 (EST)

 On Mon, 7 Feb 2000, Bjoern Groenvall wrote:
 
 > >Number:         16568
 > >Category:       kern
 > >Synopsis:       How to crash FreeBSD 4.4
                                         ^^^ 3.4 (also affects 3.1)
 
 This seems to have been fixed as a side effect of a better optimisation
 in -current in rev.1.228 of pmap.c.  Try the following patch (derived
 from there).
 
 diff -c2 pmap.c~ pmap.c
 *** pmap.c~	Fri Sep  3 22:20:49 1999
 --- pmap.c	Tue Feb 22 19:22:52 2000
 ***************
 *** 1863,1872 ****
   	pv_table_t *ppv;
   	register unsigned *pte, tpte;
 - 	int nmodify;
 - 	int update_needed;
   	int s;
   
 - 	nmodify = 0;
 - 	update_needed = 0;
   #if defined(PMAP_DIAGNOSTIC)
   	/*
 --- 1863,1868 ----
 ***************
 *** 1907,1919 ****
   				ppv->pv_vm_page->dirty = VM_PAGE_BITS_ALL;
   		}
 ! #ifdef SMP
 ! 		update_needed = 1;
 ! #else
 ! 		if (!update_needed &&
 ! 			((!curproc || (&curproc->p_vmspace->vm_pmap == pv->pv_pmap)) ||
 ! 			(pv->pv_pmap == kernel_pmap))) {
 ! 			update_needed = 1;
 ! 		}
 ! #endif
   		TAILQ_REMOVE(&pv->pv_pmap->pm_pvlist, pv, pv_plist);
   		TAILQ_REMOVE(&ppv->pv_list, pv, pv_list);
 --- 1903,1908 ----
   				ppv->pv_vm_page->dirty = VM_PAGE_BITS_ALL;
   		}
 ! 		invltlb_1pg(pv->pv_va);
 ! 
   		TAILQ_REMOVE(&pv->pv_pmap->pm_pvlist, pv, pv_plist);
   		TAILQ_REMOVE(&ppv->pv_list, pv, pv_list);
 ***************
 *** 1925,1933 ****
   	ppv->pv_vm_page->flags &= ~(PG_MAPPED | PG_WRITEABLE);
   
 - 	if (update_needed)
 - 		invltlb();
 - 
   	splx(s);
 - 	return;
   }
   
 --- 1914,1918 ----
 
 Hints on reproducing the bug:
 - Using the kernel config (PAO) in the PR is probably unnecessary.  The
   bug probably occurs with any config provided the maximum files limit
   is large enough for the memory allocation for fd_ofiles to be several
   pages.  I used a limit of 4136.
 - Limit the memory size.  The bug is much easier to reproduce with a
   memory size of 64M than with 320M.
 
 Notes:
 - An unconditional invltlb() at the end of pmap_remove_all() doesn't
   fix the bug.  I don't understand this, or why the old optimisation
   was wrong.  A conditional invltlb() at the end would be optimal for
   i386's if it worked.
 - The alpha pmap.c probably doesn't have the bug, even in RELENG_3, since
   the old "optimisation" was changed to the new one long ago in rev.1.9,
   apparently independently.
 
 Bruce
 
 

From: Bjoern Groenvall <bg@sics.se>
To: Bruce Evans <bde@zeta.org.au>
Cc: Bjoern Groenvall <bg@bg.sics.se>, tege@swox.se,
	FreeBSD-gnats-submit@FreeBSD.ORG, security-officer@FreeBSD.ORG,
	alc@FreeBSD.ORG, sheldonh@uunet.co.za, dima@rdy.com, imp@village.org,
	eivind@FreeBSD.ORG, jkh@zippy.cdrom.com
Subject: Re: kern/16568: How to crash FreeBSD 4.4
Date: 22 Feb 2000 19:09:31 +0100

 Bruce Evans <bde@zeta.org.au> writes:
 
 > On Mon, 7 Feb 2000, Bjoern Groenvall wrote:
 > 
 > > >Number:         16568
 > > >Category:       kern
 > > >Synopsis:       How to crash FreeBSD 4.4
 >                                         ^^^ 3.4 (also affects 3.1)
 > 
 > This seems to have been fixed as a side effect of a better optimisation
 > in -current in rev.1.228 of pmap.c.  Try the following patch (derived
 > from there).
 
 The patch has now been tested on one 3.4-RELEASE machine and (by
 tege@swox.se) on two different 3.3-RELEASE machines. The patch seems
 to fix the problem and we suggest that the fix is incorporated on the
 stable branch and that pr/16568 be closed.
 
 To all involved parties, thanks a lot for all the good work that you
 spent to resolve this issue, THANKS!
 
 Keep up the good work,
 Bjrn
 
 -- 
   _     _                                               ,_______________.  
 Bjorn Gronvall (Bjrn Grnvall)                        /_______________/|     
 Swedish Institute of Computer Science                  |               ||
 PO Box 1263, S-164 29 Kista, Sweden                    | Schroedingers ||
 Email: bg@sics.se, Phone +46 -8 633 15 25              |      Cat      |/
 Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30       `---------------' 
 

From: Panagiotis Christias <christia@noc.ntua.gr>
To: freebsd-gnats-submit@FreeBSD.org, bg@bg.sics.se
Cc:  
Subject: Re: kern/16568: How to crash FreeBSD 4.4
Date: Fri, 25 Feb 2000 17:51:25 +0200

 Hello,
 
 this is yet another report, this bug was responsible for crashing
 your four brand new cache boxes for the past 25 days during peak
 time, running FreeBSD-3.4STABLE(?) and the latest Squid (2.2STABLE5).
 
 Since installing the patch (4 days ago) all systems all running
 smoothly without any problem. I strongly suggest that you add the
 patch as soon as possible to the 3.0-stable branch. I'ld be
 surprised if this bug is responsible for several other crashes,
 like the kern/16890 case...
 
 Regards,
 Panagiotis, crash no more!
 
 --
 Panagiotis J. Christias    Network Management Center
 P.Christias@noc.ntua.gr    National Technical Univ. of Athens, GREECE
 
State-Changed-From-To: open->analyzed 
State-Changed-By: sheldonh 
State-Changed-When: Wed Mar 15 02:13:48 PST 2000 
State-Changed-Why:  
Bruce is going to be dealing with this in RELENG_3. 


Responsible-Changed-From-To: freebsd-bugs->bde 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Wed Mar 15 02:13:48 PST 2000 
Responsible-Changed-Why:  
Bruce knows what the problem is. 

Ooops, got these two mixed up. :-) 
State-Changed-From-To: analyzed->closed 
State-Changed-By: bde 
State-Changed-When: Sun Apr 30 01:27:32 PDT 2000 
State-Changed-Why:  
Fixed in pmap.c revs 1.219.2.7 (RELENG_3) and 1.251 (-current before 4.0 
branch). 
>Unformatted:
