Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Dec 2006 13:05:03 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw>
Cc:        freebsd-current@freebsd.org
Subject:   Re: CURRENT freezes on Laitude D520
Message-ID:  <20061216130332.A72986@fledge.watson.org>
In-Reply-To: <0612162051509.77059@www.mmlab.cse.yzu.edu.tw>
References:  <52944.192.168.1.110.1165679313.squirrel@yal.hopto.org>  <20061209195519.B60055@mp2.macomnet.net> <20061209204924.N9926@fledge.watson.org> <cb5206420612091310r719f7b3en2d4fb35b23453ddf@mail.gmail.com> <20061209214233.L2273@fledge.watson.org> <0612101036232.41529@www.mmlab.cse.yzu.edu.tw> <20061210084254.X9926@fledge.watson.org> <06121121220014.48706@www.mmlab.cse.yzu.edu.tw> <20061211140519.Q4227@fledge.watson.org> <0612162051509.77059@www.mmlab.cse.yzu.edu.tw>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 16 Dec 2006, Tai-hwa Liang wrote:

>>>> Please open a PR that describes your configuration, includes your kernel 
>>>> config (since it seems quite customized), any loader.conf settings, a 
>>>> detailed description of the problem, and the output.  I'd be quite 
>>>> interested
>>>
>>>  Okay, I'll file a PR once I can collect more information with the serial 
>>> console(probably weekend).  For now our system administrator is pretty 
>>> nervous about my suggestion on turning debug.mpsafenet back to 1. ;)
>> 
>> Thanks.
>
>  Okay, I filed the collected data as kern/106805.  Looks to me that the 
> lockup does related to the WITNESS warning I've observed.

Indeed, as you surmise, it looks like pf is holding a lock over entry to the 
network stack, which is a bad idea as pf locks normally follow most other 
locks in the network stack in the global lock order.  Mark has assigned the PR 
to freebsd-pf, so hopefully it will be picked up there.  If no one has picked 
it up in a couple of weeks, please ping me and I can investigate myself; since 
I don't use pf and am unfamiliar with the internals, it's probably better if 
someone who is an expert in pf internals takes the first cut at this.

Thanks for the excellent problem report!

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> db> trace
> Tracing pid 924 tid 100042 td 0xc653e480
> kdb_enter(c0685297) at kdb_enter+0x2b
> siointr1(c6539400,c071fec0,0,c06850a1,56e,...) at siointr1+0xce
> siointr(c6539400) at siointr+0x21
> intr_execute_handlers(c63ea4c8,e6c308d0,4,e6c30920,c0621693,...) at
> intr_execute_handlers+0xe1
> lapic_handle_intr(38) at lapic_handle_intr+0x2e
> Xapic_isr1() at Xapic_isr1+0x33
> --- interrupt, eip = 0xc04edf41, esp = 0xe6c30914, ebp = 0xe6c30920 ---
> _mtx_lock_sleep(c698ce80,c653e480,0,c698a1b6,18f2) at _mtx_lock_sleep+0x115
> _mtx_lock_flags(c698ce80,0,c698a1b6,18f2,c698ce80,...) at 
> _mtx_lock_flags+0xa2
> pf_test(2,c64bb800,e6c30a78,0,c755d000,...) at pf_test+0x81
> pf_check_out(0,e6c30a78,c64bb800,2,c755d000) at pf_check_out+0x3d
> pfil_run_hooks(c071a420,e6c30af4,c64bb800,2,c755d000,...) at 
> pfil_run_hooks+0xc9
> ip_output(c687d700,0,e6c30ac0,0,0,c755d000) at ip_output+0x83a
> tcp_output(c7558740) at tcp_output+0xe0d
> tcp_disconnect(c7558740) at tcp_disconnect+0xe0
> tcp_usr_disconnect(c72776f4,e6c30bf0,c0531e2c,c72776f4,c6edf480,...) at 
> tcp_usr_disconnect+0x6b
> sodisconnect(c72776f4) at sodisconnect+0x26
> soclose(c72776f4) at soclose+0x48
> soo_close(c6edf480,c653e480) at soo_close+0x4b
> fdrop_locked(c6edf480,c653e480,c63d5084,0,c0667839,...) at fdrop_locked+0x88
> fdrop(c6edf480,c653e480,6ac,c06d02e0,0,...) at fdrop+0x24
> closef(c6edf480,c653e480,0,0,39,...) at closef+0x367
> close(c653e480,e6c30d04) at close+0x1a6
> syscall(3b,3b,3b,0,39,...) at syscall+0x22f
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (6, FreeBSD ELF32, close), eip = 0x2830e9af, esp = 0xbfbe88dc, 
> ebp = 0xbfbe88f8 ---
>
> -- 
> Cheers,
>
> Tai-hwa Liang
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061216130332.A72986>