On Tue, Aug 21, 2012 at 02:50:28PM +0200, Adam Pribyl wrote: > On Mon, 20 Aug 2012, Josh Boyer wrote: > > >On Mon, Aug 20, 2012 at 12:25:21PM +0200, Adam Pribyl wrote: > >>It looks like this patch is not working, or at least not doing any > >>good on some platforms. This is Fedora specific right? Would it be > >>possible to remove it or either make it more specific to the cases > >>when it really helps? > > > >It can't get much more specific. The bridge itself is flaky and doesn't > >handle interrupts properly all of the time. About the only thing we > >could do to limit scope even more is to only enable the quirk if there > >is a device actually behind the bridge. That will help people that have > >the broken hardware, but aren't really using it. Most people have > >something behind the bridge though. > > > >There are two alternatives here. Drop the patch entirely, or come up > >with a boot parameter that can be passed to disable it. If we drop it > >and old method of IRQs is used, it will basically disable the interrupt > > That's the thing I do not understand. As stated in the bug, there > are boards, where there are no problem with this bridge, or at least > no obvious problems. IRQs are comming, data flowing. No "nobody > cares, Disabling, Polling, Reenabling IRQ" with latest kernels. Right. It's not a set in stone issue. We can't predict when the hardware is going to basically ignore the interrupt clearing. The people having the most issues seem to have setups where multiple devices are sharing the same IRQ. > I've read there is no documentation, nor any statement from ASM for > this issue, maybe this is a misswiring by some vendors, or there are > new silicon revisions on different baords. ASM actually did make a statement. Their statement was "we don't support Linux." If vendors are wiring things incorrectly or newer ASM bridge revisions are being shipped without revving the hardware ID, it still adds up to the same problem, which is broken hardware or the inability to detect broken hardware. > >permanently for that boot. That might sound OK, but if the IRQ is > >shared it can make people's computer useless until it's rebooted. The > >boot parameter could be helpful, but people would have to know about it > >before they can pass it in. > > > >Opinions on which to use? To be honest, I'm leaning more and more > >towards dropping it entirely. > > I'd vote for that too, but I'm not the one having problems fixed by > this patch. I'll set a tentative date for end of next week for a decision. There will be a massive gathering of kernel developers and maybe we can have some kind of small pow-wow about it. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
