console on POWER4 not working with 2.6.15

Milton Miller miltonm at bga.com
Thu Dec 22 07:21:08 EST 2005


On Thu Dec 22 04:56:28 EST 2005, Olaf Hering wrote:

> I finally managed to find the culprit.
>
> good: 25635c71e44111a6bd48f342e144e2fc02d0a314
> bad:  f9bd170a87948a9e077149b70fb192c563770fdf
>
> ...
> powerpc: Merge i8259.c into arch/powerpc/sysdev
>
> This changes the parameters for i8259_init so that it takes two
> parameters: a physical address for generating an interrupt
> acknowledge cycle, and an interrupt number offset.  i8259_init
> now sets the irq_desc[] for its interrupts; all the callers
> were doing this, and that code is gone now.  This also defines
> a CONFIG_PPC_I8259 symbol to select i8259.o for inclusion, and
> makes the platforms that need it select that symbol.
...

>  PCI: Probing PCI hardware
> +Failed to request PCI IO region on PCI domain 0000

That caught my eye.

It turns out that xics calls the 8259 init at arch_initcall before the 
pci has probed the first bus.   The ppc64 version did not request the 
resources it was using, but the combined version picked this up from 
the ppc side.

If we defer the 8259 init to subsys_initcall, or even look for it after 
we setup the first io resource from the pci code, it may solve this 
problem.


I noticed the commit did not touch xics.c.  Looking further I see that 
the move of the 8259 irq_desc setup code into i8259_init undoes the 
combined xics_8259_pic descriptors.

Perhaps this should be made more like the mpic code?
Just detect the cascade, call the cascaded irq controller, eoi, and 
return?
 From there I think xics_mask_and_ack can disappear or become empty.

Also, is there a reason we are not looking for a intack pci bridge 
property?

Ok enough for someone on vacation.

milton




More information about the Linuxppc64-dev mailing list