From: Alex Deucher
FB scratch indices are dword indices, but we were treating
them as byte indices. As such, we were getting the wrong
FB scratch data for non-0 indices. Fix the indices and
guard the indexing against indices larger than the scratch
allocation.
Fixes potential memory corruption
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Mike Lothian changed:
What|Removed |Added
Attachment #52496|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Mike Lothian changed:
What|Removed |Added
Attachment #52494|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Mike Lothian changed:
What|Removed |Added
Attachment #52491|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #2 from Mike Lothian 2011-10-18 12:35:38
PDT ---
Created attachment 52493
--> https://bugs.freedesktop.org/attachment.cgi?id=52493
System ACPI Info
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
blem as
needed.
Thanks in advance,
Aani
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111018/f75e5437/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Alex Deucher changed:
What|Removed |Added
Attachment #52491|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #1 from Mike Lothian 2011-10-18 12:19:06
PDT ---
here's my lspci:
0:00.0 Host bridge [0600]: Intel Corporation Device [8086:0104] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:0101] (rev 09)
00:01.1 PCI bridge
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Bug #: 41971
Summary: [kms] Muxless modesetting takes 20 seconds to decide
it can't modeset
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-6
Ignore this. Better patch coming.
Alex
On Tue, Oct 18, 2011 at 3:56 PM, wrote:
> From: Alex Deucher
>
> Check access to the fb scratch array to avoid accessing
> memory past the end of the array.
>
> Signed-off-by: Alex Deucher
> Cc: stable at kernel.org
> ---
> ?drivers/gpu/drm/radeon/atom.
https://bugs.freedesktop.org/show_bug.cgi?id=41744
--- Comment #6 from Vadim 2011-10-18 17:34:26 PDT ---
(In reply to comment #5)
> Thanks. Kernel 3.0 solved the problem.
> Render is still not perfect and speed is bad, but it's wokring :).
> I see odd shading and odd image in dark (ignore tearing
From: Alex Deucher
FB scratch indices are dword indices, but we were treating
them as byte indices. As such, we were getting the wrong
FB scratch data for non-0 indices. Fix the indices and
guard the indexing against indices larger than the scratch
allocation.
Fixes potential memory corruption
; >> > Lots of things... The most common cause is an incorrect command stream
> >> > sent to the GPU by userspace or the kernel.
> >> >
> >> >> Why reset didn't work?
> >> >
> >> > Might be related to 'Wait for MC idle timedout !', but I don't know
> >> > offhand what could be up with that.
> >> >
> >> >
> >> >> BTW, one question:
> >> >> I got 'RADEON_IS_PCI | RADEON_IS_IGP' in rdev->flags, which causes
> >> >> need_dma32 was set.
> >> >> Is it correct? (drivers/char/agp is not available on mips, could that
> >> >> be the reason?)
> >> >
> >> > Not sure, Alex?
> >>
> >> You don't AGP for newer IGP cards (rs4xx+). It gets set by default if
> >> the card is not AGP or PCIE. That should be changed as only the
> >> legacy r1xx PCI GART block has that limitation. I'll send a patch out
> >> shortly.
> >>
> >> Got it, thanks for the reply.
> >
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111018/95b83eaf/attachment.htm>
__
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111018/3001a527/attachment-0001.htm>
On Tue, 2011-10-18 at 09:07 +0300, Dan Carpenter wrote:
> memtimings is a valid pointer here, the intent was to test for
> kcalloc() failure.
I've queued it, thanks!
Ben.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_perf.c
> b/drivers/gpu/drm/nouveau/nouvea
Ignore this. Better patch coming.
Alex
On Tue, Oct 18, 2011 at 3:56 PM, wrote:
> From: Alex Deucher
>
> Check access to the fb scratch array to avoid accessing
> memory past the end of the array.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@kernel.org
> ---
> drivers/gpu/drm/radeon/atom.c |
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #12 from auxsvr at gmail.com 2011-10-18 09:00:54 PDT ---
radeon.agpmode=-1 stops the corruption I was getting after scrolling a PDF file
in okular with a radeon 9600xt. The problem with this solution is that
frequently Xorg freezes for
From: Alex Deucher
Check access to the fb scratch array to avoid accessing
memory past the end of the array.
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/atom.c | 15 +--
drivers/gpu/drm/radeon/atom.h |1 +
2 files changed, 14 insertions(+),
Hi Dave, Eugeni, Alex,
On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
> > 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
Thanks for taking interesting in our driver.
- Original Message -
> Hi,
>
> I 'm trying to test KMS functionality of latest vmwgfx module.
> I tried the code from
> http://permalink.gmane.org/gmane.comp.video.dri.devel/42908
>
> as a simple test case, but all I get is a black screen inste
Thanks for taking interesting in our driver.
- Original Message -
> Hi,
>
> I 'm trying to test KMS functionality of latest vmwgfx module.
> I tried the code from
> http://permalink.gmane.org/gmane.comp.video.dri.devel/42908
>
> as a simple test case, but all I get is a black screen inste
On Tue, Oct 18, 2011 at 09:10 +0300, Dan Carpenter wrote:
> If ret is non-zero then we don't initialize the struct which leaks
> stack information to user space.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Vasiliy Kulikov
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gp
https://bugs.freedesktop.org/show_bug.cgi?id=41744
--- Comment #5 from Ga?per Sedej 2011-10-18 06:14:37 PDT
---
Thanks. Kernel 3.0 solved the problem.
Render is still not perfect and speed is bad, but it's wokring :).
I see odd shading and odd image in dark (ignore tearing, it's only because of
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Mike Lothian changed:
What|Removed |Added
Attachment #52496|0 |1
is obsolete|
From: Alex Deucher
Check access to the fb scratch array to avoid accessing
memory past the end of the array.
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/atom.c | 15 +--
drivers/gpu/drm/radeon/atom.h |1 +
2 files changed, 14 insertions(+), 2
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Mike Lothian changed:
What|Removed |Added
Attachment #52494|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Mike Lothian changed:
What|Removed |Added
Attachment #52491|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #2 from Mike Lothian 2011-10-18 12:35:38 PDT
---
Created attachment 52493
--> https://bugs.freedesktop.org/attachment.cgi?id=52493
System ACPI Info
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Alex Deucher changed:
What|Removed |Added
Attachment #52491|application/octet-stream|text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=41971
--- Comment #1 from Mike Lothian 2011-10-18 12:19:06 PDT
---
here's my lspci:
0:00.0 Host bridge [0600]: Intel Corporation Device [8086:0104] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:0101] (rev 09)
00:01.1 PCI bridge
https://bugs.freedesktop.org/show_bug.cgi?id=41971
Bug #: 41971
Summary: [kms] Muxless modesetting takes 20 seconds to decide
it can't modeset
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86-6
On 10/18/2011 11:14, Jean Delvare wrote:
> Hi Dave, Eugeni, Alex,
>
> On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
>>> 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_bi
Dave Young (hidave.darks...@gmail.com) wrote:
> On Tue, Oct 18, 2011 at 10:19 AM, Dave Young
> wrote:
> > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines
> > wrote:
> >> From: Hugh Dickins
> >>
> >> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
> >> we're going
Dave Young (hidave.darkstar at gmail.com) wrote:
> On Tue, Oct 18, 2011 at 10:19 AM, Dave Young
> wrote:
> > On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines
> > wrote:
> >> From: Hugh Dickins
> >>
> >> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
> >> we're goi
> 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 t
On Tue, Oct 18, 2011 at 10:19 AM, Dave Young
wrote:
> On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines
> wrote:
>> From: Hugh Dickins
>>
>> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
>> we're going to reboot immediately, the user will not be able to see the
>>
On Tue, Oct 18, 2011 at 8:06 AM, Mandeep Singh Baines
wrote:
> From: Hugh Dickins
>
> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
> we're going to reboot immediately, the user will not be able to see the
> messages anyway, and messing with the video mode may display a
https://bugs.freedesktop.org/show_bug.cgi?id=41913
Chris Wilson changed:
What|Removed |Added
Summary|intel/intel_bufmgr_gem.c:13 |[865]
|61: do_bo_emit_r
https://bugs.freedesktop.org/show_bug.cgi?id=41913
Chris Wilson changed:
What|Removed |Added
AssignedTo|chris at chris-wilson.co.uk|dri-devel at
lists.freedesktop
On Tue, Oct 18, 2011 at 6:02 AM, Dave Airlie wrote:
>> 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
Hi,
I 'm trying to test KMS functionality of latest vmwgfx module.
I tried the code from
http://permalink.gmane.org/gmane.comp.video.dri.devel/42908
as a simple test case, but all I get is a black screen instead
of white as would be expected.
Setup:
VMWare Workstation 8.0.0
Host & Guest distro:
While hacking something else, I stumbled upon two potential issues
in drm_fb_helper. Could someone who knows this better than me enlighten
whether the problem is realistic or whether I am overseeing something ?
If the problem is real (or a potential trouble waiting to happen), I have
cut some pa
https://bugs.freedesktop.org/show_bug.cgi?id=38022
--- Comment #15 from Julien Bigot 2011-10-18 02:19:28 PDT
---
I have the same symptoms here.
Hardware is a radeon 6950 (Cayman) too. (the truth is I have 2 plugged but only
use 1 at the moment)
01:00.0 VGA compatible controller: ATI Technolog
If ret is non-zero then we don't initialize the struct which leaks
stack information to user space.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index d4a1d8b..28e1c35 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execb
These variables get allocated twice so the first allocation is a
memory leak.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index c7cff3d..86c5e4c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/
The intent here was to return an error code, but instead the code
returns the number of bytes remaining (that weren't copied).
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 97f23ab..3f63435 100644
--- a/drivers/gpu/
memtimings is a valid pointer here, the intent was to test for
kcalloc() failure.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/nouveau/nouveau_perf.c
b/drivers/gpu/drm/nouveau/nouveau_perf.c
index 9f178aa..33d03fb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_perf.c
+++ b/drivers/gp
Casting "len" from uin32_t to uint8_t in min_t() truncates the upper
bits. It doesn't matter in this case because "len" is never more
than 0x1f, but Smatch warns about it, so let's change it.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/
https://bugs.freedesktop.org/show_bug.cgi?id=36934
--- Comment #12 from aux...@gmail.com 2011-10-18 09:00:54 PDT ---
radeon.agpmode=-1 stops the corruption I was getting after scrolling a PDF file
in okular with a radeon 9600xt. The problem with this solution is that
frequently Xorg freezes for se
On 10/18/2011 08:10 AM, Dan Carpenter wrote:
> If ret is non-zero then we don't initialize the struct which leaks
> stack information to user space.
>
> Signed-off-by: Dan Carpenter
>
Reviewed-by: Thomas Hellstrom
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vm
On 10/18/2011 08:09 AM, Dan Carpenter wrote:
> These variables get allocated twice so the first allocation is a
> memory leak.
>
> Signed-off-by: Dan Carpenter
>
Reviewed-by: Thomas Hellstrom
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource
On 10/18/2011 08:09 AM, Dan Carpenter wrote:
> The intent here was to return an error code, but instead the code
> returns the number of bytes remaining (that weren't copied).
>
> Signed-off-by: Dan Carpenter
>
Reviewed-by: Thomas Hellstrom
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl
While hacking something else, I stumbled upon two potential issues
in drm_fb_helper. Could someone who knows this better than me enlighten
whether the problem is realistic or whether I am overseeing something ?
If the problem is real (or a potential trouble waiting to happen), I have
cut some p
On Tue, Oct 18, 2011 at 6:02 AM, Dave Airlie wrote:
>> 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
On 10/18/2011 11:14, Jean Delvare wrote:
> Hi Dave, Eugeni, Alex,
>
> On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
>>> 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_bi
Hi Dave, Eugeni, Alex,
On Tue, 18 Oct 2011 11:02:00 +0100, Dave Airlie wrote:
> > 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
https://bugs.freedesktop.org/show_bug.cgi?id=41744
--- Comment #5 from Gašper Sedej 2011-10-18 06:14:37 PDT ---
Thanks. Kernel 3.0 solved the problem.
Render is still not perfect and speed is bad, but it's wokring :).
I see odd shading and odd image in dark (ignore tearing, it's only because of
s
>
> From: Andi Kleen
Hi Andi,
I've merged all the RADEON: patches to drm-next locally, with one minor change
(moving some of the out-of-lines to a more appropriate place).
Thanks,
Dave.
https://bugs.freedesktop.org/show_bug.cgi?id=41913
Chris Wilson changed:
What|Removed |Added
Summary|intel/intel_bufmgr_gem.c:13 |[865]
|61: do_bo_emit_r
https://bugs.freedesktop.org/show_bug.cgi?id=41913
Chris Wilson changed:
What|Removed |Added
AssignedTo|ch...@chris-wilson.co.uk|dri-devel@lists.freedesktop
> 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 t
https://bugs.freedesktop.org/show_bug.cgi?id=38022
--- Comment #15 from Julien Bigot 2011-10-18 02:19:28 PDT ---
I have the same symptoms here.
Hardware is a radeon 6950 (Cayman) too. (the truth is I have 2 plugged but only
use 1 at the moment)
01:00.0 VGA compatible controller: ATI Technologi
>
> From: Andi Kleen
Hi Andi,
I've merged all the RADEON: patches to drm-next locally, with one minor change
(moving some of the out-of-lines to a more appropriate place).
Thanks,
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
63 matches
Mail list logo
