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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

-- 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

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux