On 12 September 2013 12:17, Viresh Kumar wrote:
> Currently cpus never become zero as we clear mask only while there are
> more than one cpu in a policy... Wait let me see what's the cleanest way
> to get this fixed..
Okay, simply replace cpumask_first() with cpumask_any_but() in
cpufreq_nominate
On Wed, Sep 11, 2013 at 02:39:22PM +, Christoph Lameter wrote:
> On Thu, 22 Aug 2013, Joonsoo Kim wrote:
>
> > With build-time size checking, we can overload the RCU head over the LRU
> > of struct page to free pages of a slab in rcu context. This really help to
> > implement to overload the s
Signed-off-by: Fan Rong
---
arch/arm/include/asm/arch_timer.h| 11 +++
drivers/clocksource/Kconfig |8
drivers/clocksource/arm_arch_timer.c | 10 +-
3 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch_timer.h
b/ar
Signed-off-by: Fan Rong
---
arch/arm/boot/dts/sun7i-a20.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index bfedcb2..ce138f7 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.d
On 12 September 2013 12:16, Srivatsa S. Bhat
wrote:
> Of course, if we change the suspend/resume sequence and that fixes this, that
> would be like getting it for free, nobody would say no to it ;-)
Not really :)
Policy with 4 CPUs, 0,1,2,3, policy->cpu currently set to 1, 2 or 3...
We will rem
Signed-off-by: Fan Rong
---
arch/arm/boot/dts/sun7i-a20.dtsi |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 999ff45..bfedcb2 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot
On Wed, Sep 11, 2013 at 02:22:25PM +, Christoph Lameter wrote:
> On Wed, 11 Sep 2013, Joonsoo Kim wrote:
>
> > Anyway, could you review my previous patchset, that is, 'overload struct
> > slab
> > over struct page to reduce memory usage'? I'm not sure whether your answer
> > is
> > ack or no
Signed-off-by: Fan Rong
---
arch/arm/mach-sunxi/Makefile |2 +
arch/arm/mach-sunxi/headsmp.S | 12 ++
arch/arm/mach-sunxi/platform.h | 346
arch/arm/mach-sunxi/platsmp.c | 166 +++
arch/arm/mach-sunxi/sunxi.c|4 +
5 file
The patchs add smp support for Allwinner A20. It add cpuregister node in dts
forsmp configure. The patchs also add a options for phy count timer to replace
vir count timer as ARM arch timer clocksource. About ARM arch timer: 1. Current
kernel use vir count timer, vir count timer can be accessed
On Wed, Sep 11, 2013 at 02:30:03PM +, Christoph Lameter wrote:
> On Thu, 22 Aug 2013, Joonsoo Kim wrote:
>
> > And, therefore we should check pfmemalloc in page flag of first page,
> > but current implementation don't do that. virt_to_head_page(obj) just
> > return 'struct page' of that object
When backends (ex: efivars) have smaller registered buffers, the big_oops_buf
is quite too big for them as number of repeated occurences in the text captured
will be less. Patch takes care of adjusting the buffer size based on the
registered buffer size. cmpr values has been arrived after doing exp
On 09/12/2013 12:11 PM, Viresh Kumar wrote:
> On 12 September 2013 11:56, Srivatsa S. Bhat
> wrote:
>> I had the same thought when solving this bug.. We have had similar issues
>> with
>> CPU hotplug notifiers too: why are they invoked in the same order during both
>> CPU down and up, instead of
* Oleg Nesterov [2013-09-11 17:47:26]:
> Currently utask->depth is simply the number of allocated/pending
> return_instance's in uprobe_task->return_instances list.
>
> handle_trampoline() should decrement this counter every time we
> handle/free an instance, but due to typo it does this only if
On 12 September 2013 12:10, Srivatsa S. Bhat
wrote:
> That said, your fix doesn't look correct. See below.
I thought I was perfect !! :(
> ... and change this suitably (from 1 to 0 etc..) ? To add to it, it will look
> more
> clear as well:
>
> if (cpus == 0) {
> /* No cpus in policy, s
On 12 September 2013 12:00, Srivatsa S. Bhat
wrote:
> Looking at the rate at which we are bumping into each others thoughts, I think
> maybe we should switch from email to IRC ;-) ;-)
Unbelievable, Even I thought so this morning :)
One more thing that I wanted to say for some other threads..
You
On 09/12/2013 10:55 AM, Viresh Kumar wrote:
> This broke after a recent change "cedb70a cpufreq: Split
> __cpufreq_remove_dev()
> into two parts" from Srivatsa..
>
> Consider a scenario where we have two CPUs in a policy (0 & 1) and we are
> removing cpu 1. On the call to __cpufreq_remove_dev_pre
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/mfd/timberdale.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/mfd/timberdale
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/mfd/sm501.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/sm501.c b/driver
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/mfd/lpc_ich.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/lpc_ich.c b/dr
On 12 September 2013 11:56, Srivatsa S. Bhat
wrote:
> I had the same thought when solving this bug.. We have had similar issues with
> CPU hotplug notifiers too: why are they invoked in the same order during both
> CPU down and up, instead of reversing the order? I even had a patchset to
> perfor
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_mf624.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uio/uio_mf624.c b/
* Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Ingo Molnar wrote:
>
> > I saw those, he posted 'needs testing' patches. He still behaved
> > passive-aggressively, pretending that it was some difficult task to
> > perform, as if we were pulling his teeth.
>
> I need your review of those. I
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_sercos3.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uio/uio_sercos3.
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_netx.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uio/uio_netx.c b/dr
* Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Ingo Molnar wrote:
>
> > So my NAK stands: you are still in denial, you should stop the silly
> > arguing and you should stop wasting maintainer time. You need to
> > address PeterZ's review feedback and fix the bugs in your patches,
> > ASAP.
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_cif.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uio/uio_cif.c b/driv
The driver core clears the driver data to NULL after device_release
or on probe failure. Thus, it is not needed to manually clear the
device driver data to NULL.
Signed-off-by: Jingoo Han
---
drivers/uio/uio_aec.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/uio/uio_aec.c b/driv
* Arnaldo Carvalho de Melo wrote:
> I haven't performed all these tests when running on an older kernel,
> just checked that PERF_RECORD_MMAP was present, PERF_RECORD_MMAP2, as
> expected, were not, probably they will be present only for the
> synthesized events, right? The ones coming from t
On 09/12/2013 12:01 PM, Viresh Kumar wrote:
> On 12 September 2013 11:51, Srivatsa S. Bhat
> wrote:
>> That said, indeed currently there is no code in cpufreq that invokes the
>> function with last == new. So its not like we are masking an existing bug
>> with
>> this patch. If you like, perhaps
Hi Jingoo,
On Tuesday 23 July 2013 12:30 PM, Jingoo Han wrote:
> On Tuesday, July 23, 2013 3:30 PM, Kishon Vijay Abraham I wrote:
>> On Tuesday 23 July 2013 06:44 AM, Jingoo Han wrote:
>>> On Tuesday, July 23, 2013 12:04 AM, Kishon Vijay Abraham I wrote:
On Thursday 18 July 2013 10:51 AM, Jin
Separate out GTK codes to a shared object called libperf-gtk.so. This
time only GTK codes are built with -fPIC and libperf remains as is.
Now run GTK hist and annotation browser using libdl.
Cc: Andi Kleen
Reviewed-by: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile
On 12 September 2013 11:51, Srivatsa S. Bhat
wrote:
> That said, indeed currently there is no code in cpufreq that invokes the
> function with last == new. So its not like we are masking an existing bug with
> this patch. If you like, perhaps we can change this patch to print a warning
> when it g
On 09/12/2013 11:22 AM, Viresh Kumar wrote:
> Let me fix my mail first.. I was running out of time yesterday and so couldn't
> frame things correctly :)
>
> On 11 September 2013 17:29, Viresh Kumar wrote:
>> Okay.. There are two different ways in which cpufreq_add_dev() work
>> currently..
>>
>>
On 09/12/2013 11:39 AM, Viresh Kumar wrote:
> On 12 September 2013 01:43, Srivatsa S. Bhat
> wrote:
>> If update_policy_cpu() is invoked with the existing policy->cpu itself
>> as the new-cpu parameter, then a lot of things can go terribly wrong.
>>
>> In its present form, update_policy_cpu() alwa
On 09/11/2013 09:56 PM, Stephen Warren wrote:
On 08/27/2013 03:28 PM, Sebastian Hesselbarth wrote:
From: Stephen Warren
Tegra's board file currently initializes clocks much earlier than those
for most other ARM SoCs. The reason is:
* The PMC HW block is involved in the path of some interrupts
On 12 September 2013 01:43, Srivatsa S. Bhat
wrote:
> If update_policy_cpu() is invoked with the existing policy->cpu itself
> as the new-cpu parameter, then a lot of things can go terribly wrong.
>
> In its present form, update_policy_cpu() always assumes that the new-cpu
> is different from poli
On Wed, Sep 11, 2013 at 9:20 PM, Michael Opdenacker
wrote:
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/dec/tulip/de4x5.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
yup - that was easy to confirm.
> Signed-off-by: Michael Opdenacker
Acked
On 12 September 2013 01:16, Srivatsa S. Bhat
wrote:
> From: Srivatsa S. Bhat
> Subject: [PATCH] cpufreq: Restructure if/else block to avoid unintended
> behavior
>
> In __cpufreq_remove_dev_prepare(), the code which decides whether to remove
> the sysfs link or nominate a new policy cpu, is gove
On 12 September 2013 00:12, Srivatsa S. Bhat
wrote:
> OK, I took a second look at the code, and I suspect that applying the
> second patch might help. So can you try by applying both the patches
> please[1][2]?
>
> Basically here is my hunch: say CPUs 2 and 3 are part of a policy and
> 3 is the po
On Wed, 2013-09-11 at 15:34 +0200, Mike Galbraith wrote:
> On Wed, 2013-09-11 at 13:06 +0200, Peter Zijlstra wrote:
> > Mike does it fix the funny you saw?
>
> Yup, modulo test_need_resched() not existing in master.
...
> while I haven't yet booted Q6600 box, core2
> Toshiba Satellite lappy i
On 12 September 2013 00:33, Stephen Warren wrote:
> For the record, I'm testing on a 2-CPU system, so I'm not sure whether
> your explanation applies; it talks about CPUs 2 and 3 whereas I only
> have CPUs 0 and 1, but perhaps your explanation applies equally to any
> pair of CPUs?
It does apply
Hi Russell,
any comment on this one?
Thanks,
Michal
On 09/04/2013 04:44 PM, Michal Simek wrote:
> This patch is inpired by the patch for drvdata
> "device-core: Ensure drvdata = NULL when no driver is bound"
> (sha1: 0998d0631001288a5974afc0b2a5f568bcdecb4d)
>
> Also it fixes all occurences in
Le 12/09/2013 02:15, Benjamin Herrenschmidt a écrit :
On Wed, 2013-09-11 at 17:36 -0500, Scott Wood wrote:
I wonder why we don't start from entry 31 so we can actually make use of
that autodecrement. What will happen when we load the first normal TLB
entry later on? I don't see any setting of
devm_iounmap is called automatically that's why remove it from the code
dev_set_drvdata(dev, NULL) is called by generic code
after device_release or on probe failure.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 28 ++--
1 file changed, 6 insertions(+), 22 d
Simplify driver probe and release function.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 123cd70..fd9c430 100644
--- a/drivers/video/xilinxfb.c
+++ b/driv
s/op/pdev/ in xilinxfb_of_probe().
No functional chagnes.
Signed-off-by: Michal Simek
---
drivers/video/xilinxfb.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 84c664e..123cd70 100644
--- a/driver
Let me fix my mail first.. I was running out of time yesterday and so couldn't
frame things correctly :)
On 11 September 2013 17:29, Viresh Kumar wrote:
> Okay.. There are two different ways in which cpufreq_add_dev() work
> currently..
>
> Boot cluster (i.e. policy with boot CPU)
> -
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Roger Quadros
[ Upstream commit 47a64a13d54f6c669b00542848d5550be3d3310e ]
Set the ehci->resuming flag for the port we receive a remote
wakeup on so that resume signalling can be comple
* Arnaldo Carvalho de Melo wrote:
> Em Wed, Sep 11, 2013 at 07:55:03AM +0200, Ingo Molnar escreveu:
> > 16645 perf_event_open(0x1eb7f00, 0x, 0, 0x, 0) = -1 EINVAL
> > (Invalid argument)
> >
> > Caused by:
> >
> > 575a9aab0f85 perf tools: Add attr->mmap2 support
> >
> > We m
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Thomas Gleixner
[ Upstream commit 5ec2481b7b47a4005bb446d176e5d0257400c77d ]
smp_call_function_* must not be called from softirq context.
But clock_was_set() which calls on_each_cpu()
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sami Rahman
[ Upstream commit 7681156982026ebf7eafd7301eb0374d7648d068 ]
Added support for MMB Networks and Planet Innovation Ingeni ZigBee USB
devices using customized Silicon Labs' CP
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Dan Williams
[ Upstream commit 4cf76df06ecc852633ed927d91e01c83c33bc331 ]
Speaks AT on interfaces 5 (command & PPP) and 3 (secondary), other
interface protocols are unknown.
Signed-off
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Nicolin Chen
[ Upstream commit 2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 ]
Also fix return values for headphone switch updates.
Signed-off-by: Nicolin Chen
Signed-off-by: Mark Brown
C
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Barry Grussling
[ Upstream commit b579fa52f6be0b4157ca9cc5e94d44a2c89a7e95 ]
This patch adds support for the Schweitzer Engineering Laboratories
C662 USB cable based off the CP210x driv
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Vineet Gupta
[ Upstream commit e6c495a96ce02574e765d5140039a64c8d4e8c9e ]
zap_pte_range loops from @addr to @end. In the middle, if it runs out of
batching slots, TLB entries needs to
On Wed, Sep 04, 2013 at 02:18:46PM +0530, Raghavendra K T wrote:
> Signed-off-by: Raghavendra K T
> ---
> Changes in V2:
> Correction in the description of steal time and added msr info (Michael S
> Tsirkin)
Thanks. Some comments below:
> Documentation/virtual/kvm/cpuid.txt | 10 ++
Use devm_request_irq function.
Signed-off-by: Michal Simek
---
drivers/dma/pl330.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a562d24..58623dc 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2923,7
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Luiz Angelo Daros de Luca
[ Upstream commit 90625070c4253377025878c4e82feed8b35c7116 ]
This adds NetGear Managed Switch M4100 series, M5300 series, M7100 series
USB ID (0846:0110) to th
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Jeff Skirvin
[ Upstream commit 96f15f29038e58e1b0a96483e2b369ff446becf1 ]
This commit fixes a race condition in the isci driver abort task and SSP
device task management path. The race
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Eldad Zack
[ Upstream commit be2f93a4c4981b3646b6f98f477154411b8516cb ]
Return SNDRV_PCM_POS_XRUN (snd_pcm_uframes_t) instead of
SNDRV_PCM_STATE_XRUN (snd_pcm_state_t) from the pointer
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Saurav Kashyap
[ Upstream commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 ]
This fixes a regression where Xyratex controllers and disks were lost by the
driver:
https://bugzilla.kernel
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Alexandr \\\"Sky\\\" Ivanov"
[ Upstream commit ca24763588844b14f019ffc45c7df6d9e8f932c5 ]
Adding support for D-Link DWM-152/C1 and DWM-156/C1 devices.
DWM-152/C1:
T: Bus=01 L
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Josef Bacik
[ Upstream commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f ]
We aren't setting path->locks[level] when we resume a snapshot deletion which
means we won't unlock the buffer w
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: William Gulland
[ Upstream commit 2c7b871b9102c497ba8f972aa5d38532f05b654d ]
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfe
Using devres functions simplify driver error path.
- Use devm_kzalloc
- Use devm_request_irq
Signed-off-by: Michal Simek
---
---
drivers/uio/uio.c | 16
drivers/uio/uio_pdrv_genirq.c | 34 ++
2 files changed, 14 insertions(+), 36 delet
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Jan Beulich
[ Upstream commit 093b9c71b6e450e375f4646ba86faed0195ec7df ]
Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure
linear area is big enough on RX") xennet_f
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Johan Hovold
[ Upstream commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 ]
Allocated urbs and buffers were never freed on errors in open.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan
On 12 September 2013 06:13, Rafael J. Wysocki
wrote:
> Yes, if you can point to a specific driver having this problem.
There are so many of those (I know it because I went through almost all drivers
recently with my cleanup series): cpufreq-cpu0, omap-cpufreq,
exynos-cpufreq, etc..
They all do t
On Thu, Sep 12, 2013 at 02:03:41PM +0900, Tetsuo Handa wrote:
> Herbert Xu wrote:
> > This way at least you'll have a working system until your initramfs
> > tool is fixed to do the right thing.
>
> Thank you. But it is module-init-tools-3.9-21.el6_4 in RHEL 6.4.
> We can't wait until Red Hat back
As a rule its better not to break string (quoted inside "") in a print statement
even if it crosses 80 column boundary as that may introduce unwanted bugs and so
this patch rewrites one of the print statements..
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 4 ++--
1 file changed,
With a recent change the logic here is changed a bit and I just figured out it
is something we don't want.
Consider we have four CPUs (0,1,2,3) managed by a policy and policy->cpu is set
to 0. Now we are suspending and hence we call __cpufreq_remove_dev_prepare() for
cpu 1, 2 & 3..
With the curre
Nobody except cpufreq_remove_dev() is calling __cpufreq_remove_dev() and so we
don't need separate routines here. Lets merge code from __cpufreq_remove_dev()
to cpufreq_remove_dev() and get rid of __cpufreq_remove_dev().
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 26
This broke after a recent change "cedb70a cpufreq: Split __cpufreq_remove_dev()
into two parts" from Srivatsa..
Consider a scenario where we have two CPUs in a policy (0 & 1) and we are
removing cpu 1. On the call to __cpufreq_remove_dev_prepare() we have cleared 1
from policy->cpus and now on a c
Hi Rafael/Srivatsa,
These are some last minute fixes for 3.12. I have found them while looking at
the code to fix the latest suspend/resume crashes we see (Reported by Stephen)..
I believe at some place these are behind those crashes, otherwise people with a
single cluster or single policy couldn
We don't need a blank line just at start of a block, lets remove it.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5a64f66..28477eb 100644
--- a/drivers/cpufreq/cpufreq.c
++
On 09/04/2013 02:18 PM, Raghavendra K T wrote:
Signed-off-by: Raghavendra K T
---
Changes in V2:
Correction in the description of steal time and added msr info (Michael S
Tsirkin)
Documentation/virtual/kvm/cpuid.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Docume
Herbert Xu wrote:
> This way at least you'll have a working system until your initramfs
> tool is fixed to do the right thing.
Thank you. But it is module-init-tools-3.9-21.el6_4 in RHEL 6.4.
We can't wait until Red Hat backports module-init-tools >= 3.11 to RHEL 6.x.
Since most people are alread
Hi Rafael, Toshi,
When we hot-add an ACPI0004 device, we got the following warning:
acpi ACPI0004:01: Attempt to re-insert
The ACPI0004 device is a System Board in Fujitsu server, which has two
numa nodes (processors and memory).
It seems that we reserved the ACPI_NOTIFY_DEVICE_CHECK e
Hi Oleg,
On 09/09/2013 08:25 PM, Oleg Nesterov wrote:
On 09/09, Anton Arapov wrote:
On Sun, Sep 08, 2013 at 06:32:32PM +0200, Oleg Nesterov wrote:
Not sure, but I can be easily wrong... afaics we need something like below, no?
Anton?
Oleg, your guess is correct.
My original intention was to
On 09/12/2013 12:57 AM, KOSAKI Motohiro wrote:
> (9/3/13 4:39 AM), Janani Venkataraman wrote:
>> Hello,
>>
>> We are working on an infrastructure to create a system core file of a
>> specific
>> process at run-time, non-disruptively. It can also be extended to a
>> case where
>> a process is able t
On Mon, 2 Sep 2013 01:09:55 -0400 ycbzzj...@gmail.com wrote:
> From: Bian Yu
>
> When raid5 hit a fresh badblock, this badblock will flagged as unack
> badblock until md_update_sb is called.
> But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb
> in md_check_recovery, the bad
This removes two warnings where dma_addr_t variables were printed using
%x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t:
drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument
of type 'unsigned int', but argument 5 has type 'dma_addr_t'
drivers/gpu/hos
This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
dma_addr_t might then be 64-bit:
drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type
'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-sdma.c:1166:3: warning: f
Actually, here it is, but not formatted properly
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 816d1a2..146e712 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -240,14 +240,14 @@ serial_omap_baud_is_mode16(struct uart
Hi all,
Please do not add any code for v3.13 to your linux-next included branches
until after v3.12-rc1 is released.
Changes since 20130911:
The akpm tree gained a conflict against Linus' tree.
I have created to
On Wed, Sep 11, 2013 at 11:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 11, 2013 at 10:19:47PM +0300, Alexey Pelykh wrote:
>> On Wed, Sep 11, 2013 at 10:00 PM, Felipe Balbi wrote:
>> > On Wed, Sep 11, 2013 at 09:48:13PM +0300, Alexey Pelykh wrote:
>> >> On Wed, Sep 11, 2013 at 9:38 PM, Felipe
This resolves a warning where resource_size_t is larger than void *:
drivers/tty/serial/imx.c:1542:6: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
Since iomem_base is a void *, casting to unsigned long is safe.
It's unclear to me that this comparison
On Wed, Sep 11, 2013 at 08:43:19PM +0900, Tetsuo Handa wrote:
> Hello.
>
> I'm again having the boot failure problem due to commit 68411521 'Reinstate
> "crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform
> framework"' in linux.git .
OK, can you please try this patch on top
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/dec/tulip/de4x5.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/dec/tulip/de4x5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On Wed, Sep 11, 2013 at 08:38:32PM -0700, Eric W. Biederman wrote:
> Greg KH writes:
>
> > On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
> >> Hello,
> >>
> >> I'll send out multiple patchsets to separate out sysfs from driver
> >> core and kobject. The eventual goal is making sysfs
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/amd/sun3lance.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/amd/sun3lance.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Hello, Eric.
On Wed, Sep 11, 2013 at 08:39:27PM -0700, Eric W. Biederman wrote:
> @ns is more significant so it should come first.
>
> Where do we have the backwards convention of putting @name first?
Because @ns is optional and you end up with stupid stuff like
sysfs_xxx_ns(@param, @ns
On Wed, Sep 11, 2013 at 08:37:23PM -0700, Eric W. Biederman wrote:
> At a practical level you probably just want to copy the good parts of
> the structure of sysfs, instead of attempting to share code.
>
> Sharing code is likely to get you into all kinds of problems with short
> term hacks.
What?
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/ibm/ehea/ehea_main.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(
On 9/11/13 3:36 PM, Thavatchai Makphaibulchoke wrote:
> I seem to be seeing the same thing as Eric is seeing.
...
> For both filesystems, the security xattr are about 32.17 and 34.87 bytes
> respectively.
...
Can you triple-check the inode size on your fs, for good measure?
dumpe2fs -h /dev/wh
On Tue, Sep 10, 2013 at 05:44:15PM -0400, Vivek Goyal wrote:
> Hi,
>
> Matthew has been posting patches to lock down kernel either due to
> secureboot requirements or because of signed modules with signing
> enforced. In kernel lock down mode, kexec will be disabled and that
> means kdump will not
Tejun Heo writes:
> Some internal sysfs functions which take explicit namespace argument
> are weird in that they place the optional @ns in front of @name which
> is contrary to the established convention. This is confusing and
> error-prone especially as @ns and @name may be interchanged withou
[ 29.804534] [ INFO: suspicious RCU usage. ]
[ 29.804539] 3.11.0+ #5 Not tainted
[ 29.804541] ---
[ 29.804545] security/apparmor/include/policy.h:363 suspicious
rcu_dereference_check() usage!
[ 29.804548]
[ 29.804548] other info that might help us debug this:
Greg KH writes:
> On Wed, Sep 11, 2013 at 10:29:02PM -0400, Tejun Heo wrote:
>> Hello,
>>
>> I'll send out multiple patchsets to separate out sysfs from driver
>> core and kobject. The eventual goal is making sysfs modular enough so
>> that cgroup can replace its nightmarish cgroupfs implementa
Tejun Heo writes:
> Hello,
>
> I'll send out multiple patchsets to separate out sysfs from driver
> core and kobject. The eventual goal is making sysfs modular enough so
> that cgroup can replace its nightmarish cgroupfs implementation which
> repeated and worsened all the past mistakes of sysfs
1 - 100 of 697 matches
Mail list logo
