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

[David Young <dyoung%pobox.com@localhost>]

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,
        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 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.
 
 Dave
 
 -- 
 David Young             OJC Technologies
 dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933