headers
Mathieu Desnoyers | 10 Feb 01:51

[RELEASE] LTTng 2.0 prerelease bundle 20120209

LTTng, the Linux Trace Toolkit Next Generation, is a highly efficient
full system tracing solution toolchain. It is composed of several
components to allow tracing of the kernel, of userspace, trace viewing
and analysis and trace streaming. LTTng is open source software.

You can get a the current release "bundle" (recommanded set of packages)
at the following URL:

http://lttng.org/bundles/

Project website: http://lttng.org
Download link: http://lttng.org/lttng2.0
(please refer to the README files for installation instructions and
lttng-tools doc/quickstart.txt for usage information)

Key Features:

- LTTng 2.0 kernel modules build against a vanilla or distribution
  kernel, without need for additional patches,
- Tracepoints, detailed syscall tracing (fast strace replacement),
  CPU Performance Monitoring Unit (PMU) counters, dynamic address/symbol
  probing (kprobes) and function call/return tracing (kretprobes support),
- Have the ability to attach "context" information to events in the
  trace (e.g. any PMU counter, pid, ppid, tid, comm name, etc).
  All the extra information fields to be collected with events are
  optional, specified on a per-tracing-session basis (except for
  timestamp and event id, which are mandatory).
- Allows non-root users part of the "tracing" group to perform kernel
  and userspace tracing.
- Allows multiple tracing sessions to be active concurrently, each with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linus Walleij | 10 Feb 01:47
Favicon

[PATCH] pinctrl: changes hog mechanism to be self-referential

Instead of a specific boolean field to indicate if a map entry shall
be hogged, treat self-reference as an indication of desired hogging.
This drops one field off the map struct and has a nice Douglas R.
Hofstadter-feel to it.

Suggested-by: Stephen Warren <swarren <at> nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij <at> linaro.org>
---
 Documentation/pinctrl.txt       |    8 ++++----
 drivers/pinctrl/core.c          |    6 ++----
 include/linux/pinctrl/machine.h |   18 ++++++------------
 3 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 2e71323..acb9078 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -989,21 +989,21 @@ is registered. This means that the core will attempt to call pinctrl_get() and
 pinctrl_enable() on it immediately after the pin control device has been
 registered.

