01:00damex: nvc0 (nvs4200m) downclock should be supported, right?
01:01damex: actually nvd9 according to nouveau wiki
02:20damex: how can i manually setup xorg-x11 config for optimus that described here https://nouveau.freedesktop.org/wiki/Optimus/ ? i want to enable UXA and TearFree for Intel... if i do https://bpaste.net/show/3a4bf9f568cf something like that - only intel ddx drivers getting loaded.
02:21damex: if i do not specify a thing - it detect both cards automatically and i can see them at xrandr --listproviders
02:27damex: found that config https://wiki.archlinux.org/index.php/PRIME#Discrete_Card_as_Primary_GPU and it says about running nouveau as primary card while intel outputs disabled. it can be enabled later by $ xrandr --setprovideroutputsource Intel nouveau. can we specify it in config? that we won't need to run that command. everything in config.
04:09karolherbst: mupuf: did you put the nvc8 card into reator? It seems there is only one card in it, which seems unusual
04:16mupuf: karolherbst: shit... it is plugged
04:17mupuf: and the fan was spinning
04:17karolherbst: mhh I thoguiht as much
04:17karolherbst: but only the nve6 is recognized
04:17mupuf: well, maybe there is a bad contact
04:28karolherbst: mupuf: there is a sign problem with the sensors though. For the ina3221 it is quite trivial, because bit 15 is the sign and bit 14-3 are the absolute value, but I highly doubt that we hit negative values anywhere
04:29mupuf: negative power consumption? :D Yeah, not gonna happen
04:29karolherbst: for the ina219 it is more complicated though. Depending on the pga, the sign bits can be up to 15-12, with the same value in each
04:30karolherbst: and the value is stored in the other ones
04:30karolherbst: well, the reg only give us the voltage though
04:30karolherbst: but still
04:30mupuf: which is what you expect
04:30karolherbst: I don't know if I should handle the sign bit, because it is rather annoying
04:50prg_: karolherbst: got a lockup. was just using a web browser when the screen flickered, checked pstate: it upclocked to 0d
04:51prg_: a few seconds later screens were frozen and in dmesg: nouveau 0000:01:00.0: fifo: FB_FLUSH_TIMEOUT, nouveau 0000:01:00.0: fifo: PBDMA0: 00000002 [MEMACK_TIMEOUT] ch 5 [023f929000 kwin] subc 0 mthd 001c data 00000002
04:51karolherbst: anything in dmesg?
04:53karolherbst: prg_: I suspect there are multiple FB_FLUSH_TIMEOUT and LB_ERROR in dmesg/logs anyway
04:54karolherbst: never found time to investigate it further, but it seems that we still do something not right
04:55prg_: dmesg contains FB_FLUSH_TIMEOUT only once, there's no LB_ERROR
04:55karolherbst: ohh okay, could be an issue with my gpu then
04:55karolherbst: but FB_FLUSH_TIMEOUT sounds not that good
04:56damex: i found out why gf119 (nvs4200m) had no working hdmi sound after rescan (atleast for now). without pci remove of nvidia card and rescan - it does not show hdmi sound card. intel hda module need to be probed with "thinkpad" vendor. thats it.
04:56damex: https://bugs.freedesktop.org/show_bug.cgi?id=75985 same issue
04:57karolherbst: those vendors...
04:58damex: last decent laptop ;(
04:58damex: and yet quirks everywhere...
04:58damex: i probably should install coreboot
04:58karolherbst: because they want to be smart
04:59karolherbst: nah, if you are stupid, you won't make something like that
04:59karolherbst: you would just leave both HDMI audio devices there
04:59damex: it is stupidity
05:04prg_: oh well, back to the blob again for now
05:08karolherbst: mupuf: any idea what may cause those FB_FLUSH_TIMEOUTs?
05:13damex: now everything is kinda fine for nouveau except powermanagement... i wonder if there is a way to maximally downclock that videocard
05:15mupuf: karolherbst: yes, failing at reclocking? :"D
05:15mupuf: Sorry, I do not have more insight on this "s
05:16damex: oops i was wrong. hdmi sound still does not work :(
05:17damex: no errors tho
05:20damex: 4.697015] sound hdaudioC2D0: hda-codec: out of range cmd 0:5:707:ffffffbf
05:20damex: i wonder how to fight that... google does not provide any output happens only on nouveau optimus setup
06:04damex: boot system with nouveau. no hdmi sound present. remove nvidia card and do pcirescan. hdmi sound device appears but does not work. rmmod nouveau and modprobe nvidia and it works. if you rmmod nvidia && modprobe nouveau - it is not once again.
06:04damex: on bare nvidia-drivers it does not work too. dafuq is that magic
06:19karolherbst: prg: thanks for testing my branch by the way. It seems like there is still some bits left regarding memory, but I am sure we will figure it out one day
06:31vedranm: damex: you are removing PCIe card while the system is on?
06:31vedranm: like, physically pulling the card out of the slot?
06:31damex: vedranm, echo "1" > /sys/bus/pci/devices/0000\:01\:00.0/remove
06:31damex: echo "1" > /sys/bus/pci/rescan
06:31vedranm: aaaah, OK
06:32damex: i am looking for another hax
06:32damex: probably with acpi_call
06:32damex: since that issue present since 2012 and noone cars
06:33damex: novidia/nouveau does not care i am not sure to report about that hack since it is already reported in a little different way
06:33karolherbst: damex: well you could ask lenovo, maybe they tell you
06:33damex: karolherbst, they broke m.2 ssd support on x250 thinkpad with one of the security bios updates.
06:34damex: and they refused to fix it lol
06:34damex: ssd was bundled with lappie
06:34damex: i doubt they will care about t420 :D
06:34damex: or any *20
06:34karolherbst: I meant, you could ask them what they did
06:34damex: ha good joke
06:34damex: i think they're the last ones who will tell me about it
06:35damex: i think it is easier to find engineer who made that shit
06:42prg: karolherbst: no problem. thanks for working on this
07:10damex: vedranm, https://github.com/damex/foosha/blob/master/nvidia-hdmi looks like that
07:11damex: tested on t420 and t430 with nvidia cards >_>
07:11damex: same shit
07:22vedranm: pmoreau: I just noticed today OpenCL is already exposed on G96
07:22vedranm: clinfo crashes in a way I have not seen before, but I don't care
07:23vedranm: eagerly awaiting basics to work
07:25karolherbst: vedranm: which CL loader are you using? sometimes icl-ocd doesn't play well with some implementations
07:27vedranm: karolherbst: ocl-icd
07:28karolherbst: ohh right it is called ocl-icd... :D
07:29vedranm: karolherbst: ahahahaha
07:29vedranm: well, of course it's not called Intel Compiler OCD
07:30vedranm: unfortunately, Debian packaging doesn't seem to allow me to remove ocl-icd
10:49pmoreau: vedranm: How is OpenCL exposed for G96? Or you mean Nouveau says that it supports compute on that card?
10:51hakzsam: vedranm, CL is definitely not yet exposed on nouveau
10:51vedranm: pmoreau: well, clinfo detects it
10:52hakzsam: vedranm, paste the output of clinfo?
10:52vedranm: pmoreau: https://ghostbin.com/paste/khvhv
10:52vedranm: hakzsam: ^
10:52vedranm: this is on Debian unstable
10:53pmoreau: Let's have a look at this unknown cap
10:55pmoreau: Looks like PREFERRED_IR
10:57hakzsam: imirkin, https://cgit.freedesktop.org/mesa/mesa/commit/?id=cbf24a01dd3d8170ded0aef310053e0493a62ede --> why it's not PREFERRED_IRS? :)
10:57pmoreau: I guess someone wrote some patches to advertise compute on Tesla cards.
10:57imirkin_: PREFERRED_IR is different.
10:57pmoreau:is not accusing hakzsam O:-)
10:57hakzsam: pmoreau, nope, it's me
10:57imirkin_: prefer is prefer. support is support.
10:58hakzsam: imirkin_, yeah, but PREFERRED_IRS is not defined for nv50....
10:58imirkin_: but that's not a problem you caused
10:58imirkin_: or is it?
10:58hakzsam: I added SUPPORTED but not PREFERRED_IRS
10:58hakzsam: it is
10:58hakzsam: to avoid this unk cap though
11:01pmoreau: vedranm: So compute is advertised, but you can't use OpenCL on it just yet. (Or at least not with git Mesa, but even so, there is **really** little OpenCL features you could use.)
11:02hakzsam: vedranm, btw, you use mesa from your package manager or something?
11:03hakzsam: it's not related to my changes anyway :)
11:07vedranm: hakzsam: Debian, yes
11:07vedranm: pmoreau: that's a great start
11:08vedranm: I have been having this PC with an Radeon HD6450 and every few months I would run clinfo, until it started working, then I ran some more stuff
11:08vedranm: now that Radeon is as good as it gets I put GT 9500 in that PC
11:08vedranm: so, same story...
11:08hakzsam: pmoreau, opencl is not even supported by mesa master..
11:08hakzsam: pmoreau, you can launch compute kernels but you need to write them in TGSI
11:09hakzsam: and to manage your resources yourself :)
11:09pmoreau: hakzsam: I never claimed the opposite :-)
11:11hakzsam: imirkin_, PIPE_SHADER_COMPUTE is enabled on nv50, that's why clover believes that CL is supported but it's a big lie :)
11:11imirkin_: ah :)
11:11hakzsam: it should not be turned on, I wonder why I did that when I added compute support on nv50
11:13hakzsam: it doesn't matter because SUPPORTED_IRS is 0
11:13hakzsam: but clover doesn't check this cap
11:13hakzsam: it is only checked for compute shaders as you already know
11:15vedranm: hakzsam: I know
11:15vedranm: pmoreau told me about this when I read his blog post
11:16vedranm: hakzsam: don't de-advertise it now
11:16vedranm: that would be like going back
11:16imirkin_: vedranm: it shouldn't be advertised
11:16imirkin_: it's totally not supported.
11:16hakzsam: well, it's a lie, not a feature :)
11:16pmoreau: Oh right, and I still need to write a new one…
11:16vedranm: I see...
11:17hakzsam: imirkin_, I can make a patch...
11:17imirkin_: hakzsam: please do
11:19pmoreau: vedranm: If you ever feel like testing my branch and report bugs, you're welcome. Though there isn't much to test :-/
11:25vedranm: pmoreau: as soon as you have something useful, I would be glad to
11:25pmoreau: What would you include in "useful"? :-)
11:25vedranm: assuming that it is not likely to crash the GPU, I can do it as much as you like
11:26vedranm: pmoreau: well, I would consider opencl vector sum useful
11:26vedranm: I see you got device store working, which is great stuff
11:26vedranm: but I would prefer to wait until a little more works
11:26pmoreau: I think that already works
11:27vedranm: oh, and I am digging through Gallium right now
11:29vedranm: pmoreau: can you assist me on src/gallium/state_trackers/clover/tgsi/compiler.cpp ?
11:30pmoreau: I never interacted with TGSI :-/ Hans de Goede would be able to help you.
11:30vedranm: pmoreau: OK then
11:31vedranm: thx :)
11:31pmoreau: vedranm: Have a look at his repo: http://cgit.freedesktop.org/~jwrdegoede/
11:31hakzsam: imirkin_, will push tomorrow, I have to go
11:32imirkin_: hakzsam: ok
11:32vedranm: pmoreau: is there a better Gallium?
11:32pmoreau: He has some LLVM to TGSI working, enough to compile a simple OpenCL kernel through TGSI.
11:32vedranm: pmoreau: I think I found a bug with scalar argument handling
11:33vedranm: I'm not sure what code path Radeon uses, but I am pretty sure it passes through TGSI
11:33imirkin_: vedranm: you are mistaken.
11:33vedranm: imirkin_: yep, I am
11:34vedranm: looked at the wrong number, sorry
11:34vedranm:will dig deeper
11:34imirkin_: radeon (both r600 and radeonsi) use a llvm backend to compile opencl -> native bytecode
11:35vedranm: imirkin_: there is some point in Gallium which initializes scalar argument and assumes size is 4 bytes
11:35vedranm: I just have to find where exactly is that done
11:36vedranm: anyway, will dig deeper and report back
11:43imirkin_: vedranm: gallium does not know anything about... any of this stuff.
11:43imirkin_: it's just a set of APIs
11:44imirkin_: and i'm sure that there are assumptions that things are ints all over the place
11:44imirkin_: TGSI isn't very adept at dealing with non-32-bit quantities
11:45imirkin_: and neither are GPUs
14:14mooch: does anyone here know anything about nv4's real mode access?
14:19vedranm: imirkin_: I see
14:45karolherbst: mupuf: will you find some time to look into the nvc8 today?
16:22imirkin_: karolherbst: can you double-check if the talos principle update fixed things on nouveau?
16:23karolherbst: imirkin_: the steam update?
16:23imirkin_: karolherbst: no, talos update
16:24karolherbst: or the mesa one?
16:24imirkin_: [which i assume they pushed through steam]
16:24imirkin_: game engine update, not mesa update
16:24karolherbst: ohh so you just mean the game update, I don't need a recent mesa or anything
16:24imirkin_: well, recent mesa wouldn't hurt ;)
16:24karolherbst: well usually my mesa is like 2 weeks old
16:25imirkin_: that's fine
16:25imirkin_: i wouldn't try mesa 8.0 though :)
16:26karolherbst: well I think I tried it out some weeks ago and it wasn't as bad anymore anyway
16:26karolherbst: but still bad
16:26imirkin_: they pushed out an update today
16:26imirkin_: which should address the discard issues
16:26karolherbst: nope, still bad
16:26imirkin_: did you get the update?
16:26karolherbst: mhh beta or main?
16:27imirkin_: beta i guess?
16:27karolherbst: k, then I have to swtich to it
16:28karolherbst: I hope also the dynamic lightning thing is fixed
16:28imirkin_: this is about the dynamic lighting thing
16:28imirkin_: there are other issues on top of that?
16:28mupuf: karolherbst: yes
16:29mupuf: just came back home
16:29karolherbst: mupuf: awesome :)
16:29mupuf: so, let's have a look
16:29karolherbst: imirkin_: I had isues also with dynamic lights disabled, but the perf didn't suck as much
16:29karolherbst: they also have a 64bit version now
16:29karolherbst: very nice
16:30karolherbst: which doens't run
16:30imirkin_: can't win 'em all
16:30karolherbst: I will check if the pcie bus speed still matters too
16:31karolherbst: yep, dynamic lights still bricked
16:31karolherbst: ohh wait
16:31karolherbst: I've disabled it already
16:32karolherbst: well I still get flickers on the ground
16:32karolherbst: nah, it still sucks big time
16:33imirkin_: thanks for checking
16:34mupuf: karolherbst: ok, gave up, it works on the second slot but not the first one..
16:34imirkin_: mupuf: solution: put it in the second slot.
16:34karolherbst: out a post it note on the gpu "beware the slot!"
16:34mupuf: imirkin_: yep, that was the solution :D
16:35karolherbst: k, now I will check the ina219 stuff
16:35mupuf: I will keep it on then
16:35imirkin_: mupuf: are all the intel people madly working on vulkan btw?
16:36imirkin_: it seems like all ML/etc acvitity has stopped from them
16:36mupuf: can't speak for the portland office
16:36mupuf: but in helsinki, we are not working on vulkan
16:37imirkin_: too cold for that? :)
16:37karolherbst: how is the gpu offloading situation in vulkan by the way?
16:37mupuf: Ian asked me to test the performance of some fixes for MSAA
16:37mupuf: so, there are still working :p
16:37imirkin_: mupuf: yeah, i saw the results of that... very sad.
16:37imirkin_: [i guess he has new patches]
16:38mupuf: what did you see?
16:38imirkin_: perf results for his patches
16:38mupuf: oh, he shared them?
16:38karolherbst: 230W sounds a bit much
16:38imirkin_: mupuf: https://lists.freedesktop.org/archives/mesa-dev/2016-February/108122.html
16:38karolherbst: but hey, it prints something
16:38karolherbst: and it changes the value
16:38imirkin_: karolherbst: it's fermi
16:38imirkin_: karolherbst: 2000W wouldn't sound too much
16:38mupuf: imirkin_: nope, not my benchmarking
16:39mupuf: I was running other benchmarks
16:39karolherbst: GTX 570.. yeah, 200W sounds fine
16:39karolherbst: mupuf: so it's working ;)
16:39imirkin_: mupuf: ah :) well, it was from idr, and it was benchmark results.
16:39karolherbst: mhh, what's odd then
16:39mupuf: imirkin_: you could not have guessed, yeah
16:40imirkin_: karolherbst: hm, according to the nvidia page, 220W max on the GTX 570
16:40imirkin_: karolherbst: and i'm guessing that one is running at way-low clocks
16:40karolherbst: I am happy that I get data at all
16:41karolherbst: 3031 vbus, 535 vshunt 320 pga
16:41karolherbst: mupuf: all three rails report the same values nearly
16:41karolherbst: ohhh not true
16:42karolherbst: one 530 and the other two 330
16:42karolherbst: mhh odd
16:42mupuf: close-enough :D
16:42mupuf: not odd no
16:42karolherbst: the first is the kepler with the ina3221
16:43karolherbst: I bet I messed something up shifting the values
16:44karolherbst: shunt starts at 0th bit and vbus at 3th
16:45karolherbst: maybe I read the pga wrongly
16:45karolherbst: but still
16:45karolherbst: then we could hit 57W
16:45karolherbst: still too much
16:47mupuf: yep. still too much
16:47karolherbst: no clue
16:47karolherbst: something is odd, but I don't know what
16:47mupuf: check the voltage first
16:47mupuf: what is the reported voltage?
16:48mupuf: and you can read my code for the ina219
16:48mupuf: it already works
16:48karolherbst: which ina219 code?
16:48mupuf: lane->V = (vbus & 0xfff8) / 2000.0;
16:48mupuf: lane->I = vshunt * 10 / (double)resistor / 1000.0;
16:48mupuf: lane->W = lane->V * lane->I;
16:49karolherbst: yeah found it
16:49karolherbst: I thought I could do the same thing as with the ina3221
16:49mupuf: P = 28.911 W (0: 11.93 W, 1: 8.24 W, 2: 8.74 W)
16:49mupuf: sounds better
16:49mupuf: still high though
16:49mupuf: but hey, it is a fermi!
16:51mupuf: karolherbst: works better?
16:52karolherbst: well I could just copy your code, but this isn't as clean as it should be
16:52karolherbst: on the ina219, the vbus has to be >> 3
16:52karolherbst: the vshunt doesn't need to be shifted
16:52karolherbst: and the pga is read out from the config reg (which is 320 by default)
16:53mupuf: pga? /me forgot all about this
16:53karolherbst: "Sets PGA gain and range. Note that the PGA defaults to ÷8 (320mV range). Table 4 shows the gain and range for the various product gain settings."
16:53karolherbst: no clue what that is though
16:53karolherbst: but seems important
16:54karolherbst: for the ina3221 I get the right value when doing this: ((vbus >> 3) * (vshunt >> 3) * pga) / shunt
16:54karolherbst: and pga is 320 on the ina3221 at any time
16:55karolherbst: which is the same as (vbus * vshunt * 5) / shunt
16:58karolherbst: with your code I get much lower values now
16:58karolherbst: ohh wait, I used the ina3221 code
16:58karolherbst: now the ina219 one
16:59karolherbst: but it is the same actually, just the shift is missing
16:59karolherbst: but why?
17:00mupuf:is sleepy right now, so ... will just ask my pillow!
17:00mupuf: see you!
17:02karolherbst: it does make no friggin sense :/
17:05karolherbst: ahh now
17:12karolherbst: now it is good :)
17:13karolherbst: https://gist.github.com/karolherbst/32fa1f7a0623ce6e73d6 :)
17:14karolherbst: I just misunderstood the pga stuff
17:14mupuf: yeah :)
17:15karolherbst: the *320 multiplier is cut by the pga config reg
17:16karolherbst: so if the default config is 3, I have to vshunt*vbus*(320/8) / shunt
17:16karolherbst: and then it's done
17:16karolherbst: and works for ina219 and ina3221
17:19mupuf: :) Night!
17:28imirkin: karolherbst: can the count of these things ever be 0?
17:28imirkin: i.e. what if there are no icc devices, but the table is there
17:28karolherbst: then there is no active rail and the rail_count is 0
17:28imirkin: if so, you'll try to kmalloc(0) which is probably not great
17:29karolherbst: let me check
17:29karolherbst: you are right
17:30karolherbst: but kmalloc(0) shouldn't fail though
17:30karolherbst: I think it returns 0x16 for slab
17:34karolherbst: it returns 16
17:34karolherbst: but it is still not great to do that
17:36karolherbst: imirkin: 0x16 is the pointer to the memory region of size 0x0 in slab, so that kmalloc(0) returns something valid
17:37karolherbst: the nvbios path also does kmalloc(0) in that case...
17:37karolherbst: k, I will just bail earlier then
17:38imirkin: karolherbst: hmmmm ok. is that true of SLUB as well? either way, it might be better to bail in that case...
17:39karolherbst: but what should nvbios_iccsense_parse return, when there is no entry
17:39imirkin: final call is up to skeggsb of course
17:46karolherbst: should be better now
17:47karolherbst: I really hope we can land it in 4.6, because I want this to be tested before we actually rely on it later
17:48imirkin: karolherbst: EINVAL?
17:48imirkin: wouldn't that cause init to fail, just coz you don't have that table?
17:48karolherbst: I thought I don't do einval in the subdev ctor
17:49karolherbst: mhh I actually don't
17:49imirkin: oh, well i was just looking at nvbios_iccsense_parse
17:50imirkin: heh, ok, you treat all errors from it as "go away". fair enough.
17:51karolherbst: when a subdev returns an error, nouveau stops loading for the gpu, right?
17:51imirkin: i think so yeah
17:52imirkin: it might continue if you return -ENODEV? i forget.
17:52karolherbst: actually nvidia fails to load when something is funny with the sense table
17:52karolherbst: as there is no extdev for a given rail
17:53karolherbst: seems like nvidia takes this part seriously
17:54karolherbst: sadly I don't know who has a ina209 :/
17:55karolherbst: but the ina219 and the ina209 are pretty close
17:55karolherbst: there are only a few differences
17:58karolherbst: actually it is quite nice if you have documentation for a piece of hardware. Makes coding for them much easier :D
17:59imirkin: almost like cheating
17:59karolherbst: yeah I feeld really bad, that I didn't fully RE those sensors
18:00karolherbst: especially because most of the regs are just returning 0 in the default config
18:01imirkin: btw, why is this gf100+?
18:01karolherbst: becuase there are no power sensors like these on older chips
18:01karolherbst: or at least the tables are not there
18:01karolherbst: I already checked all the vbios
18:02imirkin: just checked my gt215 and it doesn't have one... g200 would be the other good candidate to have weird stuff
18:03karolherbst: well there are EXTDEV tables on older chips
18:03karolherbst: but not the SENSE table
18:04karolherbst: so in any case, even if there are power sensors on older chips, it needs to be configured differently
18:14karolherbst: or maybe reclocking wasn't that important and on pre fermi there isn't either boost
18:15karolherbst: so maybe they already knew somehwat what the highest power consumption is and just didn't care enough to actually limit the gpu
18:15karolherbst: with gpu boost the situation is much different and power consumption could be too high under certain workloads with really high clocks
23:04Mittttens: nouveau crashing on nve4: https://paste.debian.net/400827/
23:05Mittttens: if anyones interested in recreating i was running multimc5
23:05Mittttens: and then installed forge on 1.8.9 and ran it
23:05Mittttens: and nouveau crashed
23:05Mittttens: tried it a couple of times
23:06Mittttens: crashes each time
23:06imirkin: Mittttens: what version of mesa?
23:07imirkin: so much for my suggestion of "try updating mesa" :)
23:08Mittttens: happened when it was doing something with opengl i believe
23:08imirkin: how quickly does it die?
23:08Mittttens: well it will start loading and will get to a part where it is loading a "texture atlas"
23:08Mittttens: and then immediately die
23:08imirkin: in units of time
23:09Mittttens: well i couldn't say since i don't know what the point is exactly that causes it to crash
23:09imirkin: like 30s or like 30min?
23:09Mittttens: but i'm going to guess probably less than 1/10th of a second it dies
23:09imirkin: heh ok
23:10imirkin: well, if you're up for it, you could grab a mmt trace of it, and provide both that and the dmesg
23:10Mittttens: hardware cursor still works but everything is deadlocked
23:10imirkin: which should let me see wtf is going on
23:10Mittttens: and i can see the frozen screen still obviously
23:10imirkin: mmt = https://nouveau.freedesktop.org/wiki/Valgrind-mmt/
23:11Mittttens: when nouveau crashes i should just REISUB right?
23:11Mittttens: or is there some way i can get it to restart?
23:11imirkin: you can probably just ssh into the box actually
23:11imirkin: i guess it's questionable whether the relevant bits will make it into the trace...
23:11Mittttens: and do what imirkin?
23:12Mittttens: once i'm ssh'd in
23:12imirkin: kill (-15) the process
23:12Mittttens: that caused it to crash?
23:12imirkin: which will hopefully still allow the trace to get flushed out
23:12Mittttens: or nouveau?
23:12imirkin: and then you can reboot
23:13Mittttens: i'm talking about if i'm not trying to debug
23:13Mittttens: just if i wanna start nouveau again
23:13imirkin: well, you can attempt to "restart" nouveau without restarting your box
23:13imirkin: you'd kill X, unbind the pci device in sysfs, and then rebind it.
23:14Mittttens: and how do i unbind/rebind it?
23:14imirkin: echo the-pci-id > /sys/.../unbind
23:14imirkin: (and then same thing, but into bind)
23:14Mittttens: i could prolly make that into a bash script init
23:15Mittttens: (not the init system)
23:16imirkin: i'm off... good luck
23:16Mittttens: thanks, see you