| - shook_queen (PART: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)) (~user@user/spencerb) | 00:20 | |
| - Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66) | 00:43 | |
| - chomwitt (QUIT: Ping timeout: 248 seconds) (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 01:01 | |
| digitalrane | i'm trying to build a 6.12.22 kernel using the rk3588 reform2 dts copied into the tree and I'm getting an error about a missing DT node hdptxphy1 - I haven't been able to find where this is being defined? Is there a patch I'm missing which adds this? | 01:36 |
|---|---|---|
| josch | digitalrane: vagrant has also seen this. The device tree is for kernel 6.14 and may not work anymore with 6.12 | 01:38 |
| josch | digitalrane: I want to address this issue in the future because 6.12 is the kernel in the next Debian stable release | 01:38 |
| josch | so that'll be the kernel on reform.debian.net and i thus need to build it somehow | 01:38 |
| digitalrane | ah cool that would explain it, thanks! I knew I'd probably save myself a bunch of time if I just asked instead of doing more grep engineering lol | 01:38 |
| digitalrane | i wonder if the node has just been renamed, hmm | 01:39 |
| josch | digitalrane: maybe this one works: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/89 | 01:39 |
| josch | but i don't have an rk3588 (yet) so i wasn't able to test this patch | 01:39 |
| digitalrane | you and me both :) | 01:41 |
| digitalrane | what would one do with such power anyhow | 01:41 |
| josch | i have a normal intel laptop for work and am wondering the same thing :D | 01:42 |
| digitalrane | it's strange because this patch adds hdptxphy_hdmi1 but I can't see that defined elsewhere either | 01:43 |
| josch | it has been too long ago for me to remember | 01:43 |
| josch | i essentially tweaked the upstream dts until the output was the same as with the vendored copy by MNT | 01:44 |
| digitalrane | rk3588-base has hdptxphy_hdmi0 though | 01:44 |
| digitalrane | hmm ok this is a really good lead, thanks | 01:45 |
| digitalrane | it's stopping me from compiling the kernel so I can at least dig into the upstream dts collection and see what might have changed | 01:45 |
| digitalrane | i'm not blocked or anything I can also just not add the dts to the tree I'm compiling (for NixOS) but I'd like to enable rk3588 at some point | 01:46 |
| digitalrane | i know some in the community are hoping for that | 01:46 |
| digitalrane | NixOS is however booting on pocket again which was a cool milestone yesterday, with NixOS 24.11 + 6.12 kernel | 01:47 |
| digitalrane | just trying to get my imx8mq reform2 going now :) | 01:47 |
| - mjw (QUIT: Ping timeout: 260 seconds) (~mjw@gnu.wildebeest.org) | 01:53 | |
| digitalrane | ok I think we are just missing hdm1-con from the patched dts | 01:54 |
| digitalrane | s/hdm1-con/hdmi1-con/ | 01:55 |
| digitalrane | example: https://patchwork.kernel.org/project/linux-rockchip/patch/20250223-vop2-hdmi1-disp-modes-v2-5-f4cec5e06fbe@collabora.com/ | 01:55 |
| digitalrane | i left a comment on the mr with the node I think needs to be added | 02:06 |
| - GNUmoon (QUIT: Ping timeout: 264 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:06 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 02:07 | |
| - mlarkin (QUIT: Ping timeout: 248 seconds) (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 02:55 | |
| - paperManu (QUIT: Ping timeout: 244 seconds) (~paperManu@172.93.30.55) | 03:52 | |
| + mlarkin (~mlarkin@syn-076-081-194-027.biz.spectrum.com) | 04:14 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 05:30 | |
| - jacobk_ (QUIT: Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 05:33 | |
| josch | digitalrane: thank you! | 07:22 |
| josch | ah and this commit that added it https://github.com/torvalds/linux/commit/77cea7ca13680e14119a3b9635c7ef16cd7ee44e that's the patchwork.k.o link from linux-rockchip that you linked to yesterday | 07:24 |
| zeha | why is apt so slow on arm64 | 07:29 |
| zeha | specifically apt update | 07:30 |
| zeha | ugh, somethings not right in unstable | 07:46 |
| zeha | a) display has the wrong size on text console | 07:46 |
| zeha | b) ssh is broken!? | 07:47 |
| zeha | b) might be some agent funkyness | 07:47 |
| zeha | a) stays across poweroff, so i guess kernel issue | 07:50 |
| josch | zeha: apt update is fast on amd64?? | 07:54 |
| josch | zeha: is your display issue the same that some users reported in the forum? only the right-hand side gets rendered to | 07:55 |
| josch | did you just upgrade to 6.14? | 07:55 |
| - xha (QUIT: Quit: WeeChat 4.5.2) (~xha@user/xha) | 08:10 | |
| digitalrane | has anyone had 6.12 booting on reform2 with imx8mq? I have it booting but can't seem to get the display working on 6.12.22 with the reform patch stack and upstream dts | 08:15 |
| digitalrane | most images I see are using 6.6 still afaict | 08:16 |
| zeha | josch: yeah probably. 6.14.6-mnt-reform-arm64 6.14.6-1~exp1+reform20250508T045900Z | 08:18 |
| zeha | 2025-05-12 07:35:26 install linux-image-6.14.6-mnt-reform-arm64:arm64 <none> 6.14.6-1~exp1+reform20250508T045900Z | 08:19 |
| zeha | https://zeha.at/~ch/IMG_6169.jpeg | 08:20 |
| josch | digitalrane: i have 6.12 booting on imx8mq classic reform with the patch stack but with this patch to upstream dts: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/84 | 08:36 |
| josch | zeha: your photo looks like these: https://community.mnt.re/t/problems-with-display-and-clock/3379 https://community.mnt.re/t/display-and-softlock-issues-after-using-hdmi-through-usb-hub/3382 | 08:39 |
| zeha | indeed | 08:40 |
| digitalrane | thanks josch, was just checking over the stock debian images to work out what I might be missing :) | 08:53 |
| digitalrane | seems the display does not work on 6.14 image also but suspect it's the same issue as the logs are the same | 08:54 |
| minute | digitalrane: hmm i've tested imx8mq with 6.14 (and our patchset) and it works... or do you mean unpatched mainline? | 10:32 |
| minute | zeha: ugh. looks like hdmi is detected without hdmi monitor? | 10:33 |
| minute | zeha: like, the console is set up like this because of the mix of rotation and external hdmi which might be unrotated | 10:33 |
| zeha | yeah maybe. can check logs and such in the afternoon | 10:34 |
| minute | maybe the new hdmi drivers have a bug regarding hpd or i messed some pinctrl up | 10:35 |
| - cobra (QUIT: Ping timeout: 248 seconds) (~cobra@user/Cobra) | 10:35 | |
| minute | btw so far i didn't encounter usb-not-working-at boot anymore with my uboot usb hub reset + 6.14 on rk3588 | 10:37 |
| minute | zeha: can reproduce @ boot console m))) | 10:38 |
| minute | my mistake was not testing _without_ hdmi connected. also i have gdm and it's fine in gdm | 10:39 |
| minute | and under gnome the hdmi is not seen as connected hm | 10:39 |
| minute | (correctly) | 10:39 |
| minute | oh wait, not true | 10:40 |
| minute | second display is just turned off but listed as "unkown display", 1024x768 | 10:40 |
| minute | so something is borked with hpd on hdmi0 | 10:40 |
| minute | (btw i believe we can get rid of that ugly manual reset of ethernet in reform-hw-setup, but not sure how to let people test that) | 10:41 |
| minute | ok yes it's a dts error | 10:49 |
| minute | external hdmi hpd line should be hdmi_tx1_hpd_m1 | 10:50 |
| minute | but according to my sysfs it's currently hdmim0-tx1-hpd | 10:50 |
| minute | m0 vs m1 | 10:50 |
| minute | fix: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/104/diffs | 11:06 |
| - Gooberpatrol66 (QUIT: Ping timeout: 276 seconds) (~Gooberpat@user/gooberpatrol66) | 11:06 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:08 | |
| + andreas-e (~Andreas@2001:861:c4:f2f0::c64) | 11:22 | |
| - andreas-e (QUIT: Client Quit) (~Andreas@2001:861:c4:f2f0::c64) | 11:23 | |
| + andreas-e (~Andreas@2001:861:c4:f2f0::c64) | 11:39 | |
| josch | minute: wow, nice that was a quick fix! :) | 11:54 |
| josch | digitalrane: yes, i tested 6.14 on imx8mq and display works fine here | 11:54 |
| josch | i suspect you are just missing either one of the patches or one of the kernel configs set to "y" | 11:55 |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 12:08 | |
| digitalrane | hmm I'll double check kernel config, thanks | 12:26 |
| digitalrane | these are the kernel messages I'm getting, which look troubling: https://paste.debian.net/1374262/ | 12:27 |
| digitalrane | oh yep ok looks like DRM_TI_SN65DSI86 is no longer in the config | 12:43 |
| + paperManu (~paperManu@172.93.30.55) | 12:44 | |
| + gustav28 (~gustav@c-78-82-53-72.bbcust.telenor.se) | 13:02 | |
| - elb (PART: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)) (~elb@2600:4041:6671:1300:d88b:69d4:6207:2b9) | 13:26 | |
| + elb (~elb@2600:4041:6671:1300:d88b:69d4:6207:2b9) | 13:26 | |
| elb | I'm curious (and eager?) to know what the approximate lead time is on pocket reforms right now; I ordered from shop.mntre.com in early April, but the estimate on the order page has remained perpetually the same distance out (weeks before I ordered to now) and my specific order has no updates | 13:26 |
| elb | (this is not urgent and not a formal request for support) | 13:27 |
| zeha | https://community.mnt.re/t/battery-voltage-jumps/3360/9 <- did that account get approved? | 13:58 |
| * mjw -> Guest1042 | 14:12 | |
| - Guest1042 (QUIT: Killed (erbium.libera.chat (Nickname regained by services))) (~mjw@gnu.wildebeest.org) | 14:12 | |
| * Guest3345 -> mjw | 14:12 | |
| + Guest1042 (~mjw@gnu.wildebeest.org) | 14:13 | |
| minute | zeha: checking | 14:58 |
| minute | gitlab is super slow for me somehow | 15:00 |
| + chomwitt (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 15:02 | |
| minute | zeha: approved | 15:08 |
| - bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:12 | |
| zeha | cool | 15:15 |
| + bkeys (~Thunderbi@66.110.201.50) | 15:17 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 15:48 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:49 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 15:53 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 15:54 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 15:57 | |
| - bkeys1 (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 15:58 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@38-146-94-247.echocast.zone) | 16:00 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 16:00 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:06 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 16:08 | |
| * bkeys1 -> bkeys | 16:08 | |
| minute | zeha: do you know if there's a better scriptable method for checking the current sysctl+hid fw versions than grepping `fwduptool get-devices`? the --json output doesn't seem to include the versions | 16:18 |
| - bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50) | 16:23 | |
| zeha | "Name" : "Pocket Reform System Controller 1.0", | 16:27 |
| zeha | "Version" : "20250504", | 16:27 |
| zeha | no? | 16:27 |
| zeha | in `fwupdmgr get-devices --json` | 16:27 |
| zeha | but maybe i'm missing something | 16:27 |
| minute | ah weird. for me it didn't show | 16:58 |
| minute | maybe fwupdmgr vs fwupdtool? | 16:58 |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 17:05 | |
| - Guest1042 (QUIT: Ping timeout: 248 seconds) (~mjw@gnu.wildebeest.org) | 17:06 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 17:18 | |
| zeha | maybe | 17:21 |
| zeha | fwupdtool get-devices --json doesnt show a lot | 17:22 |
| minute | ah ok, so they're different | 17:25 |
| minute | rebooting gitlab machine, but it's OOM, need to double the ram | 17:25 |
| minute | ok i'll fix the power-loss-after-updating-fw-and-then-issuing-power-on-or-brightnessctl bug now | 17:38 |
| minute | when doing brightnessctl with display v2 after a fw update, it hangs the rp2040... and i think it's because we rug pull the power of the SPI host because of this bug | 17:38 |
| minute | like, the system powers off and then we get T in the oled, rp2040 hangs | 17:39 |
| zeha | shouldnt that just work again after the rp2040 resets? | 17:39 |
| + bkeys (~Thunderbi@66.110.201.50) | 17:40 | |
| minute | no, because of the recently discussed gpio state not being restored | 17:40 |
| minute | which i'll fix now | 17:40 |
| zeha | ah! | 17:40 |
| zeha | ugh | 17:40 |
| minute | well, it's nice to finally understand this now ^^ | 17:40 |
| zeha | yeah | 17:40 |
| zeha | so you'll "just" add code to setup() to restore the gpios depending on if the som was powered on? | 17:41 |
| minute | zeha: i'm gonna reuse the power on/off functions https://source.mnt.re/reform/pocket-reform/-/merge_requests/38/diffs | 17:52 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:55 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:55 | |
| zeha | btw https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/104/diffs works for me | 17:57 |
| zeha | forgot to mention | 17:57 |
| zeha | MR 38: right, makes sense to me. (but haven't thought it through, brain is already somewhat fried from work today) | 17:58 |
| minute | ok, i've tested !38 on device now and it works. but i'll have to test it with display v1 as well | 17:58 |
| minute | zeha: thanks for feedback on !104 | 17:58 |
| zeha | i can also test it i guess | 17:59 |
| zeha | hmm | 18:01 |
| zeha | display turned off | 18:01 |
| zeha | not good :) | 18:01 |
| zeha | linux host and rp2040 are running though | 18:02 |
| minute | zeha: do you have display v1 or v2? | 18:03 |
| minute | zeha: iirc v1? | 18:03 |
| zeha | should be v1 | 18:03 |
| minute | ah, probably turns off because of the reset | 18:03 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:06 | |
| + bkeys (~Thunderbi@66.110.201.50) | 18:06 | |
| minute | ha, no, DISP_EN is not restored at all | 18:06 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 18:21 | |
| + bkeys (~Thunderbi@66.110.201.50) | 18:22 | |
| minute | https://source.mnt.re/reform/pocket-reform/-/merge_requests/39/diffs | 18:24 |
| zeha | display is back on but black. let me reboot and try again | 18:31 |
| zeha | hmm | 18:32 |
| zeha | power on: display backlight turns on, turns off, turns back on, but then no display output | 18:32 |
| zeha | (linux boots) | 18:34 |
| minute | zeha: same here, ok, let me try again, sorry | 18:34 |
| zeha | kk, np | 18:35 |
| zeha | as long as i can blind type the luks passphrase and it boots into linux somehow | 18:35 |
| minute | ah i think i know | 18:35 |
| zeha | should have checked where my recovery sd card is | 18:35 |
| minute | oops | 18:35 |
| minute | i'm checking battery_info.som_is_powered but that isn't actually set :D | 18:35 |
| zeha | hah | 18:36 |
| minute | (not at the right moment at least) | 18:36 |
| - arminweigl (QUIT: Ping timeout: 276 seconds) (~arminweig@sourcehut/user/arminweigl) | 18:36 | |
| minute | zeha: ah btw, after power cycle, does the display work or no? | 18:36 |
| minute | like, normal power cycle | 18:36 |
| minute | not the one done by fw update | 18:37 |
| minute | (and not reboot) | 18:37 |
| zeha | no | 18:41 |
| zeha | as said above, backlight comes on, then it turns off again, turns on again, but no output | 18:41 |
| zeha | (that was after power off / on) | 18:41 |
| minute | ah ok, i had that only directly after the update | 18:42 |
| minute | with this one, the update at least works well now with disp v2, i.e. everything survives the update, incl i can use power on on the keyboard and it doesn't turn off the system https://source.mnt.re/reform/pocket-reform/-/jobs/9933 | 18:43 |
| minute | but i need to check if i still didn't get reset right for disp v1 | 18:43 |
| + arminweigl (~arminweig@sourcehut/user/arminweigl) | 18:46 | |
| - bkeys (QUIT: Ping timeout: 265 seconds) (~Thunderbi@66.110.201.50) | 18:47 | |
| minute | mhm | 18:48 |
| zeha | i just updated into the new fw, and i think linux shut down, but the rp2040 seems to think the som is still on | 18:48 |
| minute | hmm why did linux shut down? | 18:48 |
| zeha | (= keyboard did not turn off bg leds, battery status shows 'On') | 18:48 |
| zeha | sorry, i just updated into the new fw + sudo poweroff | 18:48 |
| zeha | so maybe poweroff is now broken ;) | 18:48 |
| minute | ah so lpc command was not executed maybe | 18:49 |
| minute | poweroff works here :D | 18:49 |
| zeha | no display after poweron | 18:49 |
| minute | yeah, might be related to the pwm stuff on disp_en, will do this a bit differently now | 18:49 |
| zeha | ok, poweroff works after a power cycle | 18:50 |
| zeha | so display behaviour on power on is still: backlight on, backlight off, backlight on, no output | 18:50 |
| minute | ok thanks, one moment | 18:51 |
| minute | ok pushed but also need to try myself :D | 18:59 |
| zeha | seems good! | 19:02 |
| minute | oh? display goes on again? | 19:02 |
| zeha | so after poweron behaviour is now: keyboard lights come on, bit of delay, display backlight turns on and output shows | 19:03 |
| zeha | which is i think the old behaviour | 19:03 |
| minute | cool yes | 19:03 |
| zeha | flashing the same firmware again also seems to just work | 19:03 |
| minute | and then doing power on on keyboard doesn't disrupt stuff, right? | 19:03 |
| zeha | yeah, no funky business | 19:04 |
| minute | awesome, thanks for testing | 19:04 |
| zeha | poweroff also works | 19:04 |
| minute | nice | 19:04 |
| zeha | sudo poweroff that is | 19:04 |
| zeha | power off from menu is also fine | 19:05 |
| minute | nice | 19:07 |
| minute | ok, works fine here too with disp v2 | 19:12 |
| minute | merged | 19:12 |
| - arminweigl (QUIT: Ping timeout: 244 seconds) (~arminweig@sourcehut/user/arminweigl) | 19:16 | |
| hramrach | was the root cause of the exploding power chips found? | 19:16 |
| + arminweigl (~arminweig@sourcehut/user/arminweigl) | 19:26 | |
| + Guest1042 (~mjw@gnu.wildebeest.org) | 19:38 | |
| minute | hramrach: well, there is only a theory (input voltage spike due to ringing/tank circuit effect) and we can mitigate for that, but it's unsatisfying that i couldn't reproduce this effect in the lab (except when plugging a live 20v power source directly into the charger board, as opposed to usb-c pd supply) | 19:40 |
| minute | maybe it's an interaction with the battery protection chip/its FETs that have the ability to quickly (dis)connect the circuit, but that's downstream from charger IC | 19:41 |
| minute | i guess i could test that | 19:41 |
| minute | i got xrays and microscopy results of some damaged chips | 19:42 |
| minute | should publish them soon | 19:42 |
| hramrach | so it would be problem with the outout side, not the input side of the IC then | 19:43 |
| minute | the problem is def. at the input side though. not sure if toggling the output would affect the input in such a way | 19:43 |
| ^alex | ah, does the charger board need a snubber diode somewhere | 19:47 |
| hramrach | I did some theoretical simulations to determine if my own circuit would explode, and in the simulation (with unrealistic fixed voltage supply, and unrealistici fixed capacitance capacitor) the more capacitance was between the PMIC and the inductor the smoother the voltage curve (so long as you do not need to worry about reverse voltage, which you don't because you have that diode that people | 19:48 |
| hramrach | complain about) But real capacitors have lower capacitance at higher voltage, and the USB VBUS is limited to 10uF, a capacitor rated 10uF/50V has about 5uF at 20V whch is not much. | 19:48 |
| - wiedi (QUIT: Ping timeout: 265 seconds) (~wiedi@ip5f58441e.dynamic.kabel-deutschland.de) | 19:51 | |
| hramrach | 'ideal diode' circuits are available that, compared to plain schottky diode decrease the voltage drop by using an integrated mosfet driver and mosfet, and many come with inrush current control as well. It comes at a cost, though. While a nice diode might be $0.1~0.3 these are about $1~3 | 19:51 |
| + wiedi (~wiedi@ip5f58441e.dynamic.kabel-deutschland.de) | 19:51 | |
| hramrach | with such an 'ideal diode' you can increase the input capacitance without violating USB specification, reduce the voltage drop so people can charge from lower voltage supplies, and still get reverse polarity protection | 19:55 |
| hramrach | well, in theory at least | 19:56 |
| - chomwitt (QUIT: Ping timeout: 265 seconds) (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 20:32 | |
| + chomwitt (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 20:59 | |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 21:06 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 21:07 | |
| potatoespotatoes | hi-o! I'm noticing that wifi adapter are not visible via lspci but are visible through lsusb. is that right? | 21:10 |
| potatoespotatoes | (I'm running on an impoverished sd card image right now, trying to figure out how to make a user-friendly-ish image for folks). | 21:12 |
| + bkeys (~Thunderbi@66.110.201.50) | 21:19 | |
| hramrach | it depends on the adapter | 21:20 |
| minute | potatoespotatoes: on which device? | 21:38 |
| potatoespotatoes | pocket reform | 21:39 |
| minute | potatoespotatoes: and which processor? | 21:39 |
| minute | potatoespotatoes: and what does impoverished mean? | 21:39 |
| potatoespotatoes | ahh | 21:40 |
| potatoespotatoes | i'm working on the rk3588 | 21:40 |
| potatoespotatoes | by impoverished I mean that I'm building an image for guixSD and I just added vim a moment ago : ) I'm currently working on getting wifi operational on boot. | 21:41 |
| potatoespotatoes | (on boot of the microSD card) | 21:42 |
| potatoespotatoes | I guess I'm just surprised to see the wifi adapter on the USB interface, but it sounds like it's not unusual | 21:44 |
| minute | potatoespotatoes: ah i see. yes, we use a rare m.2 usb card for this combination | 21:46 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 21:48 | |
| + bkeys (~Thunderbi@66.110.201.50) | 21:48 | |
| potatoespotatoes | cool! | 21:51 |
| + Gooberpatrol_66 (~Gooberpat@user/gooberpatrol66) | 21:54 | |
| - Gooberpatrol66 (QUIT: Ping timeout: 244 seconds) (~Gooberpat@user/gooberpatrol66) | 21:54 | |
| - mjw (QUIT: Killed (zirconium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 22:07 | |
| * Guest1042 -> mjw | 22:07 | |
| + Guest4753 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 22:07 | |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-53-72.bbcust.telenor.se) | 22:15 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 22:35 | |
| - Gooberpatrol_66 (QUIT: Ping timeout: 244 seconds) (~Gooberpat@user/gooberpatrol66) | 22:36 | |
| minute | gitlab server is bumped to 8gb ram (from 4gb) which fixes intermittent slowness, and gitlab upgraded | 22:36 |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 22:41 | |
| josch | minute: thank you! I was told by another gitlab admin that it is in fact "normal" to have to reboot the machine running gitlab regularly as it is known to leak memory when running for a long time... | 22:44 |
| minute | uff | 22:44 |
| + bkeys (~Thunderbi@66.110.201.50) | 22:51 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 22:59 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 22:59 | |
| * bkeys1 -> bkeys | 22:59 | |
| - Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66) | 23:02 | |
| - bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50) | 23:08 | |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2001:861:c4:f2f0::c64) | 23:08 | |
| abortretryfail | I don't think we have to do that with the two we have at my work, but we're also not running CI builds all day every day. | 23:11 |
| + bkeys (~Thunderbi@66.110.201.50) | 23:11 | |
| abortretryfail | Oh, they do auto-reboot regularly for kernel updates, so maybe the problem is just hidden by that. | 23:11 |
| kfx | we don't have it at my job, but it's probably because gitlab issues patch releases (and we restart after them) so frequently that we don't need more | 23:18 |
| - bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@66.110.201.50) | 23:19 | |
| + bkeys (~Thunderbi@66.110.201.50) | 23:20 | |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@66.110.201.50) | 23:22 | |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 23:24 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 23:42 | |
| + chomwitt (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 23:43 | |
| minute | yeah for us 4gb was just not enough anymore, it was eating into swap even after a reboot | 23:49 |
| abortretryfail | oof | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
