Marvell chipsets on 8-CURRENT and XP x64 won't talk with one
pyunyh at gmail.com
Wed Nov 7 02:33:00 PST 2007
On Wed, Nov 07, 2007 at 12:14:03AM -0800, Garrett Cooper wrote:
> Pyun YongHyeon wrote:
> >On Mon, Nov 05, 2007 at 03:12:34PM -0800, Garrett Cooper wrote:
> > > Garrett Cooper wrote:
> > > >On Oct 31, 2007, at 9:50 AM, Garrett Cooper wrote:
> > > >>I'm running tcpdump on my Mac and I noted a lot of 'bad checksums'
> > > >>(0x081c was the official error in all cases), then consulted the msk
> > > >>driver. It appears that there's a bug with Yukon II chipsets with the
> > > >>hardware checksumming and I wonder whether or not the chipset that I
> > > >>have is affected by this issue as well.
> > > >>I'll provide my chipset/model info in my next reply (can't access it
> > > >>from this PC).
> > > >>-Garrett
> > > >
> > > >Got a wee bit busy there.
> > > >
> > > >Anyhow, here's the chipset info (snippet) reported from dmesg:
> > > >
> > > >[gcooper at shiina: ~]$ ssh -C optimus "dmesg | grep msk"
> > > >Password:
> > > >mskc0: <Marvell Yukon 88E8056 Gigabit Ethernet> port 0xd800-0xd8ff mem
> > > >0xfe9fc000-0xfe9fffff irq 17 at device 0.0 on pci2
> > > >msk0: <Marvell Technology Group Ltd. Yukon EC Ultra Id 0xb4 Rev 0x02>
> > > >on mskc0
> > > >msk0: Ethernet address: 00:1b:fc:45:9b:5c
> > > >miibus0: <MII bus> on msk0
> > > >
> > > >-Garrett
> > >
> > > The issue indeed is with the msk(4) driver in FreeBSD.
> > > I just plugged in an em(4) compatible card, powered it up and now my
> > > server works like a champ with the XP machine.
> >I'm confused. As I said in previous mail please check network cables
> >such that down-shifting wouldn't take part in this issue. If that
> >does not fix the issue, force speed/duplex on both ends.
> Which I made sure of. Enforcing duplexing from the FreeBSD (and I assume
> Windows?) end worked successfully. So, unless something's doing a really
> shoddy job of detecting the media type for a number of different cables,
> I don't think that .
If you use forced speed/duplex settings, both FreeBSD and Windows
*should* use the same speed/duplex. Failing that will result in
speed/duplex mismatches which in turn creates lots of unexpected
results(poor performance, packet loss, watchdog timeout etc).
Requiring forced speed/duplex normally means a bug in PHY driver.
Since I still don't know what PHY model/revision was attached to
msk(4) I'm not sure about that.
> > > As a reference the MB's affected by this are mostly the ASUS MB's, i.e.
> > > P5B and P5K series ones. MSI MB's may be affected by this issue as well
> > > because I think they come with msk(4) compatible chipsets onboard..
> >Bad checksum seems to be different issue to me. Capture traffic on
> >Mac with tcpdump and give me a URL for the pcap file.
> >Btw, it would be even better if you can show me the PHY driver
> >(e1000phy(4)) information in dmesg output.
> Will do once I get my gigabit switch back from Netgear (bloody port
> routing controller card on the switch died after transferring a few GB
> of data, sadly enough :(...). I assume the e1000phy patch is already in
> 8-CURRENT? What exactly does output from e1000phy(4) output look like
Sorry, I don't know what e1000phy patch you refers.
"dmesg | grep ^e1000phy" will show you PHY related information.
> My thought about this is that all of the TCP packets received from the
> FreeBSD machine were considered bad, so the XP machine gave up after so
> many tries and bad checksum reports. I could be wrong though.
To narrow down the issue, disable checksum offload/TSO in msk(4) and
see Mac box still receives bad packets generated from msk(4).
To disable checksum offload/TSO, use the following command.
#ifconfig msk0 -tso -txcsum
> Thanks for the advice,
More information about the freebsd-net