I am working on a PowerPC board using kernel version 4.1.35 and encountering significant boot delays, specifically around the RTC clock (ds-1337) operations. During the boot process, a script (hwclock.sh) runs the hwclock –hctosys command, and I’ve added print statements to log its execution time in the kernel logs.

Here’s a snippet from hwclock.sh:

echo "running command hwclock --hctosys. - arij" | tee /dev/kmsg
hwclock $tz --hctosys
echo "ending hwclock --hctosys. - arij" | tee /dev/kmsg

When the kernel configuration CONFIG_DYNAMIC_DEBUG is disabled, the hwclock command experiences significant delays, sometimes up to 50 seconds. However, when **CONFIG_DYNAMIC_DEBUG ** is enabled, the delays are significantly reduced, with execution times ranging between 4 to 12 seconds.

Here are some kernel log snippets from various boot cycles with **CONFIG_DYNAMIC_DEBUG **disabled:

Boot cycle 1:

[    6.401707] running command hwclock --hctosys. - arij
[   39.206200] ending hwclock --hctosys. - arij

Boot cycle 2:

[    7.054404] running command hwclock --hctosys. - arij
[   14.218021] ending hwclock --hctosys. - arij

Boot cycle 5:

[   18.659482] running command hwclock --hctosys. - arij
[   50.005113] ending hwclock --hctosys. - arij

With CONFIG_DYNAMIC_DEBUG enabled, the delays decrease:

Example with **CONFIG_DYNAMIC_DEBUG **enabled:

[   8.833980] running command hwclock --hctosys. - arij
[  14.223970] ending hwclock --hctosys. - arij

Additionally, when booting with the configuration CONFIG_PROFILING enabled, the hwclock command consistently takes no more than 2 seconds.

Questions

1. What could be causing the drastic increase in boot time when CONFIG_DYNAMIC_DEBUG is disabled?
2. Why does enabling CONFIG_DYNAMIC_DEBUG reduce the time taken for the hwclock –hctosys command?
3. Could there be any underlying issues with the RTC driver or interactions between the hwclock command and kernel configurations?
4. How might CONFIG_PROFILING impact the timing of hwclock –hctosys?
5. Any insights into these behaviors would be greatly appreciated.

i have tried multiple kernel prints in the rtc drivers and it only showed that the mutex lock is waiting to be acquired. i cant understand whats causing the problem and how is it not appearing when dynamic debugging is enabled