On Saturday 16 March 2013, Greg Kroah-Hartman wrote:
On Fri, Mar 15, 2013 at 09:13:52PM +, Arnd Bergmann wrote:
On Friday 15 March 2013, Greg Kroah-Hartman wrote:
Unless something is changed, this patch won't get into 3.9-final.
Do you want Greg to move it to his usb-linus branch
On Monday 18 March 2013, Arnaud Patard wrote:
Arnd Bergmann a...@arndb.de writes:
Sure, it's your decision. I just don't want to be accused of abandoning the
issue that I caused. It's not strictly a regression because no configuration
that was working in 3.8 is broken in 3.9, and embedded
On Thursday 06 June 2013, Maxime Ripard wrote:
So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
inferior (because not generic enough) to the device tree, but they show
interest on going down the mainline road.
Right, and of course there is nothing special about that,
On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote:
What this patchset does is also make mach-mvebu part of the multi v5
kernel. So you just need one kernel for all ARM v5 machines which are
part of multi v5. The long term goal is that you need just two 32 ARM
kernels, multi v5 and
On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote:
On Thu, Feb 20, 2014 at 11:34:36AM +, Ian Campbell wrote:
Debian has a single v7 flavour, armmp which uses the multi platform
stuff. (actually there is a second armmp-lpae, but
On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote:
On Thursday 20 February 2014 12:51:04 Ian Campbell wrote:
* ixp4xx is too different from the others and I don't think it's
possible to turn it over to multiplatform.
* I see
On Friday 21 February 2014 01:47:31 Ben Hutchings wrote:
On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote:
On Thursday 20 February 2014 14:21:10 Ian Campbell wrote:
For all I know, the only interesting ixp4xx platforms are the consumer
products listed on http://www.nslu2-linux.org
On Friday 21 February 2014 02:00:27 Ben Hutchings wrote:
On Thu, 2014-02-20 at 14:24 +, Ian Campbell wrote:
On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote:
[...]
What i suspect we will end up doing it dropping the last patch for the
moment and ensuring ARCH_KIRKWOOD still
also
allowing us to see the important output.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index 724ba3b..462b98d 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -873,9 +873,9 @@ do_alignment(unsigned long addr
On Friday 17 June 2011, Nicolas Pitre wrote:
On Fri, 17 Jun 2011, Arnd Bergmann wrote:
On Friday 17 June 2011 14:10:11 Dave Martin wrote:
As part of the general effort to make open source on ARM better, I think
it would be great if we can disable the alignment fixups (or at least
On Tuesday 12 January 2016 18:02:23 Mark Brown wrote:
> On Tue, Jan 12, 2016 at 05:29:40PM +0100, Arnd Bergmann wrote:
> > On Tuesday 12 January 2016 02:19:04 Andrew Lunn wrote:
>
> > > When i played with this, i added a reschedule point at the end of the
> > >
On Tuesday 12 January 2016 22:00:58 Mark Brown wrote:
> On Tue, Jan 12, 2016 at 10:49:57PM +0100, Arnd Bergmann wrote:
>
> > I see in the Armada 370 datasheet that the controller actually supports an
> > interrupt driven mode, which should be much better in principle
On Tuesday 12 January 2016 02:19:04 Andrew Lunn wrote:
> > Oh, right. This sounds like everything is working fine with SPI - that
> > commit was supposed to improve throughput with single threaded workloads
> > by avoiding pointless context switches and it seems it is in fact doing
> > that.
On Mon, Feb 24, 2020 at 10:01 AM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > wrote:
> > which seems a bug in the test suite. The other two get a segfault
> > that I have not debugged, but I guess this is likely a problem in your
> > patches. Have you seen the
On Tue, Feb 4, 2020 at 4:03 PM Guillem Jover wrote:
>
> On Tue, 2020-02-04 at 13:14:10 +, Steve McIntyre wrote:
> > The glibc folks have taken an interesting approach.
> >
> > * 64-bit ABIs/architectures are already using 64-bit time_t
> >throughout. The design is sane and so we should
On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski
> > wrote:
> > > > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> > > > Are there any glibc issues that prevent it from working
> > > > correctly,
> > >
> > > I think that the glibc
On Thu, Feb 20, 2020 at 4:42 PM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 2:15 PM Lukasz Majewski wrote:
>
> I do see two approaches here:
>
> 1. In glibc:
>
> When -D_TIME_BITS=64 is set - redirections are enabled for syscall
> wrappers; for example __clock_settime64 is used instead
On Fri, Feb 7, 2020 at 10:21 PM Florian Weimer wrote:
>
> * Steve McIntyre:
>
> > The kernel is *basically* fixed now. Internally, data structures
> > should now be safe. There are a small number places where 32-bit time
> > is still a thing, but it's in hand. A number of syscalls, ioctls,
> >
On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer wrote:
>
> * Ben Hutchings:
>
> > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> >> * Ben Hutchings:
> >>
> >> > If I recall correctly, glibc *will* provide both entry points, so there
> >> > is no ABI break. But the size of time_t
On Tue, Feb 11, 2020 at 12:07 PM Marco d'Itri wrote:
>
> On Feb 11, Arnd Bergmann wrote:
>
> > I agree that changing the i386 port is probably a bad idea at the moment,
> > let's see how the armhf port turns out and fix all the bugs first, as this
> > is
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge
I tried packaging this into a .deb package for use with rebootstrap, but
ran into a couple of test failures from glibc itself, when testing the i386
version while running
On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski wrote:
> > On 2/14/20 2:39 PM, Alistair Francis wrote:
> > > On Tue, Feb 11, 2020 at 5:30 PM Joseph Myers
> > An the reason this all works on RISCV is that your kernel doesn't
> > define __ARCH_WANT_STAT64 -> lacks __NR_statat64 and instead uses
On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski wrote:
> > On Thu, Feb 20, 2020 at 12:11 AM Lukasz Majewski
> >
> > Would it be possible to take a snapshot of your glibc tree
>
> The description of the status of Y2038 supporting glibc on ARM 32 can
> be found here [1].
>
> The most recent
On Tue, Feb 11, 2020 at 9:10 PM Florian Weimer wrote:
> * Ansgar:
> > Arnd Bergmann writes:
> >> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer wrote:
> >>> There's going to be a _TIME_BITS selector, similar to
> >>> _FILE_OFFSET_BITS.
> >&g
As discussed before, I tried using the rebootstrap tool [1] to see what
problems come up once the entire distro gets rebuilt. Based on Lukasz'
recommendation, I tried the 'y2038_edge' branch with his experimental
glibc patches [2], using commit c2de7ee9461 dated 2020-02-17.
Here is a rough
[some mailing lists appear to have classified the earlier mail as spam,
it was quite long and contained a lot of links. See
https://lists.debian.org/debian-arm/2020/03/msg00032.html for the
start of the thread if you did not get that]
On Wed, Mar 11, 2020 at 3:37 PM Lukasz Majewski wrote:
> >
On Mon, Mar 16, 2020 at 3:47 PM Rich Felker wrote:
> libtirpc is the replacement. I wasn't aware if uses libc-provided rpc
> headers (presumably only if they exist, since folks are using it fine
> on musl) but even if so I think the types will automatically update
> when time_t changes. Of
On Fri, Mar 13, 2020 at 9:22 PM Rich Felker wrote:
>
> On Wed, 11 Mar 2020 13:52:00 +01000, Arnd Bergmann wrote:
> > As discussed before, I tried using the rebootstrap tool [1] to see what
> > problems come up once the entire distro gets rebuilt. Based on Lukasz'
> >
> On Thu, Mar 26, 2020 at 1:15 PM Gilles Risch wrote:
>
> Hello,
>
> During these days of isolation I reanimated my old TeraStation Live
> (HS-DHTGL/R5), equipped it with some new disks and installed the latest
> official firmware (2.14). This firmware is based on a quiet old Linux
> kernel:
>
On Tue, Mar 31, 2020 at 7:08 PM Pete Batard wrote:
>
> Hi Gene,
>
> On 2020.03.31 17:41, Gene Heskett wrote:
> >> The only thing that's missing, really, is for Debian folks to
> >> integrate the retrofitted Genet network driver, which we submitted 2
> >> months ago, in the vanilla aarch64
On Tue, Mar 31, 2020 at 10:04 PM Pete Batard wrote:
>
> Hi Arnd,
>
> On 2020.03.31 19:33, Arnd Bergmann wrote:
> > There is no need to use ACPI when using the UEFI boot path, that can
> > just as well work with a normal DT.
>
> But there's also no reason to declare
On Mon, Mar 16, 2020 at 11:12 PM Lukasz Majewski wrote:
> > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker wrote:
> > > > - Removing the time32 symbols from the glibc shared object did
> > > > not work as they are still used (a lot) internally, and by the
> > > > testsuite.
> > >
> > > That
On Mon, Mar 23, 2020 at 7:21 PM Steve McIntyre wrote:
> On Wed, Mar 11, 2020 at 01:52:00PM +0100, Arnd Bergmann wrote:
> >* Adding a time64 armhf as a separate (incompatible) target in glibc
> > that defines __TIMESIZE==64 and a 64-bit __time_t would avoid
> > most of the
On Tue, Sep 1, 2020 at 4:28 PM Matti Palmström wrote:
>
> Hello everyone.
>
> Just saw a good price on an ASUS Chromebook C202XA that runs on a Media Tek
> MT8173C. Does anyone know if it's possible to install Debian to a chromebook
> like that? I'm googling as I write this but I can't really
On Tue, Jun 2, 2020 at 10:21 AM Steve Harriss wrote:
>
> Morning
>
> Just tried to follow the steps on www.cyrius.com to install Debian on my
> TS-253A using QTS 4.4.2.1320.
>
> My bad as I actually thought I had a TS-221, which is supported, but
> that was a previous machine.
>
> Any idea where
On Thu, Nov 26, 2020 at 4:34 AM Paul Wise wrote:
>
> On Fri, Nov 20, 2020 at 1:36 PM Arnd Bergmann wrote:
>
> > The main question for what would happen with the armel port
> > I think is what kernel to ship. When the marvell kernel gets
> > retired, the onl
On Thu, Nov 26, 2020 at 10:23 AM Martin Michlmayr wrote:
>
> > Possibly the three partitions could be combined into one partition
> > for kernel+initramfs
>
> When you say one partition, I guess you suggest appending the
> initramfs to the kernel? Is there a script that combines them?
> I
On Thu, Nov 26, 2020 at 11:33 AM Martin Michlmayr wrote:
>
> * Luca Olivetti [2020-11-26 11:15]:
> > > QNAP support won't be in Debian 11 (and probably the whole armel port
> > > will be dropped). Support in the Debian kernel package was disabled
> > > in August 2019 due to size issues.
> >
> >
On Tue, Dec 8, 2020 at 9:40 PM peter green wrote:
> On 08/12/2020 16:40, Lennart Sorensen wrote:
> > On Tue, Dec 08, 2020 at 09:21:42AM +0100, basti wrote:
> >> Hello Adrian,
> >>
> >> How can I help to get bullseye on armel?
> >
> > My impression was that the biggest problem for armel and armhf
On Tue, Dec 8, 2020 at 10:09 PM Lennart Sorensen
wrote:
>
> On Tue, Dec 08, 2020 at 09:53:11PM +0100, Arnd Bergmann wrote:
> > I wonder if this is something we should address in the kernel, and make
> > the behavior in compat mode resemble native 32-bit kernels more closel
On Sun, Nov 29, 2020 at 5:47 PM Alexander Reichle-Schmehl
wrote:
> * Alexander Reichle-Schmehl [201129 14:38]:
> >> flash-kernel: installing version 5.9.0-0.bpo.2-marvell
> >> Not enough space for kernel in MTD 'Kernel' (need 2327672 but is
> >> actually 2097152).
> > COMPRESS=xz see:
> >
On Thu, Dec 24, 2020 at 3:38 PM Rainer Dorsch wrote:
>
> Hi,
>
> I tried to run the bullseye installer from
>
> http://ftp2.de.debian.org/debian/dists/bullseye/main/installer-armhf/current/
> images/netboot/SD-card-images/
>
> on a cubox-i using a serial console today.
>
> It seems the network
On Fri, Nov 20, 2020 at 6:36 AM Martin Michlmayr wrote:
>
> QNAP support won't be in Debian 11 (and probably the whole armel port
> will be dropped). Support in the Debian kernel package was disabled
> in August 2019 due to size issues.
>
> While I still get emails about Debian on QNAP, the
On Sun, Nov 15, 2020 at 12:36 PM Christian Kastner wrote:
>
> On 11/15/20 2:43 AM, Wookey wrote:
> > On 2020-11-15 01:03 +0100, Christian Kastner wrote:
> >
> >> I'd like to run my own arm64 buildd, but basically I only found SBCs so
> >> far, with the NVMe-capable ones having max 4GB RAM, and
On Thu, Nov 5, 2020 at 9:29 AM Timo Jyrinki wrote:
>
> ti 3. marrask. 2020 klo 22.44 Uwe Kleine-König (u...@kleine-koenig.org)
> kirjoitti:
> > For now it is not even certain that bullseye will include support for
> > armhf at all. See
>
> Just noting that I love how many times these discussions
On Mon, Jun 14, 2021 at 10:45 AM Marcin Juszkiewicz
wrote:
> W dniu 14.06.2021 o 03:22, Paul Wise pisze:
> > On Sun, Jun 13, 2021 at 9:45 AM Marcin Juszkiewicz wrote:
> >
> >> Let me bring the idea on this list that, maybe, it is time for vendors
> >> to start looking into moving away from using
On Thu, Jun 10, 2021 at 4:43 PM Uwe Kleine-König wrote:
>
> Is there anything on your mind that is missing above and that you'd like
> to be shared with ARM? Feel free to reply here or discuss in
> #debian-arm. (I'm ukleinek there.)
I'll be at the meeting as well, and one point I would want to
On Mon, Apr 26, 2021 at 9:43 AM Ryutaroh Matsumoto
wrote:
>
> For (ARM) SBCs with limited computational power, stripping out
> unused features from the kernel sometimes improves the performance,
> depending on usage.
>
> For my use case of packet filtering by RPi4B,
>
> CONFIG_PARAVIRT=n
>
On Fri, Apr 30, 2021 at 4:10 AM Ryutaroh Matsumoto
wrote:
>
> This is a followup for my previous post of impact on kernel performance
> by kernel comile options:
>
> Summary:
> * CONFIG_PARAVIRT=n has probably no positive impact on either
> linux-image-arm64 or linux-image-rt-arm64.
Ok
> *
On Sun, May 2, 2021 at 8:21 AM Ryutaroh Matsumoto
wrote:
>
> Sorry for a bit late response.
>
> > I would not expect any change in performance from omitting unused drivers.
> > If turning off the other platforms has a performance impact, this could
> > still
> > mean that there is a serious
On Mon, Mar 1, 2021 at 9:40 AM LinAdmin wrote:
>
> Bullseye 64 Bit does more or less work. There arise problems when you install
> a desktop with media players which deliver audio and should give output to
> the headphone plug and HDMI.
>
> I also had to find out that all 64 Bit versions of all
On Tue, Mar 2, 2021 at 7:57 PM LinAdmin wrote:
> On 02.03.21 02:08, Ryutaroh Matsumoto wrote:
> >> Bullseye 64 Bit does more or less work. There arise problems
> >> when you install a desktop with media players which deliver
> >> audio and should give output to the headphone plug and HDMI.
> >
On Tue, Mar 2, 2021 at 7:51 PM LinAdmin wrote:
> > There is really no good reason to run a 32-bit /kernel/ on the Pi 4,
> > especially the version
> > with 8GB RAM. While the bug should get fixed in principle to make the
> > default kernel
> > work and allow installing a 32-bit distro, the best
On Wed, Mar 3, 2021 at 9:44 AM LinAdmin wrote:
>
> The common believe that on the same hardware 64-bit must be better or equal
> to 32-bit is clearly wrong for the "crazy" BCM2711 chip used in Pi4.
> The detailed benchmarks for Raspian Buster are at 32 Bit Kernel 4.19 and 64
> Bit Kernel 5.4.
On Tue, Mar 2, 2021 at 10:43 PM Jeffrey Walton wrote:
>
> On Tue, Mar 2, 2021 at 3:48 PM Arnd Bergmann wrote:
> >
> > On Tue, Mar 2, 2021 at 7:51 PM LinAdmin wrote:
> >
> > > > There is really no good reason to run a 32-bit /kernel/ on the Pi 4,
> > &
On Fri, Feb 12, 2021 at 3:57 AM wrote:
>
> Long story short - Debian was tried. Wifi didn't work. Armbian Bullseye was
> tried. WiFi worked. All was good, more or less, aside from guilt from sin of
> using non-free hardware... But then, Distrowatch discussion of Raspberry PiOS
> rolling out
On Sat, Feb 20, 2021 at 11:10 AM Ian Campbell wrote:
>
> On Fri, 2021-02-19 at 18:42 -0800, Rick Thomas wrote:
> > If I can get the Pi4 working with either of the Debian alternatives,
> > I will probably buy a Pi zero W as the actual replacement for the
> > Sheeva, and keep the Pi4 for
On Mon, Feb 22, 2021 at 9:17 AM Alexandre GRIVEAUX
wrote:
>
> Replacing x_bootcmd_kernel=fatload usb 0 0x640 uImage by
> x_bootcmd_kernel=ext2load usb 0 0x640 uImage or x_bootcmd_kernel=ext4load
> usb 0 0x640 uImage
>
> But the only most result i was getting is:
>
>
> [
On Fri, Feb 19, 2021 at 3:48 PM Pete Batard wrote:
> On 2021.02.19 13:37, Diederik de Haas wrote:
>
> The established goal of SBBR, which is a bona fide ARM standard that was
> designed precisely to address this major pain point, is to stop this
> madness and let the platform developers (rather
On Thu, Aug 19, 2021 at 9:03 AM Luca Olivetti wrote:
>
> Hello,
>
> I upgraded a test machine (buffalo linkstation pro/Marvell Orion5x) from
> buster to bullseye, then I rebuilt the dspam[*] deb (since it's been
> dropped by debian since buster, I did the same there).
> The newly built binary
On Thu, Oct 7, 2021 at 10:28 PM Lennart Sorensen
wrote:
> On Wed, Oct 06, 2021 at 02:08:49PM -0400, Camm Maguire wrote:
>
> I also get the impression in my searching for stuff about this problem,
> that 3/4 of the things I find about wanting to do this are gcl related.
> I guess it may be the
On Mon, Oct 4, 2021 at 7:38 PM Camm Maguire wrote:
>
> Greetings! There seems to be a subarchitecture within the current 32bit
> Debian arm universes and buildds. armv8 processors will leave the C
> stack start at 0x even when personality ADDR_LIMIT_3GB is set,
> whereas on armv7 the
On Tue, Oct 5, 2021 at 7:37 PM Camm Maguire wrote:
>
> Greetings, and thank you so much for your very detailed, clear, and
> comprehensive reply!
>
> PER_LINUX_32GB and/or a userspace interface to set the address space
> layout would be nice, but my chief concern is that whatever the kernel
>
On Tue, Dec 21, 2021 at 2:38 AM Michael Biebl wrote:
>
> On 13.12.21 20:44, Arnd Bergmann wrote:
> > It sounds like there is a compile-time check in systemd that determines
> > which
> > of these to use based on the host architecture, rather than the
On Mon, Dec 13, 2021 at 8:05 PM Vagrant Cascadian
wrote:
>
> I finally did a reprotest build of systemd on armhf to try and figure
> out why it doesn't build reproducibly... but it built reproducibly...
>
> My test did not test building with a 64-bit kernel (it was using a
> 32-bit kernel in both
On Mon, Jan 10, 2022 at 3:49 PM Mathieu Malaterre wrote:
>
> Dear arm porters,
>
> Could someone please clarify if I can build a package using gcc flags such as:
>
> -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee
>
> Ref:
>
> *
>
t; - use types with correct endianness annotation (instructions are
> always little endian on v7/v8+)
Reviewed-by: Arnd Bergmann
On Thu, Jun 23, 2022 at 7:24 PM 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 is not something that is supported by the architecture,
> but was done anyway
On Fri, Jul 15, 2022 at 9:55 PM Lennart Sorensen
wrote:
> 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
On Fri, Jul 15, 2022 at 6:13 PM Wookey wrote:
> 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, th
On Wed, Jul 20, 2022 at 9:35 PM Thorsten Glaser wrote:
>
> Dixi quod…
>
> >did something change wrt. compiler defaults on armhf recently?
>
> armel also FTBFS with SIGILL in the testsuite.
>
> So something changed incompatibly between 2019-11-10 and now
> in the ARM toolchain. But what, and how
On Sat, Jul 16, 2022 at 5:05 AM gene heskett wrote:
> On 7/15/22 21:54, Paul Wise wrote:
> > On Fri, 2022-07-15 at 13:40 -0400, gene heskett wrote:
> >
> >> Because our latency-test results are better on armhf than on arm64,
> >> we use armhf for its performance.
> > Are these results for armhf
On Fri, Jul 15, 2022 at 12:42 PM Paul Wise wrote:
>
> 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 rep
On Fri, Jul 15, 2022 at 11:39 AM gene heskett 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
On Sat, Jul 16, 2022 at 2:41 PM gene heskett wrote:
> 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 preemp
On Wed, Aug 24, 2022 at 8:03 PM Thorsten Glaser wrote:
> Do you think it would be worth compiling a VERY tiny program from
> execute_before_dh-auto-build that just runs an swp instruction, and
> if that fails, issue a message pointing to your message? I’m doing
> something similar for mksh wrt.
On Mon, Aug 22, 2022 at 3:08 AM Thorsten Glaser wrote:
>
> outlook 1017537 some armel buildds are misconfigured and lack SWP emulation
> thanks
>
> Dixi quod…
>
> ># if __ARM_ARCH__ < 6
> > swp r0, r1, [r2]
> ># else
>
> And this, after some research, is it. This is needed for armel,
On Wed, Sep 28, 2022, at 9:07 AM, Dominique MARTINET wrote:
> Arnd Bergmann wrote on Wed, Sep 28, 2022 at 08:21:00AM +0200:
>
> Ugh, this is going to be a massive headache...
> Other distributions I've worked with (e.g. nixos) have a wrapper for gcc
> and clang that just en
On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote:
> On 2022-09-28 09:32 -0400, Jeffrey Walton wrote:
>> On Wed, Sep 28, 2022 at 3:24 AM Dominique MARTINET
>> wrote:
>> > ...
>> > Ugh, this is going to be a massive headache...
>> > Other distributions I've worked with (e.g. nixos) have a wrapper for
On Thu, Sep 29, 2022, at 2:05 AM, Wookey wrote:
> On 2022-09-28 11:09 +0900, Dominique MARTINET wrote:
>>
>> As far as I'm aware, there haven't been any new public discussion since
>> that 2020 thread
>
> I mentioned it in the 'arm status' talk at debconf this year.
>
> -- has there been any new
On Tue, Oct 18, 2022, at 12:48 PM, Helmut Grohne wrote:
> Hi,
>
> I was also wondering about this Y2038 thingy and did some experiments.
> I'm reporting what I found to document it, but don't see much actionable
> stuff here. Many thanks to Arnd Bergmann for his input.
Thanks a
On Tue, Oct 18, 2022, at 16:41, Thomas Schmitt wrote:
> Hi,
>
> Steve McIntyre wrote:
>> likely to still be in routine use beyond 2038
>
> Sidenote towards ISO 9660 image producers:
>
> Don't forget to check from time to time whether Linux removed the
> int bottleneck in fs/isofs/.
> See:
>
On Tue, Oct 25, 2022, at 11:15, Diederik de Haas wrote:
> On Tuesday, 25 October 2022 10:02:09 CEST Andrew M.A. Cater wrote:
>> Debian armel runs fine without recompilation at a slight penalty.
>
> It is exactly this 'slight penalty' that I want to verify.
>
> I have a Zero W running Debian's
On Tue, Oct 25, 2022, at 00:03, Punit Agrawal wrote:
> Diederik de Haas writes:
>
>> But it can be that I'm looking at this problem all wrong and/or have some
>> tunnel vision towards building a cross compiler.
>> That is an important reason for making this ML thread.
>
> IIUC, for the kernel,
On Thu, Oct 20, 2022, at 10:57, Arnd Bergmann wrote:
> On Tue, Oct 18, 2022, at 16:41, Thomas Schmitt wrote:
>>
>> Currently it's still "int iso_date()" in:
>> https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h line 109
>> https://github.co
On Thu, Oct 20, 2022, at 16:45, Thomas Schmitt wrote:
>> I think the hard part here is knowing who to send the patches to.
>> Unmaintained file systems are particularly tricky, in this case I
>> would have used
>>
>> To: Alexander Viro
>> To: Jan Kara
>&g
On Thu, Oct 20, 2022, at 12:06, Thomas Schmitt wrote:
> Arnd Bergmann wrote:
>
>
> https://lore.kernel.org/linux-scsi/20201120140633.1673-1-scdbac...@gmx.net/T/
> [PATCH] isofs: fix Oops with zisofs and large PAGE_SIZE
>
>
> https://lore.kernel.org/linux-scsi/2020
On Mon, Oct 10, 2022, at 2:02 PM, Jérémy Lal wrote:
> Hi,
>
> Some tests in nodejs test suite consistently fail on "hoiby" but not on
> "antheil":
> https://buildd.debian.org/status/logs.php?pkg=nodejs=armhf
>
> Is there a difference between the two servers that could explain the
> different
On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
> On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
>> On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
>>...
>> > I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
>> > use musl-1.2, not gl
On Thu, Sep 29, 2022, at 11:49 AM, Wookey wrote:
> On 2022-09-29 09:47 +0200, Arnd Bergmann wrote:
>> On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote:
>>
>> I think the problem with using dpkg-buildflags is that it breaks
>> any user building their own applicati
On Wed, Sep 28, 2022, at 4:09 AM, Dominique MARTINET wrote:
>
> Arnd did a superb recap in 2020, let me just link to it first in case anyone
> needs a reminder:
> https://lists.debian.org/debian-arm/2020/02/msg00024.html
(It was Steve who did the recap of the work that I had done)
> tl;dr: glibc
On Tue, Aug 16, 2022 at 10:29 PM Ard Biesheuvel wrote:
>
> Thanks for chiming in.
>
> At this point, it is really up to the maintainers to decide whether
> the maintenance burden is worth it. The code itself seems pretty
> uncontroversial afaict.
>
> Might other distros be in a similar situation?
On Wed, Aug 17, 2022 at 7:28 PM Thorsten Glaser wrote:
>
> tags 1017538 + help
> forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
> thanks
>
> Hi Sebastian,
>
> instead of filing a bug with the information we already have…
>
> >arm/__longjmp.S: Assembler messages:
>
On Thu, Aug 18, 2022 at 12:13 AM Thorsten Glaser wrote:
>
> Arnd Bergmann dixit:
>
> >The way the FPU type gets selected in gcc changed with recent versions,
> >this was intentional and won't be reverted but it did break packages that
> >used the old method.
>
&g
On Wed, Aug 17, 2022 at 8:00 PM Thorsten Glaser wrote:
>
> Arnd Bergmann dixit:
>
> >-march=armv7-a+fp instead of -march=armv7-a to pick the right
>
> “instead of”
>
> We pass nothing there, and we need a solution (or two distinct
> ones) for armel and armhf.
I trie
On Wed, Feb 15, 2023, at 18:08, Wookey wrote:
> On 2023-02-04 21:42 -0800, Steve Langasek wrote:
>> On Thu, Oct 20, 2022 at 09:42:58PM -0700, Steve Langasek wrote:
>
>> Does doing an ABI transition of ~113 libraries seem tractable to folks?
>
> It certainly provides evidence for the idea that this
On Fri, Feb 10, 2023, at 19:23, Vagrant Cascadian wrote:
> On 2023-02-10, Mathieu Malaterre wrote:
>> On Thu, Feb 9, 2023 at 8:43 PM Andreas Tille wrote:
>> [...]
>>> according to the build logs[1] armhf fails to build (as only
>>> architecture) with
>> [...]
>>> LLVM ERROR: Symbol not found:
remembers) and
> report it upstream with the hope that someone will investigate but I'm
> not sure who that someone would be.
>
> (Maybe Arnd Bergmann but I suspect his plate is full already.)
>
> It's particularly annoying because this is a regression and the Linux
>
On Sun, Jan 7, 2024, at 23:07, Bastian Blank wrote:
> Hi
>
> With Linux 6.6 we dropped the Marvell specific kernel image, as it
> was not known to work on any of the available devices. We still have
> another armel kernel left, the one of the Raspberry Pi 0 and 1, which
> uses an ARMv6 CPU.
>
>
On Wed, Jan 17, 2024, at 23:54, Ben Hutchings wrote:
> On Wed, 2024-01-10 at 08:34 +0100, Arnd Bergmann wrote:
>>
>> Qemu versatilepb is probably the most accessible arm926
>> platform, though there are a couple of other armv5/v6 (ast2400,
>> ast2500, pxa27x, raspi1
1 - 100 of 101 matches
Mail list logo
