[Nix-dev] Experiences with Nvidia Optimus?

[Mathijs Kwik]

On Sun, Feb 5, 2012 at 11:26 AM, Arie Middelkoop <amiddelk at gmail.com> wrote:
> On 05-02-12 09:16, Mathijs Kwik wrote:
>>
>> On Sun, Feb 5, 2012 at 2:11 AM, Arie Middelkoop<amiddelk at gmail.com>
>>  wrote:
>
>
>>> The main advantage of the package actually arises when you don't use the
>>> card: it uses ACPI to shutdown the card, which - depending on what card
>>> you
>>> have - saves quite a bit of energy / heat.
>>> (also available as separate kernel module)
>>
>>
>> I haven't looked at bumblebee yet, your comments seem to indicate I
>> don't need it if I just load bbswitch and discrete_vga_poweroff on
>> startup.
>> Or is it any use besides that yet?
>
>
> I'm not entirely sure. I've used bbswitch at startup for a week. With a
> modprobe option, you can tell it to shutdown the card directly when the
> module is loaded, but that didn't work very well (maybe because some
> subsystem first had to be initialized or so). It did work to turn off the
> card using a job just after udev.
>
> I read somewhere that you should also turn on the card on shutdown. I didn't
> do that, and so far, I had only one hard lockup on shutdown, but that may be
> unrelated.
>
> Anyway, if you run the bumblebeed daemon, it takes care of this. It also
> unloads the nvidia module before shutting down the card (and actuall
> requires the nvidia module to be loaded on startup), and saves/restores 'the
> pci configuration space' (whatever that is). Anyway, that seems to work
> fine, but it's ofc a bit overkill to have a process running for only this
> purpose.

Yeah, an upstart job (task) works fine for now.
I don't switch the card on on shutdown.
Tried a few reboots, no issues.
So I'll leave it at this for now.

>
> For the near future, I've heard that the bbswitch module has been ported to
> the nouveau driver as part of switcheroo. That would be a more cleaner
> solution, although I'd not bother with it now.
>
>
>> I haven't used any non-kernel-provided modules on nixos before.
>> I now have this in configuration.nix:
>>
>> boot = {
>>   kernelPackages = pkgs.linuxPackages_3_2;
>>   extraModulePackages = [ config.boot.kernelPackages.bbswitch ];
>>   kernelModules = ["acpi-cpufreq" "kvm-intel" "bbswitch"];
>> };
>>
>> That takes care of loading the module itself.
>
>
> Yes, that corresponds exactly to what I'm having.
>
>
>> But I need to put config.boot.kernelPackages.bbswitch in
>> systemPackages too, to get the discrete_vga* helpers.
>> Is this how it's supposed to work?
>
>
> That'd work I guess. I simply put the one "echo" line of the helper into an
> upstart job (with 'task = true;' so that it only runs it once).
> Unfortunately, I deleted it from my configuration.nix, but it should be easy
> to reproduce.
>
>
>> Oh and slightly offtopic: I found the intel microcode package you
>> provided but I can't find out if it works.
>> Without it, modprobe microcode (the microcode loader) produces the
>> same dmesg output as with microcodeIntel included in
>> hardware.firmware.
>> No indication of it finding the .dat file, or using it (or skipping
>> because not applicable to my cpu).
>> How can I find out if it's any use?
>
>
> Sorry, this was exactly the issue that I wanted to investigate somewhere
> today. Some documentation seemed to suggest that the .dat file just has to
> be put in the firmware, and the module loaded. The sourcecode of the
> 'microcode' module seems to suggest something different actually. My guess
> is that some userspace tool needs to be involved or so.

That's how I remember it, but last time I used it was around 2002 or
earlier on debian.
I needed to load the kernel module and then a userspace tool could
update the microcode.

I haven't seen (or needed) microcode related stuff since then, but I
got curious after your commit.

A quick look at archlinux gives:
http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/intel-ucode

In other words: you are right, no tool is needed any longer, but you
need to convert the .dat file into some more generic format.
Tool is given there.

>
> Anyway, I'm not sure whether the microcode is of any use in the first place.
> My kernel log seems to suggest that it may be relevant for me, but I don't
> think it's important. Also, it may very well be that the bios already
> updates the microcode.

My i7 mobile cpu is listed at intel's page, but they don't give any
details about the contents.
So whether or not any useful fixes are included, at least it won't
hurt/break stuff.

>
> Then again, I experienced quite some instabilities with my new laptop, so I
> should probably check these things. So far, using the latest 3.2 kernel
> already helped a great deal.
>
> Arie