2025-04-21.log

+ chrcav (~chrcav@user/chrcav)00:37
+ aperezdc (~aperezdc@2a03:6000:6e61:633::43)00:45
- wickedshell (QUIT: Ping timeout: 276 seconds) (~wickedshe@2601:8c0:800:a1c1:9d00:de05:2d9e:b4b6)02:52
- jacqueline (QUIT: Read error: Connection reset by peer) (~jacquelin@user/jacqueline)03:13
+ jacqueline (~jacquelin@user/jacqueline)03:13
+ jacobk (~quassel@179.sub-174-244-80.myvzw.com)03:21
+ arminweigl_ (~arminweig@sourcehut/user/arminweigl)03:25
- arminweigl (QUIT: Ping timeout: 252 seconds) (~arminweig@sourcehut/user/arminweigl)03:25
* arminweigl_ -> arminweigl03:25
- arminweigl (QUIT: Ping timeout: 252 seconds) (~arminweig@sourcehut/user/arminweigl)03:30
- jacobk (QUIT: Ping timeout: 260 seconds) (~quassel@179.sub-174-244-80.myvzw.com)03:34
+ arminweigl (~arminweig@sourcehut/user/arminweigl)03:35
- paperManu (QUIT: Ping timeout: 272 seconds) (~paperManu@172.93.30.55)03:39
+ wickedshell (~wickedshe@2601:8c0:800:a1c1:ad46:75c:319e:fe3b)04:59
- josch_noreform (QUIT: Quit: Client closed) (~josch_nor@2a02:590:501:c00:ccd8:8d58:7e1b:de51)08:00
+ xha (~xha@user/xha)09:55
- Ar|stote|is (QUIT: Read error: Connection reset by peer) (~linx@149.210.8.176)11:47
+ Ar|stote|is (~linx@149.210.9.164)11:53
- _justin_kelly71 (QUIT: Read error: Connection reset by peer) (~justinkel@user/justin-kelly/x-6011154)11:57
+ _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154)11:57
- buckket (QUIT: Quit: buckket) (~buckket@vps.buckket.org)12:19
- gsora (QUIT: Ping timeout: 245 seconds) (~gsora@user/gsora)12:20
+ buckket (~buckket@vps.buckket.org)12:20
+ gsora (~gsora@user/gsora)12:24
minutechorc: which cpu module / system?13:06
chorcminute: Pocket RK3588 (i've submitted a ticket last night to support@mntre.com, number 5747)13:30
- aperezdc (QUIT: Ping timeout: 244 seconds) (~aperezdc@2a03:6000:6e61:633::43)13:46
+ paperManu (~paperManu@172.93.30.55)13:48
gordon1minute: with new patches you gave there is a breakthrough with hibernate, looks like pcie reinited almost well, after hibernate nvmes were unresponsive, after removing and rescannding nvme0 did not respond in time and but third time the charm and both nvmes reinitialized well and work fine, so i would say we're really close14:33
gordon1at least for working hibernate14:33
gordon1do you want me to check which patch exactly did it?14:34
gordon1there is still an open question if it can resume with resume partition being on nvme14:36
zehai think that should work, the resume is done without uboot help (iirc)14:38
gordon1sure, but problems with pcie happen in linux kernel, not uboot14:39
zehayou made it sound like nvme works :)14:41
gordon1not immediately after the resume14:41
+ josch_noreform (~josch_nor@2a02:590:501:c00:ccd8:8d58:7e1b:de51)14:42
zehaah14:42
gordon1i mean i assume linux kernel retrieves resume image first before doing some surgery on its parts that render pcie broken, so hopefully should be still fine, just need to be tested14:42
zehathen i wouldnt bother trying with the resume partition on nvme at first14:42
josch_noreformI just read the backlog. Wow, if at least hibernation works, that would be *massive*!! Thank you for your work gordon1!!14:42
gordon1which would be quite difficult with my current setup since i have important stuff on those nvmes14:42
gordon1josch_noreform: hold your horses, that all was tested from initrd, i'm not yet certain if such nvme disturbance will break rootfs14:44
gordon1but it is a breakthrough nonetheless, much better than before14:44
zeharesume happens after initramfs did some stuff, so i'd imagine you'll see the same problem14:45
gordon1but i am pretty sure you can already use it if you have rootfs on emmc14:45
josch_noreformgordon1: I've held my horses for some sort of suspend/hibernation with the Reform since 2021 -- I can be patient, no worries. ;)14:46
gordon1zeha: so first the new kernel boots, then initrd checks if there is a resume image on a resume partition and then it tries to recover it, at the first two steps nvmes work absolutely fine and i am certain of it, third step is handled by the kernel when it does some cpu shutdowns and preparations for the resume, i am not an expert in this process so i'm not 100% sure if it does some magic with14:48
gordon1the devices first as part of resume preparation before it unpacks the resume image, my gut feeling that it doesn't and should be fine14:48
minutegordon1: very nice to hear about your progress!14:49
zehawell then, maybe! :)14:50
gordon1minute: it also still does kernel oops about not cared hdmi irq #50 so i would think that graphics might is broken, but the moment we get nvmes to reliably resume i can start testing it with my main linux installation14:51
minutegordon1: ok, i'm messing with hdmi a lot anyway at the moment14:51
gordon1minute: full log, if youre interested https://0x0.st/8O7l.txt14:56
gordon1so looks like pcie controller resumes mostly fine, but nvmes do not, need some poking around to recover14:59
gordon1actually i am wrong, only one of nvmes didn't recover, so maybe with reform it will be the one?15:02
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)15:05
minutegordon1: thanks! also interesting your board is using 4 pcie controllers?15:08
gordon1minute: my board is rock5b+, if i recall correctly it uses one pcie controller in 2x2 configuration to have 2 nvmes, it also uses another controller for wifi m.2 slot but i never tried it, and it also uses another pcie controller for onboard wifi15:10
gordon1i need to take a peek at the dts to cross-check my words15:10
+ bkeys (~Thunderbi@66.110.201.50)15:11
minutegordon1: ah i see15:14
zehawhich patches did you end up applying? might be nice to have them in a test branch for linux-reform :)15:14
gordon1zeha: pretty much every one minute sent me, here is the list: https://0x0.st/8O77.txt 15:17
gordon1in the first one, one of the commits i didn't apply since the function call in question is already gone in 6.14.215:17
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)15:18
+ bkeys1 (~Thunderbi@66.110.201.50)15:18
gordon1possibly... sorry, going by memory here, the patches i applied are now on the machine that has its guts out in front of me, i probably need to think of some better approach for this15:19
gordon1mounted fs refuses to recover after remove and rescan of nvmes so we need to solve that issue first it seems15:20
* bkeys1 -> bkeys15:20
zeha:-)15:23
gordon1i was talking about that one https://lore.kernel.org/linux-rockchip/aACaupQvmiiBE29l@ryzen/T/#mc0f14e134aca4dcd5f56913ddff0d6159c22736f15:24
gordon1this preinit is gone15:25
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)15:28
+ bkeys1 (~Thunderbi@66.110.201.50)15:28
- bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)15:30
+ bkeys (~Thunderbi@66.110.201.50)15:30
gordon1also pcie breaks with ASPM so need to be turned off before the hibernate15:31
+ bkeys1 (~Thunderbi@38-146-94-247.echocast.zone)15:31
jfredif y'all get hibernate working on the rk3588 that'll probably mean I swap modules between my big Reform and my Pocket15:33
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50)15:35
+ bkeys (~Thunderbi@66.110.201.50)15:35
- bkeys1 (QUIT: Ping timeout: 248 seconds) (~Thunderbi@38-146-94-247.echocast.zone)15:38
- josch_noreform (QUIT: Quit: Client closed) (~josch_nor@2a02:590:501:c00:ccd8:8d58:7e1b:de51)15:38
+ bkeys1 (~Thunderbi@66.110.201.50)15:39
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50)15:40
* bkeys1 -> bkeys15:40
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)15:43
+ bkeys1 (~Thunderbi@66.110.201.50)15:43
* bkeys1 -> bkeys15:46
minutejosch: for some reason, it always wants to build 6.12 now, as opposed to 6.13, but i've set BASESUITE to experimental. any idea why? https://source.mnt.re/mntmn/reform-debian-packages/-/jobs/903615:47
+ aperezdc (~aperezdc@2a03:6000:6e61:633::43)15:56
gordon1looks related but disabling APST as a workaround does not fix my issue https://bugzilla.kernel.org/show_bug.cgi?id=19632516:03
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)16:04
+ bkeys (~Thunderbi@66.110.201.50)16:04
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)16:06
+ bkeys1 (~Thunderbi@66.110.201.50)16:07
- bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)16:09
+ bkeys (~Thunderbi@66.110.201.50)16:09
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)16:29
+ bkeys (~Thunderbi@66.110.201.50)16:30
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)16:40
+ bkeys (~Thunderbi@66.110.201.50)16:40
- bkeys (QUIT: Ping timeout: 244 seconds) (~Thunderbi@66.110.201.50)16:50
+ josch_noreform (~josch_nor@2a02:590:501:c00:ccd8:8d58:7e1b:de51)16:56
josch_noreformminute: i cannot reproduce this in my trixie branch which starts building 6.13: https://source.mnt.re/josch/reform-debian-packages/-/jobs/906016:57
josch_noreformI'll have to look at your changes... secc...16:57
+ bkeys (~Thunderbi@66.110.201.50)16:57
minutejosch_noreform: maybe i missed some of your changes16:57
josch_noreformlet me fork your branch and try some things :)16:58
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)16:59
+ bkeys (~Thunderbi@66.110.201.50)16:59
minutecool!17:00
josch_noreformminute: I cannot reproduce with your linux6.13 branch (top commit 045d987c8ce1854c1fb018282d00b4dc79697261) and no changes: https://source.mnt.re/josch/reform-debian-packages/-/jobs/908217:05
minutejosch_noreform: ah, that's i386 though, maybe a difference? let me see17:06
minutejosch_noreform: sorry, it's probably my mistake17:07
minutejosch_noreform: i think i pushed a fix and then forgot to run the pipeline with custom var again m))17:07
josch_noreformno worries, happens to me all the time as well XD17:08
josch_noreformmaybe temporarily hardcode the BASESUITE variable to a different default17:08
josch_noreformor even non-temporarily if you say that we want to get it from experimental until the trixie release17:08
minuteah, i'll just try to remember it for now :D 17:10
minute> 0001-pm-cpupower-Makefile-Fix-cross-compilation.patch17:10
minutecan that go?17:10
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50)17:12
minute(i guess it can)17:12
+ bkeys (~Thunderbi@66.110.201.50)17:13
- L29Ah (PART: !!unknown attribute: msg!!) (~L29Ah@wikipedia/L29Ah)17:14
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)17:15
+ bkeys1 (~Thunderbi@66.110.201.50)17:15
+ L29Ah (~L29Ah@wikipedia/L29Ah)17:16
josch_noreformminute: depends. The MNT CI does not cross build anything right now because it is using both the arm64 and x86 machines. If we do want to cross-build then we still need it because 3075476a7af666de3ec10b4f35d8e62db8fd5b6d only got into mainline with kernel 6.1417:17
josch_noreform(I'd add a comment to its description pointing out that it can get thrown out with 6.14)17:17
- L29Ah (PART: !!unknown attribute: msg!!) (~L29Ah@wikipedia/L29Ah)17:18
* bkeys1 -> bkeys17:18
+ L29Ah (~L29Ah@wikipedia/L29Ah)17:19
minutejosch_noreform: weird, because it says the patch can be reverse-applied17:34
+ bkeys1 (~Thunderbi@38-146-94-247.echocast.zone)18:03
- bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@66.110.201.50)18:07
- bkeys1 (QUIT: Ping timeout: 245 seconds) (~Thunderbi@38-146-94-247.echocast.zone)18:07
josch_noreformminute: oh in that case of course just drop it. I have a local clone of linus' git tree and that's different from linux-stable. It means that the patch was backported to a stable linux release of 6.13. Nice!18:29
minutejosch_noreform: ahh!18:29
- SavagePeanut (QUIT: Ping timeout: 260 seconds) (59eaa45ac7@irc.cheogram.com)18:39
- BoostisBetter (QUIT: Ping timeout: 260 seconds) (4a410829d7@irc.cheogram.com)18:40
- wiedi (QUIT: Read error: Connection reset by peer) (~wiedi@ip5f58441e.dynamic.kabel-deutschland.de)18:43
+ wiedi (~wiedi@95.88.68.30)18:44
+ SavagePeanut (59eaa45ac7@irc.cheogram.com)19:01
+ bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)19:12
- ndufresne (QUIT: Quit: The Lounge - https://thelounge.chat) (~ndufresne@apple.collaboradmins.com)19:42
+ ndufresne (~ndufresne@apple.collaboradmins.com)19:44
+ jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net)19:50
+ BoostisBetter (4a410829d7@irc.cheogram.com)19:53
- josch_noreform (QUIT: Quit: Client closed) (~josch_nor@2a02:590:501:c00:ccd8:8d58:7e1b:de51)19:54
minutefirst successful build btw https://source.mnt.re/mntmn/reform-debian-packages/-/jobs/914619:56
- ndufresne (QUIT: Quit: The Lounge - https://thelounge.chat) (~ndufresne@apple.collaboradmins.com)20:00
+ ndufresne (~ndufresne@apple.collaboradmins.com)20:02
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)20:33
joschdo you have something to automate the cancelling of all jobs but one?20:40
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone)20:47
+ bkeys1 (~Thunderbi@66.110.201.50)20:49
- bkeys (QUIT: Ping timeout: 265 seconds) (~Thunderbi@38-146-94-247.echocast.zone)20:52
* bkeys1 -> bkeys20:52
- bkeys (QUIT: Remote host closed the connection) (~Thunderbi@66.110.201.50)20:56
+ bkeys (~Thunderbi@66.110.201.50)20:57
minutejosch: no, i just mash the cancel buttons21:07
minutejosch: in the pipeline view21:07
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@66.110.201.50)21:07
joschokay! :)21:09
- jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net)21:29
+ jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net)21:30
+ bkeys (~Thunderbi@66.110.201.50)21:36
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)21:45
+ bkeys (~Thunderbi@66.110.201.50)21:45
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)21:50
+ bkeys (~Thunderbi@66.110.201.50)21:51
- bkeys (QUIT: Ping timeout: 245 seconds) (~Thunderbi@66.110.201.50)21:55
+ bkeys (~Thunderbi@66.110.201.50)22:13
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)22:22
+ bkeys1 (~Thunderbi@66.110.201.50)22:22
- bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)22:25
+ bkeys (~Thunderbi@66.110.201.50)22:25
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)22:27
+ bkeys (~Thunderbi@66.110.201.50)22:28
- bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50)22:32
+ bkeys (~Thunderbi@66.110.201.50)22:38
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)22:40
+ bkeys1 (~Thunderbi@66.110.201.50)22:40
- bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)22:42
+ bkeys (~Thunderbi@66.110.201.50)22:42
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@66.110.201.50)22:47
+ bkeys (~Thunderbi@66.110.201.50)23:06
- bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@66.110.201.50)23:16
+ bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)23:17
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)23:39
+ bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)23:39
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)23:45
+ bkeys (~Thunderbi@173.186.16.211)23:46
- Gooberpatrol_66 (QUIT: Ping timeout: 248 seconds) (~Gooberpat@user/gooberpatrol66)23:57

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!