* Re: [PATCH] i2c_intel_mid: Fix slash in sysfs name
From: Alan Cox @ 2011-01-04 10:32 UTC (permalink / raw)
To: Ben Dooks
Cc: Jean Delvare, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <4D227005.3010000-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
> > New sanity check of what? Where's the code?
Slashes in path names - it was added to the sysfs code
> > Using the adapter name to request the IRQ is silly. The very same issue
> > was fixed in i2c-pca-platform recently:
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=323584436db0cb05286425d4dfd9516fce88487f
>
> I agree, something like dev_name(dev) is much better for readability
> of /proc/interruopts
I'll take a look at this now I am back from Christmas break.
Alan
^ permalink raw reply
* Re: [RFC -v3 PATCH 0/3] directed yield for Pause Loop Exiting
From: Mike Galbraith @ 2011-01-04 10:32 UTC (permalink / raw)
To: Avi Kivity
Cc: Rik van Riel, kvm, linux-kernel, Srivatsa Vaddagiri,
Peter Zijlstra, Chris Wright
In-Reply-To: <4D22E3C0.7010808@redhat.com>
On Tue, 2011-01-04 at 11:09 +0200, Avi Kivity wrote:
> On 01/04/2011 08:42 AM, Mike Galbraith wrote:
> > If I were to, say, run a 256 CPU VM on my quad, would this help me get
> > more hackbench or whatever oomph from my (256X80386/20:) box?
>
> First of all, you can't run 256 guests on x86 kvm.
I didn't want 256 guests. Just one great big dog slow virtual playpen :)
> > > Both Intel and AMD CPUs have a feature that detects when a virtual
> > > CPU is spinning on a lock and will trap to the host.
> >
> > Does an Intel Q6600 have this trap gizmo (iow will this do anything at
> > all for my little box if I were to try it out).
>
> Likely not. Run
> http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=blob_plain;f=kvm/scripts/vmxcap;hb=HEAD,
> look for 'PAUSE-loop exiting'. I think the first processors to include
> them were the Nehalem-EXs, and Westmeres have them as well.
Oh darn, need new box to get all the toys. Thanks.
-Mike
^ permalink raw reply
* Re: fanotify coredump issue
From: Lino Sanfilippo @ 2011-01-04 10:28 UTC (permalink / raw)
To: vasily.novikov; +Cc: eparis, linux-fsdevel, malware-list
In-Reply-To: <4D219A39.70805@avira.com>
>
> -------- Original Message --------
> Subject: [malware-list] fanotify coredump issue
> Date: Mon, 27 Dec 2010 19:52:08 +0300
> From: Василий Новиков <vasiliy.novikov@gmail.com>
> To: eparis@redhat.com <eparis@redhat.com>
> CC: linux-fsdevel@vger.kernel.org <linux-fsdevel@vger.kernel.org>,
> vasily.novikov@kaspersky.com, malware-list@dmesg.printk.net
>
>
>
> Hi Eric,
>
> I tested fanotify in 2.6.37-rc7 and faced the following issue: when a
> fanotify server process (started with open_perm set) segfaults the
> kernel tries to open core dump file and here it is forced to wait a
> permission result because fanotify server receives notifications on
> file operations initiated by itself. Since fanotify server has crashed
> the permission will never be granted. So the whole system hangs.
Hmm I could not reproduce this with the latest state (ef9bf3b7144bee6ce) of
branch 'origin/for-next' from git.infradead.org/users/eparis/notify.git
What i did was:
- register with fanotify
- set mark for OPEN_PERM event
- read an event
- cause a segfault before response is returned to fanotify
The process terminates and the core file is created as expected.
Could you provide some code to trigger this?
> I don't see the point in receiving notifications on file operations
> initiated by fanotify server process so I created a patch that
> disables that and solves the issue at least in case of one fanotify
> server.
>
> Best regards,
> Vasily
>
> /usr/src/linux
> --- ./fs/notify/fanotify/fanotify.c.orig 2010-12-24 12:50:33.653029001 -0500
> +++ ./fs/notify/fanotify/fanotify.c 2010-12-24 13:28:19.561029005 -0500
> @@ -92,6 +92,9 @@ static int fanotify_get_response_from_ac
>
> pr_debug("%s: group=%p event=%p\n", __func__, group, event);
>
> + if(group->fanotify_data.tgid == task_tgid(current))
> + return 0;
> +
> wait_event(group->fanotify_data.access_waitq, event->response ||
> atomic_read(&group->fanotify_data.bypass_perm));
>
> @@ -217,6 +220,7 @@ static void fanotify_free_group_priv(str
> user = group->fanotify_data.user;
> atomic_dec(&user->fanotify_listeners);
> free_uid(user);
> + put_pid(group->fanotify_data.tgid);
> }
>
> const struct fsnotify_ops fanotify_fsnotify_ops = {
> --- ./fs/notify/fanotify/fanotify_user.c.orig 2010-12-24 12:12:07.593029001 -0500
> +++ ./fs/notify/fanotify/fanotify_user.c 2010-12-27 09:26:15.259956001 -0500
> @@ -337,6 +337,10 @@ static ssize_t fanotify_read(struct file
> ret = PTR_ERR(kevent);
> if (IS_ERR(kevent))
> break;
> + if(kevent->tgid == group->fanotify_data.tgid) {
> + fsnotify_put_event(kevent);
> + continue;
> + }
> ret = copy_event_to_user(group, kevent, buf);
> fsnotify_put_event(kevent);
> if (ret < 0)
> @@ -718,6 +722,7 @@ SYSCALL_DEFINE2(fanotify_init, unsigned
> INIT_LIST_HEAD(&group->fanotify_data.access_list);
> atomic_set(&group->fanotify_data.bypass_perm, 0);
> #endif
> + group->fanotify_data.tgid = get_pid(task_tgid(current));
> switch (flags & FAN_ALL_CLASS_BITS) {
> case FAN_CLASS_NOTIF:
> group->priority = FS_PRIO_0;
> --- ./include/linux/fsnotify_backend.h.orig 2010-12-24 12:08:59.965029002 -0500
> +++ ./include/linux/fsnotify_backend.h 2010-12-27 13:05:34.738636001 -0500
> @@ -171,6 +171,7 @@ struct fsnotify_group {
> int f_flags;
> unsigned int max_marks;
> struct user_struct *user;
> + struct pid *tgid;
> } fanotify_data;
> #endif /* CONFIG_FANOTIFY */
> };
I dont think that this will work.
A fanotify registration is not tracked by its pid, but by its group which
may be valid within several processes (think of fork() after you registered
with fanotify).
Thus checking for the pid of the process that has registered with fanotify does
not really make that much sense - the process may terminate right after registration
while the group continues to exist in (an)other process(es).
Regards,
Lino
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [U-Boot] [PATCH v2, RFC] armv7: fixloop: don't fixup if location is invalid on RAM
From: Joakim Tjernlund @ 2011-01-04 10:31 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTikrkO3O7_mkCFCuuRcc7Vrgoo=OjwbWAvAA6OSK@mail.gmail.com>
Minkyu Kang <promsoft@gmail.com> wrote on 2011/01/04 11:04:57:
>
> Dear Joakim Tjernlund,
>
> On 4 January 2011 18:49, Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >>
> >> Need to check that location is valid on RAM before the fixup.
> >
> > Why this change? The [PATCH RFC] armv7: fixloop: don't fixup if location is NULL
> > should be what you need.
>
> Some bss variables are initialized to 0xffffffff in my test case.
> In this case we should skip the fixup too.
> So, I make v2 patch for check it.
0xffffffff? What variables? Feels like a some other bug to me.
^ permalink raw reply
* Re: Kernel build
From: Américo Wang @ 2011-01-04 10:29 UTC (permalink / raw)
To: Anca Emanuel; +Cc: LKML, kernel-team
In-Reply-To: <AANLkTins3HdRJ-Y7bCuXFjOhjx+-nxDHSqUxBPuuxFxg@mail.gmail.com>
On Tue, Jan 04, 2011 at 09:59:29AM +0200, Anca Emanuel wrote:
>Question: Why I need to rebuild all the modules, if they are already builded.
>https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
>If I make an one line change, I need to wait one hour to make an new
>kernel on an intel core duo at 2GHz sistem ?
Depends on which file you change, if that is a header file,
it is supposed to re-compile all the C source files that include it.
Thanks.
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] ioeventfd: minor fixups
From: Stefan Hajnoczi @ 2011-01-04 10:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: qemu-devel
In-Reply-To: <20110103163852.GA18143@redhat.com>
On Mon, Jan 03, 2011 at 06:38:53PM +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 29, 2010 at 04:52:46PM +0200, Michael S. Tsirkin wrote:
> > This is on top of the ioeventfd patches, and
> > fixes two potential issues when ioeventfd is mixed with vhost-net:
> > - ioeventfd could start running then get stopped for vhost-net.
> > For example, vm state change handlers run in no particular order.
> > This would be hard to debug. Prevent this by always running state
> > callback before ioeventfd start and after ioeventfd stop.
> > - Separate the flags for user-requested ioeventfd and for ioeventfd
> > being overridden by vhost backend.
> > This will make it possible to enable/disable vhost depending on
> > guest behaviour.
> >
> > I'll probably split this patch in two, and merge into the
> > appropriate patches in the ioeventfd series.
> >
> > Compile-tested only so far, would appreciate feedback/test reports.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
>
> Stefan - just to clarify, I'm waiting for you ack
> to merge this + the ioeventfd patches.
Back from the holidays today. Will send feedback/ack later today.
Stefan
^ permalink raw reply
* [Qemu-devel] [PATCH] Close Gdb stub connection in gdb_exit
From: Fabien Chouteau @ 2011-01-04 10:27 UTC (permalink / raw)
To: qemu-devel; +Cc: Fabien Chouteau
On Windows, this is required to flush the remaining data in the IO stream,
otherwise Gdb do not receive the last packet.
Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
---
gdbstub.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 0aa081b..dac3ce6 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -2391,6 +2391,10 @@ void gdb_exit(CPUState *env, int code)
snprintf(buf, sizeof(buf), "W%02x", (uint8_t)code);
put_packet(s, buf);
+
+ if (s->chr) {
+ qemu_chr_close(s->chr);
+ }
}
#ifdef CONFIG_USER_ONLY
--
1.7.1
^ permalink raw reply related
* Re: [RFC -v3 PATCH 0/3] directed yield for Pause Loop Exiting
From: Mike Galbraith @ 2011-01-04 10:26 UTC (permalink / raw)
To: Avi Kivity
Cc: Rik van Riel, kvm, linux-kernel, Srivatsa Vaddagiri,
Peter Zijlstra, Chris Wright
In-Reply-To: <4D22E4F9.4060909@redhat.com>
On Tue, 2011-01-04 at 11:14 +0200, Avi Kivity wrote:
> Assuming there are no objections, Mike, can you get 2/3 into a
> fast-forward-only branch of tip.git? I'll then merge it into kvm.git
> and apply 1/3 and 2/3.
Wrong guy. Fast-forward is Peter's department.
-Mike
^ permalink raw reply
* Re: [PATCH 1/1] hidraw: Added Compatibility ioctl() for 32-bit applications.
From: Jiri Kosina @ 2011-01-04 10:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Alan Ott, Stefan Achatz, Antonio Ospite, Tejun Heo,
Marcel Holtmann, linux-input, linux-kernel
In-Reply-To: <201101041118.39602.arnd@arndb.de>
On Tue, 4 Jan 2011, Arnd Bergmann wrote:
> On Tuesday 04 January 2011 06:37:22 Alan Ott wrote:
> > Added the ioctl function to the compat_ioctl pointer in the
> > file_operations struct. Before this, some ioctls would
> > fail for 32-bit apps on 64-bit systems.
> >
> > Signed-off-by: Alan Ott <alan@signal11.us>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
Applied, thanks guys.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH] HID: magicmouse: Don't report REL_{X,Y} for Magic Trackpad
From: Jiri Kosina @ 2011-01-04 10:25 UTC (permalink / raw)
To: Chase Douglas; +Cc: Michael Poole, linux-input, linux-kernel
In-Reply-To: <4D224A0B.8010408@canonical.com>
On Mon, 3 Jan 2011, Chase Douglas wrote:
> >>> With the recent switch to having the hid layer handle standard axis
> >>> initialization, the Magic Trackpad now reports relative axes. This would
> >>> be fine in the normal mode, but the driver puts the device in multitouch
> >>> mode where no relative events are generated. Also, userspace software
> >>> depends on accurate axis information for device type detection. Thus,
> >>> ignoring the relative axes from the Magic Trackpad is best.
> >>
> >> Applied, thank you. I take it this should better go into .37 still, right?
> >
> > Yes, please.
>
> Jiri,
>
> It looks like this never got pushed to .37. Can you add "Cc:
> stable@kernel.org" to the SOB area and push it?
Hi Chase,
I am not rebasing my tree, so it's not easy to add Cc: stable@kernel.org
to the commit once it has been mirrored out.
But I have this commit in my list to send it to -stable once it goes to
Linus, manually.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: IOMMU and DMA mode of pata_jmicron
From: Roedel, Joerg @ 2011-01-04 10:23 UTC (permalink / raw)
To: Steffen Moser
Cc: Jeff Garzik, linux-kernel@vger.kernel.org, Linux IDE mailing list
In-Reply-To: <4D222E7F.5080305@steffen-moser.de>
Hi Steffen,
On Mon, Jan 03, 2011 at 03:15:59PM -0500, Steffen Moser wrote:
> Beside a possible work-around, do you think, it makes sense to
> report the problem to ASUS as the straight way should be to have
> a correct IVRS table for the board?
Sure, that makes sense. Probably they fix their BIOS, but I wouldn't
count on it. But it is worth a try.
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [RFC] /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_overcommit_hugepages
From: CAI Qian @ 2011-01-04 10:21 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-mm
In-Reply-To: <20110104095641.GA8651@tiehlicka.suse.cz>
> > 3) overcommit 2gb hugepages.
> > mmap(NULL, 18446744071562067968, PROT_READ|PROT_WRITE, MAP_SHARED,
> > 3, 0) = -1 ENOMEM (Cannot allocate memory)
>
> Hmm, you are trying to reserve/mmap a lot of memory (17179869182 1GB
> huge pages).
That is strange - the test code merely did this,
addr = mmap(ADDR, 2<<30, PROTECTION, FLAGS, fd, 0);
Do you know if overcommit was designed for 1GB pages? At least, read this
from Documentation/kernel-parameters.txt,
hugepagesz=
...
Note that 1GB pages can only be allocated at boot time
using hugepages= and not freed afterwards.
How does it allow to be overcommitted for only being able to allocate at
boot time?
> > Also, nr_overcommit_hugepages was overwritten with such a strange
> > value after overcommit failure. Should we just remove this file from
> > sysfs for simplicity?
>
> This is strange. The value is set only in hugetlb_overcommit_handler
> which is a sysctl handler.
>
> Are you sure that you are not changing the value by the /sys interface
> somewhere (there is no check for the value so you can set what-ever
> value you like)? I fail to see any mmap code path which would change
> this value.
I could double-check here, but it is not important if the fact is that
overcommit is not supported for 1GB pages.
> Btw. which kernel version are you using.
mmotm 2010-12-02-16-34 version 2.6.37-rc4-mm1+. This problem is also present
in 2.6.18.
Thanks.
CAI Qian
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [U-Boot] net/eth.c drivers/net/rtl8019.c eth_xxx function name dunplication
From: Stefano Babic @ 2011-01-04 10:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BA88111AC43448F28207F9912720F4A9@MrGates>
On 01/04/2011 08:55 AM, qq wrote:
> These words show me that net/eth.c has "eth_send" and drivers/net/rtl8019.c
> also has "eth_send" function as the same name.
> My board use RTL8019AS ethernet controller,s3c44b0 CPU.
> i couldn`t figure out what is wrong with the code and how to fix it,Thanks a
> lot for any suggestion
It seems to me that the rtl8019 driver was never updated according to
the eth_device stucture (I think it was the introduction of
CONFIG_NET_MULTI).
Network drivers must not expose global functions, and instead of that
they must set their callbacks in a struct eth_device and register itself
with eth_register().
Anyway, I do not find any board in actual u-boot code using this driver.
It seems to me like dead code...
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 1/1] hidraw: Added Compatibility ioctl() for 32-bit applications.
From: Arnd Bergmann @ 2011-01-04 10:18 UTC (permalink / raw)
To: Alan Ott
Cc: Jiri Kosina, Stefan Achatz, Antonio Ospite, Tejun Heo,
Marcel Holtmann, linux-input, linux-kernel
In-Reply-To: <1294119442-6827-2-git-send-email-alan@signal11.us>
On Tuesday 04 January 2011 06:37:22 Alan Ott wrote:
> Added the ioctl function to the compat_ioctl pointer in the
> file_operations struct. Before this, some ioctls would
> fail for 32-bit apps on 64-bit systems.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Acked-by: Arnd Bergmann <arnd@arndb.de>
I verified that all the ioctls for hidraw are indeed compatible.
Arnd
^ permalink raw reply
* [PATCH 2/3] perf: add OMAP support for the new power events
From: jean.pihet @ 2011-01-04 10:17 UTC (permalink / raw)
To: mingo, linux-kernel, trenn
Cc: linux-omap, Arjan van de Ven, linux-perf-users, rjw, Jean Pihet
In-Reply-To: <1294136263-24020-1-git-send-email-j-pihet@ti.com>
From: Jean Pihet <j-pihet@ti.com>
The patch adds the new power management trace points for
the OMAP architecture.
The trace points are for:
- default idle handler. Since the cpuidle framework is
instrumented in the generic way there is no need to
add trace points in the OMAP specific cpuidle handler;
- cpufreq (DVFS),
- clocks changes (enable, disable, set_rate),
- change of power domains next power states.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 7 +++++++
arch/arm/mach-omap2/powerdomain.c | 3 +++
arch/arm/plat-omap/clock.c | 13 ++++++++++---
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 0ec8a04..0ee0b0e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -29,6 +29,7 @@
#include <linux/delay.h>
#include <linux/slab.h>
#include <linux/console.h>
+#include <trace/events/power.h>
#include <plat/sram.h>
#include <plat/clockdomain.h>
@@ -506,8 +507,14 @@ static void omap3_pm_idle(void)
if (omap_irq_pending() || need_resched())
goto out;
+ trace_power_start(POWER_CSTATE, 1, smp_processor_id());
+ trace_cpu_idle(1, smp_processor_id());
+
omap_sram_idle();
+ trace_power_end(smp_processor_id());
+ trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
+
out:
local_fiq_enable();
local_irq_enable();
diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index 6527ec3..73cbe9a 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -23,6 +23,7 @@
#include <linux/errno.h>
#include <linux/err.h>
#include <linux/io.h>
+#include <trace/events/power.h>
#include <asm/atomic.h>
@@ -440,6 +441,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst)
pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
pwrdm->name, pwrst);
+ trace_power_domain_target(pwrdm->name, pwrst, smp_processor_id());
+
prm_rmw_mod_reg_bits(OMAP_POWERSTATE_MASK,
(pwrst << OMAP_POWERSTATE_SHIFT),
pwrdm->prcm_offs, pwrstctrl_reg_offs);
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index fc62fb5..7cbb09b 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -21,6 +21,7 @@
#include <linux/cpufreq.h>
#include <linux/debugfs.h>
#include <linux/io.h>
+#include <trace/events/power.h>
#include <plat/clock.h>
@@ -43,8 +44,10 @@ int clk_enable(struct clk *clk)
return -EINVAL;
spin_lock_irqsave(&clockfw_lock, flags);
- if (arch_clock->clk_enable)
+ if (arch_clock->clk_enable) {
+ trace_clock_enable(clk->name, 1, smp_processor_id());
ret = arch_clock->clk_enable(clk);
+ }
spin_unlock_irqrestore(&clockfw_lock, flags);
return ret;
@@ -66,8 +69,10 @@ void clk_disable(struct clk *clk)
goto out;
}
- if (arch_clock->clk_disable)
+ if (arch_clock->clk_disable) {
+ trace_clock_disable(clk->name, 0, smp_processor_id());
arch_clock->clk_disable(clk);
+ }
out:
spin_unlock_irqrestore(&clockfw_lock, flags);
@@ -120,8 +125,10 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
return ret;
spin_lock_irqsave(&clockfw_lock, flags);
- if (arch_clock->clk_set_rate)
+ if (arch_clock->clk_set_rate) {
+ trace_clock_set_rate(clk->name, rate, smp_processor_id());
ret = arch_clock->clk_set_rate(clk, rate);
+ }
if (ret == 0) {
if (clk->recalc)
clk->rate = clk->recalc(clk);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] tools, perf: Documentation for the power events API
From: jean.pihet @ 2011-01-04 10:17 UTC (permalink / raw)
To: mingo, linux-kernel, trenn
Cc: linux-omap, Arjan van de Ven, linux-perf-users, rjw, Jean Pihet
In-Reply-To: <1294136263-24020-1-git-send-email-j-pihet@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Provides documentation for the following:
- the new power trace API,
- the old (legacy) power trace API,
- the DEPRECATED Kconfig option usage.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
---
Documentation/trace/events-power.txt | 90 ++++++++++++++++++++++++++++++++++
1 files changed, 90 insertions(+), 0 deletions(-)
create mode 100644 Documentation/trace/events-power.txt
diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
new file mode 100644
index 0000000..8a50653
--- /dev/null
+++ b/Documentation/trace/events-power.txt
@@ -0,0 +1,90 @@
+
+ Subsystem Trace Points: power
+
+The power tracing system captures events related to power transitions
+within the kernel. Broadly speaking there are three major subheadings:
+
+ o Power state switch which reports events related to suspend (S-states),
+ cpuidle (C-states) and cpufreq (P-states)
+ o System clock related changes
+ o Power domains related changes and transitions
+
+This document describes what each of the tracepoints is and why they
+might be useful.
+
+Cf. include/trace/events/power.h for the events definitions.
+
+1. Power state switch events
+============================
+
+1.1 New trace API
+-----------------
+
+A 'cpu' event class gathers the CPU-related events: cpuidle and
+cpufreq.
+
+cpu_idle "state=%lu cpu_id=%lu"
+cpu_frequency "state=%lu cpu_id=%lu"
+
+A suspend event is used to indicate the system going in and out of the
+suspend mode:
+
+machine_suspend "state=%lu"
+
+
+Note: the value of '-1' or '4294967295' for state means an exit from the current state,
+i.e. trace_cpu_idle(4, smp_processor_id()) means that the system
+enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id())
+means that the system exits the previous idle state.
+
+The event which has 'state=4294967295' in the trace is very important to the user
+space tools which are using it to detect the end of the current state, and so to
+correctly draw the states diagrams and to calculate accurate statistics etc.
+
+1.2 DEPRECATED trace API
+------------------------
+
+A new Kconfig option CONFIG_EVENT_POWER_TRACING_DEPRECATED with the default value of
+'y' has been created. This allows the legacy trace power API to be used conjointly
+with the new trace API.
+The Kconfig option, the old trace API (in include/trace/events/power.h) and the
+old trace points will disappear in a future release (namely 2.6.41).
+
+power_start "type=%lu state=%lu cpu_id=%lu"
+power_frequency "type=%lu state=%lu cpu_id=%lu"
+power_end "cpu_id=%lu"
+
+The 'type' parameter takes one of those macros:
+ . POWER_NONE = 0,
+ . POWER_CSTATE = 1, /* C-State */
+ . POWER_PSTATE = 2, /* Fequency change or DVFS */
+
+The 'state' parameter is set depending on the type:
+ . Target C-state for type=POWER_CSTATE,
+ . Target frequency for type=POWER_PSTATE,
+
+power_end is used to indicate the exit of a state, corresponding to the latest
+power_start event.
+
+2. Clocks events
+================
+The clock events are used for clock enable/disable and for
+clock rate change.
+
+clock_enable "%s state=%lu cpu_id=%lu"
+clock_disable "%s state=%lu cpu_id=%lu"
+clock_set_rate "%s state=%lu cpu_id=%lu"
+
+The first parameter gives the clock name (e.g. "gpio1_iclk").
+The second parameter is '1' for enable, '0' for disable, the target
+clock rate for set_rate.
+
+3. Power domains events
+=======================
+The power domain events are used for power domains transitions
+
+power_domain_target "%s state=%lu cpu_id=%lu"
+
+The first parameter gives the power domain name (e.g. "mpu_pwrdm").
+The second parameter is the power domain target state.
+
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/3] perf: add calls to suspend trace point
From: jean.pihet @ 2011-01-04 10:17 UTC (permalink / raw)
To: mingo, linux-kernel, trenn
Cc: linux-omap, Arjan van de Ven, linux-perf-users, rjw, Jean Pihet
In-Reply-To: <1294136263-24020-1-git-send-email-j-pihet@ti.com>
From: Jean Pihet <j-pihet@ti.com>
Uses the machine_suspend trace point, called from the
generic kernel suspend_enter function.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
CC: Thomas Renninger <trenn@suse.de>
---
kernel/power/suspend.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ecf7705..0650596 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -22,6 +22,7 @@
#include <linux/mm.h>
#include <linux/slab.h>
#include <linux/suspend.h>
+#include <trace/events/power.h>
#include "power.h"
@@ -164,7 +165,9 @@ static int suspend_enter(suspend_state_t state)
error = sysdev_suspend(PMSG_SUSPEND);
if (!error) {
if (!suspend_test(TEST_CORE) && pm_check_wakeup_events()) {
+ trace_machine_suspend(state);
error = suspend_ops->enter(state);
+ trace_machine_suspend(PWR_EVENT_EXIT);
events_check_enabled = false;
}
sysdev_resume();
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/3] perf, tools: new power trace API
From: jean.pihet @ 2011-01-04 10:17 UTC (permalink / raw)
To: mingo, linux-kernel, trenn
Cc: linux-omap, Arjan van de Ven, linux-perf-users, rjw, Jean Pihet
From: Jean Pihet <j-pihet@ti.com>
Provides:
. calls to machine_suspend trace point,
. OMAP support,
. API Documentation
Applies on top of Thomas's 8 latest power trace API patches, cf.
http://marc.info/?l=linux-kernel&m=129130827309354&w=2
Jean Pihet (3):
perf: add calls to suspend trace point
perf: add OMAP support for the new power events
tools, perf: Documentation for the power events API
Documentation/trace/events-power.txt | 90 ++++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/pm34xx.c | 7 +++
arch/arm/mach-omap2/powerdomain.c | 3 +
arch/arm/plat-omap/clock.c | 13 ++++-
kernel/power/suspend.c | 3 +
5 files changed, 113 insertions(+), 3 deletions(-)
create mode 100644 Documentation/trace/events-power.txt
--
1.7.2.3
^ permalink raw reply
* Re: [PATCH 1/3] sched: add __rcu annotation
From: Peter Zijlstra @ 2011-01-04 10:17 UTC (permalink / raw)
To: Lai Jiangshan; +Cc: Ingo Molnar, Paul E. McKenney, Arnd Bergmann, LKML
In-Reply-To: <4D22D4EE.3020604@cn.fujitsu.com>
On Tue, 2011-01-04 at 16:06 +0800, Lai Jiangshan wrote:
> Add __rcu annotation to :
> (struct rq)->sd
That's a broken changelog, it's about as good as:
i++; /* increment i */
I'm really starting to detest sparse (lock annotations), it keeps adding
these annotations, but does it ever catch an actual bug?
^ permalink raw reply
* Re: [PATCH 4/4] vcs-svn: improve reporting of input errors
From: Jonathan Nieder @ 2011-01-04 10:16 UTC (permalink / raw)
To: git; +Cc: David Barr, Ramkumar Ramachandra, Sverre Rabbelier
In-Reply-To: <20101228105410.GD13360@burratino>
Jonathan Nieder wrote:
> --- a/vcs-svn/svndump.c
> +++ b/vcs-svn/svndump.c
> @@ -107,20 +107,37 @@ static void init_keys(void)
[...]
> } else if (!strncmp(t, "V ", 2)) {
> len = atoi(&t[2]);
> val = buffer_read_string(len);
> + if (!t)
> + die_short_read();
This should have said "if (!val)". Sorry for the confusion.
^ permalink raw reply
* Re: linux-next: Tree for January 4
From: Anca Emanuel @ 2011-01-04 10:14 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: LKML
In-Reply-To: <AANLkTinkEQEhsHGGgJVp_pJohmrOAaa3dCJjNSDKS4Yj@mail.gmail.com>
CC [M] drivers/usb/serial/opticon.o
drivers/staging/cx25821/cx25821-video.c: In function ‘video_open’:
drivers/staging/cx25821/cx25821-video.c:817: error: implicit
declaration of function ‘lock_kernel’
drivers/staging/cx25821/cx25821-video.c:834: error: implicit
declaration of function ‘unlock_kernel’
make[4]: *** [drivers/staging/cx25821/cx25821-video.o] Error 1
make[3]: *** [drivers/staging/cx25821] Error 2
make[2]: *** [drivers/staging] Error 2
^ permalink raw reply
* Re: [PATCH 01/11] Bluetooth: Implement automatic setup procedure for local adapters
From: Johan Hedberg @ 2011-01-04 10:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1294135715-26728-1-git-send-email-johan.hedberg@gmail.com>
On Tue, Jan 04, 2011, johan.hedberg@gmail.com wrote:
> This patch implements automatic initialization of basic information
> about newly registered Bluetooth adapters. E.g. the address and features
> are always needed so it makes sense for the kernel to automatically
> power on adapters and read this information. A new HCI_SETUP flag is
> added to track this state.
>
> In order to not consume unnecessary amounts of power if there isn't a
> user space available that could switch the adapter back off, a timer is
> added to do this automatically as long as no Bluetooth user space seems
> to be present. A new HCI_AUTO_OFF flag is added that user space needs to
> clear to avoid the automatic power off.
>
> Additionally, the management interface index_added event is moved to the
> end of the HCI_SETUP stage so a user space supporting the managment
> inteface has all the necessary information available for fetching when
> it gets notified of a new adapter. The HCI_DEV_REG event is kept in the
> same place as before since existing HCI raw socket based user space
> versions depend on seeing the kernels initialization sequence
> (hci_init_req) to determine when the adapter is ready for use.
Sorry about this stray and duplicate patch. I got some doubts when doing
git send-email originally and hit ctrl-c before an ack was shown for the
first email. It seems it got through to the list nevertheless. I.e.
ignore this as all the relevant patches are part of the next thread.
Johan
^ permalink raw reply
* Re: [PATCH] writeback: fix typo of global_dirty_limits comment
From: Jiri Kosina @ 2011-01-04 10:13 UTC (permalink / raw)
To: Minchan Kim; +Cc: linux-mm, LKML, Wu Fengguang
In-Reply-To: <1294072608-3172-1-git-send-email-minchan.kim@gmail.com>
On Tue, 4 Jan 2011, Minchan Kim wrote:
> Change runtime with real-time
>
> Cc: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> ---
> mm/page-writeback.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index c340536..98b79e2 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -384,7 +384,7 @@ unsigned long determine_dirtyable_memory(void)
> * - vm.dirty_background_ratio or vm.dirty_background_bytes
> * - vm.dirty_ratio or vm.dirty_bytes
> * The dirty limits will be lifted by 1/4 for PF_LESS_THROTTLE (ie. nfsd) and
> - * runtime tasks.
> + * real-time tasks.
> */
> void global_dirty_limits(unsigned long *pbackground, unsigned long *pdirty)
> {
Applied, thank you.
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] writeback: fix typo of global_dirty_limits comment
From: Jiri Kosina @ 2011-01-04 10:13 UTC (permalink / raw)
To: Minchan Kim; +Cc: linux-mm, LKML, Wu Fengguang
In-Reply-To: <1294072608-3172-1-git-send-email-minchan.kim@gmail.com>
On Tue, 4 Jan 2011, Minchan Kim wrote:
> Change runtime with real-time
>
> Cc: Wu Fengguang <fengguang.wu@intel.com>
> Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
> ---
> mm/page-writeback.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index c340536..98b79e2 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -384,7 +384,7 @@ unsigned long determine_dirtyable_memory(void)
> * - vm.dirty_background_ratio or vm.dirty_background_bytes
> * - vm.dirty_ratio or vm.dirty_bytes
> * The dirty limits will be lifted by 1/4 for PF_LESS_THROTTLE (ie. nfsd) and
> - * runtime tasks.
> + * real-time tasks.
> */
> void global_dirty_limits(unsigned long *pbackground, unsigned long *pdirty)
> {
Applied, thank you.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* [Qemu-devel] [Bug 638955] Re: emulated netcards don't work with recent sunos kernel
From: daniel pecka @ 2011-01-04 10:04 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20100915132907.2955.78648.malonedeb@gandwana.canonical.com>
okay Stefan ..
thanks, i poked several people and trying to learn up how netstack works
.. i have no experience with programming drivers .. i hope that we'll
fix it soon cuz it's very bad that we're unable to use kvm|qemu
regards, daniel
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/638955
Title:
emulated netcards don't work with recent sunos kernel
Status in QEMU:
New
Bug description:
hi there,
i'm using qemu-kvm backend in version: # qemu-kvm -version
QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
and there are just *not working any of model=$type with combinations of recent sunos (solaris, openindiana, opensolaris, ..) ..
you can download for testing purposes iso from here: http://dlc-origin.openindiana.org/isos/147/ or from here: http://genunix.org/distributions/indiana/ << osol and oi are also bubuntu-like *live cds, so no need to bother with installing
behaviour is as follows:
e1000 - receiving doesn't work, transmitting works .. dladm (tool for handle ethers) shows that is all ok, correct mode is loaded up, it just seems like this driver works at 100% but ..
rtl8169|pcnet - works in 10Mbit mode with several other issues like high cpu utilization and so .. dladm is unable to recognize options for this kind of -nic
others - just don't work
.. i experienced this issue several times in past .. woraround was, that rtl8169 worked so-so .. with recent sunos kernel it doesn't.
it's easy to reproduce, this is why i'm not putting here more then launching script for my virtual machine:
# cat openindiana.sh
qemu-kvm -hda /home/kvm/openindiana/openindiana.img -m 2048 -localtime -cdrom /home/kvm/+images/oi-dev-147-x86.iso -boot d \
-vga std -vnc :9 -k en-us -monitor unix:/home/kvm/openindiana/instance,server,nowait \
-net nic,model=e1000,vlan=1 -net tap,ifname=oi0,script=no,vlan=1 &
sleep 2;
ip l set oi0 up;
ip a a 192.168.99.9/24 dev oi0;
regards by daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.