This looks similar to the pppoe(4) bug that stsp fixed last year: http://marc.info/?l=openbsd-tech&m=130288210121749&w=2
Seems to me like sppp_clear_ip_addresses() needs the same workq treatment that sppp_set_ip_addresses() received. On Tue, Jun 26, 2012 at 8:22 AM, RD Thrush <r...@thrush.com> wrote: > I made a similar report yesterday via sendbug that seems to have disappeared... I'm assuming this kernel message is important. > >>Synopsis: Problematic adsl connection results in console stack trace. >>Category: kernel >>Environment: > System : OpenBSD 5.2 > Details : OpenBSD 5.2-beta (GENERIC) #268: Fri Jun 22 18:59:31 MDT 2012 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > Architecture: OpenBSD.amd64 > Machine : amd64 >>Description: > The subject machine is a firewall and has used a pppoe dsl connection > to the internet for several years. It has occasionally resulted in > the splassert/stack trace but not with enough regularitry to warrant a > report. The dsl connection has recently started to deteriorate > (probably due to soggy weather) and is frequently reconnecting > resulting in the following console output (60+ times in the past 16 > hours): > > splassert: assertwaitok: want -1 have 1 > Starting stack trace... > assertwaitok() at assertwaitok+0x1c > pool_get() at pool_get+0xd5 > ifa_item_insert() at ifa_item_insert+0x35 > ifa_add() at ifa_add+0x43 > in_ifinit() at in_ifinit+0x181 > sppp_clear_ip_addrs() at sppp_clear_ip_addrs+0xb5 > sppp_ipcp_tlf() at sppp_ipcp_tlf+0x1a > sppp_lcp_tld() at sppp_lcp_tld+0x8c > sppp_keepalive() at sppp_keepalive+0x193 > softclock() at softclock+0x291 > softintr_dispatch() at softintr_dispatch+0x5d > Xsoftclock() at Xsoftclock+0x28 > --- interrupt --- > end trace frame: 0x0, count: 245 > 0x8: > End of stack trace. [snip]
