Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 12月, 2009 1 次提交
    • S
      tracing: Add trace_dump_stack() · 03889384
      由 Steven Rostedt 提交于 
      I've been asked a few times about how to find out what is calling
some location in the kernel. One way is to use dynamic function tracing
and implement the func_stack_trace. But this only finds out who is
calling a particular function. It does not tell you who is calling
that function and entering a specific if conditional.

I have myself implemented a quick version of trace_dump_stack() for
this purpose a few times, and just needed it now. This is when I realized
that this would be a good tool to have in the kernel like trace_printk().

Using trace_dump_stack() is similar to dump_stack() except that it
writes to the trace buffer instead and can be used in critical locations.

For example:

@@ -5485,8 +5485,12 @@ need_resched_nonpreemptible:
 	if (prev->state && !(preempt_count() & PREEMPT_ACTIVE)) {
 		if (unlikely(signal_pending_state(prev->state, prev)))
 			prev->state = TASK_RUNNING;
-		else
+		else {
 			deactivate_task(rq, prev, 1);
+			trace_printk("Deactivating task %s:%d\n",
+				     prev->comm, prev->pid);
+			trace_dump_stack();
+		}
 		switch_count = &prev->nvcsw;
 	}

Produces:

           <...>-3249  [001]   296.105269: schedule: Deactivating task ntpd:3249
           <...>-3249  [001]   296.105270: <stack trace>
 => schedule
 => schedule_hrtimeout_range
 => poll_schedule_timeout
 => do_select
 => core_sys_select
 => sys_select
 => system_call_fastpath
Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      03889384
  3. 23 10月, 2009 1 次提交
    • C
      ratelimit: Make suppressed output messages more useful · 5c828713
      由 Christian Borntraeger 提交于 
      Today I got:

  [39648.224782] Registered led device: iwl-phy0::TX
  [40676.545099] __ratelimit: 246 callbacks suppressed
  [40676.545103] abcdef[23675]: segfault at 0 ...

as you can see the ratelimit message contains a function prefix.
Since this is always __ratelimit, this wont help much.

This patch changes __ratelimit and printk_ratelimit to print the
function name that calls ratelimit.

This will pinpoint the responsible function, as long as not several
different places call ratelimit with the same ratelimit state at
the same time. In that case we catch only one random function that
calls ratelimit after the wait period.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
CC: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <200910231458.11832.borntraeger@de.ibm.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5c828713
  5. 12 10月, 2009 1 次提交
  7. 23 9月, 2009 4 次提交
  9. 22 9月, 2009 1 次提交
    • I
      printk: Remove ratelimit.h from kernel.h · 3fff4c42
      由 Ingo Molnar 提交于 
      Decouple kernel.h from ratelimit.h: the global declaration of
printk's ratelimit_state is not needed, and it leads to messy
circular dependencies due to ratelimit.h's (new) adding of a
spinlock_types.h include.

Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David S. Miller <davem@davemloft.net>
LKML-Reference: <new-submission>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3fff4c42
  11. 18 7月, 2009 2 次提交
  13. 26 6月, 2009 1 次提交
    • K
      x86: Add sysctl to allow panic on IOCK NMI error · 5211a242
      由 Kurt Garloff 提交于 
      This patch introduces a new sysctl:

    /proc/sys/kernel/panic_on_io_nmi

which defaults to 0 (off).

When enabled, the kernel panics when the kernel receives an NMI
caused by an IO error.

The IO error triggered NMI indicates a serious system
condition, which could result in IO data corruption. Rather
than contiuing, panicing and dumping might be a better choice,
so one can figure out what's causing the IO error.

This could be especially important to companies running IO
intensive applications where corruption must be avoided, e.g. a
bank's databases.

[ SuSE has been shipping it for a while, it was done at the
  request of a large database vendor, for their users. ]
