On Fri, Aug 29, 2003 at 12:31:40AM -0400, Rafal Boni wrote:
> In message <200308280555.h7S5tdwa000400@fearless-vampire-killer.waterside.net>,
>  you write: 
> 
> -> [...Following up to my own message; this looks like it may be sparc64-
> ->  specific, but it may also be related to RAIDFrame, so I'm sending it
> ->  on to tech-kern as welll...]
> 
> And again following up, this time removing tech-kern, as it does look
> like a sparc64 (or U5-related) issue; with some help from Eduardo, I've
> done some more digging, and while I'm not quite sure why the pciide code
> would be touching that particular address in PCI I/O space, I did find
> some interesting bits.
> 
> First, it does look like the faulting address is part of the DMA reg-
> isters on the Promise card -- in fact, it looks like offset 0x18 in 
> the I/O space mapped by the "DMA registers" BAR at 0x20.
> 
> However, it doesn't look like anything should be accessing that offset
> in the DMA register space *unless* there's some bug that causes one of
> the channel pointers to become negative, there's some write-combining
> issue, or both... Consider me stumped (I still don't know much about
> the sparc64 CPUs nor their memory access model(s)).

This is the point where things get difficult:  you need to disassemble
the code in the vicinity of the fault and attempt to correlate that with
the source code in the driver.  Probably the easiest way to do this
is to use `objdump -dlS' on the kernel to get a disassembly listing
and try to match that up with the output of ddb's `x/i' command.

(Sun used to have a really good book on core file analysis called
_Panic!_.)

Eduardo