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.
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.
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.
josh
Adam Pribyl
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
