| - thelounge3120 (QUIT: Quit: The Lounge - https://thelounge.chat) (~thelounge@gidzit.org) | 00:04 | |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2a02-8434-b6a3-e901-facc-8e87-8e54-890e.rev.sfr.net) | 00:38 | |
| + wielaard (~mjw@gnu.wildebeest.org) | 00:47 | |
| - mjw (QUIT: Ping timeout: 240 seconds) (~mjw@gnu.wildebeest.org) | 00:49 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 00:53 | |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 00:58 | |
| + enwu (~enwu@user/enwu) | 01:11 | |
| - enwu6 (QUIT: Ping timeout: 246 seconds) (~enwu@user/enwu) | 01:13 | |
| - enwu (QUIT: Ping timeout: 248 seconds) (~enwu@user/enwu) | 01:23 | |
| + enwu (~enwu@user/enwu) | 01:25 | |
| - enwu (QUIT: Ping timeout: 244 seconds) (~enwu@user/enwu) | 01:36 | |
| + enwu1 (~enwu@user/enwu) | 01:36 | |
| - schalken (QUIT: Ping timeout: 244 seconds) (~schalken@117-118-178-69.gci.net) | 01:53 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 01:54 | |
| - n_to (QUIT: Quit: quitidiquit) (~n_to@2a03:4000:6:3662:24b1:57ff:fec6:76c1) | 02:00 | |
| + n_to (~n_to@2a03:4000:6:3662:24b1:57ff:fec6:76c1) | 02:00 | |
| - svp (QUIT: Ping timeout: 248 seconds) (~svp@2002:4f07:f0bd:0:69b1:b463:d245:e861) | 02:06 | |
| - schalken (QUIT: Ping timeout: 264 seconds) (~schalken@117-118-178-69.gci.net) | 02:13 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 02:14 | |
| + svp (~svp@2002:4f07:f0bd:0:69b1:b463:d245:e861) | 02:29 | |
| + _justin_kelly71 (~justinkel@user/justin-kelly/x-6011154) | 02:40 | |
| - wielaard (QUIT: Ping timeout: 255 seconds) (~mjw@gnu.wildebeest.org) | 02:48 | |
| - schalken (QUIT: Ping timeout: 264 seconds) (~schalken@117-118-178-69.gci.net) | 03:06 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 03:10 | |
| - paperManu (QUIT: Ping timeout: 240 seconds) (~paperManu@198.58.139.163) | 03:30 | |
| - AbortRetryFail (QUIT: Ping timeout: 264 seconds) (~arf@146.ip-149-56-132.net) | 03:52 | |
| + AbortRetryFail (~arf@146.ip-149-56-132.net) | 04:06 | |
| - paperManu_ (QUIT: Ping timeout: 240 seconds) (~paperManu@198.58.139.163) | 05:02 | |
| - GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 06:02 | |
| + GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 06:03 | |
| - casparvitch (QUIT: Remote host closed the connection) (~casparvit@user/casparvitch) | 06:44 | |
| + casparvitch (~casparvit@user/casparvitch) | 06:45 | |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 07:25 | |
| - casparvitch (QUIT: Remote host closed the connection) (~casparvit@user/casparvitch) | 08:01 | |
| + casparvitch (~casparvit@user/casparvitch) | 08:02 | |
| [tj] | If anyone is looking for a 39c3 voucher, hit me up | 08:22 |
|---|---|---|
| - casparvitch (QUIT: Remote host closed the connection) (~casparvit@user/casparvitch) | 08:26 | |
| + casparvitch (~casparvit@user/casparvitch) | 08:27 | |
| dormito | The handbook says that for the i.mx8m+ the uart labeled 'S1' @115200 baud is where u-boot and the kernel's consoles will be. I connected to that port (with 115200n8) on my 'pocket', and verified it worked in linux (/dev/ttymxc3), and then powered off, and back on. However I do not see any u-boot chatter at all. Is there something still missing? | 08:34 |
| josch | dormito: did you remember to swap RX and TX on your UART adapter? | 08:46 |
| dormito | josch: yes. the uart adaptor works when linux is booted on the reform pocket (to be clear: I ran c-kermit on my other machine, and 'busybox microcom' on the pocket, using 11520n8, and I could type on one side, and see it on the other). | 09:20 |
| dormito | *115200n8 | 09:20 |
| josch | oh that is very weird, sorry i have to idea how your early boot messages would get lost but somehow serial just decides to work later o0 | 09:22 |
| josch | [tj]: i sent you a query, thank you! <3 | 09:22 |
| dormito | ok, well thank you anyhow | 09:24 |
| josch | dormito: let me ping minute for you for more ideas :) | 09:33 |
| + thelounge2220 (~thelounge@148.168.138.88.rev.sfr.net) | 09:40 | |
| - ZetaR (QUIT: Ping timeout: 248 seconds) (~user@c-76-148-139-78.hsd1.fl.comcast.net) | 09:40 | |
| josch | it seems i also need some assistance later | 09:50 |
| josch | i have a reform keyboard 20R01 here which seems dead. When I connect it to another PC via its usb-c port, nothing shows up. When I connect USB the top right JST connector, again nothing shows up on the other side. I tried pressing reset and flipped the prog switch to no avail. Ideas? | 09:51 |
| + ZetaR (~user@c-76-148-139-78.hsd1.fl.comcast.net) | 09:55 | |
| AbortRetryFail | Those have an AVR, right? | 10:06 |
| AbortRetryFail | ATMEGA32U4 from the schematic | 10:09 |
| AbortRetryFail | If you have an AVRISP maybe it can tell if there are signs of life, but start with the basics: Does it have voltages? Is the clock running? etc. | 10:10 |
| minute | josch: that one doesn't have a standalone switch iirc, so you need to provide 3v3 on the uart connector as well | 11:20 |
| minute | josch: for example by using a reform | 11:21 |
| - thelounge2220 (QUIT: Quit: The Lounge - https://thelounge.chat) (~thelounge@148.168.138.88.rev.sfr.net) | 11:30 | |
| - erle (QUIT: Quit: K-lined) (~erle@user/erle) | 11:31 | |
| - cow321 (QUIT: Read error: Connection reset by peer) (~deflated8@user/meow/deflated8837) | 11:59 | |
| + cow321 (~deflated8@user/meow/deflated8837) | 11:59 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 12:00 | |
| + plomtest (~plom@user/plomtest) | 12:01 | |
| + wielaard (~mjw@gnu.wildebeest.org) | 12:05 | |
| + andreas-e (~Andreas@2a02-8434-b6a3-e901-facc-8e87-8e54-890e.rev.sfr.net) | 12:46 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 12:46 | |
| + plomtest (~plom@user/plomtest) | 12:47 | |
| + paperManu (~paperManu@198.58.139.163) | 12:52 | |
| josch | minute: oooooh i totally forgot about that, thank you! | 12:53 |
| josch | it seems i got too used to keyboard 3 and 4 already XD | 12:54 |
| + gustav25 (~gustav@c-78-82-53-228.bbcust.telenor.se) | 13:02 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 13:02 | |
| + plomtest (~plom@user/plomtest) | 13:03 | |
| + ericsfraga (~user@2a00:23cc:b475:7c01:53b:6ddf:a36e:d38b) | 13:05 | |
| [tj] | minute: josch I handle vouchers for Scotland (but the ccc are clear that the group is what you make of it). I get them for Congress and camp, for any future events I’m happy of you point mnt-reform related people to me for vouchers | 13:14 |
| frickler | ACTION now has a weird vision of the pink pocket chassis getting embroidered with a kilt pattern ;) | 13:21 |
| - chomwitt (QUIT: Ping timeout: 244 seconds) (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 13:22 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 13:22 | |
| + plomtest (~plom@user/plomtest) | 13:22 | |
| minute | josch: hmm, debian has a new multiarch bug maybe? it won't let me remove *:armhf > E: Removing essential system-critical packages is not permitted. | 13:37 |
| - Ar|stote|is (QUIT: Quit: No Ping reply in 180 seconds.) (~linx@149.210.6.130) | 13:37 | |
| minute | because it thinks these are essential: > libgcc-s1:armhf libc6:armhf (due to libgcc-s1:armhf) | 13:37 |
| minute | trying > sudo apt-get remove --allow-remove-essential libgcc-s1:armhf | 13:38 |
| minute | that worked | 13:41 |
| + Ar|stote|is (~linx@149.210.6.130) | 13:42 | |
| - plomtest (QUIT: Remote host closed the connection) (~plom@user/plomtest) | 13:42 | |
| + plomtest (~plom@user/plomtest) | 13:43 | |
| - paperManu (QUIT: Ping timeout: 265 seconds) (~paperManu@198.58.139.163) | 14:10 | |
| josch | minute: yes, this is known. The problem is, that apt considers packages all packages in the essential set as essential (and thus warns on removal) irrespective of their architecture. There are arguments that apt should only consider packages of the native architecture as essential but there exist use-cases involving cross-grading from one architecture to the other where you actually need more than one | 14:31 |
| josch | architecture in the essenital set. So this is something which pops up every once in a while but nobody is too motivated to work on changing the status quo. So your removal of libgcc-s1:armhf with --allow-remove-essential was exactly the right thing to do in your situation. | 14:32 |
| minute | josch: ok, thanks for explaining! i just didn't encounter this in the past (longer time ago), probably because i didn't have that package installed | 14:33 |
| minute | josch: btw maybe you also have a hint for how to remove a package with broken pre-removal script? | 14:34 |
| minute | actually i can just google that, sorry | 14:35 |
| - wielaard (QUIT: Ping timeout: 256 seconds) (~mjw@gnu.wildebeest.org) | 14:36 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 14:36 | |
| minute | ok i deleted the prerm and postrm scripts | 14:38 |
| minute | josch: btw we should change the default terminal to ptyxis, it appears to be the modern (and faster) replacement for gnome-terminal | 14:53 |
| josch | minute: broken removal scripts are *really* nasty. There is no silver bullet that i know of. We have a bunch of constraints in Debian of what packages never have to be removed because of removal scripts. And there are some nice multi-arch things we cannot have because they would create situations in which removal is no longer possible due to missing deps | 14:53 |
| josch | oh funky -- sure | 14:53 |
| josch | i never heard of it, i'm looking forward to trying it out | 14:54 |
| minute | feels a lot smoother and looks a lot better than gnome-terminal | 14:54 |
| josch | what bugged me about gnome or gnome-terminal or the shell (no idea who the culprit is) is that when you want to launch another terminal it will not do that but instead highlight the terminal window you have already open -- is there an easy way to change this behaviour? | 14:55 |
| minute | josch: well, gnome-terminal has to goooo | 14:56 |
| minute | josch: how did you try to launch the terminal? click in the dock? | 14:56 |
| josch | super+enter | 14:56 |
| josch | or super and then i type "termi" and press enter when it highlights | 14:56 |
| minute | ohh ok i think maybe you were already using ptyxis because i experience this for the first time now :D | 14:57 |
| josch | o0 | 14:57 |
| minute | i guess the shortcut needs to be changed to --new-window | 14:57 |
| josch | no way :D | 14:57 |
| minute | i guess the shortcut needs to be changed to ptyxis --new-window | 14:57 |
| josch | i'll check later | 14:57 |
| minute | josch: i only know ptyxis because yesterday we installed/set up gnome on holo_memory's pocket reform and there it was the default | 14:58 |
| minute | josch: we did that by upgrading reform-desktop-full | 14:58 |
| minute | ok setting my super+return shortcut to "ptyxis --new-window" fixes that | 14:59 |
| minute | i mean, it's a matter of taste, one could also want to open new tabs | 14:59 |
| minute | (ptyxis --tab) | 14:59 |
| josch | foot is also still among the dependencies of reform-desktop-full | 15:00 |
| minute | josch: that can go then | 15:00 |
| minute | josch: so far we had sensible-terminal i think in sway config and it starts gnome-terminal which is a bad experience on sway (and in general) because it's soooo slow for a terminal and also has a murky default theme | 15:01 |
| - jacqueline (QUIT: Read error: Connection reset by peer) (~jacquelin@user/jacqueline) | 15:02 | |
| + jacqueline (~jacquelin@user/jacqueline) | 15:02 | |
| josch | gnome-terminal is not a direct dependency of reform-desktop-full but a dependency of gnome-core | 15:03 |
| josch | so after installing ptyxis, maybe reform-system-image has to manually change the default x-terminal-emulator -- we'll see | 15:03 |
| josch | (meaning, gnome-terminal will still be there even after adding ptyxis to the deps) | 15:03 |
| josch | this might be doing what you had in mind: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/141 | 15:07 |
| minute | josch: nice, many thanks | 15:08 |
| josch | no worries, these are micro changes :) | 15:09 |
| josch | minute: of course also always feel free to edit that file yourself -- remember that i changed the reform-debian-packages build of reform-tools to work this way instead of patches because you wanted to have an easy way to do things like this yourself | 15:09 |
| minute | josch: ok! just wanted to be verbose about it so you're in the loop | 15:10 |
| josch | not saying that you cannot/should not ping me about it, just saying that you should not feel like you had to or something :) | 15:10 |
| josch | thank you, sounds good! :) | 15:10 |
| minute | ok :) | 15:10 |
| + chomwitt (~chomwitt@2a02:85f:9a5f:900:1ac0:4dff:fedb:a3f1) | 15:11 | |
| - pomel0 (QUIT: Ping timeout: 252 seconds) (~pomel0@user/pomel0) | 15:21 | |
| + pomel0 (~pomel0@user/pomel0) | 15:21 | |
| * Guest7939 -> mjw | 15:40 | |
| - pomel0 (QUIT: Remote host closed the connection) (~pomel0@user/pomel0) | 16:02 | |
| - digitalrane (QUIT: Ping timeout: 250 seconds) (~digitalra@user/digitalrane) | 16:09 | |
| - lidstah2 (QUIT: Remote host closed the connection) (~lidstah@gateway/tor-sasl/lidstah) | 16:20 | |
| + lidstah (~lidstah@gateway/tor-sasl/lidstah) | 16:21 | |
| + digitalrane (~digitalra@user/digitalrane) | 16:24 | |
| - paperManu (QUIT: Ping timeout: 252 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 16:35 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 16:37 | |
| - paperManu (QUIT: Read error: Connection reset by peer) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 16:54 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 16:58 | |
| elb | minute: josch: I've been using foot under sway and it seems reasonably well-behaved | 17:48 |
| - paperManu (QUIT: Ping timeout: 256 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 17:54 | |
| + paperManu (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 17:56 | |
| minute | elb: foot under sway is good! | 17:58 |
| minute | grimmware: elb: josch: i made a quick data logger tool to get more info about what happens before a crash reboot https://community.mnt.re/t/restarts-without-warning/3927/35 | 17:59 |
| minute | the idea is that you run this in the background and it will collect all kinds of hardware/sensor/cpu/gpu/memory/freq/irq data and hopefully there will be some pattern in the logs | 18:00 |
| minute | it collects the data every second | 18:00 |
| minute | and syncs | 18:00 |
| minute | so there's a chance that some data will be committed to disk a few seconds before the big bang | 18:00 |
| josch | minute: thank you! next time i encode a video i'll run this and remain connected via ssh to also get the last few log messages before the reboot | 18:04 |
| minute | josch: awesome | 18:05 |
| minute | improvements to this script are welcome of course, but i had to start somewhere... | 18:05 |
| grimmware | https://www.theregister.com/2025/10/22/linux_hibernation_patch/ interesting | 18:07 |
| minute | grimmware: woah woah | 18:07 |
| minute | grimmware: extra interesting that this is from collabora | 18:08 |
| minute | grimmware: regarding the panel fixing stuff, i want to make a kernel-dev script that will help making a stripped down monokernel and document how to boot that over the network for faster iteration | 18:10 |
| grimmware | minute: that would be amazing, although I would say that the biggest thing that slowed me down was having to edit a diff. A more generic workflow that doesn't require you to use emacs would be good. | 18:15 |
| minute | grimmware: yeah totally. that would be included :D | 18:20 |
| grimmware | fantastic :) more than happy to put in a few hours of development, review or testing on that if you get to a place where you can hand some of it off | 18:23 |
| grimmware | minute: incidentally with the debugging for non-battery related reboot, I've got a fair bit of experience with ebpf so if you have some theories you want to prove or disprove we might be able to pivot those into some high performance non-polling tracing, just lmk | 18:34 |
| minute | grimmware: ah very nice. i don't have any solid theories yet though | 18:34 |
| minute | grimmware: so i wanna first check if there are any common "environmental" things among those crashes or no | 18:35 |
| grimmware | minute: getting people to chuck you a `sudo journalctl -k -b -1` would probably be a good shout (dmesg from last boot) | 18:39 |
| minute | grimmware: how often is that saved? or does it only contain dmesg up to login? | 18:44 |
| grimmware | it's the entire dmesg for the last boot, so it's guarantees are essentially whatever journald's are for writing | 18:45 |
| grimmware | I'd expect to see this just truncate for a power related reboot and have something terribly interesting for a kernel related one | 18:47 |
| minute | ok, good call | 18:50 |
| grimmware | yeah, my last power related reboot happens to be my `-b -2` and it truncates after some wifi output whereas the last one has systemd handling the shutdown | 18:52 |
| minute | i'm writing the kernel dev script, and wanted to apply all patches with git-am, but there are some patches that it can't apply, "Patch format detection failed." | 18:53 |
| minute | ah, missing a subject | 18:53 |
| grimmware | I'm excited to have a play with this | 18:54 |
| + wielaard (~mjw@gnu.wildebeest.org) | 18:58 | |
| minute | so far only 1 badly formatted patch... | 19:01 |
| minute | interesting, > error: Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml: patch does not apply | 19:04 |
| minute | during > Applying: ../reform-debian-packages/linux/patches6.16/rk3588-mnt-reform2/0058-dt-bindings-display-vop2-Add-VP-clock-resets.patch | 19:04 |
| grimmware | I think holo_memory's current reboot issue is different from his old one, which is to say I think he has the one you're currently searching for | 19:05 |
| grimmware | You probably know that already but I think it bears saying out loud | 19:06 |
| grimmware | NeonkAaa's looks unrelated | 19:08 |
| grimmware | torb's sounds like holo_memory's on the very small amount of information | 19:08 |
| grimmware | R1ck's is the same | 19:09 |
| minute | grimmware: i suspect so too @ holo_memory. but it's super mysterious what the reset is (it's also quite rare) | 19:10 |
| grimmware | yeah, it could be so many different things. I like that you're going straight to getting them to just run diagnostics rather than getting people to debug | 19:11 |
| rick_ | if i can test sth.. just ping me :D an yeah.. the reboot problem is very.. strange and very hard to tackle.. cause nothing gets logged ^^v | 19:11 |
| rick_ | at least i found nothing.. and i searched for some time | 19:12 |
| grimmware | rick_: make sure to grab a `sudo journalctl -k -b -1` next time :) | 19:13 |
| rick_ | ohh new stuff in the forum.. didn't saw taht | 19:13 |
| rick_ | i did.. well without the k | 19:13 |
| grimmware | oh, you still got it? can I have a look? | 19:14 |
| grimmware | or just the end of it | 19:14 |
| grimmware | minute: a `uname -a` and display version would probably be relevant data here too | 19:17 |
| minute | grimmware: right, both should be added | 19:17 |
| minute | > error: arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts: patch does not apply | 19:18 |
| minute | ah, we have unrelated patches in the patchstack again | 19:18 |
| rick_ | grimmware i think i can find a boot in my journel which had a brownout.. but i didn t change any settings which are mentioned in the forums.. ill try that now | 19:19 |
| rick_ | was 'offline' yesterday | 19:19 |
| + synnfynn (~synnfynn@user/synnfynn) | 19:21 | |
| minute | hm, hdmi driver recently gained CEC huh | 19:30 |
| rick_ | kay, did lock the cpu/gpu at max and startet crashland in the background. lets see if we get sth ^^ | 19:49 |
| minute | rick_: noice | 19:49 |
| - mjw (QUIT: Killed (platinum.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 19:54 | |
| * wielaard -> mjw | 19:54 | |
| + Guest6281 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 19:54 | |
| minute | grimmware: first draft https://source.mnt.re/reform/reform-kernel-dev | 19:56 |
| minute | grimmware: prepare.sh makes a local kernel git with the version that's currently running (this should get some option to make that customizable if you're cross building from another major version etc) and gets all reform specific patches and applies them as regular commits, so you have a git history of all the patches in the right order. then it also configures the kernel with my monolithic | 19:58 |
| minute | kernel config | 19:58 |
| minute | ok. now i need some uboot script to be able to boot this kernel over the network... | 19:59 |
| minute | hm, looks like we don't have tftpboot enabled in rk3588 uboot :# | 20:06 |
| grimmware | oh lol sidequest | 20:09 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 20:19 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 20:19 | |
| - LainIwakura (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 20:24 | |
| ch | whi | 20:28 |
| ch | hi | 20:28 |
| minute | grimmware: yeah... https://source.mnt.re/reform/reform-rk3588-uboot/-/merge_requests/new?merge_request%5Bsource_branch%5D=networking | 20:30 |
| minute | ch: hi! | 20:30 |
| ch | https://source.mnt.re/reform/reform-rk3588-uboot/-/merge_requests/11 better link for us, i think | 20:30 |
| minute | grimmware: sorry wrong link :D | 20:30 |
| minute | haha | 20:30 |
| minute | copied too early lol | 20:30 |
| ch | :) | 20:31 |
| minute | i wonder what the fanciest initramfses are out there | 20:32 |
| ch | mh? | 20:34 |
| ch | dropbear in initramfs is about the fanciest thing i know | 20:34 |
| ch | debian/grml's initramfs has a few nice things like fetch= etc to load the rootfs from elsewhere | 20:35 |
| minute | mhm | 20:36 |
| grimmware | this'll be so fuckin cool to boot ofter tftp | 20:40 |
| grimmware | minute: the script apparently assumes a global git configuration http://paste.debian.net/1402335/ | 20:58 |
| ch | well thats not unreasonable | 21:03 |
| minute | grimmware: ah yeah that's just for git am | 21:03 |
| minute | oh we got new ddr4 firmware (v1.19) | 21:06 |
| grimmware | what's better about it? | 21:15 |
| minute | no idea | 21:16 |
| minute | strangely, my freshly baked kernel freezes during boot | 21:16 |
| minute | > Using asix_eth device | 21:25 |
| minute | > TFTP from server 192.168.1.1; our IP address is 192.168.1.190 | 21:25 |
| minute | => dns mntre.com | 21:29 |
| minute | 91.250.115.15 | 21:29 |
| minute | heh, dns in uboot | 21:29 |
| josch | minute: i welcome your reform-kernel-dev project and i see reform-debian-packages!142 but that makes me fear that the changes you are adding will get outdated by linux6.17 changes | 21:30 |
| minute | josch: doesn't matter i think... the question is how long should we follow the collabora stuff for rk3588 and when do we start preferring mainline and cherrypicking things... | 21:31 |
| josch | for example, the "remove unneeded patches" commit removes 45 files and that work would need to be re-done for 6.17 | 21:31 |
| rick_ | oh nice, with 'export PAN_MESA_DEBUG=gl3' my slicer software finally runs without problems <3 saw a discusssion about that here a few days ago ^^ | 21:32 |
| josch | aha yes, good | 21:32 |
| minute | josch: it makes me uneasy that the rk3588 patchstack is growing and not shrinking | 21:32 |
| josch | minute: i'd like to drop the collabora patch stack rather sooner than later :) | 21:32 |
| minute | josch: i think that's mainly because of rk3576 developments | 21:32 |
| minute | rick_: ah nice | 21:32 |
| josch | it is an oddity in the regular patch rebasing and causing extra work for little gain as many patches do not affect rk3588 anymore | 21:32 |
| minute | josch: yes exactly. i'm just wondering why certain patches are not getting merged and are getting old now... | 21:33 |
| + op_4_ (~tslil@2a01:4f8:c0c:7952::1) | 21:33 | |
| josch | i need to have a very close look at your MR142 and update my linux6.17 branch accordingly | 21:34 |
| + cararemixed_ (sid724089@id-724089.helmsley.irccloud.com) | 21:34 | |
| - synnfynn (QUIT: Quit: WeeChat 4.5.2) (~synnfynn@user/synnfynn) | 21:34 | |
| josch | i am happy that you are fixing up the patch headers | 21:34 |
| josch | that's something which in the past contributions by bremner and vagrantc did | 21:35 |
| + jahkosha_ (~jahkosha@user/jahkosha) | 21:35 | |
| + jn_ (~quassel@2a0a-a54a-68ad-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) | 21:35 | |
| - jn_ (QUIT: Changing host) (~quassel@2a0a-a54a-68ad-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) | 21:35 | |
| + jn_ (~quassel@user/jn/x-3390946) | 21:35 | |
| josch | there is also a more lengthy discussion of whether it makes sense to change the whole patching approach in https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/139 in case you find yourself with too much free time one day :) | 21:35 |
| - jahkosha (QUIT: Killed (zinc.libera.chat (Nickname regained by services))) (~jahkosha@user/jahkosha) | 21:36 | |
| * jahkosha_ -> jahkosha | 21:36 | |
| + mlarkin_ (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 21:36 | |
| + buckket1 (~buckket@vps.buckket.org) | 21:36 | |
| + schalken1 (~schalken@117-118-178-69.gci.net) | 21:37 | |
| minute | lol tftp boot over this 100mbit asix usb ethernet dongle is very slow > 678.7 KiB/s | 21:39 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 21:40 | |
| - Guest6281 (QUIT: *.net *.split) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 21:41 | |
| - schalken (QUIT: *.net *.split) (~schalken@117-118-178-69.gci.net) | 21:41 | |
| - colinsane (QUIT: *.net *.split) (~colinunin@97-113-71-58.tukw.qwest.net) | 21:41 | |
| - buckket (QUIT: *.net *.split) (~buckket@vps.buckket.org) | 21:41 | |
| - jn (QUIT: *.net *.split) (~quassel@user/jn/x-3390946) | 21:41 | |
| - op_4 (QUIT: *.net *.split) (~tslil@user/op-4/x-9116473) | 21:41 | |
| - cararemixed (QUIT: *.net *.split) (uid724089@id-724089.helmsley.irccloud.com) | 21:41 | |
| - mlarkin (QUIT: *.net *.split) (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 21:41 | |
| * op_4_ -> op_4 | 21:41 | |
| * cararemixed_ -> cararemixed | 21:41 | |
| - LainIwakura (QUIT: Client Quit) (~LainIwaku@user/LainIwakura) | 21:43 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 21:44 | |
| - schalken1 (QUIT: Ping timeout: 256 seconds) (~schalken@117-118-178-69.gci.net) | 21:46 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 21:46 | |
| + Guest6281 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 21:47 | |
| + colinsane (~colinunin@97-113-71-58.tukw.qwest.net) | 21:48 | |
| - LainIwakura (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 21:52 | |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 21:54 | |
| minute | ok nice, booted the first kernel over network | 21:55 |
| minute | ah, much faster with 1gbit asix | 21:58 |
| - schalken (QUIT: Ping timeout: 244 seconds) (~schalken@117-118-178-69.gci.net) | 21:59 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 22:02 | |
| minute | mhm mhm https://www.landley.net/toybox/status.html | 22:09 |
| - gustav25 (QUIT: Quit: Quit) (~gustav@c-78-82-53-228.bbcust.telenor.se) | 22:15 | |
| - schalken (QUIT: Ping timeout: 260 seconds) (~schalken@117-118-178-69.gci.net) | 22:24 | |
| - elb (QUIT: Read error: Connection reset by peer) (~elb@68.133.31.194) | 22:24 | |
| + elb (~elb@68.133.31.194) | 22:29 | |
| minute | ok, i have my kernel booting over tftp and starting toybox as shell | 22:30 |
| minute | this takes only a few seconds | 22:30 |
| minute | oh, some kernel config is missing > [ 12.256622] pcieport 0004:40:00.0: deferred probe timeout, ignoring dependency | 22:30 |
| elb | minute: the keyboard debounce logic looks like it appeared out of whole cloth when the initial keyboard firmware was committed; it's kind of complicated, but it appears that what it actually does is just checks to see that a key is pressed for two polling intervals in a row | 22:31 |
| elb | does that sound accurate? | 22:32 |
| minute | elb: yes, that's accurate i think. in the beginning (very long time ago) i experimented with longer intervals etc | 22:32 |
| elb | I'm trying to decide if reducing the logic to exactly that check is valuable or not | 22:33 |
| minute | elb: if it's still possible to change the number of polling intervals later, than yes | 22:34 |
| minute | consecutive ones, that is | 22:34 |
| minute | s/than/then | 22:34 |
| elb | ok, then I won't change anything | 22:34 |
| elb | beacuse the change i had in mind eliminated the debounce array entirely | 22:34 |
| elb | (basically debounce logic became state == 1 && pressed) | 22:35 |
| minute | elb: ah no, that's too much | 22:35 |
| elb | it's pretty easy to use consecutive debounce intervals that are all 1 with just the state array | 22:35 |
| elb | but if you want to be able to investigate history, might as well leave what's there now | 22:36 |
| elb | (basically that would be if state == k && pressed, it's pressed, otherwise if pressed == 1 then state++, otehrwise state = 0) | 22:36 |
| elb | but not a big deal to just leave it as is | 22:37 |
| + nsc (~nicolas@i5C74DC34.versanet.de) | 22:38 | |
| minute | yeah, i still have to do some keyboard debugging on next, i would prefer to have that feature for a while still | 22:38 |
| elb | are the next and pocket keyboard firmwares unified? | 22:39 |
| - nsc (PART: !!unknown attribute: msg!!) (~nicolas@i5C74DC34.versanet.de) | 22:39 | |
| elb | (the next is 2350 IIRC?) | 22:39 |
| elb | I'm not actually sure what I'm hunting at this point; all of this simplification is looking for reasons the keyboard might be drawing more power than it needs to, but I've dug at enough stuff that I think that's going to require measurement I'm not prepared to do at the moment | 22:45 |
| - LainIwakura (QUIT: Quit: Client closed) (~LainIwaku@user/LainIwakura) | 22:45 | |
| elb | although I'm also tracking a bug, my keyboard doesn't reliably light up the OLED and give the power on message when keys are pressed (it used to), and I think that's from making pressed_keys static (I need to verify this) | 22:50 |
| elb | I'm pretty sure there's a race between hid_task and main in accessing pressed_keys | 22:50 |
| elb | but I need to check the processor documentation to see if it's a race we should care about | 22:50 |
| elb | (the processor documentation will clarify both whether it's an actual race and whether if it is a race, we care about it; if it's not an actual race, we just make pressed_keys volatile and problem solved) | 22:53 |
| minute | elb: pocket+next are not unified yet. classic kbd fw4, pocket and next all share code and could be unified potentially | 22:55 |
| elb | nice, I like the sound of that | 22:55 |
| minute | uhm classic kbd fw4+next are actually unified, sorry. but next is a branch there, not fully in main | 22:55 |
| elb | I'm willing to help with that if I can, although not having all three devices it may be that I can't | 22:56 |
| minute | elb: that sounds verry interesting @ race | 22:56 |
| minute | elb: we can provide you with extra keyboards etc if that helps | 22:56 |
| minute | elb: in the next branch of reform2-keyboard4-fw i've implementing a diffing thing where it only sends usb reports when something has changed | 22:57 |
| elb | if it gets to the point that that's directly valuable to you we can talk, but my availibility for projects tends to be bursty, and I don't want to consume resources unless there's a goal I can commit to | 22:57 |
| minute | elb: that greatly reduces usb traffic, but some keydown/up events are lost, and i haven't figured out why yet, and if you found a race, it might be an explanation. | 22:58 |
| elb | yeah I was just looking at that, actually, and wondering if that would save power | 22:58 |
| minute | elb: i think it would, as usb is causing a lot of interrupts | 22:58 |
| elb | yeah but they're not _that_ fast | 22:58 |
| minute | i recently checked powertop and the input device is always high up there | 22:58 |
| elb | 5ms | 22:58 |
| minute | right... | 22:59 |
| elb | I need to learn more about tusb, too | 22:59 |
| elb | I wonder if it's trying to do USB things every 5 ms when powered off | 22:59 |
| minute | it normally shouldn't, but who knows | 22:59 |
| elb | that seems more like a power drain I'm concerned about, but I'm hoping tusb is shutting that down | 22:59 |
| minute | there is an api for detecting if there's a host at least | 22:59 |
| elb | certainly hid_task is trying | 22:59 |
| elb | yeah one of the things I want to look at is stopping hid_task when the device isn't enumerated and active | 23:00 |
| minute | interesting idea | 23:00 |
| elb | I think you could do a substantially slower poll of just the keys, instead | 23:00 |
| minute | certainly has my blessing | 23:00 |
| elb | substantially like factor of 2-5, not 100 | 23:00 |
| minute | right | 23:01 |
| elb | but again, a 5 ms wake cycle on a 2040 at 48 MHz shouldn't be enough drain to matter on those giant cells if it's not actually _doing_ anything | 23:01 |
| elb | thus needing to dig into tusb | 23:02 |
| elb | but I dunno, mA add up | 23:02 |
| minute | > [ 160.415616] PM: suspend exit | 23:05 |
| josch | wat | 23:05 |
| minute | interesting, suspend to ram test works on my monokernel | 23:05 |
| elb | !! | 23:05 |
| josch | rk3588? | 23:05 |
| minute | sure thing! | 23:05 |
| minute | i did this whole setup to be able to debug suspend and pocket panel foo | 23:05 |
| - paperManu (QUIT: Ping timeout: 256 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 23:05 | |
| minute | interestingly there is an mem abort in _phy_state_machine+0x200/0x2f8 but it can continue past that | 23:06 |
| minute | it's directly after gmac-dwmac so possibly related: | 23:07 |
| minute | > [ 158.860198] rk_gmac-dwmac fe1b0000.ethernet: init for RGMII | 23:07 |
| minute | [ 158.860337] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001b8 | 23:07 |
| josch | with or without pci/wifi/nvme? | 23:07 |
| minute | josch: no pcie devices installed, pci root port is there in lspci though (in toybox) | 23:08 |
| minute | aha, like i suspected, with ethernet cable plugged in, the mem abort isn't there | 23:09 |
| minute | ah wait. this is only the "devices" setting of pm_test | 23:09 |
| minute | i'll disable gwmac in the kernel and reboot + try again | 23:10 |
| + paperManu (~paperManu@198.58.139.163) | 23:17 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@98.19.131.193) | 23:19 | |
| vagrantc | yay. updating the lpc firmware seems to have fixed my battery reporting issues from the kernel module... and serial console seems less noisy too ... a little bit of ghosting on the OLED display, though ... ghosted faded battery status information lingers when doing other things | 23:20 |
| + LainIwakura (~LainIwaku@user/LainIwakura) | 23:20 | |
| vagrantc | (or at least, the first two boots seem to be reporting battery status correctly... have had the dumb luck "it worked!" before) | 23:20 |
| elb | wait I'm an idiot, we're only using one of the two cores, this absolutely _is not_ a bus-level race, and it's the kind of thing that can absolutely be fixed by volatile | 23:21 |
| vagrantc | entirely possible that the ground connection for the serial adapter was just loose... | 23:21 |
| minute | elb: nice | 23:26 |
| minute | i wanted a text editor for my toybox linux and was happy that go stuff (like micro) comes as static binary, and it starts but complains that > open /dev/tty: no such device or address | 23:33 |
| minute | i should probably use "oneit" | 23:35 |
| vagrantc | ok, pretty confident the serial problems are just a loose connector ... flipping it upside down torqued the serial cable and i can now see through the transparent bottom plate (yay!) that the ground pin has wiggled pretty loose | 23:35 |
| josch | busybox would have vi as an editor | 23:37 |
| minute | ahaha i got it to work | 23:43 |
| minute | i renamed /dev/tty and ln -s /dev/console /dev/tty | 23:43 |
| minute | (and export TERM=xterm) | 23:43 |
| minute | josch: i wasn't able to compile busybox, tried that first... it doesn't build on my debian for some reason | 23:43 |
| minute | josch: doesn't find ncurses | 23:44 |
| minute | josch: well, i didn't really build busybox itself, but tried make menuconfig | 23:44 |
| - LainIwakura (QUIT: Ping timeout: 250 seconds) (~LainIwaku@user/LainIwakura) | 23:46 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 23:48 | |
| minute | ok, so with gmac0 disabled, "devices" pm_test is clean | 23:49 |
| josch | minute: you can use the same tools used in reform-system-image to make a multi-gb system image to make tiny initramfs as well. For example, a "real" Debian (no busybox) fits into 24 MB gzipped. You'd trade the time you spend on fiddling with the limitations of busybox/toybox for a few more MB to transfer. | 23:50 |
| minute | josch: well, i would have to learn how to build that 24mb debian system too | 23:50 |
| minute | josch: also, the system is already fine now... i only wanted a text editor so i don't have to rebuild the system to make a change to some scripts | 23:51 |
| josch | okay! | 23:51 |
| minute | ok, devices test works | 23:51 |
| minute | darn | 23:51 |
| minute | i meant, platform test works | 23:51 |
| minute | ah, i didn't realize that hdmi works all the time as well (i just saw my camlink usb stick blinking off and on during suspend test) | 23:51 |
| minute | power goes down to 0.38A @ 12V during "platform" test | 23:52 |
| minute | processors test works as well! | 23:53 |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2a02-8434-b6a3-e901-facc-8e87-8e54-890e.rev.sfr.net) | 23:54 | |
| minute | ok so all those tests work, suspends and exits cleanly | 23:54 |
| minute | now the question is, how to make it wake from an external input | 23:54 |
| grimmware | ... | 23:55 |
| grimmware | wow | 23:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!