On Thu, Nov 09, 2023 at 04:41:00PM +0100, Christian Theune wrote: > > > On 9. Nov 2023, at 14:50, Corey Minyard <miny...@acm.org> wrote: > > > > It's 09c5ba0aa2fc "printk: add kthread console printers" and some > > others. It's in 5.19, so it was later than I thought. > > Interesting. I can see it merged but then also reverted AFAICT before the > 5.19 release.
Oh, yeah. Getting this in has been a fight, it's been going on a long time. Printk ties into so many things. > > I saw a lot of work around kprint() happened in and after 5.15 so I guess > upgrading to 5.15 shouldn’t hurt in any case. > > Not having a reproducer is the real bummer. > > I was also wondering whether using other utilities like storing kernel crash > dumps on swap would be a good avenue. The only issue here being that this is > a KVM/Qemu host with lots of RAM and I think I don’t have enough disk space > to capture full system memory dumps … You might be surprised, it is probably smaller than you think. > > > I'm not being a lot of help here, but hopefully it can lead you > > somewhere you can figure this out. These can be hard problems to > > track down. > > I guess we’re both pretty blind here. I appreciate any assistance. :) > > > I don't remember, had you done anything with the kernel preempt tracing? > > That can be useful for tracking down long preempt off times. > > Uhm no, not yet. Any pointers where to start and how this relates to > potential kprint buffers? Actually, I'm confusing this with another issue dealing with real time latencies and printk. Preempt tracing won't help your issue. A assume you are using the "normal" NMI watchdog and it's not triggerring. It should be on by default. You can look in /proc/sys/kenel/nmi_watchdog to see. I was working with a customer of our companies on something similar, a watchdog reset with not discernable reason. They couldn't use the standard NMI watchdog, so we switched to using an NMI watch from the BMC. Set the preaction to nmi and the preop to panic. With that, you can take a kernel coredump. You generally only take a coredump of kernel memory (without buffers), so it's not generally a huge amount of disk space, and it's compressed. Of course, then you have to analyze a coredump, which has its own difficulties :-(. -corey _______________________________________________ Openipmi-developer mailing list Openipmi-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openipmi-developer