On Tue, Jan 13, 2009 at 6:00 AM, Matt Sealey <m...@genesi-usa.com> wrote: > Grant Likely wrote: >> >> >> Theoretically it could call IRQ handlers to be called too often. It >> might possibly be the cause of too many 'BAD' irqs being recorded.... > > That might explain a few USB explosions, where high bandwidth transfers > (restoring partimage disks) would make the host controller die (a freeze, > then it comes back with 'nobody cared about irq 134' etc.) and perhaps a > lockup we saw with openSUSE 11.0 installer.. > >> Now that I think of it, I should probably also change all the internal >> IRQs to be LEVEL instead of EDGE. > > And what does that really affect? I wouldn't think the internal stuff would > make any difference what it senses on?
It took me most of the morning, but I traced through all the code and figured out how it is supposed to work. In this case the type field in status is indeed cosmetic. The only time I can see that it really comes into play is when edge IRQs are enabled after being disabled for replaying IRQs. It might be the source of some of the BAD irq count on the mpc5200, but it is unlikely. The real logic behind handling an IRQ is defined by the handler registered with set_irq_chip_and_handler() which the current mpc5200 PIC driver seems to be doing correctly. However, for external IRQs, the handler is not changed when the IRQ switches from the default edge sensitivity to level sensitivity. Using the wrong handler doesn't seem to actively break things, but I'm still investigating to find out if it affects performance or results in BAD irq counts. Regardless, I'm looking at a number of cleanups to the PIC code and I'll be posting a patch soon with the intent of getting it into .30. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
