[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH v2] arm64: compat: Implement misalignment fixups formultiword loads



On Fri, Jul 15, 2022 at 11:39 AM gene heskett <gheskett@shentel.net> wrote:
> On 7/15/22 04:04, LinAdmin wrote:
> > Pi 4 has much more throughput in 32-bit modes but the so
> > called experts of Debian decided to abandon it :-(

Please stop the name calling, and the spreading of misinformation on this list.

> I built this kernel for an rpi4b quite a while ago, but none more recent
> have been as usable. uname -a:
>
> Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Feb 6
> 07:09:18 EST 2020 armv7l GNU/Linux
>
> latency-test shows about 12 u-secs as long as I stay away from firefox.
>
> That's good enough to run a cnc converted 80 yo 11x56 Sheldon lathe,
> making it do dance steps that were not in its vocabulary 80 years ago.
>
> Yet that raspios buster install is the full blown graphical install I
> also use
> as a development platform, with big SSD's plugged into its usb3 ports for
> workspace.
>
> Is it stable? Absolutely, no splats since the above date unless caused by
> me, uptimes are in the many months category as I try newer stuff now
> and then and find it wanting.
>
> The exception is right now, as libc6 was replaced and I rebooted it
> 2 days ago.
>
> It would be running bullseye but the last time I switched boot cards to try
> it, the python was too new to build LinuxCNC with but the built on buster
> version still worked and so did the above kernel.
>
> What I'd like to know, is why is armhf such a dirty word to debian?

Ard's kernel patch is for the armhf target, and to keep it working
on modern hardware that runs a 64-bit kernel, as there is a specific
compatibility problem (specifically applications that trigger
undefined behavior in C with misaligned pointers) without this patch.

If you see /other/ problems with the 64-bit kernel (using the
same user space, kernel source and kernel config as the 32-bit
kernel), please report those to the respective upstream kernel
maintainers so we can fix those as well.

        Arnd


Reply to: