On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom wrote:
In any case, I'm not saying fences is the best way to flush but since the bo
code assumes that signaling a sync object means "make the buffer contents
available for CPU read / write", it's usu
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Olšák wrote:
+enum ttm_buffer_usage {
+TTM_USAGE_READ = 1,
+TTM_USAGE_WRITE = 2,
+TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
+};
Please don't use enums for bit operations.
#define TTM_USAGE_FLAG_
Two fixes on top of previous patches.
The first removes a DOS vulnerabilty.
The second one implements some screen object fixes.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Contexts, surfaces and streams allocate persistent kernel memory as the
direct result of user-space requests. Make sure this memory is
accounted as graphics memory, to avoid DOS vulnerabilities.
Also take the TTM read lock around resource creation to block
switched-out dri clients from allocating
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 272 +++
1 files changed, 215 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Olšák wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Olšák wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
>> On 10/07/2011 12:42 AM, Marek Olšák wrote:
>>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
In any case, I'm not saying fences is the best way to flu
On 10/07/2011 03:24 PM, Alex Deucher wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
wrote:
In any case, I'm not saying fences is the best way to flush but since the
On 10/07/2011 03:38 PM, Jerome Glisse wrote:
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
On 10/07/2011 12:42 AM, Marek Olšák wrote:
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
wrote:
In any case, I'm not saying fences is the best way to flush but since th
On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom wrote:
> On 10/07/2011 03:24 PM, Alex Deucher wrote:
>>
>> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
>> wrote:
>>
>>>
>>> On 10/07/2011 12:42 AM, Marek Olšák wrote:
>>>
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Summary: Hotplug detect does not work for HDMI monitor on
Fusion E-350 board
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Simon Farnsworth changed:
What|Removed |Added
Summary|Hotplug detect does not |[r600 KMS] Hotplug detect
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #1 from Alex Deucher 2011-10-07 08:59:22 PDT ---
If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting
scheduled. From there drm_helper_hpd_irq_event() gets called which actually
generates the uevent.
--
C
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #2 from Simon Farnsworth 2011-10-07
09:07:40 PDT ---
drm_helper_hpd_irq_event() isn't generating uevents, because connector->status
is not being updated somewhere, and is remaining at connector_status_connected,
when it should be bei
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #3 from Simon Farnsworth 2011-10-07
09:26:08 PDT ---
So, I think I see the proximate cause of the bug, but not the reason for it:
In radeon_dvi_detect at radeon_connectors.c:962, I see:
if (!force) {
ret = connector->st
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #4 from Alex Deucher 2011-10-07 10:35:06 PDT ---
Created an attachment (id=52093)
View: https://bugs.freedesktop.org/attachment.cgi?id=52093
Review: https://bugs.freedesktop.org/review?bug=41561&attachment=52093
1/2: fix the digita
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #5 from Alex Deucher 2011-10-07 10:35:43 PDT ---
Created an attachment (id=52094)
View: https://bugs.freedesktop.org/attachment.cgi?id=52094
Review: https://bugs.freedesktop.org/review?bug=41561&attachment=52094
2/2: fix the mixed
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #6 from Simon Farnsworth 2011-10-07
10:53:04 PDT ---
I've applied both patches, and am testing on a machine with DVI-I and
DisplayPort.
Test sequence:
1) Boot system with no outputs connected.
2) Attach a DVI-D monitor, then remove
https://bugs.freedesktop.org/show_bug.cgi?id=40252
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Alex Deucher changed:
What|Removed |Added
CC||q...@gmx.de
--- Comment #7 from Alex Deuc
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #8 from Alex Deucher 2011-10-07 11:16:14 PDT ---
(In reply to comment #6)
> Results:
>
> DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after
> the
> connector has been used for VGA, but I get an event within
From: Alex Deucher
DVI-D and HDMI-A are digital only, so there's no need to
attempt analog load detect. Also, skip bail before the
!force check, or we fail to get a disconnect events.
The next patches in the series attempt to fix disconnect
events for connectors with analog support (DVI-I, HDMI-
From: Alex Deucher
When force == false, we don't do load detection in the connector
detect functions. Unforunately, we also return the previous
connector state so we never get disconnect events for DVI-I, DVI-A,
or VGA. Save whether we detected the monitor via load detection
previously and use
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Summary: [r600 KMS] Asus A35T A4-3400
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Robert Nelson changed:
What|Removed |Added
Summary|[r600 KMS] Asus A35T|[r600 KMS] Asus A53T
|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #1 from Robert Nelson 2011-10-07 11:25:48
PDT ---
Created an attachment (id=52095)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52095)
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #2 from Robert Nelson 2011-10-07 11:26:04
PDT ---
Created an attachment (id=52096)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52096)
Xorg log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52095|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #3 from Robert Nelson 2011-10-07 11:26:21
PDT ---
Created an attachment (id=52097)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52097)
lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52096|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52097|application/octet-stream|text/plain
mime type|
Date: Fri, 16 Sep 2011 20:45:30 +
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
};
Consequently
On Fri, Oct 7, 2011 at 3:42 PM, Jerome Glisse wrote:
> Forget to mention that we would need a new wait_fence ioctl to wait
> for a specific fence seq on a specific ring
We need a wait_fence ioctl anyway and even with a timeout parameter.
It's a mandatory OpenGL feature. r600g uses a loop with sch
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse wrote:
> I should have look at the patch long ago ... anyway i think a better
> approach would be to expose fence id as 64bits unsigned to each
> userspace client. I was thinking of mapping a page readonly (same page
> as the one gpu write back) at som
(Resending with small improvements - also sending to dri-devel for feedback).
This is the the forth iteration of potential fixes for slow edid detection
issues over non-existent outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions
were posted to the bug and were use
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
As
On Fri, Oct 7, 2011 at 10:00 AM, Thomas Hellstrom wrote:
> OK. First I think we need to make a distinction: bo sync objects vs driver
> fences. The bo sync obj api is there to strictly provide functionality that
> the ttm bo subsystem is using, and that follows a simple set of rules:
>
> 1) the bo
This adds a new function intel_drm_get_valid_edid, which is used instead
of drm_get_edid within the i915 driver.
It does a similar check to the one in previous patch, but it is limited to
i915 driver.
The check is similar to the first part of EDID discovery performed by the
drm_do_probe_ddc_edid.
https://bugs.freedesktop.org/show_bug.cgi?id=41579
Summary: R300 Segfaults when using mupen64plus
Product: Mesa
Version: 7.11
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom wrote:
> In any case, I'm not saying fences is the best way to flush but since the bo
> code assumes that signaling a sync object means "make the buffer contents
> available for CPU read / write", it's usually a good way to do it; there's
> even a s
On 10/07/2011 12:42 AM, Marek Ol??k wrote:
> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
> wrote:
>
>> In any case, I'm not saying fences is the best way to flush but since the bo
>> code assumes that signaling a sync object means "make the buffer contents
>> available for CPU read / wri
Oh, and one more style comment below:
On 08/07/2011 10:39 PM, Marek Ol??k wrote:
>
> +enum ttm_buffer_usage {
> +TTM_USAGE_READ = 1,
> +TTM_USAGE_WRITE = 2,
> +TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
> +};
>
>
Please don't use enums for bit operations.
#define TTM_
Two fixes on top of previous patches.
The first removes a DOS vulnerabilty.
The second one implements some screen object fixes.
Contexts, surfaces and streams allocate persistent kernel memory as the
direct result of user-space requests. Make sure this memory is
accounted as graphics memory, to avoid DOS vulnerabilities.
Also take the TTM read lock around resource creation to block
switched-out dri clients from allocating
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 272 +++
1 files changed, 215 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom wrote:
> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> In any case, I'm not saying fences is the best way to flush but since the
>>> bo
>>> code assumes that signaling a sync
On Fri, Oct 7, 2011 at 9:38 AM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> ?wrote:
>>>
In any case, I'm not saying fences is the best way to
On 10/07/2011 03:24 PM, Alex Deucher wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
In any case, I'm not saying fences is the bes
On 10/07/2011 03:38 PM, Jerome Glisse wrote:
> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
> wrote:
>
>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>
>>> On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
>>> wrote:
>>>
>>>
In any case, I'm not saying fences is the be
On Fri, Oct 7, 2011 at 10:05 AM, Thomas Hellstrom
wrote:
> On 10/07/2011 03:24 PM, Alex Deucher wrote:
>>
>> On Fri, Oct 7, 2011 at 4:00 AM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 10/07/2011 12:42 AM, Marek Ol??k wrote:
>>>
On Wed, Oct 5, 2011 at 7:54 AM, Thomas Hellstrom
?wrote
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Summary: Hotplug detect does not work for HDMI monitor on
Fusion E-350 board
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Simon Farnsworth changed:
What|Removed |Added
Summary|Hotplug detect does not |[r600 KMS] Hotplug detect
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #1 from Alex Deucher 2011-10-07 08:59:22 PDT
---
If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting
scheduled. From there drm_helper_hpd_irq_event() gets called which actually
generates the uevent.
--
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #2 from Simon Farnsworth
2011-10-07 09:07:40 PDT ---
drm_helper_hpd_irq_event() isn't generating uevents, because connector->status
is not being updated somewhere, and is remaining at connector_status_connected,
when it should be bei
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #3 from Simon Farnsworth
2011-10-07 09:26:08 PDT ---
So, I think I see the proximate cause of the bug, but not the reason for it:
In radeon_dvi_detect at radeon_connectors.c:962, I see:
if (!force) {
ret = connector->st
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #4 from Alex Deucher 2011-10-07 10:35:06 PDT
---
Created an attachment (id=52093)
View: https://bugs.freedesktop.org/attachment.cgi?id=52093
Review: https://bugs.freedesktop.org/review?bug=41561&attachment=52093
1/2: fix the digit
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #5 from Alex Deucher 2011-10-07 10:35:43 PDT
---
Created an attachment (id=52094)
View: https://bugs.freedesktop.org/attachment.cgi?id=52094
Review: https://bugs.freedesktop.org/review?bug=41561&attachment=52094
2/2: fix the mixed
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #6 from Simon Farnsworth
2011-10-07 10:53:04 PDT ---
I've applied both patches, and am testing on a machine with DVI-I and
DisplayPort.
Test sequence:
1) Boot system with no outputs connected.
2) Attach a DVI-D monitor, then remove
https://bugs.freedesktop.org/show_bug.cgi?id=40252
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41561
Alex Deucher changed:
What|Removed |Added
CC||qjn at gmx.de
--- Comment #7 from Alex De
https://bugs.freedesktop.org/show_bug.cgi?id=41561
--- Comment #8 from Alex Deucher 2011-10-07 11:16:14 PDT
---
(In reply to comment #6)
> Results:
>
> DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after
> the
> connector has been used for VGA, but I get an event within
From: Alex Deucher
DVI-D and HDMI-A are digital only, so there's no need to
attempt analog load detect. Also, skip bail before the
!force check, or we fail to get a disconnect events.
The next patches in the series attempt to fix disconnect
events for connectors with analog support (DVI-I, HDMI-
From: Alex Deucher
When force == false, we don't do load detection in the connector
detect functions. Unforunately, we also return the previous
connector state so we never get disconnect events for DVI-I, DVI-A,
or VGA. Save whether we detected the monitor via load detection
previously and use
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Summary: [r600 KMS] Asus A35T A4-3400
Product: DRI
Version: XOrg CVS
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Robert Nelson changed:
What|Removed |Added
Summary|[r600 KMS] Asus A35T|[r600 KMS] Asus A53T
|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #1 from Robert Nelson 2011-10-07
11:25:48 PDT ---
Created an attachment (id=52095)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52095)
dmesg
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #2 from Robert Nelson 2011-10-07
11:26:04 PDT ---
Created an attachment (id=52096)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52096)
Xorg log
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52095|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #3 from Robert Nelson 2011-10-07
11:26:21 PDT ---
Created an attachment (id=52097)
--> (https://bugs.freedesktop.org/attachment.cgi?id=52097)
lspci
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52096|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Alex Deucher changed:
What|Removed |Added
Attachment #52097|application/octet-stream|text/plain
mime type|
Date: Fri, 16 Sep 2011 20:45:30 +
The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:
struct radeon_debugfs {
struct drm_info_list*files;
unsignednum_files;
};
Consequently
On Fri, Oct 7, 2011 at 3:42 PM, Jerome Glisse wrote:
> Forget to mention that we would need a new wait_fence ioctl to wait
> for a specific fence seq on a specific ring
We need a wait_fence ioctl anyway and even with a timeout parameter.
It's a mandatory OpenGL feature. r600g uses a loop with sch
On Fri, Oct 7, 2011 at 3:38 PM, Jerome Glisse wrote:
> I should have look at the patch long ago ... anyway i think a better
> approach would be to expose fence id as 64bits unsigned to each
> userspace client. I was thinking of mapping a page readonly (same page
> as the one gpu write back) at som
(Resending with small improvements - also sending to dri-devel for feedback).
This is the the forth iteration of potential fixes for slow edid detection
issues over non-existent outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059) - the previous versions
were posted to the bug and were use
This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.
As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.
As
This adds a new function intel_drm_get_valid_edid, which is used instead
of drm_get_edid within the i915 driver.
It does a similar check to the one in previous patch, but it is limited to
i915 driver.
The check is similar to the first part of EDID discovery performed by the
drm_do_probe_ddc_edid.
https://bugs.freedesktop.org/show_bug.cgi?id=41579
Summary: R300 Segfaults when using mupen64plus
Product: Mesa
Version: 7.11
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
80 matches
Mail list logo
