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

[Garrett Cooper]

On Oct 31, 2007, at 9:50 AM, Garrett Cooper wrote:

> Garrett Cooper wrote:
>> Tom Judge wrote:
>>> Garrett Cooper wrote:
>>>> Mike Silbersack wrote:
>>>>>
>>>>> On Fri, 19 Oct 2007, Garrett Cooper wrote:
>>>>>
>>>>>>> Just to clarify, how are the two hooked together?  Is it over  
>>>>>>> gigabit switch, a 10mbps hub, or directly cabled together?
>>>>>>>
>>>>>>> -Mike
>>>>>>
>>>>>>   Sure. They're both connected over a gigabit switch, but the  
>>>>>> Windows driver's kind of sketchy because it keeps on switching  
>>>>>> between 100MBit and 1GBit. I haven't really paid that much  
>>>>>> attention to what speed the FreeBSD msk driver is registering at.
>>>>>> -Garrett
>>>>>
>>>>> Ah ha!
>>>>>
>>>>> I had the flopping between 100mbps and 1gbps problem with some  
>>>>> Intel cards once - some of the machines in the lab were fine,  
>>>>> others kept switching back and forth.  We eventually narrowed  
>>>>> it down to the cables we had hand-made; some of them just  
>>>>> weren't up to snuff, and the NIC apparently decided that it had  
>>>>> to go back down to 100.
>>>>>
>>>>> I think you should switch your gigabit switch out for a 100mbps  
>>>>> switch and see if the network becomes more reliable.
>>>>>
>>>>> -Mike
>>>>
>>>>    I think I've discovered what the issue is. I believe the  
>>>> problem lies in the fact that the FreeBSD Marvell chipset driver  
>>>> (msk) isn't up to speed with the Gigabit transferring on my  
>>>> particular chipset(s). That's why transfers were most likely  
>>>> working with my laptop (Apple with 100MBit Broadcom) vs my  
>>>> desktop (Asus MB with another Marvell chipset driver) and  
>>>> another laptop (Dell laptop with Broadcom Gigabit).
>>>>    How do I tell ifconfig via rc.conf to downgrade the max speed  
>>>> to 100MBit duplex?
>>>> Thanks,
>>>> -Garrett
>>>
>>> You would need to hard code the interface configuration on the  
>>> switch and box.  This is only possible if you have a managed  
>>> switch and the methods on the switch are manufacturer and model  
>>> dependent.
>>>
>>> On FreeBSD however it is trivial for example "ifconfig em0 media  
>>> 100baseTX mediaopt full-duplex".
>>>
>>> This will disable speed negotiation and therefore must be  
>>> configured at both ends of the link.
>>>
>>> Tom
>>
>> Well, this is interesting. I used a crappy switch (100MBit SOHO  
>> switch), in place of my Netgear non-managed gigabit switch, and  
>> the same thing occurred on the XP x64 machine.
>>
>> I may have forgotten to mention that at one time both machines  
>> were running XP variants of some sort (x64 and x86), and they  
>> worked perfectly fine with one another >_>...
>>
>> Here's some additional info:
>>
>> optimus# arp -a
>> ? (192.168.0.1) at (incomplete) on msk0 [ethernet] # Dummy gateway
>> ? (192.168.0.42) at 00:11:24:2f:15:bc on msk0 [ethernet] # iBook  
>> (broadcom adapter)
>> ? (192.168.0.47) at 00:1a:92:d2:f7:f6 on msk0 [ethernet] # Win XP  
>> x64 machine
>> ? (192.168.0.255) at ff:ff:ff:ff:ff:ff on msk0 permanent [ethernet]
>> optimus# ifconfig msk0
>> msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0  
>> mtu 1500
>>        options=9a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
>>        ether 00:1b:fc:45:9b:5c
>>        inet 192.168.0.45 netmask 0xffffff00 broadcast 255.255.255.0
>>        media: Ethernet autoselect (100baseTX <full- 
>> duplex,flag0,flag1>)
>>        status: active
>> ifconfig_msk0="inet 192.168.0.45 broadcast 255.255.255.0"
>> # media 100baseTX mediaopt full-duplex"
>> defaultrouter="192.168.0.1"
>> optimus# netstat -nr
>> Routing tables
>>
>> Internet:
>> Destination        Gateway            Flags    Refs      Use   
>> Netif Expire
>> default            192.168.0.1        UGS         0        0   msk0
>> 127.0.0.1          127.0.0.1          UH          0       12    lo0
>> 192.168.0.0/24     link#1             UC          0        0   msk0
>> 192.168.0.1        link#1             UHLW        2        0   msk0
>> 192.168.0.42       00:11:24:2f:15:bc  UHLW        1      179    
>> msk0   1028
>> 192.168.0.47       00:1a:92:d2:f7:f6  UHLW        1       21    
>> msk0   1162
>> 192.168.0.255      ff:ff:ff:ff:ff:ff  UHLWb       1       49   msk0
>>
>> arp and everything's show the correct information on the XP end,  
>> even after I removed the 'dummy gateway' on both machines..
>>
>> Next course of action? Snort? tcpdump?
>>
>> Thanks,
>> -Garrett
>
>    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