Hello Doug,
On 07/11/2018 03:43 PM, Doug Anderson wrote:
> On Wed, Jul 11, 2018 at 3:36 PM, David Collins
> wrote:
>>> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
>>> wrote:
On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
> On Fri, Jun 29, 2018 at 02:29:55PM -0700, David Collins
Hi Nicolas,
I love your patch! Yet something to improve:
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.18-rc4 next-20180711]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hello Doug,
On 07/11/2018 03:43 PM, Doug Anderson wrote:
> On Wed, Jul 11, 2018 at 3:36 PM, David Collins
> wrote:
>>> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
>>> wrote:
On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
> On Fri, Jun 29, 2018 at 02:29:55PM -0700, David Collins
Hi Nicolas,
I love your patch! Yet something to improve:
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.18-rc4 next-20180711]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
During boot tsc is calibrated twice: once in tsc_early_delay_calibrate(),
and the second time in tsc_init().
Rename tsc_early_delay_calibrate() to tsc_early_init(), and rework it so
the calibration is done only early, and make tsc_init() to use the values
already determined in tsc_early_init().
During boot tsc is calibrated twice: once in tsc_early_delay_calibrate(),
and the second time in tsc_init().
Rename tsc_early_delay_calibrate() to tsc_early_init(), and rework it so
the calibration is done only early, and make tsc_init() to use the values
already determined in tsc_early_init().
It supposed to be safe to modify static branches after jump_label_init().
But, because static key modifying code eventually calls text_poke() we
may end up with accessing struct page that have not been initialized.
Here is how to quickly reproduce the problem. Insert code like this
into
sched_clock_postinit() initializes a generic clock on systems where no
other clock is porvided. This function may be called only after
timekeeping_init().
Rename sched_clock_postinit to generic_clock_inti() and call it from
sched_clock_init(). Move the call for sched_clock_init() until after
sched_clock_running may be read every time sched_clock_cpu() is called.
Yet, this variable is updated only twice during boot, and never changes
again, therefore it is better to make it a static key.
Signed-off-by: Pavel Tatashin
---
kernel/sched/clock.c | 16
It supposed to be safe to modify static branches after jump_label_init().
But, because static key modifying code eventually calls text_poke() we
may end up with accessing struct page that have not been initialized.
Here is how to quickly reproduce the problem. Insert code like this
into
sched_clock_postinit() initializes a generic clock on systems where no
other clock is porvided. This function may be called only after
timekeeping_init().
Rename sched_clock_postinit to generic_clock_inti() and call it from
sched_clock_init(). Move the call for sched_clock_init() until after
sched_clock_running may be read every time sched_clock_cpu() is called.
Yet, this variable is updated only twice during boot, and never changes
again, therefore it is better to make it a static key.
Signed-off-by: Pavel Tatashin
---
kernel/sched/clock.c | 16
get timestamps and high resultion clock available to us as early as
possible.
native_sched_clock() outputs time based either on tsc after tsc_init() is
called later in boot, or using jiffies when clock interrupts are enabled,
which is also happens later in boot.
On the other hand, tsc frequency
get timestamps and high resultion clock available to us as early as
possible.
native_sched_clock() outputs time based either on tsc after tsc_init() is
called later in boot, or using jiffies when clock interrupts are enabled,
which is also happens later in boot.
On the other hand, tsc frequency
KVM clock is initialized later compared to other hypervisor because it has
dependency on memblock allocator.
Lets bring it inline with other hypervisors by removing this dependency by
using memory from BSS instead of allocating it.
The benefits:
- remove ifdef from common code
- earlier
It is expected for sched_clock() to output data from 0, when system boots.
Add an offset xen_sched_clock_offset (similarly how it is done in other
hypervisors i.e. kvm_sched_clock_offset) to count sched_clock() from 0,
when time is first initialized.
Signed-off-by: Pavel Tatashin
---
Hi Matthias
On Tue, 2018-07-10 at 12:52 +0200, Matthias Brugger wrote:
>
> On 10/07/18 01:04, Mars Cheng wrote:
[...]
> > pmic/pwrap/i2c/rtc/kpd/spi/wdt/cqdma/auxadc/pwm/cmdq/disp. We have
> > dedicated owners to handle them and will cowork tightly with members to
> > make sure things happen in
KVM clock is initialized later compared to other hypervisor because it has
dependency on memblock allocator.
Lets bring it inline with other hypervisors by removing this dependency by
using memory from BSS instead of allocating it.
The benefits:
- remove ifdef from common code
- earlier
It is expected for sched_clock() to output data from 0, when system boots.
Add an offset xen_sched_clock_offset (similarly how it is done in other
hypervisors i.e. kvm_sched_clock_offset) to count sched_clock() from 0,
when time is first initialized.
Signed-off-by: Pavel Tatashin
---
Hi Matthias
On Tue, 2018-07-10 at 12:52 +0200, Matthias Brugger wrote:
>
> On 10/07/18 01:04, Mars Cheng wrote:
[...]
> > pmic/pwrap/i2c/rtc/kpd/spi/wdt/cqdma/auxadc/pwm/cmdq/disp. We have
> > dedicated owners to handle them and will cowork tightly with members to
> > make sure things happen in
static branching is useful to hot-patch branches that are used in hot
path, but are infrequently changed.
x86 clock framework is one example that uses static branches to setup
the best clock during boot and never change it again.
Since we plan to enable clock early, we need static branching
If architecture does not support exact boot time, it is challenging to
estimate boot time without having a reference to the current persistent
clock value. Yet, it cannot read the persistent clock time again, because
this may lead to math discrepancies with the caller of read_boot_clock64()
who
Hi Aapo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra/for-next]
[also build test WARNING on v4.18-rc4 next-20180711]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
static branching is useful to hot-patch branches that are used in hot
path, but are infrequently changed.
x86 clock framework is one example that uses static branches to setup
the best clock during boot and never change it again.
Since we plan to enable clock early, we need static branching
If architecture does not support exact boot time, it is challenging to
estimate boot time without having a reference to the current persistent
clock value. Yet, it cannot read the persistent clock time again, because
this may lead to math discrepancies with the caller of read_boot_clock64()
who
Hi Aapo,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra/for-next]
[also build test WARNING on v4.18-rc4 next-20180711]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
Currently, notsc kernel parameter disables the use of tsc register by
sched_clock(). However, this parameter does not prevent linux from
accessing tsc in other places in kernel.
The only rational to boot with notsc is to avoid timing discrepancies on
multi-socket systems where different tsc
read_persistent_wall_and_boot_offset() is called during boot to read
both the persistent clock and also return the offset between the boot time
and the value of persistent clock.
Change the default boot_offset from zero to local_clock() so architectures,
that do not have a dedicated boot_clock
Currently, notsc kernel parameter disables the use of tsc register by
sched_clock(). However, this parameter does not prevent linux from
accessing tsc in other places in kernel.
The only rational to boot with notsc is to avoid timing discrepancies on
multi-socket systems where different tsc
read_persistent_wall_and_boot_offset() is called during boot to read
both the persistent clock and also return the offset between the boot time
and the value of persistent clock.
Change the default boot_offset from zero to local_clock() so architectures,
that do not have a dedicated boot_clock
changelog
-
v13 - v12
- Addressed comments from Thomas Gleixner.
- Addressed comments from Peter Zijlstra.
- Added a patch from Borislav Petkov
- Added a new patch: sched: use static key for sched_clock_running
- Added xen pv fixes, so clock is
read_boot_clock64() was replaced by read_persistent_wall_and_boot_offset()
so remove it.
Signed-off-by: Pavel Tatashin
---
arch/s390/kernel/time.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index d1f5447d5687..e8766beee5ad
From: Borislav Petkov
Make it use the setup_* variants and have it be called only on the BSP
and drop the call in generic_identify() - X86_FEATURE_NOPL will be
replicated to the APs through the forced caps. Helps keep the mess at a
manageable level.
Signed-off-by: Borislav Petkov
In every hypervisor except for xen pv time ops are initialized in
init_hypervisor_platform().
Xen PV domains initialize time ops in x86_init.paging.pagetable_init(),
by calling xen_setup_shared_info() which is a poor design, as time is
needed prior to memory allocator.
xen_setup_shared_info() is
read_persistent_wall_and_boot_offset() will replace read_boot_clock64()
because on some architectures it is more convenient to read both sources
as one may depend on the other. For s390, implementation is the same
as read_boot_clock64() but also calling and returning value of
read_persistent_wall_and_boot_offset() will replace read_boot_clock64()
because on some architectures it is more convenient to read both sources
as one may depend on the other. For s390, implementation is the same
as read_boot_clock64() but also calling and returning value of
changelog
-
v13 - v12
- Addressed comments from Thomas Gleixner.
- Addressed comments from Peter Zijlstra.
- Added a patch from Borislav Petkov
- Added a new patch: sched: use static key for sched_clock_running
- Added xen pv fixes, so clock is
read_boot_clock64() was replaced by read_persistent_wall_and_boot_offset()
so remove it.
Signed-off-by: Pavel Tatashin
---
arch/s390/kernel/time.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index d1f5447d5687..e8766beee5ad
From: Borislav Petkov
Make it use the setup_* variants and have it be called only on the BSP
and drop the call in generic_identify() - X86_FEATURE_NOPL will be
replicated to the APs through the forced caps. Helps keep the mess at a
manageable level.
Signed-off-by: Borislav Petkov
In every hypervisor except for xen pv time ops are initialized in
init_hypervisor_platform().
Xen PV domains initialize time ops in x86_init.paging.pagetable_init(),
by calling xen_setup_shared_info() which is a poor design, as time is
needed prior to memory allocator.
xen_setup_shared_info() is
Allow sched_clock() to be used before schec_clock_init() is called.
This provides with a way to get early boot timestamps on machines with
unstable clocks.
Signed-off-by: Pavel Tatashin
---
init/main.c | 2 +-
kernel/sched/clock.c | 10 +-
2 files changed, 10 insertions(+), 2
Allow sched_clock() to be used before schec_clock_init() is called.
This provides with a way to get early boot timestamps on machines with
unstable clocks.
Signed-off-by: Pavel Tatashin
---
init/main.c | 2 +-
kernel/sched/clock.c | 10 +-
2 files changed, 10 insertions(+), 2
read_boot_clock64() is deleted, and replaced with
read_persistent_wall_and_boot_offset().
The default implementation of read_persistent_wall_and_boot_offset()
provides a better fallback than the current stubs for read_boot_clock64()
that arm has with no users, so remove the old code.
read_boot_clock64() is deleted, and replaced with
read_persistent_wall_and_boot_offset().
The default implementation of read_persistent_wall_and_boot_offset()
provides a better fallback than the current stubs for read_boot_clock64()
that arm has with no users, so remove the old code.
cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data
structure.
Currently, the setup code for c2ns data for every possible CPU goes through
the same sequence of calculations as for the boot CPU, but is based on the
same tsc frequency as the boot CPU, and thus this is not
cyc2ns converts tsc to nanoseconds, and it is handled in a per-cpu data
structure.
Currently, the setup code for c2ns data for every possible CPU goes through
the same sequence of calculations as for the boot CPU, but is based on the
same tsc frequency as the boot CPU, and thus this is not
On Fri, Jun 29, 2018 at 12:05 PM, Laura Abbott wrote:
> include/linux/stackleak.h | 1 +
> [...]
> diff --git a/include/linux/stackleak.h b/include/linux/stackleak.h
> index e2da99b3a191..00d62b302efb 100644
> --- a/include/linux/stackleak.h
> +++ b/include/linux/stackleak.h
> @@
On Fri, Jun 29, 2018 at 12:05 PM, Laura Abbott wrote:
> include/linux/stackleak.h | 1 +
> [...]
> diff --git a/include/linux/stackleak.h b/include/linux/stackleak.h
> index e2da99b3a191..00d62b302efb 100644
> --- a/include/linux/stackleak.h
> +++ b/include/linux/stackleak.h
> @@
From: Laura Abbott
This adds support for the STACKLEAK gcc plugin to arm64 by implementing
stackleak_check_alloca(), based heavily on the x86 version, and adding the
two helpers used by the stackleak common code: current_top_of_stack() and
on_thread_stack(). The stack erasure calls are made at
From: Laura Abbott
This adds support for the STACKLEAK gcc plugin to arm64 by implementing
stackleak_check_alloca(), based heavily on the x86 version, and adding the
two helpers used by the stackleak common code: current_top_of_stack() and
on_thread_stack(). The stack erasure calls are made at
On Wed, Jul 11, 2018 at 11:39:10PM +0200, Christian Borntraeger wrote:
>
>
> On 07/11/2018 11:32 PM, Paul E. McKenney wrote:
> > On Wed, Jul 11, 2018 at 11:11:19PM +0200, Christian Borntraeger wrote:
> >>
> >>
> >> On 07/11/2018 10:27 PM, Paul E. McKenney wrote:
> >>> On Wed, Jul 11, 2018 at
On Wed, Jul 11, 2018 at 11:39:10PM +0200, Christian Borntraeger wrote:
>
>
> On 07/11/2018 11:32 PM, Paul E. McKenney wrote:
> > On Wed, Jul 11, 2018 at 11:11:19PM +0200, Christian Borntraeger wrote:
> >>
> >>
> >> On 07/11/2018 10:27 PM, Paul E. McKenney wrote:
> >>> On Wed, Jul 11, 2018 at
On Wed, 11 Jul 2018, Andrew Morton wrote:
> > > Did you consider LRU-sorting the array instead?
> > >
> >
> > It adds 40 bytes to struct task_struct,
>
> What does? LRU sort? It's a 4-entry array, just do it in place, like
> bh_lru_install(). Confused.
>
I was imagining an optimized sort
On Wed, 11 Jul 2018, Andrew Morton wrote:
> > > Did you consider LRU-sorting the array instead?
> > >
> >
> > It adds 40 bytes to struct task_struct,
>
> What does? LRU sort? It's a 4-entry array, just do it in place, like
> bh_lru_install(). Confused.
>
I was imagining an optimized sort
The OMAP Mailbox driver is directly using an integer value as
match data for distinguishing the interrupt register layout
between OMAP2 and OMAP4+ SoCs. Introduce a dedicated structure
for storing this match data, and simplify the probe function by
using the of_device_get_match_data() function.
The OMAP Mailbox driver is directly using an integer value as
match data for distinguishing the interrupt register layout
between OMAP2 and OMAP4+ SoCs. Introduce a dedicated structure
for storing this match data, and simplify the probe function by
using the of_device_get_match_data() function.
Hi Jassi,
The following series includes couple of cleanup patches on
the OMAP Mailbox driver. Please pick them for 4.19.
The first patch switches the licensing to use the SPDX license
identifier. The second patch is some code cleanup in preparing
the driver to be built against a 64-bit platform
Use the appropriate SPDX license identifier in the OMAP Mailbox
driver source files and drop the previous boilerplate license text.
Signed-off-by: Suman Anna
---
drivers/mailbox/omap-mailbox.c | 10 +-
include/linux/omap-mailbox.h | 5 +
2 files changed, 2 insertions(+), 13
Hi Jassi,
The following series includes couple of cleanup patches on
the OMAP Mailbox driver. Please pick them for 4.19.
The first patch switches the licensing to use the SPDX license
identifier. The second patch is some code cleanup in preparing
the driver to be built against a 64-bit platform
Use the appropriate SPDX license identifier in the OMAP Mailbox
driver source files and drop the previous boilerplate license text.
Signed-off-by: Suman Anna
---
drivers/mailbox/omap-mailbox.c | 10 +-
include/linux/omap-mailbox.h | 5 +
2 files changed, 2 insertions(+), 13
Matthew Wilcox wrote on Wed, Jul 11, 2018:
> The 9p code doesn't take advantage of the IDR's ability to store
> a pointer. We can actually get rid of the p9_idpool abstraction
> and the multi-dimensional array of requests.
>
> v2: Address feedback from Dominique.
Thanks, I've picked them up for
Matthew Wilcox wrote on Wed, Jul 11, 2018:
> The 9p code doesn't take advantage of the IDR's ability to store
> a pointer. We can actually get rid of the p9_idpool abstraction
> and the multi-dimensional array of requests.
>
> v2: Address feedback from Dominique.
Thanks, I've picked them up for
On Wed, Jul 11, 2018 at 02:32:59PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 11, 2018 at 11:11:19PM +0200, Christian Borntraeger wrote:
> >
> >
> > On 07/11/2018 10:27 PM, Paul E. McKenney wrote:
> > > On Wed, Jul 11, 2018 at 08:39:36PM +0200, Christian Borntraeger wrote:
> > >>
> > >>
> > >>
On Wed, Jul 11, 2018 at 02:32:59PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 11, 2018 at 11:11:19PM +0200, Christian Borntraeger wrote:
> >
> >
> > On 07/11/2018 10:27 PM, Paul E. McKenney wrote:
> > > On Wed, Jul 11, 2018 at 08:39:36PM +0200, Christian Borntraeger wrote:
> > >>
> > >>
> > >>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c25c74b7476e27180e9b76840e963e542023f118
commit: 6e0832fa432ec99c94caee733c8f5851cf85560b PCI: Collect all native
drivers under drivers/pci/controller/
date: 5 weeks ago
coccinelle warnings: (new ones
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c25c74b7476e27180e9b76840e963e542023f118
commit: 6e0832fa432ec99c94caee733c8f5851cf85560b PCI: Collect all native
drivers under drivers/pci/controller/
date: 5 weeks ago
coccinelle warnings: (new ones
From: kbuild test robot
drivers/pci/controller/pci-tegra.c:1132:1-3: WARNING: PTR_ERR_OR_ZERO can be
used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: 6e0832fa432e ("PCI: Collect all native drivers under
From: kbuild test robot
drivers/pci/controller/pci-tegra.c:1132:1-3: WARNING: PTR_ERR_OR_ZERO can be
used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: 6e0832fa432e ("PCI: Collect all native drivers under
Hi Vinod,
On Wed, Jul 11, 2018 at 05:46:55PM +0530, Vinod wrote:
> > > > - jzdma->base = devm_ioremap_resource(dev, res);
> > > > - if (IS_ERR(jzdma->base))
> > > > - return PTR_ERR(jzdma->base);
> > > > + jzdma->chn_base = devm_ioremap_resource(dev, res);
> > > >
Hi Vinod,
On Wed, Jul 11, 2018 at 05:46:55PM +0530, Vinod wrote:
> > > > - jzdma->base = devm_ioremap_resource(dev, res);
> > > > - if (IS_ERR(jzdma->base))
> > > > - return PTR_ERR(jzdma->base);
> > > > + jzdma->chn_base = devm_ioremap_resource(dev, res);
> > > >
On 06/29/2018 11:11 PM, Tony Krowiak wrote:
From: Tony Krowiak
Configures the AP adapters, usage domains and control domains for the
KVM guest from the matrix configured via the mediated matrix device's
sysfs attribute files.
[..]
+
+static void kvm_ap_set_crycb_masks(struct
On 06/29/2018 11:11 PM, Tony Krowiak wrote:
From: Tony Krowiak
Configures the AP adapters, usage domains and control domains for the
KVM guest from the matrix configured via the mediated matrix device's
sysfs attribute files.
[..]
+
+static void kvm_ap_set_crycb_masks(struct
Hi Linus,
Le lun. 9 juil. 2018 à 14:09, Linus Walleij
a écrit :
Hi folks,
On Wed, Jun 27, 2018 at 7:18 PM Andy Shevchenko
wrote:
Even if GPIO and pin muxing has only one set of buffers to indicate
input or output (same registers in use) it's a GPIO driver business
to
get direction
Hi Linus,
Le lun. 9 juil. 2018 à 14:09, Linus Walleij
a écrit :
Hi folks,
On Wed, Jun 27, 2018 at 7:18 PM Andy Shevchenko
wrote:
Even if GPIO and pin muxing has only one set of buffers to indicate
input or output (same registers in use) it's a GPIO driver business
to
get direction
On 07/11/2018 04:07 PM, Andy Lutomirski wrote:
> Could the cause be an overflow of the IRQ stack? I’ve been meaning
> to put guard pages on all the special stacks for a while. Let me see
> if I can do that in the next couple days.
But what would that overflow into? Wouldn't it most likely be
On 07/11/2018 04:07 PM, Andy Lutomirski wrote:
> Could the cause be an overflow of the IRQ stack? I’ve been meaning
> to put guard pages on all the special stacks for a while. Let me see
> if I can do that in the next couple days.
But what would that overflow into? Wouldn't it most likely be
Le mer. 11 juil. 2018 à 14:18, Vinod a écrit :
On 10-07-18, 17:45, Paul Cercueil wrote:
Le lun. 9 juil. 2018 à 19:14, Vinod a écrit :
> On 03-07-18, 14:32, Paul Cercueil wrote:
> > The JZ4725B has one DMA core starring six DMA channels.
> > As for the JZ4770, each DMA channel's
Le mer. 11 juil. 2018 à 14:18, Vinod a écrit :
On 10-07-18, 17:45, Paul Cercueil wrote:
Le lun. 9 juil. 2018 à 19:14, Vinod a écrit :
> On 03-07-18, 14:32, Paul Cercueil wrote:
> > The JZ4725B has one DMA core starring six DMA channels.
> > As for the JZ4770, each DMA channel's
Le mer. 11 juil. 2018 à 14:16, Vinod a écrit :
On 10-07-18, 17:36, Paul Cercueil wrote:
> > @@ -3,7 +3,8 @@
> > Required properties:
> >
> > - compatible: Should be "ingenic,jz4780-dma"
> > -- reg: Should contain the DMA controller registers location
and
> > length.
> > +-
Le mer. 11 juil. 2018 à 14:16, Vinod a écrit :
On 10-07-18, 17:36, Paul Cercueil wrote:
> > @@ -3,7 +3,8 @@
> > Required properties:
> >
> > - compatible: Should be "ingenic,jz4780-dma"
> > -- reg: Should contain the DMA controller registers location
and
> > length.
> > +-
On Mon, 9 Jul 2018 18:37:37 -0700 (PDT) David Rientjes
wrote:
> > Did you consider LRU-sorting the array instead?
> >
>
> It adds 40 bytes to struct task_struct,
What does? LRU sort? It's a 4-entry array, just do it in place, like
bh_lru_install(). Confused.
> but I'm not sure the least
On Mon, 9 Jul 2018 18:37:37 -0700 (PDT) David Rientjes
wrote:
> > Did you consider LRU-sorting the array instead?
> >
>
> It adds 40 bytes to struct task_struct,
What does? LRU sort? It's a 4-entry array, just do it in place, like
bh_lru_install(). Confused.
> but I'm not sure the least
> On Jul 11, 2018, at 11:31 AM, Dave Jones wrote:
>
>> On Wed, Jul 11, 2018 at 10:50:22AM -0700, Dave Hansen wrote:
>> On 07/11/2018 10:29 AM, H.J. Lu wrote:
I have seen it on machines with various amounts of cores and RAMs.
It triggers the fastest on 8 cores with 6GB RAM reliably.
> On Jul 11, 2018, at 11:31 AM, Dave Jones wrote:
>
>> On Wed, Jul 11, 2018 at 10:50:22AM -0700, Dave Hansen wrote:
>> On 07/11/2018 10:29 AM, H.J. Lu wrote:
I have seen it on machines with various amounts of cores and RAMs.
It triggers the fastest on 8 cores with 6GB RAM reliably.
On Wed, Jul 11, 2018 at 03:43:34PM -0700, Doug Anderson wrote:
> Hi
>
> On Wed, Jul 11, 2018 at 3:36 PM, David Collins
> wrote:
> > Hello Doug,
> >
> >> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
> >> wrote:
> >>> On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
> On Fri, Jun 29,
On Wed, Jul 11, 2018 at 03:43:34PM -0700, Doug Anderson wrote:
> Hi
>
> On Wed, Jul 11, 2018 at 3:36 PM, David Collins
> wrote:
> > Hello Doug,
> >
> >> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
> >> wrote:
> >>> On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
> On Fri, Jun 29,
On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko wrote:
> > Approach:
> > Zapping pages is the most time consuming part, according to the suggestion
> > from
> > Michal Hocko [1], zapping pages can be done with holding read mmap_sem, like
> > what MADV_DONTNEED does. Then re-acquire write
On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko wrote:
> > Approach:
> > Zapping pages is the most time consuming part, according to the suggestion
> > from
> > Michal Hocko [1], zapping pages can be done with holding read mmap_sem, like
> > what MADV_DONTNEED does. Then re-acquire write
Hi
On Wed, Jul 11, 2018 at 3:36 PM, David Collins wrote:
> Hello Doug,
>
>> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
>> wrote:
>>> On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
On Fri, Jun 29, 2018 at 02:29:55PM -0700, David Collins wrote:
>>> ...
> The PMIC TEMP_ALARM
Hi
On Wed, Jul 11, 2018 at 3:36 PM, David Collins wrote:
> Hello Doug,
>
>> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
>> wrote:
>>> On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
On Fri, Jun 29, 2018 at 02:29:55PM -0700, David Collins wrote:
>>> ...
> The PMIC TEMP_ALARM
On Wed, 11 Jul 2018 15:17:42 -0700 Guenter Roeck wrote:
> On Tue, Jul 10, 2018 at 04:48:21PM +0300, Kirill A. Shutemov wrote:
> > We now have all VMAs with ->vm_ops set and don't need to check it for
> > NULL everywhere.
> >
> > Signed-off-by: Kirill A. Shutemov
>
> This patch causes two of
On Wed, 11 Jul 2018 15:17:42 -0700 Guenter Roeck wrote:
> On Tue, Jul 10, 2018 at 04:48:21PM +0300, Kirill A. Shutemov wrote:
> > We now have all VMAs with ->vm_ops set and don't need to check it for
> > NULL everywhere.
> >
> > Signed-off-by: Kirill A. Shutemov
>
> This patch causes two of
Hello Doug,
> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
> wrote:
>> On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
>>> On Fri, Jun 29, 2018 at 02:29:55PM -0700, David Collins wrote:
>> ...
The PMIC TEMP_ALARM hardware peripheral will perform an automatic partial
PMIC shutdown
Hello Doug,
> On Tue, Jul 10, 2018 at 10:45 AM, David Collins
> wrote:
>> On 06/29/2018 04:54 PM, Matthias Kaehlcke wrote:
>>> On Fri, Jun 29, 2018 at 02:29:55PM -0700, David Collins wrote:
>> ...
The PMIC TEMP_ALARM hardware peripheral will perform an automatic partial
PMIC shutdown
ed for reference.
Reverting the patch fixes the problem.
[ Yes, I am aware that Michael already reported the problem at
https://lkml.org/lkml/2018/7/11/480 ]
Guenter
---
# bad: [98be45067040799a801e6ce52d8bf4659a153893] Add linux-next specific files
for 20180711
# good: [1e4b044d22517cae7047
ed for reference.
Reverting the patch fixes the problem.
[ Yes, I am aware that Michael already reported the problem at
https://lkml.org/lkml/2018/7/11/480 ]
Guenter
---
# bad: [98be45067040799a801e6ce52d8bf4659a153893] Add linux-next specific files
for 20180711
# good: [1e4b044d22517cae7047
_defconfig:mps2-an385
xtensa:de212:kc705-nommu:nommu_kc705_defconfig
Both are nommu configurations.
Reverting the patch fixes the problem. Bisect log is attached for reference.
Guenter
---
# bad: [98be45067040799a801e6ce52d8bf4659a153893] Add linux-next specific files
for
_defconfig:mps2-an385
xtensa:de212:kc705-nommu:nommu_kc705_defconfig
Both are nommu configurations.
Reverting the patch fixes the problem. Bisect log is attached for reference.
Guenter
---
# bad: [98be45067040799a801e6ce52d8bf4659a153893] Add linux-next specific files
for
Hi Matthias,
On Wed, Jul 11, 2018 at 2:51 PM, Matthias Kaehlcke wrote:
> On Wed, Jul 11, 2018 at 11:44:13AM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
>> wrote:
>> > SDM845 has two tsens blocks, one with 13 sensors and the other with 8
>> > sensors.
Hi Matthias,
On Wed, Jul 11, 2018 at 2:51 PM, Matthias Kaehlcke wrote:
> On Wed, Jul 11, 2018 at 11:44:13AM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Mon, Jul 9, 2018 at 4:43 AM, Amit Kucheria
>> wrote:
>> > SDM845 has two tsens blocks, one with 13 sensors and the other with 8
>> > sensors.
201 - 300 of 1754 matches
Mail list logo
