On 10 July 2014 16:45, Srivatsa S. Bhat sriva...@mit.edu wrote:
Looks good to me. But I think it would be better to move the invocation of
kobject_move() to update_policy_cpu() itself, so that update_policy_cpu()
will do all the work involved in updating the policy-cpu, as its name
suggests.
On Wed, Jul 09, 2014 at 10:27:24PM +, James Bottomley wrote:
If we fix it at source, why would there be any need to filter? That's
the reason the no_write_same flag was introduced. If we can find and
fix the bug, it can go back into the stable trees as a bug fix, hence
nothing should
On Thu, 10 Jul 2014, Hugh Dickins wrote:
On Thu, 10 Jul 2014, Sasha Levin wrote:
On 07/10/2014 01:55 PM, Hugh Dickins wrote:
And finally, (not) holding the i_mmap_mutex:
I don't understand what prompts you to show this particular task.
I imagine the dump shows lots of other tasks which
Signed-off-by: Søren Holm s...@sgh.dk
Cc: stable@vger.kernel.org
---
drivers/usb/serial/sierra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index 6f7f01e..c55548a 100644
--- a/drivers/usb/serial/sierra.c
+++
On Thu, Jul 10, 2014 at 03:02:29PM -0400, Sasha Levin wrote:
What if we move lockdep's acquisition point to after it actually got the
lock?
NAK, you want to do deadlock detection _before_ you're stuck in a
deadlock.
We'd miss deadlocks, but we don't care about them right now. Anyways, doesn't
On 07/11/2014 10:25 AM, Peter Zijlstra wrote:
On Thu, Jul 10, 2014 at 03:02:29PM -0400, Sasha Levin wrote:
What if we move lockdep's acquisition point to after it actually got the
lock?
NAK, you want to do deadlock detection _before_ you're stuck in a
deadlock.
We'd miss deadlocks, but we
On Fri, Jul 11, 2014 at 10:33:15AM +0200, Vlastimil Babka wrote:
Quoting Hugh from previous mail in this thread:
[ 363.600969] INFO: task trinity-c327:9203 blocked for more than 120
seconds.
[ 363.605359] Not tainted
3.16.0-rc4-next-20140708-sasha-00022-g94c7290-dirty #772
oh...
I just noticed that qcserial.c also handles this exact same USB-id.
Will that pose a problem or is this the way things should be?
Fredag den 11. juli 2014 09:53:53 skrev Søren Holm:
Signed-off-by: Søren Holm s...@sgh.dk
Cc: stable@vger.kernel.org
---
drivers/usb/serial/sierra.c | 1 +
Søren Holm s...@sgh.dk writes:
oh...
I just noticed that qcserial.c also handles this exact same USB-id.
Will that pose a problem or is this the way things should be?
The device should be handled by only one of the drivers. If it is going
to be handled by sierra driver then we should
On 07/11/2014 10:38 AM, Peter Zijlstra wrote:
On Fri, Jul 11, 2014 at 10:33:15AM +0200, Vlastimil Babka wrote:
Quoting Hugh from previous mail in this thread:
[ 363.600969] INFO: task trinity-c327:9203 blocked for more than 120 seconds.
[ 363.605359] Not tainted
Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork:
The device should be handled by only one of the drivers. If it is going
to be handled by sierra driver then we should remove the entry from
the qcserial driver.
My memory is on vacation... Was it so that the qcserial driver fails
on
qcserial from master on top of v3.14 works.
I applied this patch on 3.14.5
$ git diff v3.14..ba2c0922f74a57d794c10646c3a70ee5a5e14668 --
drivers/usb/serial/qcserial.c
In total that sums up to these commits :
0ce5fb5 usb: qcserial: add additional Sierra Wireless QMI devices
ff1fcd5 usb:
Hello Wei Liu,
On 10.07.2014 14:41, Wei Liu wrote:
On Wed, Jul 02, 2014 at 09:45:44AM +0200, Philipp Hahn wrote:
@Wei Liu: You said that the patch is only a quick hack to detect, if my
analysis is correct and a proper fix would be needed. For us the
attached patch works, as the problem does
Søren Holm s...@sgh.dk writes:
Fredag den 11. juli 2014 10:47:50 skrev Bjørn Mork:
The device should be handled by only one of the drivers. If it is going
to be handled by sierra driver then we should remove the entry from
the qcserial driver.
My memory is on vacation... Was it so that
On Fri, Jul 11, 2014 at 11:41:22AM +0200, Philipp Hahn wrote:
Hello Wei Liu,
On 10.07.2014 14:41, Wei Liu wrote:
On Wed, Jul 02, 2014 at 09:45:44AM +0200, Philipp Hahn wrote:
@Wei Liu: You said that the patch is only a quick hack to detect, if my
analysis is correct and a proper fix
Søren Holm s...@sgh.dk writes:
qcserial from master on top of v3.14 works.
Thanks for verifying. You did ensure that you can actually talk to the
serial ports?
I applied this patch on 3.14.5
$ git diff v3.14..ba2c0922f74a57d794c10646c3a70ee5a5e14668 --
drivers/usb/serial/qcserial.c
Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork:
Søren Holm s...@sgh.dk writes:
qcserial from master on top of v3.14 works.
Thanks for verifying. You did ensure that you can actually talk to the
serial ports?
I beleive so. wvdial where able to connect.
Actually, commit 51b9a752fa1c
Søren Holm s...@sgh.dk writes:
Fredag den 11. juli 2014 11:57:30 skrev Bjørn Mork:
Søren Holm s...@sgh.dk writes:
qcserial from master on top of v3.14 works.
Thanks for verifying. You did ensure that you can actually talk to the
serial ports?
I beleive so. wvdial where able to connect.
On Fri, Jul 11, 2014 at 11:41:22AM +0200, Philipp Hahn wrote:
Hello Wei Liu,
On 10.07.2014 14:41, Wei Liu wrote:
On Wed, Jul 02, 2014 at 09:45:44AM +0200, Philipp Hahn wrote:
@Wei Liu: You said that the patch is only a quick hack to detect, if my
analysis is correct and a proper fix
Hello Wei Liu,
On 11.07.2014 12:32, Wei Liu wrote:
On Fri, Jul 11, 2014 at 11:41:22AM +0200, Philipp Hahn wrote:
On 10.07.2014 14:41, Wei Liu wrote:
On Wed, Jul 02, 2014 at 09:45:44AM +0200, Philipp Hahn wrote:
@Wei Liu: You said that the patch is only a quick hack to
detect, if my analysis
On Fri, Jul 11, 2014 at 01:02:18PM +0200, Philipp Hahn wrote:
Hello Wei Liu,
On 11.07.2014 12:32, Wei Liu wrote:
On Fri, Jul 11, 2014 at 11:41:22AM +0200, Philipp Hahn wrote:
On 10.07.2014 14:41, Wei Liu wrote:
On Wed, Jul 02, 2014 at 09:45:44AM +0200, Philipp Hahn wrote:
@Wei Liu: You
First I notice that I don't even have qcserial on the target ... doh
lsusb gives this - so problably getting qcserial on the target will problably
solve it.
Bus 001 Device 003: ID 1199:68c0 Sierra Wireless, Inc.
Device Descriptor:
bLength18
bDescriptorType 1
Oh dear it's friday
# modinfo qcserial | grep 1199p68
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00*
alias: usb:v1199p68A9d*dc*dsc*dp*ic*isc*ip*in*
alias:
Søren Holm s...@sgh.dk writes:
Oh dear it's friday
# modinfo qcserial | grep 1199p68
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in03*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in02*
alias: usb:v1199p68A2d*dc*dsc*dp*ic*isc*ip*in00*
alias:
On 07/11/2014 04:25 AM, Peter Zijlstra wrote:
On Thu, Jul 10, 2014 at 03:02:29PM -0400, Sasha Levin wrote:
What if we move lockdep's acquisition point to after it actually got the
lock?
NAK, you want to do deadlock detection _before_ you're stuck in a
deadlock.
I didn't suggest to do it in
hch == hch@infradead org h...@infradead.org writes:
(Back from vacation: Bear with me while I'm catching up on two weeks of
linux-scsi stuff...)
hch I think the problem is a differnet one. If we have the logical
hch provisioning EVPD it configures what method to use, but if we don't
hch have
On (Wed) 09 Jul 2014 [12:07:25], Jason Cooper wrote:
Amit, Kees,
(snip)
I'm cooling to the idea of the init function for virtio-rng, and it
might be best just to admit that there's no way to seed the entropy pool
from the virtio-rng at probe time. After all, once userspace is up, the
On Fri, 11 Jul 2014, Sasha Levin wrote:
There's no easy way to see whether a given task is actually holding a lock or
is just blocking on it without going through all those tasks one by one and
looking at their trace.
I agree with you that The call trace is very clear on it that its not,
On Fri, Jul 11, 2014 at 06:56:26PM +0530, Amit Shah wrote:
On (Wed) 09 Jul 2014 [12:07:25], Jason Cooper wrote:
Amit, Kees,
(snip)
I'm cooling to the idea of the init function for virtio-rng, and it
might be best just to admit that there's no way to seed the entropy pool
from the
Hi Greg,
this is probably the correct place to send it. Sorry!
My brain needs a break after debugging this all day... :)
-- Forwarded Message --
Subject: Fwd: Re: GRO issue with kernel 3.4.94 (icmp fragmentation needed)
Date: Friday, 11. July 2014, 17:12:55
From: Thomas
On Fri, Jul 11, 2014 at 07:55:50AM -0700, Hugh Dickins wrote:
On Fri, 11 Jul 2014, Sasha Levin wrote:
There's no easy way to see whether a given task is actually holding a lock
or
is just blocking on it without going through all those tasks one by one and
looking at their trace.
Ok, then maybe it's not 3.14.5
It's a little bit unclean since the kernel is from this repo :
git://git.yoctoproject.org/linux-yocto-3.14.git commit
144595ef6215a0febfb8ee7d0c9e4eb2eaf93d61
Fact is that master supports the MC73xx, and I seem to be running a kernel
that does not.
Does it make
On Thu, 2014-07-10 at 10:11 -0700, Cong Wang wrote:
On Thu, Jul 10, 2014 at 6:44 AM, Stephen Hemminger
step...@networkplumber.org wrote:
After upgrading a router to Linux 3.2.60 most windows machines behind it
started experiencing connection stalls. Downgrade to 3.2.59 resolved the
On Fri, Jul 11, 2014 at 11:11 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Thu, 2014-07-10 at 10:11 -0700, Cong Wang wrote:
On Thu, Jul 10, 2014 at 6:44 AM, Stephen Hemminger
step...@networkplumber.org wrote:
After upgrading a router to Linux 3.2.60 most windows machines behind it
On Fri, 2014-07-11 at 11:38 -0700, Cong Wang wrote:
On Fri, Jul 11, 2014 at 11:11 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Thu, 2014-07-10 at 10:11 -0700, Cong Wang wrote:
On Thu, Jul 10, 2014 at 6:44 AM, Stephen Hemminger
step...@networkplumber.org wrote:
After upgrading a
From: Ben Hutchings b...@decadent.org.uk
Date: Fri, 11 Jul 2014 20:01:12 +0100
On Fri, 2014-07-11 at 11:38 -0700, Cong Wang wrote:
On Fri, Jul 11, 2014 at 11:11 AM, Ben Hutchings b...@decadent.org.uk wrote:
On Thu, 2014-07-10 at 10:11 -0700, Cong Wang wrote:
On Thu, Jul 10, 2014 at 6:44 AM,
From: gre...@linuxfoundation.org
Date: Mon, 07 Jul 2014 13:49:38 -0700
The patch below does not apply to the 3.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to
-Original Message-
From: Christoph Hellwig [mailto:h...@infradead.org]
Sent: Thursday, July 10, 2014 3:19 AM
To: KY Srinivasan
Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
oher...@suse.com; jbottom...@parallels.com; jasow...@redhat.com;
a...@canonical.com;
The patch titled
Subject: coredump: fix the setting of PF_DUMPCORE
has been added to the -mm tree. Its filename is
coredump-fix-the-setting-of-pf_dumpcore.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/coredump-fix-the-setting-of-pf_dumpcore.patch
David Miller da...@davemloft.net wrote:
From: Ben Hutchings b...@decadent.org.uk
Date: Fri, 11 Jul 2014 20:01:12 +0100
On Fri, 2014-07-11 at 11:38 -0700, Cong Wang wrote:
[..]
http://marc.info/?l=linux-netdevm=139949081418806w=2
This commit should have been reverted for older
The patch titled
Subject: mm/page-writeback.c: fix divide by zero in bdi_dirty_limits()
has been added to the -mm tree. Its filename is
mm-page-writebackc-fix-divide-by-zero-in-bdi_dirty_limits.patch
This patch should soon appear at
This is a note to let you know that I've just added the patch titled
platform_get_irq: Revert to platform_get_resource if of_irq_get fails
to my driver-core git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
in the driver-core-linus
This is a note to let you know that I've just added the patch titled
USB: serial: ftdi_sio: Add Infineon Triboard
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of
This is a note to let you know that I've just added the patch titled
phy: core: Fix error path in phy_create()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of
On 2014/6/18 13:20, David Miller wrote:
Please queue up the following networking bug fixes for v3.2, v3.4,
v3.10, v3.14, and v3.15, respectively.
Thanks!
Hi, David
I found the 3.10_box contained the fixes for CVE-2014-0181, but 3.4_box didn't.
Did you miss those, or you would queue
-Original Message-
From: h...@infradead.org [mailto:h...@infradead.org]
Sent: Thursday, July 10, 2014 11:32 PM
To: James Bottomley
Cc: KY Srinivasan; linux-ker...@vger.kernel.org; m...@mkp.net;
h...@infradead.org; de...@linuxdriverproject.org; a...@canonical.com;
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Friday, July 11, 2014 5:54 AM
To: h...@infradead.org
Cc: James Bottomley; KY Srinivasan; linux-ker...@vger.kernel.org;
de...@linuxdriverproject.org; a...@canonical.com; stable@vger.kernel.org;
47 matches
Mail list logo
