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
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
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 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 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
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
filp->f_
8 matches
Mail list logo