05:27storrgie: airlied, i'd love to hear if that can happen
05:27storrgie: I'm going to begin the process of pushing these back to Lenovo and looking to replace them with T550
05:28storrgie: there is a bit of a pain on the memory limitations (16) of the T550, but the W541 is pretty much unusable right now
05:28imirkin: storrgie: chances are if you disable the intel chip in the bios, the nvidia one won't come up in such a bad state
05:29imirkin: obviously that'll negatively affect battery life
06:50storrgie: imirkin, there is no hwmux available anymore on the newer thinkpads
06:50storrgie: i think the intel is working all the time, and the nvidia writes into the intel framebuffer
07:14imirkin: storrgie: ok. double-check the bios to see if there's a disable. oftentimes there is a way to disable the igpu even in optimus setups.
07:15imirkin: storrgie: if none of the screens are attached to the nvidia device and nouveau is acting up, you can also boot with nouveau.modeset=0
07:15imirkin: which will leave the intel driver alone, but disable nouveau
07:23storrgie: imirkin, if I do that though, the nvidia device will still be on right?
07:23storrgie: I didn't think to try nouveau.modeset=0
07:23storrgie: the main thing im worried about now is battery life if I do get the W541 to work
07:24storrgie: The majority of my life is spent in firefox/sublime/terminal
07:24storrgie: I don't need the discrete adapter, we just bought these so the windows people can use the discrete adapters
07:26imirkin: storrgie: yes, but you can use something like bumblebee or a naked acpi_call to turn it off
07:37storrgie: so boot with nouveau.modeset = 0, then get bumblebee installed and use it to disable the nvidia adapter?
10:29storrgie: imirkin, is it best to use bumblebee to turn it off, or just use an acpi call someplace in a config file?
10:29imirkin_: i'd just do the acpi call
10:30imirkin_: bumblebee is tons of functionality which actively interferes with other things
10:30storrgie: where can I find documentation for this?
10:30storrgie: for the acpi call
10:30imirkin_: given their constraints, of wanting it to work with the blob, it's not a bad approach
10:30imirkin_: mmmm.... echo something > somewhere/acpi_call iirc
10:31storrgie: im not sure what the actuall acpi command is though, I'm wondering if any of this is documented by nouveau?
10:32imirkin_: i guess acpi_call might be out-of-tree as well
10:32imirkin_: documentation is pretty scant
10:33imirkin_: you can glance at what nouveau_acpi.c does
10:34imirkin_: i guess it's not super-easy to follow
10:34imirkin_: the main logic is in nouveau_dsm()
10:35storrgie: I'm not sure I'm prepared to fart around with that, maybe I should consider installing bbswitch
10:38storrgie: I want to say, even if I get this working on pure intel. I think that the external graphics ports only work with nvidia
10:39storrgie: imirkin_, where can I add the nouveau.modeset = 0 so that I don't have to add it at boot time each time?
10:39imirkin_: dunno, depends on the distro. ask in a distro support channel?
10:39imirkin_: on my system, /boot/grub/menu.lst
10:40imirkin_: actually that's not even true, i'm on an efi system now. i have to re-remember how i set it up
10:41imirkin_: if the ports are hard-wired to the nvidia card you're sol...
10:41imirkin_: you COULD also try booting with nouveau.noaccel=1
10:42imirkin_: that will disable any attempts at acceleration while leaving modesetting enabled
10:42imirkin_: which should let you use the displays attached to the nvidia card
10:42storrgie: would I get screentearing?
10:42storrgie: I dont think the 106 works well at all on nouveau
10:42imirkin_: i would assume so
10:42storrgie: every time it boots, it says llvmpipe
10:42imirkin_: GK106 works fine
10:43imirkin_: some laptops come with vbios's that initialize them into some super-powered-off state
10:43imirkin_: that we can't recover them from
10:44imirkin_: we were given instructions by nvidia on how to do it, but it appears insufficient
10:44imirkin_: or we suck at implementing those instructions
10:46storrgie: sorry, this is likely distro specific
10:46storrgie: but I have found the entry in /etc/default/grub
10:46storrgie: added nouveau.modeset=0
10:46storrgie: but this is UEFI, so I don't know how to regen the config in a way that is usable
10:47imirkin_: ask in your distro's support channel :)
10:47imirkin_: i was advised to use gummiboot with uefi, and so i did
10:47imirkin_: works great except if the keyboard is attached to the monitor which is attached to the computer
10:47imirkin_: then it freaks out *bigtime*
10:48imirkin_: (or rather, i'm guessing it gets freaked out by usb plug/unplug events)
10:51imirkin_: [and iirc gummiboot reads the config files in the uefi boot partition directly]
10:52storrgie: I'm reading this, but I don't quite grasp it
10:53storrgie: I don't know if I need to do anything beyond update the /etc/default/grub file
10:53imirkin_: ahahahha, grub2. good luck.
10:53imirkin_: my main requirement when i was figuring out the uefi boot situation was "not grub2" :)
10:55mjg59: It's the only choice if you want to deal with secure boot
10:55mjg59: So it's going to be distro default in most places
10:56imirkin_: mjg59: some day i'll figure out wtf secure boot is, but the day i was setting up my box wasn't the day for it.
10:56imirkin_: i actually started out with uefi loading my kernel directly :) gummiboot was v2
11:14storrgie: imirkin_, once I get bumblebee and bumblebee-nvidia installed, should I remove the nouveau.modeset=0 from the args?
11:14imirkin_: dunno what bumblebee-nvidia is...
11:14imirkin_: if you're using the blob driver, you should definitely still disable nouveau
11:14imirkin_: did you give the noaccel option a shot?
11:15imirkin_: i.e. forget about bumblebee, and just boot with nouveau.noaccel=1
11:15storrgie: but really, I want to have that nvidia chip off
11:15storrgie: i dont want it sapping the power of the system
11:15imirkin_: nouveau will turn it off
11:15imirkin_: when it's not in use
11:15imirkin_: and you'd still be able to use external monitors
11:15imirkin_: (that are hooked up to the nvidia gpu directly)
11:15storrgie: is there a command I can run right now to see if the chip is on or off?
11:16imirkin_: if you're using bumblebee, check the bumblebee docs
11:17storrgie: are you sure nouveau works on the GK106GLM? I thought for sure it didnt
11:18imirkin_: it has nothing to do with the chip
11:18imirkin_: it has everything to do with the vbios
11:18imirkin_: from the sounds of it, we can't bring up the engine which powers accelerated drawing functions on your card
11:19imirkin_: however nouveau.noaccel=1 should prevent it from being used
11:45storrgie: imirkin_, lots of fan noise with nouveau.noaccel=1, also I don't get the graphical luks prompt anymore
11:46imirkin_: i wonder what the diff is.
11:46imirkin_: probably some userspace oddity
11:46storrgie: im doing a fresh install of F22 now
11:50storrgie: imirkin_, i dont know why its doing it
11:51storrgie: i just did that cat /sys/kernel/debug/vgaswitcheroo/switch and see that the DIS is dynoff
11:51imirkin_: that means that nouveau has powered off the nvidia gpu
11:51imirkin_: (or at least thinks it has)
11:52storrgie: so why use nouveau.noaccell instead of just turning nouveau off?
11:53storrgie: can i check from another method to see if the gpu is on or off?
11:53imirkin_: because then you (a) have to use bbswitch to disable the gpu and (b) if any external ports are connected to the nvidia gpu, you won't be able to use them
11:54storrgie: yeah the fan is still running around 100%
11:54storrgie: and the chassis is hot
11:54imirkin_: check top to see if something spinning?
12:39voxadam: I'm still trying to track down the source of the GPU lockups on my x86_64 system with a 550 Ti (NVCE/GF114). I rarely see anything in dmesg/journald, the graphics simply lock. I'm able to ssh in and non-GPU related services keep running fine. Aside from switching to the binary driver or buying a Radeon what can I do to debug this? I've been running Fedora's 4.0.0-rcX, 4.0.0 release, and most recently a
12:39voxadam: vanila RPM (http://j.mp/1JhBqTB) but I'm still seeing lockups.
12:39voxadam: Oops. Sorry for the novel. I get carried away sometimes.
12:39imirkin_: you mentioned this was a recent issue
12:39imirkin_: you could bisect it
12:40voxadam: I was hoping you weren't going to say that.
12:40imirkin_: it's the all-purpose "let's figure out wtf happened" tool
12:40imirkin_: it does require that you have a way of reproducing the issue
12:40imirkin_: you mentioned that the KDE compositor was a lot better at triggering it though...
12:40voxadam: KDE/Qt is pretty good at that.
12:41voxadam: I've never had the pleasure of bisecting a modern kernel. Are there any good docs related to Nouveau?
12:42imirkin_: nouveau is in the kernel... so it's no different than any other bisect
12:42imirkin_: you can restrict it to drivers/gpu/drm/nouveau
12:42imirkin_: which should cut down the bisect time substantially
12:42voxadam: Sounds like I'm not going to the pub tonight?
12:43voxadam: My other half will be pleased.
17:21voxadam: imirkin: Any thoughts on the messages captured durring a crash I just had? https://gist.github.com/voxadam/ace978ad6e261a18dcb7
17:23imirkin: voxadam: downgrade libdrm to 2.4.59
17:23imirkin: you have 2.4.60 i bet, right?
17:23imirkin: skeggsb_: should we just roll back mlankhorst's patch or do you have time to figure out wtf is going on? he can't look at it right now.
17:23voxadam: Yep. I'll downgrade.
17:24voxadam: Could this be causing my lockups, some or all?
17:24imirkin: (and i have no idea where to start to diagnose it... all the traces i've seen suggest that there's no duplication going on but the kernel complains, perhaps it's hidden via shared buffers... dunno)
17:25imirkin: voxadam: wouldn't cause lockups, but who knows, the screen could stop updating
17:25voxadam: That's what happened. I was able to change to a VC just fine.
17:25voxadam: I was even able to kill my DM. Though, when I tried to restart it the system rebooted.
17:26imirkin: dunno about system rebooting
17:26imirkin: this is a purely userspace-level fail though
17:26imirkin: mesa doesn't really expect this condition to ever happen, and so it's handled extremely poorly by the driver
17:26voxadam: Well, I'll try downgrading libdrm.
17:26imirkin: so i could imagine it would just mess up in various ways