7.2-STABLE i386 box crashing -- clues?

View: New views
5 Messages — Rating Filter:   Alert me  

7.2-STABLE i386 box crashing -- clues?

by David Wolfskill :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Sometimes, I find hardware Seriously Annoying.

I'm getting pretty close to that in the present case.

I have a pretty normal machine ; it's an Intel D865GBF desktop
system board in a rack-mount 2U chssis; a single 2.6 GHz CPU where I've
(presently) deiabled hyperthreading (in an effort to un-complexify
things).

I've enabled KDB.  I've gone into the BIOS to check the hardware "events
log".  I've set up serial console, and am running tip(1) to it from
within script(1) from another machine.  Nothing.  No clues.

Every once in a while, it just crashes -- hard.  It loses video output
at that point; Ctl+Alt+Esc doesn't appear to change anything; entering
(say) "reset" blindly at that point has no apparent effect.

Either a reset switch or a power cycle bring s the machine back up again
... for a while.

Someone suggested that memory might be at fault; it had 2 512 MB PC3200
DIMMs.  Local place advertised having compatible Kingston memory of
those specs for $10/DIMM; when I got there, they said that it was out of
stock and they weren't getting any more, but they did have 1GB PC3200
DIMMs.  So I went ahead & got them (though it was rather more than $20),
and the next time it crashed, I swapped the memory.

This morning when I got up, it had crashed again.  I recalled that I had
at one point been hoping to run backups (to tape) from the machine, and
accordingly, had attached a SCSI host adaptor via PCI riser card.  Since
I had nothing actually connected to the card, I pulled it out of the
machine before bringing it back up.  (I also fleft around for
excessively warm spots; nothing.  All fans spin up, as well.)

Well, it just crashed again.

Flaky CPU?  Flaky power supply?  How might I tell?

Attached dmesg.boot is from most recent boot, so it won't show the SCSI
card I pulled.

Please include me on replies, as I'm not subscribed to hardware@.

Please include me on replies, as I'm not subscribed to hardware@.
Reply-To sewt for convenience.
I've set Reply-To for convenience.

Thanks...

Peace,
david
--
David H. Wolfskill david@...
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.2-STABLE #173 r198984: Fri Nov  6 13:53:16 PST 2009
    root@...:/common/S3/obj/usr/src/sys/ALBERT i386
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2593.68-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf29  Stepping = 9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x4400<CNXT-ID,xTPR>
  Logical CPUs per core: 2
