artifact.ci's head -r357545 kernel for 32-bit powerpc FreeBSD vs. 64-bit PowerMac: panic: lock tfo_ccache_bucket . . . already initialized
Mark Millard
marklmi at yahoo.com
Wed Feb 5 04:02:40 UTC 2020
On a 32-bit PowerMac 2 socket machine, it booted
just fine. This is a 64-bit capable 2 socket,
2 cores each, PowerMac context for the example
failure.
There is also an odd "kern.ipc.nmbclusters limit
reached" message before the powerpc64 panic.
Typed from a picture of the screen:
(I omit stack addresses and routine offsets
in the backtrace.)
. . .
firewire0: bus manager 1
bge0: link state changed to UP
[zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
panic: lock "tfo_ccache_bucket" 0xdd533f24 already initialized
cpuid = 0
time = 1
KDB: stack backtrace
. . .
panic
lock_init
_mtx_init
tcp_fastopen_init
tcp_init
protosw_init
vnet_domain_init
vnet_register_sysinit
mi_startup
btext
KDB: enter: panic
[ thread pid 0 tid 100000 ]
. . .
This is too early for user input to the
db> prompt on PowerMacs.
The loop in tcp_fastopen_init(void) seems to
be:
for (i = 0; i < V_tcp_fastopen_ccache.buckets; i++) {
TAILQ_INIT(&V_tcp_fastopen_ccache.base[i].ccb_entries);
mtx_init(&V_tcp_fastopen_ccache.base[i].ccb_mtx, "tfo_ccache_bucket",
NULL, MTX_DEF);
if (V_tcp_fastopen_client_enable) {
/* enable bucket */
V_tcp_fastopen_ccache.base[i].ccb_num_entries = 0;
} else {
/* disable bucket */
V_tcp_fastopen_ccache.base[i].ccb_num_entries = -1;
}
V_tcp_fastopen_ccache.base[i].ccb_ccache = &V_tcp_fastopen_ccache;
}
Separately, the warning:
[zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
also seems odd. The powerpc64 FreeBSD variant does not
get this message.
It leaves me wondering if the 32-bit FreeBSD
atomic_fetchadd_64 and smp_started
cross-socket/cross-core value synchronization
are working fully-correctly on 64-bit PowerMacs.
However, I'm outside of my area, so take the
below on such a basis.
It does appear to me that the SMP case for the
!smp__started yet context does not have code for
s=intr_disable() and intr_restore(s) . (Not
limited to atomic_fetchadd_64.) Such disable/restore
code is only present for the !SMP case.
How strongly is the !smp_started temporary-context
like the !SMP case as far as what it requires for
correctness?
FYI:
008fc99c <atomic_fetchadd_64> mflr r0
008fc9a0 <atomic_fetchadd_64+0x4> stw r0,4(r1)
008fc9a4 <atomic_fetchadd_64+0x8> stwu r1,-32(r1)
008fc9a8 <atomic_fetchadd_64+0xc> stw r31,28(r1)
008fc9ac <atomic_fetchadd_64+0x10> stw r30,24(r1)
008fc9b0 <atomic_fetchadd_64+0x14> mr r31,r1
008fc9b4 <atomic_fetchadd_64+0x18> stw r26,8(r31)
008fc9b8 <atomic_fetchadd_64+0x1c> stw r27,12(r31)
008fc9bc <atomic_fetchadd_64+0x20> stw r28,16(r31)
008fc9c0 <atomic_fetchadd_64+0x24> stw r29,20(r31)
008fc9c4 <atomic_fetchadd_64+0x28> bl 008fc9c8 <atomic_fetchadd_64+0x2c>
008fc9c8 <atomic_fetchadd_64+0x2c> mr r27,r3
008fc9cc <atomic_fetchadd_64+0x30> mflr r30
008fc9d0 <atomic_fetchadd_64+0x34> addis r30,r30,80
008fc9d4 <atomic_fetchadd_64+0x38> addi r30,r30,8180
008fc9d8 <atomic_fetchadd_64+0x3c> mr r28,r6
008fc9dc <atomic_fetchadd_64+0x40> mr r3,r27
008fc9e0 <atomic_fetchadd_64+0x44> mr r29,r5
008fc9e4 <atomic_fetchadd_64+0x48> bl 0093e668 <pmap_kextract>
008fc9e8 <atomic_fetchadd_64+0x4c> lwz r4,-32768(r30)
008fc9ec <atomic_fetchadd_64+0x50> rlwinm r3,r3,25,24,31
008fc9f0 <atomic_fetchadd_64+0x54> mulli r26,r3,20
008fc9f4 <atomic_fetchadd_64+0x58> lwz r4,0(r4)
008fc9f8 <atomic_fetchadd_64+0x5c> cmplwi r4,0
008fc9fc <atomic_fetchadd_64+0x60> beq- 008fca1c <atomic_fetchadd_64+0x80>
008fca00 <atomic_fetchadd_64+0x64> lwz r3,-32764(r30)
008fca04 <atomic_fetchadd_64+0x68> lwz r5,-32760(r30)
008fca08 <atomic_fetchadd_64+0x6c> li r4,0
008fca0c <atomic_fetchadd_64+0x70> li r6,101
008fca10 <atomic_fetchadd_64+0x74> add r3,r3,r26
008fca14 <atomic_fetchadd_64+0x78> addi r3,r3,16
008fca18 <atomic_fetchadd_64+0x7c> bl 0051b0b0 <__mtx_lock_flags>
008fca1c <atomic_fetchadd_64+0x80> lwz r3,4(r27)
008fca20 <atomic_fetchadd_64+0x84> lwz r4,0(r27)
008fca24 <atomic_fetchadd_64+0x88> addc r3,r3,r28
008fca28 <atomic_fetchadd_64+0x8c> stw r3,4(r27)
008fca2c <atomic_fetchadd_64+0x90> adde r3,r4,r29
008fca30 <atomic_fetchadd_64+0x94> stw r3,0(r27)
008fca34 <atomic_fetchadd_64+0x98> lwz r3,-32768(r30)
008fca38 <atomic_fetchadd_64+0x9c> lwz r4,4(r27)
008fca3c <atomic_fetchadd_64+0xa0> lwz r5,0(r27)
008fca40 <atomic_fetchadd_64+0xa4> lwz r3,0(r3)
008fca44 <atomic_fetchadd_64+0xa8> subfc r28,r28,r4
008fca48 <atomic_fetchadd_64+0xac> subfe r29,r29,r5
008fca4c <atomic_fetchadd_64+0xb0> cmplwi r3,0
008fca50 <atomic_fetchadd_64+0xb4> beq- 008fca70 <atomic_fetchadd_64+0xd4>
008fca54 <atomic_fetchadd_64+0xb8> lwz r3,-32764(r30)
008fca58 <atomic_fetchadd_64+0xbc> lwz r5,-32760(r30)
008fca5c <atomic_fetchadd_64+0xc0> li r4,0
008fca60 <atomic_fetchadd_64+0xc4> li r6,101
008fca64 <atomic_fetchadd_64+0xc8> add r3,r3,r26
008fca68 <atomic_fetchadd_64+0xcc> addi r3,r3,16
008fca6c <atomic_fetchadd_64+0xd0> bl 0051b780 <__mtx_unlock_flags>
008fca70 <atomic_fetchadd_64+0xd4> mr r3,r29
008fca74 <atomic_fetchadd_64+0xd8> mr r4,r28
008fca78 <atomic_fetchadd_64+0xdc> lwz r29,20(r31)
008fca7c <atomic_fetchadd_64+0xe0> lwz r28,16(r31)
008fca80 <atomic_fetchadd_64+0xe4> lwz r27,12(r31)
008fca84 <atomic_fetchadd_64+0xe8> lwz r26,8(r31)
008fca88 <atomic_fetchadd_64+0xec> lwz r0,36(r1)
008fca8c <atomic_fetchadd_64+0xf0> lwz r31,28(r1)
008fca90 <atomic_fetchadd_64+0xf4> lwz r30,24(r1)
008fca94 <atomic_fetchadd_64+0xf8> addi r1,r1,32
008fca98 <atomic_fetchadd_64+0xfc> mtlr r0
008fca9c <atomic_fetchadd_64+0x100> blr
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-current
mailing list