01:00mwk:wonders if the nv signing scheme actually prevents flashing custom firmware doing naughty things...
01:02imirkin: mangix: could you tell skeggsb a little more about your hardware on which you discovered an issue with the i2c-over-aux change?
01:03imirkin: skeggsb: btw, the other person who ran into issues did supply full traces as you had requested
01:07hobbs: is nouveau without ACPI impossible? I'm not talking "I booted with acpi=off", I'm talking "I have an AGP GeForce2 on a board from 1999 with no ACPI BIOS and I'd like to do something useful with it" :)
01:08imirkin: should be fine
01:08imirkin: are you running into issues with it?
01:08imirkin: i mean, don't expect it to run modern software with all the bells and whistles, but it should work just fine with recent kernel/xorg/mesa stack
01:13hobbs: nouveau.ko won't load, because it depends on button.ko and that fails loading with "no such device" when there's no ACPI
01:14imirkin: you know, that sounds MILDLY familiar
01:14airlied:wonders what you are meant to do in that situation
01:14imirkin: what kernel is this btw?
01:15hobbs: 3.16, debian
01:15imirkin: airlied: fix the button module so that it loads?
01:16airlied: imirkin: probably
01:16imirkin: hobbs: immediate fix is to build a kernel without acpi support... also check if this is still an issue in 4.12 -- 3.16 was released like 2-3 years ago
01:16imirkin: stuff can get fixed in a time period like that
01:17hobbs: okay. I'm going to have to figure out how to distcc or cross-build or whatever, because building 4.12 on that machine is bound to take a while
01:17hobbs: but I'll try
01:17mjg59: hobbs: There's newer kernels in debian-backports
01:18hobbs: I'll try that first
01:18hobbs: thanks for letting me know there's some hope :)
01:20imirkin: acpi_bus_register_driver -- that looks dodgy
01:23mangix: skeggsb: assuming you're here, it's a desktop GTX 980 in MXM form
01:23hobbs: looks like I can get to 4.9 on jessie
01:24imirkin: hobbs: well, just glancing at the latest kernel code, it's unclear that it'll help
01:24mangix: http://i.ebayimg.com/images/i/122300649942-0-1/s-l1000.jpg ah my oversized beauty
01:24hobbs: may as well find out
01:25hobbs: and honestly I understand that this is a slightly crazy desire :)
01:25imirkin: mangix: your ... precious?
01:27mangix: although if they introduce two volta MXM GPUs in SLI, I'm gone
01:29hobbs: imirkin: I do see where you're coming from though, a !CONFIG_ACPI build should stop it trying to reference any of that, hopefully?
01:29hobbs: that's plan Q, then
01:34imirkin: are you explicitly booting with 'acpi=off'?
01:34imirkin: or does the box just not have acpi?
01:35imirkin: 1999 was a bit of a while ago... i don't really remember what the deal was just then. i remember apm was a thing for laptops... acpi sounds like it was still some years in the future.
01:36hobbs: it just doesn't have it. I think ACPI existed at the time, but not for this board
01:41hobbs: or actually... okay, I'm dumb, thanks for helping :)
01:41hobbs: mjg59: turns out I can't use the backports kernel for the same reason I can't install stretch -- K6 is missing one of the instructions to qualify as "686"
01:42hobbs: imirkin: it turns out that when you go into the BIOS setup and change "ACPI Function" from "Disabled" to "Enabled", everything works great.
01:42hobbs: who knew? ;)
01:46gnarface: i'm pretty sure APM still works though
01:46gnarface: you might have to enable it manually these days
01:46hobbs: so consider my grumble registered that it's probably a tiny bit wrong that it breaks that way... but I don't actually have a problem anymore. X started without a hitch.
02:04hobbs: okay, not without a hitch, I've got a BUG() followed by a "GPU lockup" message. But since I'm running an ancient version I won't bother you with it unless you want me to :)
05:12imirkin: hobbs: yeah, better to update. i haven't ever tried nouveau with a nv11, but it has worked fine on nv5 and nv17. (pci though, never agp)
05:15hobbs: imirkin: I was compiling for an hour and it only built arch/ and most of kernel/, hadn't even started in on drivers/, so I decided to take a break for some taco bell and then install distcc :)
05:15imirkin: yeah. faster computers are faster.
05:15hobbs: um, wrong window :)
05:15imirkin: i ran on a tbird followed by a tbred for nearly 10y... was mostly ok.
05:18Hoolootwo: I think a long time ago I had it working on an nv17 or 18 agp card
05:18imirkin: it's not an often-tested scenario anymore
05:19imirkin: i remember idr had some issue with his nv20 though
05:19imirkin: ah yeah - probably this one: drm/nouveau/fifo/nv04: avoid ramht race against cookie insertion
06:00Tom^: dont you guys run out of ram on those old boxes? , seems nowadays everything eats it like its cookie dough
06:08hobbs: not as much as you'd think
06:10hobbs: yes, definitely more than it used to -- my first linux box had 12MB of RAM, and you can hardly run the kernel with that these days
06:10hobbs: but doing stuff that a machine of that age is capable of anyway, I usually have under 100MB used
06:19Tom^: im right now trying to figure out why X + window manager and three terminals is using 1.7gb of ram so
06:29hobbs: that doesn't include chrome, for instance, because chrome won't even run without SSE2 :)
06:48karolherbst: airlied: that vm scenario makes kind of sense, but is it really a good idea to share the same GPU between multiple vms, if security is important?
06:50mjg59: karolherbst: It doesn't need to be multiple simultaneous VMs
06:50mjg59: If there's nothing to reload the firmware, you have an attack vector that persists between one user leaving a machine and another picking it up
12:21imirkin: hobbs: iirc i had to resort to building chrome myself on that tbred box because of no sse2. painful.
12:21mwk: fun fact: if you run a program under valgrind, it'll supply the missing instructions...
12:22mwk:ran the nvidia libGL that way on a K6
12:22imirkin: yeah, coz you want to be running chrome under valgrind...
12:22mwk: never said that was a good idea :p
12:54karolherbst: mwk: sadly you don't get AVX on 32bit hardware
12:54karolherbst: I meant 32bit binaries
12:56karolherbst: using valgrind to debug 32bit only games is painful, cause "well AVX and 32bit makes no sense, we don't care, we abort"
16:53mslusarz: well, Valgrind itself is not slow, only tools built on top of it (memcheck/helgrind) are, because they do expensive checks
16:54mslusarz: "valgrind --tool=none chrome" is quite fast
17:09imirkin_: does that handle the instruction emulation?
17:10imirkin_: maybe one should write a "sigill" tool :)
17:13mslusarz: "none" tool doesn't do any instrumentation or analysis but it still does the assembly->VEX->assembly translation
17:13mslusarz: what "sigill" tool would do?
17:13adamitsch: How can I completely disable nvidia gpu at laptop? I have fedora 26 and I assume that gpu is consuming a lot of energy...
17:14imirkin_: handle SIGILL's and emulate the functionality when the CPU doesn't support it
17:14imirkin_: adamitsch: load nouveau, it should cause the gpu to suspend.
17:14imirkin_: adamitsch: or disable it in the bios, although that's not always an option.
17:16adamitsch: imirkin_ is it modprobe command or what
17:16imirkin_: adamitsch: well, nouveau would normally autoload unless you've explicitly disabled it
17:16mslusarz: I'm not sure but I think VG translates to assembly current CPU understands
17:16mslusarz: so "none" should do what you want
17:17imirkin_: adamitsch: pastebin dmesg and cat /sys/kernel/debug/vgaswitcheroo/switch
17:17imirkin_: mslusarz: ah neat
17:17imirkin_: mslusarz: it is sad that they don't support AVX on 32-bit though =/
17:19mslusarz: imirkin_: maybe file a feature request for that?
17:20imirkin_: i think lots of people have
17:20imirkin_: and have been told to go fuck themselves
17:20mslusarz: h, ok
17:21adamitsch: imirkin_, glxinfo says that I am running intel gpu, but I think there is something about nvidia gpu anyways... On previous fedora install I had bumblebee and I turned off nvidia with echo OFF > /proc/acpi/bbswitch , and then it switched to intel and overheating stopped and power consumption was about 10W... now I have around 18W
17:21imirkin_: adamitsch: ok ... well bumblebee just does the same ACPI call that nouveau does.
17:22adamitsch: so it is something else then?
17:22imirkin_: could be that nouveau's not loaded, or the gpu's not suspending for other reasons
17:22imirkin_: hence my request for the info
17:23adamitsch: powertop says that nic:virbr0 is consuming half of the power, but I think its just something messed up
17:24adamitsch: I'll try to disable nvidia in BIOS and see if any better :)
17:24imirkin_: ok. if you're interested in my help, provide the info i asked for. otherwise, good luck!
17:27adamitsch: cat doesn't find anything *
19:12mwk: POS and TXC transformation nailed down
19:12mwk: PTSZ, COL, FOG left to RE
19:16marmistrz: karolherbst, do you have anything against me documenting what we've found out yesterday on wiki?
19:19marmistrz: (or rather: what you've told me :P )
19:19marmistrz: if nothing against, can you please create a wiki account for me? :)
19:22karolherbst: I think I can't create a wiki account to begin with
19:40imirkin_: that's the main issue with the wiki - it's impossible to edit =/
19:52pmoreau: marmistrz: To get a wiki account, you have to follow the instructions here: https://wiki.freedesktop.org/sitewranglers/wiki/401/
21:49mwk: ... because it would be too simple if "bypass" meant "just pass the data through"
21:52mupuf: mwk: oh, fixed pipeline. How happy I am I never had to deal with you!
21:52mwk: oh yeah.
21:52mwk: and NV10 implementation is crazy in 17 different ways.
21:52mwk: ... that I know of so far
21:52mwk: though the infinity handling is my favorite so far
21:52imirkin_: first T&L in hw for nvidia...
21:53mwk: ±Inf * ±Inf == +Inf
21:53mwk: +Inf + +Inf == +Inf
21:53mwk: +Inf + -Inf == NaN
21:54mwk: -Inf + -Inf == +Inf
21:54imirkin_: makes sense ;)
21:56mwk: and context-switching that thing is just pure pain
21:57mwk: the only way to read/write the inner memories is to go through the whole pipeline
21:58mwk: so if you want to read the context for a context switch, you submit a "please read LTC1 context table entry 3" command
21:58mwk: and it goes through all the ALUs
21:58mwk: and you can never find out if it was +Inf or -Inf, because it was multiplied with 1.0 and added to 0.0 along the way
21:59mwk: yet Inf sign is actually significant on addition input
21:59mwk: writing context back is even worse, since to write back the transformed vertices store you actually have to push them through the T&L pipeline *again*
22:00mwk: so you need to temporarily put the whole thing into "bypass" mode on ctx restore, which is quite damn non-trivial, resubmit the vertices, and hope you didn't damage them too much
23:10mwk: FOG down, PTSZ and COL* to go
23:13imirkin_:patiently waiting until mwk gets to GPxxx
23:13skeggsb: and cracks secboot ;)
23:13imirkin_: with a hammer
23:14imirkin_: he appears to have moved on from NV3, so that's a start
23:14imirkin_: now into the double-digit NV's! :)
23:37mwk: I don't suppose anyone knows wtf NV10/NV20 POINT_PARAMETERS are?
23:38imirkin_: check what nouveau_vieux does?
23:38imirkin_: sounds familiar...
23:38mwk: doesn't do anything
23:38mwk: it doesn't support point parameters at all
23:44skeggsb: mangix: might have some patches for you shortly