Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion "!cpu_softintr_p()" ... subr_kmem.c

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR kern/41918; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: David Young <dyoung%pobox.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
kardel%pip.acrys.com@localhost
Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion 
"!cpu_softintr_p()" ... subr_kmem.c
Date: Mon, 24 Aug 2009 13:58:23 -0400

 On Aug 24, 12:15pm, dyoung%pobox.com@localhost (David Young) wrote:
 -- Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion "
 
 | On Sun, Aug 23, 2009 at 03:29:07PM -0400, Christos Zoulas wrote:
 | > On Aug 23,  5:45pm, dyoung%pobox.com@localhost (David Young) wrote:
 | > -- Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic 
assertion "
 | > 
 | > |  I don't know if it is related, but iwn(4) and pppoe(4) are both doing
 | > |  "funny" things with IFF_UP.  It is inexcusable in the case of iwn(4),
 | > |  which should modify IFF_RUNNING, instead.  I don't understand how/why
 | > |  pppoe(4) messes with IFF_UP, yet, but it probably should not.
 | > |  
 | > 
 | > What's funny about it? It just clears it on error like all the other
 | > wireless drivers do. Can you please explain what you mean?
 | 
 | iwn(4) clears IFF_UP in no fewer than five places, three times in
 | interrupt handlers, once in the watchdog routine, and once in the ioctl
 | routine.  I know that all wireless drivers don't do that.
 
 Well, it is no worse than if_ipw, if_iwi, if_wpi... They are the same
 code basically.
 
 | IFF_UP means "administratively enabled."  It expresses the
 | administrator's intent that the interface should operate.  We leave
 | it to other flags and variables to indicate whether the interface can
 | actually operate: IFF_RUNNING and media state.
 | 
 | It looks to me like iwn(4) should clear IFF_RUNNING when the radio is
 | inactive, but it should never clear IFF_UP.
 
 Then we need to change [in the pci directory only]:
 
     if_de.c:                sc->tulip_if.if_flags &= ~(IFF_UP|IFF_RUNNING);
     if_ipw.c:               ic->ic_ifp->if_flags &= ~IFF_UP;
     if_ipw.c:               sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP;
     if_ipw.c:                       ifp->if_flags &= ~IFF_UP;
     if_ipw.c:fail:  ifp->if_flags &= ~IFF_UP;
 
     if_iwi.c:               sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP;
     if_iwi.c:               sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP;
     if_iwi.c:                       ifp->if_flags &= ~IFF_UP;
     if_iwi.c:fail:  ifp->if_flags &= ~IFF_UP;
 
     if_iwn.c:                       ifp->if_flags &= ~IFF_UP;
     if_iwn.c:                               ifp->if_flags &= ~IFF_UP;
     if_iwn.c:               sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP;
     if_iwn.c:                       ifp->if_flags &= ~IFF_UP;
     if_iwn.c:                               ifp->if_flags &= ~IFF_UP;
 
     if_lmc.c:  sc->ifp->if_flags &= ~IFF_UP; /* down */
     if_lmc.c:  sc->ifp->if_flags &= ~IFF_UP; /* down */
 
     if_wpi.c:                               ifp->if_flags &= ~IFF_UP;
     if_wpi.c:               sc->sc_ic.ic_ifp->if_flags &= ~IFF_UP;
     if_wpi.c:                       ifp->if_flags &= ~IFF_UP;
 
 And also:
 
     cxgb_main.c:            ifp->if_flags |= IFF_UP;
     if_de.c:           ifp->if_flags |= IFF_UP;
     if_lmc.c:          sc->ifp->if_flags |= IFF_UP; /* up and not running */
     if_lmc.c:          sc->ifp->if_flags |= IFF_UP; /* a Unix tradition */
     if_nfe.c:               ifp->if_flags |= IFF_UP;
     if_ti.c:                ifp->if_flags |= IFF_UP;
     if_txp.c:               ifp->if_flags |= IFF_UP;
 
 But if we do that, what can set IFF_RUNNING again? I.e. how do we reset
 the card?
 
 christos