1. 11 Feb, 2007 1 commit
  2. 22 Dec, 2006 1 commit
  3. 07 Dec, 2006 3 commits
  4. 03 Nov, 2006 1 commit
    • Andrew Morton's avatar
      [PATCH] Add printk_timed_ratelimit() · f46c4833
      Andrew Morton authored
      
      
      printk_ratelimit() has global state which makes it not useful for callers
      which wish to perform ratelimiting at a particular frequency.
      
      Add a printk_timed_ratelimit() which utilises caller-provided state storage to
      permit more flexibility.
      
      This function can in fact be used for things other than printk ratelimiting
      and is perhaps poorly named.
      
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f46c4833
  5. 11 Oct, 2006 1 commit
    • Ingo Molnar's avatar
      [PATCH] lockdep: fix printk recursion logic · 256a6b41
      Ingo Molnar authored
      
      
      Bug reported and fixed by Tilman Schmidt <tilman@imap.cc>: if lockdep is
      enabled then log messages make it to /var/log/messages belatedly.  The
      reason is a missed wakeup of klogd.
      
      Initially there was only a lockdep_internal() protection against lockdep
      recursion within vprintk() - it grew the 'outer' lockdep_off()/on()
      protection only later on.  But that lockdep_off() made the
      release_console_sem() within vprintk() always happen under the
      lockdep_internal() condition, causing the bug.
      
      The right solution to remove the inner protection against recursion here -
      the outer one is enough.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      256a6b41
  6. 26 Sep, 2006 1 commit
  7. 06 Aug, 2006 1 commit
    • Antonino A. Daplas's avatar
      [PATCH] vt: printk: Fix framebuffer console triggering might_sleep assertion · 78944e54
      Antonino A. Daplas authored
      
      
      Reported by: Dave Jones
      
      Whilst printk'ing to both console and serial console, I got this...
      (2.6.18rc1)
      
      BUG: sleeping function called from invalid context at kernel/sched.c:4438
      in_atomic():0, irqs_disabled():1
      
      Call Trace:
       [<ffffffff80271db8>] show_trace+0xaa/0x23d
       [<ffffffff80271f60>] dump_stack+0x15/0x17
       [<ffffffff8020b9f8>] __might_sleep+0xb2/0xb4
       [<ffffffff8029232e>] __cond_resched+0x15/0x55
       [<ffffffff80267eb8>] cond_resched+0x3b/0x42
       [<ffffffff80268c64>] console_conditional_schedule+0x12/0x14
       [<ffffffff80368159>] fbcon_redraw+0xf6/0x160
       [<ffffffff80369c58>] fbcon_scroll+0x5d9/0xb52
       [<ffffffff803a43c4>] scrup+0x6b/0xd6
       [<ffffffff803a4453>] lf+0x24/0x44
       [<ffffffff803a7ff8>] vt_console_print+0x166/0x23d
       [<ffffffff80295528>] __call_console_drivers+0x65/0x76
       [<ffffffff80295597>] _call_console_drivers+0x5e/0x62
       [<ffffffff80217e3f>] release_console_sem+0x14b/0x232
       [<ffffffff8036acd6>] fb_flashcursor+0x279/0x2a6
       [<ffffffff80251e3f>] run_workqueue+0xa8/0xfb
       [<ffffffff8024e5e0>] worker_thread+0xef/0x122
       [<ffffffff8023660f>] kthread+0x100/0x136
       [<ffffffff8026419e>] child_rip+0x8/0x12
      
      This can occur when release_console_sem() is called but the log
      buffer still has contents that need to be flushed. The console drivers
      are called while the console_may_schedule flag is still true. The
      might_sleep() is triggered when fbcon calls console_conditional_schedule().
      
      Fix by setting console_may_schedule to zero earlier, before the call to the
      console drivers.
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      78944e54
  8. 10 Jul, 2006 1 commit
  9. 03 Jul, 2006 2 commits
  10. 30 Jun, 2006 1 commit
  11. 25 Jun, 2006 2 commits
    • Jan Engelhardt's avatar
      [PATCH] printk time parameter · 3b9c0410
      Jan Engelhardt authored
      
      
      Currently, enabling/disabling printk timestamps is only possible through
      reboot (bootparam) or recompile.  I normally do not run with timestamps
      (since syslog handles that in a good manner), but for measuring small
      kernel delays (e.g.  irq probing - see parport thread) I needed subsecond
      precision, but then again, just for some minutes rather than all kernel
      messages to come.  The following patch adds a module_param() with which the
      timestamps can be en-/disabled in a live system through
      /sys/modules/printk/parameters/printk_time.
      Signed-off-by: default avatarJan Engelhardt <jengelh@gmx.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3b9c0410
    • Michael Ellerman's avatar
      [PATCH] Make printk work for really early debugging · 76a8ad29
      Michael Ellerman authored
      
      
      Currently printk is no use for early debugging because it refuses to
      actually print anything to the console unless
      cpu_online(smp_processor_id()) is true.
      
      The stated explanation is that console drivers may require per-cpu
      resources, or otherwise barf, because the system is not yet setup
      correctly.  Fair enough.
      
      However some console drivers might be quite happy running early during
      boot, in fact we have one, and so it'd be nice if printk understood that.
      
      So I added a flag (which I would have called CON_BOOT, but that's taken)
      called CON_ANYTIME, which indicates that a console is happy to be called
      anytime, even if the cpu is not yet online.
      
      Tested on a Power 5 machine, with both a CON_ANYTIME driver and a bogus
      console driver that BUG()s if called while offline.  No problems AFAICT.
      Built for i386 UP & SMP.
      Signed-off-by: default avatarMichael Ellerman <michael@ellerman.id.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      76a8ad29
  12. 20 Jun, 2006 1 commit
  13. 31 Mar, 2006 1 commit
  14. 24 Mar, 2006 1 commit
    • John Z. Bohach's avatar
      [PATCH] console_setup() depends (wrongly?) on CONFIG_PRINTK · 2ea1c539
      John Z. Bohach authored
      
      
      It appears that console_setup() code only gets compiled into the kernel if
      CONFIG_PRINTK is enabled.  One detrimental side-effect of this is that
      serial8250_console_setup() never gets invoked when CONFIG_PRINTK is not
      set, resulting in baud rate not being read/parsed from command line (i.e.
      console=ttyS0,115200n8 is ignored, at least the baud rate part...)
      
      Attached patch moves console_setup() code from inside
      
      #ifdef CONFIG_PRINTK
      
      to outside (in printk.c), removing dependence on said config. option.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2ea1c539
  15. 16 Jan, 2006 1 commit
  16. 15 Jan, 2006 1 commit
  17. 09 Jan, 2006 1 commit
  18. 24 Nov, 2005 1 commit
  19. 14 Nov, 2005 1 commit
  20. 07 Nov, 2005 1 commit
  21. 31 Oct, 2005 1 commit
  22. 21 Sep, 2005 1 commit
    • Andrew Morton's avatar
      [PATCH] Add printk_clock() · 31f6d9d6
      Andrew Morton authored
      
      
      ia64's sched_clock() accesses per-cpu data which isn't set up at boot time.
      Hence ia64 cannot use printk timestamping, because printk() will crash in
      sched_clock().
      
      So make printk() use printk_clock(), defaulting to sched_clock(), overrideable
      by the architecture via attribute(weak).
      
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      31f6d9d6
  23. 07 Sep, 2005 1 commit
  24. 25 Jun, 2005 1 commit
    • Shaohua Li's avatar
      [PATCH] CPU hotplug printk fix · ac255752
      Shaohua Li authored
      
      
      In the cpu hotplug case, per-cpu data possibly isn't initialized even the
      system state is 'running'.  As the comments say in the original code, some
      console drivers assume per-cpu resources have been allocated.  radeon fb is
      one such driver, which uses kmalloc.  After a CPU is down, the per-cpu data
      of slab is freed, so the system crashed when printing some info.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ac255752
  25. 23 Jun, 2005 1 commit
    • Greg Edwards's avatar
      [PATCH] CON_CONSDEV bit not set correctly on last console · ab4af03a
      Greg Edwards authored
      
      
      According to include/linux/console.h, CON_CONSDEV flag should be set on
      the last console specified on the boot command line:
      
           86 #define CON_PRINTBUFFER (1)
           87 #define CON_CONSDEV     (2) /* Last on the command line */
           88 #define CON_ENABLED     (4)
           89 #define CON_BOOT        (8)
      
      This does not currently happen if there is more than one console specified
      on the boot commandline.  Instead, it gets set on the first console on the
      command line.  This can cause problems for things like kdb that look for
      the CON_CONSDEV flag to see if the console is valid.
      
      Additionaly, it doesn't look like CON_CONSDEV is reassigned to the next
      preferred console at unregister time if the console being unregistered
      currently has that bit set.
      
      Example (from sn2 ia64):
      
      elilo vmlinuz root=<dev> console=ttyS0 console=ttySG0
      
      in this case, the flags on ttySG console struct will be 0x4 (should be
      0x6).
      
      Attached patch against bk fixes both issues for the cases I looked at.  It
      uses selected_console (which gets incremented for each console specified on
      the command line) as the indicator of which console to set CON_CONSDEV on.
      When adding the console to the list, if the previous one had CON_CONSDEV
      set, it masks it out.  Tested on ia64 and x86.
      
      The problem with the current behavior is it breaks overriding the default from
      the boot line.  In the ia64 case, there may be a global append line defining
      console=a in elilo.conf.  Then you want to boot your kernel, and want to
      override the default by passing console=b on the boot line.  elilo constructs
      the kernel cmdline by starting with the value of the global append line, then
      tacks on whatever else you specify, which puts console=b last.
      Signed-off-by: default avatarGreg Edwards <edwardsg@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      ab4af03a
  26. 17 May, 2005 1 commit
  27. 01 May, 2005 1 commit
  28. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4