In 2006, I wrote a scheduler that ensures user fairness by assigning tickets to processes. When I was debugging the new scheduler, I put a "printk" statement inside the scheduler function. Then every time I rebooted the machine, the system hung... I was really scratching my head a lot, not being able to figure out the problem. I hard-rebooted the machine so many times that the kernel image number increased to #97. Later, I removed the printk debugging statement just by chance and surprisingly that seemed to help fix the problem. I did not understand why, I even included a small paragraph in my assignment report saying that this became a puzzle for me.

Today, when I was reading "Linux Kernel Development" book chapters about kernel synchronization, I suddenly got inspired to look into the "printk" source code, and here comes the answer to my puzzle:
...
 * This is printk().  It can be called from any context.  We want it to work.
 * Be aware of the fact that if oops_in_progress is not set, we might try to
 * wake klogd up which could deadlock on runqueue lock if printk() is called
 * from scheduler code.
...

Once again I was laughing at myself, well, I should have looked into the source code earlier, really!

Sometimes "someone" would complain that I dig too deep into the code, while I still think it is the only way I understand how the freaking kernel works. Looking back to those old days, when I got puzzled while stopped digging into the inner workings, Bruno always showed me how we could find the truth out. Once I just naturally stopped at some java library functions, unconsciously sticking to the idea that library could not be wrong, Bruno searched the source code of the library for me and showed me we should never stop on the way of finding the truth.