artifact.ci's head -r357545 kernel for 32-bit powerpc FreeBSD vs. 64-bit PowerMac: panic: lock tfo_ccache_bucket . . . already initialized

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)

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"