On Fri, 5 Oct 2007, Giuseppe Sacco wrote:
> After removing the chkslot() call, I get these errors when booting:
> [...]
> SCSI subsystem initialized
> MACEPCI: Master abort at 0x00000000 (C)
> MACEPCI: Master abort at 0x00008000 (C)
> MACEPCI: Master abort at 0x00010000 (C)
[...]
Well, these are not errors in this context even though they seem to be
reported as such -- these Master Aborts are expected to happen for non
occupied slots (device numbers). And reporting them to the user in this
context seems silly (unless debugging).
I can see the are coming from the MACE error interrupt handler -- either
the Master-Abort interrupt should be masked for the duration of the
configuration space access or, if impossible or the way to do so is
unknown, the handler should recognise the context and silently ack the
interrupt and pass the error up somehow. It is up to code handling the
host bridge in question to get it right -- see
arch/mips/pci/ops-bonito64.c for an example.
> PCI: Bridge: 0000:00:03.0
> IO window: 1000-1fff
> MEM window: 80000000-800fffff
> PREFETCH window: 80100000-801fffff
> PCI: Enabling device 0000:00:03.0 (0000 -> 0003)
> [...]
>
> It seems all probes to devfn=0 fails. There is even a call on bus=2,
> that I really don't understand. the current lspci output is:
Well, perhaps the initial setup of the PCI-to-PCI bridge reports the
subordinate bus to be 2 or something. If you post the whole PCI probe
log, someone may be able to provide an explanation.
And devfn=0 failing probably means the host bridge does not want to
report itself in the PCI configuration space; that is a valid approach
(seen with the Alphas too, for example), although personally I do not like
it very much.
> So probably, the test was correct. Should I restore the same check or
> only check for devfn==0?
The handling of Master Aborts should be fixed instead. It looks like
MACEPCI_CONTROL_MAR_INT might be the right mask bit -- do we have a spec
for the chip anywhere or is <asm-mips/ip32/mace.h> the only source?
Maciej
|