Message-ID: <CADnq5_O7T83MC9HFyVow1j4V6=nLR9cd+OfWs1=fpD24sADUbg@mail.gmail.com>
Date:	Tue, 2 Apr 2013 09:48:38 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Ilija Hadzic <ihadzic@...earch.bell-labs.com>
Cc:	Marco Munderloh <munderl@....uni-hannover.de>,
	Michal Hocko <mhocko@...e.cz>,
	Thomas Hellstrom <thellstrom@...are.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm: fix i_mapping and f_mapping initialization in
 drm_open in error path

On Tue, Apr 2, 2013 at 9:31 AM, Ilija Hadzic
<ihadzic@...earch.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 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@....uni-hannover.de <mailto:munderl@....uni-hannover.de>> 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@....uni-hannover.de
>> 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@...ts.freedesktop.org
> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists