[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140403113829.GA715@gmail.com>
Date: Thu, 3 Apr 2014 13:38:29 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Jiri Kosina <jkosina@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Mateusz Guzik <mguzik@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Mel Gorman <mgorman@...e.de>,
Kay Sievers <kay@...y.org>
Subject: Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline
* Borislav Petkov <bp@...en8.de> wrote:
> On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> > Whether it actually fixes the problem that Borislav had is
> > questionable, of course. For all I know, systemd debug mode generates
> > so much data in *other* ways and then causes feedback loops with
> > the kernel debugging that this patch is totally immaterial, and
> > dmesg was never the main issue. But unlike the "hide 'debug' from
> > /proc/cmdline", I think this patch at least _conceptually_ makes a lot
> > of sense, even if systemd gets fixed, so ...
> >
> > Borislav?
>
> Yes, ratelimiting makes the box actually boot all the way. Here's how it
> looks like:
>
> ^MLoading Linux 3.12.16-boris-00441-g60dc93e99a75-dirty ...
> ^MLoading initial ramdisk ...
> ^M[ 0.000000] Initializing cgroup subsys cpuset
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Initializing cgroup subsys cpuacct
> [ 0.000000] Linux version 3.12.16-boris-00441-g60dc93e99a75-dirty (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #11 SMP Thu Apr 3 10:19:49 CEST 2014
> [ 0.000000] Command line: BOOT_IMAGE=/@...ot/vmlinuz-3.12.16-boris-00441-g60dc93e99a75-dirty root=UUID=5f1a28cf-d910-
> 4ed0-85ac-0113d43e553f rootflags=subvol=@ resume=/dev/disk/by-uuid/45671aef-cef3-4fcd-9087-7d4f3f81aa70 splash=off showo
> pts crashkernel=256M-:128M pci=hpiosize=0 pci=hpmemsize=4m pciehp.pciehp_force=1 notsc mem=0x40000000000 loop.max_loop=6
> 4 log_buf_len=16M console=tty0 console=ttyS0,38400n8 ignore_loglevel debug
> ^^^^^
>
> We haz the "debug" thing on.
>
> ...
>
> Here we go:
>
> [ 50.636000] be2net 0000:db:00.0: irq 102 for MSI/MSI-X
> [ 50.636000] be2net 0000:db:00.0: irq 103 for MSI/MSI-X
> [ 50.636000] be2net 0000:db:00.0: irq 104 for MSI/MSI-X
> [ 50.636000] be2net 0000:db:00.0: enabled 4 MSI-x vector(s) for NIC
> [ 50.896000] systemd: 1008 callbacks suppressed
> ^^^^
>
> [ 50.896000] systemd[1]: Started Show Plymouth Boot Screen.
> [ 50.896000] systemd[1]: Got SIGCHLD for process 1192 (swapon)
> [ 50.896000] systemd[1]: Child 1192 died (code=exited, status=0/SUCCESS)
> [ 50.896000] systemd[1]: Child 1192 belongs to dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap
> [ 50.896000] systemd[1]: dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap swap process exited, code=exited status=0
> [ 50.896000] systemd[1]: dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap changed activating -> active
> [ 50.896000] systemd[1]: Job dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap/start finished, result=done
>
> ...
>
> [ 57.988000] scsi2 : Emulex 10Gbe open-iscsi Initiator Driver
> [ 63.028000] be2iscsi 0000:db:00.3: irq 117 for MSI/MSI-X
> [ 63.044000] be2iscsi 0000:db:00.3: irq 118 for MSI/MSI-X
> [ 63.064000] be2iscsi 0000:db:00.3: irq 119 for MSI/MSI-X
> [ 63.080000] be2iscsi 0000:db:00.3: irq 120 for MSI/MSI-X
> [ 63.100000] be2iscsi 0000:db:00.3: irq 121 for MSI/MSI-X
> [ 63.116000] be2iscsi 0000:db:00.3: irq 122 for MSI/MSI-X
> [ 63.132000] be2iscsi 0000:db:00.3: irq 123 for MSI/MSI-X
> [ 63.152000] be2iscsi 0000:db:00.3: irq 124 for MSI/MSI-X
> [ 63.572000] scsi host2: BC_373 : Link Down on Port 1
> [ 63.588000] scsi host2: BM_4336 : No boot session
> [ 63.656000] systemd: 11828 callbacks suppressed
> ^^^^^
>
> We luvz to talk a lot of crap, don't we.
When I suggested that systemd should reuse the tracing and perf ring
buffer infrastructure instead of cluttering the syslog it was
handwaved away...
But at least there's an upside for me: I don't have to deal with the
systemd maintainers' excessively passive-aggressive behavior ;-)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists