>Synopsis: 5.1_STABLE/i386 panic after recent pull-ups
>Arrival-Date: Mon May 21 14:00:00 +0000 2012
>Originator: John D. Baker
>Release: NetBSD 5.1_STABLE/i386
NetBSD slate.technoskunk.fur 5.1_STABLE NetBSD 5.1_STABLE (SLATE) #38: Sun
May 20 13:15:13 CDT 2012
NetBSD slate.technoskunk.fur 5.1_STABLE NetBSD 5.1_STABLE (GENERIC) #1: Sun May 20 16:16:30 CDT 2012 sysop@...:/d0/build/netbsd-5/obj/i386/sys/arch/i386/compile/GENERIC i386
Following the recent pull-ups to the netbsd-5 branch, I updated my tree
and rebuilt. Since then, I've experienced panics logged on reboot as:
May 20 16:43:05 slate savecore: reboot after panic: panic: rename: EXDEV
May 20 16:43:05 slate savecore: writing compressed core to
May 20 16:43:23 slate savecore: writing compressed kernel to
May 20 16:43:23 slate savecore: (null): Bad address
The resulting compressed kernel file is only 10 bytes. Attempting to
run 'gdb' on the core file with "/netbsd" as the kernel causes 'gdb' to
declare the core file to be an unrecognized format, not core file.
Thinkpad T42 1.7GHz, 2GB.
I'll set ddb.onpanic=1 to see if I can get more data. As it was, the
machine just froze for a few seconds and then rebooted.
=> Applying pkgsrc patches for openmotif-2.3.3nb1
panic: rename: EXDEV
fatal breakpoint trap in supervisor mode
trap type 1 code eip c053836c cs 8 eflags 246 cr2 ccdab000 ilevel 0
Stopped in pid 3922.1 (patch) at netbsd:breakpoint+0x4: popl %ebp
c305ff48,c307e82c) at netbsd:breakpoint+0x4
3e68,cf087b80,ce971c90) at netbsd:ufs_rename+0x55f
cd91b000,0) at netbsd:VOP_RENAME+0x7c
,0) at netbsd:sys_rename+0x26
I should note this is a custom kernel in which I enable options FFS_EI
options APPLE_UFS. Will try again with a GENERIC kernel.
Same result with GENERIC. same backtrace with just some variations in
a couple of the offsets from start of functions.
It seems to be something 'patch' is doing. 'mv' works as expected, but
if I make two files "foo" and "bar", save the output of
'diff -u bar foo >foo.diff' and then run 'patch < foo.diff', the machine
panics. Upon reboot, the "foo.diff" file is corrupted with what appears
to be text/data segment of library(?).
Unknown. I have three machines running 5.1 stable. Two have been updated
with the latest pullups. One panics on rename via 'patch' as described
above. The other displays no problems. Both are self-hosted. I brought
in the kernel and release sets from the unaffected machine to install on
the problem machine in case it was an issue with my build environment.
The result is the same.
I blew away the build directories on the problem machine to see about
rebuilding from top to bottom, but it froze/panicked when the first
"./configure" script got around to running its first "config.status"
script. No doubt it employed "patch" to do some of its work. I still
have "ddb.onpanic=1" so have no core-dump from the most recent events.
I am working on updating the third machine to see if any other machine