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
On Wed, 12 Jan 2011 15:05:36 -0800, Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 2:40 PM, Chris Wilson
> wrote:
> > Just the SNB machine?
>
> No. I just checked. Reverting that commit on my other machine makes
> that TED video on my Core i5 machine look fine too.
>
> So it's definitely the
On Wed, 12 Jan 2011 14:24:17 -0800, Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
> wrote:
> >
> > Oh, and I'm also seeing corruption on my sandybridge machine. No video
> > involved, the gdm login screen is already corrupted this way. Similar
> > odd shifted lines etc,
On Wed, 12 Jan 2011 15:05:36 -0800, Linus Torvalds
wrote:
> On Wed, Jan 12, 2011 at 2:40 PM, Chris Wilson
> wrote:
> > Just the SNB machine?
>
> No. I just checked. Reverting that commit on my other machine makes
> that TED video on my Core i5 machine look fine too.
>
> So it's definitely the
On Wed, 12 Jan 2011 14:31:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes
> wrote:
> >
> > Ah, ok. So it could be our internal FDI link is underrunning; it goes
> > between the CPU and PCH and carries display bits.
>
> I'm not sure it's an underrun or anything l
On Wed, 12 Jan 2011 14:31:33 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes
> wrote:
> >
> > Ah, ok. ?So it could be our internal FDI link is underrunning; it goes
> > between the CPU and PCH and carries display bits.
>
> I'm not sure it's an underrun or anything l
On Wed, Jan 12, 2011 at 2:40 PM, Chris Wilson
wrote:
>
> Wow. That should have had zero visible impact upon the rendering. All it
> should have done is reorder the sequence in which we pin the buffers into
> the GTT before applying the relocations, just to allow some pathological
> execbuffers.
>
On Wed, 12 Jan 2011 14:24:17 -0800, Linus Torvalds
wrote:
> On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
> wrote:
> >
> > Oh, and I'm also seeing corruption on my sandybridge machine. No video
> > involved, the gdm login screen is already corrupted this way. Similar
> > odd shifted lines etc,
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes wrote:
>
> Ah, ok. So it could be our internal FDI link is underrunning; it goes
> between the CPU and PCH and carries display bits.
I'm not sure it's an underrun or anything like that: the corruption is
long-term in the non-video case. So I take bac
On Wed, Jan 12, 2011 at 2:22 PM, Jesse Barnes
wrote:
>
> Ah, ok. ?So it could be our internal FDI link is underrunning; it goes
> between the CPU and PCH and carries display bits.
I'm not sure it's an underrun or anything like that: the corruption is
long-term in the non-video case. So I take ba
On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
wrote:
>
> Oh, and I'm also seeing corruption on my sandybridge machine. No video
> involved, the gdm login screen is already corrupted this way. Similar
> odd shifted lines etc, so I'd assume it's related.
Hmm. I bisected it down to
commit 6fe4f
On Wed, Jan 12, 2011 at 1:28 PM, Linus Torvalds
wrote:
>
> Oh, and I'm also seeing corruption on my sandybridge machine. No video
> involved, the gdm login screen is already corrupted this way. Similar
> odd shifted lines etc, so I'd assume it's related.
Hmm. I bisected it down to
commit 6fe4f
On Wed, 12 Jan 2011 13:28:53 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
> wrote:
> > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> > wrote:
> >>
> >> Since I doubt we're actually offloading to our video decode kernels for
> >> Flash video on your machine
On Wed, 12 Jan 2011 13:28:53 -0800
Linus Torvalds wrote:
> On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
> wrote:
> > On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes > virtuousgeek.org> wrote:
> >>
> >> Since I doubt we're actually offloading to our video decode kernels for
> >> Flash video o
On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
wrote:
> On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> wrote:
>>
>> Since I doubt we're actually offloading to our video decode kernels for
>> Flash video on your machine
>
> It's the latest 64-bit beta flash player, so maybe it does use hw
>
On Wed, Jan 12, 2011 at 12:27 PM, Linus Torvalds
wrote:
> On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
> wrote:
>>
>> Since I doubt we're actually offloading to our video decode kernels for
>> Flash video on your machine
>
> It's the latest 64-bit beta flash player, so maybe it does use hw
>
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes wrote:
>
> Since I doubt we're actually offloading to our video decode kernels for
> Flash video on your machine
It's the latest 64-bit beta flash player, so maybe it does use hw acceleration.
> it could very well be a memory
On Wed, Jan 12, 2011 at 11:46 AM, Jesse Barnes
wrote:
>
> Since I doubt we're actually offloading to our video decode kernels for
> Flash video on your machine
It's the latest 64-bit beta flash player, so maybe it does use hw acceleration.
> it could very well be a memory
On Wed, 12 Jan 2011 11:22:58 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote:
> >
> > I'm stuck at home with just my i5 laptop due to the office being shut due
> > to the ongoing floods. But I've booted and ran this for a few hours and it
> > seems to be better
On Wed, 12 Jan 2011 11:22:58 -0800
Linus Torvalds wrote:
> On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote:
> >
> > I'm stuck at home with just my i5 laptop due to the office being shut due
> > to the ongoing floods. But I've booted and ran this for a few hours and it
> > seems to be better
On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote:
>
> I'm stuck at home with just my i5 laptop due to the office being shut due
> to the ongoing floods. But I've booted and ran this for a few hours and it
> seems to be better than the current tree. It contains a couple of patches
> to fix DMAR
On Tue, Jan 11, 2011 at 10:03 PM, Dave Airlie wrote:
>
> I'm stuck at home with just my i5 laptop due to the office being shut due
> to the ongoing floods. But I've booted and ran this for a few hours and it
> seems to be better than the current tree. It contains a couple of patches
> to fix DMAR
I'm stuck at home with just my i5 laptop due to the office being shut due
to the ongoing floods. But I've booted and ran this for a few hours and it
seems to be better than the current tree. It contains a couple of patches
to fix DMAR interaction issues I see on this laptop on top of Chris's
pu
I'm stuck at home with just my i5 laptop due to the office being shut due
to the ongoing floods. But I've booted and ran this for a few hours and it
seems to be better than the current tree. It contains a couple of patches
to fix DMAR interaction issues I see on this laptop on top of Chris's
pu
41 matches
Mail list logo
