[Nouveau] BIG changes to kernel module

[Maarten Maathuis]

On Mon, Aug 6, 2012 at 8:58 AM, Ben Skeggs <skeggsb at gmail.com> wrote:
> On Sun, Aug 05, 2012 at 10:56:37PM +0200, Marcin Slusarz wrote:
>> On Sun, Aug 05, 2012 at 12:40:15PM +1000, Ben Skeggs wrote:
>> > Hey all,
>> >
>> > I've just pushed a major rework/rewrite of the Nouveau kernel module to git[1].
>> >
>> > Details of the whys and what-nots of the rework are in the various commit
>> > messages.  At this point don't expect any exciting cool functionality, the
>> > work so far is merely a restructure to allow moving forward on a number
>> > of fronts in the future.
>> >
>> > I expect that for a while there will be a *lot* of stupid typos/thinkos that
>> > cause all sorts of breakage, so please test everything any anything you can
>> > and report *regressions* from the pre-rework code (vs 3.6-rc1 for example).
>> >
>> > I'll endeavour to hunt down and fix the regressions as quickly as possible, so
>> > please report any issues to this list and/or the freedesktop bugzilla.
>> >
>> > There's two areas that didn't get "properly" ported over, that is PM-related
>> > things and modesetting.  I'll be handling the modesetting and clk/volt reworks
>> > starting from nowish (in between fixing regressions), and I suspect Martin
>> > will handle the rest of the PM bits (therm and fanctrl) since he knows the
>> > design he's going for there.
>> >
>> > One thing to note is that some kernel module options have changed now, the
>> > more important ones are:
>> >
>> > nouveau.vbios=<blah> -> nouveau.config=NvBIOS=<blah>
>> > nouveau.noaccel=<bool> -> nouveau.config=PGRAPH=<bool>
>> >
>> > Multiple options are specified like:
>> >
>> > nouveau.config=NvBIOS=ACPI,PGRAPH=1
>> >
>> > The nouveau.noaccel option now controls acceleration enable/disable for the
>> > DRM's own GPU usage, and for the "abi16" (the new interfaces aren't even
>> > exposed to userspace yet) interfaces.
>> >
>> > The DRM debugging options (drm.debug=<bitfield>) now only effect the DRM
>> > specific parts of the nouveau module.  To enable additional debugging etc
>> > for the core, incantations like the following are used now:
>> >
>> > for debug output
>> >
>> > nouveau.debug=debug
>> >
>> > or for even more verbose debug output
>> >
>> > nouveau.debug=trace
>> >
>> > or for trace output for everything, and register write logging from POST
>> >
>> > nouveau.debug=trace,DEVINIT=spam
>> >
>> > Each individual subdev/engine module has its own debug level that can
>> > override the master debug level.
>>
>> It would be very helpful to document this convention and all options in some
>> text file in-tree (and later update it when things change).
> Yes, good point.  I'll see to that before any of this hits Linus'.
>
>>
>> Some things I noticed:
>> - corruptions / lockups in Warsow (1.0) on one of the bomb maps (I didn't test
>>   too much, so it might happen on others too) - initially bisected to
>>   "drm/nouveau/instmem: completely new implementation, as a subdev module",
>>   but I'm not so sure about it - with this commit most textures are corrupted
>>   and there are PGRAPH_TRAP_MP_EXEC errors in dmesg, but on HEAD I see total
>>   mayhem with DATA_ERROR, followed by TRAP_MP_EXEC and endless stream of page
>>   faults
>> - new lockups triggerable by piglit
>> - VRAM leak? (probably triggered by piglit)
> I'll see if I can reproduce these at all during the week.
>
>> - missing channel id in error messages
> This is actually deliberate, since technically the channel address *is* the
> chid on most engines.  PFIFO errors still log the chid, because there are
> actually indices there.
>
> I do see how it can be useful to have the PFIFO channel ID too though in
> error messages, so I'll bring them back.
>
>> - debugfs removed (not advertised in any commit, so I don't know if it's
>>   intentional or not)
> Oops, that *was* a separate commit at some point.  Might have accidentally
> squashed it.  It's intentional for now, it'll come back (better) later.
>
>> - some leftovers:
>>   - XXX_THIS_IS_A_HACK
>>   - /* yell very loudly!! */ (no code implementing yelling ;)
> Oops, thanks.  I've fixed both of these and I'll push them shortly.
>
> Thanks a LOT for looking this over for me.
>
> Cheers,
> Ben.
>
>>
>> Marcin
> _______________________________________________
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

I've also noticed some problems with huge lag in freespace 2 open, i
see this in dmesg:

[111545.883979] nouveau E[     DRM][0000:01:00.0] nv50cal_space: -16

I can't find anything obviously wrong with the code checking that we
haven't locked up, but that doesn't mean you shouldn't check it :-)

Note that in the past there were always scenes that were a bit laggy,
but these things are almost like temporary lockups.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.