Re: Hunting the ahc boot-time panic

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Tue, 18 Oct 2011 23:00:53 -0500 (CDT)
"John D. Baker" <jdbaker%mylinuxisp.com@localhost> wrote:

> ahc0: bus info: csr 0x2900016
...
> From the look of my added printf() to show the value of "csr", it looks
> like memory access, bus-master and MWI cycles are enabled for "ahc"
> already.

I'd suggest sprinkling printf()s around in order to narrow down where exactly 
we crash. What I usually do there is pasting something like this:
printf("%s: %d\n", __func__, __LINE__);
all over the place and see which one is the last that makes it to the console 
before panic.
Looks like the driver will prefer IO over mmio if available, so things worth 
checking might be:
- is AHC_ALLOW_MEMIO defined?
- does ioh_valid contain something non-zero?
- I don't know if all ahcs have IO BARs, if yours has one, does it contain 
something sane?
- look at arch/macppc/pci/pci_machdep.c, fixpci() - it should enable IO and 
memory access for devices if configured by OpenFirmware.
So, what I think happens is this:
- OF only configures MMIO access, leaves NULL in the IO BAR
- fixpci() only enables memory access since there is no OF property for IO 
access
- ahc_pci_attach() tries to use IO since NULL is technically valid and we crash 
because IO access is not enabled.
So, maybe ahc should ignore IO BARs that contain NULL? Or prefer MMIO whenever 
available?
An easy test would be to always set ioh_valid to 0 and see if things work with 
that.

have fun
Michael