real memory  = 2145579008 (2046 MB)
avail memory = 2089758720 (1992 MB)
ACPI APIC Table: <INTEL  D865GBF >
ioapic0 <Version 2.0> irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: <INTEL D865GBF> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: reservation of 0, a0000 (3) failed
acpi0: reservation of 100000, 7fe00000 (3) failed
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xec00-0xec07 mem 0xf0000000-0xf7ffffff,0xffa80000-0xffafffff irq 16 at device 2.0 on pci0
agp0: <Intel 82865G (865G GMCH) SVGA controller> on vgapci0
agp0: detected 892k stolen memory
agp0: aperture size is 128M
uhci0: <Intel 82801EB (ICH5) USB controller USB-A> port 0xdc00-0xdc1f irq 16 at device 29.0 on pci0
uhci0: [GIANT-LOCKED]
uhci0: [ITHREAD]
usb0: <Intel 82801EB (ICH5) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0
uhub0: 2 ports with 2 removable, self powered
uhci1: <Intel 82801EB (ICH5) USB controller USB-B> port 0xe000-0xe01f irq 19 at device 29.1 on pci0
uhci1: [GIANT-LOCKED]
uhci1: [ITHREAD]
usb1: <Intel 82801EB (ICH5) USB controller USB-B> on uhci1
usb1: USB revision 1.0
uhub1: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1
uhub1: 2 ports with 2 removable, self powered
uhci2: <Intel 82801EB (ICH5) USB controller USB-C> port 0xe400-0xe41f irq 18 at device 29.2 on pci0
uhci2: [GIANT-LOCKED]
uhci2: [ITHREAD]
usb2: <Intel 82801EB (ICH5) USB controller USB-C> on uhci2
usb2: USB revision 1.0
uhub2: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb2
uhub2: 2 ports with 2 removable, self powered
uhci3: <Intel 82801EB (ICH5) USB controller USB-D> port 0xe800-0xe81f irq 16 at device 29.3 on pci0
uhci3: [GIANT-LOCKED]
uhci3: [ITHREAD]
usb3: <Intel 82801EB (ICH5) USB controller USB-D> on uhci3
usb3: USB revision 1.0
uhub3: <Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb3
uhub3: 2 ports with 2 removable, self powered
ehci0: <Intel 82801EB/R (ICH5) USB 2.0 controller> mem 0xffa7fc00-0xffa7ffff irq 23 at device 29.7 on pci0
ehci0: [GIANT-LOCKED]
ehci0: [ITHREAD]
usb4: EHCI version 1.0
usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3
usb4: <Intel 82801EB/R (ICH5) USB 2.0 controller> on ehci0
usb4: USB revision 2.0
uhub4: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb4
uhub4: 8 ports with 8 removable, self powered
pcib1: <ACPI PCI-PCI bridge> at device 30.0 on pci0
pci1: <ACPI PCI bus> on pcib1
fxp0: <Intel 82801BA (D865) Pro/100 VE Ethernet> port 0xcc00-0xcc3f mem 0xff8ff000-0xff8fffff irq 20 at device 8.0 on pci1
miibus0: <MII bus> on fxp0
inphy0: <i82562ET 10/100 media interface> PHY 1 on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp0: Ethernet address: 00:0c:f1:8f:fd:69
fxp0: [ITHREAD]
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH5 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
ichsmb0: <Intel 82801EB (ICH5) SMBus controller> port 0xd800-0xd81f irq 17 at device 31.3 on pci0
ichsmb0: [GIANT-LOCKED]
ichsmb0: [ITHREAD]
smbus0: <System Management Bus> on ichsmb0
smb0: <SMBus generic I/O> on smbus0
pcm0: <Intel ICH5 (82801EB)> mem 0xffa7f800-0xffa7f9ff,0xffa7f400-0xffa7f4ff irq 17 at device 31.5 on pci0
pcm0: [ITHREAD]
pcm0: primary codec not ready!
pcm0: <Analog Devices AD1985 AC97 Codec>
acpi_button0: <Sleep Button> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
fdc0: <floppy drive controller> port 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
sio0: type 16550A, console
sio0: [FILTER]
cpu0: <ACPI CPU> on acpi0
p4tcc0: <CPU Frequency Thermal Control> on cpu0
pmtimer0 on isa0
orm0: <ISA Option ROM> at iomem 0xc0000-0xc9fff pnpid ORM0000 on isa0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
ppbus0: [ITHREAD]
plip0: <PLIP network interface> on ppbus0
plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
ppc0: [GIANT-LOCKED]
ppc0: [ITHREAD]
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounter "TSC" frequency 2593681984 Hz quality 800
Timecounters tick every 1.000 msec
ad0: 152627MB <WDC WD1600AAJB-22WRA0 58.01H58> at ata0-master UDMA100
ad1: 238475MB <Hitachi HDS722525VLAT80 V36OA6MA> at ata0-slave UDMA100
acd0: CDROM <SONY CD-ROM CDU5221/1.01> at ata1-master UDMA33
Trying to mount root from ufs:/dev/ad0s2a
WARNING: / was not properly dismounted
Limiting icmp unreach response from 235 to 200 packets/sec


attachment0 (203 bytes) Download Attachment

Re: 7.2-STABLE i386 box crashing -- clues?

by Peter Jeremy-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I can't offer any solutions but I have some more questions...

On 2009-Nov-11 09:37:47 -0800, David Wolfskill <david@...> wrote:
>Every once in a while, it just crashes -- hard.  It loses video output
>at that point; Ctl+Alt+Esc doesn't appear to change anything; entering
>(say) "reset" blindly at that point has no apparent effect.

Roughly how often?

Has anything unusual happened lately?  Brownout, blackout, power surge,
lightning, heatwave, ...

>accordingly, had attached a SCSI host adaptor via PCI riser card.  Since
>I had nothing actually connected to the card, I pulled it out of the
>machine before bringing it back up.

Did you also pull the riser card?  Riser cards don't have a spectacularly
high reputation.

> (I also fleft around for
>excessively warm spots; nothing.  All fans spin up, as well.)

I don't suppose you also studied the capacitors on the motherboard.
Are any showing any signs of bulges?

Have you tried reseating everything?

>Flaky CPU?  Flaky power supply?  How might I tell?

