Hello. That message usually means the device isn't responding in a
timely manner, and the driver is resetting it. On the wm(4) cards, I
usually see it when the card has lost connectivity with the network
it's
attached to, and when the machine is trying to transmit packets.
Since
it's a fiber card, you might check to make sure autonegotiation is
working
fine, or just nail it up at 1000-baseSX. I submitted a number of
patches
to make the nailing part work some years ago, and I believe those
patches
are now a standard part of the driver.
On Mar 2, 5:13pm, SAITOH Masanobu wrote:
} Subject: Re: wm(4) issue/question
}
} Hello, Chris.
}
} From: Chris Ross <cross+netbsd%distal.com@localhost>
} Subject: wm(4) issue/question
} Date: Sun, 28 Feb 2010 15:06:36 -0500
}
} >
} > First of all, I want to point out that I don't presume this is
} > necessarily related to the wm(4) driver. But, it does involve
one,
} > and I have an issue I don't understand. I'm hoping someone
closer to
} > the wm sources might be able to assist me.
} >
} > I have an i386 router with a fiber Intel GigE card ("Intel
i82543GC
} > 1000BASE-X Ethernet, rev. 2"). This is connected to a SX GBIC
on a
} > switch, and I'm running numerous 802.1q VLANs across it. This
is all
} > working fine.
}
} I have a card which has the same chip.
}
}
} > I am trying to replace the 10/100 switches (with Gigabit GBIC
ports)
} > with full gigabit switches. I have a Dell 2724 with SX SFP's
in it,
} > and I tried connecting the i386 with wm(4) to one of them last
night,
} > after trunking that new switch into the existing fabric.
} >
} > I was getting 80% or more packet loss between my desktop and the
}
} Strange.
}
} > router (via one of it's many VLAN interfaces). I was,
throughout this
} > attempt, seeing the following type message on the console of the
} > router:
}
}
} What NetBSD version are you running? Could you give me the full
dmesg
} and ifconfig wm0 of your system?
}
}
} > wm0: device timeout (txfree 255 txsfree 63 txnext 6)
} > wm0: symbol error
} > wm0: device timeout (txfree 252 txsfree 62 txnext 64)
} > wm0: device timeout (txfree 252 txsfree 62 txnext 27)
} > wm0: device timeout (txfree 227 txsfree 41 txnext 121)
} > wm0: device timeout (txfree 249 txsfree 59 txnext 28)
} > wm0: device timeout (txfree 252 txsfree 62 txnext 10)
} > wm0: device timeout (txfree 255 txsfree 63 txnext 179)
} >
} > So, my first question is, does anyone more familiar with the
wm(4)
} > driver have any sense what that message means, and what else I
should
} > look at/into to figure out what sort of problem this is?
} >
} > Note, that I didn't try to pull everything into the new
infrastructure
} > cold, so things like ARP caches and such may still be involved
in the
} > issue(s). But, this doesn't look like that sort of problem to
me.
} >
} > Thanks for any pointers or ideas anyone has...
} >
} > - Chris
}
} I'll try to reproduce the bug.
}
} PR#40981 is a bug that device timeouts occur, but I suspect that
it's a
} different bug.
}
} http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=40981
}
} ----------------------------------------------------------
} SAITOH Masanobu (masanobu%iij.ad.jp@localhost
} msaitoh%netbsd.org@localhost)
-- End of excerpt from SAITOH Masanobu