Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 04 11月, 2014 1 次提交
    • T
      ALSA: pcm: Replace PCM hwptr tracking with tracepoints · f5914908
      由 Takashi Iwai 提交于 
      ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs.  But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.

In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own.  Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.

The new "snd_pcm" entry will appear in the tracing events:
  # ls -F /sys/kernel/debug/tracing/events/snd_pcm
  enable  filter  hw_ptr_error/  hwptr/  xrun/

The hwptr is for the regular hwptr update events.  An event trace
looks like:

  aplay-26187 [004] d..3  4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384

"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call.  The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
 offset.  It increments up to the PCM position boundary.)

The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".

The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before.  But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch.  Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.

Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      f5914908
  3. 30 10月, 2014 2 次提交
  5. 29 10月, 2014 1 次提交
  7. 28 10月, 2014 1 次提交
  9. 24 10月, 2014 2 次提交
  11. 21 10月, 2014 7 次提交
  13. 20 10月, 2014 2 次提交
  15. 16 10月, 2014 6 次提交
  17. 15 10月, 2014 3 次提交
  19. 14 10月, 2014 9 次提交
    • A
      lib/vsprintf: add %*pE[achnops] format specifier · 71dca95d
      由 Andy Shevchenko 提交于 
      This allows user to print a given buffer as an escaped string.  The
rules are applied according to an optional mix of flags provided by
additional format letters.

For example, if the given buffer is:

    1b 62 20 5c 43 07 22 90 0d 5d

The result strings would be:
    %*pE            "\eb \C\a"\220\r]"
    %*pEhp          "\x1bb \C\x07"\x90\x0d]"
    %*pEa           "\e\142\040\\\103\a\042\220\r\135"

Please, read Documentation/printk-formats.txt and lib/string_helpers.c
kernel documentation to get further information.

[akpm@linux-foundation.org: tidy up comment layout, per Joe]
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: NJoe Perches <joe@perches.com>
Cc: "John W . Linville" <linville@tuxdriver.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      71dca95d
    • O
      coredump: add %i/%I in core_pattern to report the tid of the crashed thread · b03023ec
      由 Oleg Nesterov 提交于 
      format_corename() can only pass the leader's pid to the core handler,
but there is no simple way to figure out which thread originated the
coredump.

As Jan explains, this also means that there is no simple way to create
the backtrace of the crashed process:

As programs are mostly compiled with implicit gcc -fomit-frame-pointer
one needs program's .eh_frame section (equivalently PT_GNU_EH_FRAME
segment) or .debug_frame section.  .debug_frame usually is present only
in separate debug info files usually not even installed on the system.
While .eh_frame is a part of the executable/library (and it is even
always mapped for C++ exceptions unwinding) it no longer has to be
present anywhere on the disk as the program could be upgraded in the
meantime and the running instance has its executable file already
unlinked from disk.