CPU shouldn't go flaky unless it's been overheated.  In my experience,
PSUs are the least reliable part of consumer-grade hardware but about
the only way to check is to swap it.  If you've got a DMM, you could
check all the rails but there are lots of failure modes that won't
show up that way.

Have you checked the voltage/temperature screen in the BIOS?  Does
anything look abnormal?

Are you using a PS/2 or USB keyboard?

Are you running X?

At this stage, my suggestion would be to try swapping the PSU.

--
Peter Jeremy


attachment0 (203 bytes) Download Attachment

Re: 7.2-STABLE i386 box crashing -- clues?

by David Wolfskill :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, Nov 12, 2009 at 05:27:09PM +1100, Peter Jeremy wrote:
> I can't offer any solutions but I have some more questions...

I appreciate the help!

> ...
> >Every once in a while, it just crashes -- hard.  It loses video output
> >at that point; Ctl+Alt+Esc doesn't appear to change anything; entering
> >(say) "reset" blindly at that point has no apparent effect.
>
> Roughly how often?

For the current month:

albert(7.2-S)[8] last reboot shutdown
reboot           ~                         Thu Nov 12 03:04
reboot           ~                         Wed Nov 11 20:06
reboot           ~                         Wed Nov 11 14:42
shutdown         ~                         Wed Nov 11 14:40
reboot           ~                         Wed Nov 11 14:35
reboot           ~                         Wed Nov 11 10:05
reboot           ~                         Wed Nov 11 09:09
reboot           ~                         Wed Nov 11 04:25
reboot           ~                         Tue Nov 10 12:49
reboot           ~                         Mon Nov  9 14:52
reboot           ~                         Sun Nov  8 17:42
reboot           ~                         Sat Nov  7 04:22
reboot           ~                         Fri Nov  6 21:43
reboot           ~                         Fri Nov  6 19:00
reboot           ~                         Fri Nov  6 16:20
shutdown         ~                         Fri Nov  6 16:17
reboot           ~                         Fri Nov  6 16:03
reboot           ~                         Fri Nov  6 13:07
reboot           ~                         Fri Nov  6 09:46
reboot           ~                         Thu Nov  5 16:41
reboot           ~                         Thu Nov  5 13:32
reboot           ~                         Thu Nov  5 12:59
reboot           ~                         Thu Nov  5 10:17
reboot           ~                         Thu Nov  5 04:26
reboot           ~                         Wed Nov  4 20:32
reboot           ~                         Wed Nov  4 15:48
reboot           ~                         Wed Nov  4 10:37
reboot           ~                         Tue Nov  3 13:15
reboot           ~                         Tue Nov  3 10:55
reboot           ~                         Tue Nov  3 04:16
reboot           ~                         Mon Nov  2 18:13
reboot           ~                         Sun Nov  1 20:03
shutdown         ~                         Sun Nov  1 20:01
reboot           ~                         Sun Nov  1 17:10
reboot           ~                         Sun Nov  1 13:51
shutdown         ~                         Sun Nov  1 13:48

wtmp begins Sun Nov  1 05:08:18 PST 2009
albert(7.2-S)[9]

The "solo reboots" are crashes; those paired with "shutdown" entries are
controlled.

> Has anything unusual happened lately?  Brownout, blackout, power surge,
> lightning, heatwave, ...

Nothing linked to the crashes.  I pulled the UPS out of service
some weeks ago because it needs new batteries; I need to get those
ordered.  But the crashes were happening before that, in any case.

> >accordingly, had attached a SCSI host adaptor via PCI riser card.  Since
> >I had nothing actually connected to the card, I pulled it out of the
> >machine before bringing it back up.
>
> Did you also pull the riser card?  Riser cards don't have a spectacularly
> high reputation.

That's actually what I pulled.  The SCSI card itself is still physically
in the chassis, merely with an air gap between itself at the system
board (because the riser card is now in a closet).

> > (I also fleft around for
> >excessively warm spots; nothing.  All fans spin up, as well.)
>
> I don't suppose you also studied the capacitors on the motherboard.
> Are any showing any signs of bulges?

I'll take another look for those; I recall that electrolytics exhibit
that as a sign of failure -- thanks for the reminder.

> Have you tried reseating everything?

The memory, yeah (even before replacing it); also swapped the DIMMs.
Only other thing that can be re-seated (desktop system board, so most
everything is built-in) would be the CPU, and I'm not quite sure how
that heat sink works.  I did re-seat some power connectors.

