Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Marvell Yukon 88E8057 Gigabit Ethernet and amd64

    Hardware
    3
    3
    1382
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mrhanman
      last edited by

      I've been running i386 for years now, and with the recent release of 2.2.6 I decided it was time to switch to amd64 since it is the preferred version.  I did a fresh install of amd64, but I constantly received Watchdog Timeout errors on my Marvell Yukon 88E8057 Gigabit Ethernet.  After initial configuration not changing matters, I did a fresh install of i386 and it worked fine.  After restoring my original config, I even tried to "upgrade" to amd64.  This resulted in the same error.

      I searched to see if there was a known issue with amd64 and this ethernet controller, but I didn't find anything.  Am I missing something obvious?  Where do I go from here?

      Thanks!

      1 Reply Last reply Reply Quote 0
      • B
        Blade Runner
        last edited by

        Please post your hardware configuration.

        Do not be afraid to fail.

        1 Reply Last reply Reply Quote 0
        • R
          RoyalAlert
          last edited by

          I have the same problem. I am running a 5 years old AMD64 box (AMD Athlon 64 X2 Dual Core Processor 4800+) on a ASUS motherboard. I have two NICs one of which is an Intel Pro 100/1000 and the other a Marvell Semiconductors Yukon 100/1000. I have not yet created any custom firewall rules. When the install was fresh I could run PFSense for a few seconds to a few minutes before Pfsense stopped serving requests. The first trouble-shooting thing I did was to turn off any equipment that might compete for DHCP addressing, but to no avail.

          After realising that the Gateway-log was full of error messages such as those below I stumbled up on this topic.

          
          Dec 30 09:16:08   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:09   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:10   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:11   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:12   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:13   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:14   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:15   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:16:16   apinger: Could not bind socket on address(90.226.210.126) for monitoring address 90.226.210.1(WAN_DHCP) with error Can't assign requested address
          Dec 30 09:17:48   apinger: Starting Alarm Pinger, apinger(26023)
          Dec 30 09:36:25   apinger: Starting Alarm Pinger, apinger(21795)
          
          

          Starting out I had put the LAN Interface on the Marvell card, but that caused the Web Configurator to become unresponsive as soon as the link went down. Then I switched the interfaces (so that the WAN Interface uses the Marvell NIC) with the somewhat positive result that I could at least reboot the system remotely when the link dropped as it kept doing after a few minutes after rebooting.

          After checking "Disable hardware TCP segmentation offload" in System -> Advanced, Networking tab as advised by David_W in the thread https://forum.pfsense.org/index.php?topic=96325.15, uptime increased from minutes to hours (at least in some cases, but sometimes it is minutes still).

          I have now also tried the changing the System: Advanced: System Tuneable net.net.tcp.tso variable from 1 to 0 as advised by julicravo, but that made the system more unstable as changing that variable caused the system to stop serving request just a few minutes after rebooting. I must admit though that it is somewhat hard to tell if the net.net.tcp.so made any difference for the better or worse.

          Right now I am running my WAN on the onboard ethernet and my LAN on the 1 GB Intel Pro NIC and this configuration works great.

          I believe there is a bug in the FreeBSD Marvell driver. I will replace the Marvell card with an Intel. Will pfsense auto-detect if I switch NICs and install the proper drivers by itself?

          1 Reply Last reply Reply Quote 0
          • First post
            Last post