Slow boot and reboot fail on Intel Elkhart Lake SoC - Workaround


I want to share some information concerning an issue with an Intel Elkhart Lake SoC I just wasted several hours of my life on:

I installed Core Update 166 on a Mitac PD10EHI board based on the Elkhart Lake Pentium N6415. Everything went fine except that the boot process hanged for over a minute at a certain point and - the actual problem - the reboot process hanged at the line “preparing for reboot” for a, I think, infinite time (I did not have the patients to check wether it would reboot eventually) requiring a hard reset. The latter is of course a no go for a remote managed system.

Logging udev in debug mode revealed that the boot delay occured with the device INTC1020:00. A search led me to a workaround: When blacklisting the module pinctrl_elkhartlake in /etc/modprobe.d/blacklist.conf, the problem is gone - no side effects so far.

I am not sure, if this workaround will be persistent with future IPFire updates. Maybe someone can comment?




Having a quick look through the git code it looks like when udev is updated in a core update then the blacklist.conf will be replaced by the standard defined one. Last update was Oct 2021. So not all Core Update will reset it but it can’t be guaranteed to stay fixed.

An option might be to request that your blacklist line is also added to the standard list. Raise it as a bug and if it is accepted by the devs then the bug fix will be simple.



i have the same board and can confirm that this fixes the reboot hang and the boot delay.

Really nice @cmuenkel :+1:


the workaround through /etc/modprobe.d/blacklist.conf stopped working for me since I guess 1 or 2 releases. I assume, that the pinctrl_elkhartlake module gets loaded before blacklist.conf is read now (but I am no expert).

Alternatively I tried to blacklist the module by adding “module_blacklist=pinctrl_elkhartlake” to “GRUB_CMDLINE_LINUX” in /etc/default/grub followed by “grub-mkconfig -o /boot/grub/grub.cfg”. This did the trick again.



Normal you can also create a new *.conf file for blacklisting.
echo blacklist pinctrl_elkhartlake > /etc/modprobe.d/blacklist_pinctrl_elkhartlake.conf
But you need to rebuild also the initrd because the blacklist file must copied to this also, so your grub solution is the easier way.


I have the same board and same issue. Mitac told me that it’s an kernel bug sind >5.10 and I should use version 5.10 max. However I wonder it’s still not fixed. INTC1020:00 seems to be the GPIO host controller. OK I should not need that one also since I don’t use the GPIO with this board.

That works. I added to the last line of the file ‘/etc/default/grub’


Rebuilt the grub config by

grub-mkconfig -o /boot/grub/grub.cfg

Powered off and on again. Works fine.

I did not remove the initial modprobe blacklisting. Maybe both are needed…

I am not sure if what you have written here is what you have actually done, ie added the module_blacklist line at the end of the /etc/default/grub file. If so that is incorrect.

You need to put that line at the end of the line in /etc/default/grub that starts with

After the first double quote there will be some options such as defining the console etc. The options are space separated. Add the blackist option just before the second double quote.


:expressionless::face_with_open_eyes_and_hand_over_mouth: you are so right. Thx. :hugs: I edit my previous post to prevent somebody insert the wrong line. The device boots up bloody fast now.


Have you seen this Bug report and links there?