Hello, I have the issue that my kernel freezes down during the boot phase. It 
is most probably in the later states, when the inbuild drivers are executed and 
initialized, shortly before the filesystem mount. I enabled ftrace by putting 
"ftrace_dump_on_oops" and ftrace=function or ftrace=wakeup into the kernel 
commandline. But ftrace=function led to a system, that was so slowly that the 
issue never hit. Ftrace=wakeup was answered with a message "ftrace bootup 
tracer 'wakeup' not registered. But not always. I have several devices with the 
same kernel and image but sometimes this message shows up.
But the main problem here is, that the kernel freezes sometimes down and 
doesn't has a chance to throw an oops. And it's different where it freeze each 
time. Which is most probably due the problem that printk doesn't write its 
buffer to the console each time it's invoked. So printk isn't a utility to 
pinpoint exactly where the kernel freezes. And ftrace neither, because it's 
within the kernel and freezes down with the whole kernel. At least in the way I 
using it. Is there any mean to narrow down, where a kernel freezes which is not 
invasive and doesn't slow down the kernel so much? Besides, I had one kernel 
oops but then I got the message: Dumping ftrace buffer (ftrace buffer empty) 
but in that case I didn't choose a tracer (no ftrace=......)
The system is a i.MX6 ARMv7 with kernel 5.4.256. It's a yocto build.


Thank you in advance

BR Chris
Confidentiality Notice: This message (including attachments) is a private 
communication solely for use of the intended recipient(s). If you are not the 
intended recipient(s) or believe you received this message in error, notify the 
sender immediately and then delete this message. Any other use, retention, 
dissemination or copying is prohibited and may be a violation of law, including 
the Electronic Communication Privacy Act of 1986.   
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Reply via email to