5.4-RELEASE lockups on amd64 SMP

Grooms, Matthew MGrooms at seton.org
Wed Jun 8 23:23:44 GMT 2005


Max,

     With your patch applied, I get a panic very quickly during the boot cycle with output that looks like this ...

net.inet.carp.preempt: 0 -> 1
Setting hostname: ---.
em: Link is up 100 Mbps Full Duplex
panic: mtx_lock() of spin mutex (null) @ ../../../net/if.c:1983
cpuid = 1
KDB: enter: panic
[thread pid 282 tid 100157 ]
Stopped at      kdb_enter+0x2f: nop
db> trace
Tracing pid 282 tid 100157 td 0xffffff000af78280
kdb_enter() at kdb_enter+0x2f
panic() at panic+0x249
_mtx_lock_flags() at _mtx_lock_flags+0xd6
if_handoff() at if_handoff+0x49
pfsync_sendout() at pfsync_sendout+0x268
pfsyncioctl() at pfsyncioctl+0x497
in_control() at in_control+0x8cb
ifioctl() at ifioctl+0x178
sooo_ioctl() at soo_ioctl+0x2d6
ioctl() at ioctl+0xfc
syscall() at syscall+0x4ab
Xfast_syscall() at Xfast_syscall+0xa8
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x800793340, rsp = 0x7fffffffeca8, rbp = 0x7fffffffef8b ---
db> show locks
eclusive sleep mutex pf task mtx r = 0 (0xffffffff80752f60) locked @ contrib/pf/net/if_pfsync.c:973

Rebooting the machine with the same kernel produces an identical panic. Let me know what else I can do to help. Right now I have just been rebooting back to a UP kernel which has never shown any sign of problems.

Matthew Grooms

-----Original Message-----
From: Grooms, Matthew
Sent: Wed 6/8/2005 6:22 PM
To: Max Laier
Cc: Palle Girgensohn; Kris Kennaway; freebsd-stable at freebsd.org; glebius at freebsd.org; pf at freebsd.org
Subject: RE: 5.4-RELEASE lockups on amd64 SMP
 
Matthew,

can you try the attached diff.  Available for 5 and CURRENT.  I recall that 
this problem was seen before, strange that I didn't see the problem.  Sounds 
familiar to you?  Please try the patch and let me know if that helps.  Thanks 
a lot.

On Wednesday 08 June 2005 01:35, Matthew Grooms wrote:
> Once again, here are the backtraces for the panic and lor ...
>
> Tracing id 110 tid 100089 td 0xffffff012f3f0c80
> kdb_enter() at kdb_enter+0x2f
> panic() at panic+0x249
> uma_dbg_free() at uma_dbg_free+0x188
> uma_zfree_arg() at uma_zfree_arg+0x1b0
> pf_purge_expired_states() at pf_purge_expired_states+0x41
> pfsync_input at pfsync_input+xb35
> pf_input() at ip_input+0x10f
> netisr_processqueue() at netisr_processqueue+0x17
> swi_net() at swi_net+0xa8
> ithread_loop() at ithread_loop+0xd9
> fork_exit() at fork_exit+0xc3
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffffffb44f9d00, rbp = 0 ---
> db> continue
> boot() called on cpu#0
> Uptime: 13h42m43s
> Dumping 4864 MB
>   16 32 ...
>
> lock order reversal
...
> alltraps_with_regs_pushed() at alltraps_with_regs_pushed+0x5
> pf_state_tree_lan_ext_RB_REMOVE() at pf_state_tree_lan_ext_RB_REMOVE+0x10c

This LOR is a consequence of the fault, so it can be disregarded.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News




More information about the freebsd-pf mailing list