On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote: > On 11/6/19 8:34 PM, Peter Zijlstra wrote: > > On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote: > [..] > >> Sorry, I should have tried to describe better. > >> > >> I'm trying to remove external users of console_loglevel by following > >> reasons: > > > > I suppose since all my machines have 'debug ignore_loglevel > > earlyprintk=serial,ttyS0,115200 console=ttyS0,115200' I don't have this > > experience. > > Yeah, I remember you avoid all those functionalities of printk(), fair > enough. On the other side, regular users and I'm betting most of > the non-tuned distributions use /proc/sys/kernel/printk by default. > (Checking on my Arch & Fedora - loglevel 4 from the box) > > >> - changing console_loglevel on SMP means that unwanted messages from > >> other CPUs will appear (that have lower log level) > >> - on UMP unwanted messages may appear if the code is preempted while it > >> hasn't set the console_loglevel back to old > >> - rising console_loglevel to print wanted message(s) may not work at all > >> if printk() has being delayed and the console_loglevel is already set > >> back to old value > > > > Sure, frobbing the global console_loglevel is bad. > > > >> I also have patches in wip those needs to print backtrace with specific > >> loglevel (higher when it's critical, lower when it's notice and > >> shouldn't go to serial console). > > > > (everything always should go to serial, serial is awesome :-) > > Personally I agree. Unfortunately, here @Arista there are switches (I'm > speaking about the order of thousands at least) those have baud-rate 9600. > It's a bit expensive being elaborate with such setup. > > >> Besides on local tests I see hits those have headers (messages like > >> "Backtrace: ") without an actual backtrace and the reverse - a backtrace > >> without a reason for it. It's quite annoying and worth addressing by > >> syncing headers log levels to backtraces. > > > > I suppose I'm surprised there are backtraces that are not important. > > Either badness happened and it needs printing, or the user asked for it > > and it needs printing. > > > > Perhaps we should be removing backtraces if they're not important > > instead of allowing to print them as lower loglevels? > > Well, the use-case for lower log-level is that everything goes into logs > (/var/log/dmesg or /var/log/messages whatever rsyslog has settting). > > That has it's value: > - after a failure (i.e. panic) messages, those were only signs that > something goes wrong can be seen in logs which can give ideas what has > happened. No they don't. When the kernel panics, userspace generally stops running, so rsyslog won't be able to write them to /var/log/messages. How, by "kernel panics" I mean a real kernel panic, which probably isn't what you're talking about there. You are probably talking about the whole shebang of non-fatal kernel oops, kernel warnings and the like. If so, I'd ask you to stop confuzzilating terminology. If you really want to capture such events, then you need to have the kernel write the panic to (e.g.) flash - see the mtdoops driver. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
