Re: powerpc/pic/intr.c IPL_HIGH vs IPL_NONE

[Frank Wille <frank%phoenix.owl.de@localhost>]

KIYOHARA Takashi wrote:

> The hangup reason is changing imask[IPL_HIGH] to 0x3ffe0000 from
> 0x7ffe0000.

Which means it was 0x7ffe0000 before, and now it is 0x3ffe0000?

Can you compile the kernel with PIC_DEBUG, to get some more information
about the irqs, virqs and masks in your system?


> The bit30 indicate establish PIC I8259 with IPL_NONE on
> bebox.

As far as I understand the BeBox has a custom PIC, which can handle 32
interrupt sources. And it has a i8259 (16 sources) hooked up via Be-PIC
interrupt 26. But still the Be-PIC is the primary interrupt controller,
which handles the external PPC hardware interrupts.


> intr_establish(16 + 26, IST_LEVEL, IPL_NONE, pic_handle_intr, isa_pic);
> [...]
> intr_establish() sets IPL_HIGH to is->is_ipl in powerpc/pic/intr.c.
> However it sets IPL_NONE to ih->ih_ipl.

Ok, that's true. But this should have been the same before.


> sys/arch/powerpc/pic/intr.c:intr_establish() ---
> [...]
>         if (maxipl == IPL_NONE)
>                 maxipl = IPL_HIGH;

I have to admit that it's not clear to me why this is done.


> Shall we call intr_establish() with IPL_HIGH?

This is not a good idea. It would mean that all i8259 interrupts would be
handled at IPL_HIGH.

A cascaded PIC is always hooked to the parent PIC with intr_establish() and
an IPL_NONE. I guess this is because the 8259's pic_handle_intr() will then
raise the IPL to the priority of the real 8259 irq.

I'm not sure yet, what is wrong here. Do you have detailed information where
it hangs or crashes during boot?


> Also I think, this problem happen on sandpoint(ENCPP1, SANDPOINT).

When you are right, then it might happen with all cascaded PIC
configurations. Also ofppc (Openpic+8259) or macppc (Ohare).


> In the first place, I don't understand this commit log by macallon@.
> [...]
>   when calculating per-IPL virq masks, take into account that shared
>   IRQs may request different IPLs.
>   fixes vr(4)-related problems seen on ofppc
>
>
> The is->is_ipl is always set maxipl for shared IRQs.  What problem is
> this? 

The is_ipl must be the maximum IPL in use from all handlers, which are
assigned to a specific irq.

On the Pegasos2 we had a problem with USB interrupts (IPL_SCHED) and vr(4)
interrupts (IPL_VM), which both share irq 9.

Macallan's fix is correct, but maybe it disclosed another bug, which we have
to fix now...

-- 
Frank Wille