When compiling bmips with SMP disabled, the build fails with:
drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline':
drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to
`irq_set_affinity_locked'
make[5]: *** [vmlinux] Error 1
Fix this by adding and setting
When compiling bmips with SMP disabled, the build fails with:
drivers/irqchip/irq-bcm7038-l1.o: In function `bcm7038_l1_cpu_offline':
drivers/irqchip/irq-bcm7038-l1.c:242: undefined reference to
`irq_set_affinity_locked'
make[5]: *** [vmlinux] Error 1
Fix this by adding and setting
On 09/08/2018 10:10, David Hildenbrand wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Pierre Morel
When we clear the Crypto Control Block (CRYCB) used by a guest
level 2, the vSIE shadow CRYCB for guest level 3 must be updated
before the guest uses it.
We achieve this by using the
On 09/08/2018 10:10, David Hildenbrand wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Pierre Morel
When we clear the Crypto Control Block (CRYCB) used by a guest
level 2, the vSIE shadow CRYCB for guest level 3 must be updated
before the guest uses it.
We achieve this by using the
In SLUB, prefetch_freepointer() is used when allocating an object from cache's
freelist, to make sure the next object in the list is cache-hot, since it's
probable it will be allocated soon.
Commit 2482ddec670f ("mm: add SLUB free list pointer obfuscation") has
unintentionally changed the
In SLUB, prefetch_freepointer() is used when allocating an object from cache's
freelist, to make sure the next object in the list is cache-hot, since it's
probable it will be allocated soon.
Commit 2482ddec670f ("mm: add SLUB free list pointer obfuscation") has
unintentionally changed the
On 09/08/2018 10:10, David Hildenbrand wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Pierre Morel
When we clear the Crypto Control Block (CRYCB) used by a guest
level 2, the vSIE shadow CRYCB for guest level 3 must be updated
before the guest uses it.
We achieve this by using the
Hi Evan,
On 8/6/2018 10:56 PM, Evan Green wrote:
Hi Sayali,
On Wed, Aug 1, 2018 at 1:49 AM Sayali Lokhande wrote:
From: Subhash Jadavani
UFS host supplies the reference clock to UFS device and UFS device
specification allows host to provide one of the 4 frequencies (19.2 MHz,
26 MHz, 38.4
On 09/08/2018 10:10, David Hildenbrand wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Pierre Morel
When we clear the Crypto Control Block (CRYCB) used by a guest
level 2, the vSIE shadow CRYCB for guest level 3 must be updated
before the guest uses it.
We achieve this by using the
Hi Evan,
On 8/6/2018 10:56 PM, Evan Green wrote:
Hi Sayali,
On Wed, Aug 1, 2018 at 1:49 AM Sayali Lokhande wrote:
From: Subhash Jadavani
UFS host supplies the reference clock to UFS device and UFS device
specification allows host to provide one of the 4 frequencies (19.2 MHz,
26 MHz, 38.4
Here's my current code:
https://github.com/cyndis/linux/commits/wip/t194-tcu-4
"fixup! mailbox: tegra-hsp: Add support for shared mailboxes" splits up
the controller into two. "tegra-hsp: use polling" changes it to use polling.
There are two lines in the top patch with comments:
- at the
Here's my current code:
https://github.com/cyndis/linux/commits/wip/t194-tcu-4
"fixup! mailbox: tegra-hsp: Add support for shared mailboxes" splits up
the controller into two. "tegra-hsp: use polling" changes it to use polling.
There are two lines in the top patch with comments:
- at the
Hi !
On 07/08/2018 15:00, Ludovic Desroches wrote:
> From: Nicolas Ferre
>
> When mode is set in atmel_config_iso7816() we backup last RS232 mode
> for coming back to this mode if requested.
> Also allow setup of T=0 and T=1 parameter and basic support in set_termios
> function as well.
>
>
Hi !
On 07/08/2018 15:00, Ludovic Desroches wrote:
> From: Nicolas Ferre
>
> When mode is set in atmel_config_iso7816() we backup last RS232 mode
> for coming back to this mode if requested.
> Also allow setup of T=0 and T=1 parameter and basic support in set_termios
> function as well.
>
>
On Wed, Aug 08, 2018 at 03:14:19PM -0700, Joe Perches wrote:
> On Wed, 2018-08-08 at 22:00 +0100, John Whitmore wrote:
> > The macro eqMacAddr implements the same functionality as the
> > ether_addr_equal function defined in etherdevice.h, as a result the
> > macro has been removed from the code,
On Wed, Aug 08, 2018 at 03:14:19PM -0700, Joe Perches wrote:
> On Wed, 2018-08-08 at 22:00 +0100, John Whitmore wrote:
> > The macro eqMacAddr implements the same functionality as the
> > ether_addr_equal function defined in etherdevice.h, as a result the
> > macro has been removed from the code,
On 06-Aug 09:50, Randy Dunlap wrote:
> Hi,
Hi Randy,
> On 08/06/2018 09:39 AM, Patrick Bellasi wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 041f3a022122..1d45a6877d6f 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -583,6 +583,25 @@ config HAVE_UNSTABLE_SCHED_CLOCK
>
On 06-Aug 09:50, Randy Dunlap wrote:
> Hi,
Hi Randy,
> On 08/06/2018 09:39 AM, Patrick Bellasi wrote:
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 041f3a022122..1d45a6877d6f 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -583,6 +583,25 @@ config HAVE_UNSTABLE_SCHED_CLOCK
>
From: He Zhe
The check may fail not only because ${CC} does not support the asm
feature, but also due to potential defects of ${CC} itself like what
we experienced below or even it's missing.
Assembler messages:
Fatal error: The input and output files must be distinct
(introduced by
From: He Zhe
The check may fail not only because ${CC} does not support the asm
feature, but also due to potential defects of ${CC} itself like what
we experienced below or even it's missing.
Assembler messages:
Fatal error: The input and output files must be distinct
(introduced by
On 09.08.2018 10:17, David Hildenbrand wrote:
> On 08.08.2018 16:44, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
>>
>> The KVM_S390_VM_CPU_FEAT_AP feature
On 09.08.2018 10:17, David Hildenbrand wrote:
> On 08.08.2018 16:44, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
>>
>> The KVM_S390_VM_CPU_FEAT_AP feature
Bjorn Helgaas writes:
> On Wed, Aug 08, 2018 at 03:44:03PM +0100, Punit Agrawal wrote:
>> Bjorn Helgaas writes:
>> > On Thu, Aug 2, 2018 at 9:33 AM Lorenzo Pieralisi
>> > wrote:
>> >> On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wrote:
>> >>
>> >> Jiang Liu does not work on the
Bjorn Helgaas writes:
> On Wed, Aug 08, 2018 at 03:44:03PM +0100, Punit Agrawal wrote:
>> Bjorn Helgaas writes:
>> > On Thu, Aug 2, 2018 at 9:33 AM Lorenzo Pieralisi
>> > wrote:
>> >> On Wed, Aug 01, 2018 at 02:38:51PM -0500, Jeremy Linton wrote:
>> >>
>> >> Jiang Liu does not work on the
On Thu, Aug 9, 2018 at 9:31 AM, 刘硕然 wrote:
> Thank you for the prompt reply.
>
> I tried this config, but still can get balance_dirty_pages triggered.
I think it may be due to BDI_CAP_STRICTLIMIT used by fuse. If you
remove that setting from fuse in the kernel you should not be getting
the
On Thu, Aug 9, 2018 at 9:31 AM, 刘硕然 wrote:
> Thank you for the prompt reply.
>
> I tried this config, but still can get balance_dirty_pages triggered.
I think it may be due to BDI_CAP_STRICTLIMIT used by fuse. If you
remove that setting from fuse in the kernel you should not be getting
the
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
>
> 1. Prior to the introduction of AP device virtualization, it
>was
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
>
> 1. Prior to the introduction of AP device virtualization, it
>was
On Wed 08-08-18 12:58:15, Jerome Glisse wrote:
> On Wed, Aug 08, 2018 at 08:47:58AM +0200, Michal Hocko wrote:
> > On Tue 07-08-18 11:18:10, Jerome Glisse wrote:
> > > On Tue, Aug 07, 2018 at 04:59:00PM +0200, Michal Hocko wrote:
> > > > On Tue 07-08-18 09:52:21, Jerome Glisse wrote:
> > > > > On
On Wed 08-08-18 12:58:15, Jerome Glisse wrote:
> On Wed, Aug 08, 2018 at 08:47:58AM +0200, Michal Hocko wrote:
> > On Tue 07-08-18 11:18:10, Jerome Glisse wrote:
> > > On Tue, Aug 07, 2018 at 04:59:00PM +0200, Michal Hocko wrote:
> > > > On Tue 07-08-18 09:52:21, Jerome Glisse wrote:
> > > > > On
From: Jianxin
This attempt will try to add new DT files to support Meson-G12A SoC.
1) first, Please notice that, in this patch series, the DT node about 16M
reserved
memory for hwrom is removed, since it's not needed by G12A SoC.
2) second, the pclk for uart_AO need to be fixed once G12A
* Pavel Machek [180808 21:35]:
> On Wed 2018-08-08 02:05:12, Tony Lindgren wrote:
> > Then for deeper idle modes, you need to also idle UARTs, and unbind or
> > unload USB related modules. You should get to something like 160mW
> > power consumption with mdm6600 enabled and SoC suspended that
v3: Added missed #ifdef CONFIG_MEMCG_KMEM around idr_replace()
v2: Improved comments to SHRINKER_REGISTERING and written
long description about all the things to the patch.
The patch introduces a special value SHRINKER_REGISTERING
to use instead of list_empty() to differ a registering
From: Jianxin
This attempt will try to add new DT files to support Meson-G12A SoC.
1) first, Please notice that, in this patch series, the DT node about 16M
reserved
memory for hwrom is removed, since it's not needed by G12A SoC.
2) second, the pclk for uart_AO need to be fixed once G12A
* Pavel Machek [180808 21:35]:
> On Wed 2018-08-08 02:05:12, Tony Lindgren wrote:
> > Then for deeper idle modes, you need to also idle UARTs, and unbind or
> > unload USB related modules. You should get to something like 160mW
> > power consumption with mdm6600 enabled and SoC suspended that
v3: Added missed #ifdef CONFIG_MEMCG_KMEM around idr_replace()
v2: Improved comments to SHRINKER_REGISTERING and written
long description about all the things to the patch.
The patch introduces a special value SHRINKER_REGISTERING
to use instead of list_empty() to differ a registering
Introduce new bindings for the Meson G12A SoC
Signed-off-by: Jianxin Pan
---
Documentation/devicetree/bindings/arm/amlogic.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt
b/Documentation/devicetree/bindings/arm/amlogic.txt
index
Try to add basic DT support for the Amlogic's Meson-G12A S905D2 SoC,
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
Signed-off-by: Jianxin
---
arch/arm64/boot/dts/amlogic/Makefile| 1 +
Introduce new bindings for the Meson G12A SoC
Signed-off-by: Jianxin Pan
---
Documentation/devicetree/bindings/arm/amlogic.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt
b/Documentation/devicetree/bindings/arm/amlogic.txt
index
Try to add basic DT support for the Amlogic's Meson-G12A S905D2 SoC,
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
Signed-off-by: Jianxin
---
arch/arm64/boot/dts/amlogic/Makefile| 1 +
On 08/09/2018 10:16 AM, Murphy Zhou wrote:
Hi,
Looks like this missed v4.18 ?
Hi Murphy,
yes, Jeff planned to push those patches into 4.19 and they are in "linux-next"
now,
but not in 4.18 "master" currently.
On 06/14/2018 01:41 PM, Jeff Layton wrote:
> These look fine to me. I'll plan to
On 08/09/2018 10:16 AM, Murphy Zhou wrote:
Hi,
Looks like this missed v4.18 ?
Hi Murphy,
yes, Jeff planned to push those patches into 4.19 and they are in "linux-next"
now,
but not in 4.18 "master" currently.
On 06/14/2018 01:41 PM, Jeff Layton wrote:
> These look fine to me. I'll plan to
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Introduces a new CPU model feature and two CPU model
> facilities to support AP virtualization for KVM guests.
>
> CPU model feature:
>
> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
> AP instructions are available on the
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Introduces a new CPU model feature and two CPU model
> facilities to support AP virtualization for KVM guests.
>
> CPU model feature:
>
> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
> AP instructions are available on the
On Wed, Aug 8, 2018 at 8:02 PM, Lina Iyer wrote:
> On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote:
>>
>> On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:
>>>
>>> On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson
>>> wrote:
>>> > [...]
>>> >
>>> >>>
>>> >>> Assuming that
On Wed, Aug 8, 2018 at 8:02 PM, Lina Iyer wrote:
> On Wed, Aug 08 2018 at 04:56 -0600, Lorenzo Pieralisi wrote:
>>
>> On Mon, Aug 06, 2018 at 11:37:55AM +0200, Rafael J. Wysocki wrote:
>>>
>>> On Fri, Aug 3, 2018 at 1:42 PM, Ulf Hansson
>>> wrote:
>>> > [...]
>>> >
>>> >>>
>>> >>> Assuming that
On Wed, Aug 08, 2018 at 11:55:48AM -0400, Steven Rostedt wrote:
> Having libtraceevent turn into a proper library has long been asked for.
> I never had time to do it before. Luckily, Tzvetomir was able to spend
> the time to start the preparation. The first thing that needs to be done
> is to
On Wed, Aug 08, 2018 at 11:55:48AM -0400, Steven Rostedt wrote:
> Having libtraceevent turn into a proper library has long been asked for.
> I never had time to do it before. Luckily, Tzvetomir was able to spend
> the time to start the preparation. The first thing that needs to be done
> is to
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Pierre Morel
>
> When we clear the Crypto Control Block (CRYCB) used by a guest
> level 2, the vSIE shadow CRYCB for guest level 3 must be updated
> before the guest uses it.
>
> We achieve this by using the KVM_REQ_VSIE_RESTART synchronous
>
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Pierre Morel
>
> When we clear the Crypto Control Block (CRYCB) used by a guest
> level 2, the vSIE shadow CRYCB for guest level 3 must be updated
> before the guest uses it.
>
> We achieve this by using the KVM_REQ_VSIE_RESTART synchronous
>
On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> This patch fixes a bug in ordered_event.c:alloc_event().
> An ordered_event struct was not initialized properly potentially
> causing crashes later on in free_dup_event() depending on the
> content of the memory. If it was NULL,
On Wed, Aug 08, 2018 at 03:33:20PM -0700, Stephane Eranian wrote:
> This patch fixes a bug in ordered_event.c:alloc_event().
> An ordered_event struct was not initialized properly potentially
> causing crashes later on in free_dup_event() depending on the
> content of the memory. If it was NULL,
Hi all,
Changes since 20180808:
The vfs tree still had its build failure but today I applied a suggested
patch and I have still disabled CONFIG_SAMPLE_STATX.
Non-merge commits (relative to Linus' tree): 11533
10452 files changed, 491910 insertions(+), 204122 deletions(-)
Hi all,
Changes since 20180808:
The vfs tree still had its build failure but today I applied a suggested
patch and I have still disabled CONFIG_SAMPLE_STATX.
Non-merge commits (relative to Linus' tree): 11533
10452 files changed, 491910 insertions(+), 204122 deletions(-)
VCPU requests and VCPU blocking right now don't take care of the vSIE
(as it was not necessary until now). But we want to have synchronous VCPU
requests that will also be handled before running the vSIE again.
So let's simulate a SIE entry of the VCPU when calling the sie during
vSIE handling and
When we change the crycb (or execution controls), we also have to make sure
that the vSIE shadow datastructures properly consider the changed
values before rerunning the vSIE. We can achieve that by simply using a
VCPU request now.
This has to be a synchronous request (== handled before entering
While discussing AP changes, we discovered that we will have to force
a CPU using the vSIE to regenerate/reload shadow data structures. For now,
we have no mechanism for that.
E.g. when clearing AP masks later, we could still have a vSIE CPU making
use of AP adapters as the masks might not be
VCPU requests and VCPU blocking right now don't take care of the vSIE
(as it was not necessary until now). But we want to have synchronous VCPU
requests that will also be handled before running the vSIE again.
So let's simulate a SIE entry of the VCPU when calling the sie during
vSIE handling and
When we change the crycb (or execution controls), we also have to make sure
that the vSIE shadow datastructures properly consider the changed
values before rerunning the vSIE. We can achieve that by simply using a
VCPU request now.
This has to be a synchronous request (== handled before entering
While discussing AP changes, we discovered that we will have to force
a CPU using the vSIE to regenerate/reload shadow data structures. For now,
we have no mechanism for that.
E.g. when clearing AP masks later, we could still have a vSIE CPU making
use of AP adapters as the masks might not be
On Thu, Aug 09, 2018 at 03:44:40PM +0800, Alan Kao wrote:
> We expect that a kernel with CONFIG_FPU=y can still support no-FPU
> machines. To do so, the kernel should first examine the existence of a
> FPU, then do nothing if a FPU does exist; otherwise, it should
> disable/bypass all FPU-related
On Thu, Aug 09, 2018 at 03:44:40PM +0800, Alan Kao wrote:
> We expect that a kernel with CONFIG_FPU=y can still support no-FPU
> machines. To do so, the kernel should first examine the existence of a
> FPU, then do nothing if a FPU does exist; otherwise, it should
> disable/bypass all FPU-related
From: Palmer Dabbelt
Add documentation for the SiFive implementation of the RISC-V Platform
Level Interrupt Controller (PLIC). The PLIC connects global interrupt
sources to the local interrupt controller on each hart.
Signed-off-by: Palmer Dabbelt
[hch: various fixes and updates]
Add a driver for the SiFive implementation of the RISC-V Platform Level
Interrupt Controller (PLIC). The PLIC connects global interrupt sources
to the local interrupt controller on each hart.
This driver is based on the driver in the RISC-V tree from Palmer Dabbelt,
but has been almost entirely
This series tries adds support for interrupt handling and timers
for the RISC-V architecture.
The basic per-hart interrupt handling implemented by the scause
and sie CSRs is extremely simple and implemented directly in
arch/riscv/kernel/irq.c. In addition there is a irqchip driver
for the PLIC
From: Palmer Dabbelt
Add documentation on the RISC-V local interrupt controller, which is a
per-hart interrupt controller that manages all interrupts entering a
RISC-V hart. This interrupt controller is present on all RISC-V systems.
Signed-off-by: Palmer Dabbelt
[hch: minor cleanups]
From: Palmer Dabbelt
Add documentation for the SiFive implementation of the RISC-V Platform
Level Interrupt Controller (PLIC). The PLIC connects global interrupt
sources to the local interrupt controller on each hart.
Signed-off-by: Palmer Dabbelt
[hch: various fixes and updates]
Add a driver for the SiFive implementation of the RISC-V Platform Level
Interrupt Controller (PLIC). The PLIC connects global interrupt sources
to the local interrupt controller on each hart.
This driver is based on the driver in the RISC-V tree from Palmer Dabbelt,
but has been almost entirely
This series tries adds support for interrupt handling and timers
for the RISC-V architecture.
The basic per-hart interrupt handling implemented by the scause
and sie CSRs is extremely simple and implemented directly in
arch/riscv/kernel/irq.c. In addition there is a irqchip driver
for the PLIC
From: Palmer Dabbelt
Add documentation on the RISC-V local interrupt controller, which is a
per-hart interrupt controller that manages all interrupts entering a
RISC-V hart. This interrupt controller is present on all RISC-V systems.
Signed-off-by: Palmer Dabbelt
[hch: minor cleanups]
On 08/08/2018 10:41, Jerome Brunet wrote:
> On Wed, 2018-08-08 at 00:00 +0200, Maxime Jourdan wrote:
>> Wrap the canvas node in a syscon node.
>>
>> Signed-off-by: Maxime Jourdan
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 17 +
>> 1 file changed, 17 insertions(+)
>>
>>
On 08/08/2018 10:41, Jerome Brunet wrote:
> On Wed, 2018-08-08 at 00:00 +0200, Maxime Jourdan wrote:
>> Wrap the canvas node in a syscon node.
>>
>> Signed-off-by: Maxime Jourdan
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 17 +
>> 1 file changed, 17 insertions(+)
>>
>>
On Thu, Aug 09, 2018 at 09:50:55AM +0200, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 11:29:08PM +0200, Oscar Salvador wrote:
> > On Wed, Aug 08, 2018 at 01:55:59PM -0400, Jerome Glisse wrote:
> > > Note that Dan did post patches that already go in that direction (unifying
> > > code between
On Thu, Aug 09, 2018 at 09:50:55AM +0200, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 11:29:08PM +0200, Oscar Salvador wrote:
> > On Wed, Aug 08, 2018 at 01:55:59PM -0400, Jerome Glisse wrote:
> > > Note that Dan did post patches that already go in that direction (unifying
> > > code between
On Wed, Aug 08, 2018 at 11:29:08PM +0200, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 01:55:59PM -0400, Jerome Glisse wrote:
> > Note that Dan did post patches that already go in that direction (unifying
> > code between devm and HMM). I think they are in Andrew queue, looks for
> >
> > mm:
On Wed, Aug 08, 2018 at 11:29:08PM +0200, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 01:55:59PM -0400, Jerome Glisse wrote:
> > Note that Dan did post patches that already go in that direction (unifying
> > code between devm and HMM). I think they are in Andrew queue, looks for
> >
> > mm:
On Wed, Aug 08, 2018 at 05:07:08PM -0700, Matthew Wilcox wrote:
> On Thu, Aug 09, 2018 at 07:31:25AM +1000, Dave Chinner wrote:
> > IMO, we've had enough recent bugs to deal with from shrinkers being
> > called before the filesystem is set up and from trying to handle
> > allocation errors during
On Wed, Aug 08, 2018 at 05:07:08PM -0700, Matthew Wilcox wrote:
> On Thu, Aug 09, 2018 at 07:31:25AM +1000, Dave Chinner wrote:
> > IMO, we've had enough recent bugs to deal with from shrinkers being
> > called before the filesystem is set up and from trying to handle
> > allocation errors during
We expect that a kernel with CONFIG_FPU=y can still support no-FPU
machines. To do so, the kernel should first examine the existence of a
FPU, then do nothing if a FPU does exist; otherwise, it should
disable/bypass all FPU-related functions.
In this patch, a new global variable, has_fpu, is
We expect that a kernel with CONFIG_FPU=y can still support no-FPU
machines. To do so, the kernel should first examine the existence of a
FPU, then do nothing if a FPU does exist; otherwise, it should
disable/bypass all FPU-related functions.
In this patch, a new global variable, has_fpu, is
On Wed, Aug 08, 2018 at 02:47:42PM -0700, Stephane Eranian wrote:
> Hi,
>
> Ok, I found the problem. It still exists upstream , just very tricky to
> trigger.
> Took me lots of time with gdb + watchpoints to track this down, where
> in fact it was just in front of me.
>
> From the crashdump:
>
On Wed, Aug 08, 2018 at 02:47:42PM -0700, Stephane Eranian wrote:
> Hi,
>
> Ok, I found the problem. It still exists upstream , just very tricky to
> trigger.
> Took me lots of time with gdb + watchpoints to track this down, where
> in fact it was just in front of me.
>
> From the crashdump:
>
On 09/08/2018 08:20, Janosch Frank wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Pierre Morel
+#define ECA_APIE 0x0008
That shouldn't be necessary, it's defined in kvm_host.h which vsie.c
includes. Or is it not?
This was forgotten here for a long long time!
You are right I
On 09/08/2018 08:20, Janosch Frank wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Pierre Morel
+#define ECA_APIE 0x0008
That shouldn't be necessary, it's defined in kvm_host.h which vsie.c
includes. Or is it not?
This was forgotten here for a long long time!
You are right I
On Thu, Aug 09, 2018 at 12:02:58AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 02:43:36PM +0800, Alan Kao wrote:
> > It does look a little bit weird. Should I send a v6 for this?
>
> Yes, please resend the series or just this patch.
>
> I think the hswap.h definition should go
On Thu, Aug 09, 2018 at 12:02:58AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 09, 2018 at 02:43:36PM +0800, Alan Kao wrote:
> > It does look a little bit weird. Should I send a v6 for this?
>
> Yes, please resend the series or just this patch.
>
> I think the hswap.h definition should go
Thank you for the prompt reply.
I tried this config, but still can get balance_dirty_pages triggered.
[root@A01-R20-I31-77-8S5FKM2 example]# stat -c %d /mnt/fuse/
42
[root@A01-R20-I31-77-8S5FKM2 example]# echo 20 >
/sys/devices/virtual/bdi/0:`stat -c %d /mnt/fuse/`/max_ratio
Thank you for the prompt reply.
I tried this config, but still can get balance_dirty_pages triggered.
[root@A01-R20-I31-77-8S5FKM2 example]# stat -c %d /mnt/fuse/
42
[root@A01-R20-I31-77-8S5FKM2 example]# echo 20 >
/sys/devices/virtual/bdi/0:`stat -c %d /mnt/fuse/`/max_ratio
On 07.08.2018 14:51, David Hildenbrand wrote:
> VCPU requests and VCPU blocking right now don't take care of the vSIE
> (as it was not necessary until now). But we want to have VCPU requests
> that will also be handled before running the vSIE again.
>
> So let's simulate a SIE entry when entering
On 07.08.2018 14:51, David Hildenbrand wrote:
> VCPU requests and VCPU blocking right now don't take care of the vSIE
> (as it was not necessary until now). But we want to have VCPU requests
> that will also be handled before running the vSIE again.
>
> So let's simulate a SIE entry when entering
Hi,
Looks like this missed v4.18 ?
Thanks,
Murphy
On Fri, Jun 8, 2018 at 10:27 PM, Konstantin Khorenko
wrote:
> The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid
> and use fs-specific l_pid for remote locks")
> and now /proc/$PID/fdinfo/$FD does not show the info
Hi,
Looks like this missed v4.18 ?
Thanks,
Murphy
On Fri, Jun 8, 2018 at 10:27 PM, Konstantin Khorenko
wrote:
> The behavior has been changed after 9d5b86ac13c5 ("fs/locks: Remove fl_nspid
> and use fs-specific l_pid for remote locks")
> and now /proc/$PID/fdinfo/$FD does not show the info
On Thu, Aug 9, 2018 at 5:37 AM, 刘硕然 wrote:
> Dear Miklos,
>
> Recently I've been testing FUSE and libfuse example passthrough_ll with
> writeback cache on, and found out that the performance drops significantly
> compared to that in local filesystem. As I can see from trace,
>
On Thu, Aug 9, 2018 at 5:37 AM, 刘硕然 wrote:
> Dear Miklos,
>
> Recently I've been testing FUSE and libfuse example passthrough_ll with
> writeback cache on, and found out that the performance drops significantly
> compared to that in local filesystem. As I can see from trace,
>
On Wed 08-08-18 16:20:54, Kirill Tkhai wrote:
> [Added two more places needed srcu_dereference(). All ->shrinker_map
> dereferences must be under SRCU, and this v2 adds missed in previous]
>
> The patch makes shrinker list and shrinker_idr SRCU-safe
> for readers. This requires
On Wed 08-08-18 16:20:54, Kirill Tkhai wrote:
> [Added two more places needed srcu_dereference(). All ->shrinker_map
> dereferences must be under SRCU, and this v2 adds missed in previous]
>
> The patch makes shrinker list and shrinker_idr SRCU-safe
> for readers. This requires
The patch will add a MMC clock controller driver which used by MMC or NAND,
It provide a mux and divider clock, and three phase clocks - core, tx, tx.
Two clocks are provided as the parent of MMC clock controller from
upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
To
Document the MMC sub clock controller driver, the potential consumer
of this driver is MMC or NAND. Also add four clock bindings IDs which
provided by this driver.
Reviewed-by: Rob Herring
Signed-off-by: Yixun Lan
---
.../bindings/clock/amlogic,mmc-clkc.txt | 31 +++
Export the emmc sub clock phase delay ops which will be used
by the emmc sub clock driver itself.
Signed-off-by: Yixun Lan
---
drivers/clk/meson/Makefile | 2 +-
drivers/clk/meson/clk-phase-delay.c | 96 +
drivers/clk/meson/clkc.h| 13
3
The patch will add a MMC clock controller driver which used by MMC or NAND,
It provide a mux and divider clock, and three phase clocks - core, tx, tx.
Two clocks are provided as the parent of MMC clock controller from
upper layer clock controller - eg "amlogic,axg-clkc" in AXG platform.
To
1101 - 1200 of 1264 matches
Mail list logo
