01:29hessophanes: Hi - sorry, maybe a stupid question, but I had no luck googling it: I'm looking for a way to use the HDMI output of my Lenovo P53 (onboard Intel GPU + NV TU117GLM). I've read that 2D/3D acceleration on TU11x is still unsupported, but I only need the xrandr --provideroutputsource to work. Should that be possible at the present state of development?
01:30imirkin: good news and bad news
01:30imirkin: output offloading requires acceleration
01:30hessophanes: (Actually, I tried loading nouveau, and i3 is properly rendering its background onto the HDMI output, but I cannot see any windows I place there. And it's throwing tons of i2c NAK messages.)
01:30imirkin: TU11x accel support was recently added, i think it'll be in v5.6
01:32imirkin: yeah, grab v5.6-rcX, should work better
01:32hessophanes: Ah, nice - I only saw a single commit that added a few structs for TU11x. I'm almost at git HEAD (which puts me at v5.6-rc6), so maybe that already included enough to make it work...
01:32imirkin: yes, that is already included
01:32imirkin: so you have bigger and better problems - yay!
01:32imirkin: pastebin dmesg?
01:32imirkin: oh, do you also have the latest linux-firmware?
01:32karolherbst: I just wanted to ask that as well D:
01:33imirkin: i.e. one with nvidia/tu117 directory
01:34hessophanes: No, and I wondered whether I needed that for what I wanted to do... Debian's not keeping up, sigh. Going to find the firmware from upstream...
01:38hessophanes: Cloning will take a minute. - Thanks already for your help and directions!
01:50hessophanes: Ok, dmesg starting from module load w/ proper firmware: http://paste.debian.net/1136861/
01:50hessophanes: This time I don't even see the external display. Every time I wiggle the HDMI cable I'm getting an error from i2c-11...
01:52imirkin: that's unfortunate.
01:52imirkin: i2c is required to do ... a lot of stuff
01:52imirkin: like fetch EDID
01:53imirkin: sounds like something i2c-related may have changed there
01:53imirkin: Lyude: skeggsb --^
01:53imirkin: hessophanes: do you have some sort of i2c debug thing enabled?
01:54imirkin: i don't remmeber seeing the i2c adapter registered messages
01:54hessophanes: I2C_DEBUG_CORE and DEBUG_ALGO is active, if that's what you mean...
01:55imirkin: ah yeah, probably I2C_DEBUG_CORE is throwing those
01:55hessophanes: Oh, and DEBUG_BUS as well even.
01:55imirkin: did you just happen to randomly enable them?
01:56hessophanes: Mhhh, can't say when I activated those. I've been carrying my kernel configuration forward for ages...
02:14hessophanes: Well, gotta call it a night. You already clarified a lot, thanks again!
09:57mmenzyns: what looks better, assert(0) or assert(false)?
09:59HdkR: Overwhelming majory of the codebase uses 0
10:00HdkR: 70 instances of assert(false, 1001 instances of assert(0
11:47cosurgi: I still prefer assert(false)
11:53karolherbst: HdkR: new code should really use stdbool though
11:53karolherbst: that's why we have it
11:53karolherbst: (and stdint as well btw=
12:22karolherbst: imirkin: https://gitlab.com/gitlab-org/gitlab/-/issues/15470
12:22karolherbst: that's the annoying issue :)
12:26karolherbst: ahh, my mistake
12:26karolherbst: https://gitlab.com/gitlab-org/gitlab/-/issues/14775 this is the one :=
12:31macc24: imirkin: can nouveau be made to work without vgabios?
12:32karolherbst: it describes the GPU
12:33karolherbst: without it we don't know what connectors the GPU has, etc...
12:33macc24: so it can be made to work
12:33macc24: module options?
12:33karolherbst: not possible
12:33karolherbst: on modern systems the vbios is provided by acpi
12:33macc24: can nouveau take information about gpu from something else than vbios?
12:33karolherbst: it's not possible to replace it or not use it, just accept that
12:33macc24: like some other configuration stuff
12:34karolherbst: that's what the vbios is for
12:34macc24: vbios is proprietary
12:34karolherbst: of course
12:34karolherbst: as is the GPU
12:34karolherbst: or your CPU
12:34karolherbst: there are two bits in a vbios
12:34karolherbst: 1. firmware code read by BIOS or UEFI
12:35karolherbst: 2. tables describing the GPU
12:35karolherbst: 1. is read out by your motherboard firmware, so we can't prevent that
12:35macc24: we can
12:35macc24: with coreboot
12:35karolherbst: 2. is harmless as it doesn't contain any CPU code executed
12:35karolherbst: and nouveau doesn't use those parts
12:35macc24: is it signed?
12:35karolherbst: on newer systems it is I think
12:35karolherbst: not sure
12:36macc24: so those tables can be replaced by something else
12:36karolherbst: but I think flashed on vbios needs to be signed on newer GPUs
12:36karolherbst: and how do we know by what?
12:36karolherbst: those are data tables
12:36karolherbst: nothing more
12:36karolherbst: they tell us what perf levels the GPU can be used
12:36karolherbst: like core or memory clocks
12:36karolherbst: how to configure the fan etc...
12:36karolherbst: it's tight to the hardware
12:37karolherbst: and without it we can't properly use the GPU
12:37karolherbst: it's llike an instruction manual
12:37macc24: can nouveau init the hardware if it hasn't been initialized by firmware?
12:37karolherbst: with the vbios, yes
12:37karolherbst: wihtout it, no
12:37macc24: conf tables?
12:37macc24: or what
12:37karolherbst: of essentially everything
12:37karolherbst: clocks, voltages, fan, connectors, hardware sensors
12:38karolherbst: essnetially everything
12:38macc24: so it only needs configuration stuff?
12:38karolherbst: well, if you strip away everything else you only get rid of the CPU code your firmware uses
12:39karolherbst: _but_ even coreboot needs part of that if it wants to be able to display something thorugh the GPU before loading a kernel
12:39macc24: assume that nouveau has configuration data
12:39macc24: and no gpu init was done by firmware
12:40karolherbst: where should nouveau get the configuration data?
12:40macc24: can nouveau then init the gpu?
12:40macc24: please assume that it somehow gets it
12:41karolherbst: this question is pointless to discuss
12:41karolherbst: of course it would work, but we don't have the configuration
12:41karolherbst: so it's pointless
12:41karolherbst: the vbios _is_ the configuration
12:41karolherbst: and we don't hardcode information for every single GPU model out there
12:41karolherbst: so.. any better ideas?
12:42macc24: vbios without code
12:42karolherbst: nouveau doens't use the code
12:42macc24: similar to vbt for intel gpus
12:43karolherbst: vbt is in the same situation, no?
12:43karolherbst: intel has one big advantage
12:43karolherbst: RAM isn't a concern
12:44karolherbst: for nvidia gpus you need to initialize the VRAM somehow
12:44karolherbst: that's done by the code bits of the vbios the firmware uses
12:44karolherbst: and this is not trivial
12:45macc24: assume that ram is shared with cpu
12:45karolherbst: anyway, there is this so called "devinit" in the vbios, which is a scripting language to write values into the GPUs mmio region
12:45macc24: because this is how it is on my computer
12:45karolherbst: the vbios contains a parser, nouveau contains one
12:46karolherbst: and used to init the gpu
12:48RSpliet: For the sake of argument: don't forget that all this init stuff isn't GPU specific, it's *graphics card* specific. NVIDIA provides the GPU, OEMs pick the RAM chips, temperature sensors, display outputs, type of fan etc. etc.
12:48macc24: RSpliet: i want to target integrated gpu
12:48karolherbst: doesn't make a big difference
12:48karolherbst: you essentially only skip the VRAM and fan bits
12:49macc24: ram is done, temperature can be ommited, fan too
12:49karolherbst: why can temperature be ommited?
12:49karolherbst: the GPU gets hot too
12:49macc24: because if gpu overheats, it's by bad design
12:49karolherbst: of the laptop, zes
12:49karolherbst: we still need to detect that in the driver
12:49macc24: or at least it's not needed for init
12:50macc24: >display outputs
12:50macc24: that can go in devicetree of coreboot
12:50karolherbst: it can't
12:50RSpliet: macc24: VBIOS and device tree aren't much different conceptually
12:50karolherbst: maybe for your system specifically yes
12:50karolherbst: but then there is nothing we can help you with
12:50macc24: im talking about integrated gpus
12:50macc24: so it is board specific
12:50karolherbst: those aren't special
12:51macc24: and it can go in board-specific files
12:51karolherbst: then you can do it for every single laptop out there
12:51karolherbst: have fun
12:51macc24: that's done anyway when porting coreboot
12:52karolherbst: I mean, you can do whatever you want, I am ust saying it doesn't solve any problems
12:52RSpliet: Let me repeat that, I don't want a good point to go to waste
12:52RSpliet: macc24: VBIOS and device tree aren't much different conceptually
12:53macc24: RSpliet: vbios does gpu init too
12:53karolherbst: it doesn't
12:53RSpliet: macc24: not automatically
12:53karolherbst: the firmware or the kernel do
12:53karolherbst: or the gpu on new gpus
12:53RSpliet: There's a tiny bit of x86 code embedded that you can choose to run or not.
12:53macc24: vbios inits the gpu
12:53karolherbst: it doesn't ;)
12:53macc24: RSpliet: yes and i want to replace that code
12:54RSpliet: Start by not having coreboot jump to that code. Problem solved.
12:54karolherbst: well, the x86 code isn't that big actually
12:55karolherbst: just contains a very basic vbios parser
12:55karolherbst: and a devinit script parser
12:55macc24: RSpliet: i want to replace it, not ommit
12:55macc24: RSpliet: i want to have display in payload
12:55macc24: before linux
12:55karolherbst: macc24: yes, then you need to implement a vbios table parser in coreboot
12:55karolherbst: and do whatever nouveau does in terms of devinit
12:55macc24: karolherbst: that is already done
12:56macc24: now you're talking
12:56macc24: what does devinit do exactly?
12:56karolherbst: we do detection of whether the GPU was inited by firmware or not
12:56macc24: how long would it take to port it/rewrite it to make it run on coreboot
12:56karolherbst: and if not (like with runtime suspended GPUs in laptops) we execute devinit inside nouveau
12:57karolherbst: macc24: it's... quite some code actually
12:57macc24: how long in sloc is that code?
12:57karolherbst: depends on the generation though
12:57karolherbst: if you cover all gens? probablz 2-3k
12:57karolherbst: for mcp78 probably 1.5k or something
12:57karolherbst: parsing the devionit script is trivial, but a lot of code
12:57macc24: probably similar to southbridge part of mcp78
12:58karolherbst: uhh wait
12:58karolherbst: that doesn't contain the parser I think...
12:58macc24: no need for parser
12:58karolherbst: well, you do
12:59macc24: code will get what it needs from devicetree
12:59karolherbst: no, it won't
12:59karolherbst: it's not how it works
12:59karolherbst: you actually need to program the GPU
12:59karolherbst: that's what devinit is for
13:00RSpliet: Okay, step back
13:00macc24: yea, and why devinit can't get stuff from devicetree?
13:00RSpliet: The term "VBIOS" is used to describe a file format containing three things
13:00karolherbst: you could of course extract the devinit script from vbios and put it into device tree
13:00karolherbst: you still need a parser ;)
13:01RSpliet: 1. Tables that describe the hardware on the specific card, just like device tree does for your motherboard
13:01RSpliet: 2. A couple of scripts, sequences of "ok now write value X to register y, wait 100ns, write value z to register w" etc
13:01RSpliet: 3. A bit of X86 code that can run some of these scripts
13:02RSpliet: Nouveau reimplements 3, such that there's no need to run unaudited x86 code. Coreboot can do the same
13:02karolherbst: RSpliet: I don't think you could even run the code with a running kernel even if you wanted to :p
13:03macc24: RSpliet: what happens on resume of pc?
13:03RSpliet: karolherbst: you are absolutely right, but it's slightly beside the point :-)
13:03karolherbst: macc24: we do devinit in nouveau
13:03karolherbst: I think....
13:03karolherbst: yeah.. on resume we do
13:04RSpliet: macc24: "do devinit" -> take a script from 2, and run it through our own reimplementation of 3.
13:04macc24: so open source replacement for vbios is possible without reverse engineering
13:04karolherbst: no ;)
13:04karolherbst: open source replacement of x86 vbios code, yes
13:04macc24: RSpliet: how gpu-specific is that?
13:05RSpliet: it's graphics card specific even
13:05RSpliet: (or IGP, or, you know)
13:06karolherbst: but again
13:06karolherbst: it doesn't solve any problems copying those scripts
13:06karolherbst: thosre are harmless by themselves
13:06karolherbst: well.. to some degree
13:06karolherbst: you still deal with hardware on a pcie bus
13:06karolherbst: and this hardware has full RAM access
13:08karolherbst: but that doesn't matter as long as coreboot has its code sections under control
13:08macc24: i don't really care about proprietary stuff
13:08karolherbst: and detects hardware messing around with code
13:08macc24: but i care about garbage proprietary stuff
13:08macc24: which is vgabios
13:08karolherbst: why is it garbage?
13:08karolherbst: it's very useful
13:09karolherbst: allows us to write a driver working on every gPU
13:09macc24: it can't do linear framebuffer
13:09karolherbst: not just a hand ful
13:09karolherbst: ahh yeah...
13:09karolherbst: well. you can also port nouveau to coreboot if you want to
13:09macc24: karolherbst: do you happen to know southbridge parts of mcp chipsets?
13:10macc24: not just gpu
13:10karolherbst: I looked into nvidia ethernet controllers at some point though...
13:10karolherbst: but no other bits
13:12karolherbst: anyway, the big advantage of the vbios stuff is you don't need firmware level support for the GPU. You run the code, it parses the devinit scripts, and then you get a framebuffer the firmware can use
13:12karolherbst: if you want to move beyond that, you need an actual GPU driver inside coreboot
13:12karolherbst: which... I don't think is something coreboot devs really want to spend their time on
13:13karolherbst: it's a lot of work and you need to catch up with every single new GPU
13:13RSpliet: macc24: try and shift away from the "all or nothing" view of VBIOS. I broke it down to it's three components for a reason: 1 and 2 aren't garbage but vital information for operating the graphics card. Also, what you call "vgabios" I'm not 100% sure is the same thing
13:13karolherbst: RSpliet: it is ;) it has just many names
13:14RSpliet: karolherbst: are you sure? I think the "can't do linear framebuffer" thing is a property of the "VGA" interface that every (older) graphics card has from every vendor. Like, the 0x600xxx registers, or wherever they're located (can't remember)
13:15RSpliet: A very limited interface to make any graphics card do display, without a driver.
13:15karolherbst: right, but we still need to do hardware initialization and stuff
13:15karolherbst: you can't get around this part
13:16RSpliet: The point being, that 0x600xxx register range to get a working display at a useful resolution isn't operated by the VBIOS, but by the regular BIOS.... I think.
13:16karolherbst: anyway, macc24 mentioned vbt which is the same bit
13:16karolherbst: yeah.. might be
13:17karolherbst: there is the int 10h interrupt stuff and then the VGA bits and so on...
13:17karolherbst: this is all a bit beyond me to be honest
13:18RSpliet: karolherbst: the details are hazy for me too, I rely on dinosaurs like imirkin to know this ;-)
13:18karolherbst: it doesn't change the implications though
13:18karolherbst: firmware needs to init the GPU and if it wants to do anything outside the original BIOs/VGA specs, it needs a GPU driver
13:19RSpliet: karolherbst: It's more that... before anyone calls VBIOS garbage, it'd be good to actually be informed on what it is and isn't :-)
13:21karolherbst: macc24: but to come back to your original question/concern: yes you can do all of that without having to run untrusted code. It just simply doesn't mean you also have to get rid of the vbios ;)
13:22RSpliet: "it wants to do anything outside the original BIOs/VGA specs, it needs a GPU driver" Oh 100%. Not as full-featured as nouveau I'm sure, but VBIOS parsing + init script running + display + basic memory management at least.
13:22imirkin: i saw my name mentioned, but there's a long wall of text... anything i need to answer?
13:22RSpliet: imirkin: nah, I was poking fun at your knowledge of legacy :-)
13:22karolherbst: imirkin: no
13:23imirkin: and yes, i do remember the day the dinosaurs died
13:23karolherbst: imirkin: I diged through the gitlab issues to find if somebody reported that reviewing on gitlab sucks
13:23karolherbst: there are some reports...
13:23imirkin: karolherbst: i (partly) wrote a tool at G to do code reviews
13:23imirkin: so i know something about how online code reviews can be good
13:23imirkin: gitlab ain't it.
13:24karolherbst: yeah.. but they could at least show the comments in the commit view
13:24karolherbst: would be a start
13:24imirkin: thing that kills me is that gitlab is just plain SLOW to load
13:24imirkin: forget reviews
13:24imirkin: like anything there. takes forever.
13:24karolherbst: it's not as slow as that for me
13:25imirkin: well, i'm on a 10 year old system
13:25karolherbst: it's not fast, but also not slow
13:25karolherbst: ahh, yeah
13:25karolherbst: MR page load time is like 2.5 seconds for me
13:25imirkin: that's REALLY slow
13:26karolherbst: I've seen worse
13:26imirkin: why isn't it 0.05 seconds?
13:26karolherbst: it seems to have quite a huge initial latency
13:26imirkin: (ok, 50ms is ambitious... but 100ms should be quite achievable)
13:26karolherbst: let me check _what_ is actually slow
13:26orbea: (honestly its a terrible site right there next to github)
13:26karolherbst: 1 second for the initial request
13:27karolherbst: that's.. bad
13:27karolherbst: so one second is wasted just by loading "index.html"
13:27karolherbst: orbea: forget those scripts, those aren't the issue
13:27imirkin: sounds like it's probably as slow for me as it is for you, and i have higher standards? :p
13:27karolherbst: imirkin: I just know super slow sites
13:28imirkin: i do too! gitlab!
13:28karolherbst: RH bugzilla is slow
13:28imirkin: really? i've not used the RH one much, bug in generally bz is pretty snappy
13:28karolherbst: it's _slow_
13:28imirkin: the gentoo one, the old fd.o one
13:28karolherbst: just open that
13:28imirkin: that loaded ok... says i don't have permissions to access tho
13:29karolherbst: ohh.. heh
13:29karolherbst: so then it's faster?
13:29imirkin: probably :)
13:29karolherbst: well, it took around 15 seconds here :)
13:29orbea: maybe its slower when its not access denied
13:29karolherbst: imirkin: https://bugzilla.redhat.com/show_bug.cgi?id=1046262
13:30karolherbst: if you need to work with that more often, 2.5 seconds ain't that bad anymore :p
13:30imirkin: karolherbst: took like .25s
13:30orbea: slower, but still relatively fast
13:30imirkin: i can check the logs, that was my feel for it though
13:30imirkin: if the logs come out to 0.5s, i wouldn't be terribly surprised
13:31karolherbst: heh interesting
13:31karolherbst: it's the sso bits I think
13:31karolherbst: logged out -> fast
13:31karolherbst: or well.. faster
13:31imirkin: ah, well that's just delightful
13:31RSpliet: for RHBZ or gitlab?
13:31orbea: there is also the way gitlab was designed that makes it slow, i understand it loads a framework which then loads the content, so potentially a lot of steps to load
13:31karolherbst: I have some sso hooks
13:31karolherbst: for .. sso :p
13:32karolherbst: there is still this 2 second initialy delay
13:32RSpliet: "I'm not slacking off, my browser's loading a bug report" I say, as I continue my light sabre battle
13:34karolherbst: TTFB is like 14 seconds
13:34karolherbst: in chromium
13:34karolherbst: well, same with firefox
13:35orbea: well it could be worse than gitlab, like sourceforge :P
13:36karolherbst: but I've also seen fast gitlab instances
13:36karolherbst: most.. are just not fast
13:36karolherbst: or the servers are the big weak point
13:37karolherbst: anyway, reviewing on gitlab sucks, this is what annoys me the most
13:38karolherbst: and networked databases
14:59wenzel62: I'm experiencing a nouveau crash on my laptop, with nvidia RTX 2060 Mobile
14:59imirkin: pastebin dmesg?
15:00wenzel62: you can see a demo here: https://launchpadlibrarian.net/470996774/nouveau_crash.webm
15:00wenzel62: basically spamming dmesg with FIFO sched errors
15:00karolherbst: that's turing, right?
15:00karolherbst: wenzel62: what kernel are you running on?
15:01karolherbst: ohh mhhh
15:01wenzel62: 5.3.0-42-generic, Ubuntu 19.10
15:01karolherbst: wenzel62: can you pastebin your dmesg output?
15:01wenzel62: I have a bug report on launchpad, since a few months: https://bugs.launchpad.net/ubuntu/+source/nouveau-firmware/+bug/1849637
15:02karolherbst: yeah.. it's not enough information
15:02karolherbst: I really need your full dmesg
15:02wenzel62: is this one enough ? https://gist.github.com/Wenzel/d37f032a4087c1b8c455e9eb9930eb1a
15:02karolherbst: I expect the runpm bug we are aware of, but I still want to verify it
15:02karolherbst: sadly not
15:03wenzel62: since nouveau is spamming dmesg, the beginning of the buffer was already rewritten
15:03karolherbst: wenzel62: what do you do to trigger it?
15:03wenzel62: I just boot my computer
15:03wenzel62: I'm loggin in into gnome-shell, and dmesg is already spammed by nouveau
15:04wenzel62: it's 100% reproducible
15:04karolherbst: do you know if it's fine if you don't login yet?
15:04wenzel62: I haven't tried I have to say
15:04karolherbst: because then you could do dmesg -w > dmesg.log in a tty
15:04karolherbst: and sync often so it gets written before it crashes
15:04wenzel62: you want to check if gnome-shell is triggering this
15:05karolherbst: not really. I just want to know what's at the start in the log :)
15:05karolherbst: journalctl --dmesg should also have it though
15:06wenzel62: yes, I have the log with journalctl --dmesg -b -1
15:07karolherbst: yeah, maybe that would help. the one in the bug is also cut of at the start
15:08wenzel62: here you go: https://gist.github.com/Wenzel/89a78af82eafb6e50e6da932e95c50f9
15:09wenzel62: not enough ? :(
15:09karolherbst: no.. it's fine
15:09karolherbst: the issue is just.... ufff
15:09karolherbst: a mix of multiple bugs
15:10wenzel62: do you have devs working with Canonical ?
15:10wenzel62: because my bug reports were left untouched for months, even though I had a repro with demo and logs
15:11wenzel62: otherwise I wouldn't have come here
15:11imirkin: no one from canonical in here, afaik
15:11imirkin: (at least not working on nouveau)
15:12karolherbst: it usually makes sense to report bugs upstream anyway
15:12imirkin: RH is the only company that actively sponsors nouveau development, afaik
15:13karolherbst: that " nouveau 0000:01:00.0: tmr: stalled at ffffffffffffffff" line worries me
15:13karolherbst: as it doesn't look like runpm happens
15:13imirkin: that's a pm issue, presumably
15:13imirkin: wenzel62: try booting with nouveau.runpm=0
15:13imirkin: see if that fixes everything
15:13karolherbst: imirkin: I doubt it
15:13imirkin: easy to test :)
15:14karolherbst: I think I know what happens
15:14karolherbst: we are stuck in a loop somewhere and the meantime we runtime suspend
15:14karolherbst: or the gpu just falls of the bus
15:14wenzel62: about bug report, this is written in your policy:
15:14wenzel62: "If you are using packages from your distribution and are unable/unwilling to test the latest versions of all the pieces of nouveau, send the bug reports to your distribution and not directly to us"
15:14karolherbst: wenzel62: I assume your laptop is super hot?
15:14wenzel62: that's why I didn't do an upstream report
15:14imirkin: wenzel62: that's accurate.
15:15karolherbst: I guess there is heavy load on the system
15:15imirkin: if you can't test our suggestions, no point in telling us about the issues.
15:15karolherbst: as the CPU reports high temps
15:15wenzel62: i haven't checked the temperature, can't remeber the fans speed, I just rebooted
15:15karolherbst: well "mars 27 15:44:02 Strix kernel: mce: CPU4: Package temperature above threshold, cpu clock throttled (total events = 2024)"
15:16karolherbst: ttm eviction fails
15:16karolherbst: it takes forever
15:16karolherbst: we runpm and the tmr reports garbage
15:16imirkin: tmr should take a reference, hopefully
15:16karolherbst: but that doesn't explain the initial errors
15:16karolherbst: imirkin: already done in the tree afaik
15:16imirkin: yeah, thought i saw something about that
15:16imirkin: but wouldn't be in v5.3
15:17karolherbst: but this is just fallout from the actual issue
15:17karolherbst: so the first error is this stuff: nouveau 0000:01:00.0: fifo: fault 09 [PHYS_WRITE] at 000000017fef0000 engine c0 [BAR2] client 08 [HUB/HOST_CPU_NB] reason 0d [REGION_VIOLATION] on channel -1 [0000000000 unknown]
15:17karolherbst: and I would assume that's arlready fixed
15:17karolherbst: turing being new and 5.3 not that new
15:18karolherbst: and 5.3 is EOL anyway
15:18karolherbst: I am sure that runpm=0 will prevent the system from crashing though
15:19wenzel62: how can I put that setting ? on the grub kernel line ?
15:19imirkin: or however you boot
15:19wenzel62: ok, i need to switch back to nouveau, give me a few minutes
15:26wenzel62: so, I'm back, running with nouveau.runpm=0
15:26wenzel62: nothing in dmesg so far
15:28karolherbst: wenzel62: not even those fault messages?
15:28imirkin: note that the gpu will no longer suspend, so your battery life is now reduced
15:28wenzel62: no nothing
15:29wenzel62: no faults about nvidia or nouveau
15:29karolherbst: mhhhh, interesting
15:32karolherbst: wenzel62: and I guess without runpm=0 you can still reproduce the issue right now?
15:32karolherbst: not that something else changed as well
15:34wenzel62: i'm betting i can repro, because yes, nothing changed apart from runpm=0
15:35imirkin: karolherbst: maybe it's the same controller issue?
15:35imirkin: (or at least fixed in the same way)
15:35karolherbst: the kernel complains if something goes wrong with runtime resume
15:35imirkin: ah ok
15:35karolherbst: yeah.. that's why I am a little confused
15:35karolherbst: also that apparently nouveau does something
15:36karolherbst: normally the kernel throws out some nouveau 0000:01:00.0: Refused to change power state, currently in D3
15:36karolherbst: but who knows... maybe something odd happens
15:36karolherbst: could be bad timing of stuff
15:37karolherbst: device spamming interrupts while it's suspended
15:38karolherbst: imirkin: ehh.. I should have looked at the stack
15:38karolherbst: so runtime suspend triggers a ttm eviction which fails
15:39karolherbst: but mhh, dunno if this is outfall or not
15:40karolherbst: wenzel62: would it be possible for you to test with a newer kernel?
15:40karolherbst: imirkin: also we know of some turing laptops which apparently do not have the runpm bug even with the same controller
15:40wenzel62: if it leaves no traces afterwards, yeah.
15:40wenzel62: i need to compile the latest kernel from github ?
15:40karolherbst: there are easier ways
15:41karolherbst: wenzel62: what ubuntu version are you on? 19.10?
15:42karolherbst: the ubuntu package search website is indeed broken since some time
15:44karolherbst: wenzel62: there is a kernel-ppa
15:44imirkin: karolherbst: presumably with better ACPI code
15:47karolherbst: ahh ehh, the developers made it painful, nice
15:49karolherbst: wenzel62: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.5.13/
15:49karolherbst: apparently it's painful on pupose
15:50karolherbst: apparently you download the correct files and install them
15:50karolherbst: here the wiki: https://wiki.ubuntu.com/Kernel/MainlineBuilds
15:53karolherbst: but at least you can uninstall the kenrel later on
15:54wenzel62: I'm installing 5.5.13
15:56karolherbst: imirkin: heh.. do we want to make a bet how long it takes until somebody tells mmenzyns to use gitlab again? :p
15:56imirkin: don't care.
15:57karolherbst: heh :D
15:57mmenzyns: its hard
15:58karolherbst: what is hard?
15:58wenzel62: should i reboot with runpm=0 again ?
15:58imirkin: typing git send-email. so many keys to press.
15:58karolherbst: wenzel62: on 5.5? I'd try without it
15:59mmenzyns: that I am ok with both but one group uses that and other that
15:59karolherbst: yeah.. I mean it's fine if some use something else, there are just other issues more on the management side
15:59wenzel62: installation fails for the headers package
15:59wenzel62: impossible to compile virtualbox modules
15:59karolherbst: like making a decision without asking and then enforce it on everybody
15:59wenzel62: i guess i can skip the linux-headers ?
16:00karolherbst: *making a non konsensual decision
16:00karolherbst: wenzel62: if you have no modules installed, then probably yes
16:00karolherbst: doesn't hurt though
16:01karolherbst: I am not against using gitlab, but if not everybody is fine with it, I won't enforce it
16:01mmenzyns: I understand that people are comfortable in with what they did for years but if we stick to old things we would be still coding in assembly
16:01karolherbst: and I wished others would be like that as well
16:01karolherbst: ohh, there are valid concerns on gitlab
16:01karolherbst: reviewing on gitlab sucks a bit
16:01karolherbst: like if I leave a comment in the commit tab, it disappears after hitting send
16:01karolherbst: and it only shows in the discussion tab
16:02karolherbst: sucks if you go back and you don't know for sure if you already commented on that or not
16:02mmenzyns: thats bad
16:03karolherbst: you see the comments if you don't select a commit though
16:03karolherbst: so if you have 50 commits and just go to changes it works
16:03karolherbst: but if you comment on every commit explicitly, it doens't
16:03mmenzyns: that is a small thing but one thing that is not clear at all is that when you are commenting some line it doesnt tell you that the line person is commenting is the last line in the code block, you need to figure it out yourself
16:04mmenzyns: I should have read it after myself
16:04karolherbst: I mean there are some issues.. I just don't see a big enough focus from gitlab side to fix any of that
16:04karolherbst: I am even thinking of just fixing those issues myself :D
16:05mmenzyns: I wanted to say that when someone is commenting a code; it isn't clear what line the person is reffering to. It is last line but the person needs to know that.
16:05karolherbst: yeah.. but that's no different than with email
16:05mmenzyns: yeah but with email it is indented and you clearly see someone added message between the code
16:06wenzel62: running on 5.5.13
16:06wenzel62: i have one red ligne in dmesg
16:06wenzel62: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=4406 end=4407) time 3515 us, min 1062, max 1079, scanline start 904, end 304
16:06karolherbst: wenzel62: but otherwise the nouveau stuff works?
16:06karolherbst: try "lspci" :D
16:06karolherbst: usually that kills stuff if you got the runpm bug
16:07wenzel62: Kernel modules: nvidiafb, nouveau
16:07karolherbst: I meant, there are no random messages anymore in dmesg like with 5.3, right?
16:07wenzel62: no, they are gone
16:07karolherbst: and lspci also doens't kill your machine I assume
16:07wenzel62: why would it do that ?
16:08karolherbst: you don't want to know :p
16:08karolherbst: cat /sys/bus/pci/devices/0000\:01\:00.0/power/runtime_status
16:08karolherbst: returns suspended, right?
16:08wenzel62: cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
16:08wenzel62: yes suspended
16:09karolherbst: well.. there are two things you could do now: 1. check if it works with 5.4 and move to 20.04 2. update your 5.5 kernel yourself
16:10karolherbst: 20.04 uses 5.4 afaik
16:10karolherbst: 5.3 is already EOL so we can't fix it there :p
16:10karolherbst: but cannonical would have to
16:10wenzel62: yeah, i will upgrade to 20.04 when it will be released
16:11karolherbst: well, you can already move to 20.04 if you really want to
16:11karolherbst: just means you might run into random bugs
16:11karolherbst: the apt repositories already exist
16:12wenzel62: i prefer to wait for the official release, there is no rush
16:12wenzel62: i needed the nouveau driver to boot on Xen
16:13wenzel62: ATM xen refused to boot my gnome-shell, i have not gui
16:13wenzel62: and i suspected a bug in the nvidia driver, i had suspicious entries in dmesg
16:13karolherbst: anyway, good to know it's not a runpm bug, so you can have the GPU be turned of
16:14wenzel62: yeah, thank you guys !
16:15karolherbst: wenzel62: I think some even wrote scripts to manage the kernel ppa
16:15karolherbst: but I have no clue about it, so I didn't want tor recommend anything there