Nouveau - May 2014 - [Bug 78543] New: NV28M running at 1/8th GPU clock when using nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=78543

          Priority: medium
            Bug ID: 78543
          Assignee: nouveau at lists.freedesktop.org
           Summary: NV28M running at 1/8th GPU clock when using nouveau
        QA Contact: xorg-team at lists.x.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: nv28m at freemail.hu
          Hardware: x86 (IA32)
            Status: NEW
           Version: 7.7 (2011)
         Component: Driver/nouveau
           Product: xorg

See https://bugs.freedesktop.org/show_bug.cgi?id=54700 some details. I've
opened this as the speed problem has nothing to do with the distortion, but
I've noticed it when debugging that problem. I've e-mailed two dumps for
that
thread for this machine.

In short nouveau is slow normally, unless I insert the nvidia module in one
kernel and kexec into another kernel. Then nouveau is fast until I suspend to
RAM. After resume it's slow again. And I can't fix it ;)

Long version:

I've played a bit with nvclock and found something interesting. When using
the
nvidia driver in X I get:

===============================-- General info --
Card:           nVidia Geforce 4 4000 GO
Architecture:   NV28 A2
PCI id:         0x286
NVPLL_COEFF=00010d01
m=1 n=13 p=1
GPU clock:      175.500 MHz
Bustype:        AGP

-- Memory info --
Amount:         32 MB
Type:           128 bit DDR
MPLL_COEFF=00001d02
m=2 n=29 p=0
Clock:          391.500 MHz

-- AGP info --
Status:         Enabled
Rate:           4X
AGP rates:      1X 2X 4X
Fast Writes:    Disabled
SBA:            Disabled

-- VideoBios information --
Version: 04.28.20.31
Signon message: NV28 P138 Mobile Reference VGA BIOS
===============================
When I switch to console, then it's:

===============================-- General info --
Card:           nVidia Geforce 4 4000 GO
Architecture:   NV28 A2
PCI id:         0x286
NVPLL_COEFF=00040d01
m=1 n=13 p=4
GPU clock:      21.937 MHz
Bustype:        AGP
===============================
When I do the same using nouveau in X (after nvidia kexec):

===============================-- General info --
Card:         nVidia Geforce 4 4000 GO
Architecture:     NV28 A2
PCI id:     0x286
NVPLL_COEFF=00040d01
m=1 n=13 p=4
GPU clock:     21.937 MHz
Bustype:     AGP

-- Memory info --
Amount:     32 MB
Type:         128 bit DDR
MPLL_COEFF=00000f01
m=1 n=15 p=0
Clock:         405.000 MHz

-- AGP info --
Status:     Enabled
Rate:         4X
AGP rates:     1X 2X 4X 
Fast Writes:     Enabled
SBA:         Enabled

-- VideoBios information --
Version: 04.28.20.31
Signon message: NV28 P138 Mobile Reference VGA BIOS
===============================
Nouveau on console (after nvidia kexec):

===============================-- General info --
Card:           nVidia Geforce 4 4000 GO
Architecture:   NV28 A2
PCI id:         0x286
NVPLL_COEFF=00010d01
m=1 n=13 p=1
GPU clock:      175.500 MHz
Bustype:        AGP
===============================
And what is interesting if I do a "nvclock -i -d | cat" on console
then it's:

===============================-- General info --
Card:         nVidia Geforce 4 4000 GO
Architecture:     NV28 A2
PCI id:     0x286
NVPLL_COEFF=00040d01
m=1 n=13 p=4
GPU clock:     21.937 MHz
Bustype:     AGP
===============================
There's no difference with nvidia between redirecting to file or not.

The POST values are 175 MHz GPU and 405 MHz RAM (same as nouveau console).
I've
checked the nvidia dump I've made, it's set up to 100 MHz GPU and 199
MHz RAM,
but for some reason that's not the speed it's actually reported later
(see
above, 175/391).

When I do a suspend to RAM then I get 22 MHz GPU consistently on console and X
with nouveau, independent of redirecting or not. I guess that the 22 MHz in X
after nvidia kexec is probably false and it's more like 175 MHz as on
console
without redirection.

If I directly poke the PLL and read it back then it's not the same. It's
always
1/8 of what was requested (actually +3). When I change it on nvidia it's the
same as what I write there. Also after nvidia kexec, on the nouveau console
it's matching. But not after a suspend to RAM or otherwise. The same 1/8 is
there in X when nouveau is running fast after kexec.

Any ideas what is causing this 1/8 speed limit sometimes? Or why it's
different
if I redirect/not with nouveau?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140510/c2d82215/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=78543

--- Comment #1 from nv28m <nv28m at freemail.hu> ---
Sorry, it ended up duplicated somehow ;(

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140510/5db68a56/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=78543

--- Comment #2 from nv28m <nv28m at freemail.hu> ---
I've made more testing. It looks like the modesetting driver is unaffected
of
GPU performance and because of this it's running better when the GPU is in
slow
mode.

I've tried nouveau with noaccel, this smoothed scrolling (when the GPU is
running slow), but other 2D operations were still slower than with the
modesetting driver.

So, going with the modesetting driver is not a bad option at this time (as I
don't use much 3D), but it lacks XV support ;( It would be nice to fix this
slow GPU problem somehow and then I could use nouveau.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140510/e31e2ed6/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=78543

--- Comment #3 from Martin Peres <martin.peres at ensi-bourges.fr> ---
*** Bug 78544 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140526/a039fa9a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=78543

Martin Peres <martin.peres at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|NEW                         |RESOLVED

--- Comment #4 from Martin Peres <martin.peres at free.fr> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/107.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20191204/51821743/attachment.html>