Re: [PATCH] drm: fix i_mapping and f_mapping initialization indrm_open in error path

[Alex Deucher]

On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
<ihadzic@xxxxxxxxxxxxxxxxxxxxxx> 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
> other bug had something to do with module removal/insertion?
>
> If it's the latter, then you may want to open another bug report here
> https://bugs.freedesktop.org/ (use DRI for product and pick DRM/radeon for
> component) and have this issue tracked and addressed separately.
>
> The divide error that your log shows apparently happens at this line
> inside r6xx_remap_render_backend:
>
> pipe_rb_ratio = rendering_pipe_num / req_rb_num;
>
> I would suspect that req_rb_num somehow evaluates to zero at the second
> modprobe. That variable seems to be the derived of the last three arguments
> to r6xx_remap_render_backend. If I look at the caller (evergreen_gpu_init)
> the arguments that have the play here are all derived from the GPU's
> hardware registers (or are the constant for a given GPU device). So I
> suspect that the GPU driver leaves some state in GPU at module removal that
> later bites you.

Newer kernels have a fix for this.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f689e3acbd2e48cc4101e0af454193f81af4baaf

Alex

>
> -- Ilija
>
> On Tue, 2 Apr 2013, Marco Munderloh wrote:
>
>> 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
>>
>> On 02.04.2013 13:23, Ilija Hadzic wrote:
>>>
>>>
>>> -- Ilija
>>>
>>> On Tue, Apr 2, 2013 at 6:36 AM, Marco Munderloh
>>> <munderl@xxxxxxxxxxxxxxxxxxx <mailto:munderl@xxxxxxxxxxxxxxxxxxx>> wrote:
>>>
>>>         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. However, I have still no clue
>>> why one of these makes
>>>     drm_open to fail. On rmmod radeon I get the following log messages.
>>> If don't know if the 'unpin not necessary' has anything to do with it.
>>>
>>>     [drm] radeon: finishing device.
>>>     radeon 0000:01:00.0: ffff88024e526c00 unpin not necessary
>>>     radeon 0000:01:00.0: ffff88024f2f6000 unpin not necessary
>>>     radeon 0000:01:00.0: ffff88024f2f6000 unpin not necessary
>>>     [TTM] Finalizing pool allocator
>>>     [TTM] Finalizing DMA pool allocator
>>>     [TTM] Zone  kernel: Used memory at exit: 0 kiB
>>>     [TTM] Zone   dma32: Used memory at exit: 0 kiB
>>>     [drm] radeon: ttm finalized
>>>     vga_switcheroo: disabled
>>>     [drm] Module unloaded
>>>
>>>     By the way, sometimes my r8169 ethernet controller does not survive
>>> suspend/hibernation (does not detect link). rmmod/modprobe helps. I don't
>>> know if this is related.
>>>
>>>
>>
>> --
>> Dipl.-Ing. Marco Munderloh             Mail: munderl@xxxxxxxxxxxxxxxxxxx
>> Institut für Informationsverarbeitung (TNT)     Phone: +49 511 762-19587
>> Leibniz Universitaet Hannover, Appelstr. 9a       Fax: +49 511 762- 5333
>> 30167 Hannover, Germany     Web: http://www.tnt.uni-hannover.de/~munderl
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/