>
>
> 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..:
> >
> > [ 774
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. I
-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
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 o
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 m
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 (bog
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 E
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
b/drivers/gpu/drm/radeon/radeon_legacy_
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
---
drivers/gpu/drm/radeon/radeon_legacy_
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 bo
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 +++
|--- |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>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/cfd97535/attachment.html>
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;
@@
-
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/8eaa632c/attachment.html>
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
---
drivers/gpu/drm/drm_irq.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
... 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
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.
>
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
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 ]
> 3.7.0-
On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher wrote:
> 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 c
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 mo
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 de
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 all
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 insertions(
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
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. If
-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
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 o
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
just bug fixes.
The followin
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 a
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 +-
>
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
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 mod
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 mo
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 de
https://bugs.freedesktop.org/show_bug.cgi?id=40211
Andreas Boll changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=40211
--- Comment #15 from pitam...@free.fr ---
Sorry for the late reply, I was off last week.
after settings LIBGL_DEBUG=verbose
it appears I had in my environment a
LIBGL_DRIVERS_PATH=/opt/mesa/ pointing
on an old build of mesa tree.
Enemy Territory
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 all
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 insertions(
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
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_hangcheck_
https://bugs.freedesktop.org/show_bug.cgi?id=27708
Lauri Kasanen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 m
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 (bog
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 E
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
b/drivers/gpu/drm/radeon/radeon_legacy_
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
---
drivers/gpu/drm/radeon/radeon_legacy_
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
just bug fixes.
The followin
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
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 a
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 radeon_ckeck_pot_argum
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 +++
... 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
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
___
dri-devel mailing list
dri-dev
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 +-
>
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
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 c
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 mod
59 matches
Mail list logo