> >Flaky CPU?  Flaky power supply?  How might I tell?
>
> CPU shouldn't go flaky unless it's been overheated.  In my experience,
> PSUs are the least reliable part of consumer-grade hardware but about
> the only way to check is to swap it.

:-}

> If you've got a DMM, you could check all the rails but there are
> lots of failure modes that won't show up that way.

Yeah, I kinda figured that.  I do have a DMM (used to have a VTVM), but
figured the meter wouldn't show transient dips or whatever too well.

> Have you checked the voltage/temperature screen in the BIOS?  Does
> anything look abnormal?

Did a couple of reality checks in that way as detours during some of the
reboots.  Nothing interesting there at all.  (And I have seen a case in
the past -- though with a 1U box) where that test definitely showed
something wrong (CPU temp climbing about 1C every 30 seconds, IIRC).

> Are you using a PS/2 or USB keyboard?

PS/2 via KVM.  I don't have any USB keyboarda.  :-}

> Are you running X?

Yes; the machine is configured to start xdm on transition to
multi--user, as my spouse used to use it as a desktop.  (She's gone back
to using its predecessor, a 4.11-STABLE machine, in frustration.)

> At this stage, my suggestion would be to try swapping the PSU.

Thanks.  I'll discuss it with the "family CFO."

Peace,
david
--
David H. Wolfskill david@...
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


attachment0 (203 bytes) Download Attachment

Re: 7.2-STABLE i386 box crashing -- clues?

by Peter Jeremy-6 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 2009-Nov-12 04:59:03 -0800, David Wolfskill <david@...> wrote:
>Yes; the machine is configured to start xdm on transition to
>multi--user, as my spouse used to use it as a desktop.

Does the problem still appear if you don't start X?

Is it running anything unusual when it crashes?

>> At this stage, my suggestion would be to try swapping the PSU.
>
>Thanks.  I'll discuss it with the "family CFO."

You can't swap it with another of your systems?  Even if it doesn't
fit neatly into the case, a temporary swap would give you some
confidence as to whether it was really faulty or not (especially if
the random reboots move to the other system).

--
Peter Jeremy


attachment0 (203 bytes) Download Attachment

Re: 7.2-STABLE i386 box crashing -- clues?

by David Wolfskill :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, Nov 17, 2009 at 05:29:24AM +1100, Peter Jeremy wrote:
> ...
> >Yes; the machine is configured to start xdm on transition to
> >multi--user, as my spouse used to use it as a desktop.
>
> Does the problem still appear if you don't start X?

I haven't tried that yet....

> Is it running anything unusual when it crashes?

Not that I can tell, no.  Though I did just notice that the whines about
icmp unreach responses is actually coming from the machine that's
crashing ("albert") vs. the firewall box (which is configured to log
everything to albert).

> >> At this stage, my suggestion would be to try swapping the PSU.
> >
> >Thanks.  I'll discuss it with the "family CFO."
>
> You can't swap it with another of your systems?  Even if it doesn't
> fit neatly into the case, a temporary swap would give you some
> confidence as to whether it was really faulty or not (especially if
> the random reboots move to the other system).

I think it's more a matter of "at all" rather than "neatly." :-}  I tend
to have a variety of hardware, but each machine tends to be from a
different era or have other differences that cause each to be a one-off.

But I'll see what I can find.

In the mean time. tyhe machine crashed this morning after I got in to
work -- but wonder of wonders, it came back up again this time.

And the typescript file that's capturing the serial console activity
showed:

fxp0: link state changed to UP
Limiting icmp unreach response from 234 to 200 packets/sec

FreeBSD/i386 (albert.catwhisker.org) (ttyd0)

