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
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
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
>permanently for that boot. That might sound OK, but if the IRQ
>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
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.