On Fri, Oct 19, 2012 at 04:25:12PM -0400, Chris Metcalf wrote:
> Also provide an optimized current_pt_regs() while we're at it.
Applied. BTW, are you sure you want to record parent's pid and not tid?
Anyway, here's a followup on top of this one (again, completely untested) -
switching to
Between 2.6.33 and 2.6.34 the PMU code was made modular.
The x86_pmu_enable() call was extended to disable cpuc->enabled
and iterate the counters, enabling one at a time, before calling
enable_all() at the end, followed by re-enabling cpuc->enabled.
Since cpuc->enabled was set to 0, that
This patch updates the generic events on p6, including some new
extended cache events.
Values for these events were taken from the equivelant PAPI predefined
events.
Tested on a Pentium II.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_p6.c
According to Intel SDM Volume 3B, FP_ASSIST is limited to Counter 1 only,
not Counter 0.
Tested on a Pentium II.
Signed-off-by: Vince Weaver
diff -ur linux-3.7-rc1.orig/arch/x86/kernel/cpu/perf_event_p6.c
linux-3.7-rc1/arch/x86/kernel/cpu/perf_event_p6.c
---
Hello
The following patches include some fixes for the p6 PMU driver.
I noticed these when working on the KNC driver which is roughly based
on the p6 driver.
patch1: Fixes a wrong event constraint
patch2: Expands the number of generic events supported by p6
patch3: Cleans up
Added more appropriate people to this. Added both i915 and nouveau
people, since apparently that fine piece of hardware has both.
Guys, any ideas?
Paweł, could you perhaps get a photo of the oops and post it
somewhere? I'm assuming the oops happens early during boot and you
never get a usable
==
> [ 732.789803] [ INFO: suspicious RCU usage. ]
> [ 732.790032] 3.7.0-rc1-next-20121019-sasha-2-g6d8d02d-dirty #63
> Tainted: GW
> [ 732.790032] ---
> [ 732.790032] include/linux/rcupdate.h:738 rcu_read_lock() used illegal
This patchset rebases the v2 of the patchset since the v1 was pushed into -rc1
instead. The last patch, not present on previous patchset, fixes the
permission check when allowing everything in a cgroup.
device_cgroup.c | 87 +++-
1 file
This patch converts the code to use kstrtou32() instead of simple_strtoul()
which is deprecated. The real size of the variables are u32, so use kstrtou32
instead of kstrtoul
Cc: Dave Jones
Cc: Andrew Morton
Cc: Tejun Heo
Cc: Li Zefan
Cc: James Morris
Cc: Pavel Emelyanov
Cc: Serge Hallyn
Before changing a group's default behavior to ALLOW, we must check if its
parent's behavior is also ALLOW.
Cc: Tejun Heo
Cc: Li Zefan
Cc: James Morris
Cc: Pavel Emelyanov
Cc: Serge Hallyn
Signed-off-by: Aristeu Rozanski
---
security/device_cgroup.c | 19 ++-
1 file
This was done in a v2 patch but v1 ended up being committed. The variable name
is less confusing and stores the default behavior when no matching exception
exists.
Cc: Dave Jones
Cc: Andrew Morton
Cc: Tejun Heo
Cc: Li Zefan
Cc: James Morris
Cc: Pavel Emelyanov
Cc: Serge Hallyn
commit 06f40a41b80e25e88a2b612ea3b2a94f93c94f72
Dave,
This is a batch of fixes intended for the 3.7 stream.
Dan Carpenter brings a fix for a simple signedness bug that could
prevent the proper termination of a loop.
Felix Fietkau found a few more places that need to use
ieee80211_free_txskb
Hi Linus,
Miscellaneous x86 fixes for 3.7-rc2.
The biggest ones are fixing suspend/resume breakage on 32 bits, and an
interrim fix for mapping over holes that allows AMD kit with more than
1 TB. A final solution for the latter is in the works, but involves
some fairly invasive changes that will
Hello, Frederic.
On Fri, Oct 19, 2012 at 03:44:20PM -0400, Frederic Weisbecker wrote:
> > For -stable, I think it's better to revert. If you want to remove
> > task_lock, let's do it for 3.8.
>
> I don't think that a wrong comment justifies a patch to stable.
I'm not really sure whether it's
On Mon, Oct 15, 2012 at 07:46:02PM +0200, Toralf Förster wrote:
> Even with current stable kernel 3.6.2 I sometimes get those syslog messages :
>
>
> 2012-10-15T19:37:58.401+02:00 n22 kernel: EXT4-fs error (device sdb3):
> ext4_mb_generate_buddy:741: group 436, 22902 clusters in bitmap, 22901
* Rik van Riel wrote:
> On 10/19/2012 07:41 AM, Peter Zijlstra wrote:
> >On Thu, 2012-10-18 at 17:20 -0400, Rik van Riel wrote:
> >>Having the function name indicate what the function is used
> >>for makes the code a little easier to read. Furthermore,
> >>the fault handling code largely
At Fri, 19 Oct 2012 12:54:21 -0700,
Jonathan Nieder wrote:
>
> joseph.salisb...@canonical.com wrote:
>
> > This patch adds a quirk to enable headphone jack audio on T430 Thinkpads.
> >
> > Signed-off-by: Joseph Salisbury
> > Cc:
>
> Thanks --- this is a little better.
>
> One more nit: it
Also provide an optimized current_pt_regs() while we're at it.
Signed-off-by: Chris Metcalf
---
[Re-sending to correct linus-arch / linux-arch typo.]
arch/tile/Kconfig |2 +
arch/tile/include/asm/processor.h |3 ++
arch/tile/include/asm/switch_to.h |5 +-
These are now provided in , so clean up warning
by not re-defining them in module.c.
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/module.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/tile/kernel/module.c b/arch/tile/kernel/module.c
index 001cbfa..243ffeb 100644
The tile tool chain uses the .eh_frame information for backtracing.
The vmlinux build drops any .eh_frame sections at link time, but when
present in kernel modules, it causes a module load failure due to the
presence of unsupported pc-relative relocations. When compiling to
use compiler feedback
Also provide an optimized current_pt_regs() while we're at it.
Signed-off-by: Chris Metcalf
---
arch/tile/Kconfig |2 +
arch/tile/include/asm/processor.h |3 ++
arch/tile/include/asm/switch_to.h |5 +-
arch/tile/kernel/entry.S | 11
On Fri, Oct 19, 2012 at 1:49 AM, Tang Chen wrote:
> Is it just container and pci_root_bridge hot-remove need to call
> acpi_bus_trim() twice ? For normal device without sub-device, I think
> it is OK to call acpi_bus_trim(device, 1).
>
> The reason why I'm asking this question is:
>
> I saw in
On Fri, Oct 19, 2012 at 01:34:21PM -0700, Tejun Heo wrote:
> On Mon, Oct 15, 2012 at 01:09:04PM -0700, Kent Overstreet wrote:
> > This adds a pointer to the bvec array to struct bio_integrity_payload,
> > instead of the bvecs always being inline; then the bvecs are allocated
> > with
On Mon, Oct 15, 2012 at 01:09:04PM -0700, Kent Overstreet wrote:
> This adds a pointer to the bvec array to struct bio_integrity_payload,
> instead of the bvecs always being inline; then the bvecs are allocated
> with bvec_alloc_bs().
>
> This is needed eventually for immutable bio vecs -
On Fri, 19 Oct 2012, Glauber Costa wrote:
> >>> What about gfp & __GFP_FS?
> >>>
> >>
> >> Do you intend to prevent or allow OOM under that flag? I personally
> >> think that anything that accepts to be OOM-killed should have GFP_WAIT
> >> set, so that ought to be enough.
> >>
> >
> > The oom
On Mon, Oct 15, 2012 at 01:09:01PM -0700, Kent Overstreet wrote:
> bio_integrity_split() seemed to be confusing pointers and arrays -
> bip_vec in bio_integrity_payload was an array appended to the end of the
> payload, so the bio_vecs in struct bio_pair should have come after the
>
Hello, Michal.
On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:
> On Thu 18-10-12 15:41:48, Tejun Heo wrote:
> > Hello, Michal.
> >
> > On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
> > > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > >
On Fri, Oct 19, 2012 at 05:33:18PM +0800, Li Zefan wrote:
> On 2012/10/17 21:30, Michal Hocko wrote:
> > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > safely move on and forbit all the callbacks to fail. The last missing
> > piece is moving cgroup_call_pre_destroy after
There is no need to do cpufreq_get_cpu() and cpufreq_put_cpu() for drivers that
don't support getavg() routine.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c
On Fri, Oct 19, 2012 at 06:54:42PM +0200, Rafael J. Wysocki wrote:
> > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> > review-cgroup_freezer-locking
>
> It seems that no one has any comments. :-)
>
> Are you going to prepare a branch for me to pull from?
I'm waiting for Oleg
Hey, Matt.
On Thu, Oct 18, 2012 at 06:29:45PM -0700, Matt Helsley wrote:
> Yeah, that would be a nice cleanup too. I guess the ultra-careful way to
> remove this feature would be something like:
>
> Add an internal migration restriction (which may or may not be
> exported as
On Thu, Oct 18, 2012 at 6:23 PM, Rusty Russell wrote:
>
> Smerged them together: no point moving the x509keyid script now.
> I dropped the optional dst arg, since we don't use it.
>
> Thanks,
> Rusty.
> ===
> From: Rusty Russell
> Subject: [PATCH] kbuild: sign the modules at install time
>
>
joseph.salisb...@canonical.com wrote:
> This patch adds a quirk to enable headphone jack audio on T430 Thinkpads.
>
> Signed-off-by: Joseph Salisbury
> Cc:
Thanks --- this is a little better.
One more nit: it looks like this was reported, tested, and based on a
patch by Stefan Freyr.
On Tue, 2012-10-09 at 08:56 -0600, Mike Yoknis wrote:
> On Mon, 2012-10-08 at 16:16 +0100, Mel Gorman wrote:
> > On Wed, Oct 03, 2012 at 08:56:14AM -0600, Mike Yoknis wrote:
> > > memmap_init_zone() loops through every Page Frame Number (pfn),
> > > including pfn values that are within the gaps
On Fri, 19 Oct 2012, Glauber Costa wrote:
> SLAB allows us to tune a particular cache behavior with tunables.
> When creating a new memcg cache copy, we'd like to preserve any tunables
> the parent cache already had.
SLAB and SLUB allow tuning. Could you come up with some way to put these
things
On Fri, 19 Oct 2012, Glauber Costa wrote:
> +
> +/*
> + * We use suffixes to the name in memcg because we can't have caches
> + * created in the system with the same name. But when we print them
> + * locally, better refer to them with the base name
> + */
> +static inline const char
Hello, Michal.
On Fri, Oct 19, 2012 at 03:24:38PM +0200, Michal Hocko wrote:
> > Maybe convert to proper /** function comment while at it?
>
> these are internal functions and we usually do not create kerneldoc for
> them. But I can surely change it - it would deserve a bigger clean up
> then.
On Fri, 19 Oct 2012, Glauber Costa wrote:
> An unlikely branch is used to make sure this case does not affect
> performance in the usual slab_free path.
>
> The slab allocator has a time based reaper that would eventually get rid
> of the objects, but we can also call it explicitly, since dead
On Fri, 19 Oct 2012, Glauber Costa wrote:
> We are able to match a cache allocation to a particular memcg. If the
> task doesn't change groups during the allocation itself - a rare event,
> this will give us a good picture about who is the first group to touch a
> cache page.
No that the
On Fri, 19 Oct 2012, Glauber Costa wrote:
> struct page already have this information. If we start chaining
> caches, this information will always be more trustworthy than
> whatever is passed into the function
Yes it does but the information is not standardized between the allocators
yet. Coul
2012/10/19 Tejun Heo :
> On Fri, Oct 19, 2012 at 09:35:26AM -0400, Frederic Weisbecker wrote:
>> 2012/10/18 Tejun Heo :
>> > From d935a5d6832a264ce52f4257e176f4f96cbaf048 Mon Sep 17 00:00:00 2001
>> > From: Tejun Heo
>> > Date: Thu, 18 Oct 2012 17:40:30 -0700
>> >
>> > This reverts commit
On Fri, Oct 19, 2012 at 12:36:00PM -0700, Tejun Heo wrote:
> Hello, Vivek.
>
> On Fri, Oct 19, 2012 at 11:00:11AM -0400, Vivek Goyal wrote:
> > > That way we can stick to the usual stats facility.
> >
> > So how does this help? Because it is a monotonically increasing value
> > we can use per
Hello, Vivek.
On Fri, Oct 19, 2012 at 11:00:11AM -0400, Vivek Goyal wrote:
> > That way we can stick to the usual stats facility.
>
> So how does this help? Because it is a monotonically increasing value
> we can use per cpu stats without extra locking? Or somthing else?
It's generally much
Exactly. This patch is incorrect and should be ignored.
Dmitry.
On Fri, Oct 19, 2012 at 9:19 PM, Richard Davies
wrote:
> Jeff Kirsher wrote:
>> Dmitry Fleytman wrote:
>> > Reported-by: Chris Webb
>> > Reported-by: Richard Davies
>> >
>> > Signed-off-by: Dmitry Fleytman
>> > ---
>> >
On Fri, 19 Oct 2012, Glauber Costa wrote:
> I, however, see no reason why we need to do so, since we are now locked
> during the whole deletion (which wasn't necessarily true before). I
> propose a simplification in which we delete it only when there is no
> more going back, so we don't need to
On Fri, Oct 19, 2012 at 02:49:32PM +0200, Peter Zijlstra wrote:
> Of course, if you do run out of lock classes, the next thing to do is
> to find the offending lock classes. First, the following command gives
> you the number of lock classes currently in use along with the maximum:
>
>
On Fri, Oct 19, 2012 at 6:03 AM, wrote:
> From: Wen Congyang
>
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> This 2 events may happen at the same time, so we may touch
> acpi_memory_device.res_list at the same
Hello kernel folks,
I recently decided to reinstall my Lenovo W500 laptop and found I wasn't able
to get DHCP leases, I wasn't able to install over PXE (when getting the IP a
second time within the OS)
Fedora is currently using kernel-3.6.2-2.fc18.x86_64 (Pre-beta)
The only difference I
Jeff Kirsher wrote:
> Dmitry Fleytman wrote:
> > Reported-by: Chris Webb
> > Reported-by: Richard Davies
> >
> > Signed-off-by: Dmitry Fleytman
> > ---
> > drivers/net/ethernet/intel/e1000/e1000_ethtool.c |9 +
> > drivers/net/ethernet/intel/e1000/e1000_main.c| 18
> >
Added CPU hot-remove support through an ACPI eject notification.
It calls acpi_bus_hot_remove_device(), which shares the same code
path with the sysfs eject operation. acpi_os_hotplug_execute()
serializes hot-remove operations between ACPI hot-remove and sysfs
eject requests.
Signed-off-by:
On Fri, Oct 19, 2012 at 4:35 AM, Kamezawa Hiroyuki
wrote:
> (2012/10/19 5:03), David Rientjes wrote:
>>
>> On Thu, 18 Oct 2012, Kamezawa Hiroyuki wrote:
>>>
>>> @@ -132,7 +162,7 @@ static void *m_start(struct seq_file *m, loff_t *pos)
>>> tail_vma = get_gate_vma(priv->task->mm);
>>>
Makes it easier to troubleshoot in the field.
Signed-off-by: Konrad Rzeszutek Wilk
---
include/xen/hvm.h | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/include/xen/hvm.h b/include/xen/hvm.h
index b193fa2..c2a4238 100644
---
On 19.10.2012, Greg Kroah-Hartman wrote:
> Does Linus's 3.7 git tree also crash for you this way?
Yes, it crashes in the same way with latest linus git 3.7.
Here's the screenshot:
http://www.fritha.org/crash-linus-git.jpg
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, Sep 27, 2012 at 10:57:51PM +0900, YAMANE Toshiaki wrote:
> fixed below checkpatch warning.
> - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then
> pr_err(... to printk(KERN_ERR ...
>
> Signed-off-by: YAMANE Toshiaki
Your coding style cleanup patch introduced more
On Thu, Sep 27, 2012 at 10:59:10PM +0900, YAMANE Toshiaki wrote:
> fixed below checkpatch warning.
> - WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then
> pr_err(... to printk(KERN_ERR ...
>
> and add pr_fmt.
>
> Signed-off-by: YAMANE Toshiaki
> ---
>
On 18/09/12 23:42, Rafael J. Wysocki wrote:
> Hi,
>
> On Sunday, September 16, 2012, Witold Szczeponik wrote:
>> Hi Rafael,
>>
>> what about the patches 1 and 3 which do not make any changes to the ABI?
>> The first patch simplifies the code, while the third patch fixes a problem in
>> the PNP
On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
> I'm not sure it matters, but I'm testing against a changeset about a week old:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
I was able to reproduce it with Xen 4.2 so found the culprit.
(please cc me on replies - I'm not directly subscribed to linux-kernel or
linux-pm)
I'm trying to track down why a Sandybridge system with a PCIe to PCI riser
has problems after enabling GPU RC6, and I've reduced my problem to the menu
cpuidle governor selecting high C-states from intel_idle,
Hi Linus,
Could you please pull the changes from the Xtensa repository. They are
all limited to the xtensa subtree and include some important changes
(adding long missing system calls for newer libc versions and other
fixes) and the UAPI changes.
Thanks,
-Chris
The following changes since
On Fri, 19 Oct 2012 10:10:16 +0100
Will Deacon wrote:
> On Thu, Oct 18, 2012 at 11:05:02PM +0100, Andrew Morton wrote:
> > On Wed, 17 Oct 2012 16:54:02 +0100
> > Will Deacon wrote:
> >
> > > On x86 memory accesses to pages without the ACCESSED flag set result in
> > > the
> > > ACCESSED flag
On Fri, Oct 19, 2012 at 11:08:40AM -0700, Linus Torvalds wrote:
> On Thu, Oct 18, 2012 at 5:16 PM, Richard Kuo wrote:
> >
> > Please pull the following small changes for the Hexagon arch. It includes
> > the Hexagon UAPI changes from David Howells and some CR marking changes for
> > the
On Thu, Oct 18, 2012 at 9:00 AM, Mikulas Patocka wrote:
>
> What is the procedure for making changes that require support of
> architectures? It is trivial to make a patch that moves this into
> arch-specific includes, the problem is that the patch break all the
> architectures - I wrote support
Hi Linus,
Please pull hwmon fixes for Linux 3.7-rc2 from signed tag:
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
hwmon-for-linus
Thanks,
Guenter
--
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14
On Fri, Oct 19, 2012 at 11:01:53AM -0700, Tony Luck wrote:
> On Fri, Oct 19, 2012 at 10:30 AM, Al Viro wrote:
> > IIRC, the lack of comments on function with unusual calling conventions was
> > the last remaining issue...
>
> Stylistically other asm functions have huge block header
> comments
> I think it again, and found that this check is necessary. Because we only
> lock memory hotplug when offlining pages. Here is the steps to offline and
> remove memory:
>
> 1. lock memory hotplug
> 2. offline a memory section
> 3. unlock memory hotplug
> 4. repeat 1-3 to offline all memory
On 10/19/2012 01:53 PM, Peter Zijlstra wrote:
On Fri, 2012-10-19 at 13:13 -0400, Rik van Riel wrote:
Another alternative might be to do the put_page inside
do_prot_none_numa(). That would be analogous to do_wp_page
disposing of the old page for the caller.
It'd have to be inside
On Fri, Oct 19, 2012 at 6:03 AM, wrote:
> From: Wen Congyang
>
> The memory device has been ejected and powoffed, so we can call
> acpi_bus_trim() to remove the memory device from acpi bus.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.7-rc1
for you to fetch changes up to
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.7-rc1
for you to fetch changes up to
> Hmm, IIRC, if the memory is recognized from kerenl before driver
> initialization,
> the memory device is not managed by the driver acpi_memhotplug.
Yup.
> I think we should also deal with REMOVAL_NORMAL here now. Otherwise it will
> cause
> some critical problem: we unbind the device from
On Fri, Oct 19, 2012 at 06:50:46PM +0100, Al Viro wrote:
> On Fri, Oct 19, 2012 at 10:36:39AM -0700, Dmitry Torokhov wrote:
> > On Fri, Oct 19, 2012 at 06:09:51PM +0100, Al Viro wrote:
> > > On Fri, Oct 19, 2012 at 09:33:18AM -0700, Dmitry Torokhov wrote:
> > >
> > > > We are now removing
On Fri, Oct 19, 2012 at 6:16 AM, wrote:
> From: Wen Congyang
>
> Current mem= implementation seems buggy because specification and
> implementation doesn't match. Current mem= has been working
> for many years and it's not buggy, it works as expected. So
> we should update the specification.
>
On Mon, Oct 15, 2012 at 01:09:02PM -0700, Kent Overstreet wrote:
> This adds a pointer to the bvec array to struct bio_integrity_payload,
> instead of the bvecs always being inline; then the bvecs are allocated
> with bvec_alloc_bs().
>
> Changed bvec_alloc_bs() and bvec_free_bs() to take a
* Linus Walleij [121019 06:09]:
>
> Instead: let use reserve the pins when the state is activated
> and drop them when the state is disabled, i.e. when we move to
> another state. This way different devices/functions can use the
> same pins at different times.
Hmm doesn't this mean that we are
On Thu, Oct 18, 2012 at 5:16 PM, Richard Kuo wrote:
>
> Please pull the following small changes for the Hexagon arch. It includes
> the Hexagon UAPI changes from David Howells and some CR marking changes for
> the transition from Code Aurora to Linux Foundation.
Can you please also check Al
On Thu, Oct 18, 2012 at 12:07:39PM +0200, Roland Stigge wrote:
> On 10/17/2012 09:05 PM, Greg KH wrote:
> >> +static int gpio_block_value_unexport(struct gpio_block *block)
> >> +{
> >> + struct device *dev;
> >> + int i;
> >> +
> >> + dev = class_find_device(_block_class, NULL,
On Fri, Oct 19, 2012 at 10:30 AM, Al Viro wrote:
> IIRC, the lack of comments on function with unusual calling conventions was
> the last remaining issue...
Stylistically other asm functions have huge block header
comments detailing register usage. But typically those
are way more complex. I
Michal, All,
On Friday 19 October 2012 Michal Marek wrote:
> On 18.10.2012 21:50, Yann E. MORIN wrote:
> > -#ifndef CONFIG_
> > -#define CONFIG_ "CONFIG_"
> > +/* Those two defines copied from include/linux/stringify.h */
> > +#define __stringify_1(x...)#x
> > +#define __stringify(x...)
On Fri, Oct 19, 2012 at 06:29:52AM +0200, Rafael J. Wysocki wrote:
> On Thursday 11 of October 2012 19:12:28 Yasuaki Ishimatsu wrote:
> > acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
> > number. But acpi_bus_remove() cannot return error number correctly.
> >
On 10/19, Peter Zijlstra wrote:
>
> But using preempt_{disable,enable} and using synchronize_sched() would
> be better (for PREEMPT_RCU) although it wouldn't fix anything
> fundamental.
BTW, I agree. I didn't even notice percpu-rwsem.h uses _rcu, not _sched.
> Fine goal, although somewhat arch
On Fri, 2012-10-19 at 13:13 -0400, Rik van Riel wrote:
> Would it make sense to have the normal page migration code always
> work with the extra refcount, so we do not have to introduce a new
> MIGRATE_FAULT migration mode?
>
> On the other hand, compaction does not take the extra reference...
Some gadget drivers may attempt to dequeue requests for an endpoint that has
already been disabled. For example, in the UVC gadget driver,
uvc_function_set_alt()
will call usb_ep_disable() when alt setting 0 is selected. When the userspace
application subsequently issues the VIDIOC_STREAMOFF
On Fri, Oct 19, 2012 at 10:36:39AM -0700, Dmitry Torokhov wrote:
> On Fri, Oct 19, 2012 at 06:09:51PM +0100, Al Viro wrote:
> > On Fri, Oct 19, 2012 at 09:33:18AM -0700, Dmitry Torokhov wrote:
> >
> > > We are now removing instance of character device corresponding to input
> > > device when
On 10/19, Mikulas Patocka wrote:
>
> synchronize_rcu() is way slower than msleep(1) -
This depends, I guess. but this doesn't mmatter,
> so I don't see a reason
> why should it be complicated to avoid msleep(1).
I don't think this really needs complications. Please look at this
patch for
On Fri, Oct 19, 2012 at 06:01:03PM +0200, Heinz Diehl wrote:
> On 19.10.2012, Greg Kroah-Hartman wrote:
>
> > 3.6-stable review patch. If anyone has any objections, please let me know.
>
> While 3.6.2 is fine. 3.6.3-rc1 crashes my machine (Asus U45-JC) at
> boot. A screenshot of the output is
On 10/19/2012 08:48 AM, Konrad Rzeszutek Wilk wrote:
>> paravirtualized architectures out there which are perfectly well
>> documented and supportable, but Xen has resisted doing that for
>> years, and all we ever get are vague future promises.
>
> There is no resistance - and it is being done.
On 10/18/2012 07:11 AM, Kim, Milo wrote:
> LP8788 IIO ADC driver and platform data have specific naming convention
> for ADC channels. That is using prefix 'lp8788_'.
> To keep this rule, ADC channel names are changed.
>
It's a little unusual to name the consumer side of the map so
The radeon driver does speed cap detection on the root PCI device for
the maximum speed with which the adapter can communicate. On ppc64
systems, however, the root device belongs to the Hypervisor, so the
current code would case a null pointer dereference.
I propose to look for the outmost
Hi,
On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote:
> Some gadget drivers may attempt to dequeue requests for an endpoint that has
> already been disabled. For example, in the UVC gadget driver,
> uvc_function_set_alt()
> will call usb_ep_disable() when alt setting 0 is selected.
On 10/18/2012 07:11 AM, Kim, Milo wrote:
> To get the ADC value for the battery voltage and temperature,
> LP8788 ADC driver is used.
> LP8788 charger driver is the consumer of LP8788 ADC driver.
> Thus, specific ADC driver name is required on getting the channel
> using iio_channel_get().
>
On Fri, 2012-10-19 at 11:32 -0400, Mikulas Patocka wrote:
> So if you can do an alternative implementation without RCU, show it.
Uhm,,. no that's not how it works. You just don't push through crap like
this and then demand someone else does it better.
But using preempt_{disable,enable} and
On Fri, Oct 19, 2012 at 10:32:30AM -0400, joseph.salisb...@canonical.com wrote:
> From: Joseph Salisbury
>
>
> Signed-off-by: Joseph Salisbury
> ---
> sound/pci/hda/patch_realtek.c |1 +
> 1 file changed, 1 insertion(+)
This is not the correct way to submit patches for inclusion in the
On Fri, Oct 19, 2012 at 06:09:51PM +0100, Al Viro wrote:
> On Fri, Oct 19, 2012 at 09:33:18AM -0700, Dmitry Torokhov wrote:
>
> > We are now removing instance of character device corresponding to input
> > device when input device disappears.
> >
> > Ah, I know... cdev is embedded in evdev, but
Sorry for the noise. I've just found it's my code at fault - we changed
to a 10,000 usec PM request for most platforms a while ago.
Simon
On Friday 19 October 2012 18:28:18 Simon Farnsworth wrote:
> (please cc me on replies - I'm not directly subscribed to linux-kernel or
> linux-pm)
>
> I'm
On Fri, Oct 19, 2012 at 05:16:50PM +, Luck, Tony wrote:
> > Surprisingly enough, ia64 one seems to work on actual hardware; I have sent
> > Tony an incremental patch cleaning copy_thread() up, waiting for results of
> > testing that on SMP box.
>
> Tiny bit faster than plain 3.7-rc1. lmbench3
This is a couple of high code motion patches (all within arch/parisc)
I'd like to apply at -rc1 to avoid conflicts with anything else. One
moves us on to the generated instead of included asm file model and the
other is a pull request from David Howells for UAPI disintegration.
The patches are
> In this case, the following BUG_ON in try_to_wake_up_local() will be
> triggered:
> BUG_ON(rq != this_rq());
Logically this looks OK - what is the test case to trigger this? I've done a
moderate
amount of testing of cpu online/offline while injecting corrected errors (when
testing
the CMCI
> > > This isn't limited to admin, right? So the above turns into a DoS on the
> > > console.
> > >
> > Ok, so how about a WARN_ON_ONCE() instead?
>
> That should be fine I guess ;-)
imho there is need for a generic mechanism to return an error string
to the user program without such hacks.
> Surprisingly enough, ia64 one seems to work on actual hardware; I have sent
> Tony an incremental patch cleaning copy_thread() up, waiting for results of
> testing that on SMP box.
Tiny bit faster than plain 3.7-rc1. lmbench3 reports fork+execve test at between
558 to 567 usec with the new
On 10/19/2012 12:39 PM, Peter Zijlstra wrote:
On Fri, 2012-10-19 at 11:53 -0400, Rik van Riel wrote:
If we do need the extra refcount, why is normal
page migration safe? :)
Its mostly a matter of how convoluted you make the code, regular page
migration is about as bad as you can get
Normal
101 - 200 of 1116 matches
Mail list logo
