Auke Kok <[EMAIL PROTECTED]> 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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html