14:20 Venemo: gnarface: I can't promise you 10 fps on WoW on your GPU. but as an example of improving drivers, last year we had a change that added up to +10% perf in BG3 for the 5700 XT. (sadly that change isn't applicable to the 5500)
19:04 Venemo: some of these old GPUs are actually quite good
19:05 Venemo: I just realized you can play Baldur's Gate 3 at decent fps on Hawaii
19:06 gnarface: well, reaction time isn't a big factor in BG3 either, so you can really crank the graphical quality up and just let frames drop without it very severely impacting actual gameplay
19:07 gnarface: with WoW it's a very different scenario though, especially in PvP, and i frequently get the distinct impression they're sandbagging it on purpose to sell hardware through some completely illegal under-the-table collusion
19:08 gnarface: what are the chances i could get you to just point out the file and line numbers where the fan speed settings are handled so i can take a whack at just trying to fix it myself?
19:08 dwfreed: I once built a friend a PC with a 2400G in it as a budget gaming computer; it did really well
19:10 Venemo: gnarface: oh, I didn't mean that as a reply to you. I'm at the moment testing a bunch of (very) old GPUs to see what they can do
19:10 gnarface: noted
19:11 gnarface: so, about those fan control locations in the code... ?
19:12 Venemo: have you found something interesting?
19:13 gnarface: no, i'm asking you to help me find the thing that's interesting
19:13 gnarface: i'm no kernel dev, so the scope of this codebase is completely beyond me, but i've managed to make my own patches before by comparing two similar versions of things successfully, using my rudimentary knowledge of basic C programming
19:14 gnarface: so i figure if someone could just point me to where in the code the fan speeds for this thing actually get set, maybe i can actually see why it's not working just by comparing the two most recent kernel versions i have installed here, the working one and the broken one
19:15 gnarface: this doesn't seem like the type of thing that would require a lot of effort by someone who actually knew that info offhand, i'd do all the actual work
19:16 gnarface: it's a long shot anyway, so there's little chance of me succeeding, but i've surprised myself in the past despite that
19:17 gnarface: but for example i once managed to port forward a rejected dts patch for a sdio wifi device for some arm64 boards i have here... my programming skills aren't completely useless
19:18 gnarface: i'm just... better with web pages really
19:47 Venemo: gnarface: right, my apologies.
19:48 Venemo: gnarface: so, it seems you have a version that works, and a slightly newer one that doesn't. so my recommendation would be to: (1) try the latest upstream version to see if it works there, or (2) bisect and find what broke it
19:48 gnarface: hmm, noted
20:24 Venemo: gnarface: as far as I understand, Debian ships an LTS kernel, right? and maybe they add their own patches on top. so if the problem happens in 6.1.X but not in 6.1.Y that means they backported something that they shouldn't have.
20:27 gnarface: yea, they do, and that seems logical, but when i tried to actually figure out which .patch file the relevant change was actually in, i failed, and also failed to figure out whether the problem was my lack of understanding of the codebase, or just because the change wasn't actually one of their patches, but rather some upstream patch that was merged before debian got their hands on it
20:29 gnarface: debian's source package does contain and automatically apply a big directory of their own patches, but (not sure about this) it seems like those are only their in-house ones, so a change merged upstream wouldn't necessarily be obviously sequestered in that fashion
20:29 Venemo: yes, that's a reasonable assumption. I don't think this is something Debian would have wrote
20:29 gnarface: adding to that the fact that google seems to think i own the only rx 5500 ever sold, i can't even be sure anyone else is having this problem
20:30 gnarface: the evidence that everyone thinks i should have simply waited for the 7000 series and bought a whole new computer to go with it is overwhelming
20:31 Venemo: I used to have a 5500 but I gave it to a friend so I can't test this for you, I'm sorry
20:31 gnarface: no worries, i appreciate your advice anyway
20:31 gnarface: though, it also hasn't escaped me that the simplest solution to this involves me writing a shell script to control the fan manually
20:40 Venemo: well, you can always invent workarounds
21:55 iive: gnarface, what's the problem?
22:26 gnarface: iive: the current debian stable kernel broke amdgpu fan support
22:35 iive: as in sensor reading?
22:35 iive: or the fan doesn't run at all and the card overheats?
22:35 gnarface: fan doesn't run at all and the card overheats
22:35 gnarface: i confirmed it's not hardware failure
22:35 iive: :O
22:36 gnarface: yea, seems pretty bad. what's weird though is nobody seems to have noticed or even cares, but the default behavior of the cards to not spin the fans up by default until it hits a certain temperature threshold means the search results for this problem are completely swamped with 5 years of false positives
22:38 gnarface: i can't say exactly where it broke, only that it was working in "6.1.0-32" (6.1.129-1) and not working anymore in "6.1.0-37" (6.1.140-1)
22:39 gnarface: took me over month to notice, just because most the stuff i do doesn't hit the fan-on threshold to begin with
22:40 iive: o
22:41 iive: i'm a bit confused by these kernel numbers
22:42 iive: do you have repository that keeps older package versions. aka can you narrow it further?
22:42 gnarface: the ones in quotes are the substring of the debian package name, the ones in parenthesis are the actual upstream version numbers they're built from
22:43 gnarface: yea, so this is fun, i tried to install "6.1.0-36" to find out if it was still working there and they seem to have scrubbed the corresponding headers package from their repos already despite that several older ones are still there
22:44 gnarface: i checked out to see if snapshots.debian.org still had it but it... behaved weirdly
22:45 gnarface: after that i decided to evaluate other options
22:45 iive: you don't need the headers to run the kernel... there must be an option to ignore the dependency.
22:45 iive: how about *-34?
22:45 gnarface: so i'm told, which does beg another question about why the debian packages do it that way...
22:46 gnarface: it's not about package level dependencies, requiring the headers package; it's that the kernel package invokes dkms on amdgpu, which fails if the headers package isn't present
22:46 gnarface: ... which i've just been told shouldn't actually be happening :(
22:47 gnarface: (news to me)
22:47 gnarface: no, didn't try -34 or -35 yet either, i had skipped over them to 37 and ran it for a month and a half before noticing the problem
23:20 kode54: gnarface: may I suggest using ccache if you're going to bisect the kernel?
23:20 kode54: should significantly speed up mostly similar rebuilds
23:20 gnarface: kode54: noted, thanks