Signed-off-by: NKurt Garloff <garloff@suse.de>
Signed-off-by: NRoberto Angelino <robertangelino@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
LKML-Reference: <20090624213211.GA11291@kroah.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5211a242
  15. 19 6月, 2009 1 次提交
  17. 17 6月, 2009 2 次提交
    • L
      printk: Add KERN_DEFAULT printk log-level · e28d7137
      由 Linus Torvalds 提交于 
      This adds a KERN_DEFAULT loglevel marker, for when you cannot decide
which loglevel you want, and just want to keep an existing printk
with the default loglevel.

The difference between having KERN_DEFAULT and having no log-level
marker at all is two-fold:

 - having the log-level marker will now force a new-line if the
   previous printout had not added one (perhaps because it forgot,
   but perhaps because it expected a continuation)

 - having a log-level marker is required if you are printing out a
   message that otherwise itself could perhaps otherwise be mistaken
   for a log-level.
Signed-of-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e28d7137
    • L
      printk: clean up handling of log-levels and newlines · 5fd29d6c
      由 Linus Torvalds 提交于 
      It used to be that we would only look at the log-level in a printk()
after explicit newlines, which can cause annoying problems when the
previous printk() did not end with a '\n'. In that case, the log-level
marker would be just printed out in the middle of the line, and be
seen as just noise rather than change the logging level.

