Re: fxp multicast forwarding problems - FreeBSD

This is a discussion on Re: fxp multicast forwarding problems - FreeBSD ; On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote: > Hi, > > Whilst doing some QA work on XORP on my desktop, which has fxp0 and > msk0, fxp0 got totally hosed. > I was running ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: fxp multicast forwarding problems

  1. Re: fxp multicast forwarding problems

    On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote:
    > Hi,
    >
    > Whilst doing some QA work on XORP on my desktop, which has fxp0 and
    > msk0, fxp0 got totally hosed.
    > I was running PIM-SM and IGMPv2 router-mode on the box at the time.
    >
    > I wonder if this is related to the problems with fxp multicast
    > transmission I saw back in April.
    > I'm a bit concerned about this as fxp is still a very widespread and
    > useful network chip.
    >
    > I am running 7.0-RELEASE-p4/amd64.
    > sysctls for dev.fxp.0 are set to their default values.
    >
    > I'm not expert on the fxp driver internals, but perhaps someone else has
    > seen this kind of problem before. Multicast-promiscuous mode (aka
    > ALLMULTI) was enabled on the interface. I know some NICs have problems
    > with this, or don't even support it.
    >
    > The errors look like this:
    > fxp0: SCB timeout: 0x10 0x0 0x80 0x0
    > fxp0: SCB timeout: 0x10 0x0 0x80 0x0
    > fxp0: DMA timeout
    > ... repeated ...
    >
    > Attempted workarounds which don't work to un-wedge the chip:
    > Reload the fxp0 microcode with "ifconfig fxp0 link0"
    > Forcibly unloading the kernel module and reloading it
    > Unpatching and repatching at the switch (a cheap 10/100 one)
    > Enabling and disabling promiscuous mode
    > Twiddling dev.fxp.0.noflow
    >
    > The link status looks fine, but the card will not send or receive traffic.
    > A warm reboot was enough to get things back up again.
    >
    > regards,
    > BMS


    Adding Jack Vogel, who's responsible for fxp(4).

    --
    | Jeremy Chadwick jdc at parodius.com |
    | Parodius Networking http://www.parodius.com/ |
    | UNIX Systems Administrator Mountain View, CA, USA |
    | Making life hard for others since 1977. PGP: 4BD6C0CB |

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


  2. Re: fxp multicast forwarding problems

    On Tue, Sep 23, 2008 at 11:36:38AM -0700, Jack Vogel wrote:
    > LOL, sorry to disappoint you but I'm not responsible for fxp, Intel didn't write
    > it, and i've never touched it Now that wouldnt mean that I can't look at it,
    > but I am very busy right now, so unless there's no alternative I'd rather not.
    >
    > On Tue, Sep 23, 2008 at 3:06 AM, Jeremy Chadwick wrote:
    > > On Tue, Sep 23, 2008 at 10:46:25AM +0100, Bruce M Simpson wrote:
    > >> Hi,
    > >>
    > >> Whilst doing some QA work on XORP on my desktop, which has fxp0 and
    > >> msk0, fxp0 got totally hosed.
    > >> I was running PIM-SM and IGMPv2 router-mode on the box at the time.
    > >>
    > >> I wonder if this is related to the problems with fxp multicast
    > >> transmission I saw back in April.
    > >> I'm a bit concerned about this as fxp is still a very widespread and
    > >> useful network chip.
    > >>
    > >> I am running 7.0-RELEASE-p4/amd64.
    > >> sysctls for dev.fxp.0 are set to their default values.
    > >>
    > >> I'm not expert on the fxp driver internals, but perhaps someone else has
    > >> seen this kind of problem before. Multicast-promiscuous mode (aka
    > >> ALLMULTI) was enabled on the interface. I know some NICs have problems
    > >> with this, or don't even support it.
    > >>
    > >> The errors look like this:
    > >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0
    > >> fxp0: SCB timeout: 0x10 0x0 0x80 0x0
    > >> fxp0: DMA timeout
    > >> ... repeated ...
    > >>
    > >> Attempted workarounds which don't work to un-wedge the chip:
    > >> Reload the fxp0 microcode with "ifconfig fxp0 link0"
    > >> Forcibly unloading the kernel module and reloading it
    > >> Unpatching and repatching at the switch (a cheap 10/100 one)
    > >> Enabling and disabling promiscuous mode
    > >> Twiddling dev.fxp.0.noflow
    > >>
    > >> The link status looks fine, but the card will not send or receive traffic.
    > >> A warm reboot was enough to get things back up again.
    > >>
    > >> regards,
    > >> BMS

    > >
    > > Adding Jack Vogel, who's responsible for fxp(4).


    Ha, wow! I totally made the assumption you maintained fxp(4) based upon
    of em(4). Seemed logical, but once again, I failed the team.

    Regardless, thanks for looking into this when time permits.

    --
    | Jeremy Chadwick jdc at parodius.com |
    | Parodius Networking http://www.parodius.com/ |
    | UNIX Systems Administrator Mountain View, CA, USA |
    | Making life hard for others since 1977. PGP: 4BD6C0CB |

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


+ Reply to Thread