>Number:         23581
>Category:       port-arm
>Synopsis:       Random kernel crashes on ARM
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-arm-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Nov 27 10:41:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Richard Earnshaw
>Release:        NetBSD 1.6ZF
>Organization:
ARM Ltd
-- 
>Environment:
	
	
System: NetBSD shark1.cambridge.arm.com 1.6ZF NetBSD 1.6ZF (SHARK1) #0: Thu Nov 20 15:01:59 GMT 2003 rearnsha@pc960.cambridge.arm.com:/work/rearnsha/netbsd/build/src/shark/sys/arch/shark/compile/SHARK1 shark
Architecture: arm
Machine: shark
>Description:

	Recent ARM kernels are showing random instability.  My suspicsion
	is that something, somewhere, is trampling on data structures.

	Examples include:

	1)
	Kernel alignment fault 3 (TF: f55cedf8, PC: f0108e68, FSR: 0x85d9003
		FAR: 0x65756e69)

	at netbsd:uvm_uarea_alloc ldr r2, [r4] ; r4=0x65756e69
	from	fork
		sys_fork
		syscall_plain
		swi_handler

	in process sh

	2)
	panic: assertion failure: umap->refcount != 0

	from: ubc_fault
		uvm_fault
		data_abort_handler
		uio_move
		ffs_write
		VOP_WRITE
		vn_write
		dofile_write
		sys_write
		syscall_plain
		swi_handler

	Process was "expect" the gcc testsuite driver program.  Same panic 
	also seen from sh.

	3)
	Also seen while running expect:

	parent: sync byte write: bad address in system call argument
	gnumake[1]: [check-gcc] Error 255 (ignored)

	I've seen this on both cats and a shark.

	4)
	And on my cats machine only (kernel of similar vintage to above):
	
	xemacs sees mmap return EINVAL for a perfectly reasonable set of
	arguments for mapping /dev/zero.

	This final problem is repeatable.
	
>How-To-Repeat:
	Just run some kernel-intensive applications (the gcc testsuite seems 
	to be a good example).
	
>Fix:
	No idea.
	
>Release-Note:
>Audit-Trail:
>Unformatted: