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 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, 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 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, 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, 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 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, 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 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 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 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 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, 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 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, 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, 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 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, 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 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 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 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 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, 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 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, 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, 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 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, 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 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 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 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 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, 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 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, 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, 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 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, 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 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 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 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 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, 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 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, 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, 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 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, 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 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 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 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 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, 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 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, 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, 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 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, 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 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 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
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, 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 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, 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 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, 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, 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 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: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):
>
> ?
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, 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 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, 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 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, 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, 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 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: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):
>
> ?
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
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, 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 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, 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 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, 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, 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 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: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):
>
> ?
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, 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 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, 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 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, 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, 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 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
1 - 100 of 168 matches
Mail list logo
