Package: src:binutils
The upstream binutils commit below reduced the section alignment of
armhf executables (including shared libraries) from 64k to 4k, on the
basis that the additional bloat is not justified, given that arm64 hosts
running 64k pagesize kernels with armhf user space are not used i
On Thu, 12 Dec 2024 at 21:02, Andres Salomon wrote:
>
...
> Chromium's generally not very good with non-4k page sizes; we're
> carrying an allocator patch that we had to add due to hitting asserts()
> for 64k pages. Sadly, both the bug report and screenshot are locked down
> (thanks google 🙄), so
Package: chromium
Version: 131.0.6778.108-1
Severity: important
X-Debbugs-Cc: a...@kernel.org
Dear Maintainer,
Chromium does not work at all on systems with 16k pages.
This commit appears to be the culprit
https://chromium-review.googlesource.com/c/v8/v8/+/5864909
Given that only 16k pagesize
cc Jason
On Mon, 20 Feb 2023 at 15:22, Michael Tokarev wrote:
>
> 20.02.2023 16:10, Ard Biesheuvel wrote:
> > Package: qemu-system-x86
> > Version: 1:7.2+dfsg-3
> > Severity: normal
> > X-Debbugs-Cc: a...@kernel.org
> >
> > Dear Maintainer,
>
://lore.kernel.org/all/20221228143831.396245-1-ja...@zx2c4.com/
Regards,
Ard.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: arm64 (aarch64)
Kernel: Linux 6.1.12+ (SMP w/128 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8
Package: grub-efi-arm64
Version: 2.06-5
Severity: wishlist
X-Debbugs-Cc: a...@kernel.org
Dear Maintainer,
Linux 6.1 and later implement a EFI bootable compressed format called zboot,
which does not carry the 'arm64 bare metal boot' magic number because it is
EFI-only and cannot be booted in bare
On Wed, 7 Dec 2022 at 17:02, Gerd Hoffmann wrote:
>
> On Wed, Dec 07, 2022 at 09:14:39AM -0500, James Bottomley wrote:
> > On Wed, 2022-12-07 at 15:09 +0100, Ard Biesheuvel wrote:
> > > So at some point, these drivers will be removed rather than kept
> > > alive b
On Wed, 7 Dec 2022 at 08:41, Gerd Hoffmann wrote:
>
> Hi,
>
> > A patch mentioned above set MPT_SCSI_ENABLE=FALSE, that removed
> > support for LSI 53C1030 and SAS1068.
> > These SCSI controllers were emulated by VMware, Parallels and I guess
> > VitualBox.
> > This is generic setup for VMware
Source: pcre2
Version: 10.36-2
Severity: important
X-Debbugs-Cc: a...@kernel.org
Dear Maintainer,
Currently, pcre2 is built in a mode where its JIT uses memory mappings
that are writable and executable at the same time, which is unsafe and
unnecessary.
Instead, it is possible to enable a differe
Package: x264
Severity: important
X-Debbugs-Cc: a...@kernel.org
Dear Maintainer,
When building x264 for the armhf architecture, the resulting package contains a
build of libx264.so that has a PT_GNU_STACK ELF program header that identifies
the shared object as requiring an executable stack. Thi
uming
> > > the only
> > > active use was x86, but was completely possible to use it on arm64 (it
> > > works fine for me
> > > on bullseye). Since EFI bootloaders have not yet implemented the new way,
> > > and still
> > > rely on this deprecated method on all architectures,
On Sat, 16 Jan 2021 at 18:27, Ard Biesheuvel wrote:
>
> On Sat, 16 Jan 2021 at 18:24, Diederik de Haas wrote:
> >
> > On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds
>
On Sat, 16 Jan 2021 at 18:24, Diederik de Haas wrote:
>
> On zaterdag 16 januari 2021 10:42:19 CET Ard Biesheuvel wrote:
> > Please enable CONFIG_CRYPTO_NHPOLY1305_NEON as a module for arm64 builds
>
> Is there a reason why it shouldn't be included in armhf builds? If not,
, using
the 'adiantum' template.
Kind regards,
Ard.
-- Package-specific info:
** Version:
Linux version 5.10.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP
Debian 5.10.4-1 (2020-12-31)
** Co
Hello Diederik,
On Fri, 11 Dec 2020 at 12:21, Diederik de Haas wrote:
>
> On Sun, 06 Dec 2020 09:34:36 +0100 Ard Biesheuvel wrote:
> > Currently, arm64 kernel packages are built with the following Kconfig
> > symbols
> unset:
> >
> > # CONF
Package: linux-image-arm64
Version: 5.9.6-1~bpo10+1
Severity: important
Dear Maintainer,
Currently, arm64 kernel packages are built with the following Kconfig symbols
unset:
# CONFIG_CRYPTO_SHA512_ARM64 is not set
# CONFIG_CRYPTO_SHA512_ARM64_CE is not set
# CONFIG_CRYPTO_SHA3_ARM64 is not set
g on a lot of features.
Anyway: I don't know how you build and test on non amd64 systems, do you
also use armhf, or do you use a cross compile environment?
Regards,
Ard van Breemen
dled.
By the way: the mgr dashboard modules is about 99% correct. The
disk space is obviously calculated incorrectly.
Regards,
Ard
--
.signature not found
I rebooted the 64 bit system.
And I think that last CVE fix might be the problem.
Anyway, I hope this reaches someone...
Regards,
Ard van Breemen
Package: python3-ceph-argparse
Version: 14.2.7-1~bpo10+1
Severity: important
Dear Maintainer,
Installing ceph nautilus on armhf works after fixing the timeout value in:
/usr/lib/python3/dist-packages/ceph_argparse.py line 1302.
It says:
timeout = 2 ** 32
which effectively means a timeout
versions of the SynQuacer
platform implement.
So please consider enabling CONFIG_TCG_TIS as a module for upcoming builds of
the arm64 buster kernel.
Thanks,
Ard.
-- Package-specific info:
** Version:
Linux version 4.19.0-6-arm64 (debian-ker...@lists.debian.org) (gcc version
8.3.0 (Debian 8.3.0-6
Package: clevis-dracut
Version: 11-2
Severity: important
Dear Maintainer,
clevis-dracut includes a script clevis-hook.sh that refers to the
clevis-luks-askpass
executable by its full path
/usr/lib/x86_64-linux-gnu/clevis-luks-askpass
which is obviously only valid on x86 machines. This makes th
Package: dracut
Version: 048+80-2
Severity: important
Dear Maintainer,
The following line needs to be added to
modules.d/90crypt/module-setup.sh
in order for arm64 specific crypto modules to be included in the initrd
(line 31)[[ $arch == aarch64 ]] && arch=arm64
Without this, the kernel m
The patch has been backported, and was released as part of v4.19.29
20 2e 64 61 74 61 00 00 00 00 1c 00 00 00 b0 00 00 |.data...|
Size and offset of .data section at 0x128 and 0x12c: 0x1c00 bytes @
0xb000, which brings the total file size to 0xcc00 just like in the
main header.
[0] http://people.linaro.org/~ard.biesheuvel/fwupdaa64.efi-f29
Package: fwupdate
Version: 12-4
Severity: important
Dear Maintainer,
Version 12-4 of fwupdate is broken for arm64. The included binary fwupaa64.efi
is corrupt, resulting in EFI_LOAD_ERROR to be returned by the firmware when
trying to invoke it.
The binary layout looks like this:
Detected 'AArch
Package: src:linux
Version: 4.19.16-1
Severity: normal
Dear Maintainer,
Please consider enabling the following Kconfig options for arm64 kernels
CONFIG_CRYPTO_SHA256_ARM64=m
CONFIG_CRYPTO_SHA512_ARM64=m
CONFIG_CRYPTO_SHA512_ARM64_CE=m
CONFIG_CRYPTO_SHA3_ARM64=m
CONFIG_CRYPTO_SM3_ARM64_CE=m
CONFI
Package: src:linux
Version: 4.19.16-1
Severity: normal
Dear Maintainer,
Please enable the following Kconfig options in the arm64 kernels:
CONFIG_CRYPTO_DEV_CCP=y
CONFIG_CRYPTO_DEV_CCP_DD=m
CONFIG_CRYPTO_DEV_SP_CCP=y
CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
This is needed to gain access to the crypto acce
Source: efivar
Version: 37
Severity: important
Dear Maintainer,
the efivar source package contains buggy diagnostics printing code, which may
corrupt the stack and cause crashes.
The culprit is the arrow() macro defined in src/util.h, which pokes a couple of
^ characters into a buffer consisting
Package: linux-image-4.19.0-3-armmp-lpae
Severity: important
Dear Maintainer,
Currently, the 32-bit ARM kernels are built without support for kernel mode
NEON, which means that none of the modules that depend on it are built either.
This mostly affects crypto drivers, as well as RAID6 and XOR. T
Package: linux-source-4.19
Severity: important
Dear Maintainer,
Currently, the linux-image-arm64 kernel is built with
CONFIG_ARM64_ERRATUM_843419 explicitly disabled, while it defaults to on
in the Kconfig definition.
The GCC toolchain enables a link time workaround for this erratum, and
so all
Package: src:linux
Version: 4.19.12-1
Severity: important
Dear Maintainer,
Please enable CONFIG_KERNEL_MODE_NEON, at least for the LPAE version.
This will automatically enable code paths for the XOR and RAID drivers,
and permit the various accelerated crypto drivers in arch/arm/crypto
to be enabl
On 28 February 2018 at 20:43, Ard Biesheuvel wrote:
> Package: src:linux
> Version: 4.15.4-1
> Severity: normal
>
> Dear Maintainer,
>
> Support for Socionext SynQuacer based platforms (a 24 core arm64 SoC) has
> landed in v4.15 mainline.
>
> Please enable this s
Package: src:linux
Version: 4.15.4-1
Severity: normal
Dear Maintainer,
Support for Socionext SynQuacer based platforms (a 24 core arm64 SoC) has
landed in v4.15 mainline.
Please enable this support in the Debian kernel as well:
CONFIG_ARCH_SYNQUACER=y
CONFIG_SNI_NETSEC=m
CONFIG_MMC_SDHCI_F_SDH3
pport for pmemXXX block device nodes to list-devices so
that they may be found automatically when using HTTP boot to install.
--
Ard.
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 4.14.0-rc4
Package: src:linux
Version: 4.9.30-2+deb9u2
Severity: normal
Dear Maintainer,
Please enable CONFIG_FRAMEBUFFER_CONSOLE (preferably as a builtin) in the
arm64's kernel image configuration so that systems with a graphics card
installed can get a console on the frame buffer rather than only via se
Package: src:linux
Version: 4.9.30-2+deb9u2
Severity: normal
Dear Maintainer,
Please consider adding CONFIG_SND_HDA_INTEL=m to the arm64 kernel config.
-- Package-specific info:
** Version:
Linux version 4.9.0-3-arm64 (debian-ker...@lists.debian.org) (gcc version 6.3.0
20170516 (Debian 6.3.0-18
ng to them, and
inadvertently clear upper address bits in the process.
My concern with changing CONFIG_ARCH_MMAP_RND_BITS_MAX is that it is
not a guarantee that mmap() will not be called with explicit addr
values in the problematic range. (In some cases, munmap() is used to
detect the VA range, given that munmap() turns out to succeed for
non-existent mappings unless the address value exceeds the VA size).
It's unlikely that an affected JIT would do both things at the same
time, i.e., steal upper address bits and perform mmap() allocations in
the problematic range, but we'd need to confirm it nonetheless.
--
Ard.
Package: libboost-log1.55.0
Version: 1.55.0+dfsg-3
Severity: normal
File: libboost-log
Dear Maintainer,
I am trying to cross compile an application that uses libboost_log. My host
system is has the amd64 architecture and the target system a armhf
architecture.
I tried to install both packages wit
ement
mvlan is just the ip link add ... replacement
Same goes for bridge-utils, as brctl is obsolete and vconfig has been
for 10 years, mvconfig (1.9-5 release) has been obsolete for 4 years I
think.
Anyway:
the current 2.0 version is not in git.
Regards,
Ard van Breemen
Hi,
Steinar H. Gunderson schreef op 2016-05-17 10:49:
I've got an ARM system where eth0 is hotplugged pretty slowly
(it hangs off of USB, and takes a while to initialize), so for
networking to work in general, the system needs to be able to
hotplug it. Thus, I have:
I currently use a few 1000 x
got "rejected".
As such, I am only a maintainer by name.
I have Cc: the guy that actually really does maintain the latest
version.
Regards,
Ard van Breemen.
aking it a debian native
package.
And then find a debian maintainer who is willing to upload.
Regards,
Ard van Breemen
--
.signature not found
.
Regards,
Ard van Breemen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
way these days to send patches ;-).
The patch allows to use %, dns, numerical, or whatever as
proxy address.
Regards,
Ard van Breemen
Description: enable AF_UNSPEC connections using getaddrinfo
Change port number into a string since getaddrinfo requires service name
Change connect to a loop
Hi,
On Tue, Oct 07, 2014 at 08:46:36AM -0400, David Magda wrote:
> We have some servers where VLANs are trunked to them in such a
> way that the bare network interface does not have any network
> available. This is because our network gear cannot
> simulataneously have the interface be both untagg
Hi,
On Tue, Mar 25, 2014 at 08:12:14AM +0100, ard wrote:
> Hmmm, actually I am a little bit surprised that the mere
> mentioning of eth1.20 in the bridge configuration automagically
> creates eth1.20.
A look into the bridge code:
if [ "$MODE" = "start" ] &&a
ot get created at
all, or created without ports, or somewhere in between.
If it attaches eth1 instead of nothing at all, that would be a
grave bug.
Regards,
Ard
--
.signature not found
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
On Thu, Oct 10, 2013 at 09:51:47AM +0200, Emmanuel DECAEN wrote:
> Maybe I'm wrong, but it looks like the /etc/network/*.d/vlan conflicts
> with normal behaviour of ifup/ifdown in wheezy.
> The script ifup/ifdown already use "ip link" to configure and create vlan.
I think you are quite correc
rite access to the iproute2 package repository, but not
to ifupdown. So I have to submit bugreports once I have tested
the trunk.
Regards,
Ard
--
.signature not found
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
On Tue, Jan 03, 2012 at 04:16:26PM +0100, Jaap Keuter wrote:
> Just to reignite interest in this matter (this bug, ifupdown or
> whatever) I submit a sample interfaces file I just experimented with.
> It configures an anonymous ethernet interface (eth0) with one vlan
> (vlan21). This vlan
Hi,
On Thu, Jul 01, 2010 at 06:18:25PM +0100, i...@comtek.co.uk wrote:
> Downgrading to linux-image-2.6.26-2-686 seems to fix the problem. I
> can't find a newer prebuilt kernel to test with apart from the one in
> experimental (doesn't seem to be installable).
>
> 2.6.26-2 is an acceptable fi
Hello,
On Thu, Jul 01, 2010 at 03:50:50PM +0100, i...@comtek.co.uk wrote:
> Okay, I've tried various other combinations of eth0 config with no luck.
> I haven't been able to get more information on the actual crash but I've
> attached a screenshot, just in case its of any use.
>
> Could this b
Hello,
On Wed, Jun 30, 2010 at 06:58:53PM +0100, i...@comtek.co.uk wrote:
> If I:
> 'ifup eth0'
> wait a few seconds until 'link becomes ready'
> 'ifup eth0.3'
>
> then everything is fine.
>
> If I:
> 'ifup eth0;ifup eth0.3'
>
> then I get a stack trace followed by the m
On Mon, May 24, 2010 at 10:56:15AM +0200, Andreas Henriksson wrote:
> IIRC Ard has been given access to the pkg-iproute git repo. No other news.
>
> PS. You're also welcome to help co-maintain iproute if you're interested.
I've uploaded the latest vlan-bug-fix package to
iner, and so the
distance to the community is a little far ;-).
> > I'd like the vlan people to continue maintaining vlan related stuff even
> > if they are merged into the iproute package.
> Ard, are you interested?
I am maintaining it, al beit inside the company where I am
On Mon, Feb 08, 2010 at 09:32:07AM +0100, Ard van Breemen wrote:
> Anyway: current functionality of the internal vlan package:
> - create vlans with either vconfig or ip depending on vconfig
> being there.
> - create macvlans with either mvconfig or ip depending on kernel
>
Hi,
On Tue, Nov 17, 2009 at 06:06:56PM +0100, ard wrote:
Obviously:
> #!/bin/sh -x
-x should not be there
> [ -w "${BASE}/${IFACE}/${ip_setting}" ] && echo "${!if_setting}
> > ${BASE}/${IFACE}/${ip_setting}"
needs 2 "'s extra :
Attached:
ip.txt : from the internal build
ip2.txt: what it probably should be
#!/bin/sh
# This should probably go into ifupdown
# But usually only those with lots of interfaces (vlans) need these
if [ -d "/proc/sys/net/ipv4/conf/$IFACE" ]
then
[ -n "$IF_IP_PROXY_ARP"] && echo $IF_IP_PR
Package: vlan
Version: 1.9-3
Internel 1.9-3 build differs from public build with respect to
/etc/network/if-up.d/ip
When unprepared it can break HA-firewall setups in a nasty way.
The internal build contains attached script. But actually it can
be much more generic.
Attached is the internal buil
Hello,
On Tue, Oct 07, 2008 at 09:53:15AM +0200, Andreas Henriksson wrote:
> The upstream developers consider vconfig deprecated in favor of iproute, see
> http://www.spinics.net/lists/netdev/msg77014.html and the followup.
>
> Maybe it would be good to start thinking about a scenario how to migr
c addresses,
please :-).
In other busses than pci there probably is another valid item, or
it is not needed at al.
I assume it wil also fix vlan being incorrectly renamed.
Regards,
Ard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
's created from eth0, and
that eth0 is brought up. (eth0 should already exist).
If something goes wrong there, then we really love to know.
(This behaviour is normal since kernel 2.4.14 or so.)
If that is not what you expected, then I would love to know why.
If that is what you expected, can
only be undestood by very
big/expensive irons that do IVL instead of SVL.
But my take on this, is that we can go only go sofar as to
support the vlan-raw-device in the interfaces file.
Anything more than that is too task-specific, and should be done
in preup/up/down/postdown lines in the interfaces
unnels and
bridges).
So if you remove the vlan-raw-device from the alias definition,
it should work as you want it.
Regards ard.
(I leave the bug open for Loic :-) )
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
I am a signature virus. Distribute me until the bitter
end
--
To UNSUBSCRIBE, email to [EMAI
w behaviour that ifup will handle
multiple iface eth0 entries. (I probably didn't read the manpages
right).
I will experiment with it to try to understand what is going on.
Regards,
Ard
--
begin LOVE-LETTER-FOR-YOU.txt.vbs
I am a signature virus. Distribute me until the bitter
end
--
To
Hello,
On Thu, Mar 02, 2006 at 05:23:30PM +1100, James Harper wrote:
> with a static inet6 entry in /etc/interfaces, the vlan ifupdown script try
> and do a second vconfig because they think it is a second interface. I'm not
> sure of the best way to work around this, but i'd be happy just to be ab
reassign 310734 kernel-image-2.6.8-2-386
thanks
This is apparently a kernel bug not related to the vlan userspace
package.
Regards,
Ard van Breemen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hello,
On Wed, Mar 23, 2005 at 02:54:28PM +0100, Lo?c Minier wrote:
> On mer, sep 22, 2004, Johann Botha wrote:
> > I think it should only try to add/remove the vlan interface if it is not an
> > alias.
>
> I came to the same conclusion.
I've fixed the scripts in that it ignores (exit 0) any in
69 matches
Mail list logo
