On Thu, Sep 6, 2018 at 5:46 PM Paul Burton wrote:
>
> Hi Jim,
>
> On Thu, Sep 06, 2018 at 04:42:56PM -0400, Jim Quinlan wrote:
> > Add MIPS as an arch that supports PCI_MSI_IRQ_DOMAIN and add
> > generation of msi.h in the MIPS arch.
>
> I guess the second part of this probably became untrue
When CPUs have different capacity because of RT/DL tasks or
micro-architecture or max frequency differences, there are situation where
the imbalance is not correctly set to migrate waiting task on the idle CPU.
The UC uses the force_balance case :
if (env->idle != CPU_NOT_IDLE &&
On Mon 10-09-18 14:32:16, Pavel Tatashin wrote:
> On Mon, Sep 10, 2018 at 10:19 AM Michal Hocko wrote:
> >
> > On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> > > Hi Michal,
> > >
> > > It is tricky, but probably can be done. Either change
> > > memmap_init_zone() or its caller to also cover
On Mon 10-09-18 14:32:16, Pavel Tatashin wrote:
> On Mon, Sep 10, 2018 at 10:19 AM Michal Hocko wrote:
> >
> > On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> > > Hi Michal,
> > >
> > > It is tricky, but probably can be done. Either change
> > > memmap_init_zone() or its caller to also cover
Hi,
I'm mounting an ext4 filesystem residing on an AHCI SATA disk via loop:
losetup -o 64424509440 --sizelimit 34359738368 /dev/loop0 /dev/sda
mount -t ext4 /dev/loop0 /mnt
Works perfectly on <= 4.4.155 (latest version on 4.4.x longterm branch)
On 4.9.126 (longterm branch) I get these
Hi,
I'm mounting an ext4 filesystem residing on an AHCI SATA disk via loop:
losetup -o 64424509440 --sizelimit 34359738368 /dev/loop0 /dev/sda
mount -t ext4 /dev/loop0 /mnt
Works perfectly on <= 4.4.155 (latest version on 4.4.x longterm branch)
On 4.9.126 (longterm branch) I get these
On Mon, 20 Aug 2018, RaviChandra Sadineni wrote:
> Currently on every resume we check for mkbp events and notify the
> clients. This helps in identifying the wakeup sources. But on devices
> that do not support mkbp protocol, we might end up querying key state of
> the keyboard in a loop which
On Mon, 20 Aug 2018, RaviChandra Sadineni wrote:
> Currently on every resume we check for mkbp events and notify the
> clients. This helps in identifying the wakeup sources. But on devices
> that do not support mkbp protocol, we might end up querying key state of
> the keyboard in a loop which
On Thu, Sep 6, 2018 at 5:50 PM Paul Burton wrote:
>
> Hi Jim,
>
> On Thu, Sep 06, 2018 at 04:42:57PM -0400, Jim Quinlan wrote:
> > Adds the PCIe nodes for the Broadcom STB PCIe root complex.
> >
> > Signed-off-by: Jim Quinlan
> > ---
> > arch/mips/boot/dts/brcm/bcm7425.dtsi | 28
On Thu, Sep 6, 2018 at 5:50 PM Paul Burton wrote:
>
> Hi Jim,
>
> On Thu, Sep 06, 2018 at 04:42:57PM -0400, Jim Quinlan wrote:
> > Adds the PCIe nodes for the Broadcom STB PCIe root complex.
> >
> > Signed-off-by: Jim Quinlan
> > ---
> > arch/mips/boot/dts/brcm/bcm7425.dtsi | 28
Jacek
On 09/08/2018 02:53 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 09/07/2018 03:52 PM, Dan Murphy wrote:
> [...]
>>>
And I think Jacek pointed out that the bindings references in this bindings
don't even exist.
I am thinking we need to deprecate this MFD driver and
Jacek
On 09/08/2018 02:53 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 09/07/2018 03:52 PM, Dan Murphy wrote:
> [...]
>>>
And I think Jacek pointed out that the bindings references in this bindings
don't even exist.
I am thinking we need to deprecate this MFD driver and
Em Fri, Sep 07, 2018 at 11:51:16AM +0300, Adrian Hunter escreveu:
> Commit 1c5aae7710bb ("perf machine: Create maps for x86 PTI entry
> trampolines") revealed a problem with maps__find_symbol_by_name() that
Can we have this with a Fixes: 1c5aae7710bb?
So that that, combined with the CC: stable,
Em Fri, Sep 07, 2018 at 11:51:16AM +0300, Adrian Hunter escreveu:
> Commit 1c5aae7710bb ("perf machine: Create maps for x86 PTI entry
> trampolines") revealed a problem with maps__find_symbol_by_name() that
Can we have this with a Fixes: 1c5aae7710bb?
So that that, combined with the CC: stable,
On Mon, Sep 10, 2018 at 10:19 AM Michal Hocko wrote:
>
> On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> > Hi Michal,
> >
> > It is tricky, but probably can be done. Either change
> > memmap_init_zone() or its caller to also cover the ends and starts of
> > unaligned sections to initialize and
On Mon, Sep 10, 2018 at 10:19 AM Michal Hocko wrote:
>
> On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> > Hi Michal,
> >
> > It is tricky, but probably can be done. Either change
> > memmap_init_zone() or its caller to also cover the ends and starts of
> > unaligned sections to initialize and
On Mon, Sep 10, 2018 at 7:19 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
>> > He has an irqchip that is called from the RISC-V exception handler
>> > when the interrupt flag is set in scause and then dispatches to one
>> > of: IPI, timer,
On Mon, Sep 10, 2018 at 7:19 PM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
>> > He has an irqchip that is called from the RISC-V exception handler
>> > when the interrupt flag is set in scause and then dispatches to one
>> > of: IPI, timer,
On Mon 10-09-18 22:03:17, zhong jiang wrote:
> The if condition can be removed if we use BUG_ON directly.
> The issule is detected with the help of Coccinelle.
typo here
Is this really worth changing? If anything I would really love to see
the BUG_ON going away rather than make a cosmetic
On Mon 10-09-18 22:03:17, zhong jiang wrote:
> The if condition can be removed if we use BUG_ON directly.
> The issule is detected with the help of Coccinelle.
typo here
Is this really worth changing? If anything I would really love to see
the BUG_ON going away rather than make a cosmetic
On 2018-09-10 16:56, Mark Brown wrote:
On Mon, Sep 10, 2018 at 09:27:09AM +0530, dk...@codeaurora.org wrote:
> The thing is, we want it to be 100% reliable, not 99.9% reliable. Is
> it somehow wrong to add the spinlock? ...or are you noticing
> performance problems with the spinlock there?
On 2018-09-10 16:56, Mark Brown wrote:
On Mon, Sep 10, 2018 at 09:27:09AM +0530, dk...@codeaurora.org wrote:
> The thing is, we want it to be 100% reliable, not 99.9% reliable. Is
> it somehow wrong to add the spinlock? ...or are you noticing
> performance problems with the spinlock there?
On Sat, 8 Sep 2018 at 22:17, Valentin Schneider
wrote:
>
> Hi Vincent,
>
> On 07/09/18 08:40, Vincent Guittot wrote:
> > When CPUs have different capacity because of RT/DL tasks or
> > micro-architecture or max frequency differences, there are situation where
> > the imbalance is not correctly
On Sat, 8 Sep 2018 at 22:17, Valentin Schneider
wrote:
>
> Hi Vincent,
>
> On 07/09/18 08:40, Vincent Guittot wrote:
> > When CPUs have different capacity because of RT/DL tasks or
> > micro-architecture or max frequency differences, there are situation where
> > the imbalance is not correctly
On Mon, 2018-09-10 at 08:38 +, Tianyu Lan wrote:
> Add flush range call back in the kvm_x86_ops and platform can use it
> to register its associated function. The parameter "kvm_tlb_range"
> accepts a single range and flush list which contains a list of ranges.
>
> Signed-off-by: Lan Tianyu
On Mon, 2018-09-10 at 08:38 +, Tianyu Lan wrote:
> Add flush range call back in the kvm_x86_ops and platform can use it
> to register its associated function. The parameter "kvm_tlb_range"
> accepts a single range and flush list which contains a list of ranges.
>
> Signed-off-by: Lan Tianyu
On Sat, Sep 08, 2018 at 04:36:19PM +0800, zhong jiang wrote:
> kmemdup has implemented the function that kzalloc() + memcpy() will
> do. and we prefer to use the kmemdup rather than the open coded
> implementation.
Please submit patches using subject lines reflecting the style for the
subsystem.
On Sat, Sep 08, 2018 at 04:36:19PM +0800, zhong jiang wrote:
> kmemdup has implemented the function that kzalloc() + memcpy() will
> do. and we prefer to use the kmemdup rather than the open coded
> implementation.
Please submit patches using subject lines reflecting the style for the
subsystem.
On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> Hi Michal,
>
> It is tricky, but probably can be done. Either change
> memmap_init_zone() or its caller to also cover the ends and starts of
> unaligned sections to initialize and reserve pages.
>
> The same thing would also need to be done in
On Mon 10-09-18 14:11:45, Pavel Tatashin wrote:
> Hi Michal,
>
> It is tricky, but probably can be done. Either change
> memmap_init_zone() or its caller to also cover the ends and starts of
> unaligned sections to initialize and reserve pages.
>
> The same thing would also need to be done in
On 29 June 2018 at 08:19, Viresh Kumar wrote:
> Multiple generic power domains for a device are supported with the help
> of virtual devices, which are created for each device-genpd pair. These
What "device-genpd" pair are you referring to?
> are the device structures which are attached to the
On 29 June 2018 at 08:19, Viresh Kumar wrote:
> Multiple generic power domains for a device are supported with the help
> of virtual devices, which are created for each device-genpd pair. These
What "device-genpd" pair are you referring to?
> are the device structures which are attached to the
Em Mon, Sep 10, 2018 at 10:47:54AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Sep 10, 2018 at 12:31:54PM +0200, Jiri Olsa escreveu:
> > On Mon, Sep 10, 2018 at 03:28:11PM +0530, Ravi Bangoria wrote:
> > > We don't have perf test available to test watchpoint functionality.
> > > Add simple
Em Mon, Sep 10, 2018 at 10:47:54AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Sep 10, 2018 at 12:31:54PM +0200, Jiri Olsa escreveu:
> > On Mon, Sep 10, 2018 at 03:28:11PM +0530, Ravi Bangoria wrote:
> > > We don't have perf test available to test watchpoint functionality.
> > > Add simple
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > >
> > > By default qemu doesn't use memfd for backing storage, you have
> > > to
> > > explicitly
Am Montag, den 10.09.2018, 15:30 +0200 schrieb Gerd Hoffmann:
> On Mon, Sep 10, 2018 at 01:31:08PM +0200, Gert Wollny wrote:
> > Am Montag, den 10.09.2018, 12:53 +0200 schrieb Gerd Hoffmann:
> > >
> > > By default qemu doesn't use memfd for backing storage, you have
> > > to
> > > explicitly
Hi!
> > Next -0910 seems to boot ok... but when I hit the power button to
> > suspend the machine... Full dmesg is in the attachment.
>
> Is this a next only issue or is this happening on Linus tree as well?
I believe this only happens in next. I'm pretty sure v4.19-rc1 was
ok. Let me check
Hi!
> > Next -0910 seems to boot ok... but when I hit the power button to
> > suspend the machine... Full dmesg is in the attachment.
>
> Is this a next only issue or is this happening on Linus tree as well?
I believe this only happens in next. I'm pretty sure v4.19-rc1 was
ok. Let me check
The if condition can be removed if we use BUG_ON directly.
The issule is detected with the help of Coccinelle.
Signed-off-by: zhong jiang
---
mm/memory_hotplug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index
The if condition can be removed if we use BUG_ON directly.
The issule is detected with the help of Coccinelle.
Signed-off-by: zhong jiang
---
mm/memory_hotplug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index
On Mon, Sep 10, 2018 at 10:42:05AM +0100, Vladimir Murzin wrote:
>On 02/09/18 14:07, Sasha Levin wrote:
>> From: Vladimir Murzin
>>
>> [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ]
>>
>> ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed
>> Sec_frac (bits [23:20]):
On Mon, Sep 10, 2018 at 10:42:05AM +0100, Vladimir Murzin wrote:
>On 02/09/18 14:07, Sasha Levin wrote:
>> From: Vladimir Murzin
>>
>> [ Upstream commit c803ce3f18bd93b3b4a15d1da0c5b5ebc60e0b85 ]
>>
>> ARMv8R adds support for VBAR and updates ID_PFR1 with the new filed
>> Sec_frac (bits [23:20]):
On Thu, Aug 09, 2018 at 02:57:53PM +0100, Dietmar Eggemann wrote:
> LB_BIAS allows the adjustment on how conservative load should be
> balanced.
> It is very likely that LB_BIAS' influence on load balancing can be
> neglected (see test results below). This is further supported by:
>
> (1)
On Thu, Aug 09, 2018 at 02:57:53PM +0100, Dietmar Eggemann wrote:
> LB_BIAS allows the adjustment on how conservative load should be
> balanced.
> It is very likely that LB_BIAS' influence on load balancing can be
> neglected (see test results below). This is further supported by:
>
> (1)
Hi Michal,
It is tricky, but probably can be done. Either change
memmap_init_zone() or its caller to also cover the ends and starts of
unaligned sections to initialize and reserve pages.
The same thing would also need to be done in deferred_init_memmap() to
cover the deferred init case.
For
Hi Michal,
It is tricky, but probably can be done. Either change
memmap_init_zone() or its caller to also cover the ends and starts of
unaligned sections to initialize and reserve pages.
The same thing would also need to be done in deferred_init_memmap() to
cover the deferred init case.
For
On Mon, Sep 10, 2018 at 02:48:45PM +0200, Thomas Gleixner wrote:
> Ville,
>
> On Mon, 10 Sep 2018, Ville Syrjala wrote:
>
> > From: Ville Syrjälä
> >
> > This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f.
> >
> > It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010
> >
On Mon, Sep 10, 2018 at 02:48:45PM +0200, Thomas Gleixner wrote:
> Ville,
>
> On Mon, 10 Sep 2018, Ville Syrjala wrote:
>
> > From: Ville Syrjälä
> >
> > This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f.
> >
> > It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010
> >
On 2018-08-30 09:55:03 [+0200], To K. Y. Srinivasan wrote:
> On !RT the header file get_irq_regs() gets pulled in via other header files.
> On
> RT it does not and the build fails:
>
> drivers/hv/vmbus_drv.c:975 implicit declaration of function
> ‘get_irq_regs’
On 2018-08-30 09:55:03 [+0200], To K. Y. Srinivasan wrote:
> On !RT the header file get_irq_regs() gets pulled in via other header files.
> On
> RT it does not and the build fails:
>
> drivers/hv/vmbus_drv.c:975 implicit declaration of function
> ‘get_irq_regs’
On Tue, 14 Aug 2018, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Actually honor probe deferral in trying to get the GPIO interrupt as
> of_get_named_gpio_flags() in stmpe_of_probe() may as well just do so.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/mfd/stmpe.c | 2 ++
>
On Tue, 14 Aug 2018, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Actually honor probe deferral in trying to get the GPIO interrupt as
> of_get_named_gpio_flags() in stmpe_of_probe() may as well just do so.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> drivers/mfd/stmpe.c | 2 ++
>
* Lee Jones [180910 11:18]:
> On Thu, 30 Aug 2018, Tony Lindgren wrote:
>
> > Lee,
> >
> > * Tony Lindgren [180425 07:31]:
> > > It currently only works if the parent bus uses "simple-bus". We
> > > currently try to probe children with non-existing compatible values.
> > > And we're missing
* Lee Jones [180910 11:18]:
> On Thu, 30 Aug 2018, Tony Lindgren wrote:
>
> > Lee,
> >
> > * Tony Lindgren [180425 07:31]:
> > > It currently only works if the parent bus uses "simple-bus". We
> > > currently try to probe children with non-existing compatible values.
> > > And we're missing
On Mon 10-09-18 13:46:45, Pavel Tatashin wrote:
>
>
> On 9/10/18 9:17 AM, Michal Hocko wrote:
> > [Cc Pavel]
> >
> > On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
> >> If memory end is not aligned with the linux memory section boundary, such
> >> a section is only partly initialized. This
On Mon 10-09-18 13:46:45, Pavel Tatashin wrote:
>
>
> On 9/10/18 9:17 AM, Michal Hocko wrote:
> > [Cc Pavel]
> >
> > On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
> >> If memory end is not aligned with the linux memory section boundary, such
> >> a section is only partly initialized. This
Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
> * Alexey Budankov wrote:
> > On 10.09.2018 12:18, Ingo Molnar wrote:
> > > * Alexey Budankov wrote:
> > >> Currently in record mode the tool implements trace writing serially.
> > >> The algorithm loops over mapped per-cpu data
On Tue, 14 Aug 2018, michael.henner...@analog.com wrote:
> From: Michael Hennerich
>
> no functional changes
>
> Signed-off-by: Michael Hennerich
> ---
> drivers/mfd/adp5520.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services
Em Mon, Sep 10, 2018 at 02:06:43PM +0200, Ingo Molnar escreveu:
> * Alexey Budankov wrote:
> > On 10.09.2018 12:18, Ingo Molnar wrote:
> > > * Alexey Budankov wrote:
> > >> Currently in record mode the tool implements trace writing serially.
> > >> The algorithm loops over mapped per-cpu data
On Tue, 14 Aug 2018, michael.henner...@analog.com wrote:
> From: Michael Hennerich
>
> no functional changes
>
> Signed-off-by: Michael Hennerich
> ---
> drivers/mfd/adp5520.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services
Hi,
Am Donnerstag, 6. September 2018, 18:39:56 CEST schrieb Katsuhiro Suzuki:
> This patch adds port and endpoint of i2s and spdif nodes for rk3328.
> Because to use modern sound card interface such as audio-graph-card.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
>
Hi,
Am Donnerstag, 6. September 2018, 18:39:56 CEST schrieb Katsuhiro Suzuki:
> This patch adds port and endpoint of i2s and spdif nodes for rk3328.
> Because to use modern sound card interface such as audio-graph-card.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
>
On Sat, Aug 11, 2018 at 11:00:37AM +0800, Jia-Ju Bai wrote:
You forgot to Cc the person who wrote this code...
> kernel/locking/rtmutex.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index
On Sat, Aug 11, 2018 at 11:00:37AM +0800, Jia-Ju Bai wrote:
You forgot to Cc the person who wrote this code...
> kernel/locking/rtmutex.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
> index
It was possible that sync_rcu_exp_select_cpus() enqueued something on
CPU0 while CPU0 was offline. Such a work item wouldn't be processed
until CPU0 gets back online. This problem was addressed in commit
fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being offline"). I
don't think the issue
It was possible that sync_rcu_exp_select_cpus() enqueued something on
CPU0 while CPU0 was offline. Such a work item wouldn't be processed
until CPU0 gets back online. This problem was addressed in commit
fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being offline"). I
don't think the issue
On Sat, Sep 8, 2018 at 7:15 AM Thomas Gleixner wrote:
>
> On Mon, 27 Aug 2018, Rob Herring wrote:
>
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Thomas Gleixner
> > Cc: Jason Cooper
> > Cc:
On Sat, Sep 8, 2018 at 7:15 AM Thomas Gleixner wrote:
>
> On Mon, 27 Aug 2018, Rob Herring wrote:
>
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Thomas Gleixner
> > Cc: Jason Cooper
> > Cc:
On Mon, Sep 10, 2018 at 8:38 AM Christoph Hellwig wrote:
>
> On Wed, Sep 05, 2018 at 02:37:31PM -0500, Rob Herring wrote:
> > Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
> > has the side effect of defaulting to iterating using "cpu" node names in
> > preference to the
On Mon, Sep 10, 2018 at 8:38 AM Christoph Hellwig wrote:
>
> On Wed, Sep 05, 2018 at 02:37:31PM -0500, Rob Herring wrote:
> > Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
> > has the side effect of defaulting to iterating using "cpu" node names in
> > preference to the
From: Linus Torvalds
> ...
> You could literally do something like
>
> /* Make it canonical in case we flipped the high bit */
> addr = (long)(addr<<1)>>1;
Isn't it safer to use a mask and let the compiler decide if two
shifts are a good implementation?
addr &= ~HIGH_MAGIC_BIT;
From: Linus Torvalds
> ...
> You could literally do something like
>
> /* Make it canonical in case we flipped the high bit */
> addr = (long)(addr<<1)>>1;
Isn't it safer to use a mask and let the compiler decide if two
shifts are a good implementation?
addr &= ~HIGH_MAGIC_BIT;
On 2018/9/8 22:17, Jonathan Cameron wrote:
> On Sat, 8 Sep 2018 17:59:13 +0530
> Himanshu Jha wrote:
>
>> On Sat, Sep 08, 2018 at 06:57:36PM +0800, zhong jiang wrote:
>>> The iterator in for_each_set_bit is never null, therefore, remove
>>> the redundant conditional judgment.
>>>
>>>
On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
> > He has an irqchip that is called from the RISC-V exception handler
> > when the interrupt flag is set in scause and then dispatches to one
> > of: IPI, timer, actual irqchip.
>
> So the per cpu timer is the only per cpu
On 2018/9/8 22:17, Jonathan Cameron wrote:
> On Sat, 8 Sep 2018 17:59:13 +0530
> Himanshu Jha wrote:
>
>> On Sat, Sep 08, 2018 at 06:57:36PM +0800, zhong jiang wrote:
>>> The iterator in for_each_set_bit is never null, therefore, remove
>>> the redundant conditional judgment.
>>>
>>>
On Mon, Sep 10, 2018 at 03:45:42PM +0200, Thomas Gleixner wrote:
> > He has an irqchip that is called from the RISC-V exception handler
> > when the interrupt flag is set in scause and then dispatches to one
> > of: IPI, timer, actual irqchip.
>
> So the per cpu timer is the only per cpu
On Fri 07-09-18 16:30:59, Shuah Khan wrote:
> On 09/07/2018 02:34 AM, Michal Hocko wrote:
> > On Thu 06-09-18 15:53:34, Shuah Khan wrote:
> > [...]
> >> A few critical allocations could be satisfied and root cgroup prevails. It
> >> is not the
> >> intent to have exclusivity at the expense of the
On Fri 07-09-18 16:30:59, Shuah Khan wrote:
> On 09/07/2018 02:34 AM, Michal Hocko wrote:
> > On Thu 06-09-18 15:53:34, Shuah Khan wrote:
> > [...]
> >> A few critical allocations could be satisfied and root cgroup prevails. It
> >> is not the
> >> intent to have exclusivity at the expense of the
Em Mon, Sep 10, 2018 at 12:31:54PM +0200, Jiri Olsa escreveu:
> On Mon, Sep 10, 2018 at 03:28:11PM +0530, Ravi Bangoria wrote:
> > We don't have perf test available to test watchpoint functionality.
> > Add simple set of tests:
> > - Read only watchpoint
> > - Write only watchpoint
> > - Read
Em Mon, Sep 10, 2018 at 12:31:54PM +0200, Jiri Olsa escreveu:
> On Mon, Sep 10, 2018 at 03:28:11PM +0530, Ravi Bangoria wrote:
> > We don't have perf test available to test watchpoint functionality.
> > Add simple set of tests:
> > - Read only watchpoint
> > - Write only watchpoint
> > - Read
On Mon, 10 Sep 2018, Benson Leung wrote:
> On Mon, Sep 10, 2018 at 5:12 PM Lee Jones wrote:
> >
> > On Fri, 07 Sep 2018, Benson Leung wrote:
> >
> > > Hi Enric,
> > >
> > > On Wed, Jul 18, 2018 at 06:09:56PM +0200, Enric Balletbo i Serra wrote:
> > > > cros-ec includes inside the MFD subsystem,
On Mon, 10 Sep 2018, Benson Leung wrote:
> On Mon, Sep 10, 2018 at 5:12 PM Lee Jones wrote:
> >
> > On Fri, 07 Sep 2018, Benson Leung wrote:
> >
> > > Hi Enric,
> > >
> > > On Wed, Jul 18, 2018 at 06:09:56PM +0200, Enric Balletbo i Serra wrote:
> > > > cros-ec includes inside the MFD subsystem,
On Mon, Sep 10, 2018 at 4:51 AM Andre Kalb wrote:
>
> Hi Frank,
>
> > -Ursprüngliche Nachricht-
> > Von: Frank Rowand [mailto:frowand.l...@gmail.com]
> > Gesendet: Freitag, 7. September 2018 22:01
> > An: Andre Kalb; robh...@kernel.org; devicet...@vger.kernel.org; linux-
> >
On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:
> This patch provides arch_show_interrupts() implementation to
> show IPI stats via /proc/interrupts.
>
> Now the contents of /proc/interrupts" will look like below:
>CPU0 CPU1 CPU2 CPU3
> 8: 17
On Mon, Sep 10, 2018 at 4:51 AM Andre Kalb wrote:
>
> Hi Frank,
>
> > -Ursprüngliche Nachricht-
> > Von: Frank Rowand [mailto:frowand.l...@gmail.com]
> > Gesendet: Freitag, 7. September 2018 22:01
> > An: Andre Kalb; robh...@kernel.org; devicet...@vger.kernel.org; linux-
> >
On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:
> This patch provides arch_show_interrupts() implementation to
> show IPI stats via /proc/interrupts.
>
> Now the contents of /proc/interrupts" will look like below:
>CPU0 CPU1 CPU2 CPU3
> 8: 17
On 9/10/18 9:17 AM, Michal Hocko wrote:
> [Cc Pavel]
>
> On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
>> If memory end is not aligned with the linux memory section boundary, such
>> a section is only partly initialized. This may lead to VM_BUG_ON due to
>> uninitialized struct pages access
On 9/10/18 9:17 AM, Michal Hocko wrote:
> [Cc Pavel]
>
> On Mon 10-09-18 14:35:27, Mikhail Zaslonko wrote:
>> If memory end is not aligned with the linux memory section boundary, such
>> a section is only partly initialized. This may lead to VM_BUG_ON due to
>> uninitialized struct pages access
On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > > Just a few weeks ago you said the contrary:
> > > >
> > > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> > >
> > > Sigh. Yes. Now that you remind
On Mon, 10 Sep 2018, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > > Just a few weeks ago you said the contrary:
> > > >
> > > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> > >
> > > Sigh. Yes. Now that you remind
On Mon, 10 Sep 2018, Nicolas Ferre wrote:
> Hi Lee,
>
> On 10/09/2018 at 11:48, Lee Jones wrote:
> > On Tue, 04 Sep 2018, Radu Pirea wrote:
> > > Well, this is the 12th version of this patch series.
> > > In this version I fixed a warning from kbuild-robot and I have no idea
> > > how I forgot
On Mon, 10 Sep 2018, Nicolas Ferre wrote:
> Hi Lee,
>
> On 10/09/2018 at 11:48, Lee Jones wrote:
> > On Tue, 04 Sep 2018, Radu Pirea wrote:
> > > Well, this is the 12th version of this patch series.
> > > In this version I fixed a warning from kbuild-robot and I have no idea
> > > how I forgot
/commits/Baoquan-He/x86-mm-KASLR-Fix-the-wrong-calculation-of-kalsr-region-initial-size/20180910-205421
config: i386-randconfig-x077-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error
/commits/Baoquan-He/x86-mm-KASLR-Fix-the-wrong-calculation-of-kalsr-region-initial-size/20180910-205421
config: i386-randconfig-x077-201836 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error
On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > Just a few weeks ago you said the contrary:
> > >
> > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> >
> > Sigh. Yes. Now that you remind me.
>
> Just for clarification. I had the impression
On Mon, Sep 10, 2018 at 03:37:31PM +0200, Thomas Gleixner wrote:
> > > Just a few weeks ago you said the contrary:
> > >
> > > http://lists.infradead.org/pipermail/linux-riscv/2018-August/000943.html
> >
> > Sigh. Yes. Now that you remind me.
>
> Just for clarification. I had the impression
On 09/06/2018 04:49 AM, Pierre Morel wrote:
On 13/08/2018 23:48, Tony Krowiak wrote:
From: Tony Krowiak
Registers the matrix device created by the VFIO AP device
driver with the VFIO mediated device framework.
Registering the matrix device will create the sysfs
structures needed to create
Hi Michael,
Do you plan to pull it for 4.20 ?
Cheers,
Laurent.
On 20/08/2018 16:29, Laurent Dufour wrote:
> On very large system we could see soft lockup fired when a process is
> exiting
>
> watchdog: BUG: soft lockup - CPU#851 stuck for 21s! [forkoff:215523]
> Modules linked in: pseries_rng
On 09/06/2018 04:49 AM, Pierre Morel wrote:
On 13/08/2018 23:48, Tony Krowiak wrote:
From: Tony Krowiak
Registers the matrix device created by the VFIO AP device
driver with the VFIO mediated device framework.
Registering the matrix device will create the sysfs
structures needed to create
Hi Michael,
Do you plan to pull it for 4.20 ?
Cheers,
Laurent.
On 20/08/2018 16:29, Laurent Dufour wrote:
> On very large system we could see soft lockup fired when a process is
> exiting
>
> watchdog: BUG: soft lockup - CPU#851 stuck for 21s! [forkoff:215523]
> Modules linked in: pseries_rng
801 - 900 of 1628 matches
Mail list logo
