Re: [Fwd: assigning an address to ng_fec(4) iface causes panic]

From: Maksim Yevmenkin (maksim.yevmenkin_at_gmail.com)
Date: 08/23/05

  • Next message: Matthew Grooms: "Re: odd tcpdump output w/ 6.0-BETA2 ..."
    Date: Tue, 23 Aug 2005 11:33:10 -0700
    To: Brooks Davis <brooks@one-eyed-alien.net>
    
    
    

    On 8/23/05, Brooks Davis <brooks@one-eyed-alien.net> wrote:
    > On Tue, Aug 23, 2005 at 10:09:06AM -0700, Maksim Yevmenkin wrote:
    > > Hello,
    > >
    > > please try the attached patch.
    > >
    > > > >Description:
    > > > assigning an address to ng_fec(4) iface causes panic
    > > > during dumping to dumpdev another panic occurs preventing to identify the source of the first panic and having the crash dump
    > > >
    > > > ng_iface creation sequence:
    > > > mkpeer fec dummy fec
    > > > msg fec0: add_iface "em0"
    > > > msg fec0: add_iface "em1"
    > > > msg fec0: set_mode_mac
    > > >
    >
    > > --- ng_fec.c.orig Mon Aug 22 11:42:51 2005
    > > +++ ng_fec.c Tue Aug 23 10:05:23 2005
    > > @@ -544,8 +544,8 @@
    > > struct ifnet *ifp, *bifp;
    > > struct ng_fec_portlist *p;
    > >
    > > - ifp = arg;
    > > - priv = ifp->if_softc;
    > > + priv = arg;
    > > + ifp = priv->ifp;
    > > b = &priv->fec_bundle;
    > >
    > > if (b->fec_ifcnt == 1 || b->fec_ifcnt == 3) {
    >
    > This isn't quite sufficent. You also should change the ng_fec_init(ifp)
    > call on line 718 to ng_fec_init(ifp->if_softc). If that work's I'll
    > commit it.

    oops... i missed this. thanks for catching this! i do not have
    hardware to test it :) i have attached updated path. if anyone could
    please test it and confirm that it works then feel free to commit it
    (or let me know and i can commit it myself :)

    > I've got to say this calling convention is really stupid. I'm
    > really tempted to change ifp->if_init() to take a struct ifnet * even
    > though it means an API change and a tree sweep.

    sounds good to me.

    thanks,
    max

    
    
    

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



  • Next message: Matthew Grooms: "Re: odd tcpdump output w/ 6.0-BETA2 ..."

    Relevant Pages

    • Re: FW: use of base image / delta image for automated recovery from attacks
      ... the performance and storage penalties accumulate. ... The problem is that if you commit too eagerly, ... > But in your typical web application, most partitions do not accrue important ... > doing this in hardware, ...
      (SecProg)
    • Re: 24 lost ticks with 2.6.20.10 kernel
      ... The main issue is that we read the hardware ... strange that you are losing that many ticks IMHO, ... This reverts commit 60cba200f11b6f90f35634c5cd608773ae3721b7. ...
      (Linux-Kernel)
    • Re: 24 lost ticks with 2.6.20.10 kernel
      ... The main issue is that we read the hardware ... strange that you are losing that many ticks IMHO, ... This reverts commit 60cba200f11b6f90f35634c5cd608773ae3721b7. ...
      (Linux-Kernel)
    • Re: remove blk_queue_max_phys_segments in libata
      ... LIBATA_MAX_PRD is the maximum number of DMA scatter/gather elements ... The basic issue is that the physical segment ... The commit message itself has good reasoning as well. ... naming, but essentially the 'hardware' ...
      (Linux-Kernel)
    • Re: vge(4) bad checksum
      ... it's probably using hardware checksum offloading. ... you probably missed a commit by csjp@ where it was fixed. ... is because the hardware strips the VLAN tag, ...
      (freebsd-current)