preemption_level -1 panic message.

Hi,


My driver is using synchronization KPI of msleep and wakeup in order to wait for events to be completed (one kernel thread waits on msleep while the other is doing some work and when it finishes, it call wakeup with the same channel that the msleep is waiting for..)


for the worker thread i use the wakeup call

wakeup(channel);

And on the waiting thread i use msleep without mutex:

msleep(channel, NULL, 0, "", ts);


after checking this with mojabe (10.14) i got the following panic :


panic(cpu 1 caller 0xffffff800affef06): "thread_invoke: preemption_level -1, possible cause: unlocking an unlocked mutex or spinlock"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-4903.200.199.11.1/osfmk/kern/sched_prim.c:2263


Perhaps anyone can explain this panic, and how can i avoid it ? It havn't occurred before 10.14 with the same code.


Here's the backtrace :

    frame #0: 0xffffff800afe2657 kernel`panic_trap_to_debugger [inlined] current_cpu_datap at cpu_data.h:400 [opt]
    frame #1: 0xffffff800afe2657 kernel`panic_trap_to_debugger [inlined] current_processor at cpu.c:220 [opt]
    frame #2: 0xffffff800afe2657 kernel`panic_trap_to_debugger [inlined] DebuggerTrapWithState(db_op=DBOP_PANIC, db_message=<unavailable>, db_panic_str=<unavailable>, db_panic_args=<unavailable>, db_panic_options=<unavailable>, db_panic_data_ptr=<unavailable>, db_proceed_on_sync_failure=1, db_panic_caller=<unavailable>) at debug.c:472 [opt]
    frame #3: 0xffffff800afe2635 kernel`panic_trap_to_debugger(panic_format_str=<unavailable>, panic_args=<unavailable>, reason=0, ctx=<unavailable>, panic_options_mask=<unavailable>, panic_data_ptr=<unavailable>, panic_caller=18446743524138282758) at debug.c:755 [opt]
    frame #4: 0xffffff800afe24a3 kernel`panic(str=<unavailable>) at debug.c:620 [opt]
    frame #5: 0xffffff800affef06 kernel`thread_invoke(self=0xffffff801b7a4030, thread=0xffffff801afe4540, reason=0) at sched_prim.c:2261 [opt]
    frame #6: 0xffffff800affdaff kernel`thread_block_reason(continuation=<unavailable>, parameter=<unavailable>, reason=<unavailable>) at sched_prim.c:3088 [opt]
    frame #7: 0xffffff800b4fcfe1 kernel`_sleep [inlined] thread_block(continuation=<unavailable>) at sched_prim104 [opt]
    frame #8: 0xffffff800b4fcfd6 kernel`_sleep(chan=<unavailable>, pri=0, wmsg=<unavailable>, abstime=1299691844730, continuation=0x0000000000000000, mtx=0x0000000000000000) at kern_synch.c:251 [opt]
    frame #9: 0xffffff800b4fd352 kernel`msleep(chan=0x01000004001ddd89, mtx=0x0000000000000000, pri=0, wmsg="", ts=<unavailable>) at kern_synch.c:346 [opt]

sage=<unavailable>, db_panic_str=<unavailable>, db_panic_args=<unavailable>, db_panic_options=<unavailable>, db_panic_data_ptr=<unavailable>, db_proceed_on_sync_failure=1, db_panic_caller=<unavailable>) at debug.c:472 [opt]

Replies

Just another important detail... I'm running my driver on top of Fusion virtual machine.


Preepmtion_level seems like a CPU attribute, perhaps this bug resulted from the way Fusion emulate the CPU data ?