02:47 PyR3X: is there driver support for the 5.8.x.x kernels?
02:47 PyR3X: I can't boot on 5.x kernels and still stuck on 4.19
02:52 imirkin: uhm
02:52 imirkin: yeah, nouveau should work
02:52 imirkin: in all kernels
02:56 HdkR:smells a Xavier
02:58 PyR3X: imirkin: for whatever reason everything works on 4.19 but will not boot under 5.x (fails when switching framebuffer resolution at boot)
02:58 imirkin: ok
02:58 imirkin: it should work.
03:00 PyR3X: imirkin: what is the best way to diagnose and report the issue?
03:00 imirkin: well, you could start by mentioning what hardware you have
03:01 PyR3X: Nvidia GTX 1080
03:01 imirkin: so that's like GP102?
03:03 PyR3X: from a quick google it appears so
03:03 imirkin: well
03:04 imirkin: i assume this is a desktop?
03:10 PyR3X: imirkin: yes
03:10 imirkin: do you have a second computer?
03:11 PyR3X: imirkin: yes
03:11 fling: with radeon? :D
03:12 imirkin: simplest thing to try would be to boot your gtx1080 box with nouveau.modeset=0
03:12 PyR3X: funny I have a radeon card in this box and had to put an Nvidia to drive the monitor
03:12 imirkin: and then ssh in from a second computer
03:12 imirkin: rmmod nouveau
03:12 PyR3X: imirkin: I've done that. As soon as I modprobe though it crashes
03:12 imirkin: and modprobe it again
03:12 imirkin: which should get it to load
03:12 imirkin: and you should get messages over ssh
03:12 PyR3X: I can get it to boot by modesetting
03:12 imirkin: in yet-another ssh terminal, you can try to run dmesg -w
03:13 imirkin: which might capture any last gasps of life
03:13 PyR3X: ah okay
03:13 fling: this is what I did to detect my crash
03:13 fling: and I worked around the crash by switching from xv to x11 in mpv
03:13 PyR3X: And now all of a sudden my fan has decided to run at full speed every 10 seconds or so
03:13 PyR3X: fling: what is mpv
03:13 fling: PyR3X: are you using d-sub?
03:14 PyR3X: what is d-sub
03:14 PyR3X: no?
03:14 fling: mpv is a successor to mplayer/mplayer2
03:14 fling: d-sub is the blue connector
03:14 PyR3X: I'm unsure -- I was away from my computer for 9 days -- I just booted it up and now the fan runs what seems like full speed on and off constantly
03:15 fling: does sensord report anything new to syslog?
03:24 imirkin: fling: uhm, xv should be fine
03:24 imirkin: unless you're using modeset instead of nouveau?
03:34 fling: imirkin: crashes pretty fast when using xv
03:34 fling: imirkin: not using modeset on nvidia
03:34 fling: BusID "PCI:1:0:0"
03:34 fling: Driver "nouveau"
03:35 imirkin: fling: oh, this is a multi-thing situation?
03:35 imirkin: fling: is this on the switch?
03:45 fling: imirkin: what is multi-thing?
03:45 fling: imirkin: I have ast and nvidia cards, only running X with nouveau
03:45 fling: it is not picking up the card unless I specify busid though
04:02 imirkin: fling: ah right
04:02 imirkin: i don't remember offhand what everyone's setups are :)
04:02 imirkin: anyways, VERY odd to hear that xv is having issues
04:02 imirkin: what gpu, and what are the issues?
04:08 fling: imirkin: sure, [ 156.904] (**) | |-->Device "Nvidia GT215"
04:08 fling: I thought it is gt 240
04:08 imirkin: well, GT 240 is a GT215
04:08 fling: oh
04:08 imirkin: but other GPUs are also GT215's
04:08 imirkin: GT215 = chip
04:08 imirkin: GT 240 = marketing
04:09 fling: I had the similar issue with 760 or something
04:09 imirkin: is this one of the GDDR5 GT 240's? or a GDDR3 one?
04:09 imirkin: so, unfortunately, tesla's just have issues with hangs. we don't do fifo switching correctly, i think.
04:10 fling: How to check?
04:10 imirkin: when nouveau loads it should say
04:10 imirkin: or check pstates, should be obvious from the highest pstate
04:10 imirkin: (does memory clock switching work? if so, it's not the ddr5 one)
04:13 fling: kernel: WARNING: CPU: 0 PID: 29136 at drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.c:168 g84_gr_tlb_flush+0x2e2/0x2f0 [nouveau]
04:15 imirkin: yeah
04:15 imirkin: that happens with tesla
04:15 imirkin: by switching to x11, you basically kill all accel
04:15 imirkin: i guess
04:15 imirkin: or enough.
04:16 imirkin: so the switches don't happen as much?
04:16 imirkin: i think there was a theory that it was interactions with the software channel, which is used for frame sync
04:16 imirkin: dunno.
04:16 fling: omg
04:17 fling: Are you saying I should've bought another gpu? :D
04:17 imirkin: i suspect i was pretty explicit about that the first time 'round
04:17 fling: d'oh
04:17 imirkin: or stick with ast :p
04:18 fling: haha
04:18 fling: What are switches?
04:18 fling: Can I disable switches?
04:19 imirkin: context switches? no.
04:20 fling: Am I using gddr5?
04:20 fling: should I get gddr3 one?
04:20 ericonr: imirkin: well, have the kernel only get some action when you call yield() :P
04:20 imirkin: you should get something that works. aka not-nvidia.
04:20 ericonr: boom, byebye context switches
04:20 imirkin: ericonr: i know you're just joking, but this is in reference to context switches on the gpu.
04:21 ericonr: ooh, I didn't read the whole thing
04:21 fling: I don't want radeon because it requires a firmware
04:21 ericonr: in that case, I guess you can burn down the GPU too
04:21 fling: can't use intel
04:21 imirkin: when the wrong action gets interrupted, we don't save / restore it quite right. at least that's the theory.
04:21 fling: what are other options?
04:21 imirkin: fling: ast.
04:21 fling: ast is too slow
04:21 ericonr: fling: everything nowadays requires firmware :P
04:21 imirkin: the gddr5 variant of the gt240 is relatively rare
04:22 imirkin: and at one point didn't work with nouveau at all
04:22 ericonr: and it obviously sucks
04:22 ericonr: but still, gotta be practical
04:22 imirkin: it functions now, but is much less tested
04:22 HdkR: `< fling> gnarface: so I probably don't care much about opengl performance eg games.` Amazing how a bit of time changes what you want ;)
04:22 fling: I don't need opengl
04:23 fling: I wanted better performance in darktable
04:23 fling: and maybe in mpv :D
04:27 fling: HdkR: I probably only have one opengl capable app which is mpv.
04:29 fling: imirkin: should not I try modesetting?
04:29 imirkin: go for it.
04:29 imirkin: perhaps through some dumb luck the specific timing of things will work out better for you.
04:30 fling: I had no crashes since switching from xv to x11 though
04:30 imirkin: cool
04:30 fling: I will try modesetting if it will crash again probably
05:23 fling: is nvptx for nouveau or nvidia?
05:25 fling: should not I use vaapi and vdpau?
05:42 HdkR: PTX is nvidia blob only
05:59 fling: ok
06:02 fling: Am I doomed?
06:46 rowbee: is there an easy way to switch back and forth between nvidia/nouveau on debian that doesn't involve uninstalling/reinstalling the full thing?
06:46 rowbee: also, would it be possible to do it on-the-fly?
06:46 rowbee: by "the full thing" i mean nvidia-legacy-390xx
08:31 fling: imirkin: will ddr3 version work any better?
08:32 fling: rowbee: you can kindof switch from nvidia.ko to nouveau.ko on the fly if you are lucky but don't expect it to be useable for general usage.
08:33 rowbee: ah no worries
08:33 RSpliet: rowbee: yeah that's one of the other reasons why I had a separate Linux installation for tracing on an external HDD
08:33 rowbee: it would be a nice bonus but i don't mind if i have to reboot
08:33 fling: rowbee: can you install both things on debian?
08:33 RSpliet: reboot is easier than install/uninstall :-P
08:33 fling: rowbee: if you can then it is possible to switch by blacklisting the module
08:33 rowbee: fling: yeah they can be installed but i've had extreme difficulty in getting nouveau to load rather than nvidia
08:34 rowbee: RSpliet: this isn't for reverse engineering (yet)
08:34 fling: rowbee: you can blacklist modules on the kernel command line probably
08:34 fling: rowbee: meaning you can have nouveau and nvidia grub entries
08:34 rowbee: i just don't want to have to reboot to windows in order to do gpu heavy stuff
08:34 RSpliet: rowbee: fair!
08:34 rowbee: fling: ah that's awesome news, maybe i can do something like that
08:34 rowbee: need to figure out how to add custom entries to grub.cfg that last between update-grubs
08:35 fling: rowbee: on gentoo you put custom entries to /etc/grub.d/40_custom
08:35 rowbee: oh yeah... since i'm here, once i finish the current thing i'm working on i'm gonna try to get a dmesg after i hibernate
08:35 rowbee: on debian atm
08:35 fling: rowbee: or you can hack into /etc/grub.d/10_linux to double every entry with nvidia and nouveau
08:36 rowbee: would love to have gentoo but 2ghz cpu
08:36 rowbee: this laptop is pretty much the only general purpose computing device i have atm :^(
08:36 fling: I'm using gentoo everywhere
08:36 fling: rowbee: you can have devuan in a container for things you don't want to build
08:36 rowbee: and it'll be that way until christmas or so
08:37 rowbee: fling: don't want to install gentoo right now. i have gentoo on my desktop back home
08:37 fling: o/
19:50 jcline: karolherbst, here's a super simple sphinx site. I've not tried to convert all the pages or anything, or even fix a bunch of links, just stub out a structure: https://jcline.pages.freedesktop.org/-/wiki/-/jobs/4771474/artifacts/docs/_build/html/index.html
19:52 karolherbst: jcline: how much control do we have over the hierarchy of the pages?
19:52 jcline: As much as you want, I think
19:53 jcline: karolherbst, it just maps to the directory structure in https://gitlab.freedesktop.org/jcline/wiki/-/tree/sphinx/docs
19:53 karolherbst: mhh, okay
19:53 karolherbst: I am still not convinced this gives us any benefits ;)
19:54 karolherbst: I mean.. I am fine
19:54 karolherbst: I just don't think it helps
19:54 jcline: Well to start with search actually works
19:54 jcline: Without going through google, too
19:54 karolherbst: ahh, sphinx creates an index?
19:55 karolherbst: okay, that's indeed nice
19:56 karolherbst: soo.. but I think I would still do it like this: 1. migrate to gitlab witht he current pipeline 2. identify pages which are useless _and_ nobody links to and remove them 3. identify pages which are usless _but_ others link to and replace them with something 4. remove all ikiwkiism from the markdown files 5. move to sphinx 6. make use of fancy sphinx features like search index
19:57 karolherbst: jcline: I got the google analyzer thing wired up on the nouveau wiki, it just crunches through some data and I should get the results soon
19:57 karolherbst: then we might have a good overview of what we have to keep and what not
19:57 karolherbst: I am also fine with just placing in redirects
19:58 karolherbst: and gitlab even has an experimental redirect feature which is just disabled on our instance
19:58 jcline: Well, I'm going to go through the pages I think are interesting and fix them up/research topics and drop it into my little sphinx project
19:58 karolherbst: jcline: right.. but that introduces the problem that we have two systems then :p
19:59 karolherbst: and I am kind of planning to clean up the normal wiki already
19:59 jcline: If it's someone more people are interested in, great, and if not it'll remain my personal note space
19:59 karolherbst: I just don't think we have to do such a split
19:59 karolherbst: mhhh
19:59 karolherbst: I have an idea
19:59 karolherbst: jcline: you could have a branch you rebase where you convert the files in the CI pipeline. Wouldn't that be enough for now?
19:59 jcline: Well, I'm sitting here with a need to do the task I outlined above for non-making-pretty docs reasons
20:00 jcline: What do you mean by "convert the files in the CI pipeline"
20:00 karolherbst: I mean, you probably used some tools to convert the markdown files to rst, no?
20:01 jcline: Oh, sure, but that's not the interesting bit anyway
20:01 karolherbst: right
20:01 jcline: I noted, with my first read-through, a lot of dead links, out of date info, etc
20:01 karolherbst: but if you focus on the sphinx integration, but we keep the actual content changes as different things, we won't diverge
20:01 karolherbst: I have nothing against checking what we can do with sphinx and such
20:01 jcline: I've done all the sphinx boilerplate, now it's just writing down correct information
20:01 karolherbst: I just don't want to have two different systems we have to merge at some point
20:02 karolherbst: jcline: sure, but _why_ do you ahve to do it post converting?
20:03 karolherbst: we can improve the wiki today already, if you do it in your fork, it takes time until it reaches users
20:05 jcline: because it's not clear to me what it is you want me to do other than to sit on my hands while you fiddle with things. I'm not at all familiar with ikiwiki, its markdown flavor, or perl for that matter. You're concerned about breaking links and organization, which is fine, but I don't know what is and isn't linked (and it sounds like you're still in the middle of figuring that out)
20:06 karolherbst: well, I already added a workaround for the broken links, so we can just move to the gitlab pages now I think
20:06 karolherbst: and I'd like to get rid of all the special ikiwiki things anyway
20:06 karolherbst: but that doesn't really matter
20:06 karolherbst: at this point it should really be only about rewriting stuff we have in there or identify things we can just remove
20:07 jcline: Okay, so it sounds like you're working on steps 1-4 anyway, so 5 seems like a good place for me to start
20:07 karolherbst: 5. doesn't mention converting files to rst ;)
20:08 karolherbst: that should really just be to replace the ikiwiki command with sphinx, but keep everything else as is
20:08 karolherbst: I guess there should be a step before 5. to get rid of inline HTML and special ikiwiki commands or so..
20:08 karolherbst: mhhh
20:09 jcline: My honest opinion is that there are very few docs worth saving in their current form
20:10 karolherbst: yeah, and I am not saying we should fix up pages we will remove anyway
20:11 karolherbst: there are probably pages we want to keep, but where the content is badly written or whatever
20:11 karolherbst: and we can start with writing new stuff in there
20:11 karolherbst: I am just very reluctant with "everything new" approaches as if we are not very very careful about it, people will have to fix up all their dead links
20:12 karolherbst: not doing that is just "easier" as the chances of breaking things is quite low
20:12 karolherbst: I have nothing with sphinx and rst being the end result, I just prefer to do it in multple steps instead of one big one
20:13 jcline: So what's the problem with us working on different steps in parallel
20:15 jcline: If you're really set on updating the old wiki stuff, I'll just write all the fixed-up stuff in rst and pipe it to pandoc to convert it to markdown so it can go in the old wiki. Which we then set up to point to the new docs.
20:16 karolherbst: there is nothing wrong with working on different steps in parallel. It's just that I don't want to miss out any content we might want to keep. Maybe it would be fine to just write everyting from scratch, fix the links after we know what we need and somehow push that out. It just doesn't sound like an iterative process and more of a "big change in one step" thing. I'd just prefer to fixing up the pages today than having to
20:16 karolherbst: wait a month until the new stuff lands
20:16 jcline: I agree breaking URLs is bad. So just put a banner in the old wiki template that has a link to the new one with a note about it being for historical purposes only.
20:16 karolherbst: nah..
20:16 karolherbst: that only causes issues
20:17 karolherbst: there is no reason we can't link/redirect to the new stuff
20:17 karolherbst: banners are just for lazy people :p
20:17 jcline:shrugs
20:17 karolherbst: I always hate those if I see them anywhere
20:17 karolherbst: especially because those also contain broken links
20:17 karolherbst: "new page should be here: $link" but $link breaks after a while as well
20:18 karolherbst: also, if we know where the new stuff is, we can just redirect to it directly
20:19 jcline: I don't really know what else to say. The docs are horribly out of date and I don't see dozens of people lining up to fix them, so I'm not sure making sure the transition is buttery-smooth and completely unnoticeable is a great use of our time.
20:19 karolherbst: anyway.. I am not against what you are planning to do, I just think it has a few drawbacks over just editing the markdown files and users will see the changes immediatly
20:19 karolherbst: jcline: ohh, I am not against changing stuff, I just prefer a faster rollout of changes
20:20 karolherbst: like rewriting stuff just doens't require us to move to sphinx and I don't see why better docs should be held back by moving to sphinx either
20:21 karolherbst: but maybe the rewrite would be done in a week and it would be fine, dunno
20:25 jcline: Like I said, I don't really know what else to say. We've got different ideas of how to get to the same place, so I don't see much point arguing over the details of our routes when the only people working on it is either you or me
20:26 jcline: I assumed since no one had updated the docs in months no one would mind me going through and doing a thorough update as an introductory project
20:27 jcline: If you'd prefer to handle it all, that's fine, but I don't know what you want me to do to help
20:27 karolherbst: jcline: well, the problem I see is, that after you are dine, whenever that will be, there will be this one MR or whatever which changes everything, right? And at this point we can only ack or somebody goes through all the changes and verifies nothing important got missed, correct?
20:28 jcline: That is one way to handle it, certainly
20:29 karolherbst: well, that's the only way your approach allows, doesn't it? If everybody else is up for it and everybody agrees on this "replace everything with the new thing" and we just check the new thing is in order. that's fine by me. Just want to make sure that implications are known before jumping into that
20:29 jcline: There's also no technical reason both the wiki and the new docs be hosted at the same time under two different URLs and the task done in bits and pieces
20:29 jcline: But since you've said you don't want two things at once *and* you don't want everything changed at once I have no idea how I'm supposed to meet your requirements
20:30 karolherbst: jcline: would it be an issue for you to just rewrite the markdown files you would like to work on and put them in proper shape and once we removed all ikiwikism or so, convert over to sphinx?
20:31 karolherbst: maybe I just don't see why we need to do both at once
20:31 jcline: To be honest the more we argue this in circles the more inclined I am to throw up my hands and go work on something else
20:32 jcline: I'm here, I'm offering to do literally all the work. Why are we quibbling about how I do that?
20:34 karolherbst: it's not that I am quibbling about it, I just don't understand why you are doing it this way. And maybe there is no reason and it's just how you like to do it, and that would be fine by me as well. I just see a few downsides of this approach and I didn't understand or felt like you explained to me why that's not an issue.
20:35 karolherbst: but if you want to do this all new approach and nobody is against it, that's fine as well. I just don't think it's necessary to go that far
20:36 karolherbst: I wouldn't held back your stuff once we all agree it's good, I just tried to explain that this will be something you would work in your sandbox for a while and then drop this big change, which might be fine, but maybe it then still needs more work and it will be neverending
20:37 karolherbst: I know from experience how those big projects turn out in a lot of cases, and most of the time those will never finish
20:37 karolherbst: or at some point you say "that's the best I can do, now I want to do other things" and we have to chooce between leaving things out, because nobody finishes it, or stick with the old one
20:37 jcline: The only time docs work is done is at the heat death of the universe
20:38 karolherbst: probably yes
20:39 jcline: If you'd prefer, I am more than happy to contribute this page-by-page, and when *you're* satisfied you can switch over
20:39 karolherbst: my plan was that we don't really have to switch over. So once we move over to gitlab, we can just commit the changes and those go live immediately and then we change the tool if we want to. At least that was more or less my idea
20:40 jcline: This is not, in the grand scheme of things, a large documentation project.
20:40 karolherbst: yeah, I guess I make a bigger deal out of it as it probably is
20:40 jcline: When I say switch over I mean drop in a redirect somewhere
20:41 karolherbst: ah yeah
20:41 karolherbst: that would work
20:54 karolherbst: jcline: sorry for being so stubborn about it. And your motivation to work on that is very welcomed. And I am also not stating my opinions as a "it has to be done this way". It's just my personal reservation with it. And I wouldn't block the end result if it's good even if you just ignored all my adivces or didn't address any of my remarks.
20:55 jcline: karolherbst, no worries. I understand.
21:44 karolherbst: jcline: btw, how do you link to sections within rst files?
21:45 karolherbst: can you declare like ids the generated <a href="..."> links will point to or how does that work?
21:46 karolherbst: like if somebody wants to place a link to index.rst:Community
21:46 karolherbst: how'd you declare that in rst?
21:55 karolherbst: ahh.. seems like you just take the name of the section and do "<other.rst#section>" mhh
21:55 karolherbst: at least in plain rst
21:56 karolherbst: and doesn't seem to work with all rst to html generators :/
21:56 karolherbst: that's also super stupid in markdown sadly
21:56 karolherbst: at least sphinx allows you to specify proper labels, but than it's not plain rst anymore
21:57 karolherbst: but better than ikiwiki requiring you to add html tags