Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
Doesn't make sense to disable in the other order.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
Need to turn on the error correction when enabling training or it
might not get enabled in time.
This seems to fix the FDI-B/FDI-C link training problem.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions
James Bottomley writes:
> on 3.5 killing X causes idle power to go 14W -> 5.9W
> on 3.4.6 killing X causes idle power to go 6.8W -> 5.7W
That's actually pretty good news -- you're just not getting to RC6
when X is running, but RC6 is otherwise working. And, yes, the GPU
really can suck that
James Bottomley james.bottom...@hansenpartnership.com writes:
on 3.5 killing X causes idle power to go 14W - 5.9W
on 3.4.6 killing X causes idle power to go 6.8W - 5.7W
That's actually pretty good news -- you're just not getting to RC6
when X is running, but RC6 is otherwise working. And, yes,
James Bottomley writes:
> On Mon, 2012-07-30 at 09:33 -0700, Keith Packard wrote:
>> James Bottomley writes:
>>
>> > OK, I've run the bisect as far as I can. It looks to be in the drm
>> > tree. Unfortunately, this tree has several merge points, some of whi
James Bottomley writes:
> OK, I've run the bisect as far as I can. It looks to be in the drm
> tree. Unfortunately, this tree has several merge points, some of which
> go further back than v3.4. Unfortunately, once the bisect steps back
> before 3.4, we lose the changes that gave us the power
James Bottomley james.bottom...@hansenpartnership.com writes:
OK, I've run the bisect as far as I can. It looks to be in the drm
tree. Unfortunately, this tree has several merge points, some of which
go further back than v3.4. Unfortunately, once the bisect steps back
before 3.4, we lose
James Bottomley james.bottom...@hansenpartnership.com writes:
On Mon, 2012-07-30 at 09:33 -0700, Keith Packard wrote:
James Bottomley james.bottom...@hansenpartnership.com writes:
OK, I've run the bisect as far as I can. It looks to be in the drm
tree. Unfortunately, this tree has
<#part sign=pgpmime>
On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson wrote:
> Certainly an improvement.
>
> Reviewed-by: Adam Jackson
I'd like to know if this actually helps someone before I stick it in
drm-intel-fixes...
--
keith.packard at intel.com
#part sign=pgpmime
On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson a...@redhat.com wrote:
Certainly an improvement.
Reviewed-by: Adam Jackson a...@redhat.com
I'd like to know if this actually helps someone before I stick it in
drm-intel-fixes...
--
keith.pack...@intel.com
<#part sign=pgpmime>
On Thu, 29 Mar 2012 08:14:08 +0100 (IST), Dave Airlie
wrote:
> Dave Airlie (1):
> drm/i915: suspend fbdev device around suspend/hibernate
This has my Reviewed-by on it; Dave suggested just sending it directly
to you instead of running it through my tree and then back
#part sign=pgpmime
On Thu, 29 Mar 2012 08:14:08 +0100 (IST), Dave Airlie airl...@linux.ie wrote:
Dave Airlie (1):
drm/i915: suspend fbdev device around suspend/hibernate
This has my Reviewed-by on it; Dave suggested just sending it directly
to you instead of running it through my tree
<#part sign=pgpmime>
On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka
wrote:
> Keith, is there a chance that this bug can be fixed by i915 team?
Yes, I'm working on figuring out how to actually reproduce this and then
work on a few work-arounds.
> If not, can we disable hibernate on i915
#part sign=pgpmime
On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka sgrus...@redhat.com
wrote:
Keith, is there a chance that this bug can be fixed by i915 team?
Yes, I'm working on figuring out how to actually reproduce this and then
work on a few work-arounds.
If not, can we disable
<#part sign=pgpmime>
On Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins
wrote:
> __GFP_MOVABLE is a hint to page allocation that there's a good likelihood
> that this logical page can be migrated elsewhere in physical memory later
> on if mm wants, so it's a good idea to allocate it from a
<#part sign=pgpmime>
On Sat, 17 Mar 2012 15:52:15 -0700, Linus Torvalds wrote:
> I do not believe we actually ever uncovered the original problem with
> _MOVABLE: the problem was bisected down to the stable-backported
> version of commit 4bdadb978569 ("drm/i915: Selectively enable
>
<#part sign=pgpmime>
On Sat, 17 Mar 2012 07:41:14 +, Dave Airlie wrote:
> We've had reports on 965GM in Fedora, maybe davej has the specific
> bug.
Are these reports relatively recent, leading to a possible software bug
introduced in the last couple of releases?
--
keith.packard at
#part sign=pgpmime
On Sat, 17 Mar 2012 07:41:14 +, Dave Airlie airl...@gmail.com wrote:
We've had reports on 965GM in Fedora, maybe davej has the specific
bug.
Are these reports relatively recent, leading to a possible software bug
introduced in the last couple of releases?
--
#part sign=pgpmime
On Sat, 17 Mar 2012 15:52:15 -0700, Linus Torvalds
torva...@linux-foundation.org wrote:
I do not believe we actually ever uncovered the original problem with
_MOVABLE: the problem was bisected down to the stable-backported
version of commit 4bdadb978569 (drm/i915:
#part sign=pgpmime
On Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins hu...@google.com wrote:
__GFP_MOVABLE is a hint to page allocation that there's a good likelihood
that this logical page can be migrated elsewhere in physical memory later
on if mm wants, so it's a good idea to allocate
<#part sign=pgpmime>
On Fri, 16 Mar 2012 16:24:35 -0700, Linus Torvalds wrote:
> Well, even without hibernation, one theory was about the VC switching
> - apparently that was one thing that at least one reporter does end up
> doing - switching from X into the virtual terminals and back.
Thanks
<#part sign=pgpmime>
On Fri, 16 Mar 2012 16:47:46 +, Dave Airlie wrote:
> The hibernate issue is known and I've been hoping someone from Intel
> would run with debugging it, they have a big enough team that I don't
> feel I can expend the personal time to look into it.
Yeah, I've been
<#part sign=pgpmime>
On Fri, 16 Mar 2012 09:11:54 -0700, Linus Torvalds wrote:
> I don't know if these kinds of things have been forwarded to you, but
> there's apparently been several things like this going on - with the
> finger pointing to the i915 driver apparently clearing random memory.
>
#part sign=pgpmime
On Fri, 16 Mar 2012 16:47:46 +, Dave Airlie airl...@gmail.com wrote:
The hibernate issue is known and I've been hoping someone from Intel
would run with debugging it, they have a big enough team that I don't
feel I can expend the personal time to look into it.
Yeah,
#part sign=pgpmime
On Fri, 16 Mar 2012 16:24:35 -0700, Linus Torvalds
torva...@linux-foundation.org wrote:
Well, even without hibernation, one theory was about the VC switching
- apparently that was one thing that at least one reporter does end up
doing - switching from X into the virtual
<#part sign=pgpmime>
On Thu, 15 Mar 2012 00:35:46 +0100, Carsten Emde wrote:
> This patch adds a module parameter to invert the backlight brightness
> value before writing and after reading which makes the affected notebook
> usable again.
You should add a quirk for this and set things up so
Jesse sent me a couple of trivial sprite plane fixes.
The following changes since commit 91982b58d35720b75b894c60e1e3133daa455b53:
drm/gma500: Fix Cedarview boot failures in 3.3-rc (2012-03-05 14:08:31 +)
are available in the git repository at:
Jesse sent me a couple of trivial sprite plane fixes.
The following changes since commit 91982b58d35720b75b894c60e1e3133daa455b53:
drm/gma500: Fix Cedarview boot failures in 3.3-rc (2012-03-05 14:08:31 +)
are available in the git repository at:
#part sign=pgpmime
On Thu, 15 Mar 2012 00:35:46 +0100, Carsten Emde c.e...@osadl.org wrote:
This patch adds a module parameter to invert the backlight brightness
value before writing and after reading which makes the affected notebook
usable again.
You should add a quirk for this and set
<#part sign=pgpmime>
On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds wrote:
> On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie wrote:
> >
> > ?git://people.freedesktop.org/~airlied/linux drm-fixes
>
> Hmm. Is freedesktop.org having trouble?
ECC memory errors -- we're moving this stuff to a new
#part sign=pgpmime
On Mon, 5 Mar 2012 14:09:13 -0800, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Mar 5, 2012 at 10:57 AM, Dave Airlie airl...@linux.ie wrote:
git://people.freedesktop.org/~airlied/linux drm-fixes
Hmm. Is freedesktop.org having trouble?
ECC memory errors
<#part sign=pgpmime>
On Wed, 22 Feb 2012 17:29:59 +0100, Daniel Vetter wrote:
> Queued for -next (with Adam's Acked-by from irc added), thanks for the
> patch.
Should these be pulled into -fixes?
--
keith.packard at intel.com
<#part sign=pgpmime>
On Tue, 21 Feb 2012 14:06:23 -0800, Jesse Barnes
wrote:
> Eugeni Dodonov (4):
> drm/i915: gen7: implement rczunit workaround
> drm/i915: gen7: Implement an L3 caching workaround.
> drm/i915: gen7: work around a system hang on IVB
> drm/i915: do not
#part sign=pgpmime
On Wed, 22 Feb 2012 17:29:59 +0100, Daniel Vetter dan...@ffwll.ch wrote:
Queued for -next (with Adam's Acked-by from irc added), thanks for the
patch.
Should these be pulled into -fixes?
--
keith.pack...@intel.com
___
dri-devel
#part sign=pgpmime
On Tue, 21 Feb 2012 14:06:23 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Eugeni Dodonov (4):
drm/i915: gen7: implement rczunit workaround
drm/i915: gen7: Implement an L3 caching workaround.
drm/i915: gen7: work around a system hang on IVB
#part sign=pgpmime
On Fri, 17 Feb 2012 00:25:51 +0100, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
*** Synchronous pipeline changes ***
Goal: Create an API to apply complex changes to a video pipeline atomically.
Needed for complex camera use cases. On the DRM/KMS side,
<#part sign=pgpmime>
On Fri, 17 Feb 2012 00:25:51 +0100, Laurent Pinchart wrote:
> *** Synchronous pipeline changes ***
>
> Goal: Create an API to apply complex changes to a video pipeline atomically.
>
> Needed for complex camera use cases. On the DRM/KMS side, the approach is to
> use
/i915: no lvds quirk for AOpen MP45
Keith Packard (2):
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drivers/gpu/drm/i915/intel_display.c |8 +---
drivers/gpu/drm/i915/intel_dp.c
/i915: no lvds quirk for AOpen MP45
Keith Packard (2):
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drivers/gpu/drm/i915/intel_display.c |8 +---
drivers/gpu/drm/i915/intel_dp.c
On Mon, 6 Feb 2012 12:12:16 +, Dave Airlie wrote:
> Please get this into -fixes and too me asap.
It's in -fixes; will be on its way to you soon.
This patch is sufficient to make machines work again; the second patch
serves to improve things a bit, and (as such) should probably wait in
On Mon, 6 Feb 2012 12:12:16 +, Dave Airlie airl...@gmail.com wrote:
Please get this into -fixes and too me asap.
It's in -fixes; will be on its way to you soon.
This patch is sufficient to make machines work again; the second patch
serves to improve things a bit, and (as such) should
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
paragraph 6.6.
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW,
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare jdelv...@suse.de wrote:
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare jdelv...@suse.de wrote:
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
On Wed, 25 Jan 2012 23:11:00 +0100, Daniel Vetter wrote:
> I'm a bit unhappy how generic code in intel_display.c calls function out
> of intel_dp.c. And choose_pipe_bpp_dither already has special cases for
> quite a few other encoders ... Could we add an ->adjust_bpc function to
> intel_encoder
On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter wrote:
> I think we could compute this in crtc->mode_fixup (crtc->prepare doesn't
> have the mode and adjusted_mode arguments). We could then store the
> computed bpc and dithering in one of the private fields. We'd still have
> to loop over all
On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes
wrote:
> Yeah, looks like I got this wrong when I added the pipe bpp field.
> Wonder if there's a good way to catch this sort of bug with an assert
> so we don't get the order mixed up again...
Ideally, we'd figure out a way to compute this only
3rd pipe
Jesse Barnes (2):
drm/i915: mask transcoder select bits before setting them on LVDS
drm/i915: sprite init failure on pre-SNB is not a failure
Joel Sass (1):
drm/i915: Add Clientron E830 to the ignore LVDS list
Keith Packard (5):
Merge branch 'drm-intel-next-fixes
to compute this only once, but storing the value
between those two calls would be a pain.
Cc: Lubos Kolouch
Cc: Adam Jackson
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 27 +---
drivers/gpu/drm/i915/intel_dp.c | 77
igned-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index db3b461..94f860c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/driver
Here's a couple of patches that fix some bpc (bits per component)
computation issues with DisplayPort. The problem was that the
DisplayPort code tried to figure out the 'current' bpc by looking at
the bpp stored in an associated crtc, but that was never right (as
described in the message for the
a...@redhat.com
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index db3b461..94f860c 100644
to compute this only once, but storing the value
between those two calls would be a pain.
Cc: Lubos Kolouch lubos.kolo...@gmail.com
Cc: Adam Jackson a...@redhat.com
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 27 +---
drivers/gpu/drm/i915
Here's a couple of patches that fix some bpc (bits per component)
computation issues with DisplayPort. The problem was that the
DisplayPort code tried to figure out the 'current' bpc by looking at
the bpp stored in an associated crtc, but that was never right (as
described in the message for the
: handle 3rd pipe
Jesse Barnes (2):
drm/i915: mask transcoder select bits before setting them on LVDS
drm/i915: sprite init failure on pre-SNB is not a failure
Joel Sass (1):
drm/i915: Add Clientron E830 to the ignore LVDS list
Keith Packard (5):
Merge branch 'drm-intel-next
On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yeah, looks like I got this wrong when I added the pipe bpp field.
Wonder if there's a good way to catch this sort of bug with an assert
so we don't get the order mixed up again...
Ideally, we'd figure out a way
On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter dan...@ffwll.ch wrote:
I think we could compute this in crtc-mode_fixup (crtc-prepare doesn't
have the mode and adjusted_mode arguments). We could then store the
computed bpc and dithering in one of the private fields. We'd still have
to loop
On Wed, 25 Jan 2012 23:11:00 +0100, Daniel Vetter dan...@ffwll.ch wrote:
I'm a bit unhappy how generic code in intel_display.c calls function out
of intel_dp.c. And choose_pipe_bpp_dither already has special cases for
quite a few other encoders ... Could we add an -adjust_bpc function to
On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers wrote:
> Dell U3011 monitor turns to power saving mode when resolution set to 2560 x
> 1600
> (intermittent)
>
> Reproduced with:
> Linux 2.6.38-1-amd64 (Debian kernel)
> Linux 3.1.0-1-amd64 (Debian kernel)
> Linux 3.2.0-1-amd64 (Debian
On Sat, 21 Jan 2012 13:56:21 -0500, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
Dell U3011 monitor turns to power saving mode when resolution set to 2560 x
1600
(intermittent)
Reproduced with:
Linux 2.6.38-1-amd64 (Debian kernel)
Linux 3.1.0-1-amd64 (Debian kernel)
Linux
On Tue, 25 Oct 2011 15:42:21 -0700, St?phane Marchesin wrote:
> From: Duncan Laurie
>
> This is the method used to override LVDS in intel_lvds and appears to be
> an effective way to ensure that the driver does not enable VGA hotplug.
>
> This is the same patch from 2.6.32 kernel in R12 but
On Tue, 25 Oct 2011 15:42:21 -0700, Stéphane Marchesin marc...@chromium.org
wrote:
From: Duncan Laurie dlau...@chromium.org
This is the method used to override LVDS in intel_lvds and appears to be
an effective way to ensure that the driver does not enable VGA hotplug.
This is the same
and IVB video sprite support v6
drm/i915: track sprite coverage and disable primary plane if possible
drm/i915: add color key support v4
drm/i915: don't disable a PCH DPLL that's in use
drm/i915: only set the intel_crtc DPMS mode to on if the mode set
succeeded
Keith Packard (1
and IVB video sprite support v6
drm/i915: track sprite coverage and disable primary plane if possible
drm/i915: add color key support v4
drm/i915: don't disable a PCH DPLL that's in use
drm/i915: only set the intel_crtc DPMS mode to on if the mode set
succeeded
Keith Packard (1
, and my system runs wonderfully.
> The system is a Z68 Pro board with Sandybridge i5-2500K processor, 8
> GB of RAM and UEFI firmware.
Reported-by: Kai Krakow
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 files changed, 3 insertions(+), 5 del
duce it fairly easily with something
> as simple as:
>
> while true; do dmesg; done
This patch turns them off on SNB while leaving them on for IVB.
Reported-by: Udo Steinberg
Cc: Daniel Vetter
Cc: Eugeni Dodonov
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem_exe
This leaves them enabled on IVB, but disables them on SNB as we've
discovered (yet again) that there are hardware combinations that
simply cannot run with them.
[PATCH 1/2] drm/i915: Disable semaphores by default on SNB
[PATCH 2/2] drm/i915: Disable RC6 on Sandybridge by default
--
This leaves them enabled on IVB, but disables them on SNB as we've
discovered (yet again) that there are hardware combinations that
simply cannot run with them.
[PATCH 1/2] drm/i915: Disable semaphores by default on SNB
[PATCH 2/2] drm/i915: Disable RC6 on Sandybridge by default
--
with something
as simple as:
while true; do dmesg; done
This patch turns them off on SNB while leaving them on for IVB.
Reported-by: Udo Steinberg u...@hypervisor.org
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Eugeni Dodonov eug...@dodonov.net
Signed-off-by: Keith Packard kei...@keithp.com
wonderfully.
The system is a Z68 Pro board with Sandybridge i5-2500K processor, 8
GB of RAM and UEFI firmware.
Reported-by: Kai Krakow hurikha...@gmail.com
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 files changed, 3 insertions(+), 5
On Fri, 23 Dec 2011 13:33:07 -0800, Keith Packard wrote:
> /* Enable semaphores on SNB when IO remapping is off */
Yeah, the comment is wrong now. I've updated this too:
- /* Enable semaphores on SNB when IO remapping is off */
+ /* Enable semaphores on
duce it fairly easily with something
> as simple as:
>
> while true; do dmesg; done
This patch turns them off on SNB while leaving them on for IVB.
Reported-by: Udo Steinberg
Cc: Daniel Vetter
Cc: Eugeni Dodonov
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem_e
It would also be nice to know if disabling VT-d in the BIOS resolves
this issue, or if building the kernel with IOMMU support and then
forcibly disabling it with 'intel_iommu=off' fixes the problem. Given
that you can easily reproduce this, it would be good to know how your
machine differs from
On Fri, 23 Dec 2011 09:55:34 -0200, Eugeni Dodonov
wrote:
> Could we revert it for SNB, and leave it enabled for IVB?
Yes, that's my plan. I don't want to ever disable it for IVB.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
On Fri, 23 Dec 2011 09:55:34 -0200, Eugeni Dodonov eug...@dodonov.net wrote:
Could we revert it for SNB, and leave it enabled for IVB?
Yes, that's my plan. I don't want to ever disable it for IVB.
--
keith.pack...@intel.com
pgp3KWP9zdE36.pgp
Description: PGP signature
It would also be nice to know if disabling VT-d in the BIOS resolves
this issue, or if building the kernel with IOMMU support and then
forcibly disabling it with 'intel_iommu=off' fixes the problem. Given
that you can easily reproduce this, it would be good to know how your
machine differs from
with something
as simple as:
while true; do dmesg; done
This patch turns them off on SNB while leaving them on for IVB.
Reported-by: Udo Steinberg u...@hypervisor.org
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Eugeni Dodonov eug...@dodonov.net
Signed-off-by: Keith Packard kei...@keithp.com
On Fri, 23 Dec 2011 13:33:07 -0800, Keith Packard kei...@keithp.com wrote:
/* Enable semaphores on SNB when IO remapping is off */
Yeah, the comment is wrong now. I've updated this too:
- /* Enable semaphores on SNB when IO remapping is off */
+ /* Enable semaphores on SNB
On Thu, 22 Dec 2011 01:45:20 +0100, Udo Steinberg wrote:
> I quick google search suggests that at least some of them are too old to
> support SNA.
Sounds good. If you can capture the error as Daniel suggests, that would
be great. In any case, I'll post a revert of the semaphore enable patch
as
On Thu, 22 Dec 2011 01:45:20 +0100, Udo Steinberg u...@hypervisor.org wrote:
I quick google search suggests that at least some of them are too old to
support SNA.
Sounds good. If you can capture the error as Daniel suggests, that would
be great. In any case, I'll post a revert of the semaphore
On Wed, 21 Dec 2011 22:26:26 +0100, Udo Steinberg wrote:
> That makes the problem go away. If you need more help tracking down the
> problem, then let me know. I can reproduce it fairly easily with something
> as simple as:
>
> while true; do dmesg; done
Are you using SNA?
--
On Wed, 21 Dec 2011 19:54:10 +0100, Udo Steinberg wrote:
> Hi,
>
> With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
> text scroll in an xterm, such as when extracting a tar archive. Such as this
> one (note the timestamps):
Can you try with semaphores disabled?
On Wed, 21 Dec 2011 19:54:10 +0100, Udo Steinberg u...@hypervisor.org wrote:
Hi,
With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of
text scroll in an xterm, such as when extracting a tar archive. Such as this
one (note the timestamps):
Can you try with semaphores
at lists.freedesktop.org
Cc: Daniel Vetter
Reported-by: Alex Villac??s Lasso
Reported-by: Dirk Hohndel
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915
On Tue, 13 Dec 2011 19:26:50 +0100, Daniel Vetter wrote:
> On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
> > On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso > palosanto.com> wrote:
> >
> > > By using a bootable USB stick, I could check the
for chipset power
iommu: Export intel_iommu_enabled to signal when iommu is in use
drm/i915: enable semaphores on per-device defaults
Jesse Barnes (1):
drm/i915: don't set unpin_work if vblank_get fails
Keith Packard (4):
drm/i915: add multi-threaded forcewake support
drm
for chipset power
iommu: Export intel_iommu_enabled to signal when iommu is in use
drm/i915: enable semaphores on per-device defaults
Jesse Barnes (1):
drm/i915: don't set unpin_work if vblank_get fails
Keith Packard (4):
drm/i915: add multi-threaded forcewake support
drm
On Tue, 13 Dec 2011 19:26:50 +0100, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Dec 13, 2011 at 10:14:46AM -0800, Keith Packard wrote:
On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
By using a bootable USB stick, I could check the logs, which
@lists.freedesktop.org
Cc: Daniel Vetter dan...@ffwll.ch
Reported-by: Alex Villacís Lasso a_villa...@palosanto.com
Reported-by: Dirk Hohndel d...@hohndel.org
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_gem.c |7 +--
1 files changed, 1 insertions(+), 6 deletions
On Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter
wrote:
> Hi Keith,
>
> I've noticed that you merged my patch "rm/i915: properly prefault for
> pread/pwrite" into your -fixes branch (which I assume is headed for
> 3.2). Please remove that from your queue again for the following
> reasons:
On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villac??s Lasso wrote:
> By using a bootable USB stick, I could check the logs, which
> showed many segfaults at /lib64/ld-2.14.90.so .
Ouch!
Please let me know if you find anything further; I'd like to get a
revert sent upstream in the next day or so.
On Tue, 13 Dec 2011 10:14:15 -0500, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
By using a bootable USB stick, I could check the logs, which
showed many segfaults at /lib64/ld-2.14.90.so .
Ouch!
Please let me know if you find anything further; I'd like to get a
revert sent upstream
On Wed, 14 Dec 2011 00:04:26 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Hi Keith,
I've noticed that you merged my patch rm/i915: properly prefault for
pread/pwrite into your -fixes branch (which I assume is headed for
3.2). Please remove that from your queue again for the following
On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villac??s Lasso wrote:
> Ran kernel with reverted patch for 6 hours without issues so far. Will
> keep testing after work (issue happens with my home machine).
Thanks much. Let me know if it's still stable this evening; I can send a
revert along if you
On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
Ran kernel with reverted patch for 6 hours without issues so far. Will
keep testing after work (issue happens with my home machine).
Thanks much. Let me know if it's still stable this evening; I can send
On Sun, 11 Dec 2011 13:36:30 -0500, Alex Villac?s Lasso wrote:
> My system is a Fedora 16 x86_64 running self-compiled vanilla kernel
> (.config attached for -rc5). I am getting an apparent memory corruption
> that starts since linux 3.2-rc5. No such corruption was noticed in
> 3.2-rc4. On the
On Sun, 11 Dec 2011 13:36:30 -0500, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
My system is a Fedora 16 x86_64 running self-compiled vanilla kernel
(.config attached for -rc5). I am getting an apparent memory corruption
that starts since linux 3.2-rc5. No such corruption was noticed
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. RC6 never works on Ironlake. Make the default
value for the parameter follow these guidelines. Setting the value
to either 0 or 1 will force the specified behavior.
Signed-off-by: Keith Packard
Reviewed
401 - 500 of 1027 matches
Mail list logo