login: drm0: <Intel i865G GMCH> on vgapci0
vgapci0: child drm0 requested pci_enable_busmaster
info: [drm] AGP at 0xf0000000 128MB
info: [drm] Initialized i915 1.6.0 20080730
drm0: [ITHREAD]
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
Limiting icmp unreach response from 201 to 200 packets/sec
panic: vm_fault: fault on nofault entry, addr: c3983000
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c0bf0330,e7d168f8,c082cae9,c0c1237c,0,...) at 0xc049e9a6 = db_trace_self_wrapper+0x26
kdb_backtrace(c0c1237c,0,c0c07dfe,e7d16904,0,...) at 0xc085a239 = kdb_backtrace+0x29
panic(c0c07dfe,c3983000,2,e7d169fc,e7d169ec,...) at 0xc082cae9 = panic+0x119
vm_fault(c1471000,c3983000,2,0,e7d16a7c,...) at 0xc0a6ec88 = vm_fault+0x178
trap_pfault(c0d4de20,e7d16ac4,c0b2b675,0,c660cb00,...) at 0xc0b3f60e = trap_pfault+0x20e
trap(e7d16b3c) at 0xc0b400b5 = trap+0x445
calltrap() at 0xc0b22dbb = calltrap+0x6
--- trap 0xc, eip = 0xc0b37648, esp = 0xe7d16b7c, ebp = 0xe7d16b88 ---
pmap_try_insert_pv_entry(c08b14c4,c63c0cf0,c63c0cf0,e7d16bbc,c08b4b17,...) at 0xc0b37648 = pmap_try_insert_pv_entry+0x48
pmap_copy(c6cd2d74,c69dd350,33f7d000,f4000,33f7d000,...) at 0xc0b3c1e8 = pmap_copy+0x2e8
vmspace_fork(c69dd2c4,0,2,e7d16c5c,bfbfc824,...) at 0xc0a7698b = vmspace_fork+0x42b
fork1(c63c3b40,14,0,e7d16c78,0,...) at 0xc08051ee = fork1+0x30e
fork(c63c3b40,e7d16cfc,c,8001550d,369e99,...) at 0xc0806b79 = fork+0x29
syscall(e7d16d38) at 0xc0b3f9c5 = syscall+0x335
Xint0x80_syscall() at 0xc0b22e20 = Xint0x80_syscall+0x20
--- syscall (2, FreeBSD ELF32, fork), eip = 0x340cde4b, esp = 0xbfbfc7cc, ebp = 0xbfbfc858 ---
Uptime: 3d4h1m43s
Physical memory: 2033 MB
Dumping 179 MB: 164 148 132 116 100 84 68 52 36 20 4
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...


Taking a quick look at vmcore.1, I see:

albert(7.2-S)[5] kgdb /boot/kernel/kernel vmcore.1
GNU gdb 6.1.1 [FreeBSD]
...
[above stuff...]
...
#0  doadump () at pcpu.h:196
196     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:196
#1  0xc082c817 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2  0xc082cb22 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:574
#3  0xc0a6ec88 in vm_fault (map=0xc1471000, vaddr=3281530880,
    fault_type=2 '\002', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:277
#4  0xc0b3f60e in trap_pfault (frame=0xe7d16b3c, usermode=0, eva=3281531764)
    at /usr/src/sys/i386/i386/trap.c:852
#5  0xc0b400b5 in trap (frame=0xe7d16b3c) at /usr/src/sys/i386/i386/trap.c:541
#6  0xc0b22dbb in calltrap () at /usr/src/sys/i386/i386/exception.s:166
#7  0xc0b37648 in pmap_try_insert_pv_entry (pmap=0xc6cd2d74, va=872140800,
    m=0xc2be5110) at /usr/src/sys/i386/i386/pmap.c:2229
#8  0xc0b3c1e8 in pmap_copy (dst_pmap=0xc6cd2d74, src_pmap=0xc69dd350,
    dst_addr=871878656, len=999424, src_addr=871878656)
    at /usr/src/sys/i386/i386/pmap.c:3677
#9  0xc0a7698b in vmspace_fork (vm1=0xc69dd2c4)
    at /usr/src/sys/vm/vm_map.c:2552
#10 0xc08051ee in fork1 (td=0xc63c3b40, flags=Variable "flags" is not available.
)
    at /usr/src/sys/kern/kern_fork.c:288
#11 0xc0806b79 in fork (td=0xc63c3b40, uap=0xe7d16cfc)
    at /usr/src/sys/kern/kern_fork.c:107
#12 0xc0b3f9c5 in syscall (frame=0xe7d16d38)
    at /usr/src/sys/i386/i386/trap.c:1101
#13 0xc0b22e20 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262
#14 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)


If there is an issue with the PSU, I'm not sure there's much to be
gained by spending much time on that dump -- I understand that
there's not much information to trust if the PSU is flaky.

Thanks for your help!

Peace,
david
--
David H. Wolfskill david@...
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


attachment0 (203 bytes) Download Attachment