kern/46472: 5.1_STABLE/i386 panic after recent pull-ups

[jdbaker%mylinuxisp.com@localhost]

>Number:         46472
>Category:       kern
>Synopsis:       5.1_STABLE/i386 panic after recent pull-ups
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 21 14:00:00 +0000 2012
>Originator:     John D. Baker
>Release:        NetBSD 5.1_STABLE/i386
>Organization:
>Environment:
NetBSD slate.technoskunk.fur 5.1_STABLE NetBSD 5.1_STABLE (SLATE) #38: Sun
May 20 13:15:13 CDT 2012
sysop%slate.technoskunk.fur@localhost:/d0/build/netbsd-5/obj/i386/sys/arch/i386/compil
e/SLATE i386

NetBSD slate.technoskunk.fur 5.1_STABLE NetBSD 5.1_STABLE (GENERIC) #1: Sun May 
20 16:16:30 CDT 2012  
sysop%verthandi.technoskunk.fur@localhost:/d0/build/netbsd-5/obj/i386/sys/arch/i386/compile/GENERIC
 i386

>Description:
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
/var/crash/netbsd.2.c
ore.gz
May 20 16:43:23 slate savecore: writing compressed kernel to
/var/crash/netbsd.2
.gz
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
db{0}> bt
breakpoint(c0775cab,ce971a88,c07d0d00,c3003000,cf088cd4,1,ce971a7c,c04d299c,
c305ff48,c307e82c) at netbsd:breakpoint+0x4
panic(c07640dd,0,0,2,ce971b44,ce971b74,ce971c48,1,ced9b39c,ce971c34) at
netbsd:panic+0x1b0
ufs_rename(ce971bac,cd91b000,ce971bcc,c046196c,c083c1e0,408418,c06c91a0,cd95
3e68,cf087b80,ce971c90) at netbsd:ufs_rename+0x55f
VOP_RENAME(cd953e68,cf087b80,ce971c90,ced9b39c,0,cd971c48,ce971c0c,c046f0aa,
cd91b000,0) at netbsd:VOP_RENAME+0x7c
do_sys_rename(bb903040,bb91a040,0,0,ce84b7e0,c0541274,ce84b7e0,ce971d00) at
netbsd:do_sys_rename+0x59e
sys_rename(ce84b7e0,ce971d00,ce971d28,bb936000,cdaf384c,80,bb903040,bb91a040
,0) at netbsd:sys_rename+0x26
syscall(ce971d48,b3,ab,1f,1f,80517fc,bb91a041,bfbfe6f8,bb91a040,0) at
netbsd:syscall+0xc4
db{0}>


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(?).



>How-To-Repeat:
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
is affected.
>Fix: