rvalle

I agree, yes. It is very nice and Agile. I can see the new kernel release .51 in beta apt repo. Will test it in the environment I saw the problems. R.

@Igor I am trying to understand the publishing method. How are patches turned into updates? I guess updates are pushed from armbian-firmware repo, or? But I cant see the relationship between the builder and the firmware repos.... You mentions updates go out right away. how does it work?

Nice! Sent from my 2201116SG using Tapatalk

Sorry, have never done this... Will check how you did. Sent from my 2201116SG using Tapatalk

@Igor this recent fix seems like it: https://lore.kernel.org/all/E1sbJvd-001rGD-E3@rmk-PC.armlinux.org.uk/#r apparently the driver was decoding the duplex mode incorrectly.

@Igor , thanks for your comment: I am getting some variation, but perhaps all of them are degraded anyway. While I wait for the upstream fix, is it possible to build armbian on the last working kernel version? How would that go?

Hi! I am looking into OdroidM1 network performance with kernel 6.6.47-current-rockchip64 ( 24.8.1 ) For some reason network performance is x10 faster (upstream) in bookworm and noble, when compared to jammy. Downstream performance is fine, delivering the same performance in jammy and the other distributions. Since all of them are using the same kernel, I assume that there must be some configuration that jammy is missing, or? Any idea about what could be going on?

Ok, I tested with armbian 24.8.1/6.6.47 and it seems to be normal now. R.

Hi @rpardini I am putthing an M1 in production for a MAAS server, the M.2 and ram make it ideal for LAB deployment. I found a problem Network downstream is very fast, but upstream below 100Kb/s. It should be getting 7.5Mb/s... as a RPI4, or the M1 with an USB ethernet adapter. My M1 is on 6.6.39, did you notice this before? I will try to test with the latest verion.... R.

I think the m1s is an outstanding target. Very affordable and powerful. I own one, and I am available to test. I would not know where to start in terms of adding a new target to Armbian, but I can help with testing.

thanks! that explains everything.

Yes, managed to build OdroidXU4 on the main tag but not on v23.11.2, I need to investigate why is this. I even deleted the local armbian build docker container, just in case.

@Igor it is a bit confusing. OdroidXU4 is now building on main. I guess a fix was posted. However, I am not sure if it is building on v23.11. Should a kernel update break the v23.11 tag? Perhaps it is an issue at my environment.

is there anyway to point the checkout to a particular revision?

I can see the checkout is here: ``` [🐳|🌱] git: Fetch from remote completed, rev-parsing... [ 'kernel:6.1' 'odroidxu4-6.1.y' 'FETCH_HEAD' ] [🐳|🌿] Using Kernel git revision [ 5737e0cc255c905e3c35a0186ee528ba7f056ae8 at 'Mon Jan 29 21:34:07 UTC 2024' ] ``` I can see there was an update yesterday at hardkernel repo, that is used here. I guess something broke.

Hi, I have been recently working on a couple of extensions: lvm and cloud-init I forked off "v23.11.2" tag when creating my branches, since they are extensions, and wont alter the framework much. Today I noticed that OdroidUX4 is not building, but it was building last week. A patch seems to be failing. I guess it is a kernel/driver patch. Then my question is: is it possible that, on the same tag (v23.11.2), builds break? I am starting to think that the tag is only for the build process/patch set, but excludes, for example a reference to kernel code. I suppose then the situation is that a kernel update has "broken" a patch, would that be the case? If so, is it possible to also checkout a particular working kernel for the sake of a stable dev environment? How do you normally do? R.