01:17 <steev> dunno but it sure is frustrating

01:18 <steev> especially when 4 out of 5 times, the reboot doesn't reboot properly

01:21 <steev> i attempted to revert soundwire: stream: Make master_list ordered to prevent deadlocks and interestingly enough, the first reboot did NOT give me a null pointer deref, but also didn't give me working audio, but 4 reboots/cold boots from holding power button down (because i can't tell what is going on because i no longer get console when shutting down) and i'm back to getting them

01:23 <steev> i can also tell if there is gonna be a null pointer deref because the speaker icon doesn't show up on the gdm login screen (because it doesn't happen til you actually log in)

01:39 <louist103[m]> <JensGlathe[m]> "why is sound even more complicat..." <- Funny thing is I have worked on two ports of games from the N64. For both of them audio was the hardest part. Fixing logic took a few weeks of man power. Graphics was about the same. Audio took around 2 months.

01:47 <dgilmore> hrrm, wifi after working well for ages has started crashing like crazy today on my x13s

01:47 <dgilmore> https://www.irccloud.com/pastebin/qzbIgq8S/

01:52 <steev> i haven't seen that one (luckily)

01:54 <steev> audio would also be a lot easier if i could fucking play with the damn modules instead of having to reboot each time, but they're all tied together in this weird dependency hell, so i can't even modprobe -r

01:55 <steev> knowing my luck though, it's probably soemthing stupid and the QMI wait timeout just means that the audio firmware isn't getting loaded or something

03:51 <dgilmore> it takes two reboots to getthe system back

04:43 <steev> from your wifi error?

04:43 <steev> dgilmore: was your system up the entire time?

04:44 <steev> agl_ mentioned instability but never showed the logs, after his system was up for.... 10 days?

06:49 <dgilmore> Yep, luks seemed to go wrong on the first reboot. Second it was okay

07:11 <steev> Okay so about 10 days of uptime

14:43 <JensGlathe[m]> bsod news: there's a connection to loaded venus firmware

14:45 <JensGlathe[m]> it only hapens when the venus patches are in and the firmware is loaded

14:55 <JensGlathe[m]> and it stopped working somewhere between 6.7.1 and 6.7.3

14:55 <JensGlathe[m]> EL2 doesn't load venus either

19:13 <JensGlathe[m]> 8x git bisect bad in a row, wow

19:20 <steev> between 6.7.1 and 6.7.3?

19:22 <JensGlathe[m]> first bisect was 6.7.3, started from 6.7.10 because taht's what I had

19:22 <steev> oh wow, yeah 6.7.3 was a massive number of patches

19:23 <steev> 6.7.2 is huge too

19:26 <JensGlathe[m]> good was 6.7.0, bad 6.7.10. I know that 6.7.1 is reliably working with 4k@60

19:32 <JensGlathe[m]> #9 is also bad

19:36 <JensGlathe[m]> I guess I need a different approach

19:51 <steev> are you doing git bisect or are you pulling each commit?

19:57 <JensGlathe[m]> bisect, but odd. I needed to cherry-pick the chain of commits that are not mainline every time (that works well), otherwise I won't get the bsod behaviour because it depends on venus.

19:58 <JensGlathe[m]> That throws the bisect algorithm into slo-mo apparently. 2 options to rectify it:

19:58 <JensGlathe[m]> 1. rebase mainline onto the good branch and bisect that

19:58 <JensGlathe[m]> 2. take a separate repo for bisect recording

19:59 <JensGlathe[m]> I'm inclined to do #2, hate to do shenanigans with the mainline

20:01 <JensGlathe[m]> in the end it's whatever works

20:07 <steev> oh, yeah

20:08 <steev> maybe konradybcio has some ideas

20:26 <JensGlathe[m]> cross-build fails badly (so its build on the box)

22:06 <steev> looks like they've pushed out v641 to the firmware repo for bluetooth

22:06 <steev> no idea what is different because as always, there's no mention of what changes