Date: Wed, 7 Nov 2007 19:32:40 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Garrett Cooper <youshi10@u.washington.edu> Cc: net@freebsd.org Subject: Re: Marvell chipsets on 8-CURRENT and XP x64 won't talk with one another Message-ID: <20071107103240.GG70832@cdnetworks.co.kr> In-Reply-To: <473173CB.40606@u.washington.edu> References: <47194EA1.8000402@u.washington.edu> <20071019212012.C97691@odysseus.silby.com> <47202922.3070700@u.washington.edu> <47209570.20609@tomjudge.com> <4723330A.7070803@u.washington.edu> <4728B256.5080005@u.washington.edu> <9CFC3779-3A4C-4ADD-8F2C-982887CB3039@u.washington.edu> <472FA362.6040608@u.washington.edu> <20071107004149.GB70832@cdnetworks.co.kr> <473173CB.40606@u.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 > though? > 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, > -Garrett -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071107103240.GG70832>