Attached is a v2 of the patch, for reference. I would appreciate if the
original reporter or you tested it in lieu of your proposed patch and let me
know if it fixes your
issue.
The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as rmmod radeon do not end up in a crash anymore.
Hi Ilija,
Thanks for testing. Other issues are probably unrelated, so I'll send the last
version of the patch to Dave.
I came across another problem which seems related. rmmod radeon works, however,
modprobe radeon afterwards results in a crash (divide error), see attachment.
Best, Marco
O
Hi Ilija,
> Thanks for testing. Other issues are probably unrelated, so I'll send the
> last version of the patch to Dave.
I came across another problem which seems related. rmmod radeon works, however,
modprobe radeon afterwards results in a crash (divide error), see attachment.
Best, Marco
> Attached is a v2 of the patch, for reference. I would appreciate if the
> original reporter or you tested it in lieu of your proposed patch and let me
> know if it fixes your
> issue.
The patch works for me. echo 3 > /proc/sys/vm/drop_caches as well as rmmod
radeon do not end up in a crash an
On Mon 01-04-13 13:14:50, Ilija Hadzic wrote:
>
>
> On Sun, 31 Mar 2013, Michal Hocko wrote:
>
> >On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> >>This looks a bit like a hack and it doesn't look right,
> >>conceptually. If the call fails, it should restore things as if
> >>nothing has ever hap
On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
wrote:
>
> Marco,
>
> What makes you think that the crash after second modprobe is related to the
> mappings pointers in DRM module? Can you actually establish the correlation
> between these patches and the crash or you are just suspecting because your
Marco,
What makes you think that the crash after second modprobe is related to
the mappings pointers in DRM module? Can you actually establish the
correlation between these patches and the crash or you are just suspecting
because your other bug had something to do with module removal/insertion
Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.
-- Ilija
On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh wrote:
> Attached is a v2 of the patch, for reference. I would appreciate if the
>> original reporter or you tested it in lieu of
On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
wrote:
>
> Marco,
>
> What makes you think that the crash after second modprobe is related to the
> mappings pointers in DRM module? Can you actually establish the correlation
> between these patches and the crash or you are just suspecting because your
Marco,
What makes you think that the crash after second modprobe is related to
the mappings pointers in DRM module? Can you actually establish the
correlation between these patches and the crash or you are just suspecting
because your other bug had something to do with module removal/insertio
Thanks for testing. Other issues are probably unrelated, so I'll send the
last version of the patch to Dave.
-- Ilija
On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh wrote:
> Attached is a v2 of the patch, for reference. I would appreciate if the
>> original reporter or you tested it in lieu of
On Mon 01-04-13 13:14:50, Ilija Hadzic wrote:
>
>
> On Sun, 31 Mar 2013, Michal Hocko wrote:
>
> >On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> >>This looks a bit like a hack and it doesn't look right,
> >>conceptually. If the call fails, it should restore things as if
> >>nothing has ever hap
On Sun, 31 Mar 2013, Michal Hocko wrote:
> On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
>> This looks a bit like a hack and it doesn't look right,
>> conceptually. If the call fails, it should restore things as if
>> nothing has ever happened and overwriting old_mapping is not going to
>> do th
On Sun, 31 Mar 2013, Michal Hocko wrote:
On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
This looks a bit like a hack and it doesn't look right,
conceptually. If the call fails, it should restore things as if
nothing has ever happened and overwriting old_mapping is not going to
do the trick.
On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> This looks a bit like a hack and it doesn't look right,
> conceptually. If the call fails, it should restore things as if
> nothing has ever happened and overwriting old_mapping is not going to
> do the trick.
OK, I thought this is what the patch doe
On Sat 30-03-13 18:26:53, Ilija Hadzic wrote:
> This looks a bit like a hack and it doesn't look right,
> conceptually. If the call fails, it should restore things as if
> nothing has ever happened and overwriting old_mapping is not going to
> do the trick.
OK, I thought this is what the patch doe
17 00:00:00 2001
> From: Michal Hocko
> Date: Tue, 26 Mar 2013 19:04:40 +0100
> Subject: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open
> in error path
>
> Starting with fdb40a08 (drm: set dev_mapping before calling
> drm_open_helper) inode and file mappings
17 00:00:00 2001
> From: Michal Hocko
> Date: Tue, 26 Mar 2013 19:04:40 +0100
> Subject: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open
> in error path
>
> Starting with fdb40a08 (drm: set dev_mapping before calling
> drm_open_helper) inode and file mappings
Hi,
the patch bellow fixes a nullptr dereference reported with OpenSUSE12.3.
I am not familiar with the area so I have no idea whether this is the
right way to go but after applying this patch the problem is not
reproducible anymore.
If the patch is correct then please mark it for stable (3.7+).
T
Starting with fdb40a08 (drm: set dev_mapping before calling
drm_open_helper) inode and file mappings are set to old_mapping in the
error path. old_mapping can be NULL, however, which is handled by
initializing dev_mapping to default inode->i_data. old_mapping is left
intact though so the both inode
+).
Thanks!
---
>From a786a701bd6c277329e2b788fea9a69b1c3ced2e Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Tue, 26 Mar 2013 19:04:40 +0100
Subject: [PATCH] drm: fix i_mapping and f_mapping initialization in drm_open
in error path
Starting with fdb40a08 (drm: set dev_mapping before call
21 matches
Mail list logo
