On Fri, 29 Jul 2016, Chen Yu wrote:
> On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> 1st is to bypass the sleep time if pm_trace is involved(a little complicated
> because it needs to deal with historical pm_trace), or
>
> 2nd version is to introduce a sysfs interface to
On Fri, 29 Jul 2016, Chen Yu wrote:
> On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> 1st is to bypass the sleep time if pm_trace is involved(a little complicated
> because it needs to deal with historical pm_trace), or
>
> 2nd version is to introduce a sysfs interface to
Hi Thomas,
On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Chen Yu wrote:
> > On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > > Further investigation shows that, the problem is caused by setting
> > > >
Hi Thomas,
On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Chen Yu wrote:
> > On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > > Further investigation shows that, the problem is caused by setting
> > > >
Hi,
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, July 20, 2016 9:00 PM
> To: Chen, Yu C
> Cc: Thomas Gleixner; John Stultz; Linux PM; Linux Kernel Mailing List
> Subject: Re: [PATCH][v2] timekeeping: Fix memory overwrite
Hi,
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Wednesday, July 20, 2016 9:00 PM
> To: Chen, Yu C
> Cc: Thomas Gleixner; John Stultz; Linux PM; Linux Kernel Mailing List
> Subject: Re: [PATCH][v2] timekeeping: Fix memory overwrite
On Wednesday, July 20, 2016 07:06:58 PM Chen Yu wrote:
> Hi Thomas,
> On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > > > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > > > Further
On Wednesday, July 20, 2016 07:06:58 PM Chen Yu wrote:
> Hi Thomas,
> On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > > > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > > > Further
Hi Thomas,
On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Chen Yu wrote:
> > On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > > Further investigation shows that, the problem is caused by setting
> > > >
Hi Thomas,
On Tue, Jul 19, 2016 at 12:40:14PM +0200, Thomas Gleixner wrote:
> On Tue, 19 Jul 2016, Chen Yu wrote:
> > On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > > Further investigation shows that, the problem is caused by setting
> > > >
On Tue, 19 Jul 2016, Chen Yu wrote:
> On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > Further investigation shows that, the problem is caused by setting
> > > /sys/power/pm_trace to 1 before the 1st hibernation, since once
> > > pm_trace is enabled, the
On Tue, 19 Jul 2016, Chen Yu wrote:
> On 2016年07月19日 16:36, Thomas Gleixner wrote:
> > On Tue, 19 Jul 2016, Chen Yu wrote:
> > > Further investigation shows that, the problem is caused by setting
> > > /sys/power/pm_trace to 1 before the 1st hibernation, since once
> > > pm_trace is enabled, the
Hi Thomas,
On 2016年07月19日 16:36, Thomas Gleixner wrote:
On Tue, 19 Jul 2016, Chen Yu wrote:
It is reported the hibernation fails at 2nd attempt, which
hangs at hibernate() -> syscore_resume() -> i8237A_resume()
-> claim_dma_lock(), because the lock has already been taken.
However there is
Hi Thomas,
On 2016年07月19日 16:36, Thomas Gleixner wrote:
On Tue, 19 Jul 2016, Chen Yu wrote:
It is reported the hibernation fails at 2nd attempt, which
hangs at hibernate() -> syscore_resume() -> i8237A_resume()
-> claim_dma_lock(), because the lock has already been taken.
However there is
On Tue, 19 Jul 2016, Chen Yu wrote:
> It is reported the hibernation fails at 2nd attempt, which
> hangs at hibernate() -> syscore_resume() -> i8237A_resume()
> -> claim_dma_lock(), because the lock has already been taken.
> However there is actually no other process would like to grab
> this
On Tue, 19 Jul 2016, Chen Yu wrote:
> It is reported the hibernation fails at 2nd attempt, which
> hangs at hibernate() -> syscore_resume() -> i8237A_resume()
> -> claim_dma_lock(), because the lock has already been taken.
> However there is actually no other process would like to grab
> this
It is reported the hibernation fails at 2nd attempt, which
hangs at hibernate() -> syscore_resume() -> i8237A_resume()
-> claim_dma_lock(), because the lock has already been taken.
However there is actually no other process would like to grab
this lock on that problematic platform.
Further
It is reported the hibernation fails at 2nd attempt, which
hangs at hibernate() -> syscore_resume() -> i8237A_resume()
-> claim_dma_lock(), because the lock has already been taken.
However there is actually no other process would like to grab
this lock on that problematic platform.
Further
18 matches
Mail list logo