Date: Wed, 22 Jul 1998 13:49:55 -0400 (EDT) From: woods@zeus.leitch.com (Greg A. Woods) To: dg@root.com Cc: stable@FreeBSD.ORG Subject: Re: Tree tagging put off by ~12 hours. Message-ID: <199807221749.NAA24347@brain.zeus.leitch.com> In-Reply-To: David Greenman's message of "Tue, July 21, 1998 17:42:36 -0700" regarding "Re: Tree tagging put off by ~12 hours. " id <199807220042.RAA22499@implode.root.com> References: <199807211852.OAA04259@brain.zeus.leitch.com> <199807220042.RAA22499@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ On Tue, July 21, 1998 at 17:42:36 (-0700), David Greenman wrote: ]
> Subject: Re: Tree tagging put off by ~12 hours.
>
> The above error indicates that for whatever reason, the system couldn't
> page in the data it needed for a page fault. This type of error most often
> occurs when running a binary over NFS and having the file or the NFS server
> go away. It can also happen if the disk drive that it was on stops responding
> or has a bad block, etc. In no case does it indicate a problem with your
> memory, however.
I was worried that somehow the NMI problem also mentioned on this thread
might be related to the vm_fault events I witnessed on my machine here.
There's a slim chance (very very slim, mind you) that my window manager
was running over NFS (I had a copy of it in my ~/bin directory which is
NFS mounted), and I did remove it at some time yesterday, though I'm
almost 100% certain the removal occurred many hours after the vm_fault
error. The NFS server itself has been up for almost 86 days now, and
has never given any problem. I may be wrong about the removal though --
it's very hard to tell now. However how could one process running over
NFS cause several other un-related processes not running over NFS to
fail in the same way?
The primary system disk is still an IDE drive, which might explain the
problem, though it was definitely up and spinning before the second
process started vm_fault'ing. The swap space is spread over the IDE
(250MB) and the first SCSI drive (1GB), but there's also 256MB of RAM in
this machine and swap is rarely used (eg. since the reboot yesterday
there's still none used even though I've built kernels, run several
CVSUPs, cvs imported and updated the whole FreeBSD tree, run big emacs
processes, big netscape processes, two tkined sessions, etc., etc.,
etc.). I'll attach a dmesg FYI.
(BTW, if it is a paging problem with a binary running over NFS then I'd
consider the current behaviour to be a serious bug. This would be a
denial of service even on any less powerful hardware. NFS errors should
be treated identically regardless of whether they're found by a user
program or something in the kernel. Should a PR be opened on this?)
--
Greg A. Woods
+1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Copyright (c) 1992-1998 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 2.2.6-STABLE #1: Mon Jul 20 11:40:33 EDT 1998
woods@brain.zeus.leitch.com:/var/work.d/Leitch-BSD-2.2/sys/compile/BRAIN
CPU: Pentium II (267.27-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x633 Stepping=3
Features=0x80f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX>
real memory = 268435456 (262144K bytes)
avail memory = 260968448 (254852K bytes)
Probing for devices on PCI bus 0:
chip0 <generic PCI bridge (vendor=8086 device=7180 subclass=0)> rev 3 on pci0:0:0
chip1 <generic PCI bridge (vendor=8086 device=7181 subclass=4)> rev 3 on pci0:1:0
chip2 <Intel 82371AB PCI-ISA bridge> rev 1 on pci0:4:0
chip3 <Intel 82371AB IDE interface> rev 1 on pci0:4:1
chip4 <Intel 82371AB USB interface> rev 1 int d irq 9 on pci0:4:2
chip5 <Intel 82371AB Power management controller> rev 1 on pci0:4:3
vga0 <VGA-compatible display device> rev 154 on pci0:9:0
fxp0 <Intel EtherExpress Pro 10/100B Ethernet> rev 2 int a irq 10 on pci0:11:0
fxp0: Ethernet address 00:a0:c9:6c:7f:79
ahc0 <Adaptec 2940 Ultra SCSI host adapter> rev 1 int a irq 11 on pci0:12:0
ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs
ahc0: target 0 Tagged Queuing Device
(ahc0:0:0): "SEAGATE ST34501W 0018" type 0 fixed SCSI 2
sd0(ahc0:0:0): Direct-Access 4339MB (8887200 512 byte sectors)
sd0(ahc0:0:0): with 6576 cyls, 8 heads, and an average 168 sectors/track
ahc0: target 1 Tagged Queuing Device
(ahc0:1:0): "SEAGATE ST34501W 0018" type 0 fixed SCSI 2
sd1(ahc0:1:0): Direct-Access 4339MB (8887200 512 byte sectors)
sd1(ahc0:1:0): with 6576 cyls, 8 heads, and an average 168 sectors/track
ahc0: target 2 Tagged Queuing Device
(ahc0:2:0): "SEAGATE ST34501W 0013" type 0 fixed SCSI 2
sd2(ahc0:2:0): Direct-Access 4339MB (8887200 512 byte sectors)
sd2(ahc0:2:0): with 6576 cyls, 8 heads, and an average 168 sectors/track
probe0(ahc0:9:0): scsi_cmd
probe0(ahc0:9:0): scsi_done
(ahc0:9:0): command: 0,0,0,0,0,0-[0 bytes]
probe0(ahc0:9:0): scsi_cmd
probe0(ahc0:9:0): scsi_done
(ahc0:9:0): command: 12,0,0,0,2c,0-[44 bytes]
------------------------------
000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
032: 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------
Probing for devices on PCI bus 1:
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 at 0x60-0x64 irq 12 on motherboard
psm0: model Generic PS/2 mouse, device ID 0
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <WDC AC12100L>
wd0: 2014MB (4124736 sectors), 4092 cyls, 16 heads, 63 S/T, 512 B/S
npx0 on motherboard
npx0: INT 16 interface
lmhw0 at 0x290 on isa
lmhw0: found an LM78-J.
ccd0-3: Concatenated disk drivers
IP Filter: initialized. Default = pass all, Logging = disabled
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807221749.NAA24347>