Subject: port-i386/1416: vm-related panics when using caches on Pentium
To: None <gnats-bugs@gnats.netbsd.org>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: netbsd-bugs
Date: 08/28/1995 19:18:40
>Number:         1416
>Category:       port-i386
>Synopsis:       vm-related panics when using caches on Pentium
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 28 22:20:03 1995
>Last-Modified:
>Originator:     Jason Thorpe
>Organization:
Numerical Aerodynamic Simulation Project - NASA Ames
>Release:        -current, Aug 22 1995
>Environment:
	
System: NetBSD sticky 1.0A NetBSD 1.0A (STICKY) #1: Mon Aug 28 18:15:31 PDT 1995 thorpej@antie:/work/netbsd/src/sys/arch/i386/compile/STICKY i386


>Description:
	When using the internal and external caches on a Pentium
	system (ASUS mainboard), I let the system run for a while and
	get vm-related panics.  I managed to get a stack trace of one of
	them:

	vmfault(f8275000, fc840000, 1, 0) -> 1
	kernel: page fault trap, code=0
	stopped at	_vm_object_copy: cmpl $0,0x28 (%ebx)

	_vm_object_copy()
	_vm_map_copy_entry()
	_vmspace_fork()
	_vm_fork()
	_fork1()
	_fork()
	_syscall()

	syscall #2

>How-To-Repeat:
	See above.  It's worth noting that running with the internal
	cache only produces "Data modified on free list" messages
	before the system wedges.

>Fix:
	Zero clue.  One thing's for sure, disabling all of the cache
	is _not_ the Right Thing.  It's ... slow.
>Audit-Trail:
>Unformatted: