Re: 2.6.20-rc7: known regressions (v2) (part 1)

[ebiederm@xmission.com (Eric W. Biederman)]

Auke Kok <auke-jan.h.kok@intel.com> writes:

> that's explained by a driver change that did that. Since at initialization we're
> basically waiting for a link change to tell the stack that we're up, we decided
> to change the order to have the hardware fire an LSI interrupt to trigger a
> watchdog run. So no interrupts would immediately explain why the watchdog never
> runs. That's nothing to worry about for this problem, as soon as interrupts are
> seen in /proc/interrupts this all starts working for e1000.


While I think we need to fix this issue, and in general the issue of MSI
interrupts on PCI-Express busses downstream of hypertransport chains.
This e1000 issue is not a regression, so not fixing it for 2.6.20 is
not a big deal.

I have yet to see all of the pieces I'm trying to look at confirmed,
but I believe by at least looking at the hypertransport MSI mapping
capability's enable bit in general we should be able to do a much
better job of detecting if MSI works in a system or not.

I though someone several months ago had made our MSI supported detect logic
a lot smarter, with defaults that were generally correct, but looking
at the kernel that code apparently never made it anywhere.  Instead
all I see are a handful of common chipsets special cased by the quirk logic.

We should be able to do a lot better but not in the 2.6.20 time frame.

As for the original problem report with duplicate MSI interrupts in
/proc/interrupts.  That sounds like a regression and is probably
simple to fix if we can get some more details.

Eric