03:51lroop: Could someone here tell me where nouveau finds the BIOS for the GPU? Installing the nvidia proprietary drivers on my machine somehow caused the card to show up with PCI device ID 0001 instead of the correct one, and when I uninstalled the blob and tried to go back to nouveau I'm seeing a "bios: unable to locate usable image" error
03:51lroop: (This is on Debian testing on a ThinkPad T460s - Nvidia card in question is a GeForce 930M)
03:52lroop: FWIW if I boot the machine off of a live USB it does find/load the BIOS so I don't think it's a bad/unsupported GPU
05:13lroop: ah. the difference seems to be that the live USB was booting via EFI and I'm booting from disk with legacy BIOS. when I forced the live USB to boot with legacy BIOS nouveau couldn't find the nvbios either
07:46dcomp: I got it my GM108 working. I think it was a race. I loaded nouveau with NvClkMode and it started spewing SCHED FIFO ERROR 20; then unloaded it and then reloaded it and now it works
07:52dcomp: had to do the top in a vcon otherwise it wont unload because I think gnome-shell immediately tries to grab it
08:15rowbee: seriously screw nvidia
08:15rowbee: if i had to estimate, this game's performance is around 5-10x worse on linux than on windows and it's all nvidia's fault
08:16rowbee: i actually get 60fps, can you believe it?!
08:17rowbee: RSpliet, sorry for the ping but i found this: https://github.com/RSpliet/kernel-nouveau-nv50-pm/
08:17rowbee: might be useful? (not?)
08:17RSpliet: rowbee: that's my old tree... I made it work for exactly one card, and not to the top "performance mode"
08:18RSpliet: A good starting point if you want to pick up the work required for fermi clock changing, but...
08:19RSpliet: There's also this branch. Somehow the results need to be merged and forward-ported and fixed/tested for a far wider range of cards https://github.com/skeggsb/nouveau/tree/devel-clk
08:20RSpliet: Neither of those will "just work"
08:23rowbee: thanks, yeah i expect that lol
08:23rowbee: i'm currently battling with realtek
08:23rowbee: for the first time in 10 years windows does not understand how headphone jacks work. very interesting.
08:25rowbee: i wonder whether a device-independent solution could be reached...
08:29RSpliet: Given the amounts of quirks in snd-hda-intel (the Linux driver for all this sound stuff), I suspect the answer will be no.
08:30rowbee: no i mean, for reclocking
08:30rowbee: but the answer is no again i suppose
08:37RSpliet: Oh for reclocking yes there's definitely sort-of-device independent code possible, NVIDIA does it. All the info required for parameters come from VBIOS and the chip name/generation
08:37RSpliet: It's just that from reverse engineering you only see what you see. Unless you've seen every card out there, you don't know what you haven't encountered
08:39RSpliet: Pretty sure that the first card you support adds code for supporting that 1 card. The modifications you make for the second card adds support for like 60% of all cards. The third one brings it up to 90%, and from there on it just gets tedious (but progressively less work to spot the divergence)
08:40rowbee: i see
08:40RSpliet: The second tree I linked has been the result of very methodologically trying out all VBIOS bits rather than focussing on bringing up the first card ASAP. There's very valuable stuff in that tree that increase the chance of success for a wider range of cards :-)
08:42RSpliet: (Courtesy of Ben, who also wrote the Kepler clock changing code :-) )
08:55karolherbst: dcomp: interesting.. so yeah, seems like it's just the order of operation
08:55karolherbst: dcomp: and I assume without setting NvClkMode it will never work?
09:43dcomp: karolherbst: Will try now. I've been using runpm=0, do clocks get reloaded after suspend?
09:43karolherbst: but the order might be an issue again
09:44dcomp: So it should just work without a module reload?
09:44dcomp: Oh yeah, I'll try and see
09:48dcomp: So I get a whole load of mmio fault if I just load and unload the driver
09:49dcomp: I'm going to see if NvClkMode is required on the second load
09:55dcomp: It seems I don't need NvClkMode but I do need runpm=0
09:56dcomp: On second load that it. So the clock state is preserved as long as the card isn't suspended
09:57karolherbst: but we also have to fix the order of operations
09:57karolherbst: so before touching memory, we have to make sure that reclocking is finished if it's specified as an argument
10:02dcomp: Is it run in parallel now? Or has the order been changed since you wrote the reclocking code?
10:02karolherbst: mhhh, memory reclocking is done async
10:02karolherbst: the caller can just block on the result
10:02karolherbst: but the order can also be different..
10:02karolherbst: not quite sure
17:49hermier: hi, today my kernel was doing near to do some oom kill when it trigered this kernel error inside nouveau: https://dpaste.org/RuLo
18:43lroop: Well, I found a workaround to get the vbios to actually load on my machine.
18:44lroop: Somehow nouveau can't find it when booting from legacy BIOS but can with EFI, so I extracted the vbios.rom and added it to initramfs.
18:44karolherbst: lroop: does it work on windows?
18:44lroop: IDK if it's a problem with Lenovo's BIOS, a problem with Debian, or what
18:44lroop: yeah, works fine on Win10
18:44karolherbst: laptops started to ship the vbios through ACPI
18:45karolherbst: lroop: I meant in BIOS mode
18:45lroop: Not sure, I've never tried booting Windows in BIOS mode on that box
18:45karolherbst: at this point I have no idea if there is anything we can actually do about it
18:45karolherbst: but why not just use uefi?
18:45lroop: I probably will.
18:46karolherbst: I'd assume with uefi you also get better battery lifetime :)
18:46RSpliet: Is that VBIOS actually in ACPI on this machine?
18:46lroop: I'm puzzled that Debian installed to boot via legacy BIOS by default anyhow since the machine supports UEFI and the bootable USB drive I used can boot via UEFI
18:46lroop: That was actually how I figured out that it was a UEFI vs BIOS thing, looking through dmesg and noticing that the USB drive was booting via UEFI
18:47lroop: RSpliet: not sure, nouveau.config=NvBios=ACPI also did not find it
18:47RSpliet: lroop: I don't suppose you can grab a dmesg of Linux booting (and nouveau loading) while your laptop is in UEFI mode, and the VBIOS isn't snuck into initramfs? That should help confirm where the VBIOS is supposed to come from.
18:47lroop: I work with Linux for a living, but embedded ARM/FPGA stuff where the console is a serial port, so graphics drivers are not my specialty
18:48lroop: sure, that'd be easy enough to od
18:49lroop: The dmesg from a UEFI boot didn't seem to say where VBIOS was coming from unless I didn't know where to look
18:49RSpliet: karolherbst: does it still say in the logs?
18:49RSpliet:checks his own logs
18:50RSpliet: Oh... hmm... no you're right
18:51RSpliet: There's probably a debugging option that must be enabled for us to find out :-/
18:51dcomp: I know it says when you run with debug=debug
18:52RSpliet: it will say an awful lot with that set I presume :-D
18:52rowbee: RSpliet: alright, gonna try starting some work on reclocking. where to start?
18:52rowbee: currently getting 5.8.10 sources
18:53RSpliet: lroop: Also, in BIOS mode, have you tried booting with nouveau.config="NvForcePost=1" ?
18:53lroop: I haven't but can.
18:53lroop: Is that dmesg still useful, or not without the printout to say where it's getting VBIOS from
18:53RSpliet: lroop: nah, it wouldn't be, sorry
18:54RSpliet: It's been a while since I've done serious stuff with nouveau
18:54RSpliet: (and I work for a competitor now, so it's unlikely I will do serious stuff in the foreseeable future)
18:54lroop: fair. I never really touched it at all until I got to poking around with this issue last night.
18:55lroop: I've historically avoided laptops with upgraded GPUs but bought a couple of nice T460s cheap from my employer's surplus hardware sale because my wife's laptop is falling apart and mine's 8 years old
18:55RSpliet: if the NvForcePost=1 thing works (again, when the VBIOS isn't in an initramfs) it might hint at a quirky BIOS. Speaking of which, doesn't Lenovo do UEFI updates through fwupd ?
18:57RSpliet: Ah, yeh should do.
18:57RSpliet: lroop: you can try updating your "system firmware" using fwupdmgr if you haven't already.
18:58RSpliet: (Or if yo did actually mean a T460s -> https://fwupd.org/lvfs/devices/com.lenovo.ThinkPadN1CET.firmware )
18:59lroop: yeag, T460s
19:10rowbee: tee: /sys/kernel/debug/dri/0/pstate: Function not implemented
19:10rowbee: at least it's pretty honest
19:19rowbee: what is the pm_runtime* stuff in nouveau_debugfs.c for?
19:19RSpliet: Think that's for suspend/resume
19:19rowbee: from linux docs it just looks like acquiring a device counter
19:20rowbee: "increment the device’s usage counter, run pm_runtime_resume(dev) and return its result"
19:20RSpliet: as for getting Fermi clock changing working. The way forward is applying/forward-porting the patches from Ben's tree, then cherry-pick some of my changes, see if it works, if not, find out why (which _will_ require reverse engineering)
19:23rowbee: that's 98 commits
19:23RSpliet: Yep. They're all pretty small though
19:23RSpliet: He organised them one patch per... I think VBIOS bit/word
19:23rowbee: then let me see
19:24RSpliet: Well, all... most of them are small :-P
19:24rowbee: maybe i can merge them over to linux-5.8.6
19:25RSpliet: I don't expect major problems, most of them touch code that hasn't been touched in over a year. Some of them might complain a wee bit
19:25lroop: RSpliet: so, I did it from Windows but I did grab the latest firmware from Lenovo and install it
19:25rowbee: alright, let me merge them in order
19:26RSpliet: rowbee: Also, bear in mind, when I said "it'd take 2 months of work", I did mean it'd take me, or Ben two months. I think karolherbst could pull it off in two months. ;-) If any of them had the time that is.
19:26RSpliet: That being said, if you're up for the challenge you can learn a lot!
19:26RSpliet: And getting to the point where *your* card works will probably take a bit less work
19:27rowbee: yeah i'm just trying my luck
19:29RSpliet: rowbee: are you familiar with envytools?
19:30rowbee: i used nvapoke/nvapeek a bit before
19:31RSpliet: Ok. For this one you're also going to want to play with nvbios (grab yours from /sys/kernel/debug/dri/0/vbios.rom )
19:32RSpliet: And if things don't work, it is likely that you'll have to trace what the official driver does using mmiotrace - which is a kernel feature
19:32RSpliet: demmio is the tool in envytools that will make such a trace... more readable
19:33rowbee: i used mmiotrace before
19:33rowbee: and demmio too
19:33rowbee: when we were working on the backlight thing
19:33RSpliet: finally, nvafakebios allows you to make non-persistent modifications to the VBIOS, that will be undone on a reboot.
19:33rowbee: i see, that's helpful
19:33rowbee: is there any chance of me frying my gpu during this?
19:34RSpliet: The reverse-engineering cycle I tend to go through is 1) make a tiny modification to one of the relevant VBIOS values, 2) mmiotrace the official driver, 3) compare the trace with a trace from when the BIOS didn't have the modification.
19:34RSpliet: I haven't managed to fry my cards, and I've done this a *lot*. Including modest overclocks
19:35rowbee: i see, that's very useful
19:35RSpliet: Worst worst worst case, NVIDIA's thermal protection is reliable enough to prevent that from happening :-)
19:35RSpliet: But what you'll find is that quite often, you try changing a value in the VBIOS, and when you load the NVIDIA driver the card hangs or the output is garbled - and only the reset button will rescue your system.
19:37RSpliet: I had a separate external hard drive with a Linux installation on it with the official driver installed just for tracing
19:37RSpliet: That way, I don't have to constantly switch between the two installations, and if I happen to hang my system at the worst possible time (in the middle of writing back inportant data to my FS) I didn't risk losing anything important ;-)
19:37RSpliet: I'm pretty sure I was overly cautious on that front, but it served me well
19:39AndrewR: karolherbst, hello :} I was looking at OpenCL spec and there was cl_khr_gl_sharing section. I wa slike 'cool!' and then saw this: https://github.com/intel/compute-runtime/issues/166 (basically not implemented yet on linux). Do you work on something like this, or this is too early to ask ? (also i wonder if CL 1.2 style calls can be stuffed into nv50-era hw I have ...))
19:39rowbee: yeah that's certainly a good idea. i do have a 32gb flash drive, maybe i should make a small debian installation on it to boot from with the proprietary driver
19:40AndrewR: karolherbst, https://trac.ffmpeg.org/wiki/HWAccelIntro - ffmpeg apparently require CL 1.2 ...
19:41RSpliet: rowbee: yep, something that supports the NVIDIA legacy driver for Fermi would do. Mine is a 8yo Fedora installation, but with them defaulting to Wayland I'd recommend something else for the job today
19:42lroop: oh, that's the other funny thing with my VBIOS headache - the NVIDIA proprietary driver also wouldn't load, probably the same issue
19:43lroop: and I don't know if theirs has a magic kernel option for "here's the VBIOS, stupid"
19:43rowbee: just debian with nothing installed -> install xfce on it
19:44RSpliet: lroop: ehh... not sure. I don't think the NVIDIA driver takes kernel options at all (maybe they do since tying into drm)
19:45RSpliet: but you seem to have found a way of feeding it to nouveau by slipping it into your initramfs
19:46lroop: yeah, i'm just curious to see if their driver behaves with UEFI
19:46lroop: I suppose Lenovo may just assume that nobody's trying to boot a modern OS with legacy BIOS
19:47RSpliet: Or any OS really. Do you have a particular reason for booting through legacy BIOS mode?
19:48lroop: none at all other than the Debian installer deciding to install legacy grub.
19:48lroop: and I just haven't taken the time to go deal with it yet :-P
19:48RSpliet: Ah, right... yeah fair. That may just be the path of least resistance though
19:49RSpliet: I did at one point manually convert my drive to GPT and install a fresh grub on it. Just to prove I have balls of steel really...
19:50lroop: yeah, the nice thing here is that this isn't a mission-critical piece of hardware, I'm still using my old laptop and just trying to learn what hoops I'll have to jump through
20:15rowbee: error: drm/nouveau/nvif/vmm.c: does not exist in index
20:15rowbee: any ideas where this went?
20:17rowbee: oh i'm dumb. excuse me.
20:22rowbee: secboot directory actually doesn't exist though...
20:24dcomp: Anyone got any ideas on how to get mmiotrace to autodisable. I can't use it because nouveau spams so much of causes the system to hang. I'm not sure if this will work but I'm thinking of using an alarm timer to trigger a traceoff. Sound possible?
20:43karolherbst: AndrewR: I think it's too early at this point to care about extensions
20:47rowbee: there is a patch in the devel-clk tree that replaces probe_fbp stuff in the struct nvkm_ram_func for each individual ram* C file with fbpa stuff. is this normal/okay?
20:47rowbee: let me post the commit, one second.
20:50rowbee: i have no idea what this stuff does, so i can't say
21:02rowbee: in https://github.com/skeggsb/nouveau/commit/6f1c6fa7631561e1daef285d8972fc26d6cab072 you can see in nvkm_device_ctor there used to be a whole bunch of stuff after if (detect) that's gone in linux-5.8.10, was this stuff moved somewhere else or am i missing something?
21:03rowbee: nevermind, the mmio stuff just moved up-top. scratch the previous message
21:03lroop: RSpliet: yeah, NvForcePost=1 somehow causes it to work with an initrd that doesn't contain the VBIOS
21:05AndrewR: karolherbst, ok (my idea was to reuse some of this infrastructure: https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra-5.1/cinelerra/playback3d.C;h=9eee736f36d47d926bd6ca8909c03ec897c5ed52;hb=HEAD (sorry for long url). But without OpenGL sharing this will be not that easy ..
21:05AndrewR: karolherbst, but at least i found some more examples to test when nv50-ear support will reappear :}
21:07karolherbst: yeah.. I mean it is fine for others to work on new stuff :) I just don't have enough time to spend on non core features atm
21:07karolherbst: we actually have a MR to bringt clover up to 1.2
21:07karolherbst: so at least this part is more or less done
21:21rowbee: what is memx?
21:25AndrewR: karolherbst, but this will work only on nvc0 GPUs ? (OpenCL 1.2 via clover)
21:31ecv: Hi, ever since I updated my Ubuntu (18.04 or 1810) I started having issues with my laptop Intel/Nvidia hybrid Geforce GO 7300, getting all sorts of artifact in my desktop with skewing and out of proportion floating windows, things out of place and nuts. Luckily I was able to fix this (dont ask me how) on 19.10 but now on 20.04 I cant figure a work
21:31ecv: around anymore. I tried oibaf PPA VPAU (I think) drivers and the picture was clear but video playback super choppy and glxinfo reporting some vmware driver as vendor (??) Finally I gave up because at the very least maximized windows are for the most part readable and fullscreen stuff just fine and we use this laptop mainly as a media player.
21:31ecv: Anyways, I think these cards aren't supported by nvidia anymore. Aren't they supported by nouveau driver either? Or somehow the developers are not aware of this issue for so many months (year+)? Any idea how to fix this and get decent video playback?
21:38karolherbst: AndrewR: well.. nv50 has a few limitations so we can't use it with 1.2 but those are quite stupid limitations so it will just work for most workloads anyway
21:39AndrewR: karolherbst, then I'm looking forward into year 2021 :}
21:40imirkin: ecv: nouveau does support nv4x GPUs (of which your GeForce Go 7300 is one), however that support has always been, and continues to be, crap
21:40imirkin: ecv: unfortunately recent software relies more and more on solid and stable OpenGL drivers for drawing pixels to the screen
21:42imirkin: ecv: developers who care about nv4x (pretty much just me at this point, i'd guess?) aren't interested in making it work well with ubuntu. feel free to send patches.
21:42ecv: oh I see, thanks imirkin for clearing this up
21:43imirkin: fwiw, works perfectly fine with my environment. of course that environment hasn't changed in 20+ years.
21:43ecv: imirkin I'm afraid I don't have the knowledge nor the time for that... I guess it's a dead end
21:44ecv: oh I see
21:51ecv: imirkin: out of curiosity, what would be a good start point to check? I figure I'd need to install an older version of Ubuntu where nouveau is artifact free then compare the list of dependencies of one and the next version where it doesnt work well. Then start replacing packages one by one until it breaks or work. Then inspect that suspect for
21:51ecv: changes. Is this a correct approach or is it better to try these on different git versions?
21:52imirkin: ecv: i know nothing about ubuntu
21:52imirkin: my assumption is that they use various fanciness, which causes your issues.
21:52imirkin: obviously nothing to do with ubuntu itself, but rather the specific environment you've chosen (likely the default one)
21:53imirkin: a different choice is likely to yield better results for you
21:53imirkin: but may not have the UX you're used to
21:54ecv: an old version and flavor of Linux?
21:55imirkin: it's not about age of the version
21:55imirkin: it's about whether that software is based on OpenGL for everything or not
21:55ecv: what would you recommend imirkin?
21:55imirkin: if it's based on OpenGL, it won't work well
21:55imirkin: for you? no clue. i can tell you what i use. i can also tell you that you won't like it.
21:56imirkin: i use X (make sure it's using the nouveau ddx, none of the 'modeset' nonesense), i use WindowMaker for a window manager, and that's it.
21:56imirkin: no gnome, no kde, none of that bs
21:56ecv: I do like all the bells and whistles, but maybe if it's stable enough ...
21:56ecv: oh no LOL
21:56ecv: no way, thanks
21:56imirkin: told ya.
21:57imirkin: i haven't personally tested this, but i expect "xfce" may be more to your liking and will work better.
21:58ecv: so changing the WM might resolve this?
21:58imirkin: i don't know precisely what problems you're having
21:58imirkin: but it's likely that you're using a compositor or other environment which makes heavy use of GL
21:58imirkin: "don't do that" :)
21:58ecv: thanks a lot imirkin :)
21:59imirkin: also if you want to dump all the acceleration, you can just stick LIBGL_ALWAYS_SOFTWARE=1 into your environment
21:59ecv: I'll that a try
21:59imirkin: or boot with nouveau.noaccel=1
21:59ecv: no, I do need that for smooth videos
21:59imirkin: (the latter will also prevent you from having any acceleration in X)
21:59imirkin: if you want smooth videos, make sure you use 'xv' and not GL
21:59imirkin: basically GL = bad
22:00imirkin: if it uses GL, it won't work well.
22:00ecv: thanks :)
22:00imirkin: at best it'll be slow, at worst you'll get tons of artifacts and hangs.
22:00imirkin: the nv4x GL driver is designed for the occasional game, not for everyday software
22:02RSpliet: ecv: you could look into the Cinnamon software rendering thingmebob as well
22:02karolherbst: I guess if somebody really would have some time to spare.. somebody could fix nv4x :D
22:02imirkin: karolherbst: yep, of course
22:02imirkin: nothing intrinsic about the hardware that prevents making a solid and stable and conformant driver
22:02imirkin: patches welcome
22:03imirkin: however the current nv30 driver ain't it.
22:03karolherbst: I even have nv4x pcie cards....
22:03RSpliet: Pretty sure I have an nv4x AGP card
22:03RSpliet: time on the other hand
22:03imirkin: RSpliet: that's a bit of a rarity
22:04imirkin: there were native nv40 AGP's, and some nv4a's which were nv44's with something bolted onto them
22:04RSpliet: imirkin: I don't suppose you're talking about "worth the big bucks" kind of rarity
22:04RSpliet: Yeah, think this is an NV4B with a bridge bolted on one way or the other
22:04imirkin: nv4b would have been pcie-native
22:04imirkin: but yeah, nothing preventing people from adding 30 bridges to plug it into a VAX :)
22:05karolherbst: but do you actually see the bridge or is that all transparent?
22:05RSpliet: To be honest, I have no idea
22:05RSpliet: I bought it eons ago when my FX 5600 died. Turned out that was running without a fan for a solid year or so
22:06karolherbst: I have this 8600m or 8400m inside this macmini also comes without a fan
22:06RSpliet: Did wonder about the artefacts, but enjoyed the silence
22:06RSpliet: No it did come with a fan
22:06RSpliet: It's a GeForce FX
22:06imirkin: nv3x without a fan ... that's not a good combination
22:06RSpliet: They're basically electric heaters that can math
22:06karolherbst: tesla was insane
22:07imirkin: that's contestable...
22:07imirkin: i don't think they can do math.
22:07karolherbst: I think tesla was worse than anything
22:07imirkin: tesla wasn't bad
22:07karolherbst: tesla was fine with 130ºC
22:07imirkin: GF100 was bad.
22:07RSpliet: NV3x/NV4x was defo worse
22:07karolherbst: I meant in regards to heat
22:07RSpliet: NV3x/NV4x was defo worse
22:07imirkin: the GF100 even defeats FX 5900 or whatever it was
22:07karolherbst: oh.. really? insane
22:08RSpliet: Oh the FrankenFX?
22:08RSpliet: Those "we must ship NOW!" transition cards are never great
22:09RSpliet: Wasn't it the FX5200 where they thought "you know what, we'll bolt the old NV1x memory controller back on it!"?
22:09imirkin: tesla has memory partitions.
22:10imirkin: fermi has the GF108 where you randomly double everything
22:10karolherbst: but the gf100 isn't that hot...
22:10imirkin: karolherbst: GF100? it's hot.
22:10RSpliet: karolherbst: not at 50MHz ;-P
22:10imirkin: even at 50mhz :p
22:10karolherbst: so how hot did it got? :p
22:10RSpliet: The zeroes were a lawless hardware decade.
22:10imirkin: "NVIDIA Fermi GF100 GPUs - Too little, too late, too hot, and too expensive"
22:10karolherbst: 98 is like nothing
22:11karolherbst: my 8400m hits 98 as well
22:11imirkin: that's with fans.
22:11karolherbst: and? :p
22:11karolherbst: I didn't ask for TDP
22:11imirkin: and sucking down massive power.
22:11karolherbst: I did ask for the hottest card
22:11karolherbst: I know that tesla can safely reach 130
22:11imirkin: hottest cards are the ones in mupuf's oven then.
22:11karolherbst: at least some teslas
22:12imirkin: mine shuts down around 110 or 120 :)
22:12karolherbst: that's more than kepler/fermi :p
22:12RSpliet: Kepler/Fermi has power gating. The BLCG/ELPG stuff. Which is supposed to save power.
22:13karolherbst: mhh.. seems like nvidia says 105 for tesla
22:13RSpliet: And actual DVFS too for that matter.
22:14RSpliet: Yet... they've been the primary driver of obsoleting fireplaces
22:14RSpliet: Truth be told, think the NVA0 was a monstrocity too when it comes to power consumption
22:14imirkin: oh yeah.
22:14karolherbst: that for sure
22:15imirkin: GTX 280 / Quadro FX 3900 or whatever
22:15imirkin: but it also had jet engine-style fans
22:15karolherbst: ahh.. nvidia throttles tesla 1st gen at 110
22:15karolherbst: seems people even ran them at 120
22:15karolherbst:should check vbios again
22:15RSpliet: No no, those weren't jet-engine style. Those were actual jet engines. They couldn't fit more 8-pin power sockets on the board, so they had to resort to other means
22:16imirkin: i have the G92 variant of that Quadro FX -- it's no joke.
22:16karolherbst: the 8800 has tons of reports because people got worried about those 100+ ºC
22:16imirkin: sounds like a 747 is about to land
22:17RSpliet: Rightfully so, they were melting their own solder while rendering DOTA
22:17AndrewR: anongit.freedesktop.org timeouts for me ...
22:17karolherbst: I know that I checked someones computer which had a 8800 as he reported after an hour or so the GPU perf dropped
22:17karolherbst: the fan was broken :D
22:17imirkin: AndrewR: #freedesktop
22:17karolherbst: tesla was just insane...
22:17karolherbst: that 8400m I have.. it idles around 85ºC
22:17imirkin: RSpliet: well, ATI's were melting their own solder too
22:17AndrewR: imirkin, it was like this for half-day ... may be someone already noticed? But thnks never was on that ch
22:18imirkin: i think there was a global supply issue in solder or soemthing
22:18RSpliet: At least compared to NV3x/NV4x the Tesla got stuff done with all that power.
22:18imirkin: or maybe a technique for flow soldering got adopted which didn't work as well
22:18imirkin: or something. i forget. such a long time ago.
22:18RSpliet: imirkin: it was something to do with the solder becoming brittle over time due to repetetive heating up and cooling down
22:19karolherbst: RSpliet: yeah.. not a problem on tesla, the cards where just always hot :p
22:19imirkin: RSpliet: right, but ... not like that no longer happens.
22:19RSpliet: karolherbst: no, that was the source of regular failure with the 9600 or sth
22:19karolherbst: cooling too good?
22:19RSpliet: No, people had a tendency of shutting down their machine overnight because of the noise of those jet engines
22:21RSpliet: Oh yeah, it was the 9800. People actually called baking their card or butchering it with a hairdryer "reflow", with a similar irony of how staff at Starbucks are "baristas"
22:22RSpliet: Hmm, maybe bad example. How the teller with a coffee machine at your local petrol station is called a "barista"
22:22RSpliet: Anyway, you catch my drift
22:33ecv: hey, I'm so grateful. Thank you so much imirkin :) XFCE is working so good
22:34ecv: besides it looks much more complete than I remember. It looks very usable. Everything is working just fine
22:34ecv: thanks again
22:34karolherbst: ecv: you might want to enable compositing though/.. not sure if xfwm enables it by default these days or not
22:34karolherbst: makes things more enjoyable
22:39lroop: OK, so to close the loop on that VBIOS issue I was talking about - repartitioning the drive to boot from UEFI instead of legacy BIOS got rid of the issue, so I am guessing this is just a Lenovo BIOS issue and not of interest to nouveau or Debian developers
22:50RSpliet: lroop: well, with Lenovo working together with Red Hat to bring Fedora to their laptops
22:50RSpliet: perhaps some of the RH people here might be interested
22:50karolherbst: well... "just use uefi"? :p
22:50RSpliet: karolherbst: you might get Lenovo to fix their BIOS :-P
22:51karolherbst: might not even be a bios bug but we just don't do the right thing
22:51karolherbst: would be interesting to know what nvidia does on that system
22:51RSpliet: apparently the blob fails too
22:51karolherbst: then I guess it could be a firmware bug indeed
22:52RSpliet: I briefly wondered whether the BIOS just forgot to POST the GPU. But never heard back about NvForcePost results. Too late now :-D
22:54karolherbst: could be
22:56RSpliet: Anyway, it's a T460s. Sounds like it's reproducible, if anyone cares enough. Just use UEFI sounds like a very 2020 answer
23:02uis: Hi. Was register allocation issue fixed?
23:13lroop: yeah, the blob fails. haven't tried the blob with EFI yet but will later tonight