One possibility is to echo 0x3f >/proc/*/coredump_filter and dump all
the file-backed memory including the executable's .eh_frame section.
But that can create huge core files, for example even due to mmapped
data files.

Other possibility would be to read .eh_frame from /proc/PID/mem at the
core_pattern handler time of the core dump.  For the backtrace one needs
to read the register state first which can be done from core_pattern
handler:

    ptrace(PTRACE_SEIZE, tid, 0, PTRACE_O_TRACEEXIT)
    close(0);    // close pipe fd to resume the sleeping dumper
    waitpid();   // should report EXIT
    PTRACE_GETREGS or other requests

The remaining problem is how to get the 'tid' value of the crashed
thread.  It could be read from the first NT_PRSTATUS note of the core
file but that makes the core_pattern handler complicated.

Unfortunately %t is already used so this patch uses %i/%I.

Automatic Bug Reporting Tool (https://github.com/abrt/abrt/wiki/overview)
is experimenting with this.  It is using the elfutils
(https://fedorahosted.org/elfutils/) unwinder for generating the
backtraces.  Apart from not needing matching executables as mentioned
above, another advantage is that we can get the backtrace without saving
the core (which might be quite large) to disk.

[mmilata@redhat.com: final paragraph of changelog]
Signed-off-by: NJan Kratochvil <jan.kratochvil@redhat.com>
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Mark Wielaard <mjw@redhat.com>
Cc: Martin Milata <mmilata@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b03023ec
    • P
      rtc: bq32000: add trickle charger device tree binding · d5fae669
      由 Pavel Machek 提交于 
      BQ32000 have "trickle chargers".  Introduce a device tree binding for
specifying the trickle charger configuration for that.
Signed-off-by: NPavel Machek <pavel@denx.de>
Reviewed-by: NJason Cooper <jason@lakedameon.net>
Cc: Matti Vaittinen <matti.vaittinen@nsn.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d5fae669
    • M
      Documentation: dt-bindings: trickle charger dt binding document for ds1339 · 2ac848c0
      由 Matti Vaittinen 提交于 
      Some DS13XX devices have "trickle chargers".  Introduce a device tree
binding for the resistor and diode configuration for enabling trickle
charger.
Signed-off-by: NMatti Vaittinen <matti.vaittinen@nsn.com>
Acked-by: NJason Cooper <jason@lakedaemon.net>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Pavel Machek <pavel@denx.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2ac848c0
    • C
      rtc: s3c: add support for RTC of Exynos3250 SoC · df9e26d0
      由 Chanwoo Choi 提交于 
      Add support for RTC of Exynos3250 SoC.  The Exynos3250 needs source
clock(32.768KHz) for RTC block.  If source clock of RTC is registerd on
clock list of common clk framework, Exynos RTC drvier have to control
this clock.

Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
 (XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and
 XRTCXTO pins. RTC uses this clock as the source of a real-time clock.)
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      df9e26d0
    • C
      rtc: s3c: remove warning message when checking coding style with checkpatch script · d67288da
      由 Chanwoo Choi 提交于 
      Remove warning message when checking codeing style with checkpatch script
and reduce un-necessary i2c read operation on s3c_rtc_enable.

    WARNING: line over 80 characters
    #406: FILE: drivers/rtc/rtc-s3c.c:406:
    +		if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN) == 0) {

    WARNING: line over 80 characters
    #414: FILE: drivers/rtc/rtc-s3c.c:414:
    +		if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_CNTSEL)) {

    WARNING: line over 80 characters
    #422: FILE: drivers/rtc/rtc-s3c.c:422:
    +		if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_CLKRST)) {

    WARNING: Missing a blank line after declarations
    #451: FILE: drivers/rtc/rtc-s3c.c:451:
    +	struct s3c_rtc_drv_data *data;
    +	if (pdev->dev.of_node) {

    WARNING: Missing a blank line after declarations
    #453: FILE: drivers/rtc/rtc-s3c.c:453:
    +		const struct of_device_id *match;
    +		match = of_match_node(s3c_rtc_dt_match, pdev->dev.of_node);

    WARNING: DT compatible string "samsung,s3c2416-rtc" appears un-documented -- check ./Documentation/devicetree/bindings/
    #650: FILE: drivers/rtc/rtc-s3c.c:650:
    +		.compatible = "samsung,s3c2416-rtc",

    WARNING: DT compatible string "samsung,s3c2443-rtc" appears un-documented -- check ./Documentation/devicetree/bindings/
    #653: FILE: drivers/rtc/rtc-s3c.c:653:
    +		.compatible = "samsung,s3c2443-rtc",
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d67288da
    • N
      autofs: the documentation I wanted to read · 87d672cb
      由 NeilBrown 提交于 
      This documents autofs from the perspective of what the module actually
supports rather than how automount is expected to use it.

It is formatted using "markdown" and works best with Markdown.pl
(markdown_py doesn't like some constructs).

[rdunlap@infradead.org: copy editing]
Signed-off-by: NNeilBrown <neilb@suse.de>
Cc: Randy Dunlap <rdunlap@infradead.org>
Acked-by: NIan Kent <raven@themaw.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      87d672cb
    • M
      binfmt_misc: touch up documentation a bit · 43bd40e5
      由 Mike Frysinger 提交于 
      Line wrap the content to 80 cols, and add more details to various fields
to match the code.  Drop reference to a website that does not exist
anymore.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      43bd40e5
    • M
      binfmt_misc: expand the register format limit to 1920 bytes · bbaecc08
      由 Mike Frysinger 提交于 
      The current code places a 256 byte limit on the registration format.
This ends up being fairly limited when you try to do matching against a
binary format like ELF:

 - the magic & mask formats cannot have any embedded NUL chars
   (string_unescape_inplace halts at the first NUL)
 - each escape sequence quadruples the size: \x00 is needed for NUL
 - trying to match bytes at the start of the file as well as further
   on leads to a lot of \x00 sequences in the mask
 - magic & mask have to be the same length (when decoded)
 - still need bytes for the other fields
 - impossible!

Let's look at a concrete (and common) example: using QEMU to run MIPS
ELFs.  The name field uses 11 bytes "qemu-mipsel".  The interp uses 20
bytes "/usr/bin/qemu-mipsel".  The type & flags takes up 4 bytes.  We
need 7 bytes for the delimiter (usually ":").  We can skip offset.  So
already we're down to 107 bytes to use with the magic/mask instead of
the real limit of 128 (BINPRM_BUF_SIZE).  If people use shell code to
register (which they do the majority of the time), they're down to ~26
possible bytes since the escape sequence must be \x##.

The ELF format looks like (both 32 & 64 bit):

	e_ident: 16 bytes
	e_type: 2 bytes
	e_machine: 2 bytes

Those 20 bytes are enough for most architectures because they have so few
formats in the first place, thus they can be uniquely identified.  That
also means for shell users, since 20 is smaller than 26, they can sanely
register a handler.

But for some targets (like MIPS), we need to poke further.  The ELF fields
continue on:

	e_entry: 4 or 8 bytes
	e_phoff: 4 or 8 bytes
	e_shoff: 4 or 8 bytes
	e_flags: 4 bytes

We only care about e_flags here as that includes the bits to identify
whether the ELF is O32/N32/N64.  But now we have to consume another 16
bytes (for 32 bit ELFs) or 28 bytes (for 64 bit ELFs) just to match the
flags.  If every byte is escaped, we send 288 more bytes to the kernel
((20 {e_ident,e_type,e_machine} + 12 {e_entry,e_phoff,e_shoff} + 4
{e_flags}) * 2 {mask,magic} * 4 {escape}) and we've clearly blown our
budget.

Even if we try to be clever and do the decoding ourselves (rather than
relying on the kernel to process \x##), we still can't hit the mark --
string_unescape_inplace treats mask & magic as C strings so NUL cannot
be embedded.  That leaves us with having to pass \x00 for the 12/24
entry/phoff/shoff bytes (as those will be completely random addresses),
and that is a minimum requirement of 48/96 bytes for the mask alone.
Add up the rest and we blow through it (this is for 64 bit ELFs):
magic: 20 {e_ident,e_type,e_machine} + 24 {e_entry,e_phoff,e_shoff} +
       4 {e_flags} = 48              # ^^ See note below.
mask: 20 {e_ident,e_type,e_machine} + 96 {e_entry,e_phoff,e_shoff} +
       4 {e_flags} = 120
Remember above we had 107 left over, and now we're at 168.  This is of
course the *best* case scenario -- you'll also want to have NUL bytes
in the magic & mask too to match literal zeros.

Note: the reason we can use 24 in the magic is that we can work off of the
fact that for bytes the mask would clobber, we can stuff any value into
magic that we want.  So when mask is \x00, we don't need the magic to also
be \x00, it can be an unescaped raw byte like '!'.  This lets us handle
more formats (barely) under the current 256 limit, but that's a pretty
tall hoop to force people to jump through.

With all that said, let's bump the limit from 256 bytes to 1920.  This way
we support escaping every byte of the mask & magic field (which is 1024
bytes by themselves -- 128 * 4 * 2), and we leave plenty of room for other
fields.  Like long paths to the interpreter (when you have source in your
/really/long/homedir/qemu/foo).  Since the current code stuffs more than
one structure into the same buffer, we leave a bit of space to easily
round up to 2k.  1920 is just as arbitrary as 256 ;).
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bbaecc08
  21. 13 10月, 2014 1 次提交
    • N
      powerpc/numa: Add ability to disable and debug topology updates · 2d73bae1
      由 Nishanth Aravamudan 提交于 
      We have hit a few customer issues with the topology update code (VPHN
and PRRN). It would be nice to be able to debug the notifications coming
from the hypervisor in both cases to the LPAR, as well as to disable
responding to the notifications at boot-time, to narrow down the source
of the problems. Add a basic level of such functionality, similar to the
numa= command-line parameter. We already have a toggle in
/proc/powerpc/topology_updates that allows run-time enabling/disabling,
so the updates can be started at run-time if desired. But the bugs we've
run into have occured during boot or very shortly after coming to login,
and have resulted in a broken NUMA topology.
Signed-off-by: NNishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      2d73bae1
  23. 12 10月, 2014 1 次提交
    • D
      Input: i8042 - disable active multiplexing by default · 68da1664
      由 Dmitry Torokhov 提交于 
      Active multiplexing is a nice feature as it allows several pointing devices
(such as touchpad and external mouse) use their native protocols at the
same time. Unfortunately many manufacturers do not implement the feature
properly even though they advertise it. The problematic implementations are
never fixed, since Windows by default does not use this mode, and move from
one BIOS/model of laptop to another. When active multiplexing is broken
turning it on usually results in touchpad, keyboard, or both unresponsive.

With PS/2 usage on decline (most of PS/2 devices in use nowadays are
internal laptop touchpads), I expect number of users who have laptops with
working MUX implementation, docking stations with external PS/2 ports, and
who are still using external PS/2 mice, to be rather small. Let's flip the
default to be OFF and allow activating it through i8042.nomux=0 kernel
option.  We'll also keep DMI table where we can record known good models.
Acked-by: NJiri Kosina <jkosina@suse.cz>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      68da1664
  25. 11 10月, 2014 3 次提交
  27. 10 10月, 2014 1 次提交
    • S
      zram: use notify_free to account all free notifications · 015254da
      由 Sergey Senozhatsky 提交于 
      `notify_free' device attribute accounts the number of slot free
notifications and internally represents the number of zram_free_page()
calls.  Slot free notifications are sent only when device is used as a
swap device, hence `notify_free' is used only for swap devices.  Since
f4659d8e (zram: support REQ_DISCARD) ZRAM handles yet another one
free notification (also via zram_free_page() call) -- REQ_DISCARD
requests, which are sent by a filesystem, whenever some data blocks are
discarded.  However, there is no way to know the number of notifications
in the latter case.

Use `notify_free' to account the number of pages freed by
zram_bio_discard() and zram_slot_free_notify().  Depending on usage
scenario `notify_free' represents:

 a) the number of pages freed because of slot free notifications, which is
   equal to the number of swap_slot_free_notify() calls, so there is no
   behaviour change

 b) the number of pages freed because of REQ_DISCARD notifications
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: NMinchan Kim <minchan@kernel.org>
Acked-by: NJerome Marchand <jmarchan@redhat.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Chao Yu <chao2.yu@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      015254da