On Nov  4, 12:43pm, Peter Seebach wrote:
> running
> 	int *foo = 0; *foo = 0;
> gives me
> 68040 access error: pc 270e, code 481, ea dfffd84, fa 0
>  curpcb 1e56000 ->pcb_ustp 51b5 / a36a000
> 
> Is this right?  Seems fishy... ;-)

  Sort of (right).  Page 0 of the kernel in -current is now invalid, and
there is some debug code in trap.c to display information about accesses
to page 0.  The above message is printed out if the kernel was compiled
with DEBUG (and I think if DDB is configured, it will enter the debugger).
At the point the message is being printed, it's not known if the fault is
on an access to kernel address space or user address space.  Easiest fix
is to comment out the code that sets 0x100 in mmudebug (around line 283)
in trap.c.

  I suppose I should remove or comment out part of that code that does
the check for page 0 access.  I had lots of trouble with page 0 references
in the kernel code, particularly when the fault caused another page 0
reference and the system hangs.  I wanted something available so that I
would be able to find out what's happening if someone else starts running
in page 0 accesses when using drivers or configurations that I don't have.

Michael