| elektron | suspend to ram work w/ rcore rk3588 module? | 00:02 |
|---|---|---|
| gordon1 | no | 00:04 |
| gordon1 | hibernate does not work either | 00:05 |
| gordon1 | but look a bit more promising | 00:05 |
| elektron | k. I'll stop trying and wondering why my system hangs.. | 00:05 |
| abortretryfail | There's some stuff you can try to do and troubleshoot it. I forget the commands, but if you search the forum we had a thread about hibernate on the imx8 that might be helpful | 00:07 |
| gordon1 | elektron: you can give a try to s2idle, it _should_ work, but i did not try it for complicated reasons (don't have reform and my current hardware with rk3588 is incapable of waking up) | 00:09 |
| austriancoder | josch: I still need to look how txf is done for older gpu models, but if you would like to test it: https://gitlab.freedesktop.org/austriancoder/mesa/-/commits/txf | 00:09 |
| minute | gordon1: btw i recently saw a patch addressing suspend issues with pcie/nvme on rk3588 | 00:41 |
| gordon1 | minute: can i have it pls? | 00:42 |
| gordon1 | can try it probably tomorrow | 00:42 |
| minute | gordon1: yeah i need to search for it, just came home, will paste in a few mins | 00:43 |
| gordon1 | no rush | 00:43 |
| minute | gordon1: strange, i searched for a while and can't find it... i also thought i had posted it here a few days (max weeks) ago, hm | 01:17 |
| gordon1 | i mean potentially, i might have missed it | 01:18 |
| gordon1 | (unless you checked the logs) | 01:18 |
| minute | gordon1: checked now and found it, but not 100% sure about it tbh https://lore.kernel.org/linux-rockchip/1744352048-178994-1-git-send-email-shawn.lin@rock-chips.com/ | 01:23 |
| gordon1 | yeah, sounds related to the issue with pcie after the hibernate, will try it out | 01:25 |
| minute | v3 https://lore.kernel.org/linux-rockchip/1744940759-23823-1-git-send-email-shawn.lin@rock-chips.com/T/#u | 01:25 |
| minute | possibly related https://lore.kernel.org/linux-rockchip/ad4b2140f5a4bf20b199ab092f28def7@manjaro.org/T/#mb33bac5e4b83de93e6688ae6e9735e012f7e4e7a | 01:26 |
| minute | also interesting https://lore.kernel.org/linux-rockchip/aACaupQvmiiBE29l@ryzen/T/#m51e0ec42ab1fc6e774dd4ab898dd26cace6b24ad | 01:29 |
| gordon1 | >The current state of the rockchip_pcie_phy_deinit() function might actually not cause issues because the rockchip_pcie_phy_deinit() function is used only in the error-handling path in the rockchip_pcie_probe() function | 01:35 |
| gordon1 | oh well | 01:35 |
| minute | oof https://lore.kernel.org/linux-rockchip/e340a408-2e21-1bca-7267-46b84690f66f@rock-chips.com/T/#t | 01:36 |
| gordon1 | oh, deinit is used in PM patch, good | 01:38 |
| minute | yeah, a bunch of things to try | 01:43 |
| - robin (QUIT: Read error: Connection reset by peer) (~robin@user/terpri) | 02:23 | |
| + robin (~robin@user/terpri) | 02:23 | |
| - mjw (QUIT: Ping timeout: 265 seconds) (~mjw@gnu.wildebeest.org) | 02:51 | |
| + arminweigl_ (~arminweig@sourcehut/user/arminweigl) | 03:25 | |
| - arminweigl (QUIT: Ping timeout: 265 seconds) (~arminweig@sourcehut/user/arminweigl) | 03:27 | |
| * arminweigl_ -> arminweigl | 03:27 | |
| - paperManu (QUIT: Ping timeout: 265 seconds) (~paperManu@172.93.30.55) | 03:37 | |
| - nsc (QUIT: Ping timeout: 276 seconds) (~nicolas@i5C74DFD8.versanet.de) | 03:50 | |
| + nsc (~nicolas@i5C74DF92.versanet.de) | 03:51 | |
| + arminweigl_ (~arminweig@sourcehut/user/arminweigl) | 04:11 | |
| - arminweigl (QUIT: Ping timeout: 265 seconds) (~arminweig@sourcehut/user/arminweigl) | 04:12 | |
| * arminweigl_ -> arminweigl | 04:12 | |
| + colinsane (~colinunin@97-113-94-68.tukw.qwest.net) | 04:19 | |
| - Ar|stote|is (QUIT: Ping timeout: 245 seconds) (~linx@149.210.0.138) | 04:50 | |
| + Ar|stote|is (~linx@149.210.0.250) | 04:55 | |
| - razzy (QUIT: Quit: Lost terminal) (~razzy@user/razzy) | 07:10 | |
| + Guest47 (~Guest47@189-232.customer.interconnect.cz) | 08:58 | |
| - Ar|stote|is (QUIT: Ping timeout: 265 seconds) (~linx@149.210.0.250) | 09:01 | |
| - Guest47 (QUIT: Client Quit) (~Guest47@189-232.customer.interconnect.cz) | 09:02 | |
| + josch_noreform (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 09:11 | |
| josch_noreform | minute: i just read the backlog. So, the Debian kernel version in experimental is not supposed to be uploaded to unstable before Trixie, hence it is not made to compile on Bookworm either. I guess my MR 81 where I already did a lot of the rebasing work was not useful to you because it's already too old by now? But if you look at that MR then you | 09:18 |
| josch_noreform | will see that I already ran into the problem with rt back then and added a code comment which references the Debian bug that I filed about this last year in August which has more context. | 09:18 |
| josch_noreform | austriancoder: thank you so much! I applied your 3 commits on top of mesa in Debian unstable and am building it now and will test it on imx8mq once it's done. :) | 09:53 |
| - josch_noreform (QUIT: Ping timeout: 240 seconds) (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 10:42 | |
| + Ar|stote|is (~linx@149.210.8.22) | 10:56 | |
| - buckket (QUIT: Quit: buckket) (~buckket@vps.buckket.org) | 10:59 | |
| + buckket (~buckket@vps.buckket.org) | 11:00 | |
| - antti (QUIT: Ping timeout: 248 seconds) (~antti@user/antti) | 11:04 | |
| + antti (~antti@user/antti) | 11:06 | |
| - antti (QUIT: Quit: antti) (~antti@user/antti) | 11:19 | |
| - wiedi_ (QUIT: Read error: Connection reset by peer) (~wiedi@ip5f58441e.dynamic.kabel-deutschland.de) | 11:53 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:59 | |
| - kensanata (QUIT: Quit: OK) (~alex@user/kensanata) | 12:16 | |
| + kensanata (~alex@user/kensanata) | 12:16 | |
| + wiedi (~wiedi@ip5f58441e.dynamic.kabel-deutschland.de) | 12:19 | |
| minute | josch: hmm but i used your branch linux6.13 as a base as you suggested | 12:34 |
| minute | did i overwrite something that made the build work? will take a look | 12:35 |
| + josch_noreform (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 12:35 | |
| + razzy (~razzy@user/razzy) | 12:35 | |
| josch_noreform | minute: oooh then please ignore my last comment -- i'll try to reproduce your finding after i'm done with mesa | 12:36 |
| josch_noreform | minute: what was your motivation for getting linux 6.13 to compile? the rk3588 patch stack? | 12:36 |
| josch_noreform | unfortunately I fear that it will still be a bit of a freeze before Trixie releases and only then do we get new kernel versions in unstable | 12:37 |
| minute | josch_noreform: yes, i couldn't get dsi+hdmi to work in the reform classic on 6.12, so i thought it's better to use a bit more modern stack as a base | 12:37 |
| minute | josch_noreform: and we can't make any more hdmi adapters (the chip and its company are gone) and we need to ship reforms | 12:37 |
| josch_noreform | oh dear the hdmi adapters are even no more o0 | 12:37 |
| minute | josch_noreform: and i have everything working on 6.13 after a few very long days | 12:38 |
| josch_noreform | oooh | 12:38 |
| josch_noreform | hrm... | 12:38 |
| razzy | hello again, question. I was under impression that bigger offered FPGA was usable as workstation. was that not a case? only for simulation of old hardware? | 12:38 |
| minute | razzy: why not read the article https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.html | 12:39 |
| minute | razzy: > In our tests I run RISC-V cores at 100 MHz in the FPGA, although I think that double that speed is possible. | 12:39 |
| minute | razzy: > 100 MHz | 12:40 |
| razzy | minute: thank you, will read. | 12:42 |
| minute | razzy: if you want an integration of usable arm/riscv and fpga, you can look into something like zynq ultrascale or polarfire soc. but we don't offer anything with that. it's too niche, i.e. there are not enough people who would be interested in this to make it worth the development effort for us. we are a tiny company and need to focus on the things that help the most people interested in | 12:42 |
| minute | OSHW. | 12:42 |
| minute | razzy: that's why we are at the moment focusing on performant socs like rk3588, and qualcomm and ampere in the future. | 12:43 |
| minute | josch_noreform: i think we shipped a kernel from experimental before, no? | 12:44 |
| razzy | minute: I understand. I have great respect for your work so far. | 12:44 |
| razzy | computational freedom is great feat. | 12:45 |
| josch_noreform | minute: yes, and we can do that again. I'm putting this on top of my todo list and hope I will find some time for it. A bit tricky of course with holidays and family right now and my actual machine with my usual setup at home and not here. I'll see what I can do and come back to you once I got 6.13 to compile. | 12:47 |
| josch_noreform | (I'm currently on BoostisBetter's reform with a setup I created a few days ago) | 12:47 |
| josch_noreform | (which is also why i noticed the imx8mq gtk4+clapper problem) | 12:49 |
| minute | josch_noreform: ohh i see. i don't want to put extra stress on you. let me give a little more context/findings so far | 12:50 |
| josch_noreform | minute: hehe no worries, I also want to receive my rk3588 classic reform as soon as possible so i have a good motivation ;) | 12:52 |
| minute | josch_noreform: 1. it's fine to not build rt for this, most people don't need it and it shouldn't be a blocker to ship. 2. the build gets past the patching state, it's now "only" complaining about "UNSHARE_MMDEBSTRAP_AUTO_CREATE requires mmdebstrap which was not found. Not attempting to auto-create chroot". then, sbuild fails with "useradd: user 'sbuild' already exists" | 12:52 |
| josch_noreform | we recently (2 days ago) did a *very* large upload of sbuild with very many change | 12:53 |
| josch_noreform | that upload didn't make it to testing yet | 12:53 |
| minute | josch_noreform: before, it was complaining about missing dh-python and build-essential:native which i just added to the apt install line in .gitlab-ci.yaml | 12:53 |
| josch_noreform | maybe you could try to use unstable instead of testing for the build environment and see what happens then? | 12:53 |
| josch_noreform | if you still get the error, maybe we need to fix sbuild in unstable | 12:54 |
| minute | josch_noreform: yeah, i tried unstable first and then tried testing. let me see what happened with unstable. but then i probably just didn't have those dependencies added, so i can just switch back to unstable | 12:54 |
| minute | ah no, i just built the wrong branch (main) on my last try with unstable m)) so will repeat that correctly now | 12:55 |
| josch_noreform | yes, please try that first -- i'm afk now for a bit, will check the log later | 12:55 |
| minute | josch_noreform: alright, thank you so far! | 12:55 |
| josch_noreform | thank you! | 12:55 |
| josch_noreform | (mesa is still compiling -- imx8mq is nice but a311d is just a tad more snappy and i got used to that :D) | 12:56 |
| minute | josch_noreform: oh yeah mesa takes a long time on imx8mq :D i did it many times back in the day ahaha | 12:56 |
| minute | i faintly remember i once built chromium or webkit-wpe on imx8mq (on weston) a _very_ long time ago | 12:57 |
| josch_noreform | brave! :D | 12:58 |
| josch_noreform | oh and i experienced now a few times a very weird lockup where the graphics would glitch out (will take a photo next time this happens) and then the system just stops (at least the screen stays glitched no matter what i do and i don't have a second pc here that i could use to see if maybe the system is still available via network) | 12:59 |
| minute | josch_noreform: on imx8mq? | 13:01 |
| minute | it's also funny how both custom and patched don't build on unstable or testing | 13:05 |
| minute | josch_noreform: if you have the time, maybe you can explain something to me (or point me to the right docs). when i follow the readme to try to build the experimental kernel on my unstable pocket reform system, i assume i have to do `mmdebstrap --variant=buildd experimental ~/.cache/sbuild/experimental-arm64.tar`, but this errors out with there being no experimental/updates release file. is | 13:08 |
| minute | this expected? | 13:08 |
| minute | so yeah it looks like the main blocker r/n is mmdebstrap not wanting to create the experimental-arm64.tar | 13:15 |
| minute | ah > If SUITE does not refer to "unstable" or "testing", then SUITE-updates and SUITE-security mirrors are automatically added | 13:16 |
| razzy | minute: from what I am reading in article, the FPGA had working ethernet connection. yes? so it was usable as secure terminal, yes? | 13:18 |
| minute | razzy: sure | 13:18 |
| minute | aha, i see that experimental is not the "real" base suite but setup.sh checks for it and sets up unstable as the actual suite when experimental is chosen | 13:21 |
| josch_noreform | all of this is nought with sbuild from testing or unstable | 13:22 |
| minute | josch_noreform: ah, the real issue is the sbuild changes? | 13:22 |
| josch_noreform | we overhauled the unshare backend and you no longer need to create the chroot yourself | 13:22 |
| josch_noreform | i did not let the reform-debian-packages scripts take advantage of this yet, because they are run on bookworm | 13:23 |
| josch_noreform | but if we need to build with testing or unstable anyways, i'll drop all the manual chroot setup in the .gitlab-ci.yml | 13:23 |
| josch_noreform | because with modern sbuild, this happens automatically | 13:23 |
| minute | josch_noreform: ah, i see | 13:24 |
| josch_noreform | re "If SUITE does not refer to "unstable" or "testing", then" -- the problem here is, that you are now running the CI scripts which assume that they are run with packages from Bookworm on unstable or testing where some things chcanged | 13:28 |
| josch_noreform | so if kernel 6.13 cannot be built in bookworm anymore, then as a first step, i can change .gitlab-ci.yml to do the right thing for testing or unstable | 13:29 |
| minute | josch_noreform: that would be great yes | 13:29 |
| josch_noreform | i think we want unstable because if we do find any remaining bugs in packages like sbuild or mmdebstrap, then i can fix them quickly by uploads to unstable | 13:29 |
| josch_noreform | sincce we are in the freeze right now, transitions to testing take 10 days | 13:30 |
| minute | josch_noreform: it would also be useful for me because all my machines run unstable :D | 13:30 |
| - wickedshell (QUIT: Ping timeout: 272 seconds) (~wickedshe@2601:8c0:800:a1c1:7502:a6ab:85c0:bb67) | 13:31 | |
| minute | josch_noreform: if i run sbuild directly, the problem is that it calls mmdebstrap with the "reform" suite instead of "unstable". | 13:38 |
| josch_noreform | if you run sbuild yourself, you have to pass similar options that linux/build.sh passes, particularly --chroot="$BASESUITE-$BUILD_ARCH" which should evaluate to --chroot=unstable-arm64 | 13:41 |
| minute | aha | 13:41 |
| minute | i did --chroot="experimental-arm64", that was the mistake then | 13:41 |
| josch_noreform | it's not a mistake if you have a experimental-arm64.tar set up *also* with unstable | 13:42 |
| minute | i see :3 | 13:42 |
| josch_noreform | and sbuild does that automatically if you do did not already ccreate that tarball yourself | 13:43 |
| minute | locally it looks like it's building the kernel now | 13:46 |
| - kensanata (QUIT: Quit: OK) (~alex@user/kensanata) | 13:47 | |
| + kensanata (~alex@user/kensanata) | 13:47 | |
| + paperManu (~paperManu@172.93.30.55) | 13:52 | |
| minute | josch_noreform: ah sorry, i'll stop tinkering, i see that you're also already on this | 13:54 |
| josch_noreform | there are two needs to be met. One is to run the scripts via .gitlab-ci.yml. The other is to run this locally.I'm fixing the former first. | 13:56 |
| minute | josch_noreform: yeah, the former is more important for sure | 13:56 |
| - josch_noreform (QUIT: Ping timeout: 240 seconds) (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 14:37 | |
| + josch_noreform (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 14:39 | |
| josch_noreform | minute: this is how the lockup glitch looks like on imx8mq: https://mister-muffin.de/p/ja68.jpg | 14:40 |
| minute | josch_noreform: hmm, hard to say what that is, i.e. not sure if GPU or scanout issue, maybe DCSS compression related? i mean, if the display content stays there i guess the DSI->eDP link is still running... austriancoder: does this glitch look familiar at all? | 14:47 |
| minute | josch_noreform: because there is a vertical and horizontal offset it looks more like GPU related to me (tiling patterns) | 14:47 |
| minute | josch_noreform: do you have that also when not using firefox? could it be triggered by FF GPU operations? | 14:48 |
| minute | josch_noreform: later when you have another computer again, i would recommend to attach usb serial and do dmesg -w, maybe you'll catch some gpu errors before it happens | 15:01 |
| + wickedshell (~wickedshe@2601:8c0:800:a1c1:9d00:de05:2d9e:b4b6) | 15:38 | |
| - bkeys (QUIT: Ping timeout: 272 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:59 | |
| josch_noreform | it is now happening maybe once per day, so not very often but still annoying enough | 16:02 |
| josch_noreform | but yes, often enough such that when i'm back home i can leave it running with uart adapter attached | 16:03 |
| josch_noreform | i'll have to investigate this more seriously now that it has happened a few times and thus is not just a one-time fluke | 16:03 |
| + bkeys (~Thunderbi@66.110.201.50) | 16:04 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:44 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:44 | |
| * bkeys1 -> bkeys | 16:46 | |
| - josch_noreform (QUIT: Quit: Client closed) (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 17:07 | |
| + bkeys1 (~Thunderbi@172.58.0.49) | 17:07 | |
| - bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50) | 17:10 | |
| * bkeys1 -> bkeys | 17:10 | |
| - bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@172.58.0.49) | 17:23 | |
| vkoskiv | Anyone from here at Revision, perhaps? :] | 18:07 |
| + chorc (~dart@user/chorc) | 18:12 | |
| - chorc (QUIT: Client Quit) (~dart@user/chorc) | 18:12 | |
| svp | trying to conjure a layout for the keyboard, it makes me kind of miss the weirdly staggered 2.0 and its' neatly sized keycaps, lol | 18:13 |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 18:15 | |
| minute | vkoskiv: unfortunately again not, but will watch stream occasionally | 18:17 |
| + josch_noreform (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 18:28 | |
| josch_noreform | collect2: fatal error: ld terminated with signal 9 [Killed] | 18:28 |
| josch_noreform | compilation terminated. | 18:28 |
| josch_noreform | the joys of 4gigs of ram... | 18:28 |
| minute | josch_noreform: you could build in our CI if that helps | 18:30 |
| josch_noreform | haha MNT CI is busy with my reform-debian-packages trial and error ;) | 18:31 |
| josch_noreform | no worries, i'm in no rush :) | 18:31 |
| minute | ok :3 | 18:31 |
| josch_noreform | and mega success moment: the bug you found earlier is actually a bug in sbuild itself: https://salsa.debian.org/debian/sbuild/-/merge_requests/172 | 18:49 |
| josch_noreform | very happy to have found this before we shipped this in Trixie :) | 18:49 |
| zeha | how did nobody else notice before :/ | 18:50 |
| josch_noreform | exactly!! | 18:57 |
| josch_noreform | also, the error mode is really bad because all you see is this: https://source.mnt.re/reform/reform-debian-packages/-/jobs/8863 | 18:57 |
| josch_noreform | so the user is like: why does getent not find a user and then adduser claims the user already exists???? | 18:57 |
| - xktr (QUIT: Ping timeout: 248 seconds) (~xktr@user/xktr) | 18:58 | |
| + xktr (~xktr@user/xktr) | 18:59 | |
| minute | josch_noreform: zeha: oh wow haha, always glad to be of service stumbling on bugs | 19:27 |
| + chorc (~chorc@user/chorc) | 19:51 | |
| - josch_noreform (QUIT: Ping timeout: 240 seconds) (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 20:44 | |
| BoostisBetter | minute: have you had any other reports of a Pocket Reform keyboard controller having issues like mine? | 21:10 |
| minute | BoostisBetter: rarely but it can happen | 21:21 |
| minute | alternative to waybar https://github.com/JakeStanger/ironbar?tab=readme-ov-file | 21:21 |
| minute | a flashy fork of sway with effects https://github.com/WillPower3309/swayfx | 21:25 |
| minute | i'm also trying out https://codeberg.org/vyivel/croissant | 22:06 |
| minute | it feels immediately more stable than wayfire, but the default config is a bit unusual | 22:07 |
| BoostisBetter | minute: I would be interested in how it goes in either of those. Wayfire was nice, but it just didn't seem to be keeping up very well. | 22:18 |
| + josch_noreform (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 22:21 | |
| - josch_noreform (QUIT: Ping timeout: 240 seconds) (~josch_nor@2a02:590:501:c00:d1d9:6a4b:3d3a:530d) | 22:26 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
