Date: Tue, 14 Jan 1997 10:04:54 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: freebsd-current@FreeBSD.org Cc: wjs@cs.duke.edu Subject: 2.2-BETA fsync panics -- h/w or s/w? Message-ID: <199701141504.KAA24341@snow.cs.duke.edu>
next in thread | raw e-mail | index | archive | help
We're attempting to build a web server out of what amounts to spare
parts. We've installed 2.2-BETA on it, and we're experiencing
reproducible panics (via hitting ctrl-g in the xemacs minibuffer,
xemacs is a binary from pacakges).
The machine is an old Micron 486dx2, and we're very suspicious of the
hardware, esp. the PCI bus. It has Buslogic 946 SCSI host adapter
with a 2G Seagate ST32550N which is used for swap and all fs except /,
& an old IDE disk that's being used for /.
Here is a stack trace & some variable values from one of the panics:
--------------------------------------------------------------------
(kgdb) where
#0 boot (howto=256) at ../../kern/kern_shutdown.c:243
#1 0xf010ce02 in panic (fmt=0xf01748ef "page fault")
at ../../kern/kern_shutdown.c:367
#2 0xf0175456 in trap_fatal (frame=0xefbffef0) at ../../i386/i386/trap.c:742
#3 0xf0174f44 in trap_pfault (frame=0xefbffef0, usermode=0)
at ../../i386/i386/trap.c:653
#4 0xf0174c1f in trap (frame={tf_es = 16, tf_ds = -266797040, tf_edi = 0,
tf_esi = -242894976, tf_ebp = -272629928, tf_isp = -272629992,
tf_ebx = -242911232, tf_edx = 1, tf_ecx = -242598528, tf_eax = 0,
tf_trapno = 12, tf_err = -242941952, tf_eip = -267205693,
tf_cs = -267255800, tf_eflags = 66118, tf_esp = -266768984,
tf_ss = -242911232}) at ../../i386/i386/trap.c:311
#5 0xf012c3c3 in fsync (p=0xf1857800, uap=0xefbfff94, retval=0xefbfff84)
at ../../kern/vfs_syscalls.c:1866
#6 0xf0175693 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 0,
tf_esi = 2616704, tf_ebp = -272639796, tf_isp = -272629788, tf_ebx = 1,
tf_edx = -1, tf_ecx = 1883136, tf_eax = 95, tf_trapno = 0, tf_err = 7,
tf_eip = 137380369, tf_cs = 31, tf_eflags = 646, tf_esp = -272639824,
tf_ss = 39}) at ../../i386/i386/trap.c:892
#7 0x8304211 in ?? ()
#8 0x958e3 in ?? ()
#9 0x9594d in ?? ()
#10 0x95989 in ?? ()
#11 0x2231b in ?? ()
#12 0x21fc5 in ?? ()
#13 0x12a33 in ?? ()
#14 0x12bf7 in ?? ()
#15 0x2eac3 in ?? ()
#16 0x2fd36 in ?? ()
#17 0x1124d in ?? ()
#18 0x110d4 in ?? ()
#19 0x240d5 in ?? ()
#20 0x10c70 in ?? ()
#21 0x10c8c in ?? ()
#22 0x23dfc in ?? ()
#23 0x10e10 in ?? ()
#24 0x21b79 in ?? ()
#25 0x21ee4 in ?? ()
#26 0x1095 in ?? ()
(kgdb) up 5
#5 0xf012c3c3 in fsync (p=0xf1857800, uap=0xefbfff94, retval=0xefbfff84)
at ../../kern/vfs_syscalls.c:1866
1866 error = VOP_FSYNC(vp, fp->f_cred,
(kgdb) l
1861 vp = (struct vnode *)fp->f_data;
1862 VOP_LOCK(vp);
1863 if (vp->v_object) {
1864 vm_object_page_clean(vp->v_object, 0, 0 ,0, FALSE);
1865 }
1866 error = VOP_FSYNC(vp, fp->f_cred,
1867 (vp->v_mount->mnt_flag & MNT_ASYNC) ? MNT_NOWAIT : MNT_WAIT, p);
1868 VOP_UNLOCK(vp);
1869 return (error);
1870 }
(kgdb) p *fp
$6 = {f_list = {le_next = 0xf19d6f00, le_prev = 0xf197f700}, f_flag = 67,
f_type = 1, f_count = 8, f_msgcount = 0, f_cred = 0xf1412800,
f_ops = 0xf01981e0, f_offset = 0x00000000000012b9, f_data = 0xf185b780 ""}
(kgdb) p *vp
$7 = {v_flag = 0, v_usecount = 1, v_writecount = 1, v_holdcnt = 0,
v_lastr = 0, v_id = 3840, v_mount = 0x0, v_op = 0xf1818d00, v_freelist = {
tqe_next = 0x0, tqe_prev = 0xf1872520}, v_mntvnodes = {
le_next = 0xf185b680, le_prev = 0xf183f0a8}, v_cleanblkhd = {
lh_first = 0x0}, v_dirtyblkhd = {lh_first = 0x0}, v_numoutput = 0,
v_type = VBAD, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0,
vu_specinfo = 0x0, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 0,
v_cstart = 0, v_lasta = 0, v_clen = 0, v_ralen = 0, v_usage = 13,
v_maxra = 0, v_object = 0x0, v_tag = VT_NON, v_data = 0x0}
(kgdb) p vp->v_mount
$8 = (struct mount *) 0x0
--------------------------------------------------------------------
Notice that vp->v_mount is null.
And here's some boot output which describes the hardware better:
--------------------------------------------------------------------
Copyright (c) 1992-1996 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 2.2-BETA_A #0: Fri Jan 10 10:58:25 EST 1997
gallatin@tmp-xxx.cs.duke.edu:/usr/src/sys/compile/POC
Calibrating clock(s) relative to mc146818A clock ... i8254 clock: 1193158 Hz
CPU: i486 DX2 (486-class CPU)
Origin = "GenuineIntel" Id = 0x436 Stepping=6
Features=0xb<FPU,VME,PSE>
real memory = 41943040 (40960K bytes)
avail memory = 39546880 (38620K bytes)
Probing for devices on PCI bus 0:
chip0 <Intel 82424ZX (Saturn) cache DRAM controller> rev 4 on pci0:0
chip1 <Intel 82378ZB PCI-ISA bridge> rev 3 on pci0:2
pci0:3: CMD, device=0x0640, class=storage (ide) int a irq 14 [no driver assigned]
bt0 <Buslogic 946 SCSI host adapter> rev 0 int a irq 11 on pci0:15
bt0: Bt946C/ 0-(32bit) bus
bt0: reading board settings, busmastering, int=11
bt0: version 4.28D, async only, parity, 32 mbxs, 32 ccbs
bt0: targ 3 async
bt0: Using Strict Round robin scheme
bt0 waiting for scsi devices to settle
(bt0:3:0): "SEAGATE ST32550N 0021" type 0 fixed SCSI 2
sd0(bt0:3:0): Direct-Access 2047MB (4194058 512 byte sectors)
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
lpt0 at 0x378-0x37f irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface
psm0: disabled, not probed.
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: NEC 72065B
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <Conner Peripherals 420MB - CFS420A>
wd0: 406MB (832608 sectors), 826 cyls, 16 heads, 63 S/T, 512 B/S
bt: unit number (1) too high
bt1 not found at 0x330
1 3C5x9 board(s) on ISA found at 0x300
ep0 at 0x300-0x30f irq 10 on isa
ep0: utp[*UTP*] address 00:20:af:71:3f:17
npx0 on motherboard
npx0: INT 16 interface
--------------------------------------------------------------------
The basic question is: Are these panics hardware or software related?
I'm personally inclined to blame hardware, but it would be nice to get
a second opinion.
Many thanks,
Drew
------------------------------------------------------------------------------
Andrew Gallatin
Duke University Internet: gallatin@cs.duke.edu
Department of Computer Science Phone: (919) 660-6590
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701141504.KAA24341>