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