Dear Keerthy,
On Mon, 2016-07-11 at 16:56 +0800, dawei chien wrote:
> Dear Keerthy,
>
> On Thu, 2016-07-07 at 17:24 +0530, Keerthy wrote:
> > Hi Dawei Chien,
> >
> >
> > On Thursday 07 July 2016 02:36 PM, Dawei Chien wrote:
> > > This patch adds support for mt2701 chip to mtk_thermal.c,
> > >
Dear Keerthy,
On Mon, 2016-07-11 at 16:56 +0800, dawei chien wrote:
> Dear Keerthy,
>
> On Thu, 2016-07-07 at 17:24 +0530, Keerthy wrote:
> > Hi Dawei Chien,
> >
> >
> > On Thursday 07 July 2016 02:36 PM, Dawei Chien wrote:
> > > This patch adds support for mt2701 chip to mtk_thermal.c,
> > >
On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote:
> On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote:
> > Hi Mike,
> >
> > On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote:
> > > Hi James,
> > >
> > > Quoting James Liao (2016-07-03 20:51:48)
> > > > On Fri, 2016-07-01 at 18:21
On Wed, 2016-08-03 at 13:46 +0800, James Liao wrote:
> On Mon, 2016-07-11 at 16:24 +0800, James Liao wrote:
> > Hi Mike,
> >
> > On Fri, 2016-07-08 at 16:32 -0700, Michael Turquette wrote:
> > > Hi James,
> > >
> > > Quoting James Liao (2016-07-03 20:51:48)
> > > > On Fri, 2016-07-01 at 18:21
On Fri, 5 Aug 2016 23:21:35 -0700
Tony Lindgren wrote:
> * Andreas Kemnade [160805 08:35]:
> > I repeat the subject line of the patch:
> > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()
> > It is *not* fix charging.
> >
> > So you
On Fri, 5 Aug 2016 23:21:35 -0700
Tony Lindgren wrote:
> * Andreas Kemnade [160805 08:35]:
> > I repeat the subject line of the patch:
> > [PATCH v2] musb: omap2430: do not assume balanced enable()/disable()
> > It is *not* fix charging.
> >
> > So you mean that the phy should magically know
On 08/08/2016 09:40 PM, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level randomization and
On 08/08/2016 09:40 PM, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level randomization and
>From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 9 Aug 2016 01:11:13 -0400
Debugging what goes wrong with cgroup setup can get hairy. Add
tracepoints for cgroup hierarchy mount, cgroup creation/destruction
and task migration
>From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 9 Aug 2016 01:11:13 -0400
Debugging what goes wrong with cgroup setup can get hairy. Add
tracepoints for cgroup hierarchy mount, cgroup creation/destruction
and task migration operations for
Hi Andrey,
> Am 09.08.2016 um 01:49 schrieb Andrey Utkin :
>
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>>
>> BR and thanks,
>>
Hi Andrey,
> Am 09.08.2016 um 01:49 schrieb Andrey Utkin :
>
> On Mon, Aug 08, 2016 at 11:26:38PM +0200, H. Nikolaus Schaller wrote:
>> Here is what I see in 4.8-rc1 on Pyra device after typing "poweroff".
>> I hope someone knows what it means.
>>
>> BR and thanks,
>> Nikolaus
>>
>>
Hi Linus,
I thought I should dequeue this, some of these could have made -rc1 if I'd
had less illness. This contains a bunch of amdgpu fixes, and some i915
regression fixes.
It also contains some fixes for an older regression with some EDID
changes and some 6bpc panels.
Then there are the
Hi Linus,
I thought I should dequeue this, some of these could have made -rc1 if I'd
had less illness. This contains a bunch of amdgpu fixes, and some i915
regression fixes.
It also contains some fixes for an older regression with some EDID
changes and some 6bpc panels.
Then there are the
The dummy version of kernfs_path_from_node() was missing. This
currently doesn't break anything. Let's add it for consistency and to
ease adding wrappers around it.
Signed-off-by: Tejun Heo
Cc: Greg Kroah-Hartman
---
include/linux/kernfs.h | 5
cgroup_path() and friends used to format the path from the end and
thus the resulting path usually didn't start at the start of the
passed in buffer. Also, when the buffer was too small, the partial
result was truncated from the head rather than tail and there was no
way to tell how long the full
The dummy version of kernfs_path_from_node() was missing. This
currently doesn't break anything. Let's add it for consistency and to
ease adding wrappers around it.
Signed-off-by: Tejun Heo
Cc: Greg Kroah-Hartman
---
include/linux/kernfs.h | 5 +
1 file changed, 5 insertions(+)
diff
cgroup_path() and friends used to format the path from the end and
thus the resulting path usually didn't start at the start of the
passed in buffer. Also, when the buffer was too small, the partial
result was truncated from the head rather than tail and there was no
way to tell how long the full
kernfs_path*() functions always return the length of the full path but
the path content is undefined if the length is larger than the
provided buffer. This makes its behavior different from strlcpy() and
requires error handling in all its users even when they don't care
about truncation. In
It doesn't have any in-kernel user and the same result can be obtained
from kernfs_path(@kn, NULL, 0). Remove it.
Signed-off-by: Tejun Heo
Cc: Serge Hallyn
Cc: Greg Kroah-Hartman
---
fs/kernfs/dir.c| 23
kernfs path formatting functions always return the length of full path
but the content of the output buffer is undefined when the length is
longer than the provided buffer. Most cgroup path formatting
functions return the start of the output or NULL on errors including
overflow. These
kernfs_path*() functions always return the length of the full path but
the path content is undefined if the length is larger than the
provided buffer. This makes its behavior different from strlcpy() and
requires error handling in all its users even when they don't care
about truncation. In
It doesn't have any in-kernel user and the same result can be obtained
from kernfs_path(@kn, NULL, 0). Remove it.
Signed-off-by: Tejun Heo
Cc: Serge Hallyn
Cc: Greg Kroah-Hartman
---
fs/kernfs/dir.c| 23 ---
include/linux/kernfs.h | 4
2 files changed, 27
kernfs path formatting functions always return the length of full path
but the content of the output buffer is undefined when the length is
longer than the provided buffer. Most cgroup path formatting
functions return the start of the output or NULL on errors including
overflow. These
On 04/08/16 22:24, Mimi Zohar wrote:
> The TPM PCRs are only reset on a hard reboot. In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and then restored on the subsequent
> boot.
>
> The existing securityfs
On 04/08/16 22:24, Mimi Zohar wrote:
> The TPM PCRs are only reset on a hard reboot. In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and then restored on the subsequent
> boot.
>
> The existing securityfs
Acked-by: Julia Lawall
On Mon, 8 Aug 2016, Jonathan Corbet wrote:
> No textual changes have been made, but the formatting has obviously been
> tweaked.
>
> Cc: Michal Marek
> Cc: Gilles Muller
> Cc: Nicolas Palix
Acked-by: Julia Lawall
On Mon, 8 Aug 2016, Jonathan Corbet wrote:
> No textual changes have been made, but the formatting has obviously been
> tweaked.
>
> Cc: Michal Marek
> Cc: Gilles Muller
> Cc: Nicolas Palix
> Cc: Julia Lawall
> Signed-off-by: Jonathan Corbet
> ---
>
Vince Weaver writes:
> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
>
Vince Weaver writes:
> Hello
>
> running the perf_fuzzer on Haswell, this is a new warning I don't think
> I've seen before.
>
> It works out to be this code here:
>
> /* this has to be the last one */
> rb_free_aux(rb);
>
On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.6.6 release.
There are 96 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.6.6 release.
There are 96 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
Hi Nilay,
Sounds good, I will post an updated version.
Thanks,
David
On Mon, Aug 8, 2016 at 9:12 AM, Nilay Vaish wrote:
> On 7 August 2016 at 15:10, David Carrillo-Cisneros wrote:
>> Hi Nilay,
>>
static int perf_event_read(struct perf_event
Hi Nilay,
Sounds good, I will post an updated version.
Thanks,
David
On Mon, Aug 8, 2016 at 9:12 AM, Nilay Vaish wrote:
> On 7 August 2016 at 15:10, David Carrillo-Cisneros wrote:
>> Hi Nilay,
>>
static int perf_event_read(struct perf_event *event, bool group)
{
- int
In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
directly if req->status has been set to a non-zero value. This will
cause driver hang as soon as transfer time out is triggered.
In my test case, below system log
In sg_timeout(), req->status is set to "-ETIMEDOUT" before calling
into usb_sg_cancel(). usb_sg_cancel() will do nothing and return
directly if req->status has been set to a non-zero value. This will
cause driver hang as soon as transfer time out is triggered.
In my test case, below system log
On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
> handled by EDAC.
And how is mpc85_xxx EDAC handling them?
mpc85xx_mc_check() only reports them.
And now to get to my original question: is it *enough* to report
On Tue, Aug 09, 2016 at 04:31:19AM +, york sun wrote:
> Yes, for most SoCs RFXE remains cleared. Uncorrectable errors are
> handled by EDAC.
And how is mpc85_xxx EDAC handling them?
mpc85xx_mc_check() only reports them.
And now to get to my original question: is it *enough* to report
Hello,
I hope this Message finds you well.
To start with my name is George Oloni. I am seeking for your cooperation to
invest in your Country.
Please kindly respond to this message as to enable me to gives you More Details
about my investment proposal.
Warm Regards
Mr. George Oloni
Hello,
I hope this Message finds you well.
To start with my name is George Oloni. I am seeking for your cooperation to
invest in your Country.
Please kindly respond to this message as to enable me to gives you More Details
about my investment proposal.
Warm Regards
Mr. George Oloni
Hi, Arnaldo :)
On 08/09/2016 03:58 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Aug 02, 2016 at 06:20:46PM +0900, Taeung Song escreveu:
To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
also have only
Hi, Arnaldo :)
On 08/09/2016 03:58 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Aug 02, 2016 at 06:20:46PM +0900, Taeung Song escreveu:
To easily set default config values into actual variables for 'colors' config,
it would be better that actual variables for each 'colors' config
also have only
Соберем для Вас по интернет базу данных
потенциальных клиентов для Вашего Бизнеса!
В базе будут все контактные данные необходимые
для массовой продажи Ваших товаров и услуг.
По Вашему запросу пришлем пример и подробную информацию.
Если интересно запросите подробности сейчас
Email:
Соберем для Вас по интернет базу данных
потенциальных клиентов для Вашего Бизнеса!
В базе будут все контактные данные необходимые
для массовой продажи Ваших товаров и услуг.
По Вашему запросу пришлем пример и подробную информацию.
Если интересно запросите подробности сейчас
Email:
I wasn't able to repro this with mainline. Sorry for the noise.
On 8/6/2016 1:49 PM, Babu Moger wrote:
Hi,
Seeing some terrible write performance with ext3/4 writes. Reads are
fine.
I have a created loop device and mounted as ext3(tried ext4 also).
Here is iostat output. await time is
I wasn't able to repro this with mainline. Sorry for the noise.
On 8/6/2016 1:49 PM, Babu Moger wrote:
Hi,
Seeing some terrible write performance with ext3/4 writes. Reads are
fine.
I have a created loop device and mounted as ext3(tried ext4 also).
Here is iostat output. await time is
On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter wrote:
>
> On 06/08/16 00:45, John Stultz wrote:
>> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter wrote:
>>> Hi John,
>>>
>>> On 30/07/16 05:39, John Stultz wrote:
Hey Jon,
So after rebasing my nexus7
On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter wrote:
>
> On 06/08/16 00:45, John Stultz wrote:
>> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter wrote:
>>> Hi John,
>>>
>>> On 30/07/16 05:39, John Stultz wrote:
Hey Jon,
So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.17 release.
There are 68 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 08/08/2016 12:10 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.17 release.
There are 68 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 08/08/2016 12:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.14.75 release.
There are 21 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 08/08/2016 12:09 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.14.75 release.
There are 21 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On August 8, 2016 9:01:42 PM PDT, Borislav Petkov wrote:
>On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
>> Default implementation expects 6 pages maximum are needed for low
>page
>> allocations. If KASLR memory randomization is enabled, the worse case
>> of e820
On August 8, 2016 9:01:42 PM PDT, Borislav Petkov wrote:
>On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
>> Default implementation expects 6 pages maximum are needed for low
>page
>> allocations. If KASLR memory randomization is enabled, the worse case
>> of e820 layout would
On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level
On Mon, Aug 08, 2016 at 11:40:07AM -0700, Thomas Garnier wrote:
> Default implementation expects 6 pages maximum are needed for low page
> allocations. If KASLR memory randomization is enabled, the worse case
> of e820 layout would require 12 pages (no large pages). It is due to the
> PUD level
Hi Rik,
2016-07-13 22:50 GMT+08:00 Frederic Weisbecker :
> From: Rik van Riel
>
> Currently, if there was any irq or softirq time during 'ticks'
> jiffies, the entire period will be accounted as irq or softirq
> time.
>
> This is inaccurate if only a subset of
Hi Rik,
2016-07-13 22:50 GMT+08:00 Frederic Weisbecker :
> From: Rik van Riel
>
> Currently, if there was any irq or softirq time during 'ticks'
> jiffies, the entire period will be accounted as irq or softirq
> time.
>
> This is inaccurate if only a subset of the time was actually spent
>
Hi all,
Changes since 20160808:
Linus' tree lost the build failure (this was actually an rdma tree
problem).
The sound-asoc tree lost its build failure.
Non-merge commits (relative to Linus' tree): 978
965 files changed, 27099 insertions(+), 7759 deletions
Hi all,
Changes since 20160808:
Linus' tree lost the build failure (this was actually an rdma tree
problem).
The sound-asoc tree lost its build failure.
Non-merge commits (relative to Linus' tree): 978
965 files changed, 27099 insertions(+), 7759 deletions
Boris Brezillon writes:
> cirrus_modeset_init() is initializing/registering the emulated fbdev
> and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> !funcs->best_encoder is valid"), DRM internals can access/test some of
> the fields in
Boris Brezillon writes:
> cirrus_modeset_init() is initializing/registering the emulated fbdev
> and, since commit c61b93fe51b1 ("drm/atomic: Fix remaining places where
> !funcs->best_encoder is valid"), DRM internals can access/test some of
> the fields in mode_config->funcs as part of the
On 07/27/2016 11:12 AM, Christoph Lameter wrote:
On Mon, 25 Jul 2016, Tejun Heo wrote:
I don't get it. What's the harm of using percpu memory here? Other
percpu data structures have remote access too. They're to a lower
degree but I don't see a clear demarcation line and making addtions
On 07/27/2016 11:12 AM, Christoph Lameter wrote:
On Mon, 25 Jul 2016, Tejun Heo wrote:
I don't get it. What's the harm of using percpu memory here? Other
percpu data structures have remote access too. They're to a lower
degree but I don't see a clear demarcation line and making addtions
On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote:
> On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote:
> > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to
> archs.
> > v4: Add comments explaining when to call acpi_ioapic_add().
> > v3: Previous versions break mips.
On Tuesday, Aug 9, 2016 4:23 AM, Bjorn Helgaas wrote:
> On Sun, Jun 26, 2016 at 11:44:57AM +0800, Rui Wang wrote:
> > v5: Remove #ifdef CONFIG_X86 from setup-bus.c, making it neutral to
> archs.
> > v4: Add comments explaining when to call acpi_ioapic_add().
> > v3: Previous versions break mips.
Add a delay before checking device ready for memblaze device
Signed-off-by: Wenbo Wang
---
drivers/nvme/host/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c82282f..ab90e5f 100644
---
Add a delay before checking device ready for memblaze device
Signed-off-by: Wenbo Wang
---
drivers/nvme/host/pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c82282f..ab90e5f 100644
--- a/drivers/nvme/host/pci.c
+++
On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
> RFXE is cleared by default. So for most SoCs, this is not even a concern
> at all. But for e500v1, when RIO or PCI are used, this bit is set
> specifically to catch an error by machine check (see commit 4e0e3435).
> This is not the
On Mon, Aug 08, 2016 at 03:39:44PM +, york sun wrote:
> RFXE is cleared by default. So for most SoCs, this is not even a concern
> at all. But for e500v1, when RIO or PCI are used, this bit is set
> specifically to catch an error by machine check (see commit 4e0e3435).
> This is not the
From: Yonglong Wu
According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.
Signed-off-by: Yonglong Wu
---
drivers/usb/core/hub.c |2 +-
1 file
From: Yonglong Wu
According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.
Signed-off-by: Yonglong Wu
---
drivers/usb/core/hub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Yonglong Wu
According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.
Change-Id: Ie744b95f12d7d21d9519e77ed706c8cc33fa
Signed-off-by: Yonglong Wu
Hi Mark
> > snd_soc_pcm_set_drvdata() will set driver data to rtd->dev,
> > but driver data of rtd->dev is already used as "rtd" on
> > soc_post_component_init().
>
> This doesn't apply against current code, please check and resend.
Thanks.
It seems current your branch already has same patch.
From: Yonglong Wu
According to USB30 specification, the Function Remote Wakeup field can be
modified by the SetFeature() requests. SetFeature() is recommended to use.
Change-Id: Ie744b95f12d7d21d9519e77ed706c8cc33fa
Signed-off-by: Yonglong Wu
---
drivers/usb/core/hub.c |2 +-
1 file
Hi Mark
> > snd_soc_pcm_set_drvdata() will set driver data to rtd->dev,
> > but driver data of rtd->dev is already used as "rtd" on
> > soc_post_component_init().
>
> This doesn't apply against current code, please check and resend.
Thanks.
It seems current your branch already has same patch.
A new task inherits cpus_allowed and mems_allowed masks from its parent,
but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
before this new task is inserted into the cgroup's task list, the new task
won't be updated accordingly.
Signed-off-by: Zefan Li
A new task inherits cpus_allowed and mems_allowed masks from its parent,
but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
before this new task is inserted into the cgroup's task list, the new task
won't be updated accordingly.
Signed-off-by: Zefan Li
---
On 2016/08/08 09:26, Andreas Werner wrote:
[...]
> > > +
> > > + if (cf->can_dlc > 0)
> > > + data[0] = be32_to_cpup((__be32 *)(cf->data));
> > > + if (cf->can_dlc > 3)
> > > + data[1] = be32_to_cpup((__be32 *)(cf->data + 4));
> > > +
> > > + writel(id, _buf->can_id);
> > > +
On 2016/08/08 09:26, Andreas Werner wrote:
[...]
> > > +
> > > + if (cf->can_dlc > 0)
> > > + data[0] = be32_to_cpup((__be32 *)(cf->data));
> > > + if (cf->can_dlc > 3)
> > > + data[1] = be32_to_cpup((__be32 *)(cf->data + 4));
> > > +
> > > + writel(id, _buf->can_id);
> > > +
On 08/08, valdis.kletni...@vt.edu wrote:
>On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> > In other words - how did this patch get into a tree that 0day listens to?
>>
>> 0Day has a service to automatically capture every patchset sent to LKML
>
On 08/08, valdis.kletni...@vt.edu wrote:
>On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> > In other words - how did this patch get into a tree that 0day listens to?
>>
>> 0Day has a service to automatically capture every patchset sent to LKML
>
On 08/09, Al Viro wrote:
>On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said:
>> >
>> >> FYI, we noticed the following commit:
>> >>
>> >> https://github.com/0day-ci/linux
>> >>
On 08/09, Al Viro wrote:
>On Tue, Aug 09, 2016 at 09:17:58AM +0800, Ye Xiaolong wrote:
>> On 08/08, valdis.kletni...@vt.edu wrote:
>> >On Sun, 07 Aug 2016 22:02:42 +0800, kernel test robot said:
>> >
>> >> FYI, we noticed the following commit:
>> >>
>> >> https://github.com/0day-ci/linux
>> >>
Allow some seq_puts removals by taking a string instead of a single char.
Signed-off-by: Joe Perches
---
On top of Alexey's patch, this would also save a couple percent CPU
fs/proc/array.c | 178 ++-
fs/proc/stat.c
Allow some seq_puts removals by taking a string instead of a single char.
Signed-off-by: Joe Perches
---
On top of Alexey's patch, this would also save a couple percent CPU
fs/proc/array.c | 178 ++-
fs/proc/stat.c | 49
On 8 August 2016 at 19:40, Daniel Vetter wrote:
> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>> Hello there,
>>
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
>> requires 37 bits to represent, but
On 8 August 2016 at 19:40, Daniel Vetter wrote:
> On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
>> Hello there,
>>
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
>> requires 37 bits to represent, but ‘int’ only has 32
> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast
> (de)inflating
> & fast live migration
>
> On 08/07/2016 11:35 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
>
>
> Subject: Re: [PATCH v3 kernel 0/7] Extend virtio-balloon for fast
> (de)inflating
> & fast live migration
>
> On 08/07/2016 11:35 PM, Liang Li wrote:
> > Dave Hansen suggested a new scheme to encode the data structure,
> > because of additional complexity, it's not implemented in v3.
>
>
Perf-probe detects a variable's type and use the detected type to add new
probe. Then, kprobes prints its variable in hexadecimal format if the
variable is unsigned and prints in decimal if it is signed.
We sometimes want to see unsigned variable in decimal format (i.e.
sector_t or size_t). In
Perf-probe detects a variable's type and use the detected type to add new
probe. Then, kprobes prints its variable in hexadecimal format if the
variable is unsigned and prints in decimal if it is signed.
We sometimes want to see unsigned variable in decimal format (i.e.
sector_t or size_t). In
On Tue, Aug 09, 2016 at 12:13:01AM +0300, Török Edwin wrote:
> On 2016-08-08 19:55, Darrick J. Wong wrote:
> > On Mon, Aug 08, 2016 at 12:08:18PM -0400, Theodore Ts'o wrote:
> >> On Sun, Aug 07, 2016 at 11:28:10PM -0700, Darrick J. Wong wrote:
> >>>
> >>> I have one lingering concern -- is it a
On Tue, Aug 09, 2016 at 12:13:01AM +0300, Török Edwin wrote:
> On 2016-08-08 19:55, Darrick J. Wong wrote:
> > On Mon, Aug 08, 2016 at 12:08:18PM -0400, Theodore Ts'o wrote:
> >> On Sun, Aug 07, 2016 at 11:28:10PM -0700, Darrick J. Wong wrote:
> >>>
> >>> I have one lingering concern -- is it a
+ Archit
On 08/09/2016 02:53 AM, Sean Paul wrote:
Instead of just preparing the panel on bind, actually prepare/unprepare
during modeset/disable. The panel must be prepared in order to read hpd
status and edid, so we need to keep state around the prepares in order
to ensure we don't
+ Archit
On 08/09/2016 02:53 AM, Sean Paul wrote:
Instead of just preparing the panel on bind, actually prepare/unprepare
during modeset/disable. The panel must be prepared in order to read hpd
status and edid, so we need to keep state around the prepares in order
to ensure we don't
Build results:
total: 148 pass: 142 fail: 6
Failed builds:
h8300:allnoconfig
h8300:edosk2674_defconfig
h8300:h8300h-sim_defconfig
h8300:h8s-sim_defconfig
unicore32:defconfig
unicore32:allnoconfig
Qemu test results:
total: 107 pass:
Build results:
total: 148 pass: 142 fail: 6
Failed builds:
h8300:allnoconfig
h8300:edosk2674_defconfig
h8300:h8300h-sim_defconfig
h8300:h8s-sim_defconfig
unicore32:defconfig
unicore32:allnoconfig
Qemu test results:
total: 107 pass:
On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
> On 08/08, valdis.kletni...@vt.edu wrote:
> > In other words - how did this patch get into a tree that 0day listens to?
>
> 0Day has a service to automatically capture every patchset sent to LKML
Something's wrong then. Nick has proven to be
On Tue, 09 Aug 2016 09:17:58 +0800, Ye Xiaolong said:
> On 08/08, valdis.kletni...@vt.edu wrote:
> > In other words - how did this patch get into a tree that 0day listens to?
>
> 0Day has a service to automatically capture every patchset sent to LKML
Something's wrong then. Nick has proven to be
1 - 100 of 1814 matches
Mail list logo