der Mouse wrote
> 
> I've got a machine with a 486DLC in it.  Seems to be working fine,
> except, EXCEPT...I'm trying to do a build-from-source.  After a few
> hours, it drops into ddb.  Here's the latest example:
> 
> uvm_fault(0xf2699008, 0x0, 0, 1) -> 1
> kernel: page fault trap, code=0
> Stopped in cpp at       _sys_dup2+0x37: xorl    %esp,0x34(%edi)
> db> 
> 
> The thing is, I have ddb.onpanic set to 0 (set every time, in the rc
> scripts) specifically because I don't want to have to go to this
> machine's console all the time when it dies!
> 
> What's the matter here?  Based on a quick look at the code, this
> appears to be some failure mode proceeding from an ordinary page fault.
> What's not clear is why this page fault failed when most page faults
> work fine.  It appears to be for address zero, but if dereferencing
> address zero were all it took to produce this, it would have been
> caught long since.
> 
> I could simply comment out the kdb_trap() call in the we_re_toast: code
> in trap.c (and then deal manually with the two or so crashes it will
> take to build a new kernel).  But that is presumably there for a
> reason...so I ask, what is that reason?

G'day,

I've had similar experiences after I recompiled a new kernel which
had options VM86 and USER_LDT enabled. The system paniced repeatendly
with the new kernel with the following message:

uvm_fault(0x2f2eda160,0x001) ->1
kernel: page fault trap, code=0
stopped in cron at _cache_lookup 0xe3 movl 0x20(%ecx),%eax

I've since reverted back to my old kernel and live is back to
normal again ;)

I am still not sure whether this was a coincident, a hardware or
kernel problem. As mentioned in my previous email, I am going to
investigate it further next weekend, but sought that it may
be of interest to this list to context to this report.

cheerio Berndt