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