From owner-freebsd-stable Mon Feb 11 6:26:29 2002 Delivered-To: freebsd-stable@freebsd.org Received: from sumter.awod.com (sumter.awod.com [208.140.99.1]) by hub.freebsd.org (Postfix) with ESMTP id 2922837B402 for ; Mon, 11 Feb 2002 06:26:18 -0800 (PST) Received: from teddy.fas.com (pcp01008475pcs.mplsnt01.sc.comcast.net [68.58.200.215]) by sumter.awod.com (8.8.7/8.12.2) with ESMTP id JAA92229; Mon, 11 Feb 2002 09:26:14 -0500 (EST) (envelope-from stanb@awod.com) Received: from stan by teddy.fas.com with local (Exim 3.34 #1 (Debian)) id 16aHPl-0004mO-00; Mon, 11 Feb 2002 09:26:41 -0500 Date: Mon, 11 Feb 2002 09:26:41 -0500 From: stan To: Danny Pansters Cc: FreeBSD Stable Mailing List Subject: Re: Kernel Panic on 4.5 STABLE Message-ID: <20020211142641.GA18239@teddy.fas.com> Mail-Followup-To: Danny Pansters , FreeBSD Stable Mailing List References: <20020209160959.GA1010@teddy.fas.com> <20020211021857.A094524D28@mail.ricin.net> <20020211040220.GA5800@teddy.fas.com> <20020211124717.2F89124D28@mail.ricin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20020211124717.2F89124D28@mail.ricin.net> User-Agent: Mutt/1.3.27i X-Editor: gVim X-Operating-System: Debian GNU/Linux X-Kernel-Version: 2.4.17 X-Uptime: 09:18:46 up 7 days, 14:54, 1 user, load average: 0.94, 0.37, 0.13 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Feb 11, 2002 at 01:47:41PM +0100, Danny Pansters wrote: > On Monday 11 February 2002 05:02, you wrote: > > > > BTWW, it's ipfw. A simple ipfw -a l will reliably panic my mahine. > > And, I;m not even using ipfw. The daily security check calls it ;-( >=20 > Pfff. OK I see where it happens. I don't run ipfw, neither do I have=20 > anything ipfw'ish in kernel config: >=20 > root@shaggy.ricin.net [/etc] # ipfw -a l > ipfw: getsockopt(IP_FW_GET): Protocol not available >=20 > I've never used ipfw, nor netgraph. Could it be that the latter=20 > causes the first to be loaded as a module?, e.g. try: >=20 > root@scooby.ricin.net [/etc/periodic/daily] # kldstat > Id Refs Address Size Name > 1 2 0xc0100000 1e5a30 kernel > 2 1 0xc1ee8000 c3000 vinum.ko Script started on Sun Feb 10 16:39:08 2002 black# kldstat -v Id Refs Address Size Name 1 6 0xc0100000 2a4384 kernel Contains modules: Id Name 7 rootbus 8 intsmb/smbus 9 alsmb/smbus 10 ichsmb/smbus 11 amdsmb/smbus 12 smbus/smb 13 bti2c/iicbb 14 lpbb/iicbb 15 pcf/iicbus 16 iicbb/iicbus 17 bti2c/iicbus 18 pci/ed 19 eisa/ahc 20 pci/ahc 21 miibus/ukphy 22 miibus/amphy 23 netgraph 24 miibus/brgphy 25 pci/uhci 26 pci/ohci 27 miibus/dcphy 28 miibus/e1000phy 29 miibus/xlphy 30 ohci/usb 31 uhci/usb 32 uhub/ugen 33 uhub/uhid 34 uhub/ums 35 uhub/ukbd 36 uhub/umass 37 usb/uhub 38 uhub/uhub 39 miibus/inphy 40 isab/isa 41 nexus/isa 42 isa/isahint 43 isa/orm 44 isa/pnp 45 isa/snd_ad1816 46 isa/snd_es1888 47 sbc/snd_ess 48 isa/esscontrol 49 isa/snd_gusc 50 isa/snd_mss 51 isa/snd_pnpmss 52 gusc/snd_guspcm 53 sbc/snd_sb16 54 sbc/snd_sb8 55 isa/snd_sbc 56 pci/snd_als 57 pci/snd_cmipci 58 pci/snd_cs4281 59 pci/snd_csa 60 csa/snd_csapcm 61 pci/snd_ds1 62 pci/snd_emu10k1 63 pci/emujoy 64 pci/snd_es137x 65 pci/fm801 66 pci/snd_ich 67 pci/snd_maestro 68 pci/snd_neomagic 69 pci/snd_solo 70 pci/snd_t4dwave 71 pci/via 72 pci/snd_sonicvibes 73 miibus/mlphy 74 miibus/nsphy 75 miibus/nsgphy 76 miibus/pnphy 77 miibus/pnaphy 78 miibus/tlphy 79 miibus/rlphy 80 snd_pcm 81 miibus/xmphy 82 isa/ata 83 pci/atapci 84 atapci/ata 85 miibus/lxtphy 86 miibus/qsphy 87 miibus/acphy 88 ppbus/plip 89 intpm/intsmb 90 pci/intpm 91 pcib/pci 92 pci/pcib 93 pci/isab 94 isa/ed 95 eisa/mainboard 96 isab/eisa 97 nexus/eisa 98 pci/chip 99 scterm-sc 100 scrndr-vga 101 pci/ign 102 nexus/apm 103 cardbus/ahc 104 ppbus/lpt 105 ahc 106 ppc/ppbus 107 ppbus/ppi 108 root/nexus 109 isa/fdc 110 fdc/fd 111 nexus/npx 112 nexus/pcib 113 vesa 114 atkbdc/atkbd 115 iicsmb/smbus 116 isa/atkbdc 117 isa/ppc 118 atkbdc/psm 119 isa/sio 120 pci/sio 121 isa/sc 122 isa/vga 123 bti2c/smbus 124 nfs 125 procfs 126 mfs 127 ufs 128 cd9660 129 msdos 130 ng_tty 131 ng_UI 132 ng_vjc 133 if_tun 134 if_gif 135 if_loop 136 ng_async 137 ng_bpf 138 ng_echo 139 ng_ether 140 ng_hole 141 ng_iface 142 ng_one2many 143 ng_rfc1490 144 ng_socket 145 ng_tee 146 elf 147 shell 148 aout 2 1 0xc03a5000 a2f8 agp.ko Contains modules: Id Name 1 pci/agp_intel 2 pci/agp_via 3 pci/agp_sis 4 pci/agp_ali 5 pci/agp_amd 6 pci/agp_i810 3 1 0xc2c93000 2000 warp_saver.ko Contains modules: Id Name 149 warp_saver 4 1 0xc2c95000 14000 linux.ko Contains modules: Id Name 150 linuxelf 151 linuxaout 5 1 0xc2cd0000 13000 radeon.ko Contains modules: Id Name 152 pci/radeon 6 1 0xc2d24000 2000 trafcount.ko Contains modules: Id Name 153 trafcount black# ;=08=1B[Kls -l /sbin/ipfw -r-xr-xr-x 1 root wheel 261432 Feb 10 16:13 /sbin/ipfw black# ls -l /modules/ipfw.ko -r-xr-xr-x 1 root wheel 27163 Feb 10 16:29 /modules/ipfw.ko black# ^D=08=08exit Script done on Sun Feb 10 16:39:36 2002 Doesn't look like it's geting loade. At least not untill ipfw runs, which _might_ cause it to be loaded? Or not? Any idea? >=20 > If this shows ipfw.ko or something alike then it's likely to be=20 > loaded on demand for some reason, while perhaps not having all teh=20 > kernel options at hand that it might need. Just a thought.=20 >=20 > [it is not always the case that using a module or compiling it into=20 > the kernel are two different ways of achieving the same, for example=20 > compiling vinum into the kernel won't work properly, using ipfilter > as module doesn't work exactly the same as when compiled into the=20 > kernel, etc] >=20 > Also check the timestamp of /etc/security to make sure it has been or=20 > doesn't need to be updated after installing world. You, or=20 > mergemaster for that matter, might have forgotten to diff it with a=20 > newer version (if present). If all else fails you could always remove=20 > the ipfw crud from the security script of course as last resort ;-)=20 >=20 Mergemaster was happy with it. Also just runing ipfw -a l will panic the machine. Yes I have presently set the defauls so that the daily secuirty check is not run. However I ahve absolutely no confidence that something else may not triger the same (or another) kerenel panic.=20 I'm not going to have confidence in this amchien till I track this down :-) BTW, on a differnt machine (PII vs Atholon) I get the smae usage message you do when I run ipfw -a l. I can replicate this panic with a kernel compiled from GENERIC, so I don't belive it's something I have wrong in the kernel config file. --=20 "They that would give up essential liberty for temporary safety deserve neither liberty nor safety." -- Benjamin Franklin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message