svn commit: r215132 - head/sys/dev/nfe

[Pyun YongHyeon]

On Thu, Nov 11, 2010 at 01:34:34PM -0800, Rob Farmer wrote:
> On Thu, Nov 11, 2010 at 13:18, Pyun YongHyeon <pyunyh at gmail.com> wrote:
> > Yes, but I think this has nothing to do with the subject.
> > I think MCP controllers have a silicon bug that does not generate
> > TX completion interrupts under certain conditions/controller models.
> > The PR indicates what was really happened which also indicates
> > possible silicon bug. nve(4) also seems to have some workaround for
> > that but I wanted to verify it since we don't know what binary blob
> > did during controller initialization. The message just shows
> > informational message and does not reset controller so I think that
> > edge case is already handled by nfe(4).
> >
> 
> I have a system that does this same thing - watchdog timeout (missed
> Tx interrupts) over and over. It also generates so much bogus traffic

As I said, the message is informational one so you can ignore it.
nve(4) just does not show any message for that case.

> that all other systems connected to the same switch/hub lose their
> network connection while the machine is running. Switching to nve
> resolves the problem.
> 

I believe you're the first one that reported real issue. Could you
give me more details about bogus traffic? I don't know what PHY
was used with the controller but e1000phy(4) may have advertised
flow-control so the bogus traffic could be a kind of flow-control
storm triggered nfe(4)/e1000phy(4). Maybe opening a PR with
dmesg/pciconf output would be better.

> If it can't be fixed, that's fine. Just please don't remove nve -
> there are systems that need it.
> 
> -- 
> Rob Farmer