Date: Mon, 31 Jan 2000 04:00:04 -0800 (PST) From: Terry Kennedy <terry@tmk.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/10872: Panic in soreceive() due to NULL mbuf pointer Message-ID: <200001311200.EAA67399@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/10872; it has been noted by GNATS.
From: Terry Kennedy <terry@tmk.com>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001311200.EAA67399>