-This is enabled by simply setting the .hog_on_boot field in the map to true,
-like this:
+This is enabled by simply setting the .dev_name field in the map to the name
+of the pin controller itself, like this:

 {
 	.name = "POWERMAP"
 	.ctrl_dev_name = "pinctrl-foo",
 	.function = "power_func",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lima Union | 10 Feb 01:41
Picon
Gravatar

OOPS: report for 3.2.5

Dear LKML: AFAIK this is the best place to report this kind of
problems. I don't know if my kernel is considered to be tainted or not
(vbox drivers?, sorry in advance if this is the case) but it may help
you to narrow some already known (or not) problem.

I've included all the requested information from 'reporting-bugs', let
me know if something else is required by e-mail (* I'm not subscribed
to the ML *).
Yours truly, a long time Linux lover.

[1.] One line summary of the problem:
I just got an oops after removing an unmounted Sandisk pendrive.

[2.] Full description of the problem/report:
I'm running Debian testing + GNOME3 (fall-back UI), upon removing a
pendrive I got the oops attached bellow. It wasn't mounted because a
couple of seconds before I issued a 'mount' and it wasn't listed. I
tried to reproduce the problem a couple of times without success.

[3.] Keywords (i.e., modules, networking, kernel):
$ uname -a
Linux debian1 3.2.5 #8 SMP Mon Feb 6 22:15:16 ART 2012 x86_64 GNU/Linux

$ lsmod
Module                  Size  Used by
vboxpci                12409  0
vboxnetadp              4883  0
vboxnetflt             13847  0
vboxdrv              1755604  3 vboxpci,vboxnetadp,vboxnetflt
binfmt_misc             6045  1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larry Finger | 10 Feb 01:31
Favicon

[RFC/RFT] p43pci: Convert driver to use asynchronous firmware loading

Drivers that load firmware from their probe routine have problems with the
latest versions of udev as they get timeouts while waiting for user
space to start. The problem is fixed by using request_firmware_nowait()
and delaying the start of mac80211 until the firmware is loaded.

To prevent the possibility of the driver being unloaded while the firmware
loading callback is still active, a completion queue entry is used.

Signed-off-by: Larry Finger <Larry.Finger <at> lwfinger.net>
---

This conversion of p54pci to use asynchronous firmware loading is based
on the method used in p54usb. As I do not have the hardware, it is only
compile tested. I would appreciate any feedback from people that have the
hardware.

Larry
---

Index: wireless-testing-new/drivers/net/wireless/p54/p54pci.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/p54/p54pci.c
+++ wireless-testing-new/drivers/net/wireless/p54/p54pci.c
@@ -488,6 +488,69 @@ static int p54p_open(struct ieee80211_hw
 	return 0;
 }

+static void p54_start_ops(struct ieee80211_hw *dev)
+{
+	struct p54p_priv *priv = dev->priv;
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stultz | 10 Feb 01:16
Favicon

[PATCH 1/2] [RFC] Range tree implementation

After Andrew suggested something like his mumbletree idea
to better store a list of ranges, I worked on a few different
approaches, and this is what I've finally managed to get working.

I suspect range-tree isn't a totally accurate name, but I
couldn't quite make out the difference between range trees
and interval trees, so I just picked one to call it. Do
let me know if you have a better name.

The idea of storing ranges in a tree is nice, but has a number
of complications. When adding a range, its possible that a
large range will consume and merge a number of smaller ranges.
When removing a range, its possible you may end up splitting an
existing range, causing one range to become two. This makes it
very difficult to provide generic list_head like behavior, as
the parent structures would need to be duplicated and removed,
and that has lots of memory ownership issues.

So, this is a much simplified and more list_head like
implementation. You can add a node to a tree, or remove a node
to a tree, but the generic implementation doesn't do the
merging or splitting for you. But it does provide helpers to
find overlapping and adjacent ranges.

I made the tree self-balancing via splaying as it seemed easier
to handle with the merging/splitting cases I originally tried to
make the generic code handle, but since I've dropped that, I
suspect it can be reworked to use a rbtree. I just wanted to get
this out for initial review.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mauro Carvalho Chehab | 10 Feb 01:00
Picon
Favicon

[PATCH v3 00/31] Hardware Events Report Mecanism (HERM)

This is the third version of HERM patches.

This patch series is targeted on solving some problems found at the
hardware error report mecanisms at the Kernel:

	- MCE events generate processor specific messages. Decoding them
require to know arch-specific, CPU specific information. On some cases,
the same CPU output different things on different CPU stepping;

	- The EDAC core is outdated: it assumes that all drivers talk to
memories via a chip select signal, using one or two channels. Drivers
for modern architectures need to fake data to the EDAC core;

	- There are several error functions for memory errors on EDAC;
its usage is confusing, and some drivers could be providing more information,
but they're limited to the API rigid constraints. For example, single-channel
drivers could be reporting errors to a single DIMM, even on traditional
memory architecture, but the EDAC function call doesn't allow it;

	- When an error event arises on modern x86 processors, an MCE
event is generated. Such error could be enriched by a parsed information,
complemented by some additional data available on non-MCE registers,
generating just one event with the complete (MCE log + parsed info)
event information.

While HERM is meant to be generic, the current focus is to fix the issues
with the memory errors.

This series incorporates a feedback from Boris and Tony with regards to
integrate memory error events with MCE, where supported.
(Continue reading)

Permalink | Reply | 31 comments |
headers
Stephen Rothwell | 10 Feb 00:50
Picon
Picon

linux-next: manual merge of the arm-soc tree with the arm tree

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-at91/at91cap9.c between commit fa23e771d863 ("Merge branch
'fixes' into for-next") from the arm tree and commit 9918ceafd4a9 ("ARM:
at91: code removal of CAP9 SoC") from the arm-soc tree.

The latter removes the file, so I did that.
--

-- 
Cheers,
Stephen Rothwell                    sfr <at> canb.auug.org.au
Permalink | Reply | 1 comment |
headers
Peter De Schrijver | 10 Feb 00:47
Favicon

[PATCH v3 00/10] Add tegra30 support for secondary cores

This patchset introduces support for secondary cores on tegra30. It also
introduces some functions for the flowcontroller and adds basic support for
tegra30 powerdomains.

---

This patchset requires http://www.spinics.net/lists/arm-kernel/msg158016.html
for the cortex A9 erratum #743622 workaround

Changes in v3:

 * split out chip id changes in several patches
 * remove reset handler debugging code
 * remove unused size declartion for reset SRAM code
 * remove workaround for cortex A9 erratum #743622. This will be handled by
   generic code.

Changes in v2:

 * moved chip id reading to fuse.c and cleanup code
 * don't set bit 1 of SB_CTRL on Tegra20
 * removed unused variables in tegra_cpu_reset_handler_init()

Peter De Schrijver (10):
  ARM: tegra: cleanup use of chipid register
  ARM: tegra: export Tegra chipid
  ARM: tegra: initialize Tegra chipid early
  ARM: tegra: functions to access the flowcontroller
  ARM: tegra: rework Tegra secondary CPU core bringup
  ARM: tegra: prepare powergate.c for multiple variants
(Continue reading)

Permalink | Reply | 10 comments |
headers
Linus Torvalds | 10 Feb 00:46
Gravatar

Hmm.. WARN_ON_ONCE(cpuc->enabled)

Ok, so I get the appended on my Core i5 when I did a "perf record -f
-e cycles:pp make -j" on the kernel build.

What's up, guys? I haven't tried that particular perf run in a while,
so it might have been going on for quite some time.

                             Linus

---

 WARNING: at arch/x86/kernel/cpu/perf_event_intel_ds.c:442
intel_pmu_pebs_enable+0x89/0xa0()
 Hardware name: System Product Name
 Pid: 12994, comm: perf Not tainted 3.3.0-rc3-00001-g690d137f448d #34
 Call Trace:
  <IRQ>  [<ffffffff8102f205>] warn_slowpath_common+0x75/0xb0
  [<ffffffff8105c1d4>] ? load_balance+0xc4/0x860
  [<ffffffff8102f305>] warn_slowpath_null+0x15/0x20
  [<ffffffff81013f59>] intel_pmu_pebs_enable+0x89/0xa0
  [<ffffffff81014614>] intel_pmu_enable_event+0xf4/0x190
  [<ffffffff81010f33>] x86_pmu_start+0x83/0x110
  [<ffffffff81098336>] perf_adjust_freq_unthr_context+0x106/0x170
  [<ffffffff810985a0>] perf_event_task_tick+0x200/0x2c0
  [<ffffffff8106a5d0>] ? tick_nohz_handler+0xf0/0xf0
  [<ffffffff81055856>] scheduler_tick+0xc6/0x100
  [<ffffffff8103b649>] update_process_times+0x69/0x80
  [<ffffffff8106a62f>] tick_sched_timer+0x5f/0xb0
  [<ffffffff8104dcd5>] __run_hrtimer.clone.31+0x55/0x110
  [<ffffffff8104e6ff>] hrtimer_interrupt+0xdf/0x210
  [<ffffffff8101c744>] smp_apic_timer_interrupt+0x64/0xa0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Karbiru Ahmed | 10 Feb 00:07
Picon
Gravatar

REPLY URGENTLY

REPLY URGENTLY

Dear Friend,

I'm happy to inform you about my success in getting the fund
transferred under the cooperation of a new partner from london.
Presently I’m in london for investment projects with my own share of
the total sum. Meanwhile, I didn't forget your past efforts and
attempts to assist me in transferring those funds despite that it
failed us some how.

Now contact my secretary, his name is John Smith and his Email Address
secretary email:( johnsimth36 <at> gmail.com )ask him to send you the total
$3,000.000.00 which i kept for your compensation for all the past
efforts and attempts to assist me in this matter. I appreciated your
efforts at that time very much. so feel free and get in touched with
my secretary Mr John Smith and instruct him where to send the amount
to you.

Please do let me know immediately you receive it so that we can share
the joy after all the sufferness at that time. In the moment, i am
very busy here because of the investment projects which me and the new
partner are having at hand, finally, remember that I had forwarded
instruction to the secretary on your behalf to receive that money, so
feel free to get in touch with Mr John Smith and he will send the
amount to you without any delay.

with best regards
Mr Karbiru Ahmed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Don Zickus | 9 Feb 23:42
Picon
Favicon

[PATCH 1/3] watchdog: update documentation

From: Fernando Luis Vázquez Cao <fernando <at> oss.ntt.co.jp>

The soft and hard lockup detectors are now built on top of the hrtimer
and perf subsystems. Update the documentation accordingly.

Signed-off-by: Fernando Luis Vazquez Cao<fernando <at> oss.ntt.co.jp>
Acked-by: Randy Dunlap <rdunlap <at> xenotime.net>
Signed-off-by: Don Zickus <dzickus <at> redhat.com>
---
 Documentation/lockup-watchdogs.txt |   63 +++++++++++++++++++++++++++
 Documentation/nmi_watchdog.txt     |   83 ------------------------------------
 2 files changed, 63 insertions(+), 83 deletions(-)
 create mode 100644 Documentation/lockup-watchdogs.txt
 delete mode 100644 Documentation/nmi_watchdog.txt

diff --git a/Documentation/lockup-watchdogs.txt b/Documentation/lockup-watchdogs.txt
new file mode 100644
index 0000000..d2a3660
--- /dev/null
+++ b/Documentation/lockup-watchdogs.txt
@@ -0,0 +1,63 @@
+===============================================================
+Softlockup detector and hardlockup detector (aka nmi_watchdog)
+===============================================================
+
+The Linux kernel can act as a watchdog to detect both soft and hard
+lockups.
+
+A 'softlockup' is defined as a bug that causes the kernel to loop in
+kernel mode for more than 20 seconds (see "Implementation" below for
(Continue reading)

Permalink | Reply | 2 comments |

Gmane