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
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
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
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
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
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 happened and
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 mund...@tnt.uni-hannover.de
wrote:
Attached is a v2 of the patch, for reference. I would appreciate if the
original reporter
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
On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
ihad...@research.bell-labs.com 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
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 anymore.
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
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
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 does
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.
I think the right way to fix it would be to separately store the
original mapping for
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.
I think the right way to fix it would be to separately store the
original mapping for
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+).
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
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+).
21 matches
Mail list logo
