Marvell 88E8001 on sk0 and RELENG_5_3 - big problems

From: Heinz Knocke (knockefreebsd_at_o2.pl)
Date: 12/14/04

  • Next message: Peter Radcliffe: "Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW"
    To: <freebsd-net@freebsd.org>, <freebsd-hardware@freebsd.org>, <freebsd-stable@freebsd.org>
    Date: Tue, 14 Dec 2004 23:00:40 +0100
    
    

    Hi!

    Marvell's chip is not in supported nics section of 5_3 release notes, but in man sk is , so I decided to write.
    I've got some boxes with Marvell Gigabit NICs on-board (Gigabyte and ASUS). Sadly, I can't be happy with it and freebsd 5.3 because of the following two problems:

    a) sk0 driver seems to have some kind of bug in it - see http://www.freebsd.org/cgi/query-pr.cgi?pr=71229
    Does anybody know how is the work going on with it? I know that under Linux they'd had some troubles with these NICs too, standard sk98lin module didn't work properly and there was a vendors patch needed. Marvel doesn't support FreeBSD, but maybe Windows NDIS2 will work?:
    http://www.marvell.com/drivers/driverDisplay.do?dId=113&pId=16 . I can do some tests, but let me know if it's not totaly useless (some tips how to make it work would be helpfull to :)

    b) according to the vendor's info, NIC should be able to do jumboframes. (http://www.marvell.com/products/pcconn/yukon/Yukon_88E8001_10_073103_final.pdf)

    ifconfig mtu 9000 works, but packets seems to come truncated (in both directions)

    host1% sudo ping -s 2000 host2
    PING host2 (10.10.10.2): 2000 data bytes
    ^C
    --- host2 ping statistics ---
    23 packets transmitted, 0 packets received, 100% packet loss

    host2% sudo tcpdump -i sk0 -c 30
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on sk0, link-type EN10MB (Ethernet), capture size 96 bytes
    22:23:23.514150 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 3
    22:23:24.524147 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 4
    22:23:25.534282 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 5
    22:23:26.544280 IP truncated-ip - 524 bytes missing! dyplom1g > dyplom2g: icmp 2008: echo request seq 6
    ^C

    Does anybody know what's going on?? Are a) and b) all the same big Marvel problem :)) ?
    Honestly said I don't know how to track it further, because the link layer (hardware or the driver) seems just to clip frames. If there's not enought info for the solution please tell me what tests can I do - I'll do it ASAP.

    I'd appreciate you support as usual :))

    hk
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


  • Next message: Peter Radcliffe: "Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW"

    Relevant Pages

    • Marvell 88E8001 on sk0 and RELENG_5_3 - big problems
      ... Marvell's chip is not in supported nics section of 5_3 release notes, but in man sk is, so I decided to write. ... but packets seems to come truncated ... If there's not enought info for the solution please tell me what tests can I do - I'll do it ASAP. ...
      (freebsd-net)
    • Re: Ethernet card receiving influenced by CPU speed?
      ... it usually shows up in nics and video cards. ... Frames are the "packets" used to send ethernet signals/data on the ...
      (comp.os.linux.networking)
    • Re: [RFC v1] hand off skb list to other cpu to submit to upper layer
      ... I am investigating an ip_forward performance issue with 10G IXGBE NIC. ... The 2nd receives the packets from one NIC and forwards them out ... As NICs supports multi-queue, I bind the queues to different logical ... cpu of different physical cpu while considering cache sharing carefully. ...
      (Linux-Kernel)
    • Re: [RFC v1] hand off skb list to other cpu to submit to upper layer
      ... multiple receiving NICs scenario as I couldn't get enough hardware. ... The assumption is it's best to send out packets from the TX of the ... Or more direct speaking is we need send packets on the same cpu on ... The start point is that could reduce skb and data cache miss. ...
      (Linux-Kernel)
    • Re: What is a default route??
      ... lines run to two different ISPs. ... By "bonding" the NICs the OP could have automatic failover (another ... two route paths. ... route related packets out one interface and other related packets out ...
      (comp.os.linux.networking)