This changes things to always look at the log-level in the first
bytes of the printout. If a log level marker is found, it is always
used as the log-level. Additionally, if no newline existed, one is
added (unless the log-level is the explicit KERN_CONT marker, to
explicitly show that it's a continuation of a previous line).
Acked-by: NArjan van de Ven <arjan@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5fd29d6c
  19. 16 6月, 2009 1 次提交
    • G
      debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem. · 156f5a78
      由 GeunSik Lim 提交于 
      Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
directory name to mount debugfs filesystem for ftrace according to
./Documentation/tracers/ftrace.txt file.

And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
existed in kernel source like ftrace, DRM, Wireless, Documentation,
Network[sky2]files to mount debugfs filesystem.

debugfs means debug filesystem for debugging easy to use by greg kroah
hartman. "/sys/kernel/debug/" name is suitable as directory name
of debugfs filesystem.
- debugfs related reference: http://lwn.net/Articles/334546/

Fix inconsistency of directory name to mount debugfs filesystem.

* From Steven Rostedt
  - find_debugfs() and tracing_files() in this patch.
Signed-off-by: NGeunSik Lim <geunsik.lim@samsung.com>
Acked-by     : Inaky Perez-Gonzalez <inaky@linux.intel.com>
Reviewed-by  : Steven Rostedt <rostedt@goodmis.org>
Reviewed-by  : James Smart <james.smart@emulex.com>
CC: Jiri Kosina <trivial@kernel.org>
CC: David Airlie <airlied@linux.ie>
CC: Peter Osterlund <petero2@telia.com>
CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
CC: Masami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      156f5a78
  21. 17 4月, 2009 1 次提交
  23. 03 4月, 2009 1 次提交
  25. 01 4月, 2009 1 次提交
  27. 29 3月, 2009 1 次提交
  29. 25 3月, 2009 2 次提交
  31. 13 3月, 2009 1 次提交
    • F
      tracing/core: bring back raw trace_printk for dynamic formats strings · 48ead020
      由 Frederic Weisbecker 提交于 
      Impact: fix callsites with dynamic format strings

Since its new binary implementation, trace_printk() internally uses static
containers for the format strings on each callsites. But the value is
assigned once at build time, which means that it can't take dynamic
formats.

So this patch unearthes the raw trace_printk implementation for the callers
that will need trace_printk to be able to carry these dynamic format
strings. The trace_printk() macro will use the appropriate implementation
for each callsite. Most of the time however, the binary implementation will
still be used.

The other impact of this patch is that mmiotrace_printk() will use the old
implementation because it calls the low level trace_vprintk and we can't
guess here whether the format passed in it is dynamic or not.

Some parts of this patch have been written by Steven Rostedt (most notably
the part that chooses the appropriate implementation for each callsites).
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      48ead020
  33. 09 3月, 2009 1 次提交
    • I
      tracing: optimize trace_printk() · 7bffc23e
      由 Ingo Molnar 提交于 
      Impact: micro-optimization

trace_printk() does this unconditionally:

	trace_printk_fmt = fmt;

Where trace_printk_fmt is an entry into a global array. This is
very SMP-unfriendly.

So only write it once per bootup.

Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <1236356510-8381-5-git-send-email-fweisbec@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7bffc23e
  35. 07 3月, 2009 1 次提交
    • F
      tracing/core: drop the old trace_printk() implementation in favour of trace_bprintk() · 769b0441
      由 Frederic Weisbecker 提交于 
      Impact: faster and lighter tracing

Now that we have trace_bprintk() which is faster and consume lesser
memory than trace_printk() and has the same purpose, we can now drop
the old implementation in favour of the binary one from trace_bprintk(),
which means we move all the implementation of trace_bprintk() to
trace_printk(), so the Api doesn't change except that we must now use
trace_seq_bprintk() to print the TRACE_PRINT entries.

Some changes result of this:

- Previously, trace_bprintk depended of a single tracer and couldn't
  work without. This tracer has been dropped and the whole implementation
  of trace_printk() (like the module formats management) is now integrated
  in the tracing core (comes with CONFIG_TRACING), though we keep the file
  trace_printk (previously trace_bprintk.c) where we can find the module
  management. Thus we don't overflow trace.c

- changes some parts to use trace_seq_bprintk() to print TRACE_PRINT entries.

- change a bit trace_printk/trace_vprintk macros to support non-builtin formats
  constants, and fix 'const' qualifiers warnings. But this is all transparent for
  developers.

- etc...

V2:

- Rebase against last changes
- Fix mispell on the changelog

V3:

- Rebase against last changes (moving trace_printk() to kernel.h)
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
LKML-Reference: <1236356510-8381-5-git-send-email-fweisbec@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      769b0441
  37. 05 3月, 2009 2 次提交
    • S
      tracing: add tracing_on/tracing_off to kernel.h · 2002c258
      由 Steven Rostedt 提交于 
      Impact: cleanup

The functions tracing_start/tracing_stop have been moved to kernel.h.
These are not the functions a developer most likely wants to use
when they want to insert a place to stop tracing and restart it from
user space.

tracing_start/tracing_stop was created to work with things like
suspend to ram, where even calling smp_processor_id() can crash the
system. The tracing_start/tracing_stop was used to stop the tracer from
doing anything. These are still light weight functions, but add a bit
more overhead to be able to stop the tracers. They also have no interface
back to userland. That is, if the kernel calls tracing_stop, userland
can not start tracing.

What a developer most likely wants to use is tracing_on/tracing_off.
These are very light weight functions (simply sets or clears a bit).
These functions just stop recording into the ring buffer. The tracers
don't even know that this happens except that they would receive NULL
from the ring_buffer_lock_reserve function.

Also, there's a way for the user land to enable or disable this bit.
In debugfs/tracing/tracing_on, a user may echo "0" (same as tracing_off())
or echo "1" (same as tracing_on()) into this file. This becomes handy when
a kernel developer is debugging and wants tracing to turn off when it
hits an anomaly. Then the developer can examine the trace, and restart
tracing if they want to try again (echo 1 > tracing_on).

This patch moves the prototypes for tracing_on/tracing_off to kernel.h
and comments their use, so that a kernel developer will know how
to use them.
Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      2002c258
    • I
      tracing: move utility functions from ftrace.h to kernel.h · 526211bc
      由 Ingo Molnar 提交于 
      Make common utility functions such as trace_printk() and
tracing_start()/tracing_stop() generally available to kernel
code.

Cc: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      526211bc
  39. 06 2月, 2009 1 次提交
  41. 05 2月, 2009 1 次提交
    • I
      printk: introduce printk_once() · f036be96
      由 Ingo Molnar 提交于 
      This pattern shows up frequently in the kernel:

  static int once = 1;
  ...

		if (once) {
			once = 0;
			printk(KERN_ERR "message\n");
		}
  ...

So add a printk_once() helper macro that reduces this to a single line
of:

		printk_once(KERN_ERR "message\n");

It works analogously to WARN_ONCE() & friends. (We use a macro not
an inline because vararg expansion in inlines looks awkward and the
macro is simple enough.)
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f036be96
  43. 09 1月, 2009 1 次提交
  45. 07 1月, 2009 2 次提交
  47. 16 11月, 2008 1 次提交
  49. 31 10月, 2008 1 次提交
  51. 29 10月, 2008 1 次提交
  53. 17 10月, 2008 2 次提交
    • A
      Make the taint flags reliable · 25ddbb18
      由 Andi Kleen 提交于 
      It's somewhat unlikely that it happens, but right now a race window
between interrupts or machine checks or oopses could corrupt the tainted
bitmap because it is modified in a non atomic fashion.

Convert the taint variable to an unsigned long and use only atomic bit
operations on it.

Unfortunately this means the intvec sysctl functions cannot be used on it
anymore.

It turned out the taint sysctl handler could actually be simplified a bit
(since it only increases capabilities) so this patch actually removes
code.

[akpm@linux-foundation.org: remove unneeded include]
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      25ddbb18
    • J
      driver core: basic infrastructure for per-module dynamic debug messages · 346e15be
      由 Jason Baron 提交于 
      Base infrastructure to enable per-module debug messages.

I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
control of debugging statements on a per-module basis in one /proc file,
currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
is not set, debugging statements can still be enabled as before, often by
defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.

The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
can be dynamically enabled/disabled on a per-module basis.

Future plans include extending this functionality to subsystems, that define 
their own debug levels and flags.

Usage:

Dynamic debugging is controlled by the debugfs file, 
<debugfs>/dynamic_printk/modules. This file contains a list of the modules that
can be enabled. The format of the file is as follows:

	<module_name> <enabled=0/1>
		.
		.
		.

	<module_name> : Name of the module in which the debug call resides
	<enabled=0/1> : whether the messages are enabled or not

For example:

	snd_hda_intel enabled=0
	fixup enabled=1
	driver enabled=0

Enable a module:

	$echo "set enabled=1 <module_name>" > dynamic_printk/modules

Disable a module:

	$echo "set enabled=0 <module_name>" > dynamic_printk/modules

Enable all modules:

	$echo "set enabled=1 all" > dynamic_printk/modules

Disable all modules:

	$echo "set enabled=0 all" > dynamic_printk/modules

Finally, passing "dynamic_printk" at the command line enables
debugging for all modules. This mode can be turned off via the above
disable command.

[gkh: minor cleanups and tweaks to make the build work quietly]
Signed-off-by: NJason Baron <jbaron@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      346e15be
  55. 14 10月, 2008 1 次提交
  57. 12 10月, 2008 1 次提交
  59. 11 10月, 2008 1 次提交
    • G
      Staging: add TAINT_CRAP for all drivers/staging code · 061b1bd3
      由 Greg Kroah-Hartman 提交于 
      We need to add a flag for all code that is in the drivers/staging/
directory to prevent all other kernel developers from worrying about
issues here, and to notify users that the drivers might not be as good
as they are normally used to.

Based on code from Andreas Gruenbacher and Jeff Mahoney to provide a
TAINT flag for the support level of a kernel module in the Novell
enterprise kernel release.

This is the kernel portion of this feature, the ability for the flag to
be set needs to be done in the build process and will happen in a
follow-up patch.

Cc: Andreas Gruenbacher <agruen@suse.de>
Cc: Jeff Mahoney <jeffm@suse.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      061b1bd3
  61. 23 9月, 2008 1 次提交
    • T
      Introduce FW_BUG, FW_WARN and FW_INFO to consistenly tell users about BIOS bugs · a0ad05c7
      由 Thomas Renninger 提交于 
      The idea is to add this to printk after the severity:
printk(KERN_ERR FW_BUG "This is not our fault, BIOS developer: fix it by
simply add ...\n");

If a Firmware issue should be hidden, because it is
work-arounded, but you still want to see something popping up e.g.
for info only:
printk(KERN_INFO FW_INFO "This is done stupid, we can handle it,
but it should better be avoided in future\n");

or on the Linuxfirmwarekit to tell vendors that they did something
stupid or wrong without bothering the user:
printk(KERN_INFO FW_BUG "This is done stupid, we can handle it,
but it should better be avoided in future\n");

Some use cases:
  - If a user sees a [Firmware Bug] message in the kernel
    he should first update the BIOS before wasting time with
    debugging and submiting on old firmware code to mailing
    lists.

  - The linuxfirmwarekit (http://www.linuxfirmwarekit.org)
    tries to detect firmware bugs. It currently is doing that
    in userspace which results in:
        - Huge test scripts that could be a one liner in the kernel
        - A lot of BIOS bugs are already absorbed by the kernel

What do we need such a stupid linuxfirmwarekit for?

  - Vendors: Can test their BIOSes for Linux compatibility.
    There will be the time when vendors realize that the test utils
    on Linux are more strict and using them increases the qualitity
    and stability of their products.

  - Vendors: Can easily fix up their BIOSes and be more Linux
    compatible by:
    dmesg |grep "Firmware Bug"
    and send the result to their BIOS developer colleagues who should
    know what the messages are about and how to fix them, without
    the need of studying kernel code.

  - Distributions: can do a first automated HW/BIOS checks.
    This can then be done without the need of asking kernel developers
    who need to dig down the code and explain the details.
    Certification can/will just be rejected until
    dmesg |grep "Firmware Bug" is empty.

  - Thus this can be used as an instrument to enforce cleaner BIOS
    code. Currently every stupid Windows ACPI bug is
    re-implemented in Linux which is a rather unfortunate situation.
    We already have the power to avoid this in e.g. memory
    or cpu hot-plug ACPI implementations, because Linux certification
    is a must for most vendors in the server area.
    Working towards being able to do that in the laptop area
    (vendors are starting to look at Linux here also and will use this tool)
    is the goal. At least provide them a tool to make it as easy
    for this guys (e.g. not needing to browse kernel code) as possible.

  - The ordinary Linux user: can go into the next shop, boots the
    firmwarekit on his most preferred machines. He chooses one without
    BIOS bugs. Unsupported HW is ok, he likes to try out latest projects
    which might support them or likes to dig on it on his own, but he
    hates to workaround broken BIOSes like hell.

I double checked with the firmwarekit.
There they have:
So the mapping generally is (also depending on how likely the BIOS is
to blame, this could sometimes be difficult):
FW_INFO  = INFO
FW_WARN  = WARN
FW_BUG   = FAIL

For more info about the linuxfirmwarekit and why this is needed
can be found here:
http://www.linuxfirmwarekit.org

While severity matches with the firmwarekit, it might be tricky
to hide messages from the user.
E.g. we recently found out that on HP BIOSes negative temperatures
are returned, which seem to indicate that the thermal zone is
invalid.
We can work around that gracefully by ignoring the thermal zone
and we do not want to bother the ordinary user with a frightening
message: Firmware Bug: thermal management absolutely broken
but want to hide it from the user.

But in the linuxfirmwarekit this should be shown as a real
show stopper (the temperatures could really be wrong,
broken thermal management is one of the worst things
that can happen and the BIOS guys of the machine must
implement this properly).

It is intended to do that (hide it from the user with
KERN_INFO msg, but still print it as a BIOS bug) by:
printk(KERN_INFO FW_BUG "Negativ temperature values detected.
Try to workarounded, BIOS must get fixed\n");
Hope that works out..., no idea how to better hide it
as printk is the only way to easily provide this functionality.
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      a0ad05c7