00:00imirkin_: (1366 isn't divisible by 8, and 8 is a factor that's used in a lot of places)
00:00pedahzur: I figured with a laptop this old, all those bugs would be worked out by now. :)
00:00imirkin_: laptops are all special
00:00imirkin_: and as a developer, you tend not to get too many of them
00:01imirkin_: like when i go on ebay to buy a gpu to test something on, i just get a board for $10
00:01imirkin_: not a laptop for $200 or whatever
00:02imirkin_: i have something like 20 GPUs stuffed in a drawer ... can't do that with laptops
00:02pedahzur: I did try ctrl-alt-f1; ctrl-alt-f7, but that didn't seem to work. I don't know if the chvt command would do something they keyboard command doesn't?
00:02imirkin_: chvt is exactly that
00:02imirkin_: so if that doesn't help, nevermind
00:02imirkin_: changing resolutions should trigger a modeset
00:02imirkin_: e.g. xrandr -s 640x480; xrandr -s 1366x768
00:03imirkin_: well - it's a laptop panel, so we actually have a scaler turned on
00:03imirkin_: to scale to native resolution
00:03imirkin_: since the panel doesn't support multiple modes
00:03imirkin_: however i think we still trigger a modeset, even though it's the same ultimate resolution
00:03imirkin_: you can also force-disable the scaler
00:03pedahzur: When I try to do it from a script (and not the logged in user) it xrandr says it can't connect, so...??
00:03imirkin_: it's an xrandr property
00:04imirkin_: is it running as root?
00:04pedahzur: I tried both ssh'ed in as the user that was logged in to X and as root (sudo)
00:04imirkin_: if so, you can just do XAUTHORITY=/home/you/.Xauthority DISPLAY=:0 xrandr bla
00:05imirkin_: (totally a hack, but hey, whatever works)
00:05pedahzur: I'll try that.
00:06pedahzur: I'll just have to figure out the user logged in via X, and use that directory instead. :)
00:07imirkin_: or just assume it's you
00:07imirkin_: but really we should fix the underlying cause
00:07imirkin_: i suspect it's something simple
00:07imirkin_: if you're interested in assisting, of course
00:07imirkin_: skeggsb: any ideas about this --^
00:08imirkin_: eDP resume goes wrong in resume
00:08imirkin_: the display script is missing an OR link (? whatever that means)
00:08imirkin_: and then link training itself fails saying that it's an unsupported link rate
00:09imirkin_: on a GT218
00:09pedahzur: I'd be happy to help as much as I can. Certainly not a kernel dude...but have user/admin'ed Linux for over 20 years. :)
00:09imirkin_: cool. basically you'd have to provide logs, build kernels with patches, and then provide more logs
00:11skeggsb: a log with "log_buf_len=8M nouveau.debug=disp=trace,bios=trace,i2c=trace" would be a good first step
00:13pedahzur: skeggsb: nouveau.debug=disp=trace ? or nouveau.debug=debug,disp-trace ?
00:13skeggsb: exactly as i wrote it
00:14skeggsb: nouveau.debug=trace would probably do too, but i can't remember how much other junk would get output too
00:14imirkin_:likes to throw drm.debug=0x1e in there too, to see what the rest of the drm system is doing
00:15skeggsb: rarely relevant for this stuff, but, sometimes :P
00:15imirkin_: yeah, more relevant for debugging straight up failures
00:16imirkin_: or perhaps just more relevant to those of us who don't remmeber all the disp methods by heart
00:16imirkin_: those *few* of us, i should say... :)
00:16skeggsb:doesn't know those by heart either
00:17imirkin_: uh huh
00:17skeggsb: used to, but too many GPU variants now
00:17imirkin_: yeah, they keep making more GPU generations, but they don't make more of you =/
00:22pedahzur: imirkin_: Tried with the XAUTHORITY and DISPLAY variables...got further, but now xrandr complains "xrandr: Configure crtc 0 failed" So...dunno. :)
00:22imirkin_: yeah, i guess modesetting is pretty messed up
00:22imirkin_: should just fix it for real ... get skeggsb some logs
00:22skeggsb: pedahzur: oh btw, to keep things simpler.. when you get the log, boot to runlevel 3, and take X out of the equation
00:23skeggsb: "echo mem > /sys/power/state" to suspend from there
00:27pedahzur: skeggsb: Oh, that's lovely. When I append 3 to the kernel command line, I don't get any VT at all. I'll fiddle with the command line some more. Maybe some variables in there messing with it.
00:27imirkin_: do you get VTs if you boot into X?
00:28imirkin_: this stuff is controlled via /etc/inittab ... unless you're on systemd, in which case you're SOL
00:28pedahzur: Yeah, systemd. Ubuntu 19.10
00:29imirkin_: just need to read a million lines of code, and the answer should become apparent then.
00:29pedahzur: Ah, there we go. Removed the $vt_handoff variable from the grub boot line
00:31pedahzur: HAHAHAHAHAHAHAHA! I get right back to my VT, right where I left off, when I resume in runlevel 3. :P
00:31pedahzur: I guess my laptop hates me. :D
00:31skeggsb: well, that's less fun
00:31pedahzur: I guess I'm going to have to bring X into it.
00:32pedahzur: It was good idea, though...
00:32skeggsb: do you still get the "script needs OR link" message?
00:33pedahzur: Hmmm...this might be telling... Screen does NOT come back when I close the lid. PM scripts must be doing something different than just 'echo mem > /proc/sys/state'
00:33pedahzur: Let me take a look at the dmesg.
00:33imirkin_: hopefully they're not running vbetool?
00:34imirkin_: that's the sort of thing that was a good idea a very long time ago, but now it just breaks everything
00:34pedahzur: Yeah, I see the script needs OR link twice, about 75 seconds apart. That might be how far apart my resumes were.
00:35skeggsb: it's potentially not releavnt to the issue, but i want to find out why that's being hit anyway
00:35pedahzur: skeggsb: `which vbetool` and `dpkg -l|grep vbetool` don't return anything.
00:35pedahzur: Should I be looking elsewhere?
00:36imirkin_: welp, good luck.
00:42pedahzur: What is run when the lid closes? I am not finding anything useful /etc/pm/ nor /etc/acpi/. Lemme guess...it's systemd now?
00:43pedahzur: AGGGH. It is!
01:12pedahzur: I'll try to get additional logs soon.
01:18DeeEff_: Good day #nouveau! I just switched back to nouveau after having the worst time with nvidia driver upgrades, and wanted to know if it's possible to get better performance with my 750Ti. I've tried "echo 0a > /sys/kernel/debug/dri/0/pstate" but there seems to be no folders in /sys/kernel/debug. Any surface level advice?
01:23Tashtari: Hi all. Was hoping someone could point me in the right direction with an issue I'm having with nouveau... on boot, I get this: nouveau 0000:01:00.0: disp: ERROR 1 [PUSHBUFFER_ERR] 02  chid 0 mthd 0000 data 00000400 (and then again with chid 1)
01:23Tashtari: then when I try to run startx, the console stays on the screen, frozen, and eventually after I get back to a console (which takes several seconds), I see messages in dmesg "nouveau 0000:01:00.0: DRM: core notifier timeout" and "nouveau 0000:01:00.0: DRM: base-0: timeout".
01:23Tashtari: My GPU is a GeForce 210.
02:30DeeEff_: Ah, nevermind my above question. Seems I need to mount the debugfs and I was not doing that by default
03:33imirkin: Tashtari: what kernel, and which GeForce 210 is it? G84, G98, or GT218?
03:33imirkin: Tashtari: actually a full boot log is probably good
03:34imirkin: also, is there anything odd about your configuration? e.g. you're using coreboot, or something else non-standard?
03:42Tashtari: imirkin: If I admit to using coreboot, is that an "all bets are off" situation? :)
03:43imirkin: but it informs what could be going wrong
03:44Tashtari: Ok. Hang on, let me get some more info here...
03:44imirkin: other platform weirdness, e.g. being on non-x86
03:49Tashtari: imirkin: http://paste.debian.net/1125781/ <- Bootlog
03:49Tashtari: imirkin: It is identified as a GT218.
03:52imirkin: ouch, it's just totally broken there =/
03:54Tashtari: Hmm. What about it suggests total brokenness?
03:54imirkin: the fact that you get that disp error so early
03:55imirkin: is this a warm reboot after nvidia blob was loaded?
03:55imirkin: although iirc vbios init cleared that...
03:58imirkin: it's saying mthod 0 data 400, although method 400 would make more sense
03:58imirkin: method 400 = configure DAC (i.e. vga)
04:00imirkin: this could be going wrong if dma / etc are set up slightly wrong
04:00imirkin: given that this is coreboot ... certainly a potential option.
04:01imirkin: Tashtari: do you know if coreboot runs the option roms?
04:02imirkin: if not, could you try booting nouveau.config=NvForcePost=1 ?
04:04Tashtari: imirkin: As in, give that as a kernel command line parameter?
04:05Tashtari: Ok, trying that now.
04:05Tashtari: I'll make sure it's a cold boot, just for good measure...
04:07imirkin: do you get video output during boot before linux loads?
04:08Tashtari: I do. I was actually just thinking of that now, the coreboot payload is petitboot, which is itself linux, so maybe something is going awry with there being two back-to-back initializations?
04:12imirkin: well hopefully that stops running after handoff to the OS
04:13imirkin: but yeah, could be that it's not getting out of the way enough
04:13imirkin: or it's leaving things in an inappropriate state
04:13imirkin: NvForcePost should take care of it though
04:16Tashtari: That... looks a lot better, I'd cautiously say.
04:16imirkin: so yeah, i dunno what coreboot is doing, but it's not what the traditional bios does
04:17Tashtari: That's for sure. Is there a better way of hardcoding that option than sticking it in the kernel command line?
04:18imirkin: if it's compiled as a module, you can put it in /etc/modprobe.conf somewhere
04:22Tashtari: You've been a tremendous help; thank you kindly. =)
04:23imirkin: np, good luck!
04:31imirkin: Tashtari: btw, in case you want to play with h264 video decoding accel, have a look at https://nouveau.freedesktop.org/wiki/VideoAcceleration/
04:31imirkin: Tashtari: also btw2, you should have working reclocking on there - check /sys/kernel/debug/dri/0/pstate
04:34Tashtari: http://paste.debian.net/1125788/ <- pstate
04:34Tashtari: I'm without context, what does this mean?
04:48imirkin: it means you have 3 perf levels
04:48imirkin: you can switch between them by echo'ing 03/07/0f into that file
04:49imirkin: moar mhz == moar speed
04:49imirkin: (more speed == more heat/power usage)
14:13imirkin_: karolherbst: back at work?
14:14karolherbst: imirkin_: on the way
14:14karolherbst: in a train right now
14:14imirkin_: hehe ok
14:14imirkin_: down to a single GTF failure
14:15imirkin_: and in the past 30 seconds i actually developed an idea for what could be going wrong
14:15imirkin_: note to future-self: some of the buffers have 0 attributes, maybe they have to be explicitly disabled
14:15imirkin_: (basically PRIMITIVES_WRITTEN is 1 instead of 4 in one of the tests)
14:16karolherbst: well, I will be home in like 10 hours or so, but I try to work while on the way
14:17karolherbst: I've got power an wifi here.. so
14:17imirkin_: not an ideal place to work, then?
14:17karolherbst: well, it's not the most comfortable place
14:18imirkin_: but not the least? :)
14:18karolherbst: it's better than most trains actually, enough place to sit good enough and don't have to bend my arms in a wierd way
14:21imirkin_: hehe yeah, that's a common problem for me
17:15uis: Any RA news?
17:16karolherbst: uis: not quite sure which RA issue you hit, but I sent out a patch I don't like to fix one of those
17:16karolherbst: uis: https://lists.freedesktop.org/archives/mesa-dev/2019-November/223772.html
17:16karolherbst: but you might be affected by a different issue
17:17karolherbst: doesn't matter
17:17karolherbst: uis: did you encounter crashes or just the "spilling failed" messages?
17:18karolherbst: I might actually find some time this week to write a proper patch. Just a proper patch will be a lot of work as I would have to rewrite a lot of RA
17:21karolherbst: uis: anyway, if you encounter crashes, the linked patch should fix it. I just doubt that neither I nor imirkin would like to see that patch merged
17:21uis: I sent apitrace about month ago
17:22uis: ~19 oct
17:27karolherbst: uis: might have deleted it after I figured out which bug that is (as there are better ways to reproduce than apitraces)
20:04system32: Is there a 940M driver for loonix
20:04system32: Nvidia geforce 940 M
20:09joepublic: that's a, maxwell?
20:09system32: uh idk lemme google it
20:10system32: joepublic, yes its a maxwell card
20:10joepublic: according to the feature matrix, maxwell (NV110) has 3d acceleration support, https://nouveau.freedesktop.org/wiki/FeatureMatrix/
20:11system32: so uh what do i need to do?
20:11system32: do i need to download something?
20:11joepublic: nnouveau is part of the kernel, so you shouldn't need to download anything
20:12imirkin_: what's loonix?
20:12system32: ah. also, for gaming, should i switch to Nvidia drivers?
20:12system32: oh i should? well this may explain the lag
20:12imirkin_: assuming you're OK downloading code from the internet and running it at ring0
20:13system32: its from a trusted dev tho. nVidia
20:13imirkin_: if you say so.
20:13imirkin_: you're the one who has to be comfortable with it, not me
20:13system32: alright, thanks
20:14joepublic:personally doesn't trust proprietary EULA-based stuff and uses nouveau, lower frame rate or not
20:14system32: i mean, i dont see any other options
20:14system32: bruh this is a laptop
20:14imirkin_: so next time you get one, make sure it has an AMD gpu
20:15system32: but the AMD driver is proprietary too.(?)
20:16imirkin_: all code that runs on your CPU is upstream / open-source
20:16joepublic: amd has open source drivers - freely licensed drivers that depend on proprietary firmware for the card
20:16imirkin_: can't really get away from card firmware though
20:16imirkin_: and personally it doesn't bother me too much that they decided to make some of the GPU firmware-run.
20:17imirkin_: but it does bother joepublic
20:17imirkin_: so as before ... have to make decisions that work for you :)
20:17joepublic: firmware-run is fine, but where's the source? the toolset to build it? :)
20:17system32: btw. one last thing. i have a GT9400 in my old pc. i've been told Nouveau drivers are better for old GPUs
20:18imirkin_: they're not.
20:18karolherbst: joepublic: nowhere, but the firmware runs even before linux gets loaded, so you are screwed anyway :p
20:18imirkin_: this may have been true in a pre-3d-for-everything world
20:18imirkin_: but now that applications use a 3d render to draw each pixel, that's no longer the case
20:19karolherbst: imirkin_: btw, do you know if with UEFI we know have 32 bit code or still 16 bit code in the vbios to POST the card?
20:19imirkin_: karolherbst: haven't checked TBH
20:19system32: ah. ok so i'll use the nVidia driver for that too i guess
20:19karolherbst: I was under the impression intel wanted to get rid of all the 16 bit stuff
20:19system32: thanks bro
20:20imirkin_: karolherbst: it's supposed to contain a GOP driver though ... somewhere
20:20imirkin_: no clue what the bootstrapping mechanism is
20:20karolherbst: GOP was that BIOS stuff, right?
20:20imirkin_: GOP = driver for UEFI
20:20karolherbst: ahh, then yeah
20:20karolherbst: but uefi is either 32 or 64 bit
20:21imirkin_: in practice, 32
20:21imirkin_: 64 never took off, and they're incompatible
20:21karolherbst: well, I thought apple is doing 64 bit only by now
20:21imirkin_: but they're a locked-down platform
20:21imirkin_: so not relevant to general-purpose hw
20:21HdkR: Latest MacOS release is 64bit only atm
20:21karolherbst: well, linux still runs on it.. but that's only relevant for the bootloader anyway
20:22imirkin_: HdkR: the OS, or the UEFI firmware?
20:22karolherbst: HdkR: unrelated
20:22HdkR: Also they are locking down the ARM platforms to be 64bit only as well :)
20:22HdkR: OS, not sure what UEFI is doing on that platform
20:22imirkin_: HdkR: no more thumb mode? :)
20:22HdkR: ugh, murder thumb
20:23HdkR: The quicker we can kill AArch32 compatibility, the quicker we can remove the frontend decoder bloat
20:23karolherbst: seems like apple indeed ships 64 bit efi systems
20:23karolherbst: at least refind has 64 bit binaries
20:24karolherbst: imirkin_: actually.. my laptop also uses a 64 bit grub
20:24karolherbst: ... so
20:24karolherbst: I am sure, because I don't have a 32 bit one installed :)
20:25HdkR: Can't wait until we get to the point that the CPU just comes up in 32bit mode on x86 platforms :)
20:26karolherbst: HdkR: I think that is already the case if all legacy stuff is disabled, no?
20:26karolherbst: or did you mean 64 bit mode :p
20:26karolherbst: mhh, but yeah, maybe the CPU bootstraping still involves some 16 bit stuff? I hope not though
20:27HdkR: Yea, the initial bootstrap in BIOS/UEFI land still needs a mode switch somewhere
20:27karolherbst: uff.. btw, anybody any ideas what to use when kasan doesn't help?
22:34andres: Currently nouveau on my x1extreme gen2, with an intel and a mobile GTX 1650, doesn't work, not even just as an output provider / running with the modesetting driver. Is it worth investigating / writing bug reports etc, or is that pointless for the moment?
22:35imirkin_: the mobile bit makes things more complicated, with runpm
22:35Lyude: imirkin_: we're working on it
22:35karolherbst: but that's turing
22:35imirkin_: can you confirm it still doesn't work booting with nouveau.runpm=0 ?
22:35Lyude: andres: we're working on it
22:35karolherbst: imirkin_: won't help, it's turing ;)
22:35imirkin_: don't we have modesetting on turing?
22:35karolherbst: fun fact, runpm works on turing :p
22:35imirkin_: but no output offloading anyways
22:35Lyude: imirkin_: there's some issues with nouveau on turing regarding modesetting atm
22:36karolherbst: Lyude: we need acceleration for prime, no?
22:36Lyude: either me or skeggsb are planning on taking a look at them soon
22:36Lyude: karolherbst: not actually sure tbh
22:36andres: Lyude: Working, in the sense of bug reports/data isuseful? Or that noise would be distracting, and checking back later is better?
22:36Lyude: andres: basically the ladder yeah, I've already got a x1extreme 2nd gen next to me
22:37andres: Ok. Thanks!
23:48pedahzur: skeggsb and imirkin: I just e-mailed the list with the kernel logs after the additional debug flags you gave me. I'm ready and waiting for further instructions. :)