1. 10 Jul, 2009 2 commits
    • Frans Pop's avatar
      printk: Restore previous console_loglevel when re-enabling logging · 1aaad49e
      Frans Pop authored
      When logging to console is disabled from userspace using klogctl()
      and later re-enabled, console_loglevel gets set to the default
      log level instead to the previous value.
      
      This means that if the kernel was booted with 'quiet', the boot is
      suddenly no longer quiet after logging to console gets re-enabled.
      
      Save the current console_loglevel when logging is disabled and
      restore to that value. If the log level is set to a specific value
      while disabled, this is interpreted as an implicit re-enabling of
      the logging.
      
      The problem that prompted this patch is described in:
      
          http://lkml.org/lkml/2009/6/28/234
      
      There are two variations possible on the patch below:
      
       1) If klogctl(7) is called while logging is not disabled, then set level
          to default (partially preserving current functionality):
        	case 7:		/* Enable logging to console */
       -		console_loglevel = default_console_loglevel;
       +		if (saved_console_loglevel == -1)
       +			console_loglevel = default_console_loglevel;
       +		else {
       +			console_loglevel = saved_console_loglevel;
       +			saved_console_loglevel = -1;
       +		}
      
       2) If klogctl(8) is called while logging is disabled, then don't enable
          logging, but remember the requested value for when logging does get
          enabled again:
        	case 8:		/* Set level of messages printed to console */
       [...]
       - 		console_loglevel = len;
       +		if (saved_console_loglevel == -1)
       +			console_loglevel = len;
       +		else
       +			saved_console_loglevel = len;
      
      Yet another option would be to ignore the request.
      Signed-off-by: default avatarFrans Pop <elendil@planet.nl>
      Cc: cryptsetup@packages.debian.org
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <200907061331.49930.elendil@planet.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      1aaad49e
    • Robin Getz's avatar
      printk: Ensure that "console enabled" messages are printed on the console · 8259cf43
      Robin Getz authored
      Today, when a console is registered without CON_PRINTBUFFER,
      end users never see the announcement of it being added, and
      never know if they missed something, if the console is really
      at the start or not, and just leads to general confusion.
      
      This re-orders existing code, to make sure the console is
      added, before the "console [%s%d] enabled" is printed out -
      ensuring that this message is _always_ seen.
      
      This has the desired/intended side effect of making sure that
      "console enabled:" messages are printed on the bootconsole, and
      the real console. This does cause the same line is printed
      twice if the bootconsole and real console are the same device,
      but if they are on different devices, the message is printed to
      both consoles.
      
      Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      LKML-Reference: <200907091308.37370.rgetz@blackfin.uclinux.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      8259cf43
  2. 03 Jul, 2009 1 commit
    • Robin Getz's avatar
      printk: Enable the use of more than one CON_BOOT (early console) · 4d091611
      Robin Getz authored
      Today, register_console() assumes the following usage:
      
        - The first console to register with a flag set to CON_BOOT
          is the one and only bootconsole.
      
        - If another register_console() is called with an additional
          CON_BOOT, it is silently rejected.
      
        - As soon as a console without the CON_BOOT set calls
          registers the bootconsole is automatically unregistered.
      
        - Once there is a "real" console - register_console() will
          silently reject any consoles with it's CON_BOOT flag set.
      
      In many systems (alpha, blackfin, microblaze, mips, powerpc,
      sh, & x86), there are early_printk implementations, which use
      the CON_BOOT which come out serial ports, vga, usb, & memory
      buffers.
      
      In many embedded systems, it would be nice to have two
      bootconsoles - in case the primary fails, you always have
      access to a backup memory buffer - but this requires at least
      two CON_BOOT consoles...
      
      This patch enables that functionality.
      
      With the change applied, on boot you get (if you try to
      re-enable a boot console after the "real" console has been
      registered):
      
        root:/> dmesg | grep console
        bootconsole [early_shadow0] enabled
        bootconsole [early_BFuart0] enabled
        Kernel command line: root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600 console=ttyBF0,57600 nmi_debug=regs
        console handover:boot [early_BFuart0] boot [early_shadow0]  -> real [ttyBF0]
        Too late to register bootconsole early_shadow0
      
      or:
      
        root:/> dmesg | grep console
        Kernel command line: root=/dev/mtdblock0 rw console=ttyBF0,57600
        console [ttyBF0] enabled
      Signed-off-by: default avatarRobin Getz <rgetz@blackfin.uclinux.org>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      Cc: "Andrew Morton" <akpm@linux-foundation.org>
      Cc: "Mike Frysinger" <vapier.adi@gmail.com>
      Cc: "Paul Mundt" <lethal@linux-sh.org>
      LKML-Reference: <200907012108.38030.rgetz@blackfin.uclinux.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4d091611
  3. 02 Jul, 2009 4 commits
    • Yinghai Lu's avatar
      x86: add boundary check for 32bit res before expand e820 resource to alignment · 7c5371c4
      Yinghai Lu authored
      fix hang with HIGHMEM_64G and 32bit resource.  According to hpa and
      Linus, use (resource_size_t)-1 to fend off big ranges.
      
      Analyzed by hpa
      Reported-and-tested-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7c5371c4
    • Linus Torvalds's avatar
      x86: fix power-of-2 round_up/round_down macros · 43644679
      Linus Torvalds authored
      These macros had two bugs:
       - the type of the mask was not correctly expanded to the full size of
         the argument being expanded, resulting in possible loss of high bits
         when mixing types.
       - the alignment argument was evaluated twice, despite the macro looking
         like a fancy function (but it really does need to be a macro, since
         it works on arbitrary integer types)
      
      Noticed by Peter Anvin, and with a fix that is a modification of his
      suggestion (bug noticed by Yinghai Lu).
      
      Cc: Peter Anvin <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      43644679
    • David Howells's avatar
      FRV: Add basic performance counter support · 42ca4fb6
      David Howells authored
      Add basic performance counter support to the FRV arch.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      42ca4fb6
    • David Howells's avatar
      FRV: Implement atomic64_t · 00460f41
      David Howells authored
      Implement atomic64_t and its ops for FRV.  Tested with the following patch:
      
      	diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
      	index 55e4fab..086d50d 100644
      	--- a/arch/frv/kernel/setup.c
      	+++ b/arch/frv/kernel/setup.c
      	@@ -746,6 +746,52 @@ static void __init parse_cmdline_early(char *cmdline)
      
      	 } /* end parse_cmdline_early() */
      
      	+static atomic64_t xxx;
      	+
      	+static void test_atomic64(void)
      	+{
      	+	atomic64_set(&xxx, 0x12300000023LL);
      	+
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x12300000023LL);
      	+	mb();
      	+	if (atomic64_inc_return(&xxx) != 0x12300000024LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x12300000024LL);
      	+	mb();
      	+	if (atomic64_sub_return(0x36900000050LL, &xxx) != -0x2460000002cLL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != -0x2460000002cLL);
      	+	mb();
      	+	if (atomic64_dec_return(&xxx) != -0x2460000002dLL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != -0x2460000002dLL);
      	+	mb();
      	+	if (atomic64_add_return(0x36800000001LL, &xxx) != 0x121ffffffd4LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x121ffffffd4LL);
      	+	mb();
      	+	if (atomic64_cmpxchg(&xxx, 0x123456789abcdefLL, 0x121ffffffd4LL) != 0x121ffffffd4LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x121ffffffd4LL);
      	+	mb();
      	+	if (atomic64_cmpxchg(&xxx, 0x121ffffffd4LL, 0x123456789abcdefLL) != 0x121ffffffd4LL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0x123456789abcdefLL);
      	+	mb();
      	+	if (atomic64_xchg(&xxx, 0xabcdef123456789LL) != 0x123456789abcdefLL)
      	+		BUG();
      	+	mb();
      	+	BUG_ON(atomic64_read(&xxx) != 0xabcdef123456789LL);
      	+	mb();
      	+}
      	+
      	 /*****************************************************************************/
      	 /*
      	  *
      	@@ -845,6 +891,8 @@ void __init setup_arch(char **cmdline_p)
      	 //	asm volatile("movgs %0,timerd" :: "r"(10000000));
      	 //	__set_HSR(0, __get_HSR(0) | HSR0_ETMD);
      
      	+	test_atomic64();
      	+
      	 } /* end setup_arch() */
      
      	 #if 0
      
      Note that this doesn't cover all the trivial wrappers, but does cover all the
      substantial implementations.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00460f41
  4. 01 Jul, 2009 33 commits