Pi 4 has much more throughput in 32-bit modes but the so
called experts of Debian decided to abandon it :-(
On 14.07.22 03:52, Wookey wrote:I agree. So far, raspios is still available in armhf flavor, and for
On 2022-07-01 15:53 +0200, Ard Biesheuvel wrote:
The 32-bit ARM kernel implements fixups on behalf of user space when
using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit >>> aligned.
This feature is one of the remaining impediments to being able to switch >>> to 64-bit kernels on 64-bit capable hardware running 32-bit user space,
so let's implement it for the arm64 compat layer as well.
Cheers, Gene Heskett.
Note to cc'ees: if this is something you would like to see merged,Decent 32-bit arm hardware is thin on the ground these days. Debian
please indicate so. This stuff is unlikely to get in if there are no
users.
still has some but it's getting old and flaky. Being able to build
reliably on 64-bit hardware is important and useful. Unaligned
accesses are much less of a problem than they used to be, but they can
still happen, so having these fixups available is definitely a good
thing.
Debian runs its 32-bit buildds with alignment fixups turned on. It
looks like the boxes still hit about 1 per day.
We also do 32 bit builds on 64-bit kernels (in 32-bit userspaces) and
it mostly works. We do have packages that fail on 64-bit kernels and
have to be built on real 32-bit hardware, but I don't know how much of
that would be fixed by this patch. Some, presumably.
So yes, cheers for this. It is helpful in the real world (or at least
it should be).
Wookey
.
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 :-(
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?
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.
On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote:
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.
Gene's complaint is unrelated to this thread, but it is that Debian
refuses to support running the 32-bit ARMMP kernel on 64-bit hardware, specifically on the RaspberryPi 4b. There wasn't any justification from Debian given in the bug reports, but it sounds like only build config
options are needed to be enabled, but Debian refuses to do that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12 https://bugs.debian.org/981586
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 :-(
On 14.07.22 03:52, Wookey wrote:I agree. So far, raspios is still available in armhf flavor, and for
On 2022-07-01 15:53 +0200, Ard Biesheuvel wrote:
The 32-bit ARM kernel implements fixups on behalf of user space when using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit
aligned.
This feature is one of the remaining impediments to being able to switch
to 64-bit kernels on 64-bit capable hardware running 32-bit user space, so let's implement it for the arm64 compat layer as well.
running
heavy machinery with just a few microseconds to respond to an IRQ,
armhf builds are a given. LinuxCNC is such an application.
On Fri, Jul 15, 2022 at 05:39:34AM -0400, gene heskett wrote:
On 7/15/22 04:04, LinAdmin wrote:
Pi 4 has much more throughput in 32-bit modes but the soI agree. So far, raspios is still available in armhf flavor, and for
called experts of Debian decided to abandon it :-(
On 14.07.22 03:52, Wookey wrote:
On 2022-07-01 15:53 +0200, Ard Biesheuvel wrote:
The 32-bit ARM kernel implements fixups on behalf of user space
when
using LDM/STM or LDRD/STRD instructions on addresses that are not
32-bit
aligned.
This feature is one of the remaining impediments to being able to
switch
to 64-bit kernels on 64-bit capable hardware running 32-bit user
space,
so let's implement it for the arm64 compat layer as well.
running
heavy machinery with just a few microseconds to respond to an IRQ,
armhf builds are a given. LinuxCNC is such an application.
LinAdmin,
Just a thought: you might want to check which "so called experts" you are calling out here. Wookey has been an expert at ARM for the last 15 years or
more - he knows what he's talking about.
Debian has *not* abandoned armhf - Debian is one of the last Linux distributions actively supporting 32 bit for ARM or Intel architectures.
Gene,
Raspberry Pi OS is **not** Debian. Strictly, it's very much on its own as a forkof Raspbian from Peter Green.
For historical reasons, Raspbian and Raspberry Pi OS are the odd ones out with
their version of armhf - arm v6 plus hardware floating point originally, where everyone else had settled on arm v7 plus hardware floating point.
LinuxCNC is probably supported by neither Debian nor Raspberry Pi OS.
Finally, of course, it's useful for everyone to remember to be polite
and considerate - Code of Conduct applies here as everywhere else on
Debian's mailing lists.
With every good wish, as ever,
Andy Cater
On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote:
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.
Gene's complaint is unrelated to this thread, but it is that Debian
refuses to support running the 32-bit ARMMP kernel on 64-bit hardware, specifically on the RaspberryPi 4b. There wasn't any justification from Debian given in the bug reports, but it sounds like only build config
options are needed to be enabled, but Debian refuses to do that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12 https://bugs.debian.org/981586
On Fri, Jul 15, 2022 at 05:39:34AM -0400, gene heskett wrote:Ahh contraire, linuxcnc is at this moment and has been since the
On 7/15/22 04:04, LinAdmin wrote:LinAdmin,
Pi 4 has much more throughput in 32-bit modes but the soI agree. So far, raspios is still available in armhf flavor, and for
called experts of Debian decided to abandon it :-(
On 14.07.22 03:52, Wookey wrote:
On 2022-07-01 15:53 +0200, Ard Biesheuvel wrote:
The 32-bit ARM kernel implements fixups on behalf of user space when >>>>> using LDM/STM or LDRD/STRD instructions on addresses that are not 32-bit >>>>> aligned.
This feature is one of the remaining impediments to being able to switch >>>>> to 64-bit kernels on 64-bit capable hardware running 32-bit user space, >>>>> so let's implement it for the arm64 compat layer as well.
running
heavy machinery with just a few microseconds to respond to an IRQ,
armhf builds are a given. LinuxCNC is such an application.
Just a thought: you might want to check which "so called experts" you are calling out here. Wookey has been an expert at ARM for the last 15 years or more - he knows what he's talking about.
Debian has *not* abandoned armhf - Debian is one of the last Linux distributions actively supporting 32 bit for ARM or Intel architectures.
Gene,
Raspberry Pi OS is **not** Debian. Strictly, it's very much on its own as a forkof Raspbian from Peter Green.
For historical reasons, Raspbian and Raspberry Pi OS are the odd ones out with
their version of armhf - arm v6 plus hardware floating point originally, where everyone else had settled on arm v7 plus hardware floating point.
LinuxCNC is probably supported by neither Debian nor Raspberry Pi OS.
Finally, of course, it's useful for everyone to remember to be polite
and considerate - Code of Conduct applies here as everywhere else on
Debian's mailing lists.
With every good wish, as ever,
Andy Cater
.
On 2022-07-15 18:42 +0800, Paul Wise wrote:It, LinuxCNC, does indeed run on an armhf kernel built right on the pi
On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote:Ah thanks Paul. I was wondering why we were being accused of 'Debian abandonning armhf' when it was news to me, and I'm just writing the
If you see /other/ problems with the 64-bit kernel (using theGene's complaint is unrelated to this thread, but it is that Debian
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.
refuses to support running the 32-bit ARMMP kernel on 64-bit hardware,
specifically on the RaspberryPi 4b. There wasn't any justification from
Debian given in the bug reports, but it sounds like only build config
options are needed to be enabled, but Debian refuses to do that:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12
https://bugs.debian.org/981586
'ARM ports status' talk for Debconf next week.
Clearly one normally does not run foreign-arch kernels on hardware so
we don't have to support it, and Ben is right to say 'this is not a
bug'.
On the other hand, if the armhf kernel does work on RPi4 with a few
config options, and there is an actual use case, then the question is
what is the downside of enabling the config options?
Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on other 64-bit machines?No. It runs with the same armhf kernel on an rpi3b, but the 3b is
Do i386 kernels work on amd64 machines?Different architecture. No relevance here.
Sounds like something that might be worth discussion at debconf next week. I'll mention it in the talk.
Wookey
The question from Debian's POV is how many other people want to use non-native arm kernels (and for what?). How many platforms is it
relevant to? And if there is a downside, how many does that effect,
and how/how much.
On 7/15/22 12:16, Wookey wrote:
Clearly one normally does not run foreign-arch kernels on hardware so
we don't have to support it, and Ben is right to say 'this is not a
bug'.
On the other hand, if the armhf kernel does work on RPi4 with a fewIt, LinuxCNC, does indeed run on an armhf kernel built right on the pi
config options, and there is an actual use case, then the question is
what is the downside of enabling the config options?
and has been since Jessie on a rpi3b.
Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on other 64-bit machines?No. It runs with the same armhf kernel on an rpi3b, but the 3b is dragging its
tongue on the floor where the 4b has some leftover zip.
Because our latency-test results are better on armhf than on arm64, we use armhf for its performance.
Do i386 kernels work on amd64 machines?Different architecture. No relevance here.
On 2022-07-15 18:42 +0800, Paul Wise wrote:
On Fri, 2022-07-15 at 12:04 +0200, Arnd Bergmann wrote:On the other hand, if the armhf kernel does work on RPi4 with a few
config options, and there is an actual use case, then the question is
what is the downside of enabling the config options?
Does this only work for the RPi4, or does it enable/prevent 32-bit
kernels on other 64-bit machines?
Do i386 kernels work on amd64 machines?
Sounds like something that might be worth discussion at debconf next week. I'll mention it in the talk.
Ah thanks Paul. I was wondering why we were being accused of 'Debian abandonning armhf' when it was news to me, and I'm just writing the
'ARM ports status' talk for Debconf next week.
Clearly one normally does not run foreign-arch kernels on hardware so
we don't have to support it, and Ben is right to say 'this is not a
bug'.
On the other hand, if the armhf kernel does work on RPi4 with a few
config options, and there is an actual use case, then the question is
what is the downside of enabling the config options?
Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on other 64-bit machines?
Do i386 kernels work on amd64 machines?
Sounds like something that might be worth discussion at debconf next week. I'll mention it in the talk.
It is generally possible to run 32-bit kernels on 64-bit hardware on x86, some armv8 and mips, but there are a lot of downsides. On powerpc,
sparc, riscv, and newer armv8/v9, one has to run a 64-bit kernel.
Traditionally you'd only have a 64-bit kernel but 32-bit user space, at
least on powerpc, pa-risc and sparc.
I think x86 and arm are the odd ones out here, because Debian has
never shipped a 64-bit kernel packaged as a 32-bit .deb file here,
though at the moment mipsel is the only one that ships with
64-bit kernel by default.
On Fri, Jul 15, 2022 at 05:13:33PM +0100, Wookey wrote:
Ah thanks Paul. I was wondering why we were being accused of 'Debian abandonning armhf' when it was news to me, and I'm just writing the
'ARM ports status' talk for Debconf next week.
Clearly one normally does not run foreign-arch kernels on hardware so
we don't have to support it, and Ben is right to say 'this is not a
bug'.
On the other hand, if the armhf kernel does work on RPi4 with a few
config options, and there is an actual use case, then the question is
what is the downside of enabling the config options?
Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on other 64-bit machines?
Certainly people have been running 32 bit kernels on the Pi 3 and 4 and
it works fine. Some high end aarch64 CPUs don't support 32 bit mode,
but that is certainly not the case for the Pi's CPU.
Do i386 kernels work on amd64 machines?
Yes, but... They certainly don't work with more than 3.5GB or so of ram unless you use the pae version of the kernel then you can have some more. There have been issues in some cases with systems that had too much ram
where rather than just ignoring it the kernel would fail to boot.
Of course it was very common a 15 or 20 years ago to run debian i386 with
an amd64 kernel and was fully supported by debian including the installer which as far as I remember even recommended that kernel if supported by
the host. Quite a bit of user space code still had issues with 64 bit,
but you got to run a kernel that could take full advantage of your ram
and other cpu features, while running 32 bit user space (since the amd64 kernel of course can run i386 binaries just fine).
For example this was very much in Debian: http://snapshot.debian.org/archive/debian/20050312T000000Z/pool/main/k/kernel-image-2.6.9-amd64/kernel-image-2.6.9-9-amd64-generic_2.6.9-4_i386.deb
So an amd64 kernel in the i386 archive.
Sounds like something that might be worth discussion at debconf next week. I'll mention it in the talk.
Well it would essentially mean treating arm like i386 used to be treated.
It is certainly not a thing Debian hasn't supported before.
Because our latency-test results are better on armhf than on arm64,
we use armhf for its performance.
On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote:The whole install of raspios is armhf. So I guess its yes.
Because our latency-test results are better on armhf than on arm64,Are these results for armhf kernel with armhf userland?
we use armhf for its performance.
Are the results for arm64 kernel with armhf userland similar?I have not tried to build an aarch64 from the src I have.
How much worse are the results for arm64 kernel and userland?No, not exact, but its roughly 4x longer when I can get it to run,
The whole install of raspios is armhf. So I guess its yes.
I have not tried to build an aarch64 from the src I have.
It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since. It is now in testing so
those of you w/o 5 years of history to lose could try it for the price of a 64G u-sd card.
On 7/15/22 21:54, Paul Wise wrote:
On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote:
The whole install of raspios is armhf. So I guess its yes.Because our latency-test results are better on armhf than on arm64,Are these results for armhf kernel with armhf userland?
we use armhf for its performance.
Are the results for arm64 kernel with armhf userland similar?I have not tried to build an aarch64 from the src I have.
How much worse are the results for arm64 kernel and userland?No, not exact, but its roughly 4x longer when I can get it to run,
as it did check for a realtime preempt kernel and did a graceful
exit if not found. So its not been run on 64 bit Debian image since
stretch.
It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since.
It is now in testing so those of you w/o 5 years of history to lose
could try it for the price of a 64G u-sd card.
On Sat, Jul 16, 2022 at 5:05 AM gene heskett <gheskett@shentel.net> wrote:
On 7/15/22 21:54, Paul Wise wrote:There are unfortunately a number of variables here that make things
On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote:The whole install of raspios is armhf. So I guess its yes.
Because our latency-test results are better on armhf than on arm64,Are these results for armhf kernel with armhf userland?
we use armhf for its performance.
Are the results for arm64 kernel with armhf userland similar?I have not tried to build an aarch64 from the src I have.
How much worse are the results for arm64 kernel and userland?No, not exact, but its roughly 4x longer when I can get it to run,
as it did check for a realtime preempt kernel and did a graceful
exit if not found. So its not been run on 64 bit Debian image since
stretch.
really hard to compare, any of these can have an effect that dominates
your results:
- 4.19 is four years old, and both the mainline kernel and the
preempt-rt patches have changed a lot in the meantime. It's
possible that a current preempt-rt has regressed compared to
the version you are running. If so, we can work on fixing the
regression for future kernels, but there won't be much interest
in working on the old kernel
- Raspberry Pi OS (and Raspbian before that) has a number of
platform specific kernel patches that are neither in mainline
Linux nor in the Debian kernel packages. It is possible that they
have already identified and fixed a source of latency in their
kernels but not managed to upstream that fix for a number of
reasons.
- A lot of kernel configuration options can have a huge impactI wish you would admit that the raspios I am running IS armhf (kernel7l)
on latency, it's not just preempt-rt that can be turned on or off,
but any device driver that disables preemption for too long can
increase the maximum latency of the system.
- The raspbian user space should have very little effect on
latency but it's worth pointing out that you may see different
performance between armv6 (raspbian)
and armv7 (debianThe card its running on right now is over 2 years old, zero problems,
armhf), between vfpv3-d16 (raspbian and debian armhf) and
neon-d32 (fedora and others), and between a32 (raspbian),
t32 (debian armhf) and a64 (debian arm64), instruction sets
running the same code. In most applications the effect is very
small, and it's not always the same one that's fast either.
It, latency-test, has recently been worked on but I've not testedDo you have your latency-test output available for reference
it on a Debian image of either flavor since.
somewhere?
To establish a baseline, it would be good if someone could run
the same test using debian armhf userland on similar hardware
with this kernel:
https://packages.debian.org/bookworm/linux-image-rt-arm64
If that can reproduce the bad numbers you observed, the next
step would be to try a corresponding 32-bit kernel and see if
that is better, but that requires building a custom package.
There is a linux-image-rt-armmp package in bookworm, but to
get PCI and USB3 working on Raspberry Pi 4, one needs to
enable both the PCI driver and CONFIG_ARM_LPAE, possibly
more.
It is now in testing so those of you w/o 5 years of history to loseFor some reason, linuxcnc is still missing for armhf. I managed
could try it for the price of a 64G u-sd card.
to build the source package, which had a minor issue finding the libboost_python310 dependency, but it worked after I added
that. I don't have the right system to test on myself though.
[Side note: I hope you are not storing any important data on an
SD card. Even with "industrial grade" ones, I would recommend
doing regular backups to more permanent storage, and the
usual consumer cards are not designed to handle running a
general-purpose OS at all and will cause data corruption over
time]
Arnd
.
On Fri, 2022-07-15 at 23:05 -0400, gene heskett wrote:
The whole install of raspios is armhf. So I guess its yes.I seem to remember them switching to arm64 recently?
I think, since the 240G I'm using for workspace is over 50% full, that II have not tried to build an aarch64 from the src I have.
That's probably me but its also likely a week on down the log.I think it would be helpful if someone with an RPi4 could do this.
For those of you who are able to try this, sounds like you just install linuxcnc-uspace and then run latency-test. Also install/try latencytop, although Linux CONFIG_LATENCYTOP is not enabled in Debian probably.
It, latency-test, has recently been worked on but I've not tested
it on a Debian image of either flavor since. It is now in testing so
those of you w/o 5 years of history to lose could try it for the price of a 64G u-sd card.
$ apt-file search latency-test
linuxcnc-uspace: /usr/bin/latency-test
linuxcnc-uspace: /usr/share/doc/linuxcnc/examples/sample-configs/apps/latency/latency-test.demo
linuxcnc-uspace: /usr/share/man/man1/latency-test.1.gz
On 7/16/22 08:10, Arnd Bergmann wrote:
- 4.19 is four years old, and both the mainline kernel and the
preempt-rt patches have changed a lot in the meantime. It's
possible that a current preempt-rt has regressed compared to
the version you are running. If so, we can work on fixing the
regression for future kernels, but there won't be much interest
in working on the old kernel
- Raspberry Pi OS (and Raspbian before that) has a number of
platform specific kernel patches that are neither in mainline
Linux nor in the Debian kernel packages. It is possible that they
have already identified and fixed a source of latency in their
kernels but not managed to upstream that fix for a number of
reasons.
Their kernels are uniformly horrible with latency's ranging to above a millisecond.
Linuxcnc simply refuses to run on those kernels.
- The raspbian user space should have very little effect onI wish you would admit that the raspios I am running IS armhf (kernel7l)
latency but it's worth pointing out that you may see different
performance between armv6 (raspbian)
I've no clue where you got the impression it was v6. It is not.
I wish you would admit that the raspios I am running IS armhf (kernel7l)
I've no clue where you got the impression it was v6. It is not.
The card its running on right now is over 2 years old, zero problems,
and has had all updates, including a daily update of linuxcnc from the
the buildbot, or if the buildbot is down, my own scripts also building installable deb's. The secret is use a big enough card that it has enough room to do its maintenance. 64G card has around 15G's on it.
On Sat, Jul 16, 2022 at 2:41 PM gene heskett <gheskett@shentel.net> wrote:I got this as 4.19.y, and applied the realtime patch kit. I've not been
On 7/16/22 08:10, Arnd Bergmann wrote:I think this is simply because raspbian does not ship any preempt-rt
- 4.19 is four years old, and both the mainline kernel and theTheir kernels are uniformly horrible with latency's ranging to above a
preempt-rt patches have changed a lot in the meantime. It's
possible that a current preempt-rt has regressed compared to
the version you are running. If so, we can work on fixing the
regression for future kernels, but there won't be much interest
in working on the old kernel
- Raspberry Pi OS (and Raspbian before that) has a number of
platform specific kernel patches that are neither in mainline
Linux nor in the Debian kernel packages. It is possible that they
have already identified and fixed a source of latency in their
kernels but not managed to upstream that fix for a number of
reasons.
millisecond.
Linuxcnc simply refuses to run on those kernels.
kernel themselves, so clearly their kernel binaries won't be low-latency.
You did not say where you got the kernel that you are running
successfully, so as far as I could tell this might be a combination
of the raspbian patches and the preempt-rt patches.\
This paragraph was about the user space, not the kernel.- The raspbian user space should have very little effect onI wish you would admit that the raspios I am running IS armhf (kernel7l)
latency but it's worth pointing out that you may see different
performance between armv6 (raspbian)
I've no clue where you got the impression it was v6. It is not.
The entire reason for Raspbian's existence is that it runs on armv6
hardware like the Raspberry Pi 1, which Debian armhf does not
run on. Building for armv6 means they can run the same user space
on all hardware generations from v6 to v8, and they advertise this
on their website:
https://www.raspberrypi.com/software/operating-systems/
ship at least two separate 32-bit kernels, since an LPAE-enabled
kernel is needed to access PCI and high memory but is incompatible
with Armv6 hardware.
Arnd
.
On Sat, Jul 16, 2022 at 08:41:07AM -0400, gene heskett wrote:raspian/raspios is available in all 3 flavors.
I wish you would admit that the raspios I am running IS armhf (kernel7l)You said raspios which sure looks like raspian. Raspian/Raspberry Pi
I've no clue where you got the impression it was v6. It is not.
OS is armv6. If you are running Debian armhf, then it is armv7 but it
would be a lot less confusing to call it Debian and not raspios in
that case.
Doesn't matter what your kernel is. What is your userspace you are
actually running?
The card its running on right now is over 2 years old, zero problems,Backups once in a while of the card is still nice to have.
and has had all updates, including a daily update of linuxcnc from the
the buildbot, or if the buildbot is down, my own scripts also building
installable deb's. The secret is use a big enough card that it has enough
room to do its maintenance. 64G card has around 15G's on it.
raspian/raspios is available in all 3 flavors.
True, but when those two seagate 2T drives puked in quick succession, I lost all
my patched amanda sources. I'd only been running amanda since 1998.
I figured if bullseye ever stabilizes I might see about starting it up
again. But UM
sold it to zmanda so progress stopped, and then was sold to Betsol about 2 years back, and so far they've been all hat and no cattle. As far as I'm concerned its time to look for a new backup strategy that mimics how amanda worked. IOW I'm still building this box, almost from scratch. Its been very painful
so far with bullseye.
Am 16.07.2022 um 18:02 schrieb gene heskett <gheskett@shentel.net>:
I've not been
able to find another kernel src any newer that even admits to having a realtime preempt in its config, it is conspicuously absent in anything
newer, and I am subbed to linux-rt so I see all the new stuff being announced.
Raspbian(.org) was created by Peter Green (plugwash) (and Mike Thompson who's name is still attached to raspbian(.org)'s GPG key, but otherwise moved on) precisely because the RPi 1 did not meet the armhf/armv7 qualifications that Debian uses.
The Raspberry Pi Foundation (RPF) started with (Debian's) armel (armv5) architecture, but that was slow and didn't optimally use the HW that was available on the RPi 1.
So Plugwash (and Mike) started a recompilation of the Debian archive which makes better use of the HW available in the RPi 1. Confusingly, they labeled it armhf, while it was and is NOT the same as Debian's armhf.
To add to the confusion, RPF called their OS also Raspbian :-/
AFAIK it's still Plugwash that runs the buildd which compiles the packages for
Raspbian/RaspiOS, but those packages are now also mirrored on RPF servers/ archives. That is still ~armv6 (+hardfloat+sth IIRC).
The RPi 2 (and newer) can run Debian's armhf (armv7).
The RPi 3 and newer can also run arm64 and that is the same as Debian's.
I am *quite* sure RaspiOS is not available in normal/Debian's armhf, but only in their own armv6+ (but labeled armhf) and arm64.
You said raspios which sure looks like raspian. Raspian/Raspberry Pi
OS is armv6. If you are running Debian armhf, then it is armv7 but it would be a lot less confusing to call it Debian and not raspios in
that case.
raspian/raspios is available in all 3 flavors.
On Fri, Jul 15, 2022 at 11:39 AM gene heskett <gheskett@shentel.net> wrote:
On 7/15/22 04:04, LinAdmin wrote:Please stop the name calling, and the spreading of misinformation on this list.
Pi 4 has much more throughput in 32-bit modes but the so
called experts of Debian decided to abandon it :-(
...
Arnd
I won't care about Debian Arm anymore because Ubuntu jammy
2204 LTS 32 bit runs like a charm.
LinAdmin
On 15.07.22 12:04, Arnd Bergmann wrote:
On Fri, Jul 15, 2022 at 11:39 AM gene heskett <gheskett@shentel.net> wrote:
On 7/15/22 04:04, LinAdmin wrote:Please stop the name calling, and the spreading of misinformation on this list.
Pi 4 has much more throughput in 32-bit modes but the so
called experts of Debian decided to abandon it :-(
...
Arnd
LinAdmin,
your way how you interact on this Mailling list is highly inappropiate.
You've been called out due to name calling and instead of appoligizing you're doubling down in your response.
Such kind of messages will not be tolerated on Debian mailing lists, and you have been told that before.
To be frank, until you want to constructivly interact with the Debian community you are _NOT_ welcome.
Good night Andy
Is it possible you never have heard of the Streisand effect?
Regards
LinAdmin
On 18.08.22 18:58, Andrew M.A. Cater wrote:
On Thu, Aug 18, 2022 at 05:21:19PM +0200, LinAdmin wrote:
I do know that you do not like my comment that 32bit on Pi4Good afternoon, LinAdmin
is much more efficient than 64 Bit ...
Linadmin
It does appear to me that this comment is not directly relevant to this message and might not be helpful. Nobody mentioned this in this thread today apart from you
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:22:19 |
| Calls: | 10,388 |
| Calls today: | 3 |
| Files: | 14,061 |
| Messages: | 6,416,833 |
| Posted today: | 1 |