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

[Auke Kok <auke-jan.h.kok@intel.com>]

Adam Kropelin wrote:
> Auke Kok wrote:
> > Adam Kropelin wrote:
> > > I've never had this device work 100% with MSI on any kernel version
> > > I've tested so far. But I'm not the original reporter of the
> > > problem, and I believe for him it was a true regression where a
> > > previous kernel wored correctly.
> > maybe I've been unclear, but here's how e1000 detects link changes:
> >
> > 1) by checking every 2 seconds in the watchdog by reading PHY
> > registers
>
> That would explain why I see link status changes but 0 interrupt count 
> in /proc/interrupts. However, on >= 2.6.19 the link state never changes. 
> Ever. It's always down. On <= 2.6.18 the link state does change but with 
> 0 interupt count.
>
> > 2) by receiving an interrupt from the NIC with the LSI bit
> > in the interrupt control register
> >
> > if the link is down to start with, the watchdog will obviously spot a
> > 'link up' change since it doesn't use any interrupts.
>
> This does not seem to work on 2.6.19+. Unless the watchdog interval is 
> tens of minutes. I've waited at least 5 minutes and link never went up.

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.

Cheers,

Auke
-
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/