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: Sun, 23 Aug 2009 12:44:23 -0500

 On Sun, Aug 23, 2009 at 06:54:35AM -0400, Christos Zoulas wrote:
 > On Aug 23,  6:45am, kardel%netbsd.org@localhost (Frank Kardel) wrote:
 > -- Subject: Re: kern/41918: pppoe BROKEN: panic:kernel diagnostic assertion "
 > 
 > |  Besides that there is always room for improvement, the problem occurred 
 > |  just recently - a feeled 1-2weeks ago (I noticed it with my -current 
 > |  update of last week).
 > |  So it is likely the deferral of the setting of link-local and loopback 
 > |  addresses to a thread. The workqueue setup code uses kmem_zalloc that 
 > |  imports the non softintr
 > |  requirement into in6_ifattach() (in6_ifattach.c:1.83 2009-08-13). Using 
 > |  malloc() instead might be an option (in6_createmkludge()) does that.
 > |  
 > |  Frank
 > 
 > That also seems to break if_iwn.c during boot.
 
 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.
 
 Dave
 
 -- 
 David Young             OJC Technologies
 dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933