Date: Tue, 23 Sep 2008 20:36:00 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Jack Vogel <jfvogel@gmail.com> Cc: Bruce M Simpson <bms@incunabulum.net>, FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: fxp multicast forwarding problems Message-ID: <20080924033600.GA71488@icarus.home.lan> In-Reply-To: <2a41acea0809231136o51201085g3ba38dfb625ef217@mail.gmail.com> References: <48D8BAF1.1020602@incunabulum.net> <20080923100601.GA52531@icarus.home.lan> <2a41acea0809231136o51201085g3ba38dfb625ef217@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080924033600.GA71488>