Re: Using Raspberry POE+ hat with bullseye
> I am using Debian Bullseye on a Raspberry PI 4 with a POE+ hat. So far I am > unable to get the fan on the POE+ hat working. (deleted) > #uname -a > Linux host 5.10.0-9-arm64 #1 SMP Debian 5.10.70-1 (2021-09-30) aarch64 GNU/ > Linux (deleted) > #uname -a > Linux host 5.14.0-0.bpo.2-arm64 #1 SMP Debian 5.14.9-2~bpo11+1 (2021-10-10) > aarch64 GNU/Linux * Debian arm64 (incl. images from raspi.debian.net) uses the plain upstream linux kernel. * The plain kernel 5.10 does not have the RPi POE driver. * 5.14 and later have the RPi POE driver, but the debian kernels do not enable it (so far). Solutions can be (1) Compile the kernel by yourself, following https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html It takes several hours but possible on RPi4. (2) or file a bug report to the Debian linux source package requesting enablement of CONFIG_PWM_RASPBERRYPI_POE. As far as I can remember, a request of a new device driver into the kernel package should verify working of that device driver with its corresponding device. Unfortunately, I don't have POE so I cannot help with verification. Best regards, Ryutaroh
compiling vanilla kernel with Debian clang-13
Hi, this is a clang related notes on compiling vanilla Linux kernel 5.15
by Debian clang-13 (from sid/experimental).
In short, the combination of Linux 5.15 + clang 13 seems better than
previous ones, e.g. Linux 5.13 + clang12, on arm64.
(1) Clang-related Kconfig items seem to work fine with my use case,
in particular, I have not seen any problem with the following config items:
CONFIG_RELR=y
CONFIG_SHADOW_CALL_STACK=y
CONFIG_LTO_CLANG_FULL=y
CONFIG_CFI_CLANG=y
CONFIG_CFI_CLANG_SHADOW=y
CONFIG_TRIM_UNUSED_KSYMS=y
CONFIG_INIT_STACK_ALL_ZERO=y (or CONFIG_INIT_STACK_ALL_PATTERN=y)
(2) "-mcpu=native" seems to work. With 5.13, it did not build a bootable kernel.
(3) Polyhedral optimization seems to work, as proposed at
https://groups.google.com/g/clang-built-linux/c/Pg7CXssRuYo/m/eHJkNgjTDgAJ
(4) ld.lld-13 uses less memory than ld.lld-12. ld.lld-12 used 7GiB with
CONFIG_LTO_CLANG_FULL=y, but ld.lld-13 uses "only" 4GiB.
I used the following script to compile a kernel.
Clang on Debian can be unstalled by
apt-get install clang/exerimental llvm/experimental lld/experimental.
clang in sid depends on clang-11 for now.
(5) CONFIG_XFS_FS=y or CONFIG_OVERLAY_FS=y causes runtime error in
clang.
cd /var/tmp
arch=`dpkg --print-architecture`
if [ $arch = amd64 ]; then
variant=amd64_none_amd64
march='-march=native'
elif [ $arch = arm64 ]; then
variant=arm64_none_arm64
march='-mcpu=native'
elif [ $arch = armhf ]; then
variant=armhf_none_armmp-lpae
march='-mcpu=native'
else
echo "Please find a suitable config of $arch."
exit 1
fi
KVER=5.15.2
exec build-log-${KVER}.txt 2>&1
set -xe
wget -T 10 -c https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-${KVER}.tar.xz
tar Jxf linux-${KVER}.tar.xz
cd linux-${KVER}
# install linux-config-5.15 from sid or experimental
xzcat /usr/src/linux-config-5.15/config.${variant}.xz >.config
cat >>.config <
Bug#989499: openssl: version 3 is slower than version 1.1.1k on arm64 with no crypto hardware
Package: openssl Version: 3.0.0~~alpha16-1 Severity: minor Tags: experimental X-Debbugs-Cc: debian-arm@lists.debian.org Dear Maintainer, As a response to a recent discussion at the Debian ARM mailing list, I compared the speed of aes-128-cbc of openssl 1.1.1k in Bullseye and 3.0 in experimental on Raspberry Pi 4B. The results are as below. Version 3.0 is slower than version 1.1.1k. On the other hand, at https://lists.debian.org/debian-arm/2021/06/msg9.html Diederik reported that version 3.0 is faster on arm64 with crypto hardware. I am unsure if this is an upstream issue. My speed results are as below: # openssl speed aes-128-cbc ... OpenSSL 1.1.1k 25 Mar 2021 built on: Thu Mar 25 20:49:34 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 73719.58k78001.25k79918.46k79520.45k78646.02k 79442.42k # openssl speed -evp aes-128-cbc ... OpenSSL 1.1.1k 25 Mar 2021 built on: Thu Mar 25 20:49:34 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 37975.41k40705.82k41937.97k42066.56k42265.07k 42382.97k # openssl speed aes-128-cbc ... version: 3.0.0-alpha16 built on: built on: Thu May 6 19:54:38 2021 UTC options:bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 CPUINFO: OPENSSL_armcap=0x83 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 37858.56k40995.79k41736.44k42339.69k41984.00k 42350.33k # openssl speed -evp aes-128-cbc ... version: 3.0.0-alpha16 built on: built on: Thu May 6 19:54:38 2021 UTC options:bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 CPUINFO: OPENSSL_armcap=0x83 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes AES-128-CBC 38057.99k41038.28k41973.03k41930.50k42233.35k 42308.27k Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.41-rt42 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssl depends on: ii libc62.31-12 ii libssl3 3.0.0~~alpha16-1 openssl recommends no packages. Versions of packages openssl suggests: ii ca-certificates 20210119 -- no debconf information
Re: hardware encryption,Re: hardware encryption
From: Ryutaroh Matsumoto Date: Fri, 04 Jun 2021 04:18:25 +0900 (JST) > Note that openssl version is much older but it is bundled with Debian > Bullseye. I installed openssl ver. 3 from Debian experimental, and observed much slower speed than ver. 1.1.1 in Debian Bullseye, on the same hardware and kernel, as below. Interesting... I wonder if I should file a bug to Debian BTS... # openssl speed aes-128-cbc ... version: 3.0.0-alpha16 built on: built on: Thu May 6 19:54:38 2021 UTC options:bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 CPUINFO: OPENSSL_armcap=0x83 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 37858.56k40995.79k41736.44k42339.69k41984.00k 42350.33k # openssl speed -evp aes-128-cbc ... version: 3.0.0-alpha16 built on: built on: Thu May 6 19:54:38 2021 UTC options:bn(64,64) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-UqeSFN/openssl-3.0.0~~alpha16=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 CPUINFO: OPENSSL_armcap=0x83 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes AES-128-CBC 38057.99k41038.28k41973.03k41930.50k42233.35k 42308.27k Best regards, Ryutaroh
Re: hardware encryption,Re: hardware encryption
Your Rock64 is significantly faster than my RPi4B. I wonder how such a big difference appears. From: Diederik de Haas Date: Thu, 03 Jun 2021 19:34:19 +0200,Thu, 03 Jun 2021 19:34:19 +0200 > $ openssl speed aes-128-cbc > ... > version: 3.0.0-alpha16 > built on: built on: Thu May 6 19:54:38 2021 UTC > ... > The 'numbers' are in 1000s of bytes per second processed. > type16 bytes64 bytes 256 bytes 1024 > bytes8192 bytes 16384 bytes > aes-128-cbc 84716.70k 269243.61k 584986.37k 830015.83k > 944873.47k 953417.73k > > $ openssl speed -evp aes-128-cbc > ... > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes64 bytes 256 bytes 1024 > bytes8192 bytes 16384 bytes > AES-128-CBC 95904.58k 297023.53k 611697.15k 855083.69k > 966412.97k 956033.71k On my RPi4B I have: # openssl speed aes-128-cbc ... OpenSSL 1.1.1k 25 Mar 2021 built on: Thu Mar 25 20:49:34 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128 cbc 73719.58k78001.25k79918.46k79520.45k78646.02k 79442.42k # openssl speed -evp aes-128-cbc ... OpenSSL 1.1.1k 25 Mar 2021 built on: Thu Mar 25 20:49:34 2021 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-YhzaKF/openssl-1.1.1k=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 37975.41k40705.82k41937.97k42066.56k42265.07k 42382.97k Note that openssl version is much older but it is bundled with Debian Bullseye. Kernel version is upstream 5.10.39 with almost the same kernel compilation options with Debian RT kernel. CPU frequency is fixed to 1.5GHz by "cpupower frequency-set -g performance". Best regards, Ryutaroh
Re: hung during build on arm-ubc-01
Hi,
On my Debian Bullseye arm64, "apt-get source --compile nodejs/experimental"
fails
by testsuite failures as:
not ok 1756 parallel/test-repl-strict-mode-previews
---
duration_ms: 1.774
severity: fail
exitcode: 1
stack: |-
assert.js:918
throw err;
^
AssertionError [ERR_ASSERTION]: The input did not match the regular
expression /\/\/ ReferenceError: xyz is not defined/. Input:
'> \nx\ny\nz\n'
at Object.
(/home/ryutaroh/build-nodejs/nodejs-14.16.1~dfsg/test/parallel/test-repl-strict-mode-previews.js:42:10)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1092:10)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14)
at Function.executeUserEntryPoint [as runMain]
(internal/modules/run_main.js:72:12)
at internal/main/run_main_module.js:17:47 {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: '> \nx\ny\nz\n',
expected: /\/\/ ReferenceError: xyz is not defined/,
operator: 'match'
}
...
not ok 1731 parallel/test-repl-mode
---
duration_ms: 1.151
severity: fail
exitcode: 1
stack: |-
assert.js:383
throw err;
^
AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:
assert.ok(
cli.output.accumulator.includes('\n// ReferenceError: xyz is not
defined')
)
at testStrictModeTerminal
(/home/ryutaroh/build-nodejs/nodejs-14.16.1~dfsg/test/parallel/test-repl-mode.js:52:10)
at
/home/ryutaroh/build-nodejs/nodejs-14.16.1~dfsg/test/parallel/test-repl-mode.js:15:3
at Array.forEach ()
at Object.
(/home/ryutaroh/build-nodejs/nodejs-14.16.1~dfsg/test/parallel/test-repl-mode.js:14:7)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1092:10)
at Module.load (internal/modules/cjs/loader.js:928:32)
at Function.Module._load (internal/modules/cjs/loader.js:769:14)
at Function.executeUserEntryPoint [as runMain]
(internal/modules/run_main.js:72:12)
at internal/main/run_main_module.js:17:47 {
generatedMessage: true,
code: 'ERR_ASSERTION',
actual: false,
expected: true,
operator: '=='
}
...
Full build log is attached. Ryutaroh
log.txt.xz
Description: Binary data
Re: kernel configs in Debian
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 performance regression where we do not > expect it. I do not know if you meant CONFIG_ARCH_* by "drivers". Removal of all CONFIG_ARCH_* other than CONFIG_ARCH_BCM2835 disables CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_FASTEOI_HIERARCHY_HANDLERS=y CONFIG_NUMA=n & CONFIG_HOTPLUG_CPU=n disable CONFIG_HAVE_SETUP_PER_CPU_AREA and CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK, and enable CONFIG_ARCH_FLATMEM_ENABLE. Those changes could have some impact... > The impact of CONFIG_DEBUG_PREEMPT is also higher than I expected > here, it may be worth asking on the linux-rt-users list about what the > expected cost on arm64 hardware is. I believe they are very well aware of this, see https://wiki.linuxfoundation.org/realtime/documentation/howto/applications/preemptrt_setup There recommendation seems(?) CONFIG_DEBUG_PREEMPT=n for better performance. > Can you check whether there are any other differences in the .config > file besides CONFIG_PARAVIRT that may cause the difference, and > that you didn't mix up the results? I believe no. The reason of the difference may come from: * The number of measurement is too few (2 times). * Measured speed depends on the IPv6 network of ISP, which I cannot make constant. The RPi4B is used for processing real network traffic and my family complains if it is down for too long... > I see you do a couple of things in this fragment. One of them is the > CONFIG_BPF_JIT_ALWAYS_ON=y option that might result in > a significant difference if you actually use BPF (otherwise it makes > no difference). I believe the measured speed depends on nftables, ipv4-ipv6 tunnel, macvlan driver, Ethernet driver and the general network stack, not including BPF. My net if config is: ip6tnl1 (tunnel) binds to myve1 (macvlan), and myve1 binds to eth0, and eth0 has absolutely no IPv4 or IPv6 address. The reason of using macvlan is to use multiple macvlan and macvtap interfaces binding to eth0. "ip l" shows as follows: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether dc:a6:32:bb:99:d9 brd ff:ff:ff:ff:ff:ff 3: myve1@eth0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 96:8a:a9:8d:f6:64 brd ff:ff:ff:ff:ff:ff 4: myvtap1@eth0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 500 link/ether 8e:7e:4b:95:3b:59 brd ff:ff:ff:ff:ff:ff 5: ip6tnl0@NONE: mtu 1452 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/tunnel6 :: brd :: permaddr 616:be05:411:: 6: ip6tnl1@myve1: mtu 1460 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/tunnel6 2400:4050:2ba1:ac00:99:f0ae:8600:2c00 peer 2001:380:a120::9 permaddr 9648:2668:3d4f:: 7: wlan0: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether dc:a6:32:bb:99:da brd ff:ff:ff:ff:ff:ff > I also see that you enable a number debugging options, including > CONFIG_UBSAN_SANITIZE_ALL=y, which I would expect to make > the kernel significantly slower when turned on. Is this one enabled > in the other kernels as well, or did you find that it has a positive > effect here? As far as I see, CONFIG_UBSAN=y and CONFIG_UBSAN_SANITIZE_ALL=y have not decreased the performance noticeablly (for my personal use cases). So I choose to turn on them when I have chance to build a kernel. As far as I can recall CONFIG_UBSAN related options did not decrease the YouTube playing by firefox-esr. For build of user-space applications, I have not seen " subjectively noticeable" performance difference by UBSAN. So I routinely use -fanitize=undefined. ASAN and MSAN are terribly slow, as we know well. > As mentioned above, turning off the unused platforms /should/ not > make a difference other than code size. Do you get different > results if you drop all the CONFIG_ARCH_*=n lines from the > fragment? If you do, I would consider that a problem in the > upstream kernel that needs to be investigated further. Having look at arch/arm64/Kconfig.platforms, I see some options depending on CONFIG_ARCH_*. Besides the ones mentioned at the beginning, they include IRQ_DOMAIN_HIERARCHY ARM_GIC The *IRQ* and ARM_GIC config options can have some impact on the performance, if a use case includes lots of HW interrupts, as I am using it I am ready to re-build a Debian kernel with only CONFIG_ARCH_* (except CONFIG_ARCH_BCM2835) disabled. Best regards, Ryutaroh
Re: kernel configs in Debian
Hi, 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. * CONFIG_DEBUG_PREEMPT=n much improves performance of linux-image-rt-arm64, while it is unselectabe with linux-image-arm64 as CONFIG_DEBUG_PREEMPT depends on CONFIG_PREEMPTION. * linux-image-rt-arm64 is much slower than the standard linux-image-arm64, but its performance probably becomes comparable by omitting unnecessary compile options for a given hardware. * All kernel versions are 5.10.28. Experiments: Compile options are adjusted as follows: apt-get source linux cd linux-5.10.28 fakeroot make -f debian/rules.gen setup_arm64_none_arm64 cat >>debian/build/build_arm64_none_arm64/.config <<'EOF' CONFIG_XEN=n CONFIG_PARAVIRT=n CONFIG_DEBUG_INFO_BTF=n EOF fakeroot debian/rules source fakeroot make -j 4 -f debian/rules.gen binary-arch_arm64_none_arm64 CONFIG_XEN selects CONFIG_PARAVIRT, so it must be disabled when CONFIG_PARAVIRT=n. CONFIG_DEBUG_INFO_BTF=y causes build error with linux-image-arm64. The job of RPi4B is taking IPv4 packets, applying NAPT, encapslating them in IPv6, and vice versa. Almost no user process is involved. CPU is mainly in the kernel mode or interrupt. The cpu consumption of hard irq + softirq of single cpu core spikes to 85 to 100% during the speedtest. CPU frequency of RPi4 is set to the lowest (600 MHz) by cpupower frequency-set -g powersave IPv6 packets can travel at around 600-800Mbps. All IPv4 packets are converted to IPv6 by RPi4, and no IPv4 packets are exchanged with the ISP. ISP's network is essentially IPv6 single stack. All devices are wired to a single Ethernet switch. On another amd64 fast laptop, I do speedtest -v --selection-details -a -i 192.168.1.72 -s 28910 The observed speeds are shown below: linux-image-arm64 with no change: Download: 577.23 Mbps (data used: 370.7 MB) Upload: 386.99 Mbps (data used: 353.0 MB) Download: 592.79 Mbps (data used: 1.1 GB) Upload: 380.41 Mbps (data used: 171.0 MB) linux-image-arm64 with CONFIG_PARAVIRT=n Download: 485.35 Mbps (data used: 406.0 MB) Upload: 380.57 Mbps (data used: 171.5 MB) Download: 514.57 Mbps (data used: 256.8 MB) Upload: 376.92 Mbps (data used: 169.2 MB) linux-image-rt-arm64 with no change: Download: 380.85 Mbps (data used: 422.2 MB) Upload: 283.87 Mbps (data used: 127.8 MB) linux-image-rt-arm64 with CONFIG_PARAVIRT=n Download: 332.95 Mbps (data used: 265.4 MB) Upload: 310.06 Mbps (data used: 273.7 MB) Download: 385.97 Mbps (data used: 400.1 MB) Upload: 295.57 Mbps (data used: 133.2 MB) Download: 379.69 Mbps (data used: 394.0 MB) Upload: 293.07 Mbps (data used: 139.4 MB) linux-image-rt-arm64 with CONFIG_PARAVIRT=n & CONFIG_DEBUG_PREEMPT=n Download: 425.95 Mbps (data used: 753.7 MB) Upload: 347.50 Mbps (data used: 382.8 MB) Download: 423.05 Mbps (data used: 499.4 MB) Upload: 332.48 Mbps (data used: 149.4 MB) RT kernel specialized for RPi: https://github.com/emojifreak/debian-rpi-image-script/blob/main/build-debian-raspi-kernel.sh Download: 488.33 Mbps (data used: 514.6 MB) Upload: 416.72 Mbps (data used: 330.8 MB) Download: 504.79 Mbps (data used: 633.5 MB) Upload: 404.07 Mbps (data used: 258.5 MB) Best regards, Ryutaroh
Re: kernel configs in Debian
Hi Alan, > I think you can probably enable CONFIG_IKCONFIG, I'm running a I am pretty sure I can, as I am using my rebuilt Debian RT kernel with CONFIG_IKCONFIG=m. I guess that Arnd wants comparison between the original Debian kernel and a minimally changed kernel (I am not completely sure, of course). I wonder why the Debian kernel team keeps CONFIG_IKCONFIG and CONFIG_IKHEADERS disabled... which probably makes linux-headers-* and linux-config-* packages unnecessary. Best regards, Ryutaroh
Re: kernel configs in Debian
Hi Alan, thank you for your interest. > Also look lor /proc/config.gz. If you have it it's a dump of the > config options of the running kernel. Whether it gets generated or not > is itself a config option. I plan to make the minimal chanages to the config as rebuilding it by apt-get source linux/sid cd linux-5.10.28 fakeroot make -f debian/rules.gen setup_arm64_none_arm64 cat >>debian/build/build_arm64_none_arm64/.config <<'EOF' CONFIG_XEN=n CONFIG_PARAVIRT=n EOF fakeroot debian/rules source fakeroot make -j 3 -f debian/rules.gen binary-arch_arm64_none_arm64 I expect not having /proc/config.gz as the CONFIG_IKCONFIG is disabled in the Debian kernel. I will include diff -u of .config in debian/build/build_arm64_none_arm64 and /usr/src/linux-config-5.10/config.arm64_rt_arm64 As CONFIG_XEN selects CONFIG_PARAVIRT, CONFIG_XEN=n is required to build a kernel with CONFIG_PARAVIRT=n. The last build of the above steps failed as ".btf.vmlinux.bin.o: file not recognized: file format not recognized". I am re-trying the build with adding CONFIG_DEBUG_INFO_BTF=n As single build takes 6 hours on RPi4B, it can take several days to find correct steps to build. The above steps seems completely obeying the instructions at https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html#s4.2.3 and https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html#s4.2.5 Best regards, Ryutaroh
Re: kernel configs in Debian
Hi Arnd, > Also, do you see the same performance difference with the non-rt kernel? > Most people would not run the -rt kernel because of the inherent > performance overhead, and it's not clear whether the slowdown you > see is the result of a combination of CONFIG_PREEMPT_RT with some > other option, or if this is something that hurts normal users as well. Thank you for your interest. I will check the differences of kernel compilation options for non-rt kernel (linux-image-arm64). Hopefully, I can return additional info. within one week. Best regards, Ryutaroh
kernel configs in Debian
Hi, 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 CONFIG_DEBUG_KERNEL=n each of the above increases the throughput of the packet filtering router by about 100Mbps, from the baseline 600Mbps by linux-image-rt-arm64 5.10. The above options cannot be disabled in Debian kernel package for its wider use cases. Rebuild of linux-image-rt-arm64 was done by https://github.com/emojifreak/debian-rpi-image-script/blob/main/build-debian-raspi-kernel.sh On the other hand, I am wondering why the following options are currently disabled by Debian arm64 kernel 5.10 package: CONFIG_CLEANCACHE: Cleancache can be thought of as a page-granularity victim cache for clean pages that the kernel's pageframe replacement algorithm (PFRA) would like to keep around, but can't since there isn't enough memory. So when the PFRA "evicts" a page, it first attempts to use cleancache code to put the data contained in that page into "transcendent memory", memory that is not directly accessible or addressable by the kernel and is of unknown and possibly time-varying size. And when a cleancache-enabled filesystem wishes to access a page in a file on disk, it first checks cleancache to see if it already contains it; if it does, the page is copied into the kernel and a disk access is avoided. When a transcendent memory driver is available (such as zcache or Xen transcendent memory), a significant I/O reduction may be achieved. When none is available, all cleancache calls are reduced to a single pointer-compare-against-NULL resulting in a negligible performance hit. If unsure, say Y to enable cleancache This is enabled by other distros.: https://hlandau.github.io/kconfigreport/option/CONFIG_CLEANCACHE.xhtml CONFIG_ZONE_DEVICE: Device memory hotplug support allows for establishing pmem, or other device driver discovered memory regions, in the memmap. This allows pfn_to_page() lookups of otherwise "device-physical" addresses which is needed for using a DAX mapping in an O_DIRECT operation, among other things. If FS_DAX is enabled, then say Y. (FS_DAX is enabled in Debian arm64 kernel 5.10 package) CONFIG_IRQ_TIME_ACCOUNTING: Select this option to enable fine granularity task irq time accounting. This is done by reading a timestamp on each transitions between softirq and hardirq state, so there can be a small performance impact. (My observation suggests CONFIG_PARAVIRT=y having much higher overhead.) If in doubt, say N here. The above CONFIG_IRQ_TIME_ACCOUNTING enables %hi in "top". See also "Is Your Linux Version Hiding Interrupt CPU Usage From You?" https://tanelpoder.com/posts/linux-hiding-interrupt-cpu-usage/ CONFIG_PARAVIRT_TIME_ACCOUNTING has a similar role for linux-image-cloud-arm64: Select this option to enable fine granularity task steal time accounting. Time spent executing other tasks in parallel with the current vCPU is discounted from the vCPU power. To account for that, there can be a small performance impact. If in doubt, say N here. The above enables "%st" in "top". Some other distros seem enabling it: https://hlandau.github.io/kconfigreport/option/CONFIG_PARAVIRT_TIME_ACCOUNTING.xhtml Best regards, Ryutaroh Matsumoto
Re: Stability of kernel updates on Debian 10
Hi Sad, If you are booting RPi from USB, the reason of failure is probably https://salsa.debian.org/raspi-team/image-specs/-/issues/41 In such a case, upgrading initramfs-tools to 0.140 should fix the symptom. Best regards, Ryutaroh From: Sad Clouds Subject: Stability of kernel updates on Debian 10 Date: Sat, 24 Apr 2021 08:53:37 +0100 > Hi, this is the first time I'm trying Debian on ARM and got an issue > after installing updates. > > I installed Debian 10 on RPi 4 (4GB), hoping updates would be stable > enough - https://raspi.debian.net/verified/20210210_raspi_4_buster.img.xz > > Ran "apt-get update; apt-get dist-upgrade" and now the kernel hangs > half-way through booting. Is this a known issue and also, do updates > get tested at all for RPi before they are released? > > The following packages got updated: > > root@rpi4-20210210:/etc/apt# apt-get dist-upgrade > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... Done > The following NEW packages will be installed: > linux-image-5.10.0-0.bpo.5-arm64 > The following packages will be upgraded: > base-files debian-archive-keyring firmware-brcm80211 iputils-ping libbsd0 > libdns-export1104 libisc-export1100 libpam-systemd > libpython3.7-minimal libpython3.7-stdlib libssl1.1 libsystemd0 libudev1 > libzstd1 linux-image-arm64 python3.7 python3.7-minimal > raspi-firmware systemd systemd-sysv udev wpasupplicant > 22 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 68.5 MB of archives. > After this operation, 259 MB of additional disk space will be used. > Do you want to continue? [Y/n] y >
how fast traffic can RPi4B filter
Hi,
Last weekend, I replaced my router in my home as the old one
showed hard disk health warnings.
In short, by using /etc/nftables.conf, RPi4B seems able to filter packets
at 600 Mbits/sec, where %irq of "atop" reaches 90% and M=1,000,000.
Packet processing capability depends on the complexity of tasks.
The router tunnels IPv4 packets over IPv6 by MAP-E (*).
MAP-E consists of two steps:
(1) IPv4 NAPT (Network Address and Port Translation)
(2) Tunneling (e.g. by ip -6 tunnel add $TUNDEV mode ip4ip6 remote $BR local
$CE dev $WANDEV encaplimit none)
As the sets of usable ports by NAPT are discontinuous in MAP-E,
the filtering rule is very complex (attached at the bottom),
nonetheless, RPi4B is able to handle packets
at a satisfactory speed, which is a surprise.
(*) Explanations of MAP-E:
https://en.wikipedia.org/wiki/Mapping_of_Address_and_Port or
https://www.slideshare.net/akiranakagawa3/20150304-apricot2015apnicfukuoka
Best regards, Ryutaroh Matsumoto
/etc/nftables.conf:
#!/usr/sbin/nft -f
flush ruleset
table ip my_notrack {
chain PREROUTING {
type filter hook prerouting priority raw;
ip saddr 192.168.1.0/24 ip daddr 192.168.1.2 notrack
ip saddr 192.168.1.2 ip daddr 192.168.1.0/24 notrack
}
}
table inet map_e_filter {
chain PREROUTING {
type filter hook prerouting priority filter;
iifname ip6tnl1 meta nfproto ipv6 log prefix "Error: ipv6 in
tunnel! " flags all counter
}
chain INPUT {
type filter hook input priority filter;
iifname ip6tnl1 meta nfproto ipv6 log prefix "Error: ipv6 in
tunnel! " flags all counter
}
chain POSTROUTING {
type filter hook postrouting priority filter;
iifname ip6tnl1 tcp flags & syn == syn tcp option maxseg size
set rt mtu counter # log prefix "TCPMSS shortened (input) " level debug flags
all
oifname ip6tnl1 tcp flags & syn == syn tcp option maxseg size
set rt mtu counter # log prefix "TCPMSS shortened (output) " level debug flags
all
}
}
table ip map_e_nat {
map myvmap {
type mark : verdict
elements = { 1 : goto map_e_chain1, 2 : goto map_e_chain2, 3 :
goto map_e_chain3, 4 : goto map_e_chain4, 5 : goto map_e_chain5, 6 : goto
map_e_chain6, 7 : goto map_e_chain7, 8 : goto map_e_chain8, 9 : goto
map_e_chain9, 10 : goto map_e_chain10, 11 : goto map_e_chain11, 12 : goto
map_e_chain12, 13 : goto map_e_chain13, 14 : goto map_e_chain14, 15 : goto
map_e_chain15, 16 : goto map_e_chain16, 17 : goto map_e_chain17, 18 : goto
map_e_chain18, 19 : goto map_e_chain19, 20 : goto map_e_chain20, 21 : goto
map_e_chain21, 22 : goto map_e_chain22, 23 : goto map_e_chain23, 24 : goto
map_e_chain24, 25 : goto map_e_chain25, 26 : goto map_e_chain26, 27 : goto
map_e_chain27, 28 : goto map_e_chain28, 29 : goto map_e_chain29, 30 : goto
map_e_chain30, 31 : goto map_e_chain31, 32 : goto map_e_chain32, 33 : goto
map_e_chain33, 34 : goto map_e_chain34, 35 : goto map_e_chain35, 36 : goto
map_e_chain36, 37 : goto map_e_chain37, 38 : goto map_e_chain38, 39 : goto
map_e_chain39, 40 : goto map_e_chain40, 41 : goto map_e_chain41, 42 : goto
map_e_chain42, 43 : goto map_e_chain43, 44 : goto map_e_chain44, 45 : goto
map_e_chain45, 46 : goto map_e_chain46, 47 : goto map_e_chain47, 48 : goto
map_e_chain48, 49 : goto map_e_chain49, 50 : goto map_e_chain50, 51 : goto
map_e_chain51, 52 : goto map_e_chain52, 53 : goto map_e_chain53, 54 : goto
map_e_chain54, 55 : goto map_e_chain55, 56 : goto map_e_chain56, 57 : goto
map_e_chain57, 58 : goto map_e_chain58, 59 : goto map_e_chain59, 60 : goto
map_e_chain60, 61 : goto map_e_chain61, 62 : goto map_e_chain62, 63 : goto
map_e_chain63, 64 : goto map_e_chain64 }
}
chain POSTROUTING {
type nat hook postrouting priority srcnat;
oifname ip6tnl1 mark set 1 counter packets 0
oifname ip6tnl1 meta l4proto tcp mark set numgen inc mod 61
offset 2 counter packets 0 # Chain64 or 63 will not be used and reserved for
server use.
oifname ip6tnl1 meta l4proto udp mark set numgen inc mod 61
offset 2 counter packets 0 # Chain64 or 63 will not be used and reserved for
server use.
oifname ip6tnl1 meta l4proto icmp mark set numgen inc mod 61
offset 2 counter packets 0 # Chain64 or 63 will not be used and reserved for
server use.
oifname ip6tnl1 meta l4proto udplite mark set numgen inc mod 61
offset 2 counter packets 0 # Chain64 or 63 will not be used and reserved for
server use.
oifname ip6tnl1 meta l4proto sctp mark set numgen inc mod 61
offset 2 counter packets 0 # Chain64 or 63 will not be used and reserved for
server use.
oifname ip6tnl1 meta l4proto dccp mark set numgen inc mod 61
o
32-bit versus 64-bit kernels with YouTube
Hi all, There was a debate on running 32-bit kernel on 64-bit ARM CPU. As my purely subjective experience, playing the same YouTube video on 32-bit kernel on RPi4B 8GB has 0.5 to 1 higher load average and 15 to 30% less CPU idle time than 64-bit kernel, according to "top". vc4.ko was used with both kernels and Xfce4 desktop was used. For playing YouTube by firefox, 64-bit kernel seems more suitable than 32-bit. Exact kernel compilation options for 32- and 64-bit kernels are https://github.com/emojifreak/debian-rpi-image-script/blob/main/build-raspi-kernel.sh Best regards, Ryutaroh Matsumoto From: Ryutaroh Matsumoto Subject: Re: Playing YouTube on RPi4B with task-gnome-desktop Date: Sat, 27 Mar 2021 12:21:42 +0900 (JST) >> (5) With the weston session, the frame drop and texture degradation decrease >> and >> the load average decreases below 4. > > On the same hardware, task-xfce-desktop seems to give even smoother > video playing with YouTube than the weston. I wonder if a promise by > Wayland is less overhead than the conventional X server... > Memory footprints are almost the same between weston and Xfce > (1 GB of all the processes and 1GB of buffer cache). > > Best regards, Ryutaroh
Re: Bug#986882: firefox-esr armhf: always fails to start with Error: eval: #() is not a valid R5RS form. use '#() instead
Control: reassign -1 uim 1:1.8.8-9 Control: severity -1 normal I found that GTK_IM_MODULE=uim firefox-esr causes the reported start-up failure, while GTK_IM_MODULE=xim firefox-esr allows the normal start-up of firefox-esr. So I reassign this to uim. The same symptom is also observed with firefox/sid. See also https://wiki.matoken.org/linux/issue http://hidenosuke.org/diary/?date=20080213 Best regards, Ryutaroh Matsumoto
Re: Bug#986882: firefox-esr armhf: always fails to start with Error: eval: #() is not a valid R5RS form. use '#() instead
Firefox-ESR always fails to start also in a QEMU armhf VM with linux-image-armmp-lpae/bullseye. It seems that firefox-esr is completely unavailable on Debian Bullseye armhf, while few people would use firefox on 32-bit architectures... Best regards, Ryutaroh Matsumoto
Bug#986882: firefox-esr armhf: always fails to start with Error: eval: #() is not a valid R5RS form. use '#() instead
Package: firefox-esr Version: 78.9.0esr-1 Severity: important Tags: sid bullseye X-Debbugs-Cc: debian-arm@lists.debian.org Dear Maintainer, On freshly installed Debian bullseye armhf, firefox-esr does not start at all with the following error: rm -rf .mozilla MOZILLA_DISABLE_PLUGINS=1 firefox-esr Error: eval: #() is not a valid R5RS form. use '#() instead Best regards, Ryutaroh Matsumoto -- Package-specific info: -- Extensions information Name: DoH Roll-Out Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Firefox Screenshots Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Form Autofill Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: Japanese Language Pack locale Location: /usr/lib/firefox-esr/browser/extensions/langpack...@firefox-esr.mozilla.org.xpi Package: firefox-esr-l10n-ja Status: enabled Name: Web Compat Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi Package: firefox-esr Status: enabled Name: WebCompat Reporter Location: /usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi Package: firefox-esr Status: user-disabled -- Plugins information -- Addons package information ii firefox-esr 78.9.0esr-1 armhfMozilla Firefox web browser - Extended Support Release (ESR) ii firefox-esr-l10n-ja 78.9.0esr-1 all Japanese language package for Firefox ESR -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: armhf (armv7l) Kernel: Linux 5.10.29-preempt (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libc62.31-11 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-3 ii libnspr4 2:4.29-1 ii libnss3 2:3.61-1 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.0-2 ii libx11-xcb1 2:1.7.0-2 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrender1 1:0.9.10-1 ii procps 2:3.3.17-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages firefox-esr recommends: ii libavcodec-extra58 [libavcodec58] 7:4.3.2-0+deb11u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.18.3-4 ii libgtk2.0-02.24.33-1 ii pulseaudio 14.2-2 -- no debconf information
Re: Bullseye armhf kernel for Raspberry Pi 4b does not boot
Control: tags -1 + wontfix patch
From: Der_Martin
Date: Fri, 9 Apr 2021 10:45:13 +0200
> On 16 Mar 2021 someone published a solution to that bug. Obviously nobody
> cares?
Bug #981586 is a duplicate of #971059.
#981586 is unlikely to get fixed because
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12
So I add "wontfix".
Only
CONFIG_PCIE_BRCMSTB=m
is sufficient for linux-image-armmp-lpae to boot on RPi4B 8GB.
The following script on Debian Bullseye armhf (in a container or a VM)
builds a kernel bootable from USB MSD on RPi4B 8GB.
#!/bin/sh
set -ex
KVAR=5.10.29
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-${KVAR}.tar.xz
tar Jxf linux-${KVAR}.tar.xz
apt-get -q -y install linux-config-5.10 build-essential libncurses-dev fakeroot
dpkg-dev
apt-get -q -y build-dep linux
cd linux-${KVAR}
xzcat /usr/src/linux-config-5.10/config.armhf_none_armmp-lpae.xz >.config
ARCH=arm
export ARCH
echo 'CONFIG_PCIE_BRCMSTB=m' >>.config
make oldconfig
nice -19 make -j 12 bindeb-pkg
Best regards, Ryutaroh Matsumoto
Re: More progress to report
From: Arnd Bergmann Subject: Re: More progress to report Date: Tue, 2 Mar 2021 21:41:46 +0100 > highmem is a huge problem by itself, and we plan to remove > it in the future for 32-bit kernels across all architectures. We should > probably add a boot-time warning in the mainline kernel as well > for any such configuration. I found an episode of the above. As #986326, LTP (linux test project) consistently causes kernel panic on linux-image-armmp-lpae, while it dosn't on linux-image-armmp, both on Sid (5.10.26 kernels), 3 GB memory, 1GB swap partition, and 2 CPU cores on QEMU 5.2. Best regards, Ryutaroh
Re: Unclean (USB) filesystem on reboot of arm64 8GB RPi4 UEFI
From: Ralph Aichinger >> To access USB devices on RPi4B, initramfs must load >> reset_raspberrypi.ko, as >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694 >> I hope it fixes your problem. > Thanks a lot, Ryutaroh, it indeed did fix my problem. > And thank you for filing and working on this bug. It was very difficult for me and took very long time to identify the cause of the symptom. I wish initramfs-tools 0.140 will be included in Bullseye so that nobody will suffer from this again... Ryutaroh
Re: Unclean (USB) filesystem on reboot of arm64 8GB RPi4 UEFI
> My problem is that each time I reboot (using shutdown -r now) > my system boots into an initrd shell asking me to fsck /dev/sda3 > Possibly related log entry: To access USB devices on RPi4B, initramfs must load reset_raspberrypi.ko, as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694 I hope it fixes your problem. Best regards, Ryutaroh Matsumoto
RPi4B 5GHz WiFi problems #985632 & #981616 completely went away by replacing brcmfmac43455-sdio.bin and brcmfmac43455-sdio.clm_blob
Control: reassign 981616 firmware-brcm80211 20201218-3 Hi, two RPi4B 5GHz WiFi problems #985632 firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine and #981616 5GHz WiFi does not work with vc4.ko on RPi4 and 4K display completely went away by replacing /lib/firmware/brcm/brcmfmac43455-sdio.bin and /lib/firmware/brcm/brcmfmac43455-sdio.clm_blob by the files at https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm Commit messages at https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm are interesting: Use BCM43456 clm_blob on CYW43455 The previous CYW43455 clm_blob provides limited access to the higher 5GHz channels (100+) - the BCM43456 (surprisingly) seems to work and doesn't have this problem. Huh Update CYW43455 firmware This release fixes the error: Firmware trap: type 0x4 @ epc 0x0007a094 The full version string is: Version 7.45.229 (617f1f5 CY) CRC: 253bd863 Date: Mon 2021-01-04 19:58:58 PST Ucode Ver: 1043.2160 FWID 01-2dbd9d2e See: raspberrypi/linux#3849 Best regards, Ryutaroh Matsumoto
Re: Playing YouTube on RPi4B with task-gnome-desktop
> (5) With the weston session, the frame drop and texture degradation decrease > and > the load average decreases below 4. On the same hardware, task-xfce-desktop seems to give even smoother video playing with YouTube than the weston. I wonder if a promise by Wayland is less overhead than the conventional X server... Memory footprints are almost the same between weston and Xfce (1 GB of all the processes and 1GB of buffer cache). Best regards, Ryutaroh
Playing YouTube on RPi4B with task-gnome-desktop
Dear Debian ARM users, As Bullseye almost frozen, I have seen if I can play YouTube video on my RPi4B 8GB. It was essentially a success with some tricks as follows: (1) 5GHz WiFi becomes unusable with firmware-brcm80211 version 20210208-1 and newer, as reported #985632. 2.4GHz WiFi works fine even with Bluetooth (resolved #984844). (2) task-gnome-desktop is installed. (3) Pulseaudio does not work with ALSA sinks brought by vc4.ko, e.g. in #!/bin/sh set -x while true; do systemctl --user status pulseaudio pacmd list-sinks pacmd exit systemctl --user restart pulseaudio done every command gets stuck or fails (#985928). A workaround is preventing pulseaudio from touching the ALSA sinks brought by vc4.ko. In /etc/pulse/default.pa (3-1) Comment out "load-module module-udev-detect" and "load-module module-detect". (3-2) Add "load-module module-alsa-card device_id=2" assuming snd_bcm2835 has device ID 2 in /proc/asound/cards. In the following, Firefix-ESR Wayland in Bullseye with MOZ_ENABLE_WAYLAND=1 in the enviroment variables is assumed. Gnome Wayland session is also assumed. (4) A YouTube video https://youtu.be/NCqNDjntd3E can played by the Firefox ESR Wayland with some drop of frames and some degradation of textures. Audio is fine with HDMI output. Load average is above 7. (5) With the weston session, the frame drop and texture degradation decrease and the load average decreases below 4. (*) Firefox (ESR) with MOZ_ENABLE_WAYLAND=1 does not work at all on Gnome Wayland and Weston sessions on the Raspberry Pi OS as v3d.ko does not support Wayland. I wonder how Ubuntu RasPi team will handle it (or simply dropping support of Wayland as Raspberry Pi OS does). I hope this being somewhat interesting to the list members... Best regards, Ryutaroh Matsumoto
Re: Bug#985863: firefox: VideoCore GPU seems unrecognized by Firefox 87 Wayland
>> crw-rw+ 1 root video 226, 0 Mar 24 16:35 card0 > and you are in this video group? Thanks, yes, ryutaroh@raspi4b8gb:~$ groups ryutaroh adm tty lp fax cdrom floppy audio video plugdev systemd-journal kvm netdev bluetooth pulse-access colord (You might say too many groups...) Ryutaroh
Bug#985863: firefox: VideoCore GPU seems unrecognized by Firefox 87 Wayland
Package: firefox Version: 87.0-1 Severity: normal Tags: sid X-Debbugs-Cc: debian-arm@lists.debian.org Dear Maintainer, I wonder if the reported issue is https://bugzilla.mozilla.org/show_bug.cgi?id=1689207 but I am unsure of it. I am running linux-image-arm64 with VideoCore GPU as follows: $ ls -l /dev/dri total 0 drwxr-xr-x 2 root root 60 Mar 24 16:34 by-path crw-rw+ 1 root video 226, 0 Mar 24 16:35 card0 $ ls -l /dev/dri/by-path total 0 lrwxrwxrwx 1 root root 8 Mar 24 16:35 platform-gpu-card -> ../card0 # dmesg | fgrep -i gpu [ 23.523232] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4]) [ 23.610693] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4]) [ 23.611152] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4]) [ 23.611474] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4]) [ 23.611805] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.612075] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.612523] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.612848] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4]) [ 23.821879] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 [ 24.141019] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device # dpkg-query -W | fgrep linux-image linux-image-5.10.0-5-rt-arm64 5.10.24-1 linux-image-rt-arm645.10.24-1 The reported issue is observed on the Debian kernel as well as the Raspberry Pi OS kernel. Firefox 87 Wayland seems not recognizing the GPU and shows the following error messages, while firefox-esr in Bullseye does not show it. Under MOZ_ENABLE_WAYLAND=1 firefox on amd64 host with I915 GPU shows no error messages. Script started on 2021-03-25 14:22:01+09:00 [TERM="xterm-256color" TTY="/dev/pts/0" COLUMNS="80" LINES="24"] $ export MOZ_ENABLE_WAYLAND=1 $ firefox --version Mozilla Firefox 87.0 $ firefox Crash Annotation GraphicsCriticalError: |[0][GFX1-]: No GPUs detected via PCI (t=2.27638) [GFX1-]: No GPUs detected via PCI (firefox:2753): Gdk-CRITICAL **: 14:23:35.084: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:36.057: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:36.059: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:36.709: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-CRITICAL **: 14:23:37.510: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox:2753): Gdk-WARNING **: 14:23:47.899: Tried to unmap the parent of a popup $ firefox-esr --version Mozilla Firefox 78.9.0esr $ firefox-esr (firefox-esr:2556): Gdk-CRITICAL **: 14:22:52.143: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.322: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.324: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.914: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:53.916: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-CRITICAL **: 14:22:54.618: gdk_wayland_window_set_dbus_properties_libgtk_only: assertion 'GDK_IS_WAYLAND_WINDOW (window)' failed (firefox-esr:2556): Gdk-WARNING **: 14:23:08.679: Tried to unmap the parent of a popup $ exit exit Script done on 2021-03-25 14:23:55+09:00 [COMMAND_EXIT_CODE="0"] Best regards, Ryutaroh Matsumoto -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-5-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libatk1.0-0 2.36.0-2 ii libc62.31-10 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.20-2 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stabl
Bug#985632: firmware-brcm80211: [REGRESSION] RPi4B 5GHz WiFi stopped working with 20210208-4, 20201218-3 was fine
Package: firmware-brcm80211 Version: 20210208-4 Severity: grave Tags: sid bullseye Justification: renders package unusable X-Debbugs-Cc: debian-arm@lists.debian.org Dear Maintainer, 5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto5GHz WiFi stopped working with 20210208-4. iw wlan0 scan does not show SSID of 5GHz WiFi. With 20201218-3, 5GHz worked fine, provided that vc4.ko is blacklisted (see #981616). I will see if the newer package in the experimental behaves differently. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-brcm80211 depends on no packages. firmware-brcm80211 recommends no packages. Versions of packages firmware-brcm80211 suggests: ii initramfs-tools 0.139 -- no debconf information
Bug#985121: linux-image-5.10.0-4-rt-arm64: KMS seems broken in vc4.ko
Package: src:linux Version: 5.10.19-1 Severity: normal Tags: upstream sid bullseye X-Debbugs-Cc: debian-arm@lists.debian.org Control: forwarded -1 http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008049.html Dear Maintainer, kmscube 0.0.0~git20210103-1 fails to start with the error message on Raspberry Pi 4B: failed to set mode: Invalid argument kmscube works fine on linux-image-amd64 and Raspberry Pi OS kernel with vc4.ko and v3d.ko loaded. Debian kernel without vc4.ko does not have KMS support on RPi4B. If this is an issue in kmscube, please feel free to reassign. This has been reported to the upstream maintainer. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.10.0-4-rt-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP PREEMPT_RT Debian 5.10.19-1 (2021-03-02) ** Command line: dma.dmachans=0x37f5 bcm2709.boardrev=0xd03114 bcm2709.serial=0x488d2af3 bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:BB:99:D9 vc_mem.mem_base=0x3eb0 vc_mem.mem_size=0x3ff0 console=tty0 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 cma=256M@256M rootwait rootfstype=ext4 module_blacklist=vc4,btrfs ** Tainted: C (1024) * staging driver was loaded ** Kernel log: [ 15.434159] systemd[1]: Listening on udev Kernel Socket. [ 15.469512] systemd[1]: Mounting Huge Pages File System... [ 15.586142] systemd[1]: Mounting POSIX Message Queue File System... [ 15.693933] systemd[1]: Mounting Kernel Debug File System... [ 15.760955] systemd[1]: Mounting Kernel Trace File System... [ 15.824464] systemd[1]: Starting Restore / save the current clock... [ 15.887927] systemd[1]: Starting Set the console keyboard layout... [ 15.948674] systemd[1]: Starting Create list of static device nodes for the current kernel... [ 16.009118] systemd[1]: Starting Load Kernel Module configfs... [ 16.072408] systemd[1]: Starting Load Kernel Module drm... [ 16.136954] systemd[1]: Starting Load Kernel Module fuse... [ 16.186350] fuse: init (API version 7.32) [ 16.593944] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [ 16.594243] systemd[1]: Condition check resulted in File System Check on Root Device being skipped. [ 16.606377] systemd[1]: Starting Journal Service... [ 16.697713] systemd[1]: Starting Load Kernel Modules... [ 16.772886] systemd[1]: Starting Remount Root and Kernel File Systems... [ 16.826411] EXT4-fs (sda2): re-mounted. Opts: journal_async_commit,nobarrier,data=writeback,commit=3600 [ 16.839276] systemd[1]: Starting Coldplug All udev Devices... [ 16.936206] systemd[1]: Mounted Huge Pages File System. [ 16.963282] systemd[1]: Mounted POSIX Message Queue File System. [ 16.991278] systemd[1]: Mounted Kernel Debug File System. [ 17.088051] systemd[1]: Started Journal Service. [ 17.499035] systemd-journald[259]: Received client request to flush runtime journal. [ 29.663856] vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 29.838127] iproc-rng200 fe104000.rng: hwrng registered [ 30.005996] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer [ 30.152450] Module vc4 is blacklisted [ 30.528213] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 30.841068] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. [ 30.893324] cryptd: max_cpu_qlen set to 1000 [ 30.905644] mc: Linux media interface: v0.10 [ 30.931090] bcm2835_audio bcm2835_audio: card created with 8 channels [ 30.965046] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 30.965729] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [ 30.966251] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [ 30.966940] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 30.988506] platform regulatory.0: firmware: direct-loading firmware regulatory.db [ 30.993828] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [ 31.010109] videodev: Linux video capture interface: v2.00 [ 31.089165] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6 [ 31.099490] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.bin [ 31.100616] brcmfmac mmc0:0001:1: firmware: direct-loading firmware brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt [ 31.106479] usbcore: registered new interface driver brcmfmac [ 31.197366] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned. [ 31.222017] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned. [ 31.241095] brcmfmac
Bug#984844: bluez-firmware: 2.4 GHz WiFi is interfered by bluetooth on RPi4B
Package: bluez-firmware Version: 1.2-4 Severity: important Tags: upstream fixed-upstream sid bullseye X-Debbugs-Cc: debian-arm@lists.debian.org Control: forwarded -1 https://github.com/RPi-Distro/firmware-nonfree/issues/8 Dear Maintainer, I have installed bluetooth 5.55-3 bluez 5.55-3 bluez-firmware 1.2-4 When I block bluetooth by /usr/sbin/rfkill, 2.4 GHz WiFi on Raspberry Pi 4 seems to work, at least ping packets can reach to machines on the same LAN. On the other hand, when I unblock bluetooth by /usr/sbin/rfkill, 2.4GHz WiFi does not work well. Connection by SSID is established, but no ping packet reach to machines on the same LAN. This seems fixed at https://github.com/RPi-Distro/firmware-nonfree/issues/8 Linux kernel is Debian linux-image-5.10.0-4-rt-arm64 5.10.19-1 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-rt-arm64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Re: WiFi on RPi
> Interference from bluetooth? Could be. I have been suspecting this possibility. But as my main frequency is 5GHz, I have not investigating it... The Raspbian OS is known to have suffered from the interference between bluetooth and 2.4GHz WiFi as https://github.com/RPi-Distro/firmware-nonfree/issues/8 Best regards, Ryutaroh
Re: WiFi on RPi
> | 3: wlan0: mtu 1500 qdisc noop state DOWN mode > DEFAULT group default qlen 1000 > | link/ether dc:a6:32:ae:8d:59 brd ff:ff:ff:ff:ff:ff > \-- Just FYI, with kernel version 5.9 and 5.10, I have been unable to get WiFi on RPi4B 8GB working with 2.4GHz. 5GHz works fine without vc4.ko and fails with vc4.ko. 2.4GHz WiFi is usable with Raspbian kernel 64-bit 5.10, so I am assuming my hardware is OK. Since I do not use 2.4GHz WiFi because it gets interfered by my microwave oven, I have not spent much time on investigating the cause... Best regards, Ryutaroh
Re: More progress to report
> That approach may be reasonable for many arm architectures > which do not show considerably lower performance on 64 bit > compared to 32 bit. > > For the Pi4 this is an undeniably good reason not to use 64 > bit because contrary to common believes the 32 bit kernel > has no problems with 8 GB of RAM. How about running 32-bit binaries/executables on 64 bit-kernel, which can be done on RPi with no problem. My reason for advocating 32-bit binaries on 64-bit ARM CPUs (not limited to RPi4) is considerably smaller memory footprint. Best regards, Ryutaroh
more unofficial installer for RPi
Hi all, Since customizations of Debian for RPi have been discussed here, I'd like to give a pointer to more unofficial installer of Debian for RPi at https://github.com/emojifreak/debian-rpi-image-script It does customizations of locales, etc. in an interactive manner, and it write an bootable image directly to an SD card, USB MSD, or /dev/loop?. Other features not found in raspi.debian.net include: * GPT partitioning and boot from USB (Linux kernel 5.10 prevents images on raspi.debian.net from USB booting...) * Choice of Debian 10 Buster, 11 Bullseye and later. * Choice among ifupdown, Network Manager and systemd-networkd for network configuration * Choice of package coverage according to the package priority * btrfs and ext4 filesystems can be chosen as root. btrfs compress-force=lzo significantly increases the storage speed and size (but I have less trust in btrfs...) * Setting the size of a swap partition (or lack of it) * Choice of timezone and locale * Choice of wireless SSID * Choice of keyboard layout The above installer needs a very latest version of qemu-user-static Debian package (probably >= 5.2) installed on a Debian (or its variant) host running the above installer script. Best regards, Ryutaroh
Re: More progress to report
> 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. Diederik reported probably the same problem to the linux-rpi-kernel list as http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-February/008002.html For that problem, black listing vc4.ko at cmdline.txt prevents the problem http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-February/008007.html > Unfortunately the Bullseye 32 Bit kernel seems not to boot, > because the support of USB looks broken: Debian kernel team does not support booting 32-bit kernel on 64-bit ARM, as told by Ben https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971059#12 Best regards, Ryutaroh
WiFi on RPi
Hi John, > Does anyone have wifi running on an RPi400 with Debian 64 Buster or > Bullseye? I'm using RPi4B 8GB model, which seems similar to RPi400. Without "module_blacklist=vc4" in the kernel command line (i.e. "cmdline.txt"), WiFi on my RPi4B does not work. Best regards, Ryutaroh
Re: Debian Bullseye on Raspberry Pi 4 4GB?
From: deloptes > is the aarch64 bullseye kernel working on the RPI? > The buster does not work, so I copied the raspberrypi kernel and it works > fine. Since I couldn't find an answer on the list, I write what I know. I use RPi4B 8GB. Plain upstream kernel became fully functioning from kernel version 5.8. Kernel version 5.9 was fine. 4K display output is also possible by hdmi_enable_4kp60=1 "config.txt". Gnome desktop environment works fine with 4K display. We can install Linux kernel 5.10 from buster-backports, which is the way to create images on raspi.debian.net for buster. Linux kernel 5.10 have several regressions: 1. Unless reset_raspberrypi.ko is loaded by initramfs, USB boot becomes impossible. 2. 5GHz WiFi is blocked by the newly introduced vc4.ko. 3. According to Diederik on the linux-rpi-kernel list, the audio functionality is also affected by vc4.ko. 4. My btrfs root filesystem becomes completely unmountable once every week... 2 and 3 can be worked around by module_blacklist=vc4 in the kernel comand line. Because of 4, I am using self-compiled upstreadm kernel 5.9.16... Another intel laptop also becomes very unstable with kernel 5.10, and I am staying away from 5.10. Best regards, Ryutaroh Matsumoto
Pls. consider raspi-related configs for kernel 5.10
Control: retitle -1 Pls. consider raspi-related configs for 5.10 Control: tags -1 + patch Control: block 968181 by 977441 Dear Debian kernel maintainers, CC: the Debian ARM list, Could you consider enabling the following kernel compilation options for Raspberry Pi 3&4 series for kernel 5.10? The patch is against latest package source at salsa.debian.org. --- debian/config/arm64/config-orig 2020-12-16 09:46:18.645380333 +0900 +++ debian/config/arm64/config 2020-12-16 10:22:17.998897582 +0900 @@ -424,6 +424,11 @@ ## file: drivers/gpu/drm/vc4/Kconfig ## CONFIG_DRM_VC4=m +CONFIG_DRM_VC4_HDMI_CEC=y +CONFIG_DRM_V3D=m +CONFIG_BCM_VIDEOCORE=m +CONFIG_BCM2835_VCHIQ=m +CONFIG_BCM2835_VCHIQ_MMAL=m ## ## file: drivers/gpu/host1x/Kconfig @@ -443,6 +448,7 @@ CONFIG_SENSORS_PWM_FAN=m CONFIG_SENSORS_SL28CPLD=m CONFIG_SENSORS_XGENE=m +CONFIG_SENSORS_RASPBERRYPI_HWMON=m ## ## file: drivers/hwspinlock/Kconfig @@ -1006,6 +1012,7 @@ CONFIG_PINCTRL_AMD=y CONFIG_PINCTRL_SINGLE=y CONFIG_PINCTRL_MAX77620=y +CONFIG_PINCTRL_BCM2835=y ## ## file: drivers/pinctrl/qcom/Kconfig @@ -1093,6 +1100,7 @@ ## file: drivers/reset/Kconfig ## CONFIG_RESET_CONTROLLER=y +CONFIG_RESET_RASPBERRYPI=m ## ## file: drivers/rpmsg/Kconfig @@ -1136,6 +1144,7 @@ ## file: drivers/soc/bcm/Kconfig ## CONFIG_RASPBERRYPI_POWER=y +CONFIG_BCM2835_POWER=y ## ## file: drivers/soc/fsl/Kconfig I have already built a Debian package with the above options from the latest master branch source on salsa.debian.org, and observed the following on RPi4: (1) CONFIG_DRM_V3D has no effect, as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977441#18 (2) HDMI display resolution can become 4K and fixing an important bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968188 (3) /dev/dri/render* does not appear unlike https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1880125/comments/14 https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1850876/comments/33 GPU/DRM acceleration remains unusable on RPi4, and bug 968181 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968181 remains open. 968181 seems blocked by 977441. (4) My built Debian kernel 5.10.1 can boot from my usb mass storage device ID 04bb:0168 I-O Data Device, Inc. I-O DATA HDPH-UT but cannot access the root filesystem... My USB MSD mergenally worked with Debian kernel 5.9.* and can compile the Debian kernel package. My USB MSD requires periodical reset by the Debian kernel 5.9.*, which suggests this MSD is buggy... I ordered a faster SSD-based USB MSD. (5) Raspberry Pi Wireless cannot be used by my built Debian kernel 5.10.1. The wirelss has worked perfectly with Debian kernel 5.7--5.9. I will see what will happen with a Debian kernel package 5.10* both with and without proposed patch, and report it back, when it arrives in experimental or unstable. Bes regards, Ryutaroh Matsumoto
Re: Bug#976808: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0
Hi Alper, Thanks for your simpler reproducing procedure. Several days ago I verified that this symptom also appears with the latest github source of qemu and reported this to the upstream as https://bugs.launchpad.net/qemu/+bug/1907952 I pasted your simpler procedure to the upstream report. This Debian bug report also has "upstream" and "forwarded" properties. So far, no response has been given to the upstream bug report. Let us hope the upstream pays attention to this... Best regards, Ryutaroh
Re: Bug#976808: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0
I verified that the reported symptom does NOT occur with
qemu-system-x86_64 and ttyS0 serial console running on an amd64 host.
This symptom seems unique to arm(64).
Specifically, I did the following:
(1) Start Bullseye d-i Alpha3 amd64 by the following commands:
#!/bin/sh
ARCH=amd64
IMAGE=`pwd`/qemu-disk-${ARCH}.qcow2
CDROM=`pwd`/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso
rm -f $IMAGE
qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o
preallocation=off $IMAGE 20G
cd /var/tmp
cp /usr/share/OCMF/OVMF_VARS.fd .
qemu-system-x86_64 \
-vga none -display gtk -enable-kvm -machine q35 -cpu host -m 3072 -smp 2\
-net nic,model=virtio -net user -object
rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0,id=rng-device0 \
-drive
if=virtio,file=${IMAGE},index=0,format=qcow2,discard=unmap,detect-zeroes=unmap,media=disk
\
-cdrom ${CDROM} \
-drive
if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=`pwd`/OVMF_VARS.fd
(2) Start the d-i with "console=ttyS0" kernel command line.
I was able to use arrow keys without problem with the d-i Alpha 3.
Best regards, Ryutaroh Matsumoto
Re: Bug#976808: arrow keys are received as just ^[ on ttyAMA0
Control: found -1 1:5.2+dfsg-2 Control: retitle -1 with "-display gtk" arrow keys are received as just ^[ on ttyAMA0 Control: severity minor I have checked my reported symptom with qemu-system-arm/sid. With -nographic, arrow keys work just fine. With -display gtk, arrow keys does not work on ttyAMA0 as reported. I changed the severity to minor as we know workarounds. The reason why virt-manager does not show this symptom may be because virt-manager uses spice. I suspect something wrong in "-display gtk". Best regards, Ryutaroh
Re: Bug#976808: arrow keys are received as just ^[ on ttyAMA0
The symptom does not appear when I use virt-manager instead of using qemu-system-aarch64 directly. Ryutaroh
Re: Bug#976808: Bullseye arm64 d-i Alpha 3: Items cannot be selected by space
Control: retitle -1 arrow keys are received as just ^[ on ttyAMA0 Control: reassign -1 qemu-system-arm 1:5.1+dfsg-4+b1 From: Alper Nebi Yasak Date: Thu, 10 Dec 2020 17:36:20 +0300 > (Just in case, try running "cat -v" and pressing the arrow keys -- it > prints ^[[A upto ^[[D or ^[0A upto ^[0D for me.) Thank you for trying to reproduce the symptom. I tried * -device virtio-gpu-pci -device usb-kbd * -device virtio-gpu-pci -device vitio-keyboard-pci. with qemu-system-aarch64. On my own built QEMU disk image, in both cases, * On /dev/tty1, arrow keys print ^[[A ^[[B and * on /dev/ttyAMA0 they just print ^[. This symptom is independent of Debian Installer Alpha 3, and looks a bug in qemu-system-arm or linux-image-arm64. So I reassign this to qemu and retitle this. /dev/tty1 is unusable by d-i Alpha 3 with the default kernel command line, and I added "console=tty1" to the kernel command line as I was told at the Debian ARM mailing list. Then I am now able to use arrow keys on the graphical installer! Thanks! This is not an errata of d-i, but adding this workaround "console=tty1" to https://www.debian.org/devel/debian-installer/errata may be helpful to users. Ryutaroh
Re: d-i Alpha 3 seems unusable for qemu-system-aarch64
> So maybe there should be message "Debian is for SBC, please use > $OTHER_DISTRO for servers/etc" on d-i website? Debian Bullseye arm64 disk image for ACPI systems can be built on an amd64/arm64 Debian host by mmdebstrap (or probably qemu-debootstrap) and grub-install in grub-efi-arm64 as I did at https://github.com/emojifreak/qemu-arm-image-builder "Debian is for SBC" sounds too strong... Ryutaroh
d-i Alpha 3 seems unusable for qemu-system-aarch64
Hi Debian Arm users, I tried Bullseye d-i Alpha3 released on December 6 for building a qemu disk image usable by qemu-system-aarch64. To me, Alpha 3 d-i seems almost unusable for that purpose. I filed a report at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808 If you have interest, please have a look. Ryutaroh
arm64, armhf and armel autopkgtest-virt-qemu
Hi everyone, Conventionally autopkgtest-virt-qemu has been unavailable for arm64, armhf and armel ports. Unofficial VM images and patch to autopkgtest latest upstream git source are posted at http://153.240.174.134:64193/autopkgtest-VM/ which make autopkgtest available for arm64, armhf and armel guest VMs. I hope they are useful for ARM porting activities... Best regards, Ryutaroh Matsumoto
Bug#973038: autopkgtest-build-qemu installs grub-pc on arm64 which is unavailable
Package: autopkgtest
Version: 5.15
Severity: important
X-Debbugs-Cc: debian-arm@lists.debian.org
Dear Maintainer,
autopkgtest-build-qemu tries to install grub-pc even when architecture is arm64.
Clearly, grub-pc is unavailable arm64.
# autopkgtest-build-qemu sid /var/tmp/sid-arm64.img
gives
Exec: ['mount', '--bind', '/sys', '/tmp/tmpbfh0w3m3/sys']
Exec: ['chroot', '/tmp/tmpbfh0w3m3', 'apt-get', '-y', '--no-show-progress',
'install', 'grub-pc']
ERROR: Program failed: 100
ERROR: RuncmdError('Program failed: 100')
Something went wrong, cleaning up!
Exec: ['kpartx', '-dsv', '/var/tmp/sid-arm64.img.raw']
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: arm64 (aarch64)
Kernel: Linux 5.9.0-1-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages autopkgtest depends on:
ii apt-utils 2.1.10
ii libdpkg-perl1.20.5
ii procps 2:3.3.16-5
ii python3 3.8.2-3
ii python3-debian 0.1.38
Versions of packages autopkgtest recommends:
ii autodep8 0.24
Versions of packages autopkgtest suggests:
pn lxc
pn lxd
ii ovmf 2020.08-1
ii qemu-efi-aarch64 2020.08-1
ii qemu-efi-arm 2020.08-1
pn qemu-system
ii qemu-utils1:5.1+dfsg-4+b1
pn schroot
ii vmdb2 0.19-1
-- no debconf information
