fxp multicast forwarding problems

[Jeremy Chadwick]

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 <koitsu at freebsd.org> 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 |