| - S0rin (QUIT: Ping timeout: 245 seconds) (~S0rin@user/s0rin) | 00:19 | |
| + S0rin (~S0rin@user/s0rin) | 00:20 | |
| + tiskaan (~tiskaan@84.70.121.60) | 00:37 | |
| - eibachd (QUIT: Read error: Connection reset by peer) (~eibachd@pd9509587.dip0.t-ipconnect.de) | 01:21 | |
| + eibachd (~eibachd@p200300dcf7231c00eca0985b93716e8e.dip0.t-ipconnect.de) | 01:21 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 01:23 | |
| - erle (QUIT: Remote host closed the connection) (~erle@2a02:3102:4286:16:fb3b:63a:be5:cdd8) | 01:28 | |
| + erle (~erle@2a02:3102:4286:16:7f27:d647:dfee:e8c4) | 01:28 | |
| - tiskaan (QUIT: Ping timeout: 245 seconds) (~tiskaan@84.70.121.60) | 01:35 | |
| + tiskaan (~tiskaan@84.70.121.60) | 01:40 | |
| - XYZ_ (QUIT: Ping timeout: 246 seconds) (~XYZ@37-48-8-216.nat.epc.tmcz.cz) | 01:55 | |
| + XYZ_ (~XYZ@78-80-123-108.customers.tmcz.cz) | 02:00 | |
| - tiskaan (QUIT: Ping timeout: 264 seconds) (~tiskaan@84.70.121.60) | 02:09 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 02:16 | |
| + mjw (~mjw@gnu.wildebeest.org) | 03:31 | |
| - nsc (QUIT: Ping timeout: 260 seconds) (~nicolas@173-48-142-46.pool.kielnet.net) | 03:42 | |
| + nsc (~nicolas@i5E86126B.versanet.de) | 03:44 | |
| erle | <minute> (and my reform has gone through many versions) | 04:24 |
|---|---|---|
| erle | reform of theseus | 04:24 |
| - chomwitt (QUIT: Ping timeout: 246 seconds) (~chomwitt@2a02:587:7a0f:8900:1ac0:4dff:fedb:a3f1) | 04:43 | |
| - erle (QUIT: Ping timeout: 256 seconds) (~erle@2a02:3102:4286:16:7f27:d647:dfee:e8c4) | 05:09 | |
| violet | trying to figure out how i wanna solve a problem on my soquartz project | 05:28 |
| violet | so the rk3566 cannot hardware-PWM the pin which is wired up to the backlight PWM brightness control on the CM4->Reform adapter module. lol | 05:28 |
| violet | right now im looking at a few things. 1 is, there is an out of tree patch ( https://lore.kernel.org/all/20200915135445.al75xmjxudj2rgcp@axis.com/T/ ) which implements software GPIO PWM using a timer. which i guess would work and is maybe the simplest to get going so im probably gonna do it before trying anything else anyway | 05:29 |
| violet | but in terms of hardware mods right now my two thoughts are either soldering onto the card edge or cutting open the PWM pin on the bundle of display wires. and then wiring the other end to the hack the planet port and doing something with the system controller. or trying to stick a new PWM chip somewhere and giving the system a way to talk to it in whatever way is easiest | 05:30 |
| - mjw (QUIT: Ping timeout: 268 seconds) (~mjw@gnu.wildebeest.org) | 05:32 | |
| - jagtalon (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@user/jagtalon) | 08:45 | |
| + jagtalon (~quassel@user/jagtalon) | 08:46 | |
| - jagtalon (QUIT: Client Quit) (~quassel@user/jagtalon) | 08:46 | |
| + jagtalon (~quassel@user/jagtalon) | 08:46 | |
| + erle (~erle@2a02:3102:4286:16:551e:a464:7889:a99b) | 10:05 | |
| - klardotsh (QUIT: Ping timeout: 245 seconds) (~klardotsh@c-67-170-115-80.hsd1.wa.comcast.net) | 10:36 | |
| minute | violet: there are two cm4 pins going to the reform backlight pwm pin because i already had that issue with bpi vs rpi. can both not do pwm on the rk? | 11:14 |
| minute | violet: also, do you already have working display?? | 11:15 |
| violet | sadly, i dont | 11:18 |
| violet | but i think im making progress | 11:19 |
| violet | feels like one of those things where soon im either going to learn what im doing wrong or im going to learn that its actually impossible | 11:19 |
| violet | but tl;dr there's some kind of trouble with the dsiphy. not sure what other than the dsi driver cannot succesfully lock the dsi phy, which is where im leaving it for now | 11:21 |
| violet | might have to do a bunch of println debugging in the phy driver lol | 11:21 |
| violet | its very strange because all of the known-working examples ive seen of dsi outputs with this SoC look so simple | 11:22 |
| violet | but also: none of them have ever used DSI1, they all use DSI0. so for all i know theres something funky about that. hope not though | 11:23 |
| violet | minute: as for the backlight pwm pin, i cant find the second pin you're talking about on the paper schematic. on here i see pin 29 on the left CM4 connector going to PI_BACKLIGHT_PWM and i see PI_BACKLIGHT_PWM going to BACKLIGHT_PWM. but i dont see anything else going to it | 11:25 |
| violet | which pin is it? | 11:26 |
| minute | violet: ohh ok. in any case for backlight i would first just set it up as gpio and turn it fully on. then you don't need to do a lot of work there with unclear outcome | 11:26 |
| violet | yeah thats what ive been doing | 11:26 |
| violet | and thats been working fine | 11:26 |
| violet | its not something im going to poke at until i see pixels on screen | 11:27 |
| minute | violet: hmm, you have the bpi version of the rcm4 manual yes? it could be an error on my part if i didn't update the schematic to that last change | 11:27 |
| violet | yeah i do | 11:28 |
| minute | i am making some coffee and will check the pin for you | 11:28 |
| violet | ty! | 11:28 |
| minute | about the dsi, maybe you can share your WIP device tree how it is at the moment? i can have a look | 11:29 |
| minute | violet: http://dump.mntmn.com/reform-pi.pdf | 11:36 |
| minute | violet: both GPIO12 and GPIO16 (of pi cm4) are connected to the backlight pwm pin | 11:38 |
| violet | cool, ty! | 11:38 |
| minute | each has a 1k resistor to prevent shorts | 11:38 |
| violet | here's my WIP stuff and some other relevant files https://x.artemis.sh/files/misc/reform-dbg/1/ | 11:38 |
| minute | (that's R25 and R18) | 11:38 |
| violet | soquartz-reform.dts is the file i have been hacking on | 11:38 |
| violet | but i put the dtsis in too, they're from linux 6.6.8 stable | 11:39 |
| violet | also panel-edp.c because i modified the mode to try to do a 60Hz mode when i was thinking maybe the problem was that it had a 70Hz mode but at this point im not sure if thats relevant one way or the other | 11:39 |
| minute | violet: in my experience it is a good idea to print-debug the dsi clock calculation / which dsi clock is used/trying to lock | 11:40 |
| violet | ive been referencing https://github.com/CounterPillow/overlay-examples/blob/main/quartz64a/pine64-lcd-panel.dts#L56-L62 as well as the anbernic rk3566 devicetrees which are in 6.6.8 | 11:41 |
| violet | uploaded the relevant one to that folder, rg353x | 11:42 |
| violet | but yeah mostly what i know is that VPLL is a clock that is used for pixel clock stuff and not much else, and that it needs to be manually set based on that | 11:42 |
| minute | i see, looks plausible | 11:43 |
| minute | violet: do you get any dmesg output from sn65sdi86? | 11:44 |
| violet | yeah i sure do, sec | 11:45 |
| violet | https://dpaste.com/EQGNSGW4Y | 11:46 |
| violet | in this block of dmesg you can see it starts to do the modeset. there's that [drm:dw_mipi_dsi_mode_set [dw_mipi_dsi]] failed to wait phy lock state. and then there's some sn65dsi86 stuff which ultimately fails on the eDP communication | 11:47 |
| violet | which, if im reading the mainboard schematic right, it doesnt have its own refclk, so its relying on the DSI clock to do that. and then my further assumption is its not getting that DSI clock | 11:47 |
| minute | correct | 11:48 |
| minute | 140.4mhz clock looks unusual | 11:49 |
| violet | yeah i have no idea what is standard | 11:49 |
| violet | i couldnt find any like, lists of standard pixel clocks | 11:49 |
| minute | 162mhz | 11:49 |
| minute | (on this panel) | 11:49 |
| violet | i can bump it back to the original panel mode to see if that does anyth | 11:50 |
| minute | that would be great. also, in dw_mipi_dsi i guess it has to set the real mipi clock somewhere (that becomes the dsi refclk). it should be something like 486MHz | 11:51 |
| minute | 162*3 = 486 | 11:51 |
| minute | (on some systems, i think with samsung dsi in imx8mplus, the dsi clock is given in DDR terms, so it's 972 mhz) | 11:52 |
| minute | on page 18 here on the bottom there is a table of the refclks that sn65dsi86 likes: https://www.ti.com/lit/ds/symlink/sn65dsi86.pdf?ts=1704310581655 | 11:53 |
| minute | (Table 8-1) | 11:53 |
| minute | afaik the relationship of the mode's pixel clock to the dsi bitclock is (correct me if i'm mistaken): pixelclock * 24bit / 4lanes, which is a DDR rate, so divided by 2 it's the actual clock. which shortens to pixelclock * 3 | 11:56 |
| violet | hmm, yeah switching back to 162MHz panel display made the *ERROR* Link training failed error go away | 11:59 |
| violet | still no pixels on the display but thats certainly something | 12:00 |
| minute | violet: oh nice. can you hack the colorbars test into the sn65dsi86 driver? | 12:01 |
| violet | whats that? | 12:01 |
| minute | approximately before this line, add another register write regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, VSTREAM_ENABLE, | 12:02 |
| minute | sorry, wonky copypaste on phone | 12:02 |
| minute | write 0x10 to register 0x3c | 12:04 |
| minute | then the sn65dsi86 will generate a test picture | 12:04 |
| minute | instead of using the incoming dsi pixels | 12:04 |
| violet | ooo ok, so before the vstream enable | 12:04 |
| minute | yep | 12:04 |
| minute | that way you can see if the timing is ok | 12:04 |
| violet | colors!!!!! | 12:08 |
| violet | it works :D | 12:08 |
| violet | no flickers or anything | 12:08 |
| minute | ok nice | 12:09 |
| minute | so the timing is good | 12:09 |
| minute | then you only need to fix the pixel pipeline ;D | 12:09 |
| violet | how bad could it be! hahaha | 12:09 |
| minute | for example, for a311d i had to force dsi burst mode | 12:09 |
| violet | yeah i noticed that one. i put in the patch for that in case it ends up being relevant for me here | 12:10 |
| violet | but i think really i need to just start printing a bunch of of the dsi phy state and see if anything looks weird | 12:10 |
| violet | i have that "failed to wait phy lock state" message but basically nothing else to go on right now | 12:11 |
| violet | but the clock is working which means its not completely broken so thats very good | 12:12 |
| minute | violet: yes, printing a lot of stuff seems like the right way, i also always do that | 12:13 |
| + mjw (~mjw@gnu.wildebeest.org) | 12:14 | |
| minute | violet: one more thing, i see in your DTS that for SD card you assume "to us, it is always 1.8v". that is not the case with rcm4. there is another level shifter on the rcm4 that does 3.3v->1.8v | 12:15 |
| minute | this is a bit convoluted but it's because the original imx8mq module expected 1.8v and all other modules don't/need another round of shifting | 12:16 |
| violet | oh! good to know lol | 12:17 |
| minute | but yeah, cool to see you making progress there. it's also interesting because i will have to integrate the rk3588 soon and it has similar IP | 12:17 |
| violet | if it gets 1.8v will it be a problem? im not sure how levelshifting works in the down direction that way | 12:17 |
| minute | violet: don't worry about the SD levelshifting at all, just pretend you're directly connected to the SD card | 12:18 |
| violet | k! | 12:18 |
| minute | violet: (if you are... because there are 2 sets of SD card pins on the CM4 and only one is wired up by default) | 12:18 |
| violet | yeah i am booting from the SD card right now | 12:19 |
| minute | oh nice | 12:20 |
| minute | then that works | 12:20 |
| minute | :D | 12:20 |
| violet | i actually had to disable the eMMC because it was breaking boot. i dont really know why yet. it might be because its labeled as non-removable in the soquartz dtsi, but mine is removed | 12:20 |
| - eibachd (QUIT: Ping timeout: 256 seconds) (~eibachd@p200300dcf7231c00eca0985b93716e8e.dip0.t-ipconnect.de) | 12:20 | |
| minute | sounds plausible | 12:20 |
| violet | it was working with the eMMC enabled but none attached on 6.1. so i dunno. ill turn it back on and try to debug that once i get display working | 12:20 |
| violet | the only other weird thing right now is that my nvme optane drive doesnt enumerate. and the main reason thats weird is because the optane drive works fine on a different carrier board (pine64's cm4 blade carrier). and, separately to that, the atheros wifi enumerated before i took it out and replaced it with the optane drive | 12:22 |
| violet | so something's up with that but i havent tried to figure out what yet, if other nvme drives work fine, etc. | 12:22 |
| + eibachd (~eibachd@p200300dcf7231c00bb7ae130635bacf6.dip0.t-ipconnect.de) | 12:23 | |
| minute | violet: could be related to reset | 12:27 |
| minute | violet: i.e. https://community.mnt.re/t/nvme-not-working-with-rcm4-fix-for-m-2-adapters/1674 | 12:27 |
| minute | we put this solder blob on there but it means that the reset is probably not done (it just pulls the reset line up) | 12:28 |
| violet | ok it looks like this SoC cant do PWM on the other pin you mentioned either | 12:30 |
| violet | doesnt seem to have any other fun functions that i could trick into being a PWM either | 12:34 |
| violet | well i guess thats not entirely true. it can be a clock for a PDM output, so if enough of that is wired up i might be able to convince that to give me a 50%-brightness setting. and it can also be a UART tx pin, so maybe i could write write out something that plausibly would act like PWM with some degree of brightness control | 12:37 |
| minute | violet: cool | 12:58 |
| - romi (QUIT: Read error: Connection reset by peer) (bd30729973@user/romi) | 13:01 | |
| - cmahns (QUIT: Write error: Connection reset by peer) (8fe824803c@2604:bf00:561:2000::10cd) | 13:01 | |
| - Zaba (QUIT: Read error: Connection reset by peer) (80b9b4b35e@2604:bf00:561:2000::116) | 13:01 | |
| - tretinha (QUIT: Write error: Connection reset by peer) (3a571d9f43@2604:bf00:561:2000::1151) | 13:01 | |
| - henesy (QUIT: Write error: Connection reset by peer) (d7619ffbc2@2604:bf00:561:2000::143) | 13:01 | |
| - theesm (QUIT: Write error: Connection reset by peer) (2cbdf4b38a@2604:bf00:561:2000::11c8) | 13:01 | |
| - noam (QUIT: Write error: Connection reset by peer) (81879d1ffa@2604:bf00:561:2000::dfc) | 13:01 | |
| + tretinha (3a571d9f43@2604:bf00:561:2000::1151) | 13:01 | |
| + noam (81879d1ffa@2604:bf00:561:2000::dfc) | 13:01 | |
| + romi (bd30729973@user/romi) | 13:01 | |
| + henesy (d7619ffbc2@2604:bf00:561:2000::143) | 13:01 | |
| + theesm (2cbdf4b38a@2604:bf00:561:2000::11c8) | 13:01 | |
| violet | something else i could maybe explore (just speculating for fun now) is rk3566 has a riscv core inside of it that people have figured out how to program and wrote some kernel drivers to make that possible. i cant find anything outright saying it but from the example code im reading it seems like it can read/write basically anything in the first 32-bits of address space. which maybe also applies to all | 13:01 |
| violet | the MMIO registers | 13:01 |
| + cmahns (8fe824803c@2604:bf00:561:2000::10cd) | 13:01 | |
| + Zaba (80b9b4b35e@2604:bf00:561:2000::116) | 13:01 | |
| violet | and it can take interrupts from a hardware pwm. so if this is actually how it works i could maybe upload a program to this core, set up something to feed it with interrupts, and have it just toggle the GPIO pin state | 13:02 |
| violet | incredibly cursed imo but now i really want to try this | 13:03 |
| violet | i will simply not accidentally stomp all over kernel memory in the process :D | 13:04 |
| minute | haha that sounds pretty good | 13:05 |
| - S0rin (QUIT: Ping timeout: 252 seconds) (~S0rin@user/s0rin) | 13:42 | |
| + S0rin (~S0rin@user/s0rin) | 13:45 | |
| - f_[xmpp] (QUIT: Ping timeout: 256 seconds) (fffdb90022@fases/developer/funderscore) | 13:47 | |
| - Twodisbetter (QUIT: Ping timeout: 246 seconds) (2cc0e4ea1c@irc.cheogram.com) | 13:48 | |
| + Twodisbetter (2cc0e4ea1c@irc.cheogram.com) | 13:57 | |
| + tiskaan (~tiskaan@84.70.121.60) | 14:43 | |
| josch | minute: reform-system-image pipelines pass again after the dkms maintainer uploaded a fixed version yesterday night -- at your convenience, please have a look at https://source.mnt.re/reform/reform-system-image/-/merge_requests/88 and see if you like these changes. Nothing should change the images that are built. This MR just adds more flexibility to the build process. | 14:46 |
| minute | josch: looks good to me! | 14:50 |
| minute | josch: shall i merge or you wanted to do that? | 14:52 |
| josch | minute: doesn't really matter who presses the button, no? :D I clicked it now and made sure that the "delete source branch" check box was checked. Thanks! :) | 14:55 |
| minute | josch: cool! | 15:05 |
| josch | another topic is, that you can now customize both the reform-debian-packages as well as the reform-system-images pipeline via the web interface like this: https://source.mnt.re/reform/reform-debian-packages/-/pipelines/new | 15:06 |
| josch | the problem is, that depending how the cron job publishing the repo is set up, it will wrongly pull CI results from pipelines that were run with these variables set to non-default values | 15:07 |
| josch | to prevent this, i'd like to add some shell checks in the jobs which make the jobs fail if these variables are set to non-defaults for the "main" branch | 15:07 |
| josch | I don't know the exact command that the cron job uses -- do you have it handy? | 15:08 |
| josch | then i could confirm whether poisoning the official repo is indeed possible or not | 15:08 |
| josch | and if yes, implement the checks | 15:08 |
| minute | checking now | 15:17 |
| josch | awesome, thank you! :) | 15:18 |
| minute | ZIP=latest.zip | 15:20 |
| minute | REPODIR=reform-debian-repo | 15:20 |
| minute | wget -O $ZIP "https://source.mnt.re/reform/reform-debian-packages/-/jobs/artifacts/main/download?job=reprepro" | 15:20 |
| minute | that's it basically (plus the unzipping) | 15:20 |
| minute | josch: should i change anything? | 15:21 |
| josch | i don't think you can change anything | 15:22 |
| josch | i researched this topic a few days ago | 15:22 |
| minute | ok | 15:22 |
| josch | and it seems these URLs retrieve the latest pipeline results for the given branch | 15:22 |
| josch | irrespective of whether the pipeline was manually triggered with variables changed or not | 15:22 |
| josch | i'll add these safety checks tonight then | 15:23 |
| minute | i see. maybe one could include a text file in the artifacts and check that | 15:23 |
| josch | thank you for confirming! | 15:23 |
| minute | safety checks are also good | 15:23 |
| minute | (i.e. i could unpack and check, then move) | 15:23 |
| josch | yes, i also thought of adding a file | 15:23 |
| josch | if you are fine with adding code that checks this file on the side of the cron-job i'll do that as well | 15:23 |
| minute | sure | 15:23 |
| josch | okay! :) | 15:24 |
| + julianwgs (~julian@p200300e9d74175004cda32bbd1e5272a.dip0.t-ipconnect.de) | 15:30 | |
| julianwgs | Regarding https://source.mnt.re/reform/reform/-/issues/16 I would propose that someone familiar with the design updates just one schematic and board layout for now. This is significantly less effort than all of them and I can start working and it should be quite easy to onboard more designs in the future. I would like to start with the motherboard, as it is complicated enough to be a representative example. | 15:35 |
| minute | julianwgs: ok! | 15:44 |
| julianwgs | Can you update the motherboard to the newest KiCAD version? | 15:47 |
| minute | julianwgs: pushed | 15:47 |
| minute | julianwgs: reform2-motherboard25-pcb is now kicad 7.0.9 | 15:48 |
| minute | i just did that on my reform... :D | 15:48 |
| julianwgs | Great! Thank you! | 15:50 |
| jfred | minute: on an a311d reform? | 15:59 |
| jfred | somewhat different but I need to try out freecad on my a311d reform. I tried opening some of the reform CAD files while I had the imx8mq module installed and that was *slow* haha | 16:01 |
| jfred | (it's been a while since I've been to my local hackerspace but we apparently have a CNC machine at the space now... I've really gotta start learning CAD now) | 16:02 |
| + yankcrime (~nick@gw.tetromino.io) | 16:13 | |
| josch | jfred: i only ever opened reform-related 3d files in freecad on my a311d reform and cannot remember any non-smoothness :) | 16:18 |
| jfred | :D | 16:20 |
| AbortRetryFail | jfred: is it still slow if you set MESA_GL_VERSION_OVERRIDE=3.0 ? >:] | 16:20 |
| jfred | I don't have the imx8mq module installed in a reform these days so can't check 😅 | 16:21 |
| AbortRetryFail | I guess I can try it myself. | 16:21 |
| jfred | I'd like to reuse that module in a desktop-style machine at some point though | 16:22 |
| AbortRetryFail | I've found some apps run just fine with that set because etnaviv has a bunch of teh extensions for gl 3.0 but not all of them so it doesn't try. | 16:22 |
| AbortRetryFail | heh, it crashes. oh well | 16:26 |
| AbortRetryFail | Crashes even if I dont use the version override. weird. | 16:27 |
| josch | hrm... could somebody run "free --kibi" on imx8mq an paste the "Mem:" line? Thanks! | 16:35 |
| - julianwgs (PART: !!unknown attribute: msg!!) (~julian@p200300e9d74175004cda32bbd1e5272a.dip0.t-ipconnect.de) | 16:37 | |
| AbortRetryFail | yeah, just a sec | 16:37 |
| AbortRetryFail | Mem: 4024496 728948 2185732 47816 1324176 3295548 | 16:38 |
| josch | huh... why is memory of a311d 209 MB less? | 16:57 |
| AbortRetryFail | more reserved for the GPU? | 17:00 |
| AbortRetryFail | its a pity nvtop doesn't work on these mobile GPUs | 17:01 |
| - S0rin (QUIT: Ping timeout: 245 seconds) (~S0rin@user/s0rin) | 17:12 | |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-159-4.tukw.qwest.net) | 17:27 | |
| + colinsane (~colinunin@97-113-159-4.tukw.qwest.net) | 17:30 | |
| - eibachd (QUIT: Ping timeout: 260 seconds) (~eibachd@p200300dcf7231c00bb7ae130635bacf6.dip0.t-ipconnect.de) | 17:34 | |
| + eibachd (~eibachd@p200300dcf7231c00ace7e5313aacb2aa.dip0.t-ipconnect.de) | 17:35 | |
| + S0rin (~S0rin@user/s0rin) | 17:52 | |
| - eibachd (QUIT: Ping timeout: 246 seconds) (~eibachd@p200300dcf7231c00ace7e5313aacb2aa.dip0.t-ipconnect.de) | 17:59 | |
| + eibachd (~eibachd@p200300dcf7231c001d7dfdb17cf7ffb5.dip0.t-ipconnect.de) | 17:59 | |
| minute | josch: address space shenanigans i assume | 18:43 |
| - erle (QUIT: Quit: Just say no, then Putin can not legally invade your nation without your consent.) (~erle@2a02:3102:4286:16:551e:a464:7889:a99b) | 19:05 | |
| - skipwich (QUIT: Remote host closed the connection) (~skipwich@user/skipwich) | 19:45 | |
| + skipwich (~skipwich@user/skipwich) | 19:46 | |
| + chomwitt (~chomwitt@2a02:587:7a0f:8900:1ac0:4dff:fedb:a3f1) | 19:52 | |
| minute | ooc i benchmarked our NAS cpu here to compare it to a311d... and it's slower | 19:56 |
| minute | > Tot: 163 2807 4586 | 19:56 |
| minute | (7z b) | 19:56 |
| minute | vs a311d: > Tot: 531 1715 8981 | 19:56 |
| minute | ah, it's faster for compression though, slower for decompression | 19:56 |
| minute | (it's AMD A6-7400K) | 19:57 |
| Twodisbetter | still impressive. It is amazing how far ARM has come in the last 5 years. | 20:01 |
| + klardotsh (~klardotsh@c-67-170-115-80.hsd1.wa.comcast.net) | 20:04 | |
| - tiskaan (QUIT: Ping timeout: 268 seconds) (~tiskaan@84.70.121.60) | 20:08 | |
| - eibachd (QUIT: Ping timeout: 276 seconds) (~eibachd@p200300dcf7231c001d7dfdb17cf7ffb5.dip0.t-ipconnect.de) | 20:09 | |
| + eibachd (~eibachd@p200300dcf7231c00d42bef322e8e5014.dip0.t-ipconnect.de) | 20:09 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 20:17 | |
| josch | Twodisbetter: for Debian (we use these to run autopkgtest lxc containers) we got systems with 128-core Ampere CPUs and 768 GB of ram donated -- and that was three years ago. I do not see an x86 cpu with that number of cores even today. | 20:48 |
| josch | i remember this because i had a script that runs "xz --threads=0 ..." which would use as many threads as there are processor cores available. And that would always fail on arm64. Reason was that with 128 threads, 768 GB of ram are not enough. :D | 20:51 |
| josch | since then i never write my scripts with $(nproc) or similar anymore -- that would just fail for systems with ridiculous numbers of cores like certain arm boards | 20:52 |
| josch | minute: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/22 this now creates a new artifact called variables.sh which is a shell script that your shell script can just source. It will set some variables that your script can then check to make sure everything is as expected. | 20:53 |
| + tiskaan (~tiskaan@84.70.121.60) | 20:53 | |
| minute | muaha https://youtube.com/shorts/KOgYCeMMpuc?si=GXhQYX8rxIPGTxpU | 21:01 |
| - tiskaan (QUIT: Ping timeout: 245 seconds) (~tiskaan@84.70.121.60) | 21:10 | |
| Twodisbetter | josch: yeah, seriously impressive! | 21:21 |
| - eibachd (QUIT: Ping timeout: 260 seconds) (~eibachd@p200300dcf7231c00d42bef322e8e5014.dip0.t-ipconnect.de) | 21:25 | |
| minute | josch: great! | 21:28 |
| + eibachd (~eibachd@p200300dcf7231c00abb3c38ae078b726.dip0.t-ipconnect.de) | 21:29 | |
| - S0rin (QUIT: Ping timeout: 252 seconds) (~S0rin@user/s0rin) | 21:37 | |
| + S0rin (~S0rin@user/s0rin) | 21:41 | |
| - XYZ_ (QUIT: Read error: Connection reset by peer) (~XYZ@78-80-123-108.customers.tmcz.cz) | 21:59 | |
| jfred | yesssss jeff geerling video | 21:59 |
| sknebel | usual youtube rules apply, dont read (some of) the comments ... | 22:00 |
| + XYZ (~XYZ@78-80-123-108.customers.tmcz.cz) | 22:04 | |
| josch | awesome video, great stuff! :) | 22:10 |
| minute | it's a teaser, full vid will come next week | 22:27 |
| + tiskaan (~tiskaan@84.70.121.60) | 22:28 | |
| josch | right but with that teaser i have no worries for the big video :) | 22:28 |
| AbortRetryFail | lol that video loops way too well | 22:29 |
| - XYZ (QUIT: Read error: Connection timed out) (~XYZ@78-80-123-108.customers.tmcz.cz) | 22:46 | |
| + XYZ (~XYZ@78-80-123-108.customers.tmcz.cz) | 23:04 | |
| - tiskaan (QUIT: Ping timeout: 268 seconds) (~tiskaan@84.70.121.60) | 23:10 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 23:20 | |
| eibachd | Seems Jeff really likes it. Awesome. | 23:53 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!