So what else is in those magic 2.12.00 official drivers besides this
eeprom magic? And why don't you printer a much more informative
message to the logs when you do fail a chip?
No matter what you say here, you're targetting end users with this
patch, even if you're just trying to put
On Thu, Oct 23, 2014 at 02:55:43PM -0400, Sasha Levin wrote:
> On 10/23/2014 02:39 PM, Paul E. McKenney wrote:
> > On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin wrote:
> >> On 10/13/2014 01:35 PM, Dave Jones wrote:
> >>> oday in "rcu stall while fuzzing" news:
> >>>
> >>> INFO: rcu_preempt
On Thu, Oct 23, 2014 at 10:51:59PM +0300, Yanko Kaneti wrote:
> On Thu-10/23/14-2014 08:33, Paul E. McKenney wrote:
> > On Thu, Oct 23, 2014 at 05:27:50AM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 23, 2014 at 09:09:26AM +0300, Yanko Kaneti wrote:
> > > > On Wed, 2014-10-22 at 16:24 -0700,
On Tue, 21 Oct 2014 18:28:11 +0200 Fabian Frederick wrote:
> Based on ext2_direct_IO
>
> --- a/fs/affs/file.c
> +++ b/fs/affs/file.c
> @@ -12,6 +12,7 @@
> * affs regular file handling primitives
> */
>
> +#include
> #include "affs.h"
>
> #if PAGE_SIZE < 4096
> @@ -392,6 +393,22 @@
Note: stub out endian-ness conversion for now.
We'll add a flag to control it for BE guests later.
Signed-off-by: Michael S. Tsirkin
---
This will be needed once __virtio16 typedefs come in.
drivers/net/tun.c | 34 +-
1 file changed, 17 insertions(+), 17
In order to help be able to easily count uses of Coccinelle for kernel
development I'd like to propose the use of the tag:
Generated-by: Coccinelle SmPL
This would save space on commits where it seems more than the above
number of words are used to describe this exact thing.
Luis
--
To
Ping ;)
Paul, should I resend or you do not think this can go via your rcu
tree?
On 09/28, Oleg Nesterov wrote:
>
> Paul, could you take these 2 doc patches? Assuming that you agree
> with the comments, of course.
>
> On 09/24, Paul E. McKenney wrote:
> >
> > On Tue, Sep 23, 2014 at 09:03:48PM
On 10/23, Paul E. McKenney wrote:
>
> OK, so making each pass through the loop a separate RCU read-side critical
> section might be considered to be suppressing notification of an error
> condition?
I agree, this change probably makes sense anyway. Personally I'd prefer
the version below (somehow
On Thu, Oct 23, 2014 at 03:37:59PM -0400, Dave Jones wrote:
> On Thu, Oct 23, 2014 at 12:28:07PM -0700, Paul E. McKenney wrote:
>
> > > > This one will require more looking. But did you do something like
> > > > create a pair of mutually recursive symlinks or something? ;-)
> > >
> > >
On Thu, Oct 23, 2014 at 11:43:22AM -0700, Guenter Roeck wrote:
> On Thu, Oct 23, 2014 at 08:03:57PM +0200, Andrew Lunn wrote:
> > > No, I am not saying that. The hwmon device's parent device will tell,
> > > which is how it works for all other hwmon devices.
> >
> > O.K, so parent is important.
>
On Thu, Oct 23, 2014 at 03:47:32PM -0400, Nicolas Pitre wrote:
> On Wed, 22 Oct 2014, Catalin Marinas wrote:
>
> > On Wed, Oct 22, 2014 at 05:06:23PM +0100, mathieu.poir...@linaro.org wrote:
> > > +#if __LINUX_ARM_ARCH__ >= 5
> >
> > My old ARMv5 book does not list LDRD/STRD. It looks like they
On Wed, 22 Oct 2014, Catalin Marinas wrote:
> On Wed, Oct 22, 2014 at 05:06:23PM +0100, mathieu.poir...@linaro.org wrote:
> > +#if __LINUX_ARM_ARCH__ >= 5
>
> My old ARMv5 book does not list LDRD/STRD. It looks like they only come
> with ARMv5TE. Are there any processors prior to this supported
On Thu, Oct 23, 2014 at 09:13:19PM +0200, Oleg Nesterov wrote:
> On 10/23, Paul E. McKenney wrote:
> >
> > On Mon, Oct 13, 2014 at 01:35:04PM -0400, Dave Jones wrote:
> > > Today in "rcu stall while fuzzing" news:
> > >
> > > INFO: rcu_preempt detected stalls on CPUs/tasks:
> > > Tasks blocked
v2: Perform check using product ID instead of vendor ID and
update half word before checksum rather than checksum
itself.
This patch provides the FTDI genuine product verification steps
as contained within the new 2.12.00 official release. It ensures
that counterfeiters don't exploit engineering
On 10/23, Alex Thorlton wrote:
>
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1661,6 +1661,18 @@ struct task_struct {
> unsigned intsequential_io;
> unsigned intsequential_io_avg;
> #endif
> +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> + struct callback_head
On Thu, 23 Oct 2014 08:53:14 -0400 Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a
On Thu, 2014-10-23 at 15:30 -0400, Eric Paris wrote:
> On Thu, 2014-10-23 at 12:20 -0700, Andy Lutomirski wrote:
> > On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
> > > On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> > >> On 10/22/2014 09:04 PM, Eric Paris wrote:
> > >> > git
On Thu, Oct 23, 2014 at 12:28:07PM -0700, Paul E. McKenney wrote:
> > > This one will require more looking. But did you do something like
> > > create a pair of mutually recursive symlinks or something? ;-)
> >
> > I'm not 100% sure, but this may have been on a box that I was running
>
I don't understand this patch, but...
On 10/23, Alex Thorlton wrote:
>
> static inline int khugepaged_fork(struct mm_struct *mm, struct mm_struct
> *oldmm)
> {
> + /* this will add task_pgcollapse_work to task_works */
> if (test_bit(MMF_VM_HUGEPAGE, >flags))
> - return
On Thu, Oct 23, 2014 at 02:40:18PM -0400, Dave Jones wrote:
> On Thu, Oct 23, 2014 at 11:32:32AM -0700, Paul E. McKenney wrote:
>
> > > trinity-c225R running task13448 646 32295 0x
> > > 880161ccfb28 0002 880161ccfe10 88000bf85e00
> > >
Fix a memory leak with scsi-mq triggered by commands with large data
transfer length.
Fixes: c53c6d6a68b1 ("scatterlist: allow chaining to preallocated chunks")
Cc: # 3.17.x
Signed-off-by: Tony Battersby
---
For inclusion in 3.18 and 3.17.x.
--- a/lib/scatterlist.c 2014-10-23
Fix an error path in SCSI_IOCTL_SEND_COMMAND that calls
blk_put_request(rq) on an invalid IS_ERR(rq) pointer.
Fixes: a492f075450f ("block,scsi: fixup blk_get_request dead queue
scenarios")
Signed-off-by: Tony Battersby
---
For inclusion in 3.18 only.
This does not conflict with the other
Here's the test code:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
// Whether to use a pthread mutex+condvar or do the raw futex operations. Either
// one will break.
// There's less user-space code involved with the non-pthread version,
Hey Michal,
On Tue, Oct 07, 2014 at 02:13:56PM +0200, Michal Marek wrote:
> This violates the principle of least surprise:
>
> make $file.s
> as -o $file.o $file.s
>
> should be equivalent to
>
> make $file.o
on a second thought, I think we don't care about this. Because we build
the objects
Trivial patchset to use standard unsigned long in drivers/
instead of long unsigned int
I'm just sending the summary; if you think it's worth being applied,
I'll send this patchset and smaller ones for other trees.
Regards,
Fabian
Fabian Frederick (13):
qla4xxx: replace long unsigned int by
pi_state_free and exit_pi_state_list both clean up futex_pi_state's.
exit_pi_state_list takes the hb lock first, and most callers of
pi_state_free do too. requeue_pi didn't, which causes lots of problems.
Move the pi_state_free calls in requeue_pi to before it drops the hb
locks which it's already
> Hi,
>
> on recent Linus git, I regulary get the following backtrace (since 3.17 around
> or so).
> HW is Intel Corporation Wireless 7260 (rev 83)
>
> [ 1774.340980] [ cut here ]
> [ 1774.341003] WARNING: CPU: 2 PID: 2402 at
> /home/arnd/Projekte/kernel/linux-
>
On Thu, Oct 23, 2014 at 12:15 PM, Eric Paris wrote:
> On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
>> On 10/22/2014 09:04 PM, Eric Paris wrote:
>> > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
>> > It was writing over %esp/pt_regs semi-randomly on i686
>From 45970693cad6c12da2d5ac7da3d2bd7a566170d7 Mon Sep 17 00:00:00 2001
From: Markus Elfring
Date: Thu, 23 Oct 2014 20:55:13 +0200
Subject: [PATCH] staging - rtl8188eu: Deletion of unnecessary checks before
three function calls
The functions kfree(), rtw_free_netdev() and vfree() test whether
(cc's added)
On Thu, 23 Oct 2014 17:56:53 +0100 Zubair Lutfullah Kakakhel
wrote:
> The default region counts are set to 1 with a comment saying empty
> dummy entry.
>
> If this is a dummy entry, should this be changed to 0?
>
> We have faced this in mips/kernel/setup.c arch_mem_init.
>
>
Hi,
on recent Linus git, I regulary get the following backtrace (since 3.17 around
or so).
HW is Intel Corporation Wireless 7260 (rev 83)
[ 1774.340980] [ cut here ]
[ 1774.341003] WARNING: CPU: 2 PID: 2402 at
On 10/23, Paul E. McKenney wrote:
>
> On Mon, Oct 13, 2014 at 01:35:04PM -0400, Dave Jones wrote:
> > Today in "rcu stall while fuzzing" news:
> >
> > INFO: rcu_preempt detected stalls on CPUs/tasks:
> > Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> > Tasks blocked on level-0
On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> On 10/22/2014 09:04 PM, Eric Paris wrote:
> > git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
> > It was writing over %esp/pt_regs semi-randomly on i686 with the expected
> > "system can't boot" results. As noted
Well, probably not something for stable/urgent...
On October 23, 2014 11:39:48 AM PDT, Andy Lutomirski
wrote:
>On 10/22/2014 09:04 PM, Eric Paris wrote:
>> git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very
>dumb.
>> It was writing over %esp/pt_regs semi-randomly on i686 with
On Wed, Oct 22, 2014 at 08:54:00PM +, Paul Zimmerman wrote:
> > From: Bartlomiej Zolnierkiewicz [mailto:b.zolnier...@samsung.com]
> > Sent: Wednesday, October 22, 2014 4:16 AM
> >
> > On Monday, October 20, 2014 01:52:01 PM dingu...@opensource.altera.com
> > wrote:
> > > From: Dinh Nguyen
>
On Thu, Oct 23, 2014 at 8:33 AM, Mark Rutland wrote:
> Since v1 [1]:
> * Add a positive acknowledgement for a configuration table DTB
> * Fixed a couple of typos in the commit message
>
> Ard, Leif, Roy, I've assumed your acks from v1 are still valid with the
> additional print. Please shout if
On Wed, Oct 22, 2014 at 12:23:05PM +0200, Johan Hovold wrote:
> On Wed, Oct 15, 2014 at 12:08:32PM -0500, Felipe Balbi wrote:
> > On Wed, Oct 15, 2014 at 07:06:28PM +0200, Johan Hovold wrote:
> > > On Wed, Oct 15, 2014 at 11:55:02AM -0500, Felipe Balbi wrote:
>
> > > > BTW, how do you test this
On 10/23/2014 02:39 PM, Paul E. McKenney wrote:
> On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin wrote:
>> On 10/13/2014 01:35 PM, Dave Jones wrote:
>>> oday in "rcu stall while fuzzing" news:
>>>
>>> INFO: rcu_preempt detected stalls on CPUs/tasks:
>>> Tasks blocked on level-0 rcu_node
On 10/23/2014 11:41 AM, Chris Healy wrote:
> Hi Guenter,
>
> I do not believe it is possible to know if an EEPROM is attached or not.
If we cannot do this, how about a DT/platform data set of properties
that describes the EEPROM when present?
>
> Chris
>
On Wed, Oct 22, 2014 at 12:18:49PM +0200, Johan Hovold wrote:
> On Fri, Oct 10, 2014 at 01:07:27PM -0500, Felipe Balbi wrote:
> > On Thu, Oct 09, 2014 at 09:06:31PM +0200, Johan Hovold wrote:
>
> > > - /* clear pending irqs, and set 1/second periodic,
> > > - * which we'll use instead of update
On Wed, Oct 22, 2014 at 12:50:11PM +0200, Johan Hovold wrote:
> On Sat, Oct 11, 2014 at 07:47:58PM -0500, Felipe Balbi wrote:
> > On Sat, Oct 11, 2014 at 12:12:01PM +0200, Johan Hovold wrote:
> > > On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
> > > > Hi,
> > > >
> > > > On Thu,
On Thu, Oct 23, 2014 at 10:29 AM, Joe Perches wrote:
> Commit 66b47b4a9dad ("checkpatch: look for common misspellings")
> made it difficult to use checkpatch via a symlink.
>
> Fix that and make a missing spelling.txt file non-fatal.
> Emit a warning when the spelling.txt file can not be opened.
On Thu, Oct 23, 2014 at 01:05:19PM -0500, Alex Thorlton wrote:
> I'll double check everything and do a resend here shortly.
Resend is out there. It looks like I got this one right (maybe next
time I'll get it on the first try :). Thanks for pointing out my error,
Rik!
- Alex
--
To unsubscribe
On Thu, Oct 23, 2014 at 11:23 AM, Andrew Morton
wrote:
> On Thu, 23 Oct 2014 09:39:09 -0700 Kees Cook wrote:
>
>> > I wonder if the chances of damage would be lower if we were to continue
>> > to accept the \r, but turn it into something else ("\r"?) when it is
>> > read.
>>
>> I think that
On Oct 14 2014 or thereabouts, Dmitry Torokhov wrote:
> On Tue, Oct 14, 2014 at 02:44:01PM -0700, Benson Leung wrote:
> > When using the device tree binding of compatible = "hid-over-i2c"
> > the i2c id table also needs to have that name in order to
> > auto load this driver.
> >
> >
Hi Guenter,
I do not believe it is possible to know if an EEPROM is attached or not.
Chris
From: Guenter Roeck [li...@roeck-us.net]
Sent: Thursday, October 23, 2014 9:40 AM
To: Andrew Lunn
Cc: net...@vger.kernel.org; David S. Miller; Florian Fainelli;
This patch just removes any call to start khugepaged for now. If we decide to
go forward with this new approach, then this patch will also dismantle the other
bits of khugepaged that we'll no longer need.
Signed-off-by: Alex Thorlton
Cc: Andrew Morton
Cc: Bob Liu
Cc: David Rientjes
Cc: Eric
This patch adds a /proc file to read out the information that we've added to the
task_struct. I'll need to split the information out to separate files, probably
in a subdirectory, change a few of the files to allow us to modify their values,
and it will need appropriate locks.
Signed-off-by:
This patch implements the actual functionality changes that I'm proposing. For
now I've just repurposed the existing khugepaged functions to do what we need.
Evenrtually they'll need to be completely separated, probably using a config
option to pick which method we want. We might also want to
This patch just adds the necessary bits to the task_struct so that the scans can
eventually be controlled on a per-mm basis. As I mentioned previously, we might
want to add some more counters here.
Signed-off-by: Alex Thorlton
Cc: Andrew Morton
Cc: Bob Liu
Cc: David Rientjes
Cc: Eric W.
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
Dear Gregory CLEMENT,
On Thu, 23 Oct 2014 20:14:27 +0200, Gregory CLEMENT wrote:
> +/*
> + * The following field (.smp) is stil needed to ensure backward
stil -> still
> + * compatibility with the old device trees
It would be good to be more specific here:
The following field (.smp)
On Thu, Oct 23, 2014 at 08:03:57PM +0200, Andrew Lunn wrote:
> > No, I am not saying that. The hwmon device's parent device will tell,
> > which is how it works for all other hwmon devices.
>
> O.K, so parent is important.
>
> > Not really. Again, the parent device provides that information.
On Tue, Oct 14, 2014 at 10:35:10PM -0400, Sasha Levin wrote:
> On 10/13/2014 01:35 PM, Dave Jones wrote:
> > oday in "rcu stall while fuzzing" news:
> >
> > INFO: rcu_preempt detected stalls on CPUs/tasks:
> > Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> > Tasks blocked on
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
>> [1.] One line summary of the problem: "BUG: sleeping function called from
>> invalid context at mm/slub.c:1250" after CPU hotplug
> I'm really not surprised.
>
>> When SoC
On Thu, Oct 23, 2014 at 11:32:32AM -0700, Paul E. McKenney wrote:
> > trinity-c225R running task13448 646 32295 0x
> > 880161ccfb28 0002 880161ccfe10 88000bf85e00
> > 001d4100 0003 880161ccffd8 001d4100
> >
On 10/22/2014 09:04 PM, Eric Paris wrote:
> git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
> It was writing over %esp/pt_regs semi-randomly on i686 with the expected
> "system can't boot" results. As noted in:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=85277
>
>
On Mon, Oct 13, 2014 at 01:35:04PM -0400, Dave Jones wrote:
> Today in "rcu stall while fuzzing" news:
>
> INFO: rcu_preempt detected stalls on CPUs/tasks:
> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
> Tasks blocked on level-0 rcu_node (CPUs 0-3): P766 P646
>
On 10/23/2014 12:23 PM, Fabian Frederick wrote:
> label 'out' is unused since commit 374f8fdea4aa
> ("scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND")
This got fixed up yesterday.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Oct 21, 2014 9:59 PM, "Seth Forshee" wrote:
>
> On Tue, Oct 21, 2014 at 02:27:13PM -0700, Andy Lutomirski wrote:
> > On Tue, Oct 21, 2014 at 2:21 PM, Seth Forshee
> >
> > > return s;
> > >
> > > fail:
> > > diff --git a/fs/xattr.c b/fs/xattr.c
> > > index 64e83efb742d..383bb9f2
On 10/23/2014 01:28 PM, Paul Zimmerman wrote:
>> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnier...@samsung.com]
>> Sent: Wednesday, October 22, 2014 5:26 AM
>>
>> On Monday, October 20, 2014 01:52:06 PM dingu...@opensource.altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> config
> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnier...@samsung.com]
> Sent: Wednesday, October 22, 2014 5:26 AM
>
> On Monday, October 20, 2014 01:52:06 PM dingu...@opensource.altera.com wrote:
> > From: Dinh Nguyen
> >
> > config USB_DWC2_PLATFORM
> > bool "DWC2 Platform"
> > - depends
On Thu, 23 Oct 2014 09:39:09 -0700 Kees Cook wrote:
> > I wonder if the chances of damage would be lower if we were to continue
> > to accept the \r, but turn it into something else ("\r"?) when it is
> > read.
>
> I think that would complicate things more than help them.
Why.
> If there's a
label 'out' is unused since commit 374f8fdea4aa
("scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND")
Signed-off-by: Fabian Frederick
---
block/scsi_ioctl.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index cc7927a..d1ae462 100644
---
On 10/23, Kirill Tkhai wrote:
>
> I'm agree generic helper is better. But probe_slab_address() has a sence
> if we know that SDBR is worse in our subject area.
And I still think it is worse.
> Less of code is
> easier to support :)
Sure, but ignoring the comments, SDBR needs the same code in
On 10/23, Oleg Nesterov wrote:
>
> Damn.
Yes.
> On 10/22, Oleg Nesterov wrote:
> >
> > +struct task_struct *task_rcu_dereference(struct task_struct **ptask)
> > +{
> > + struct task_struct *task;
> > + struct sighand_struct *sighand;
> > +
> > + task = rcu_dereference(*ptask);
> > + if
This commit implements CPU hotplug support for the Marvell Armada 38x
platform. Similarly to what was done for the Armada XP, this commit:
* Implements the ->cpu_die() function of SMP operations by calling
armada_38x_do_cpu_suspend() to enter the deep idle state for
CPUs going offline.
*
This patch removes the unneeded include of the armada-370-xp.h header.
It also moves some declarations from this file into more accurate
places.
Finally, it also adds a comment explaining that we can't remove yet the
smp field in the dt machine struct due to backward compatibly of the
device
During the secondary startup the SCU was assumed to be in normal
mode. It is not always the case, and especially after a kexec. This
commit adds the needed sequence to put the SCU in normal mode.
Signed-off-by: Gregory CLEMENT
---
arch/arm/mach-mvebu/headsmp-a9.S | 1 +
1 file changed, 1
This will allow reusing the same function in the secondary_startup
for the Cortex A9 SoC.
Signed-off-by: Gregory CLEMENT
---
arch/arm/mach-mvebu/pmsu_ll.S | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-mvebu/pmsu_ll.S
Hi,
This patch set adds the hot plug and also kexec support for the Armada
38x Socs.
The first patch was done in order to have the same code between Armada
XP and the Cortex A9 based mvebu SoCs. In order to ensure the the
backward compatibility for the device tree, it is only a preliminary
work
On 10/23/2014 08:13 PM, Dmitry Torokhov wrote:
On Thu, Oct 23, 2014 at 07:18:49PM +0300, Grygorii Strashko wrote:
On 10/23/2014 06:49 PM, Dmitry Torokhov wrote:
On Thu, Oct 23, 2014 at 05:22:58PM +0300, Grygorii Strashko wrote:
From: Geert Uytterhoeven
The existing pm_clk_add() allows to
> No, I am not saying that. The hwmon device's parent device will tell,
> which is how it works for all other hwmon devices.
O.K, so parent is important.
> Not really. Again, the parent device provides that information. libsensors,
> which is the preferred way of accessing sensors information
On Thu, Oct 23, 2014 at 01:55:13PM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/22/2014 10:49 PM, Alex Thorlton wrote:
>
> > Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
> > controls to task_struct Convert khugepaged scan functions to work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 10:49 PM, Alex Thorlton wrote:
> Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
> controls to task_struct Convert khugepaged scan functions to work
> with task_work Add /proc files to expose per-mm pgcollapse stats
Is it
On Thu, Oct 23, 2014 at 05:56:07PM +0200, Michal Hocko wrote:
> On Thu 23-10-14 10:42:07, Johannes Weiner wrote:
> > Having these functions and their documentation split out and somewhere
> > makes it harder, not easier, to follow what's going on.
> >
> > Inline them directly where charge moving
On Thu, Oct 23, 2014 at 4:33 PM, Laurent Pinchart
wrote:
> Casting physical addresses to unsigned long and using %lu truncates the
> values on systems where physical addresses are larger than 32 bits. Use
> %pa and get rid of the cast instead.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Geert
Forgot that I need a cross-compiler for s390 changes, so of course
they don't build :(
Will repost later, for now here's a fix.
---
drivers/s390/kvm/virtio_ccw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
On Thu, 2014-10-23 at 09:54 -0600, Alex Williamson wrote:
> On Thu, 2014-10-23 at 18:00 +0300, Marcel Apfelbaum wrote:
> > On Thu, 2014-10-23 at 08:49 -0600, Alex Williamson wrote:
> > > On Thu, 2014-10-23 at 17:33 +0300, Marcel Apfelbaum wrote:
> > > > On Thu, 2014-10-23 at 07:57 -0600, Alex
On Thu, 2014-10-23 at 22:48 +0530, ajay kanala wrote:
> Hi,
> any help?
You should CC the MIPS folks methinks, works fine in x86_64 at least.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Thu, Oct 23, 2014 at 06:54:59PM +0200, Andrew Lunn wrote:
> On Thu, Oct 23, 2014 at 09:27:55AM -0700, Guenter Roeck wrote:
> > On Thu, Oct 23, 2014 at 03:47:06PM +0200, Andrew Lunn wrote:
> > > > >>+static DEVICE_ATTR_RO(temp1_input);
> > > > >
> > > > >You probably want the number of
The feature has been removed from Xen. Also Linux cannot use it on ARM32
without CONFIG_ARM_LPAE.
Signed-off-by: Stefano Stabellini
Reviewed-by: David Vrabel
Acked-by: Ian Campbell
---
Changes in v2:
- remove the definition of XENFEAT_grant_map_identity.
---
arch/arm/xen/enlighten.c
Introduce an arch specific function to find out whether a particular dma
mapping operation needs to bounce on the swiotlb buffer.
On ARM and ARM64, if the page involved is a foreign page and the device
is not coherent, we need to bounce because at unmap time we cannot
execute any required cache
Merge xen/mm32.c into xen/mm.c.
As a consequence the code gets compiled on arm64 too: introduce a few
compat functions to actually be able to compile it.
Introduce xen_is_dma_coherent on arm64 and call into the dma_ops
functions from the xen_dma wrappers in page-coherent.h to handle
non-coherent
Introduce support for new hypercall GNTTABOP_cache_flush.
Use it to perform cache flashing on pages used for dma when necessary.
If GNTTABOP_cache_flush is supported by the hypervisor, we don't need to
bounce dma map operations that involve foreign grants and non-coherent
devices.
Signed-off-by:
Dom0 is not actually capable of issuing outer_inv_range or
outer_clean_range calls.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm32.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c
index a5a93fc..6153d61 100644
---
Introduce a utility function to check whether a device is dma coherent.
The current implementation is suboptimal. Let's rework it later in
common arch/arm code.
Use it to figure out whether we need to issue cache maintenance
operations instead of checking on the existence of a particular dma_ops
Hi all,
this patch series introduces support for GNTTABOP_cache_flush to perform
cache maintenance operation on foreign pages and reverts the current
code based on XENFEAT_grant_map_identity.
It also provides a very slow fallback by bouncing on the swiotlb buffer,
in case the hypercall is not
the following is needed on top of v4 virtio 1.0 support
that I sent. Will squash it in for v5.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 85a164e..e9018b4
> On 23 October 2014 at 18:29 Marcel Holtmann wrote:
>
>
> Hi Fabian,
>
> > use cpr for hci_cp_read_clock_offset instead of cp
> > (already defined above).
> >
> > Signed-off-by: Fabian Frederick
> > ---
> > net/bluetooth/hci_conn.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3
Commit 66b47b4a9dad ("checkpatch: look for common misspellings")
made it difficult to use checkpatch via a symlink.
Fix that and make a missing spelling.txt file non-fatal.
Emit a warning when the spelling.txt file can not be opened.
Reference: http://xkcd.com/1172/
Signed-off-by: Joe Perches
New Intel Atom processors (Baytrail and Cherryview), have a TSC that won't stop
in S3 state, say the TSC value won't be reset to 0 after resume. This feature
makes TSC a more reliable clocksource and could benefit the timekeeping code
during system suspend/resume cycle.
Signed-off-by: Jeremy
From: Meelis Roos
Date: Thu, 23 Oct 2014 02:22:36 +0300 (EEST)
>> Whilst I don't have access to my reproducer machine until tomorrow in
>> order to test this myself, I wanted to toss this patch your way so you
>> could get a head start on me.
>
> Unfortunately it fails earlier during the boot:
Hi Andre,
On Thu, Oct 23, 2014 at 10:00 AM, Andre Przywara wrote:
> Hi,
>
> I see a crash with 3.18-rc1 on a Juno board related to bpf_jit (see dump
> below). Userland tries to carry on afterwards, but eventually hangs in
> RCU stalls.
> The kernel has just CONFIG_BPF_JIT enabled, I guess Ubuntu
On Thu, 23 Oct 2014 19:25:01 +0300
"Michael S. Tsirkin" wrote:
> Gracefully handle failure to write device status.
> We really should handle other errors as well, but this one is needed for
> virtio 1.0 compliance.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/s390/kvm/virtio_ccw.c |
> The general idea of preemptively poisoning pages which contain deferred
> errors is fine though.
Agreed. I used to think that it wasn't likely to be very useful because in many
cases the UCNA errors are just a trail of breadcrumbs set by different units
on the chip as the poison passed through
Hi,
any help?
thanks in advance
-- Ajay
On Sat, Oct 18, 2014 at 4:41 PM, ajay kanala wrote:
> Hi,
> I have been trying to enable "threadirqs" command line option on
> 3.10.12 kernel and kernel crashes with NULL pointer access for
> kthreadd_task in wake_up_process function:
>
> [0.00]
On Wed, 22 Oct 2014, Joe Perches wrote:
> On Wed, 2014-10-22 at 16:25 +0300, Jani Nikula wrote:
>> On Wed, 22 Oct 2014, Joe Perches wrote:
>> > On Wed, 2014-10-22 at 13:43 +0300, Jani Nikula wrote:
>> >> Since commit 66b47b4a9dad00e45c049d79966de9a3a1f4d337
>> >> Author: Kees Cook
>> >> Date:
On 10/23/2014 11:14 AM, Christoph Hellwig wrote:
> On Thu, Oct 23, 2014 at 01:49:07PM +0300, Meelis Roos wrote:
>>> ping?
>>
>> Sorry, forgot to reply. Yes, it worked fine, on the initial Ultra 1 and
>> additionally on Ultra 2 too.
>
> Thanks!
>
> Can I get a review from Jens and some SCSI
On Thu, Oct 23, 2014 at 01:49:07PM +0300, Meelis Roos wrote:
> > ping?
>
> Sorry, forgot to reply. Yes, it worked fine, on the initial Ultra 1 and
> additionally on Ultra 2 too.
Thanks!
Can I get a review from Jens and some SCSI developers, too?
Jens, are you fine taking the blkdev.h revert
201 - 300 of 1456 matches
Mail list logo
