Marvell chipsets on 8-CURRENT and XP x64 won't talk with one another

[Pyun YongHyeon]

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 
 > 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