Date: Wed, 11 Jun 2014 19:55:04 +0200 From: "O. Hartmann" <ohartman@zedat.fu-berlin.de> To: FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Panic String: ffs_alloccg: map corrupted [/dev/gpt/tmp] Message-ID: <20140611195504.3d03de36.ohartman@zedat.fu-berlin.de>
next in thread | raw e-mail | index | archive | help
--Sig_/sT/d/JpS+8LMMfR4Iri1.qm
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Running FreeBSD
Version String: FreeBSD 11.0-CURRENT #3 r267294: Mon Jun 9 22:07:15 CEST 2=
014 amd64
crashes wihout panic message and /var/crash/info.0 contains this message:
Dump header from device /dev/gpt/swap
Architecture: amd64
Architecture Version: 2
Dump Length: 968962048B (924 MB)
Blocksize: 512
Dumptime: Wed Jun 11 19:19:19 2014
Hostname: thor.sb211.zbv
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 11.0-CURRENT #3 r267294: Mon Jun 9 22:07:15 CEST=
2014
root@thor.sb211.zbv:/usr/obj/usr/src/sys/THOR
Panic String: ffs_alloccg: map corrupted
Dump Parity: 3034136388
Bounds: 0
Dump Status: good
I'm very confused about the panic string, since it seems to tell me somethi=
ng is bad with
FFS/UFS.
More disturbing is the fact that the boot process into multi user stops at =
a compalin
about unclean /dev/gpt/tmp filesystem (mount to /tmp): The OS stops at the =
PAsswd: prompt
for single user-mode maintainance.
I can not understand why the system is stopping complaining about a broken =
/tmp
filesystem. I consider especially /tmp infill corrupt after a fault and I'd=
like to ask
whether there is a way to overrun this corruption and force a repair and mo=
unt, even if
the data contained in /tmp is after forced cleaning corrupt.
When using tmpfs backed /tmp there shouldn't be any stopp/fault of that kin=
d so it would
be canonical to have it also for a hard-drive backed /tmp, or am I wrong?
It is not the first time that I receive this kind of crash under heavy load=
(box is a
8GB system with this CPU specs: =20
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final
208032) 20140512 CPU: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz (2999=
.72-MHz
K8-class CPU) Origin=3D"GenuineIntel" Id=3D0x10676 Family=3D0x6 Model=3D=
0x17 Stepping=3D6
Features=3D0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG=
E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Features2=3D0x8e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTP=
R,PDCM,SSE4.1>
AMD Features=3D0x20100800<SYSCALL,NX,LM>
AMD Features2=3D0x1<LAHF>
TSC: P-state invariant, performance statistics
real memory =3D 8589934592 (8192 MB)
avail memory =3D 8278880256 (7895 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <A_M_I_ OEMAPIC >
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
[...]
The not-so-funny-part is that I have those crashes under heavy load very fr=
equent on ALL
C2D systems (one E8400 as shown, another has a Q4400 CPU, but also 8 GB RAM=
, same
motherboard). In all cases of a sudden crash, /tmp gets corrupted and the s=
ystem refuses
to boot into multiuser mode complaining about the broken /tmp filesystem wh=
ich can not be
repaired automatically.
Apart from this specific question about an unclean /tmp, this kind of crash=
under heavy
load on a specific hardware architecture with most recent CURRENT is puzzli=
ng (and
occured within the past 8 weeks several times with the same stupid blocking=
at the
broken /tmp partition). I also checked the hardware with tools like memtest=
86 ensure
having no fault memory, but I can not exclude some kind of overheating the =
CPU since I
realized with CLANG and -O3 (which is supposed to optimise for vector units=
if available,
if I'm right) this increases the average CPU temperature by ~ 3 - 5 degree =
Celsius. This
is more obvious on a Dell Latitude E6510 with a first-generation Sandy Brid=
ge mobile CPU
and FreeBSD 9.2/9.3: compiling the OS with gcc 4.2 (base compiler in that s=
ystem), the
temperature is 2 - 4 degrees lower than using CLANG 3.4.1 with -O3 enabled =
(reading the
ACPI reported temperature via "systctl -a|grep tempe"). This is funny, isn'=
t it?
Regards and thanks in advance,=20
Oliver=20
--Sig_/sT/d/JpS+8LMMfR4Iri1.qm
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJTmJf8AAoJEOgBcD7A/5N8Ew4IALqzQzq/0gEP6dgG4Mh3hOed
B3oq5i/29q12OXk2CS/l1EKKMW6e7zvxw8cKZGbHCPxUvb9rI1VB1Sj3gNy/c/qS
X3atNekbuFLMza+MBOW5lGjxADlepzGTn73cxLQ97LBYYuI1Evaqyz3gjD1mHrKN
+TlAE8iXXPTMktDSzB4ikXSHnvdDHIzJI0oE7QLAxIoX6DX2sxCPBOOHfDhSvJZN
Xb5RDRk8W90UE0pwnf7KB8hQzgOoG47akrQfsiPnrBB9bGdzteFIThYo8wDo0/WS
jkWuvVye1nlTw7elzNGIdWyyUvbgLSfaL6e6s9Qe237Ah84jnZDWFDfJ7qKPeZA=
=uFC3
-----END PGP SIGNATURE-----
--Sig_/sT/d/JpS+8LMMfR4Iri1.qm--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140611195504.3d03de36.ohartman>