On Thu, Nov 11, 2010 at 01:34:34PM -0800, Rob Farmer wrote: > On Thu, Nov 11, 2010 at 13:18, Pyun YongHyeon <pyu...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
