NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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


Home | Main Index | Thread Index | Old Index