[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung

> > > On Tue, Oct 23, 2012 at 10:06:52AM -0700, Justin P. Mattock wrote: > > This is happening both with MAINLINE and NEXT. > > > > basically system is running fine, then under load system becomes > > really sluggish and unresponsive. I was able to get dmesg of the > > error..: > > > > [

new error message: drm:__gen6_gt_force_wake_get

On Wed, Oct 24, 2012 at 9:23 PM, Toralf F?rster wrote: > Since 21th of October (since 3.6.2) I'm getting that error sometimes > at my ThinkPad T420 with an integrated intel i915 graphic - wasn't > aware of it before. > > It is safe to ignore it ? If it happens at boot-up and after resume, yes.

new error message: drm:__gen6_gt_force_wake_get

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since 21th of October (since 3.6.2) I'm getting that error sometimes at my ThinkPad T420 with an integrated intel i915 graphic - wasn't aware of it before. It is safe to ignore it ? - -- MfG/Sincerely Toralf F?rster pgp finger print: 7B1A 07F4 EC82

[PATCH] drm: kms_helper: don't lose hotplug event

There's a race window (small for hpd, 10s large for polled outputs) where userspace could sneak in with an unrelated connnector probe ioctl call and eat the hotplug event (since neither the hpd nor the poll code see a state change). To avoid this, check whether the connector state changes in all

[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. It is done to give X

[PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.

The Radeon driver uses the analog/digital flag to determine if the DAC or the TMDS encoder should be enabled on a DVI-I connector. If the EDID is bogus this flag is no longer reliable. This fix adds a fallback to DAC load detection to determine if anything is connected to the DAC. If not and a

[PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.

For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value works better on ES1000 (RV100) chips, too, as it doesn't produce any false positives on any cards I have tested. Therefore let's assume that this value is good for all RV100 and RV200 chipset generations. Signed-off-by: Egbert

[PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.

An uninitialized variable led to broken load detection. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c

[PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.

TV DAC load detection did not take into account that there are chips with a single CRTC when attempted to enable the 2nd CRTC. This fix adds support for single CRTC chips and cleans up handling of different chipset generations. Signed-off-by: Egbert Eich ---

[PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2

On 23.10.2012 18:45, Klaus Schnass wrote: >> /** >> + * radeon_check_pot_argument - check that argument is a power of two >> + * >> + * @arg: value to check >> + * >> + * Validates that a certain argument is a power of two (all asics). >> + * Returns true if argument is valid. >> + */ >> +static

[PATCH] drm/radeon: fix and simplify pot argument checks v3

GART and VRAM size limits need to be a power of two. Fix values greater than 1GB and simplify those checks a bit. v2: also fix radeon_vram_limit usage, and simplify test even more. v3: fix typo in function name Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_device.c | 60

[Bug 40211] texture probleme in wolfenstein enemy territory rv770

|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/06b144b2/attachment.html>

[Bug 40211] texture probleme in wolfenstein enemy territory rv770

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/cfd97535/attachment.html>

[PATCH] drivers/gpu/drm/radeon/evergreen_cs.c: Remove unnecessary semicolon

A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @r1@ statement S; position p,p1; @@ S at p1;@p @script:python r2@ p << r1.p; p1 << r1.p1; @@ if p[0].line != p1[0].line_end: cocci.include_match(False) @@ position r1.p; @@

[Bug 27708] [KMS] Repeated EDID errors despite everything working

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/8eaa632c/attachment.html>

[PATCH] drm: don't unnecessarily enable the polling work

... by properly checking connector->polled. This doesn't matter too much because the polling work itself gets this slightly more right and doesn't set repoll if there's nothing to do. But we can do better. v2: Chris Wilson noticed that I broke polling, since repoll will never ever be set true.

[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected

On 10/24/2012 01:14 PM, Arend van Spriel wrote: > On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote: >> I have this lockdep warning on wireless-testing tree based >> on 3.7-rc1 (no other patches except wireless bits). >> >> = >> Restarting tasks ... done.

[PATCH 2/2] drm: add support for monotonic vblank timestamps

On Wed, 2012-10-24 at 10:08 +0200, Michel D?nzer wrote: > On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: > > Jumps in the vblank and page flip event timestamps cause trouble for > > clients, so we should avoid them. The timestamp we get currently with > > gettimeofday can jump, so use

[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected

On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote: > I have this lockdep warning on wireless-testing tree based > on 3.7-rc1 (no other patches except wireless bits). > > = > Restarting tasks ... done. > [ INFO: possible recursive locking detected ] >

[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich wrote: > The Radeon driver reduces the framebuffer resolution to 8bpp if > a device with less than 32 Mb VRAM is found. This causes the > framebuffer to run in 8 bit paletted mode. For a text console this > is not an issue as 256 different colors is

[PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.

On Wed, Oct 24, 2012 at 12:32 PM, Egbert Eich wrote: > The Radeon driver uses the analog/digital flag to determine if the > DAC or the TMDS encoder should be enabled on a DVI-I connector. > If the EDID is bogus this flag is no longer reliable. This fix > adds a fallback to DAC load detection to

[PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.

On Wed, Oct 24, 2012 at 12:31 PM, Egbert Eich wrote: > For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value > works better on ES1000 (RV100) chips, too, as it doesn't produce any false > positives on any cards I have tested. Therefore let's assume that this > value is good for

[PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.

On Wed, Oct 24, 2012 at 12:29 PM, Egbert Eich wrote: > An uninitialized variable led to broken load detection. Looks good. Added to by -fixes queue. Thanks! Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + > 1 files changed, 1

[PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.

On Wed, Oct 24, 2012 at 12:28 PM, Egbert Eich wrote: > TV DAC load detection did not take into account that there are > chips with a single CRTC when attempted to enable the 2nd CRTC. > This fix adds support for single CRTC chips and cleans up handling > of different chipset generations. I don't

[pull] radeon drm-fixes-3.7

From: Alex Deucher Hi Dave, Fixes pull request for radeon. The main things here are fixing a ATPX regression from the acpi rework, fixing some fallout from the async VM work, and fixing some module options that were broken in certain cases. Other than that, mainly

[PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2

On Wed, Oct 24, 2012 at 11:31 AM, Christian K?nig wrote: > On 23.10.2012 18:45, Klaus Schnass wrote: >>> >>> /** >>> + * radeon_check_pot_argument - check that argument is a power of two >>> + * >>> + * @arg: value to check >>> + * >>> + * Validates that a certain argument is a power of two (all

[PATCH] drm/radeon: fix ATPX regression in acpi rework

On Tue, Oct 23, 2012 at 5:59 PM, wrote: > From: Alex Deucher > > Copy and paste typo in the apci rework. > > Fixes: > https://bugzilla.kernel.org/show_bug.cgi?id=49351 > > Signed-off-by: Alex Deucher Reviewed-by: Jerome Glisse > --- > drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-

[PATCH -fixes 0/2] TTM Race fixes

On Mon, Oct 22, 2012 at 02:51:24PM +0200, Thomas Hellstrom wrote: > A couple of fixes for theoretical races discovered during the lockdep > discussions with Maarten Lankhorst > For the serie Reviewed-by: Jerome Glisse

[PATCH 2/2] drm: add support for monotonic vblank timestamps

On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: > Jumps in the vblank and page flip event timestamps cause trouble for > clients, so we should avoid them. The timestamp we get currently with > gettimeofday can jump, so use instead monotonic timestamps. > > For backward compatibility use a

drm i915 hangs on heavy io load

Hi Dave, hi Chris, thanks for your answers. On Di, 23 Okt 2012, Dave Airlie wrote: > Does booting with i915.i915_enable_rc6=0 help? No,booted with that, it happened again on a completely idle system (well, I believe completely idle, I was doing the dishes ;-) [12437.995026]

drm i915 hangs on heavy io load

On Wed, 24 Oct 2012 09:36:59 +0900, Norbert Preining wrote: > Hi Dave, hi Chris, > > thanks for your answers. > > On Di, 23 Okt 2012, Dave Airlie wrote: > > Does booting with i915.i915_enable_rc6=0 help? > > No,booted with that, it happened again on a completely idle > system (well, I believe

[PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2

/** + * radeon_check_pot_argument - check that argument is a power of two + * + * @arg: value to check + * + * Validates that a certain argument is a power of two (all asics). + * Returns true if argument is valid. + */ +static bool radeon_ckeck_pot_argument(int arg) +{ + return (arg (arg

Re: [PATCH 2/2] drm: add support for monotonic vblank timestamps

On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: Jumps in the vblank and page flip event timestamps cause trouble for clients, so we should avoid them. The timestamp we get currently with gettimeofday can jump, so use instead monotonic timestamps. For backward compatibility use a module

Re: [PATCH 2/2] drm: add support for monotonic vblank timestamps

On Wed, 2012-10-24 at 10:08 +0200, Michel Dänzer wrote: On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: Jumps in the vblank and page flip event timestamps cause trouble for clients, so we should avoid them. The timestamp we get currently with gettimeofday can jump, so use instead

Re: [PATCH -fixes 0/2] TTM Race fixes

On Mon, Oct 22, 2012 at 02:51:24PM +0200, Thomas Hellstrom wrote: A couple of fixes for theoretical races discovered during the lockdep discussions with Maarten Lankhorst For the serie Reviewed-by: Jerome Glisse jgli...@redhat.com ___ dri-devel

[PATCH] drm: don't unnecessarily enable the polling work

... by properly checking connector-polled. This doesn't matter too much because the polling work itself gets this slightly more right and doesn't set repoll if there's nothing to do. But we can do better. v2: Chris Wilson noticed that I broke polling, since repoll will never ever be set true. Fix

[PATCH] drm/radeon: fix and simplify pot argument checks v3

GART and VRAM size limits need to be a power of two. Fix values greater than 1GB and simplify those checks a bit. v2: also fix radeon_vram_limit usage, and simplify test even more. v3: fix typo in function name Signed-off-by: Christian König deathsim...@vodafone.de ---

Re: [PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2

On 23.10.2012 18:45, Klaus Schnass wrote: /** + * radeon_check_pot_argument - check that argument is a power of two + * + * @arg: value to check + * + * Validates that a certain argument is a power of two (all asics). + * Returns true if argument is valid. + */ +static bool

Re: [PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2

On Wed, Oct 24, 2012 at 11:31 AM, Christian König deathsim...@vodafone.de wrote: On 23.10.2012 18:45, Klaus Schnass wrote: /** + * radeon_check_pot_argument - check that argument is a power of two + * + * @arg: value to check + * + * Validates that a certain argument is a power of two (all

[pull] radeon drm-fixes-3.7

From: Alex Deucher alexander.deuc...@amd.com Hi Dave, Fixes pull request for radeon. The main things here are fixing a ATPX regression from the acpi rework, fixing some fallout from the async VM work, and fixing some module options that were broken in certain cases. Other than that, mainly

[PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.

TV DAC load detection did not take into account that there are chips with a single CRTC when attempted to enable the 2nd CRTC. This fix adds support for single CRTC chips and cleans up handling of different chipset generations. Signed-off-by: Egbert Eich e...@suse.de ---

[PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.

An uninitialized variable led to broken load detection. Signed-off-by: Egbert Eich e...@suse.de --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c

[PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.

For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value works better on ES1000 (RV100) chips, too, as it doesn't produce any false positives on any cards I have tested. Therefore let's assume that this value is good for all RV100 and RV200 chipset generations. Signed-off-by: Egbert

[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. It is done to give X

[Bug 27708] [KMS] Repeated EDID errors despite everything working

https://bugs.freedesktop.org/show_bug.cgi?id=27708 Lauri Kasanen cur...@operamail.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.

On Wed, Oct 24, 2012 at 12:28 PM, Egbert Eich e...@suse.de wrote: TV DAC load detection did not take into account that there are chips with a single CRTC when attempted to enable the 2nd CRTC. This fix adds support for single CRTC chips and cleans up handling of different chipset generations.

Re: [PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.

On Wed, Oct 24, 2012 at 12:29 PM, Egbert Eich e...@suse.de wrote: An uninitialized variable led to broken load detection. Looks good. Added to by -fixes queue. Thanks! Alex Signed-off-by: Egbert Eich e...@suse.de --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + 1 files

Re: [PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.

On Wed, Oct 24, 2012 at 12:31 PM, Egbert Eich e...@suse.de wrote: For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value works better on ES1000 (RV100) chips, too, as it doesn't produce any false positives on any cards I have tested. Therefore let's assume that this value is

Re: [PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.

On Wed, Oct 24, 2012 at 12:32 PM, Egbert Eich e...@suse.de wrote: The Radeon driver uses the analog/digital flag to determine if the DAC or the TMDS encoder should be enabled on a DVI-I connector. If the EDID is bogus this flag is no longer reliable. This fix adds a fallback to DAC load

Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich e...@suse.de wrote: The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different

new error message: drm:__gen6_gt_force_wake_get

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since 21th of October (since 3.6.2) I'm getting that error sometimes at my ThinkPad T420 with an integrated intel i915 graphic - wasn't aware of it before. It is safe to ignore it ? - -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82

Re: new error message: drm:__gen6_gt_force_wake_get

On Wed, Oct 24, 2012 at 9:23 PM, Toralf Förster toralf.foers...@gmx.de wrote: Since 21th of October (since 3.6.2) I'm getting that error sometimes at my ThinkPad T420 with an integrated intel i915 graphic - wasn't aware of it before. It is safe to ignore it ? If it happens at boot-up and

Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.

On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich e...@suse.de wrote: The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb VRAM is found. This causes the framebuffer to run in 8 bit

Re: [PATCH 1/2] drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos

On 23.10.12 20:53, Imre Deak wrote: For measuring duration we want to avoid that our start/end timestamps jump, so use monotonic instead of real time for that. Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/drm_irq.c | 18 -- 1 file changed, 12