Hi, On 24-07-15 04:32, Ben Skeggs wrote: > On 24 July 2015 at 01:20, Hans de Goede <hdegoede at redhat.com> wrote: >> MSI interrupts appear to not work for nv46 based cards. Change the mc >> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is >> identical to the nv44 mc code except that it does not use msi >> (it does not define a msi_rearm callback). > I'm fine with this, but it'd be nice to check that the binary driver > doesn't/can't use MSI on these too (there might be an alternate method > we need to use). > > Would you be able to grab the latest proprietary driver that works on > nv4x, and do a mmiotrace of it?
I've grabbed 304.125 > You *might* need to use "modprobe > nvidia NVreg_EnableMSI=1", because at some point NVIDIA didn't use it > by default anywhere. You're right I needed to specify NVreg_EnableMSI=1, with that set /proc/interrupts shows that MSI is used. Here is an of running glxgears with the binary driver using msi interrupts mmiotrace: https://fedorapeople.org/~jwrdegoede/nvidia-bin-nv46-msi-on-glxgears.mmiotrace.gz AFAIK there are some nouveau tools to parse this a bit, right ? I'm going to call it a day for today, if you can give me some pointers what to do with the mmiotrace to find a potential fix for the msi issues, that would be appreciated. BTW I had to build my own kernel with mmiotrace enabled in Kconfig, as this is disabled in the Fedora kernels by default. Do you know if there is a good reason to have this disabled by default, or should I ask the Fedora kernel maintainers to enable it by default ? Slightly offtopic: I decided to be bold and try gnome-shell on the nv46 with msi disabled, which sofar was a guaranteed way to freeze the system, and it now works somewhat (latest kernel, ddx and mesa). I see something which shows horizontal lines which are small parts from my desktop background, and things change significantly when I switch to the overview mode. But other then that the display is completely wrong, it looks a bit like a framebuffer pitch problem, but then different. I think it is likely some tiling problem or some such. Note that metacity + glxgears works, this only shows with gnome-shell, any hints where to start looking wrt debugging this? Or should I first try to run piglet and see if some tests there point out the culprit? Regards, Hans > > Thanks, > Ben. > >> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=90435 >> Signed-off-by: Hans de Goede <hdegoede at redhat.com> >> --- >> drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c >> b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c >> index c630136..b4ad791 100644 >> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c >> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/nv40.c >> @@ -265,7 +265,7 @@ nv40_identify(struct nvkm_device *device) >> device->oclass[NVDEV_SUBDEV_CLK ] = &nv40_clk_oclass; >> device->oclass[NVDEV_SUBDEV_THERM ] = &nv40_therm_oclass; >> device->oclass[NVDEV_SUBDEV_DEVINIT] = nv1a_devinit_oclass; >> - device->oclass[NVDEV_SUBDEV_MC ] = nv44_mc_oclass; >> + device->oclass[NVDEV_SUBDEV_MC ] = nv4c_mc_oclass; >> device->oclass[NVDEV_SUBDEV_BUS ] = nv31_bus_oclass; >> device->oclass[NVDEV_SUBDEV_TIMER ] = &nv04_timer_oclass; >> device->oclass[NVDEV_SUBDEV_FB ] = nv46_fb_oclass; >> -- >> 2.4.3 >> >> _______________________________________________ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau