Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-20 Thread Jeff Chua
On Thu, Jan 20, 2011 at 10:39 AM, Linus Torvalds torva...@linux-foundation.org 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

Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-20 Thread Chris Wilson
On Wed, 19 Jan 2011 22:22:48 -0800, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua jeff.chua.li...@gmail.com wrote: Rafael send out two patches earlier. Could be related. I was facing issue during resume. No, I'm aware of the

Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-20 Thread Jeff Chua
On Thu, Jan 20, 2011 at 2:22 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua jeff.chua.li...@gmail.com wrote: Rafael send out two patches earlier. Could be related. I was facing issue during resume. No, I'm aware of the rcu-synchronize

Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-20 Thread Linus Torvalds
On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson ch...@chris-wilson.co.uk 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

Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-20 Thread Chris Wilson
On Thu, 20 Jan 2011 08:07:02 -0800, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Jan 20, 2011 at 2:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Right, the autoreported HEAD may have been already reset to 0 and so hit the wraparound bug which caused it to exit early

Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-20 Thread Linus Torvalds
On Thu, Jan 20, 2011 at 9:51 AM, Linus Torvalds torva...@linux-foundation.org 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

more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-19 Thread Linus Torvalds
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

Re: more intel drm issues (was Re: [git pull] drm intel only fixes)

2011-01-19 Thread Linus Torvalds
On Wed, Jan 19, 2011 at 8:55 PM, Jeff Chua jeff.chua.li...@gmail.com 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