In message <[EMAIL PROTECTED]>, Mark Santcroos writes:
>While doing heavy IO (updating my p4 repo) on my laptop I got the following
>panic. (I was running in X so both backtrace and dmesg are from the core
>dump after reboot)
>
>I'm wondering whether the ENOMEM's reported by GEOM point out that GEOM
>has a problem or just tell us that the machine was out of memory and some
>other subsystem failed.
>ENOMEM 0xc3724300 on 0xc2412c80(ad0s1)
The ENOMEM from GEOM is just a notification that an I/O request failed
due to lack of memory.
GEOM reacts to this by rescheduling the I/O request and entering a
rudimentary back-off mode where further I/O requests are paced so
that some of the outstanding ones get a chance to complete. The
current pacing is inspired a little bit by tcp slowstart btw.
>By looking at the stack it seems that the NULL-pointer dereference is
>going down pretty far.
>The arguments in the lstat(frame #28) already seem bogus.
>#10 0xc0381d12 in trap_fatal (frame=0xce5c1700, eva=0) at
>../../../i386/i386/trap.c:844
This is the interesting trap I think, all the stuff above is noise.
>#11 0xc03819f2 in trap_pfault (frame=0xce5c1700, usermode=0, eva=20) at
>../../../i386/i386/trap.c:758
>#12 0xc03814e0 in trap (frame=
> {tf_fs = -832831464, tf_es = -1071710192, tf_ds = -951058416, tf_edi =
>-1037023552, tf_esi = -951046744, tf_ebp = -832825484, tf_isp = -832825556, tf_ebx =
>0, tf_edx = 5, tf_ecx = 0, tf_eax = -1740064768, tf_trapno = 12, tf_err = 2, tf_eip =
>-1071712263, tf_cs = 8, tf_eflags = 66183, tf_esp
>= -951046744, tf_ss = -951046572})
> at ../../../i386/i386/trap.c:445
>#13 0xc0371bf8 in calltrap () at {standard input}:96
>#14 0xc01edc00 in spec_xstrategy (vp=0xc23046c0, bp=0xc7502da8) at
>../../../fs/specfs/spec_vnops.c:596
This doesn't correspond to my sourcefile, but you should examine this one.
>#15 0xc01edc7b in spec_specstrategy (ap=0x0) at ../../../fs/specfs/spec_vnops.c:633
This, I think is impossible, so I think we should assume that something
overwrite some memory and cleared out some bits which should have
survived.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
