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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
