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: