gmane.linux.kernel

[PATCH] ftrace: add quick function trace stop


This patch adds a way to disable the function tracer quickly without
the need to run kstop_machine. It adds a new variable called
function_trace_stop which will stop the calls to functions from mcount
when set.  This is just an on/off switch and does not handle recursion
like preempt_disable().

It's main purpose is to help other tracers/debuggers start and stop tracing
fuctions without the need to call kstop_machine.

A new file is added to /debug/tracing called function_trace_stop.
Echoing 1 into this file will stop the function tracing and echoing 1
will allow function tracing. Note, this is not the same as the heavy weight
/proc/sys/kernel/ftrace_enabled which calls the kstop_machine to fully
enable or disable ftrace.

   ftrace_enabled      function_stop_trace

        0                     0 or 1      - No function tracing at all
        1                       0         - mcount called but no function is
                                              traced
        1                       1         - normal function tracing

Note, only x86 architecture has this implemented (for now).

Signed-off-by: Steven Rostedt <srostedt <at> redhat.com>
---
 arch/x86/kernel/entry_32.S |    6 +++++
 arch/x86/kernel/entry_64.S |    5 ++++
 include/linux/ftrace.h     |   28 ++++++++++++++++++++++++

(Continue reading)

headers

Andrey Batyiev | 6 Oct 18:21

APIC misconfiguration

Hello everyone

I'm trying to create touchscreen driver for Wibrain UMPC. I found out that device doesn't emit interrupts
until I switch polarity field in IO_APIC_route_entry. To do this, I need to export ioapic_read_entry and
ioapic_write_entry symbols from arch/x86/kernel/io_apic_{32,64}.c
Is there any other (better) way to do this?

Thanks,
   Andrey

headers

Tom Tucker | 6 Oct 17:55

[PATCH 00/03] RDMA Transport Support for 9P


Eric:

This patch series implements an RDMA Transport provider for 9P and 
is relative to your for-next branch.  The RDMA support is built on the 
OpenFabrics API and uses SEND and RECV to exchange data. This patch 
series has been tested with dbench and iozone.

Signed-off-by: Tom Tucker <tom <at> opengridcomputing.com>
Signed-off-by: Latchesar Ionkov <lionkov <at> lanl.gov>

[PATCH 01/03] 9prdma: RDMA Transport Support for 9P

 net/9p/trans_rdma.c |  996 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 996 insertions(+), 0 deletions(-)

[PATCH 02/03] 9prdma: Makefile change for the RDMA transport

 net/9p/Makefile |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

[PATCH 03/03] 9prdma: Kconfig changes for the RDMA transport

 net/9p/Kconfig |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

headers

George Nychis | 6 Oct 17:38

how to link to hrtimers in the kernel

Hi all,

I have modified drivers/usb/core/devio.c to use hrtimer_nanosleep(), and 
have included linux/hrtimer.h with it.

But now I am having trouble linking, I get:
ERROR: "hrtimer_nanosleep" [drivers/usb/core/usbcore.ko] undefined!

How do I properly link to the hrtimer library?

Thanks!
George

headers

Andre Haupt | 6 Oct 17:08

[PATCH] pc8736x_gpio: add support for PC87365 chips.

This is only compile tested, because i do not own appropriate hardware.

Signed-off-by: Andre Haupt <andre <at> bitwigglers.org>
---
 drivers/char/pc8736x_gpio.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/char/pc8736x_gpio.c b/drivers/char/pc8736x_gpio.c
index b930de5..3f7da8c 100644
--- a/drivers/char/pc8736x_gpio.c
+++ b/drivers/char/pc8736x_gpio.c
@@ -41,7 +41,8 @@ static u8 pc8736x_gpio_shadow[4];
 #define SIO_BASE2       0x4E	/* alt command-reg to check */

 #define SIO_SID		0x20	/* SuperI/O ID Register */
-#define SIO_SID_VALUE	0xe9	/* Expected value in SuperI/O ID Register */
+#define SIO_SID_PC87365	0xe5	/* Expected value in ID Register for PC87365 */
+#define SIO_SID_PC87366	0xe9	/* Expected value in ID Register for PC87366 */

 #define SIO_CF1		0x21	/* chip config, bit0 is chip enable */

