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
