On Thu, Jan 20, 2011 at 2:22 PM, Linus Torvalds
wrote:
> On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua
> wrote:
>>
>> Rafael send out two patches earlier. Could be related. I was facing
>> issue during resume.
>
> No, I'm aware of the rcu-synchronize thing, this isn't it. This is
> really at the su
On Thu, 20 Jan 2011 08:07:02 -0800, Linus Torvalds wrote:
> On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson
> wrote:
> >
> > Right, the autoreported HEAD may have been already reset to 0 and so hit
> > the wraparound bug which caused it to exit early without actually
> > quiescing the ringbuffer.
On Thu, Jan 20, 2011 at 10:39 AM, Linus Torvalds
wrote:
> Ok, so I have a new issue that I'm currently bisecting but that people
> may be able to figure out even befor emy bisect finishes.
>
> On my slow Atom netbook (that I'm planning on using as my traveling
> companion for LCA), suspend-to-RAM
On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds
wrote:
>
> So how about just doing this in the loop? It will mean that the
> _first_ read uses the fast cached one (the common case, hopefully),
> but then if we loop, we'll use the slow exact one.
>
> (cut-and-paste, so whitespace isn't good):
>
>
On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds
wrote:
>
> So how about just doing this in the loop? It will mean that the
> _first_ read uses the fast cached one (the common case, hopefully),
> but then if we loop, we'll use the slow exact one.
>
> (cut-and-paste, so whitespace isn't good):
>
> ?
On Wed, 19 Jan 2011 22:22:48 -0800, Linus Torvalds wrote:
> On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua
> wrote:
> >
> > Rafael send out two patches earlier. Could be related. I was facing
> > issue during resume.
>
> No, I'm aware of the rcu-synchronize thing, this isn't it. This is
> really at
On Thu, Jan 20, 2011 at 9:38 AM, Chris Wilson wrote:
>
>> because from looking at the code, I get the notion that
>> "intel_read_status_page()" may not be exact. But what happens if that
>> inexact value matches our cached ring->actual_head, so we never even
>> try to read the exact case? Does it
On Thu, Jan 20, 2011 at 9:38 AM, Chris Wilson
wrote:
>
>> because from looking at the code, I get the notion that
>> "intel_read_status_page()" may not be exact. But what happens if that
>> inexact value matches our cached ring->actual_head, so we never even
>> try to read the exact case? Does it
On Thu, 20 Jan 2011 08:07:02 -0800, Linus Torvalds
wrote:
> On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson
> wrote:
> >
> > Right, the autoreported HEAD may have been already reset to 0 and so hit
> > the wraparound bug which caused it to exit early without actually
> > quiescing the ringbuffer.
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson wrote:
>
> Right, the autoreported HEAD may have been already reset to 0 and so hit
> the wraparound bug which caused it to exit early without actually
> quiescing the ringbuffer.
Yeah, that would explain the issue.
> Another possibility is that I ad
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson
wrote:
>
> Right, the autoreported HEAD may have been already reset to 0 and so hit
> the wraparound bug which caused it to exit early without actually
> quiescing the ringbuffer.
Yeah, that would explain the issue.
> Another possibility is that I a
On Thu, Jan 20, 2011 at 2:22 PM, Linus Torvalds
wrote:
> On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua wrote:
>>
>> Rafael send out two patches earlier. Could be related. I was facing
>> issue during resume.
>
> No, I'm aware of the rcu-synchronize thing, this isn't it. This is
> really at the suspe
On Wed, 19 Jan 2011 22:22:48 -0800, Linus Torvalds
wrote:
> On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua wrote:
> >
> > Rafael send out two patches earlier. Could be related. I was facing
> > issue during resume.
>
> No, I'm aware of the rcu-synchronize thing, this isn't it. This is
> really at t
On Thu, Jan 20, 2011 at 10:39 AM, Linus Torvalds
wrote:
> Ok, so I have a new issue that I'm currently bisecting but that people
> may be able to figure out even befor emy bisect finishes.
>
> On my slow Atom netbook (that I'm planning on using as my traveling
> companion for LCA), suspend-to-RAM
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua wrote:
>
> Rafael send out two patches earlier. Could be related. I was facing
> issue during resume.
No, I'm aware of the rcu-synchronize thing, this isn't it. This is
really at the suspend stage, and I had bisected it down to the drm
changes.
In fact,
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua wrote:
>
> Rafael send out two patches earlier. Could be related. I was facing
> issue during resume.
No, I'm aware of the rcu-synchronize thing, this isn't it. This is
really at the suspend stage, and I had bisected it down to the drm
changes.
In fact,
Ok, so I have a new issue that I'm currently bisecting but that people
may be able to figure out even befor emy bisect finishes.
On my slow Atom netbook (that I'm planning on using as my traveling
companion for LCA), suspend-to-RAM takes a long time with current git.
It's quite noticeable - it use
Ok, so I have a new issue that I'm currently bisecting but that people
may be able to figure out even befor emy bisect finishes.
On my slow Atom netbook (that I'm planning on using as my traveling
companion for LCA), suspend-to-RAM takes a long time with current git.
It's quite noticeable - it use
18 matches
Mail list logo
