Bug 90435

While the nv30 gallium driver is far from perfect, I'm fairly sure that glxgears is supposed to work. Can you try older mesa versions to see if they work? Like 10.4, 10.3, etc.

The only thing that comes to mind is a change I added to avoid color/depth size conflicts (the hw can only do 32-bit color with 24-bit depth, or 16-bit color with 16-bit depth). Ideally the driver would create a shadow version, but my change was just enough to avoid faults, I just don't set a depth buffer at all during the render in such cases.

(In reply to Ilia Mirkin from comment #1)
> While the nv30 gallium driver is far from perfect, I'm fairly sure that
> glxgears is supposed to work. Can you try older mesa versions to see if they
> work? Like 10.4, 10.3, etc.
> 
I dont't think, it will change the behavior. I also tried nouveau 9-12 month ago, effects was the same.

OK, well at one point or another (like mesa 10.0), glxgears definitely worked on my NV43 and NV44 (which cover both 3d classes available in the nv4x family). Could be that there's something funky about NV46 specifically, or worse, something funky about *your* nv46.

(In reply to Ilia Mirkin from comment #3)
> OK, well at one point or another (like mesa 10.0), glxgears definitely
> worked on my NV43 and NV44 (which cover both 3d classes available in the
> nv4x family). Could be that there's something funky about NV46 specifically,
> or worse, something funky about *your* nv46.

So, I tried Mesa 10.4 - same behaviour. Then I tried Mesa 10.0 - glxgears works! But then I tried to start my simple program - and I catch a hangup fo X-server.

program code (shadow.c) is in attach.

Created attachment 115854 [details]
shadow.c

What I not changed - is the kernel driver nouveau. It was the last version from the kernel...

Hi Ilya,

(In reply to Ilya from comment #6)
> What I not changed - is the kernel driver nouveau. It was the last version
> from the kernel...

I've tried to reproduce your problem and 10.4 (and newer) for me only show a black window with glxgears, not even a static picture.

Then I tried 10.0.0 as you said that works, but that does not work for me either. Are you sure you're using nouveau_dri and not llvmpipe in your 10.0.0 build ? Can you run glxinfo in the working build please?

Regards,

Hans

(In reply to Hans de Goede from comment #7)
> Hi Ilya,
> 
> (In reply to Ilya from comment #6)
> > What I not changed - is the kernel driver nouveau. It was the last version
> > from the kernel...
> 
> I've tried to reproduce your problem and 10.4 (and newer) for me only show a
> black window with glxgears, not even a static picture.

OK, 2 people telling me that the whole everything is broken... probably time to plug in my NV44 and see what's is going on.

Hans, can you confirm which HW you were using to reproduce this? Did you get your hands on an actual NV46, same as the OP? PCIe, I presume?

OK, so I just plugged in a

04:00.0 VGA compatible controller: NVIDIA Corporation NV44 [GeForce 6200 TurboCache] (rev a1)

and ran:

X -config /etc/X11/xorg-nv44.conf -sharevts -novtswitch :1
DISPLAY=:1 glxgears

And glxgears showed up just fine on the S-Video output with mesa 10.5.4.

The shadow.c application does start out by working, but eventually appears to stop. [hmmm... and it appears to have hung that gpu on a restart.]

(In reply to Ilia Mirkin from comment #8)
> (In reply to Hans de Goede from comment #7)
> > Hi Ilya,
> > 
> > (In reply to Ilya from comment #6)
> > > What I not changed - is the kernel driver nouveau. It was the last version
> > > from the kernel...
> > 
> > I've tried to reproduce your problem and 10.4 (and newer) for me only show a
> > black window with glxgears, not even a static picture.
> 
> OK, 2 people telling me that the whole everything is broken... probably time
> to plug in my NV44 and see what's is going on.
> 
> Hans, can you confirm which HW you were using to reproduce this?

I'm using a Asus EN7300TC512

> Did you get your hands on an actual NV46, same as the OP? PCIe, I presume?

According to glxinfo it is a NV46, yes, and yes it is a PCIe card.

Hi all,

I've been looking into this toay, it seems that with the latest xf86-video-nouveau + latest mesa (both git master) I can reproduce the problem and work around it by starting glxgears like this:

"vblank_mode=0 glxgears"

I need this workaround on both mesa-10.0 and mesa-git-master, so it seems that whatever problem Ilya was original seeing has been fixed in mesa-git-master.

Ilya can you please try mesa-git-master and if that does not work (the vblank issue may be specific to my card), try it with: "vblank_mode=0 glxgears" ?

Downgrading xf86-video-nouveau to 1.0.10 fixes the vblank issue for me, a git bisect points to:
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=f0fa8313714c2a5b16e784b257b5ff79da3a443b

Which is a commit which enables sync-to-vblank by default and as such is not really useful, and the real problem lies elsewhere.

Suggestions how to further debug the vblank issue are welcome.

Regards,

Hans

(In reply to Hans de Goede from comment #11)
> Hi all,
> 
> I've been looking into this toay, it seems that with the latest
> xf86-video-nouveau + latest mesa (both git master) I can reproduce the
> problem and work around it by starting glxgears like this:
> 
> "vblank_mode=0 glxgears"
> 
> I need this workaround on both mesa-10.0 and mesa-git-master, so it seems
> that whatever problem Ilya was original seeing has been fixed in
> mesa-git-master.
> 
> Ilya can you please try mesa-git-master and if that does not work (the
> vblank issue may be specific to my card), try it with: "vblank_mode=0
> glxgears" ?
> 

I have not already tested git-version, but the mesa 10.5.5 from Arch the vblank_mode=0 works good for me. glxgears, lugaru, sauerbraten work fine (slow, but, it wokrs).

(In reply to Ilya from comment #12)
> (In reply to Hans de Goede from comment #11)
> > Hi all,
> > 
> > I've been looking into this toay, it seems that with the latest
> > xf86-video-nouveau + latest mesa (both git master) I can reproduce the
> > problem and work around it by starting glxgears like this:
> > 
> > "vblank_mode=0 glxgears"
> > 
> > I need this workaround on both mesa-10.0 and mesa-git-master, so it seems
> > that whatever problem Ilya was original seeing has been fixed in
> > mesa-git-master.
> > 
> > Ilya can you please try mesa-git-master and if that does not work (the
> > vblank issue may be specific to my card), try it with: "vblank_mode=0
> > glxgears" ?
> > 
> 
> I have not already tested git-version, but the mesa 10.5.5 from Arch the
> vblank_mode=0 works good for me. glxgears, lugaru, sauerbraten work fine
> (slow, but, it wokrs).

Great, thanks for testing, then it seems you've the same issue. I'll try to investigate this further Friday (tomorrow I've some other items I need to look into).

> Great, thanks for testing, then it seems you've the same issue. I'll try to
> investigate this further Friday (tomorrow I've some other items I need to
> look into).

Any news about it?

I seem to have the same problem with a G72GLM [Quadro FX 350M] using mesa 10.6.1 and nouveau 1.0.11 on an x86-64.

I disabled GLXVBlank as a temporary workaround:

Section "Device"
        Identifier "system-video"
        Option "GLXVBlank" "off"
EndSection

Since the issue at hand is interrupt delivery, has anyone tried doing

nouveau.config=NvMSI=0

Great. Using kernel parameter nouveau.config=NvMSI=0 did the trick!

Thanks.

Hi,

(In reply to Ilia Mirkin from comment #16)
> Since the issue at hand is interrupt delivery, has anyone tried doing
> 
> nouveau.config=NvMSI=0

Ah, good one. Yes that fixes things. Looking at other nv4x cards, it seems that we are not using MSI on the C51 / C61 /  C67 / C68 / C73 either, these all set the mc-subdev oclass to nv4c_mc_oclass which results in msi not being used. I've written (and tested) a patch to do the same for nv46. I'll attach that here and send it to the list.

Regards,

Hans

Created attachment 117321 [details] [review]
[PATCH] nouveau: nv46: Change mc subdev oclass from nv44 to nv4c

I discussed with Ben how to move forward with this, Ben agrees that the patch I attached to this bug report is the best way to move forward with this, and he will merge that into the nouveau kernel code.

FYI this bug also has some details about this same problem on nv46:
https://bugs.freedesktop.org/show_bug.cgi?id=78441

I found this comment interesting:
"OTOH, it's very interesting that you bisected it to that particular commit. It's not the commit that turns on MSI, but rather a commit that fixes MSI for some situations, making it more reliable. But apparently not for you..."