Early panic in msleep();
Early panic in msleep();
- Subject: Early panic in msleep();
- From: Jorgen Lundman <email@hidden>
- Date: Thu, 26 Jul 2018 17:28:35 +0900
- Autocrypt: addr=email@hidden; prefer-encrypt=mutual; keydata= xsDiBD2KhOgRBACHjaJI1Q5XudbpYACUeGAKFxsxhhg46svF6Y0HzzDP+ZMQENVGiqucma0H b/mY9knTJ5F+rQZO+LKG2T4oBH1VdznJkz28tkmZUXGCEmNOZ852Hb1fFRwnbngRylMq7cEV TgupfCWYbC6Qw7eKBlHWjlvFosn/r828j7STe0CtawCgsbMU6598cmwIvOXaSGuDHLnMzfED /0SVpaTDADGymmjZ/RUyl7wc0D/1Dd0N17kZzQuwXQtj0CWnGwC8XWEvYLdAwNoGmzkJgVg4 3l5JPo4Yeuj7hNayRCjQU6jvnSdj0AuItfuE76/YdSG/X+TWAdHsizXtdXxf6KrS5PSjWult b4yL2EoYkiN58SflRa287mwJxatpA/9/axDaElD8Ko4QsskT2FamKLms1clT8IcuN1JNP71h b4gG0sng8jIl534r3KucJjlYEIp6lL3jBD/lcNQqd+UXMsR7KKEuDvW/ZMzQdLMvpyRCN463 jzrclxG1rXuvyeSWKiOnQbcD5pwsff3xlbb3mMovkf6rbXxvZxQlfUAuRM0kSm9yZ2VuIEx1 bmRtYW4gPGx1bmRtYW5AbHVuZG1hbi5uZXQ+wlkEExECABkFAj2KhOgECwcDAgMVAgMDFgIB Ah4BAheAAAoJEPNmEmurHstLXGgAnA7x3Ipz89W9tWjeJZ3AeEF6DAX/AJ4+QReCt51Nnovp 3T17+gy+p91MEc7ATQQ9ioTpEAQA5omoMw1PE/2reQ96uhFr/eFtGEc6136juCE6Lbrrc52j /DwsB0s87miNKfBRUGKXaqLQmfPY9Qajz/MHUHQ9iOkpCGou8RNviJGKFup4qf/g1qzNQ9ud pgkTEc7qZ7qBWG5HcOoIAvM78qvKwV0Sedry6TpOaiWsuL1HWdSGXI8AAwcEALVHV3MQ+a5K vwhX8Pam52AnIEzcw3m7tcSoJikLZhR//spUaZ3++hN+NNlSxgnGJ+VWKyhxc+SA/IO32vFP rAS6HxyfdZtIKPXfwM/8HjTUa4n6DR8ChIrS43X6cz3TZCFVD9tYLLP5cKo6uuPBd807EQN+ GJAzER048LeRiWMNwkYEGBECAAYFAj2KhOoACgkQ82YSa6sey0soMgCgg7zP7pYVB12AgkyN 0aUsovPMPCQAnjaw8yZSKLeBOzplkeFSIIbfWqTs
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.lundman.net D002A14AD92
- Openpgp: preference=signencrypt
Hello list,
So we do seem to have a panic on boot in mojave which is confusing me somewhat.
If I load kext after boot, no problems.
If I slow down boot, like use boot-args=-v on a MacBookAir, no problems.
Slow VM, no problems.
So clearly I have a race, possible loading so early not everything is ready.
Reading the screen, I appear to die:
Kernel trap at 0xXXXXXXXX, type 14=page fault
mach_kernel : _sleep + 0x63
mach_kernel : _msleep + 0x62
net.lundman.spl : _spl_cv_wait + 0x22
This is early in my kext init phase, I have created a new thread, hold a
mutex and call msleep() to wait on the thread to signal it has started.
Now, I do not have the kernel sources, so I can only guess at the location,
but the _sleep code probably has not changed. I die in here:
_sleep + 0x63 (+99 decimal).
(lldb) dis -a _sleep
kernel`_sleep:
kernel[0xffffff80008ce3e8] <+88>: je 0xffffff80008ce3f2 ;
<+98> at OSAtomicOperations.c
kernel[0xffffff80008ce3ea] <+90>: lock
kernel[0xffffff80008ce3eb] <+91>: incq 0x80(%rax)
kernel[0xffffff80008ce3f2] <+98>: movl %r14d, %esi
kernel[0xffffff80008ce3f5] <+101>: andl $0x400, %esi ; imm
= 0x400
which *probably* matches:
p = current_proc();
p->p_priority = pri & PRIMASK;
/* It can still block in proc_exit() after the teardown. */
if (p->p_stats != NULL)
OSIncrementAtomicLong(&p->p_stats->p_ru.ru_nvcsw);
But it isn't clear to me why it would die in OSIncrementAtomicLong().
'current_proc()' will never return NULL, and we pass the test of p->p_stats.
Is it possible "->p_ru" is not yet ready for me to call msleep()?
Now, I could presumably sleep a little in my init, but that isn't exactly a
solution. Perhaps I can have the kext loaded a little later, although we
want it loaded before mountroot so we can have the rootfs.
Currently, we have plist.info set as:
<key>IOProviderClass</key>
<string>IOResources</string>
<key>IOResourceMatch</key>
<string>IOBSD</string>
<key>OSBundleRequired</key>
<string>Root</string>
In addition to that, it would be nice if I could connect to the lldb of the
macbookair (VMs do not boot fast enough to panic). But not sure if using a
thunderbolt->ethernet adapter will work, when it is this early in the boot
process.
I have attempted to use "kdp_match_name=en2 kdp_ip_addr=192.168.x.x" but I
am unable to connect.
Any information would be appreciated, even in haiku form.
Lund
--
Jorgen Lundman | <email@hidden>
Unix Administrator | +81 (0)90-5578-8500
Shibuya-ku, Tokyo | Japan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden