From owner-freebsd-bugs Mon Jan 31 4: 0: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 9EA6114F86 for ; Mon, 31 Jan 2000 04:00:04 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id EAA67399; Mon, 31 Jan 2000 04:00:04 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Mon, 31 Jan 2000 04:00:04 -0800 (PST) Message-Id: <200001311200.EAA67399@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Terry Kennedy Subject: Re: kern/10872: Panic in soreceive() due to NULL mbuf pointer Reply-To: Terry Kennedy Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/10872; it has been noted by GNATS. From: Terry Kennedy To: freebsd-gnats-submit@freebsd.org Cc: bmilekic@dsuper.net Subject: Re: kern/10872: Panic in soreceive() due to NULL mbuf pointer Date: Mon, 31 Jan 2000 06:43:05 -0500 (EST) Bosko Milekic writes: > Considering all this, a fair assumption would be that the > tulip_rx_intr() panic was a side-effect of an mbuf shortage. Hopefully, > you will no longer obtain this particular panic. Unfortunately, I'm still getting hit with these regularly under 3.4- RELEASE (installed from the 29-Dec-2000 ISO). Right now, the system is dying with these every 15 to 20 minutes (it's a news server that nor- mally moves about .3TB/day). It doesn't look like an mbuf shortage - here's a netstat of the entrails: (0:12) news:/var/crash# netstat -m -M vmcore.0 941/1216 mbufs in use: 619 mbufs allocated to data 322 mbufs allocated to packet headers 519/708/32768 mbuf clusters in use (current/peak/max) 1568 Kbytes allocated to network (73% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines of course, netstat -M is broken and misreports the active system, not the actual values in the crash dump: (0:13) news:/var/crash# netstat -m -M vmcore.0 971/1216 mbufs in use: 688 mbufs allocated to data 283 mbufs allocated to packet headers 580/740/32768 mbuf clusters in use (current/peak/max) 1632 Kbytes allocated to network (78% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Note that the values are different each time I re-run netstat, despite giving the -M option. Frankly, I don't understand how a bug marked as critical, with a clear method to reproduce it, can stay unresolved from 3.1 through 3.4. The old CSRG 2BSD docs mentioned sending a $100 bill wrapped around a bug report if you wanted immediate attention to your bug. I know that was a joke, but is there a similar method that works for FreeBSD? I'm getting desperate! Here's the gdb backtrace. I have the kernel (w/ symbols) and dumpfile if anyone wants them (note the dumpfile is 384MB). I can also provide access to the system (though it will likely be annoying since it keeps crashing). Script started on Mon Jan 31 06:38:17 2000 (0:1) news:/var/crash# gdb -k kernel.0 vmcore.0 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"... IdlePTD 2928640 initial pcb at 25a8d8 panicstr: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2b0600 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c6187 stack pointer = 0x10:0xc02417d4 frame pointer = 0x10:0xc0241814 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 = Idle interrupt mask = net trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d28e0 stack pointer = 0x10:0xc024152c frame pointer = 0x10:0xc0241530 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 = Idle interrupt mask = net bio trap number = 12 panic: page fault dumping to dev 20001, offset 262144 dump 383 382 381 380 379 378 377 376 375 374 373 372 371 370 [...] 5 4 3 2 1 --- #0 boot (howto=260) at ../../kern/kern_shutdown.c:285 285 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:285 #1 0xc01416c0 in at_shutdown ( function=0xc023991a <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #2 0xc020c3d5 in trap_fatal (frame=0xc02414f0, eva=48) at ../../i386/i386/trap.c:942 #3 0xc020c0b3 in trap_pfault (frame=0xc02414f0, usermode=0, eva=48) at ../../i386/i386/trap.c:835 #4 0xc020bd2a in trap (frame={tf_es = 375717904, tf_ds = 16, tf_edi = -972519680, tf_esi = 0, tf_ebp = -1071377104, tf_isp = -1071377128, tf_ebx = -1071321596, tf_edx = -1073168320, tf_ecx = 0, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071830816, tf_cs = 8, tf_eflags = 66182, tf_esp = -834145536, tf_ss = -1071377072}) at ../../i386/i386/trap.c:437 #5 0xc01d28e0 in acquire_lock (lk=0xc024ee04) at ../../ufs/ffs/ffs_softdep.c:270 #6 0xc01d565b in initiate_write_inodeblock (inodedep=0xc6088700, bp=0xcdc47270) at ../../ufs/ffs/ffs_softdep.c:2788 #7 0xc01d540b in softdep_disk_io_initiation (bp=0xcdc47270) at ../../ufs/ffs/ffs_softdep.c:2648 #8 0xc0171bc6 in spec_strategy (ap=0xc02415b0) at ../../miscfs/specfs/spec_vnops.c:539 #9 0xc0171359 in spec_vnoperate (ap=0xc02415b0) at ../../miscfs/specfs/spec_vnops.c:129 #10 0xc01e1659 in ufs_vnoperatespec (ap=0xc02415b0) at ../../ufs/ufs/ufs_vnops.c:2318 #11 0xc015eeff in bwrite (bp=0xcdc47270) at vnode_if.h:891 #12 0xc0163502 in vop_stdbwrite (ap=0xc0241618) at ../../kern/vfs_default.c:296 #13 0xc016334d in vop_defaultop (ap=0xc0241618) at ../../kern/vfs_default.c:130 #14 0xc0171359 in spec_vnoperate (ap=0xc0241618) at ../../miscfs/specfs/spec_vnops.c:129 #15 0xc01e1659 in ufs_vnoperatespec (ap=0xc0241618) at ../../ufs/ufs/ufs_vnops.c:2318 #16 0xc015f8ab in vfs_bio_awrite (bp=0xcdc47270) at vnode_if.h:1145 #17 0xc01dacda in ffs_fsync (ap=0xc02416a0) at ../../ufs/ffs/ffs_vnops.c:205 #18 0xc01d9183 in ffs_sync (mp=0xc5ee4a00, waitfor=2, cred=0xc0e3a100, p=0xc026f8f4) at vnode_if.h:499 #19 0xc0167e27 in sync (p=0xc026f8f4, uap=0x0) at ../../kern/vfs_syscalls.c:549 #20 0xc0141281 in boot (howto=256) at ../../kern/kern_shutdown.c:203 #21 0xc01416c0 in at_shutdown ( function=0xc023991a <__set_sysinit_set_sym_memdev_sys_init+1050>, arg=0x0, queue=12) at ../../kern/kern_shutdown.c:446 #22 0xc020c3d5 in trap_fatal (frame=0xc0241798, eva=2819584) at ../../i386/i386/trap.c:942 #23 0xc020c0b3 in trap_pfault (frame=0xc0241798, usermode=0, eva=2819584) at ../../i386/i386/trap.c:835 #24 0xc020bd2a in trap (frame={tf_es = -1071906800, tf_ds = -974913520, tf_edi = -974858240, tf_esi = -1058292096, tf_ebp = -1071376364, tf_isp = -1071376448, tf_ebx = -1056483072, tf_edx = 518358, tf_ecx = -974857732, tf_eax = 2819584, tf_trapno = 12, tf_err = 0, tf_eip = -1071881849, tf_cs = 8, tf_eflags = 66055, tf_esp = -974858240, tf_ss = -60358592}) at ../../i386/i386/trap.c:437 #25 0xc01c6187 in tulip_rx_intr (sc=0xc5e4d800) at ../../pci/if_de.c:3649 #26 0xc01c67db in tulip_intr_handler (sc=0xc5e4d800, progress_p=0xc024183c) at ../../pci/if_de.c:3998 #27 0xc01c6939 in tulip_intr_normal (arg=0xc5e4d800) at ../../pci/if_de.c:4187 (kgdb) up 25 #25 0xc01c6187 in tulip_rx_intr (sc=0xc5e4d800) at ../../pci/if_de.c:3649 3649 MCLGET(m0, M_DONTWAIT); (kgdb) list 3644 MGETHDR(m0, M_DONTWAIT, MT_DATA); 3645 if (m0 != NULL) { 3646 #if defined(TULIP_COPY_RXDATA) 3647 if (!accept || total_len >= MHLEN) { 3648 #endif 3649 MCLGET(m0, M_DONTWAIT); 3650 if ((m0->m_flags & M_EXT) == 0) { 3651 m_freem(m0); 3652 m0 = NULL; 3653 } (kgdb) quit (0:2) news:/var/crash exit Script done on Mon Jan 31 06:39:29 2000 Terry Kennedy http://www.tmk.com terry@tmk.com Jersey City, NJ USA +1 201 451 4554 (voice) +1 201 451 0900 (FAX) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message