@@ -91,13 +92,17 @@ static inline int superio_inb(int addr)

 static int pc8736x_superio_present(void)
 {
+	int id;
+
 	/* try the 2 possible values, read a hardware reg to verify */
 	superio_cmd = SIO_BASE1;
-	if (superio_inb(SIO_SID) == SIO_SID_VALUE)

(Continue reading)

headers

Andi Kleen | 6 Oct 16:09

scheduler hang on cpu re-hotplug with 2.6.27rc8

[Rafael, something for the regression list]

While testing cpu hotunplug/hotreplug (first 
setting two CPUs to offline and then to online again) on a 16 thread machine
with 2.6.27rc8 the first 

# echo 1 > ./devices/system/cpu/cpu14/online

after hotunplug deadlocked somewhere in the scheduler:

bash          D 00000000ffffcb5b     0  4683   4671
 ffff8804bc583c68 0000000000000086 ffff8804bc9d8640 0000000000000296
 ffff8804bdd34730 ffff8804be6fc090 ffff8804bdd34978 0000000c805a1e2a
 ffff8804be4fd780 ffffffff802298b4 ffffffff808acd98 ffff88027d0b1168
Call Trace:
 [<ffffffff802298b4>] __dequeue_entity+0x25/0x68
 [<ffffffff805a1b4b>] schedule_timeout+0x1e/0xad
 [<ffffffff8022a11f>] __disable_runtime+0x57/0x155
 [<ffffffff8025cc47>] cpupri_set+0xbe/0xcd
 [<ffffffff805a19b3>] wait_for_common+0xcd/0x131
 [<ffffffff8022c918>] default_wake_function+0x0/0xe
 [<ffffffff80241f3a>] synchronize_rcu+0x30/0x36
 [<ffffffff80241fac>] wakeme_after_rcu+0x0/0xc
 [<ffffffff8022dab6>] partition_sched_domains+0x9b/0x1dd
 [<ffffffff8022dc26>] update_sched_domains+0x2e/0x35
 [<ffffffff805a5297>] notifier_call_chain+0x29/0x4c
 [<ffffffff8059ef76>] _cpu_up+0xd0/0x10a
 [<ffffffff8059f004>] cpu_up+0x54/0x61
 [<ffffffff805837d5>] store_online+0x43/0x67
 [<ffffffff802c51e9>] sysfs_write_file+0xd2/0x110

(Continue reading)

headers

Jan Kiszka | 6 Oct 16:04

SIGTRAP vs. sys_exit_group race

Hi,

are there any news on these ideas?

http://marc.info/?l=linux-kernel&m=121540671602971

I've been caught by a race between a ptraced thread running on a
breakpoint, thus generating a SIGTRAP and another thread in this process
issuing sys_exit_group. The discussion above, specifically Oleg's
concerns, made me think that this is a generic issue of current
mainline.

I observed this on a heavily patched 2.6.26.5 kernel which comes, among
other things, with a higher probability for latencies/reschedules
between the queuing of SIGTRAP and the actual delivery. Right into this
window, the sys_exit_group comes. It informs gdb about the termination,
sends out SIGKILL to the other threads and turns the caller into a
zombie. Now the second thread has SIGKILL + SIGTRAP pending, and it
picks SIGTRAP for delivery. At this point gdb gets confused (maybe a bug
of its own?), sends SIGSTOP to the dead thread and waits for it to enter
the traced state (which it will never do) - deadlock of gdb, only
resolvable by killing the latter.

The patch below (rebased against latest git) resolves the issue for me,
but I'm definitely not sure about all its implications and if I'm not
papering over a different issue. Could you comment on my scenario? Is it
possible with mainline as well? Will Roland's approach resolve it?

Thanks,
Jan

(Continue reading)

headers

Mathieu Desnoyers | 6 Oct 15:26

Marker depmod fix core kernel list

Hi Linus,

Do you think this fix could be pulled in before 2.6.27 final ?

Thanks,

Mathieu

* Theodore Ts'o (tytso <at> mit.edu) wrote:
> 
> I've been playing with adding some markers into ext4 to see if they
> could be useful in solving some problems along with Systemtap.  It
> appears, though, that as of 2.6.27-rc8, markers defined in code which is
> compiled directly into the kernel (i.e., not as modules) don't show up
> in Module.markers:
> 
> kvm_trace_entryexit arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
> kvm_trace_handler arch/x86/kvm/kvm-intel  %u %p %u %u %u %u %u %u
> kvm_trace_entryexit arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
> kvm_trace_handler arch/x86/kvm/kvm-amd  %u %p %u %u %u %u %u %u
> 
> (Note the lack of any of the kernel_sched_* markers, and the markers I
> added for ext4_* and jbd2_* are missing as wel.)
> 
> Systemtap apparently depends on in-kernel trace_mark being recorded in
> Module.markers, and apparently it's been claimed that it used to be
> there.  Is this a bug in systemtap, or in how Module.markers is getting
> built?   And is there a file that contains the equivalent information
> for markers located in non-modules code?
>

(Continue reading)

headers

Jan Kiszka | 6 Oct 13:39

KGDB: x86: Avoid invoking kgdb_nmicallback twice per NMI

Stress-testing KVM's latest NMI support with kgdbts inside an SMP guest,
I came across spurious unhandled NMIs while running the singlestep test.
Looking closer at the code path each NMI takes when KGDB is enabled, I
noticed that kgdb_nmicallback is called twice per event: One time via
DIE_NMI_IPI notification, the second time on DIE_NMI. Removing the first
invocation cures the unhandled NMIs here.

Signed-off-by: Jan Kiszka <jan.kiszka <at> siemens.com>
---
 arch/x86/kernel/kgdb.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

Index: b/arch/x86/kernel/kgdb.c
===================================================================
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -455,12 +455,7 @@ static int __kgdb_notify(struct die_args
 		return NOTIFY_DONE;

 	case DIE_NMI_IPI:
-		if (atomic_read(&kgdb_active) != -1) {
-			/* KGDB CPU roundup */
-			kgdb_nmicallback(raw_smp_processor_id(), regs);
-			was_in_debug_nmi[raw_smp_processor_id()] = 1;
-			touch_nmi_watchdog();
-		}
+		/* Just ignore, we will handle the roundup on DIE_NMI. */
 		return NOTIFY_DONE;

 	case DIE_NMIUNKNOWN:

(Continue reading)

headers

Mark Brown | 6 Oct 14:30

[PATCH 0/13] WM8350 support

These patches against the regulator tree add initial support for the
WM8350, a multi-function device with several subsystems targetted at
embedded systems.  This series adds a core driver providing device acess
under drivers/mfd and support for the PMIC functionality of the device
via the regulator API.  Due to their use in the core some definitions
for other parts of the device are also included - drivers for these will
follow.

All the WM8350 drivers submitted here were originally written by Liam
Girdwood with some updates from me for submission to mainline.

Samuel, as with the WM8400 are you OK with merging this via the
regulator tree?

The following changes since commit fcbd54dd718e6741b05f8e5b08cbc75548acf0e4:
  Mark Brown (1):
        regulator: Add WM8400 regulator support

are available in the git repository at:

  git://opensource.wolfsonmicro.com/linux-2.6-audioplus for-lrg

Mark Brown (13):
      mfd: Add WM8350 audio register definitions
      mfd: Add WM8350 GPIO register definitions
      mfd: Add WM8350 PMIC register definitions
      mfd: Add WM8350 PMU register definitions
      mfd: Add WM8350 comparator register definitions
      mfd: Add WM8350 RTC register definitions
      mfd: Add WM8350 watchdog register definitions

(Continue reading)

headers

Frederic Weisbecker | 6 Oct 14:20

Re: [PATCH -tip] Fastboot: fix initcalls disposition in bootgraph.pl

Frédéric Weisbecker wrote:
> 2008/10/6 Ingo Molnar <mingo <at> elte.hu>:
>> * Frédéric Weisbecker <fweisbec <at> gmail.com> wrote:
>>
>>> 2008/10/5 Ingo Molnar <mingo <at> elte.hu>:
>>>> Frédéric, is the revert still needed, or is latest tip/master OK ?
>>> Yes it should be reverted. Tracing is still stopped at the end of
>>> kernel_init().
>> lost track - exactly which commit ID should be reverted?
>>
>>        Ingo
>>
> 
> Hmm actually, the "stop_boot_trace" feature may be needed in  the
> future. If I trace the shed events too,
> I should be able to limit the tracing to avoid too much entries. I
> will see later.
> Perhaps just a patch to remove the trace stopping after builtin initcalls.
> I will submit it soon.
> 
> Sorry, just forget this revert request.
> 
> Thanks.
> 

From: Frederic Weisbecker <fweisbec <at> gmail.com>
Subject: [PATCH -tip] Tracing/fastboot: Revert the stopping of the boot tracer

Since the patch that stopped the tracing after builtin-initcalls wasn't
a real solution of a bootgraph.pl's bug, we may continue to trace boot

(Continue reading)

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31