Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: 2.6.20-rc7: known regressions (v2) (part 1) | Date | Sat, 03 Feb 2007 15:24:03 -0700 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |