[Bug 20211] Runing Kubrick game maximized freezes X and causes kernel panic
https://bugs.freedesktop.org/show_bug.cgi?id=20211 --- Comment #2 from chemtech --- Jure Repinc, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 20129] Large texture object obscuring display with radeon driver in dxx-rebirth
https://bugs.freedesktop.org/show_bug.cgi?id=20129 --- Comment #14 from chemtech --- jsado_...@comcast.net, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 20751] 2D acceleration on R6xx freezes my computer
https://bugs.freedesktop.org/show_bug.cgi?id=20751 --- Comment #3 from chemtech --- Nicolas Bareil, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 21122] If DRI is enabled ,System will freeze after X quit
https://bugs.freedesktop.org/show_bug.cgi?id=21122 --- Comment #8 from chemtech --- TeF, Please attach full dmesg. Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=21284 --- Comment #5 from chemtech --- Andrew Randrianasulu, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 20537] piglit failures on ATI Mobility M6
https://bugs.freedesktop.org/show_bug.cgi?id=20537 --- Comment #9 from chemtech --- jsado_...@comcast.net, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 3493] r128: Entire X-windowing system hangs during normal 3D gaming
https://bugs.freedesktop.org/show_bug.cgi?id=3493 --- Comment #17 from chemtech --- Alan Grimes, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 8634] [r128] Driver does not support GLX_SGI_make_current_read
https://bugs.freedesktop.org/show_bug.cgi?id=8634 --- Comment #3 from chemtech --- Ian Romanick, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22
https://bugs.freedesktop.org/show_bug.cgi?id=9379 --- Comment #19 from chemtech --- Miroslav Šustek, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 704] Should MACCESS be validated?
https://bugs.freedesktop.org/show_bug.cgi?id=704 --- Comment #1 from chemtech --- ajax at nwnk dot net, Do you still experience this issue with newer soft? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 7034] via_cmdbuf_wait timed out hw
https://bugs.freedesktop.org/show_bug.cgi?id=7034 --- Comment #1 from chemtech --- Alexander Skwar, Do you still experience this issue with newer soft? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 7445] AMD64+Radeon display corruption
https://bugs.freedesktop.org/show_bug.cgi?id=7445 --- Comment #15 from chemtech --- Frank Kingswood, Do you still experience this issue with newer soft? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 6409] XvMC on Intel i810
https://bugs.freedesktop.org/show_bug.cgi?id=6409 --- Comment #2 from chemtech --- José JORGE, Do you still experience this issue with newer soft? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> > In order to prevent a potential NULL deference with hostile userspace,
> > we need to check whether the ioctl was passed an invalid args pointer.
> >
> > Reported-by: Tommi Rantala
> > Link:
> > http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 365e41a..9f5602e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void
> > *data,
> > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > int ret, i;
> >
> > - if (args->buffer_count < 1) {
> > + if (args == NULL)
> > + return -EINVAL;
> > +
> > + if (args->buffer_count < 1 ||
> > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
> > return -EINVAL;
> > }
> > @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void
> > *data,
> > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > int ret;
> >
> > + if (args == NULL)
> > + return -EINVAL;
> > +
> > if (args->buffer_count < 1 ||
> > - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
> > return -EINVAL;
> > }
>
> Why did you change UINT_MAX to INT_MAX?
Because we check later against INT_MAX, and I didn't like the confusion.
If we are going to pick an arbitrary limit, lets at least be consistent.
> TBH, I'm confused what we're
> trying to achieve, and why we need anything other than:
> if (!args->buffer_count)
Because we then promptly do a u32 multiply and we need to be sure that
userspace can't trigger an overflow there and cause us to read
unallocated memory later.
>
> I'm also not seeing how the NULL checks are needed since at least it
> seems to be for execbuffer (IOW) we could never have NULL args.
That's what I thought too. Looking at the stack trace, the empirical
evidence is that we need the check.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=21284 Andrew Randrianasulu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #6 from Andrew Randrianasulu --- Sorry, I completely forgot about it! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv7 10/10] drm: tegra: Add gr2d device
On Wed, Mar 13, 2013 at 02:36:26PM +0200, Terje Bergstrom wrote:
[...]
> diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
[...]
> +static inline struct host1x_drm_context *tegra_drm_get_context(
> + struct list_head *contexts,
> + struct host1x_drm_context *_ctx)
> +{
> + struct host1x_drm_context *ctx;
> +
> + list_for_each_entry(ctx, contexts, list)
> + if (ctx == _ctx)
> + return ctx;
> + return NULL;
> +}
Maybe make this a little more high-level, such as:
static bool host1x_drm_file_owns_context(struct host1x_drm_file *file,
struct host1x_drm_context *context)
?
> +static int tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
> + struct drm_file *file_priv)
> +{
> + struct tegra_drm_open_channel_args *args = data;
> + struct host1x_client *client;
> + struct host1x_drm_context *context;
> + struct host1x_drm_file *fpriv = file_priv->driver_priv;
> + struct host1x_drm *host1x = drm->dev_private;
> + int err = -ENODEV;
> +
> + context = kzalloc(sizeof(*context), GFP_KERNEL);
> + if (!context)
> + return -ENOMEM;
> +
> + list_for_each_entry(client, &host1x->clients, list)
> + if (client->class == args->class) {
> + context->client = client;
Why do you assign this here? Should it perhaps be assigned only when the
opening of the channel succeeds? The .open_channel() already receives a
pointer to the client as parameter, so it doesn't have to be associated
with the context.
> +static int tegra_drm_ioctl_get_syncpoint(struct drm_device *drm, void *data,
> + struct drm_file *file_priv)
> +{
> + struct tegra_drm_get_syncpoint *args = data;
> + struct host1x_drm_file *fpriv = file_priv->driver_priv;
> + struct host1x_drm_context *context =
> + (struct host1x_drm_context *)(uintptr_t)args->context;
> +
> + if (!tegra_drm_get_context(&fpriv->contexts, context))
> + return -ENODEV;
> +
> + if (context->client->num_syncpts < args->param)
> + return -ENODEV;
I think this might be easier to read as:
if (args->param >= context->client->num_syncpts)
return -ENODEV;
> + args->value = host1x_syncpt_id(context->client->syncpts[args->param]);
This could use a temporary variable "syncpt" to make it easier to read.
> +static int tegra_drm_gem_create_ioctl(struct drm_device *drm, void *data,
> + struct drm_file *file_priv)
tegra_drm_ioctl_gem_create()?
> +{
> + struct tegra_drm_create *args = data;
> + struct drm_gem_cma_object *cma_obj;
> + struct tegra_drm_bo *cma_bo;
These can probably just be named "cma"/"gem" and "bo" instead.
> +static int tegra_drm_ioctl_get_offset(struct drm_device *drm, void *data,
> + struct drm_file *file_priv)
I think this might be more generically named tegra_drm_ioctl_mmap()
which might come in handy if we ever need to do something more than just
retrieve the offset.
> +{
> + struct tegra_drm_get_offset *args = data;
> + struct drm_gem_cma_object *cma_obj;
> + struct drm_gem_object *obj;
> +
> + obj = drm_gem_object_lookup(drm, file_priv, args->handle);
> + if (!obj)
> + return -EINVAL;
> + cma_obj = to_drm_gem_cma_obj(obj);
The above two lines should be separated by a blank line.
> +
> + args->offset = cma_obj->base.map_list.hash.key << PAGE_SHIFT;
Perhaps a better way would be to export the get_gem_mmap_offset() from
drivers/gpu/drm/drm_gem_cma_helper.c and reuse that.
> static struct drm_ioctl_desc tegra_drm_ioctls[] = {
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_GEM_CREATE,
> + tegra_drm_gem_create_ioctl, DRM_UNLOCKED | DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_READ,
> + tegra_drm_ioctl_syncpt_read, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_INCR,
> + tegra_drm_ioctl_syncpt_incr, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_WAIT,
> + tegra_drm_ioctl_syncpt_wait, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_OPEN_CHANNEL,
> + tegra_drm_ioctl_open_channel, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_CLOSE_CHANNEL,
> + tegra_drm_ioctl_close_channel, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_GET_SYNCPOINT,
> + tegra_drm_ioctl_get_syncpoint, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SUBMIT,
> + tegra_drm_ioctl_submit, DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_GEM_GET_OFFSET,
> + tegra_drm_ioctl_get_offset, DRM_UNLOCKED),
> };
Maybe resort these to put the GEM-specific IOCTLs closer tog
Re: [Intel-gfx] [PATCH v3] drm/i915: bounds check execbuffer relocation count
On Thu, Mar 14, 2013 at 12:32:00PM -0700, Kees Cook wrote: > On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter wrote: > > On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote: > >> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote: > >>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote: > >>> > It is possible to wrap the counter used to allocate the buffer for > >>> > relocation copies. This could lead to heap writing overflows. > >>> > > >>> > CVE-2013-0913 > >>> > > >>> > v3: collapse test, improve comment > >>> > v2: move check into validate_exec_list > >>> > > >>> > Signed-off-by: Kees Cook > >>> > Reported-by: Pinkie Pie > >>> > Cc: sta...@vger.kernel.org > >>> > >>> Looks good to me. The only bikeshed that remains is whether we should > >>> just collapse the two variables into one, but the current 'max - count' > >>> is more idiomatic and so preferrable. > >>> Reviewed-by: Chris Wilson > >> > >> Picked up for -fixes, thanks for the patch. > > > > I've forgotten to dump my wishlist: Can I have an i-g-t for this? For > > this bug here specifically an execbuf with just one buffer with too > > many relocs plus another execbuf with two buffers with relocation so > > that the 2nd relocation list will overflow should be sufficient. > > Sure thing. Where do these live? (Or what docs should I read for > this?) I'm assuming i-g-t means "intel graphics test"? :) Close :) GPU Tools. The tests lives in the tests directory of: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37112] GPU lockup when trying to use profile based frequency switching
https://bugzilla.kernel.org/show_bug.cgi?id=37112 Hrvoje Senjan changed: What|Removed |Added Kernel Version|2.35-2.6.39 |2.35-3.9-rc2 Severity|normal |high --- Comment #12 from Hrvoje Senjan 2013-03-15 12:33:54 --- Would really appreciate for some further info, the situation is the same with low and mid methods, it tries to change the memory clock too low. Thanks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alex Deucher changed: What|Removed |Added Attachment #76544|0 |1 is obsolete|| --- Comment #55 from Alex Deucher --- Created attachment 76557 --> https://bugs.freedesktop.org/attachment.cgi?id=76557&action=edit take 2 Try this patch. The bits of the non_disp field are inverted for compatibility with evergreen. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support
Hi Sergei,
On Friday 15 March 2013 16:55:58 Sergei Shtylyov wrote:
> On 14-03-2013 18:35, Laurent Pinchart wrote:
> > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> > and DU1 LVDS outputs will require information about the panels that will
> > be connected to those outputs.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> [...]
>
> > diff --git a/arch/arm/mach-shmobile/board-marzen.c
> > b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
> > --- a/arch/arm/mach-shmobile/board-marzen.c
> > +++ b/arch/arm/mach-shmobile/board-marzen.c
>
> [...]
>
> > @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
> > .num_resources = ARRAY_SIZE(hspi_resources),
> > };
> >
> > +/* DU */
> > +static struct resource rcar_du_resources[] = {
> > + [0] = {
> > + .name = "Display Unit",
> > + .start = 0xfff8,
> > + .end= 0xfffb1007,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + [1] = {
> > + .start = gic_spi(31),
>
> Forgot to add: we're supoosed to use the new gic_iid() macro instead.
Thanks for pointing this out. I've based this patch on mainline where
gic_iid() isn't available yet. I'll make sure to rebase on Simon's tree before
sending a pull request.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv7 10/10] drm: tegra: Add gr2d device
On 15.03.2013 14:13, Thierry Reding wrote:
> On Wed, Mar 13, 2013 at 02:36:26PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
> [...]
>> +static inline struct host1x_drm_context *tegra_drm_get_context(
>> + struct list_head *contexts,
>> + struct host1x_drm_context *_ctx)
>> +{
>> + struct host1x_drm_context *ctx;
>> +
>> + list_for_each_entry(ctx, contexts, list)
>> + if (ctx == _ctx)
>> + return ctx;
>> + return NULL;
>> +}
>
> Maybe make this a little more high-level, such as:
>
> static bool host1x_drm_file_owns_context(struct host1x_drm_file *file,
> struct host1x_drm_context *context)
>
> ?
We only need the true/false value, so changing signature makes sense.
>
>> +static int tegra_drm_ioctl_open_channel(struct drm_device *drm, void *data,
>> + struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_open_channel_args *args = data;
>> + struct host1x_client *client;
>> + struct host1x_drm_context *context;
>> + struct host1x_drm_file *fpriv = file_priv->driver_priv;
>> + struct host1x_drm *host1x = drm->dev_private;
>> + int err = -ENODEV;
>> +
>> + context = kzalloc(sizeof(*context), GFP_KERNEL);
>> + if (!context)
>> + return -ENOMEM;
>> +
>> + list_for_each_entry(client, &host1x->clients, list)
>> + if (client->class == args->class) {
>> + context->client = client;
>
> Why do you assign this here? Should it perhaps be assigned only when the
> opening of the channel succeeds? The .open_channel() already receives a
> pointer to the client as parameter, so it doesn't have to be associated
> with the context.
True, we can move the assignment to happen after checking the
open_channel result.
>
>> +static int tegra_drm_ioctl_get_syncpoint(struct drm_device *drm, void *data,
>> + struct drm_file *file_priv)
>> +{
>> + struct tegra_drm_get_syncpoint *args = data;
>> + struct host1x_drm_file *fpriv = file_priv->driver_priv;
>> + struct host1x_drm_context *context =
>> + (struct host1x_drm_context *)(uintptr_t)args->context;
>> +
>> + if (!tegra_drm_get_context(&fpriv->contexts, context))
>> + return -ENODEV;
>> +
>> + if (context->client->num_syncpts < args->param)
>> + return -ENODEV;
>
> I think this might be easier to read as:
>
> if (args->param >= context->client->num_syncpts)
> return -ENODEV;
Ok, will do.
>
>> + args->value = host1x_syncpt_id(context->client->syncpts[args->param]);
>
> This could use a temporary variable "syncpt" to make it easier to read.
Ok.
>
>> +static int tegra_drm_gem_create_ioctl(struct drm_device *drm, void *data,
>> + struct drm_file *file_priv)
>
> tegra_drm_ioctl_gem_create()?
Sure.
>
>> +{
>> + struct tegra_drm_create *args = data;
>> + struct drm_gem_cma_object *cma_obj;
>> + struct tegra_drm_bo *cma_bo;
>
> These can probably just be named "cma"/"gem" and "bo" instead.
Ok.
>
>> +static int tegra_drm_ioctl_get_offset(struct drm_device *drm, void *data,
>> + struct drm_file *file_priv)
>
> I think this might be more generically named tegra_drm_ioctl_mmap()
> which might come in handy if we ever need to do something more than just
> retrieve the offset.
Yeah, that changes the API semantics a bit, but in general there
shouldn't be a need to just get the offset without doing the actual mmap.
>
>> +{
>> + struct tegra_drm_get_offset *args = data;
>> + struct drm_gem_cma_object *cma_obj;
>> + struct drm_gem_object *obj;
>> +
>> + obj = drm_gem_object_lookup(drm, file_priv, args->handle);
>> + if (!obj)
>> + return -EINVAL;
>> + cma_obj = to_drm_gem_cma_obj(obj);
>
> The above two lines should be separated by a blank line.
Ok.
>
>> +
>> + args->offset = cma_obj->base.map_list.hash.key << PAGE_SHIFT;
>
> Perhaps a better way would be to export the get_gem_mmap_offset() from
> drivers/gpu/drm/drm_gem_cma_helper.c and reuse that.
Ok, we'll add that as a patch to the series.
>
>> static struct drm_ioctl_desc tegra_drm_ioctls[] = {
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_GEM_CREATE,
>> + tegra_drm_gem_create_ioctl, DRM_UNLOCKED | DRM_AUTH),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_READ,
>> + tegra_drm_ioctl_syncpt_read, DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_INCR,
>> + tegra_drm_ioctl_syncpt_incr, DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_SYNCPT_WAIT,
>> + tegra_drm_ioctl_syncpt_wait, DRM_UNLOCKED),
>> + DRM_IOCTL_DEF_DRV(TEGRA_DRM_OPEN_CHANNEL,
>> +
[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22
https://bugs.freedesktop.org/show_bug.cgi?id=9379 --- Comment #20 from Miroslav Šustek --- (In reply to comment #19) > Miroslav Šustek, > Do you still experience this issue with newer drivers ? > Please check the status of your issue. I'm sorry, I no longer have the HW to test it. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Harald Arnesen wrote: > I have the same problem on my Lenovo T500. I think the graphics card is > involved. > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > nobody cared" during boot, not when I boot with the ATI card. Confirming this. After a lot of hassle, I have bisected this reliably to commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 Author: Daniel Vetter Date: Sat Dec 1 13:53:45 2012 +0100 drm/i915: use the gmbus irq for waits Adding Daniel, Imre and Daniel to CC while I will try to figure out what's happening in parallel. Attaching dmesg.txt from the machine with 28c70f162a as head, with drm.debug=0xe. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 733] kernel total freeze switching X->fb (matrox)
https://bugs.freedesktop.org/show_bug.cgi?id=733 --- Comment #8 from chemtech --- Alessandro Lepore, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: add support for Richland APUs
From: Alex Deucher
Richland APUs are a new version of the Trinity APUs
with performance and power management improvements.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/ni.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index a7d3de7..27769e7 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -468,13 +468,19 @@ static void cayman_gpu_init(struct radeon_device *rdev)
(rdev->pdev->device == 0x9907) ||
(rdev->pdev->device == 0x9908) ||
(rdev->pdev->device == 0x9909) ||
+ (rdev->pdev->device == 0x990B) ||
+ (rdev->pdev->device == 0x990C) ||
+ (rdev->pdev->device == 0x990F) ||
(rdev->pdev->device == 0x9910) ||
- (rdev->pdev->device == 0x9917)) {
+ (rdev->pdev->device == 0x9917) ||
+ (rdev->pdev->device == 0x)) {
rdev->config.cayman.max_simds_per_se = 6;
rdev->config.cayman.max_backends_per_se = 2;
} else if ((rdev->pdev->device == 0x9903) ||
(rdev->pdev->device == 0x9904) ||
(rdev->pdev->device == 0x990A) ||
+ (rdev->pdev->device == 0x990D) ||
+ (rdev->pdev->device == 0x990E) ||
(rdev->pdev->device == 0x9913) ||
(rdev->pdev->device == 0x9918)) {
rdev->config.cayman.max_simds_per_se = 4;
@@ -483,6 +489,9 @@ static void cayman_gpu_init(struct radeon_device *rdev)
(rdev->pdev->device == 0x9990) ||
(rdev->pdev->device == 0x9991) ||
(rdev->pdev->device == 0x9994) ||
+ (rdev->pdev->device == 0x9995) ||
+ (rdev->pdev->device == 0x9996) ||
+ (rdev->pdev->device == 0x999A) ||
(rdev->pdev->device == 0x99A0)) {
rdev->config.cayman.max_simds_per_se = 3;
rdev->config.cayman.max_backends_per_se = 1;
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: add Richland pci ids
From: Alex Deucher
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
include/drm/drm_pciids.h | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index a386b0b..918e8fe 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -581,7 +581,11 @@
{0x1002, 0x9908, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9909, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x990A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
- {0x1002, 0x990F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x990B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x990C, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x990D, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x990E, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x990F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9910, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9913, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9917, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
@@ -592,6 +596,13 @@
{0x1002, 0x9992, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9993, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9994, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9995, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9996, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9997, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9998, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x999A, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x999B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x99A0, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x99A2, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x99A4, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_ARUBA|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 3832] Can't use R128 and Mach64 simultaniously.
https://bugs.freedesktop.org/show_bug.cgi?id=3832 --- Comment #2 from chemtech --- Alan Grimes Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 3267] Rendering errors running foobillard on Radeon 7500
https://bugs.freedesktop.org/show_bug.cgi?id=3267 --- Comment #9 from chemtech --- Grzegorz Nimoski Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 5477] sis_dri hangs server, causes certain apps (glxcontexts) to segfault
https://bugs.freedesktop.org/show_bug.cgi?id=5477 --- Comment #1 from chemtech --- ugenn Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 5531] DRI enabled freezes X when running any opengl app
https://bugs.freedesktop.org/show_bug.cgi?id=5531 --- Comment #1 from chemtech --- Juan Luis Baptiste Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #56 from Anthony Waters --- take 2 didn't work for me, I also tried (non_disp << 28) to (non_disp << 30) and those didn't fix it either. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 5569] savage: glxgears only shows monochrome flicker
https://bugs.freedesktop.org/show_bug.cgi?id=5569 --- Comment #6 from chemtech --- Steffen Schwientek Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 6090] Texture bitmap not displaying correctly in games similar to tuxracer for r200 based cards.
https://bugs.freedesktop.org/show_bug.cgi?id=6090 --- Comment #2 from chemtech --- Brian Beardall Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 6192] System hard locks when attempting to run HQ Dragothic (3D Mark 2001SE) demo in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=6192 --- Comment #1 from chemtech --- Neil Skrypuch Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 6249] VIA ME600 + XvMC + mplayer hang
https://bugs.freedesktop.org/show_bug.cgi?id=6249 --- Comment #2 from chemtech --- Dan Smolik Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 7971] radeon driver unable to claim hw lock from abusive dri clients
https://bugs.freedesktop.org/show_bug.cgi?id=7971 --- Comment #2 from chemtech --- Aapo Tahkola Do you still experience this issue with newer drivers ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: add support for Richland APUs
On Fri, Mar 15, 2013 at 9:50 AM, wrote:
> From: Alex Deucher
>
> Richland APUs are a new version of the Trinity APUs
> with performance and power management improvements.
>
> Signed-off-by: Alex Deucher
> Cc: sta...@vger.kernel.org
For the serie:
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/ni.c | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index a7d3de7..27769e7 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -468,13 +468,19 @@ static void cayman_gpu_init(struct radeon_device *rdev)
> (rdev->pdev->device == 0x9907) ||
> (rdev->pdev->device == 0x9908) ||
> (rdev->pdev->device == 0x9909) ||
> + (rdev->pdev->device == 0x990B) ||
> + (rdev->pdev->device == 0x990C) ||
> + (rdev->pdev->device == 0x990F) ||
> (rdev->pdev->device == 0x9910) ||
> - (rdev->pdev->device == 0x9917)) {
> + (rdev->pdev->device == 0x9917) ||
> + (rdev->pdev->device == 0x)) {
> rdev->config.cayman.max_simds_per_se = 6;
> rdev->config.cayman.max_backends_per_se = 2;
> } else if ((rdev->pdev->device == 0x9903) ||
>(rdev->pdev->device == 0x9904) ||
>(rdev->pdev->device == 0x990A) ||
> + (rdev->pdev->device == 0x990D) ||
> + (rdev->pdev->device == 0x990E) ||
>(rdev->pdev->device == 0x9913) ||
>(rdev->pdev->device == 0x9918)) {
> rdev->config.cayman.max_simds_per_se = 4;
> @@ -483,6 +489,9 @@ static void cayman_gpu_init(struct radeon_device *rdev)
>(rdev->pdev->device == 0x9990) ||
>(rdev->pdev->device == 0x9991) ||
>(rdev->pdev->device == 0x9994) ||
> + (rdev->pdev->device == 0x9995) ||
> + (rdev->pdev->device == 0x9996) ||
> + (rdev->pdev->device == 0x999A) ||
>(rdev->pdev->device == 0x99A0)) {
> rdev->config.cayman.max_simds_per_se = 3;
> rdev->config.cayman.max_backends_per_se = 1;
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 8258] drm_handle_t isn't 64bit safe
https://bugs.freedesktop.org/show_bug.cgi?id=8258 --- Comment #3 from chemtech --- Andres Salomon Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 3380] Dynamically generate GL dispatch functions for PowerPC
https://bugs.freedesktop.org/show_bug.cgi?id=3380 --- Comment #8 from chemtech --- Ian Romanick Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 7111] racer: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock
https://bugs.freedesktop.org/show_bug.cgi?id=7111 --- Comment #14 from chemtech --- pmhere Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 8896] X error when using off-screen rendering with DRI enabled
https://bugs.freedesktop.org/show_bug.cgi?id=8896 --- Comment #1 from chemtech --- cbeau Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9301] FreeBSD system locks up with DRI enabled on Radeon RS300
https://bugs.freedesktop.org/show_bug.cgi?id=9301 --- Comment #15 from chemtech --- Yong-Jhen Hong Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 5999] problems with r300 and metacity compositing manager
https://bugs.freedesktop.org/show_bug.cgi?id=5999 --- Comment #13 from chemtech --- Diego Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9506] r300 crash on Misfit Model 3D
https://bugs.freedesktop.org/show_bug.cgi?id=9506 --- Comment #15 from chemtech --- Jacek Poplawski Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9851] Bad via entries in pci ids list both for kernel tree and drm tree.
https://bugs.freedesktop.org/show_bug.cgi?id=9851 --- Comment #1 from chemtech --- Xavier Bachelot Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9348] Hard Lockup with Ati X600 X.Org >7.1.1 caused by libdri.so
https://bugs.freedesktop.org/show_bug.cgi?id=9348 --- Comment #3 from chemtech --- Oliver Pahl Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9457] Restricting drm open file descriptors (AIGLX deadlock)
https://bugs.freedesktop.org/show_bug.cgi?id=9457 --- Comment #4 from chemtech --- Thomas Hellström Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 9576] Screen corruption at 24-bit color depth on radeon
https://bugs.freedesktop.org/show_bug.cgi?id=9576 --- Comment #7 from chemtech --- David Brigada Do you still experience this issue with newer soft ? Please check the status of your issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Jiri Kosina wrote: > > I have the same problem on my Lenovo T500. I think the graphics card is > > involved. > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > nobody cared" during boot, not when I boot with the ATI card. > > Confirming this. After a lot of hassle, I have bisected this reliably to > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > Author: Daniel Vetter > Date: Sat Dec 1 13:53:45 2012 +0100 > > drm/i915: use the gmbus irq for waits > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > happening in parallel. > > Attaching dmesg.txt from the machine with 28c70f162a as head, with > drm.debug=0xe. Just a datapoint -- I have put a trivial debugging patch in place, and it reveals that "nobody cared" for irq 16 happens long after last I915_WRITE(GMBUS4 + reg_offset, 0); has been performed in gmbus_wait_hw_status(). On the other hand, if I comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), then it of course falls back to GPIO bit-banging, but the "nobody cared" for irq 16 is gone. So it seems like something gets severely confused by the I915_WRITE to GMBUS4 + reg_offset. So far this seems to have been reported solely on Lenovos as far as I can see (although a completely different types), so it might be some platform-specific quirk? Honestly, I still don't understand how all the GMBUS stuff relates to IRQ 16 at all. -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support
Hello.
On 15-03-2013 5:36, Laurent Pinchart wrote:
Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
and DU1 LVDS outputs will require information about the panels that will
be connected to those outputs.
Signed-off-by: Laurent Pinchart
---
arch/arm/configs/marzen_defconfig | 2 ++
arch/arm/mach-shmobile/board-marzen.c | 65
+
2 files changed, 67 insertions(+)
diff --git a/arch/arm/mach-shmobile/board-marzen.c
b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
[...]
@@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
.num_resources = ARRAY_SIZE(hspi_resources),
};
+/* DU */
+static struct resource rcar_du_resources[] = {
+ [0] = {
+ .name = "Display Unit",
+ .start = 0xfff8,
+ .end= 0xfffb1007,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = gic_spi(31),
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct rcar_du_platform_data rcar_du_pdata = {
+ .encoders = {
+ [0] = {
+ .encoder = RCAR_DU_ENCODER_VGA,
+ },
+ },
+};
+
+static struct platform_device rcar_du_device = {
+ .name = "rcar-du",
+ .num_resources = ARRAY_SIZE(rcar_du_resources),
+ .resource = rcar_du_resources,
+ .dev= {
+ .platform_data = &rcar_du_pdata,
+ .coherent_dma_mask = ~0,
+ },
+};
+
Are we seeing again SoC device declared in the board file? That simply
doesn't scale...
The goal is obviously to move all that to DT, but there's no DT bindings
for the DU DRM driver yet.
I don't see how it justifies dubious non-DT design. Let me tell/remind you
about the LTSI-3.4 tree where all this stuff can be backported and which
doesn't have DT support, AFAIR.
This patch is an example only, I should have marked it as such. If I need to
push something similar to mainline I will keep your comment in mind and see
how I can move the platform device to setup-r8a7779.c. Platform data, however,
need to be provided on a per-board basis.
Yes, it's the usual case of their usage.
Thanks for heeding to my comment.
WBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support
Hello.
On 14-03-2013 18:35, Laurent Pinchart wrote:
Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
and DU1 LVDS outputs will require information about the panels that will
be connected to those outputs.
Signed-off-by: Laurent Pinchart
[...]
diff --git a/arch/arm/mach-shmobile/board-marzen.c
b/arch/arm/mach-shmobile/board-marzen.c
index cdcb799..0020506 100644
--- a/arch/arm/mach-shmobile/board-marzen.c
+++ b/arch/arm/mach-shmobile/board-marzen.c
[...]
@@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
.num_resources = ARRAY_SIZE(hspi_resources),
};
+/* DU */
+static struct resource rcar_du_resources[] = {
+ [0] = {
+ .name = "Display Unit",
+ .start = 0xfff8,
+ .end= 0xfffb1007,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = gic_spi(31),
Forgot to add: we're supoosed to use the new gic_iid() macro instead.
WBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] nouveau: nv10_fence.c: avoid sparse warning
fix this warning : sparse: symbol 'nv10_fence_context_new' was not declared. Should it be static? Signed-off-by: Laurent Navet --- drivers/gpu/drm/nouveau/nouveau_fence.h |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h b/drivers/gpu/drm/nouveau/nouveau_fence.h index c899434..61ee43a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fence.h +++ b/drivers/gpu/drm/nouveau/nouveau_fence.h @@ -64,6 +64,7 @@ int nv17_fence_sync(struct nouveau_fence *, struct nouveau_channel *, struct nouveau_channel *); u32 nv10_fence_read(struct nouveau_channel *); void nv10_fence_context_del(struct nouveau_channel *); +int nv10_fence_context_new(struct nouveau_channel *); void nv10_fence_destroy(struct nouveau_drm *); int nv10_fence_create(struct nouveau_drm *); -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alex Deucher changed: What|Removed |Added Attachment #76557|0 |1 is obsolete|| --- Comment #57 from Alex Deucher --- Created attachment 76563 --> https://bugs.freedesktop.org/attachment.cgi?id=76563&action=edit take 3 Only set the non_disp bit for tiled to linear copies. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, Mar 15, 2013 at 02:33:13PM +0100, Jiri Kosina wrote: > On Fri, 15 Mar 2013, Harald Arnesen wrote: > > > I have the same problem on my Lenovo T500. I think the graphics card is > > involved. > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > nobody cared" during boot, not when I boot with the ATI card. > > Confirming this. After a lot of hassle, I have bisected this reliably to > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > Author: Daniel Vetter > Date: Sat Dec 1 13:53:45 2012 +0100 > > drm/i915: use the gmbus irq for waits > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > happening in parallel. Wasn't this fixed by the merge from David (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? I can't figure out the exact commit that the merge message referred to though... greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Greg KH wrote: > > > I have the same problem on my Lenovo T500. I think the graphics card is > > > involved. > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > > nobody cared" during boot, not when I boot with the ATI card. > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > Author: Daniel Vetter > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > drm/i915: use the gmbus irq for waits > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out what's > > happening in parallel. > > Wasn't this fixed by the merge from David > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? Why do you think it should, please? (I am seeing this with a2362d247 still). -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, Mar 15, 2013 at 04:37:56PM +0100, Jiri Kosina wrote: > On Fri, 15 Mar 2013, Greg KH wrote: > > > > > I have the same problem on my Lenovo T500. I think the graphics card is > > > > involved. > > > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq 16: > > > > nobody cared" during boot, not when I boot with the ATI card. > > > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > > Author: Daniel Vetter > > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > > > drm/i915: use the gmbus irq for waits > > > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out > > > what's > > > happening in parallel. > > > > Wasn't this fixed by the merge from David > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? > > Why do you think it should, please? The line: - Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs and subsequent fallout (Paulo) > (I am seeing this with a2362d247 still). Ok, I guess it isn't still fixed properly, just was guessing :) greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold).
Hi everyone, As a follow up, Konrad sent me in private his vbios and the issue turned out to be trivial. The reason why it behaved this way was that his vbios didn't have sensor calibration values. The fix is available here: http://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commit/59b4006b5b30828bbd094dffe3937333b43d1e12 This fix is part of a pull request I sent to Ben. Thanks again Konrad for reporting and testing the patches, I'll add you as a tester to this patch :) Cheers, Mupuf PS: For the records, here is a fwd of our private conversation. Message original Sujet: Re: nouveau shuts the machine down with v3.9-rc1 (temperature (72 C) hit the 'shutdown' threshold). Date : Fri, 15 Mar 2013 11:16:17 -0400 De :Konrad Rzeszutek Wilk Pour : Martin Peres On Fri, Mar 15, 2013 at 02:30:44AM +0100, Martin Peres wrote: On 13/03/2013 03:20, Konrad Rzeszutek Wilk wrote: >>Ah ah, what challenge? The reason why the temperature is messed up >>is ... trivial. >> >>Will send a patch for that! >Heh. Pls CC me so I can test it and add the Tested-by flag: >>Thanks for reporting the bug! >Of course. >>Martin Hey Konrad, Here are the thermal patches I sent to Ben Skeggs for review. The patch that should solve your problem is the patch 6. Let me know if it solves your issue (that I managed to reproduce by faking a different vbios). dmesg | grep nou [ 12.177930] calling nouveau_drm_init+0x0/0x1000 [nouveau] @ 1488 [ 12.330206] nouveau :00:0d.0: setting latency timer to 64 [ 12.353307] nouveau [ DEVICE][:00:0d.0] BOOT0 : 0x04c000a2 [ 12.359398] nouveau [ DEVICE][:00:0d.0] Chipset: C61 (NV4C) [ 12.365477] nouveau [ DEVICE][:00:0d.0] Family : NV40 [ 12.371621] nouveau [ VBIOS][:00:0d.0] checking PRAMIN for image... [ 12.416327] nouveau [ VBIOS][:00:0d.0] ... appears to be valid [ 12.422758] nouveau [ VBIOS][:00:0d.0] using image from PRAMIN [ 12.429324] nouveau [ VBIOS][:00:0d.0] BIT signature found [ 12.429326] nouveau [ VBIOS][:00:0d.0] version 05.61.32.22.01 [ 12.443160] nouveau [ PFB][:00:0d.0] RAM type: unknown [ 12.443161] nouveau [ PFB][:00:0d.0] RAM size: 128 MiB [ 12.443162] nouveau [ PFB][:00:0d.0]ZCOMP: 0 tags [ 12.50] nouveau [ PTHERM][:00:0d.0] FAN control: none / external [ 12.514647] nouveau [ PTHERM][:00:0d.0] fan management: disabled [ 12.521161] nouveau [ PTHERM][:00:0d.0] internal sensor: no [ 12.547272] nouveau [ PTHERM][:00:0d.0] programmed thresholds [ 90(2), 95(3), 145(2), 135(5) ] [ 12.573758] nouveau [ DRM] VRAM: 125 MiB [ 12.579153] nouveau [ DRM] GART: 512 MiB [ 12.584887] nouveau [ DRM] TMDS table version 1.1 [ 12.590018] nouveau [ DRM] DCB version 3.0 [ 12.594555] nouveau [ DRM] DCB outp 00: 01000310 0023 [ 12.601754] nouveau [ DRM] DCB outp 01: 00110204 97e5 [ 12.607585] nouveau [ DRM] DCB conn 00: [ 12.612424] nouveau [ DRM] Saving VGA fonts [ 12.656034] nouveau W[ DRM] DCB type 4 not known [ 12.660991] nouveau W[ DRM] Unknown-1 has no encoders, removing [ 12.681157] nouveau [ DRM] 1 available performance level(s) [ 12.687714] nouveau [ DRM] 0: core 425MHz shader 425MHz fanspeed 100% [ 12.694575] nouveau [ DRM] c: [ 12.699270] nouveau [ DRM] MM: using M2MF for buffer copies [ 12.738742] nouveau :00:0d.0: No connectors reported connected with modes [ 12.752063] nouveau [ DRM] allocated 1024x768 fb: 0x9000, bo 88012dffbc00 [ 12.763397] fbcon: nouveaufb (fb0) is primary device [ 12.780410] nouveau :00:0d.0: fb0: nouveaufb frame buffer device [ 12.786754] nouveau :00:0d.0: registered panic notifier [ 12.792330] [drm] Initialized nouveau 1.1.0 20120801 for :00:0d.0 on minor 0 [ 12.800071] initcall nouveau_drm_init+0x0/0x1000 [nouveau] returned 0 after 602409 usecs and no poweroffs :-) So definitly Tested-by: Konrad Rzeszutek Wilk all of the patches. Thanks! Cheers, Martin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, 15 Mar 2013, Greg KH wrote: > > > > > I have the same problem on my Lenovo T500. I think the graphics card > > > > > is > > > > > involved. > > > > > > > > > > This laptop has "hybrid graphics" - one Intel GMA 4500MHD and one ATI > > > > > Mobility Radeon HD 3650. When I boot with the Intel card, I get "irq > > > > > 16: > > > > > nobody cared" during boot, not when I boot with the ATI card. > > > > > > > > Confirming this. After a lot of hassle, I have bisected this reliably to > > > > > > > > commit 28c70f162a315bdcfbe0bf940a740ef8bfb918d6 > > > > Author: Daniel Vetter > > > > Date: Sat Dec 1 13:53:45 2012 +0100 > > > > > > > > drm/i915: use the gmbus irq for waits > > > > > > > > Adding Daniel, Imre and Daniel to CC while I will try to figure out > > > > what's > > > > happening in parallel. > > > > > > Wasn't this fixed by the merge from David > > > (2cc79544bd0aabb4b3cf467ead5df526d9134c64)? > > > > Why do you think it should, please? > > The line: > - Fix PCH irq handling race which resulted in missed gmbus/dp > aux irqs and subsequent fallout (Paulo) Ah, that one. I believe that should be irrelevant for GM chipsets, as they don't have AUX line, right? > > (I am seeing this with a2362d247 still). > > Ok, I guess it isn't still fixed properly, just was guessing :) Seems like this is a different issue. Thanks, -- Jiri Kosina SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> > On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> > > In order to prevent a potential NULL deference with hostile userspace,
> > > we need to check whether the ioctl was passed an invalid args pointer.
> > >
> > > Reported-by: Tommi Rantala
> > > Link:
> > > http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
> > > 1 file changed, 9 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > index 365e41a..9f5602e 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void
> > > *data,
> > > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > > int ret, i;
> > >
> > > - if (args->buffer_count < 1) {
> > > + if (args == NULL)
> > > + return -EINVAL;
> > > +
> > > + if (args->buffer_count < 1 ||
> > > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > > DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
> > > return -EINVAL;
> > > }
> > > @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void
> > > *data,
> > > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > > int ret;
> > >
> > > + if (args == NULL)
> > > + return -EINVAL;
> > > +
> > > if (args->buffer_count < 1 ||
> > > - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> > > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > > DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
> > > return -EINVAL;
> > > }
> >
> > Why did you change UINT_MAX to INT_MAX?
>
> Because we check later against INT_MAX, and I didn't like the confusion.
> If we are going to pick an arbitrary limit, lets at least be consistent.
>
> > TBH, I'm confused what we're
> > trying to achieve, and why we need anything other than:
> > if (!args->buffer_count)
>
> Because we then promptly do a u32 multiply and we need to be sure that
> userspace can't trigger an overflow there and cause us to read
> unallocated memory later.
> >
> > I'm also not seeing how the NULL checks are needed since at least it
> > seems to be for execbuffer (IOW) we could never have NULL args.
>
> That's what I thought too. Looking at the stack trace, the empirical
> evidence is that we need the check.
> -Chris
I think we need to investigate the issue more then, or put a BUG_ON() in
the drm code and run it through trinity. We have other places where arg
can't/shouldn't be NULL and we don't check.
--
Ben Widawsky, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #58 from Anthony Waters --- That didn't work either, the L2T path is the one that keeps getting executed. In my case dst_mode is RADEON_SURF_MODE_2D or RADEON_SURF_MODE_1D and src_mode is RADEON_SURF_MODE_LINEAR_ALIGNED. I'll see if I can get some more specifics about the issue. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 7111] racer: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock
https://bugs.freedesktop.org/show_bug.cgi?id=7111 --- Comment #15 from mrste...@gmx.de --- Though I am not pmhere, I want to inform you that for me this problem has been gone for a long while now. Don't know exactly with which software versions. Sorry for not posting earlier. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #59 from Alexandre Demers --- Alex, a couple of things changed in your last attachment. You removed the L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed the binary offset for 28 (instead of 27). Am I right to understand you set "non_disp" back to 1 because your are offsetting one more bit (according to your comment in v2)? If that's right, I don't see how v3 is different from v2 except for the L2T change. And since non_disp=1 is not set at all in the main branch, how would that fix the corruption problem. Aren't we back to v0 for the L2T path (which is broken) and to v2 for the T2L path (which is also not better)? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 8634] [r128] Driver does not support GLX_SGI_make_current_read
https://bugs.freedesktop.org/show_bug.cgi?id=8634 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Ian Romanick --- The r128 driver was removed from Mesa years ago. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)
On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina wrote: > Just a datapoint -- I have put a trivial debugging patch in place, and it > reveals that "nobody cared" for irq 16 happens long after last > > I915_WRITE(GMBUS4 + reg_offset, 0); > > has been performed in gmbus_wait_hw_status(). On the other hand, if I > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(), > then it of course falls back to GPIO bit-banging, but the "nobody cared" > for irq 16 is gone. > > So it seems like something gets severely confused by the I915_WRITE to > GMBUS4 + reg_offset. So far this seems to have been reported solely on > Lenovos as far as I can see (although a completely different types), so it > might be some platform-specific quirk? > > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ > 16 at all. that device is using i915 :00:02.0: irq 44 for MSI/MSI-X so can you try to boot with pci=nomsi? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alex Deucher changed: What|Removed |Added Attachment #76563|0 |1 is obsolete|| --- Comment #60 from Alex Deucher --- Created attachment 76590 --> https://bugs.freedesktop.org/attachment.cgi?id=76590&action=edit use blitter for compressed textures This patch fixes the issue here. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #61 from Alex Deucher --- (In reply to comment #59) > Alex, a couple of things changed in your last attachment. You removed the > L2T part, you reverted the "non_disp = 2" back to "non_disp = 1" and changed > the binary offset for 28 (instead of 27). Am I right to understand you set > "non_disp" back to 1 because your are offsetting one more bit (according to > your comment in v2)? The non_disp field is two bits on cayman and one bit evergreen. Bit 28 in this packet represents bit 0 of the non_disp field and bit 27 represents bit 1 of the non_disp field so that it's compatible with evergreen. So just setting bit 28 covers us for both evergreen and cayman since we only care about non_dip bit 0. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #62 from Alex Deucher --- The way to properly handle T2L or L2T conversions of compressed textures with the DMA engine is to hack up the formats like we do in the blitter code so that it looks like a PIPE_FORMAT_R16G16B16A16_UINT or PIPE_FORMAT_R32G32B32A32_UINT T2L or L2T blit. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 6192] System hard locks when attempting to run HQ Dragothic (3D Mark 2001SE) demo in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=6192 --- Comment #2 from Neil Skrypuch --- Seven years later... I can't really test this now, I don't have an X server on that machine anymore. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote: > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote: > > That's what I thought too. Looking at the stack trace, the empirical > > evidence is that we need the check. > > -Chris > > I think we need to investigate the issue more then, or put a BUG_ON() in > the drm code and run it through trinity. We have other places where arg > can't/shouldn't be NULL and we don't check. Actually we are both wrong. drm_ioctl() does not validate that the user struct matches the expected size, just ensures that if that user cmd specifies that the arg is to be used that it only up to the known size is copied. A hostile userspace can bludgen a NULL pointer through drm_ioctl() into the driver->ioctl->func(). If we used driver->ioctl->cmd instead of the user supplied cmd, we would have a whole other can of worms to deal with (as we suddenly get a struct of zeroes). However, those worms should already be treated as invalid. Choose your poison. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alex Deucher changed: What|Removed |Added Attachment #76590|0 |1 is obsolete|| --- Comment #63 from Alex Deucher --- Created attachment 76592 --> https://bugs.freedesktop.org/attachment.cgi?id=76592&action=edit take 5 After further investigation this seems to be an alignment issue with large block sizes on the DMA engine on cayman. For now just use the blitter for large block sizes. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.9
From: Alex Deucher Hi Dave, Mostly just small bug fixes. Big change is new pci ids for Richland APUs. The following changes since commit 8698080ee092bdbd6ee2cd5e7f707ceea2812bd8: Merge branch 'drm-nouveau-fixes-3.9' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2013-03-11 13:53:58 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.9 Alex Deucher (6): drm/radeon: fix S/R on VM systems (cayman/TN/SI) drm/radeon: fix backend map setup on 1 RB trinity boards drm/radeon/benchmark: make sure bo blit copy exists before using it drm/radeon/benchmark: allow same domains for dma copy drm/radeon: add support for Richland APUs drm/radeon: add Richland pci ids drivers/gpu/drm/radeon/ni.c | 33 +++- drivers/gpu/drm/radeon/radeon_benchmark.c | 21 - drivers/gpu/drm/radeon/si.c |1 + include/drm/drm_pciids.h | 13 ++- 4 files changed, 50 insertions(+), 18 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 7111] racer: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock
https://bugs.freedesktop.org/show_bug.cgi?id=7111 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Fri, Mar 15, 2013 at 10:06:19PM +, Chris Wilson wrote: > On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote: > > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote: > > > That's what I thought too. Looking at the stack trace, the empirical > > > evidence is that we need the check. > > > -Chris > > > > I think we need to investigate the issue more then, or put a BUG_ON() in > > the drm code and run it through trinity. We have other places where arg > > can't/shouldn't be NULL and we don't check. > > Actually we are both wrong. drm_ioctl() does not validate that the > user struct matches the expected size, just ensures that if that user > cmd specifies that the arg is to be used that it only up to the known > size is copied. > > A hostile userspace can bludgen a NULL pointer through drm_ioctl() into > the driver->ioctl->func(). > > > + if (args == NULL) > > > + return -EINVAL; > > > + I must be failing to see the obvious, but I'm still not getting how args can ever be NULL. kdata which is passed to us as "data" and cast to "args' is either always some stack variable, or some kmalloc'd memory. I see how the arguments themselves can be crap which is really only when user size != drv_size. So tell me, which case can result in a NULL arg? 1. user size == drv_size // better not be this one 2. user size < driver size 3. user size > driver size It seems to me we still must [simply] be missing something in our parameter validation. > > If we used driver->ioctl->cmd instead of the user supplied cmd, we would > have a whole other can of worms to deal with (as we suddenly get a > struct of zeroes). However, those worms should already be treated as > invalid. Choose your poison. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Ben Widawsky, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 20211] Runing Kubrick game maximized freezes X and causes kernel panic
https://bugs.freedesktop.org/show_bug.cgi?id=20211 --- Comment #3 from Jure Repinc --- I think thins bug can be closed. I haven't got this freeze for quite some time now. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 6192] System hard locks when attempting to run HQ Dragothic (3D Mark 2001SE) demo in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=6192 --- Comment #3 from chemtech --- Then please close the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 20211] Runing Kubrick game maximized freezes X and causes kernel panic
https://bugs.freedesktop.org/show_bug.cgi?id=20211 --- Comment #4 from chemtech --- Then please close the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #64 from Alexandre Demers --- (In reply to comment #63) > Created attachment 76592 [details] [review] > take 5 > > After further investigation this seems to be an alignment issue with large > block sizes on the DMA engine on cayman. For now just use the blitter for > large block sizes. It does the trick for now. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #51 from Alex Deucher --- Created attachment 76544 --> https://bugs.freedesktop.org/attachment.cgi?id=76544&action=edit set non_disp tiling bit for cayman Good catch! I believe the attached patch should fix the issue. -- 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/20130315/16b07244/attachment.html>
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #52 from Alexandre Demers --- (In reply to comment #51) > Created attachment 76544 [details] [review] > set non_disp tiling bit for cayman > > Good catch! I believe the attached patch should fix the issue. I don't know for others, but it doesn't fix the corruption over here. -- 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/20130315/65c410be/attachment.html>
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802
--- Comment #53 from Alexandre Demers ---
(In reply to comment #50)
> I believe I have the source of the bug, it appears that there is a special
> case for Caymen GPUs that isn't handled in the DMA code path. In
> evergreen_state.c within the method evergreen_create_sampler_view_custom
> there is the chunk of code
>
> /* 128 bit formats require tile type = 1 */
> if (rscreen->chip_class == CAYMAN) {
> if (util_format_get_blocksize(pipe_format) >= 16)
> non_disp_tiling = 1;
> }
>
> however, within evergreen_dma_copy_tile in the same source file no such code
> exists. I tested whether this was the case or not by placing the lines of
> code
>
> if (util_format_get_blocksize(dst->format) >= 16) {
> printf("Caymen non disp tiling skipping dma tile\n");
> return FALSE;
> }
>
> before the call to evergreen_dma_copy_tile in evergreen_dma_blit, and the
> corruption no longer appeared. (having this checks skips the DMA path for
> this case and goes through the normal path, which would be
> evergreen_create_sampler_view_custom I believe)
>
> I'm not sure which bits in the DMA packet control this setting.
Your observations are right, using your trick does indeed remove the
corruptions.
--
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/20130315/8a302b29/attachment.html>
[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support
On Friday 15 March 2013 02:11:05 Sergei Shtylyov wrote:
> On 15.03.2013 0:11, Laurent Pinchart wrote:
> >>> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
> >>> and DU1 LVDS outputs will require information about the panels that will
> >>> be connected to those outputs.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>>
> >>> ---
> >>>
> >>>arch/arm/configs/marzen_defconfig | 2 ++
> >>>arch/arm/mach-shmobile/board-marzen.c | 65
> >>>+
> >>>2 files changed, 67 insertions(+)
> >>>
> >>> diff --git a/arch/arm/mach-shmobile/board-marzen.c
> >>> b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
> >>> --- a/arch/arm/mach-shmobile/board-marzen.c
> >>> +++ b/arch/arm/mach-shmobile/board-marzen.c
> >>
> >> [...]
> >>
> >>> @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
> >>> .num_resources = ARRAY_SIZE(hspi_resources),
> >>>};
> >>>
> >>> +/* DU */
> >>> +static struct resource rcar_du_resources[] = {
> >>> + [0] = {
> >>> + .name = "Display Unit",
> >>> + .start = 0xfff8,
> >>> + .end= 0xfffb1007,
> >>> + .flags = IORESOURCE_MEM,
> >>> + },
> >>> + [1] = {
> >>> + .start = gic_spi(31),
> >>> + .flags = IORESOURCE_IRQ,
> >>> + },
> >>> +};
> >>> +
> >>> +static struct rcar_du_platform_data rcar_du_pdata = {
> >>> + .encoders = {
> >>> + [0] = {
> >>> + .encoder = RCAR_DU_ENCODER_VGA,
> >>> + },
> >>> + },
> >>> +};
> >>> +
> >>> +static struct platform_device rcar_du_device = {
> >>> + .name = "rcar-du",
> >>> + .num_resources = ARRAY_SIZE(rcar_du_resources),
> >>> + .resource = rcar_du_resources,
> >>> + .dev= {
> >>> + .platform_data = &rcar_du_pdata,
> >>> + .coherent_dma_mask = ~0,
> >>> + },
> >>> +};
> >>> +
> >>
> >> Are we seeing again SoC device declared in the board file? That simply
> >> doesn't scale...
> >
> > The goal is obviously to move all that to DT, but there's no DT bindings
> > for the DU DRM driver yet.
>
> I don't see how it justifies dubious non-DT design. Let me tell/remind you
> about the LTSI-3.4 tree where all this stuff can be backported and which
> doesn't have DT support, AFAIR.
This patch is an example only, I should have marked it as such. If I need to
push something similar to mainline I will keep your comment in mind and see
how I can move the platform device to setup-r8a7779.c. Platform data, however,
need to be provided on a per-board basis.
--
Regards,
Laurent Pinchart
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #54 from Alexandre Demers --- (In reply to comment #51) > Created attachment 76544 [details] [review] > set non_disp tiling bit for cayman > > Good catch! I believe the attached patch should fix the issue. Since this bug is pretty much the same as previous one I had identified in comment 29 (pointing to bug 38173) and since the proposed patch is also pretty similar to 1 of the 2 patches needed to fix that identified bug, is it possible there is something missing that would look like the second patch that was needed? patch 1 from bug 38173 (similar to the one proposed with your attachment 76544): http://cgit.freedesktop.org/mesa/mesa/commit/?id=5e1495b2d9311fa2b320766a1d299053904bd9c3 patch 2 from bug 38173 (possibly similar to what is missing to complete your proposed patch): http://cgit.freedesktop.org/mesa/mesa/commit/?id=acca690c259824636ef1ff684a10bd1caca4751f In other words, are we sure we are offsetting the non_disp variable correctly for Cayman? Because according to the second patch, the offset was different. -- 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/20130315/1e77d102/attachment.html>
[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support
On 15.03.2013 0:11, Laurent Pinchart wrote:
>>> Only the DU0 VGA output is currently supported. Support for the DU0 LVDS
>>> and DU1 LVDS outputs will require information about the panels that will
>>> be connected to those outputs.
>>> Signed-off-by: Laurent Pinchart
>>>
>>> ---
>>>arch/arm/configs/marzen_defconfig | 2 ++
>>>arch/arm/mach-shmobile/board-marzen.c | 65 +
>>>2 files changed, 67 insertions(+)
>>> diff --git a/arch/arm/mach-shmobile/board-marzen.c
>>> b/arch/arm/mach-shmobile/board-marzen.c index cdcb799..0020506 100644
>>> --- a/arch/arm/mach-shmobile/board-marzen.c
>>> +++ b/arch/arm/mach-shmobile/board-marzen.c
>> [...]
>>> @@ -147,6 +148,38 @@ static struct platform_device hspi_device = {
>>> .num_resources = ARRAY_SIZE(hspi_resources),
>>>};
>>>
>>> +/* DU */
>>> +static struct resource rcar_du_resources[] = {
>>> + [0] = {
>>> + .name = "Display Unit",
>>> + .start = 0xfff8,
>>> + .end= 0xfffb1007,
>>> + .flags = IORESOURCE_MEM,
>>> + },
>>> + [1] = {
>>> + .start = gic_spi(31),
>>> + .flags = IORESOURCE_IRQ,
>>> + },
>>> +};
>>> +
>>> +static struct rcar_du_platform_data rcar_du_pdata = {
>>> + .encoders = {
>>> + [0] = {
>>> + .encoder = RCAR_DU_ENCODER_VGA,
>>> + },
>>> + },
>>> +};
>>> +
>>> +static struct platform_device rcar_du_device = {
>>> + .name = "rcar-du",
>>> + .num_resources = ARRAY_SIZE(rcar_du_resources),
>>> + .resource = rcar_du_resources,
>>> + .dev= {
>>> + .platform_data = &rcar_du_pdata,
>>> + .coherent_dma_mask = ~0,
>>> + },
>>> +};
>>> +
>> Are we seeing again SoC device declared in the board file? That simply
>> doesn't scale...
> The goal is obviously to move all that to DT, but there's no DT bindings for
> the DU DRM driver yet.
I don't see how it justifies dubious non-DT design. Let me tell/remind you
about the LTSI-3.4 tree where all this stuff can be backported and which
doesn't have DT support, AFAIR.
WBR, Sergei
[Bug 20211] Runing Kubrick game maximized freezes X and causes kernel panic
https://bugs.freedesktop.org/show_bug.cgi?id=20211 --- Comment #2 from chemtech --- Jure Repinc, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- 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/20130315/105f5eae/attachment.html>
[Bug 20129] Large texture object obscuring display with radeon driver in dxx-rebirth
https://bugs.freedesktop.org/show_bug.cgi?id=20129 --- Comment #14 from chemtech --- jsado_sc3 at comcast.net, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- 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/20130315/e2b8ad41/attachment.html>
[Bug 20751] 2D acceleration on R6xx freezes my computer
https://bugs.freedesktop.org/show_bug.cgi?id=20751 --- Comment #3 from chemtech --- Nicolas Bareil, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- 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/20130315/5ae4af06/attachment.html>
[Bug 21122] If DRI is enabled ,System will freeze after X quit
https://bugs.freedesktop.org/show_bug.cgi?id=21122 --- Comment #8 from chemtech --- TeF, Please attach full dmesg. Please check the status of your issue. -- 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/20130315/a1797241/attachment-0001.html>
[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=21284 --- Comment #5 from chemtech --- Andrew Randrianasulu, Please attach full dmesg and output of lspci -vv Please check the status of your issue. -- 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/20130315/8dd69b6f/attachment.html>
[Bug 20537] piglit failures on ATI Mobility M6
https://bugs.freedesktop.org/show_bug.cgi?id=20537 --- Comment #9 from chemtech --- jsado_sc3 at comcast.net, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- 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/20130315/720752a1/attachment.html>
[Bug 3493] r128: Entire X-windowing system hangs during normal 3D gaming
https://bugs.freedesktop.org/show_bug.cgi?id=3493 --- Comment #17 from chemtech --- Alan Grimes, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- 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/20130315/3ab8727e/attachment.html>
[Bug 8634] [r128] Driver does not support GLX_SGI_make_current_read
https://bugs.freedesktop.org/show_bug.cgi?id=8634 --- Comment #3 from chemtech --- Ian Romanick, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- 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/20130315/d51cdcaf/attachment.html>
[Bug 9379] drmCommandNone( fd, DRM_R128_CCE_IDLE ) - gives errno 22
https://bugs.freedesktop.org/show_bug.cgi?id=9379 --- Comment #19 from chemtech --- Miroslav ?ustek, Do you still experience this issue with newer drivers ? Please check the status of your issue. -- 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/20130315/bf9d498d/attachment.html>
[Bug 704] Should MACCESS be validated?
https://bugs.freedesktop.org/show_bug.cgi?id=704 --- Comment #1 from chemtech --- ajax at nwnk dot net, Do you still experience this issue with newer soft? Please check the status of your issue. -- 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/20130315/a37f61c2/attachment.html>
[Bug 7034] via_cmdbuf_wait timed out hw
https://bugs.freedesktop.org/show_bug.cgi?id=7034 --- Comment #1 from chemtech --- Alexander Skwar, Do you still experience this issue with newer soft? Please check the status of your issue. -- 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/20130315/a1940142/attachment.html>
[Bug 7445] AMD64+Radeon display corruption
https://bugs.freedesktop.org/show_bug.cgi?id=7445 --- Comment #15 from chemtech --- Frank Kingswood, Do you still experience this issue with newer soft? Please check the status of your issue. -- 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/20130315/5b7a2176/attachment.html>
[Bug 6409] XvMC on Intel i810
https://bugs.freedesktop.org/show_bug.cgi?id=6409 --- Comment #2 from chemtech --- Jos? JORGE, Do you still experience this issue with newer soft? Please check the status of your issue. -- 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/20130315/f256dff9/attachment-0001.html>
[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> > In order to prevent a potential NULL deference with hostile userspace,
> > we need to check whether the ioctl was passed an invalid args pointer.
> >
> > Reported-by: Tommi Rantala
> > Link:
> > http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow
> > at mail.gmail.com
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 365e41a..9f5602e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void
> > *data,
> > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > int ret, i;
> >
> > - if (args->buffer_count < 1) {
> > + if (args == NULL)
> > + return -EINVAL;
> > +
> > + if (args->buffer_count < 1 ||
> > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
> > return -EINVAL;
> > }
> > @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void
> > *data,
> > struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> > int ret;
> >
> > + if (args == NULL)
> > + return -EINVAL;
> > +
> > if (args->buffer_count < 1 ||
> > - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> > + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> > DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
> > return -EINVAL;
> > }
>
> Why did you change UINT_MAX to INT_MAX?
Because we check later against INT_MAX, and I didn't like the confusion.
If we are going to pick an arbitrary limit, lets at least be consistent.
> TBH, I'm confused what we're
> trying to achieve, and why we need anything other than:
> if (!args->buffer_count)
Because we then promptly do a u32 multiply and we need to be sure that
userspace can't trigger an overflow there and cause us to read
unallocated memory later.
>
> I'm also not seeing how the NULL checks are needed since at least it
> seems to be for execbuffer (IOW) we could never have NULL args.
That's what I thought too. Looking at the stack trace, the empirical
evidence is that we need the check.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 21284] [KMS] Radeon rv280 black screen with modeset=1
https://bugs.freedesktop.org/show_bug.cgi?id=21284 Andrew Randrianasulu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #6 from Andrew Randrianasulu --- Sorry, I completely forgot about it! -- 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/20130315/56dbb55c/attachment.html>
[PATCHv7 10/10] drm: tegra: Add gr2d device
eld. However I think we can
leave this as-is for now and change it later if required.
> +static int gr2d_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct host1x_drm *host1x = host1x_get_drm_data(dev->parent);
> + int err;
> + struct gr2d *gr2d = NULL;
> + struct host1x_syncpt **syncpts;
I don't think there's a need for this temporary variable. You could just
use gr2d->client.syncpts directly.
> + gr2d = devm_kzalloc(dev, sizeof(*gr2d), GFP_KERNEL);
> + if (!gr2d)
> + return -ENOMEM;
> +
> + syncpts = devm_kzalloc(dev, sizeof(*syncpts), GFP_KERNEL);
> + if (!syncpts)
> + return -ENOMEM;
> +
> + gr2d->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(gr2d->clk)) {
> + dev_err(dev, "cannot get clock\n");
> + return PTR_ERR(gr2d->clk);
> + }
> +
> + err = clk_prepare_enable(gr2d->clk);
> + if (err) {
> + dev_err(dev, "cannot turn on clock\n");
> + return err;
> + }
> +
> + gr2d->channel = host1x_channel_alloc(dev);
> + if (!gr2d->channel)
> + return -ENOMEM;
> +
> + *syncpts = host1x_syncpt_request(dev, 0);
> + if (!(*syncpts)) {
> + host1x_channel_free(gr2d->channel);
> + return -ENOMEM;
> + }
> +
> + gr2d->client.ops = &gr2d_client_ops;
> + gr2d->client.dev = dev;
> + gr2d->client.class = HOST1X_CLASS_GR2D;
> + gr2d->client.syncpts = syncpts;
> + gr2d->client.num_syncpts = 1;
> +
> + err = host1x_register_client(host1x, &gr2d->client);
> + if (err < 0) {
> + dev_err(dev, "failed to register host1x client: %d\n", err);
> + return err;
> + }
> +
> + gr2d_init_addr_reg_map(dev, gr2d);
> +
> + dev_set_drvdata(dev, gr2d);
Nit: I think it'd be nicer to use platform_set_drvdata() here to mirror
the platform_get_drvdata() from gr2d_remove().
> diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h
[...]
> +struct tegra_drm_create {
struct tegra_drm_gem_create?
> + __u64 size;
> + u32 flags;
> + u32 handle;
> + u32 offset;
> + u32 padding;
Also since we have a separate IOCTL for this, I think you can leave out
the offset field (and also padding since it isn't required anymore).
> +struct tegra_drm_get_offset {
> + __u32 handle;
> + __u32 offset;
> +};
struct tegra_drm_gem_mmap to go along with the name change of the IOCTL.
> +struct tegra_drm_syncpt_incr_args {
> + __u32 id;
> + __u32 pad;
> +};
Shouldn't this second field be something like "value" to allow this
IOCTL to increment by more than 1?
> +#define DRM_TEGRA_NO_TIMEOUT (0x)
No need for the parentheses.
> +struct tegra_drm_reloc {
> + __u32 cmdbuf_mem;
> + __u32 cmdbuf_offset;
> + __u32 target;
> + __u32 target_offset;
> + __u32 shift;
> + __u32 pad;
> +};
I've found this to be a little inconsistent. Why does the cmdbuf_mem
have the _mem suffix, but not the target field? Given that this will
eventually be used by userspace software once merged it will be fixed
forever. I had noticed the same for the in-kernel structures but didn't
think it important enough to hold up the patches. In this case I think
we should make them consistent, though.
> +#define DRM_TEGRA_DRM_GEM_CREATE 0x00
> +#define DRM_TEGRA_DRM_SYNCPT_READ0x01
> +#define DRM_TEGRA_DRM_SYNCPT_INCR0x02
> +#define DRM_TEGRA_DRM_SYNCPT_WAIT0x03
> +#define DRM_TEGRA_DRM_OPEN_CHANNEL 0x04
> +#define DRM_TEGRA_DRM_CLOSE_CHANNEL 0x05
> +#define DRM_TEGRA_DRM_GET_SYNCPOINT 0x06
> +#define DRM_TEGRA_DRM_SUBMIT 0x08
> +#define DRM_TEGRA_DRM_GEM_GET_OFFSET 0x09
> +
> +#define DRM_IOCTL_TEGRA_DRM_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_GEM_CREATE, struct tegra_drm_create)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_READ DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SYNCPT_READ, struct tegra_drm_syncpt_read_args)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_INCR DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SYNCPT_INCR, struct tegra_drm_syncpt_incr_args)
> +#define DRM_IOCTL_TEGRA_DRM_SYNCPT_WAIT DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SYNCPT_WAIT, struct tegra_drm_syncpt_wait_args)
> +#define DRM_IOCTL_TEGRA_DRM_OPEN_CHANNEL DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_OPEN_CHANNEL, struct tegra_drm_open_channel_args)
> +#define DRM_IOCTL_TEGRA_DRM_CLOSE_CHANNEL DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_CLOSE_CHANNEL, struct tegra_drm_open_channel_args)
> +#define DRM_IOCTL_TEGRA_DRM_GET_SYNCPOINT DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_GET_SYNCPOINT, struct tegra_drm_get_syncpoint)
> +#define DRM_IOCTL_TEGRA_DRM_SUBMIT DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_SUBMIT, struct tegra_drm_submit_args)
> +#define DRM_IOCTL_TEGRA_DRM_GEM_GET_OFFSET DRM_IOWR(DRM_COMMAND_BASE +
> DRM_TEGRA_DRM_GEM_GET_OFFSET, struct tegra_drm_get_offset)
Same comment regarding reordering and GET_OFFSET -> MMAP rename.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130315/aea2033f/attachment.pgp>
[Intel-gfx] [PATCH v3] drm/i915: bounds check execbuffer relocation count
On Thu, Mar 14, 2013 at 12:32:00PM -0700, Kees Cook wrote: > On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter > wrote: > > On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote: > >> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote: > >>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote: > >>> > It is possible to wrap the counter used to allocate the buffer for > >>> > relocation copies. This could lead to heap writing overflows. > >>> > > >>> > CVE-2013-0913 > >>> > > >>> > v3: collapse test, improve comment > >>> > v2: move check into validate_exec_list > >>> > > >>> > Signed-off-by: Kees Cook > >>> > Reported-by: Pinkie Pie > >>> > Cc: stable at vger.kernel.org > >>> > >>> Looks good to me. The only bikeshed that remains is whether we should > >>> just collapse the two variables into one, but the current 'max - count' > >>> is more idiomatic and so preferrable. > >>> Reviewed-by: Chris Wilson > >> > >> Picked up for -fixes, thanks for the patch. > > > > I've forgotten to dump my wishlist: Can I have an i-g-t for this? For > > this bug here specifically an execbuf with just one buffer with too > > many relocs plus another execbuf with two buffers with relocation so > > that the 2nd relocation list will overflow should be sufficient. > > Sure thing. Where do these live? (Or what docs should I read for > this?) I'm assuming i-g-t means "intel graphics test"? :) Close :) GPU Tools. The tests lives in the tests directory of: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ -- Damien
