> This bad access, I would thing should cause a mem fault or seg fault
> but instead hangs the system!

Access hardware in the wrong way, and you lose.  that's not too
surprising.  8-)


> What is the correct thing todo to crash (ie panic() netbsd is a pci
> access is not on a board?

The only way to do that is to bounds-check every single access.  I'd
say that's a good thing to support (via a kernel compile-time option),
but in general, that shouldn't be the default mode of operation.
I've tried to get people to write code like that in the past, but
have never had time enough (and concern enough) to do it myself.

If you access device space in the wrong way, who knows what the
hardware will do.  It's not reasonable to expect that the OS will
catch your programming errors.  If it can, great.  But if it doesn't,
well, code more carefully.  8-)


> PS Isn't this the same idea as a pci configuration read getting a master
>    abort?

No.  In the case of a PCI configuration read that gets a master abort:

(1) that's a situation that, in some circumstances is expected and
unavoidable (e.g. during probing).  That has to be handled specially.

(2) Master aborts and similar errors are reported in a relatively
well-defined way to the operating system.  Who knows what action your
bogus access was causing the hardware to take.  (Indeed, it may have
simply locked up the bus, in hardware!)


cgd