[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
The following reply was made to PR kern/41918; it has been noted by GNATS.
From: David Young <dyoung%pobox.com@localhost>
To: Christos Zoulas <christos%zoulas.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion
"!cpu_softintr_p()" ... subr_kmem.c
Date: Mon, 24 Aug 2009 12:15:09 -0500
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.
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.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933
Main Index |
Thread Index |