Package: src:linux
Version: 5.18.5-1
Severity: normal
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org
Dear Maintainer,
I do not expect a kernel module in a genuine Debian kernel package
taints a kernel. But I see the following message in dmesg on
Control: close -1
>> The severity seems now minor.
>> It has still the mysterious dmesg error on tpm as follows.
>> The full dmesg log is attached.
>
> Do you still have the issues? Otherwise let's close this bug.
No. Let's close this. Ryutaroh
Control: clone -1 -2
Control: reassign -2 clang-12 1:12.0.1-12
Control: retitle -2 -static-pie AND -fuse-ld=lld-12 produce unusable a.out
The same symptom appears with
clang-12 -static-pie AND -fuse-ld=lld-12
Best regards, Ryutaroh
Control: tags -1 + upstream
Control: forwarded -1 https://bugs.llvm.org/show_bug.cgi?id=52201
From: Sylvestre Ledru
> It seems an upstream issue, not a packaging issue.
> Could you please report this bug upstream?
Thank you for your quick response. I brought this to the upstream as above.
in _dl_relocate_static_pie ()
#1 0xf7f8663c in __libc_start_main ()
#2 0xf7f864b8 in _start ()
(gdb) info local
No symbol table info available.
(gdb) quit
A debugging session is active.
Inferior 1 [process 530049] will be killed.
Quit anyway? (y or n) y
Best regards, Ryutaroh Matsumoto
=undefined hello.c
$ ./a.out
hello world!
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental
, version 1 (GNU/Linux),
dynamically linked, BuildID[sha1]=8fb93260326c669fd2b80d0863ca0c536d425c19, for
GNU/Linux 3.7.0, not stripped
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates
'
/usr/bin/ld: read-only segment has dynamic relocations
collect2: error: ld returned 1 exit status
On the other hand, clang-13 can handle the same situation better as below:
$ clang-13 -static -fPIE -static-pie hello.c
$ ./a.out
hello world!
Best regards, Ryutaroh Matsumoto
-- System
-filesystems fails
Date: Thu, 19 Aug 2021 15:58:26 +0200,Thu, 19 Aug 2021 15:58:26 +0200
> Hi Ryutaroh Matsumoto,
>
> On 18 Nov 2020 12:57:40 +0900 Ryutaroh Matsumoto
>
> wrote:
>> Package: vmdb2
>> Version: 0.19-1
>> ...
>> ii qemu-utils 1:5.1+dfsg-4+b
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
regards, Ryutaroh Matsumoto
-- Package-specific info:
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'),
(1, 'experimental')
Architecture: arm64 (aarch64)
Kernel: Linux 5.10.0-6-arm64 (SMP w/4 CPU
Control: tags -1 + wontfix
> Not sure what I should do with this bug report (besides closing it).
You are welcome to close this.
It seems a bit strange that IPAccounting=yes is also accepted by
systemd user instance...
Sorry for my initial report not being much pointed...
Best regards, Ryutaroh
Control: retitle -1 IPAccounting=yes does not work for systemd-run --user
A real inconvenience of 986905 is that IPAccounting does not work for
any process under systemd --user by non-root. For example,
ryutaroh@raspi4b8gb:~$ systemd-run --user --scope --unit=test -p
"IPAccounting=yes" sh -c
Control: retitle -1 systemd user instance: Attaching egress BPF program to
cgroup failed with Invalid argument
> Currently, to trigger this issue, I need task-xfce-desktop (on every arch.).
> I believe that this can be reproduced without task-xfce-desktop,
> and will try to find a reproduction
> So you enabled "DefaultIPAccounting=yes" for the systemd --user
> instances (i.e. in user.conf) and only those systemd --user instances
> trigger that error?
Yes (on amd64, arm64 and armhf).
I do not see the error in the systemd PID 1
except on an armhf kernel with CONFIG_BPF_JIT_ALWAYS_ON=y.
Hi Michael, I failed to send my email to you:
> This reported symptom (986905) is also observed with Debian amd64,
> outside of a VM, with task-xfce-desktop installed and
> DefaultIPAccounting=yes in /etc/systemd/user.conf.
We do not need armhf to reproduce 986905.
> The systemd system instance
My reports have been wrong.
This reported symptom is also observed with Debian amd64, outside of a VM,
with task-xfce-desktop installed and
DefaultIPAccounting=yes in /etc/systemd/user.conf.
In
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986905#5
all the error messages are from systemd user
Hi,
a minimal procedure to reproduce this in armhf VM is as follows:
> Download d-i Alpha 3 for armhf.
> (The latest weekly build of d-i did not boot...)
* Start installer in VM with non-expert CUI mode.
* Install as you like with "standard packages" with Xfce desktop
(Instllation is painfully
Control: tags -1 - moreinfo
> Do you have instructions how I can reproduce this (on a amd64 box)?
I removed "moreinfo" tag. If the following is not enough, please attach the tag
again.
(Assuming "virt-manager" is acceptable)
In the following, lighdm display manager is somehow needed to
> Can you attach the output of
> grep BPF /boot/config-$(uname -r)
root@qemu-bullseye-armhf:~# uname -a
Linux qemu-bullseye-armhf 5.10.0-5-armmp-lpae #1 SMP Debian 5.10.26-1
(2021-03-27) armv7l GNU/Linux
root@qemu-bullseye-armhf:~# fgrep -nH BPF /boot/config-5.10.0-5-armmp-lpae
/sid.
See also
https://wiki.matoken.org/linux/issue
http://hidenosuke.org/diary/?date=20080213
Best regards, Ryutaroh Matsumoto
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
-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
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
Control: severity -1 minor
Startup failure of lightdm was caused by
GDM_BACKEND=wayland environment variable...
Installing accountsservice removes the error message
reported in #960329.
accountsservice is suggested by lightdm.
Upgrading "suggest" to "recommend" might be a good idea...
Sorry for
Control: severity -1 normal
I now think that failure of the startup of lightdm is
caused by something other than lightdm.
I keep investigating and lower the severity
until I get a clear picture of the symptom.
Best regards, Ryutaroh
4B.
All packages are pure Debian.
I hope this issue is fixed before the official Bullseye release.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'),
(1
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
rd.img-5.10.0-5-rt-arm64
disable_fw_kms_setup=1
disable_overscan=1
hdmi_enable_4kp60=1
Best regards, Ryutaroh Matsumoto
Hi Stefan, thank you for your response.
> i assume you set this option in the config.txt? This shouldn't have any
> affect for the mainline kernel / DT.
I am aware of that...
I did "snd_bcm2835 enable_hdmi=0" in /etc/modules.
"modinfo snd_bcm2835" shows as below. Doesn't it indicate snd_bcm2835
> I think the root cause of this issue is that both vc4.ko and snd_bcm2835.ko
> try to provide ALSA sinks to HDMI audio outputs from RPi.
> Why do the two drivers provide the same functionality for the same device?
> It seems nonsense.
> There must be some coordination between vc4.ko and
rovide different ALSA sinks of the same
device already causes another symptom as
http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008077.html
Best regards, Ryutaroh Matsumoto
From: Ryutaroh Matsumoto
Subject: vc4.ko brings unusable ALSA sinks
Date: Fri, 26 Mar 2021 17:15:40 +0900 (JST)
> Touching vc4-hdmi-[01] too many times makes the kernel unstable,
> and shutting down often needs several minutes.
> /usr/bin/pulseaudio in its default setting touches all
Control: notfound -1 20210208-4
#984844 is not observed in 20210208-4 in testing/Bullseye.
Ryutaroh
Control: reassign -1 firmware-brcm80211 20201218-3
Control: close -1 20210315-1
The symptom #984844 disappeared by upgrading firmware-brcm80211
from 20201218-3 to 20210315-1. Ryutaroh
Control: reopen -1
Control: forwarded -1
http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-March/008065.html
Control: found -1 5.10.24-1
Control: tags -1 + upstream
Sorry, #981616 still persists in 5.10.24-1.
For detail, please refer to
YLAND_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
Control: tags -1 + fixed-upstream
#985847 is fixed in upstream by
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798
Ryutaroh
confirmed that the symptom also appears with Firefox in Debian Bullseye.
This symptom does not happen with weston with Xwayland.
Related Ubuntu bug report at
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1896171
I wish some fix will be included in Bullseye Updates...
Best regards, Ryutaroh
Control: close -1 5.10.24-1
I recheck the situation with Debian kernel 5.10.24 and
Debian firmware-brcm80211 20201218-3.
5GHz WiFi works fine with vc4 and without vc4.
Debian package of firmware-brcm80211 newer than 20201218-3
has a severe issue with 5GHz WiFi as reported at
Control: found -1 20210315-1
> I will re-check 20210315-1.
The system boots with 20210315-1 and the reported symtom remains in
the same way. Ryutaroh
Hi Maximilian, thank you again for your response.
> but are you sure that these
> bootflags are still adequate for the latest cypress firmware?
What did you mean by "bootflags"??
Did you mean /proc/cmdline (i.e. cmdline.txt in Raspberry Pi)?
> concerning bluetooth unfortunately this seems
Control: tags -1 - moreinfo
Hi Maximilian, thank you for your attention!
> please provide info on the affected hardware,
It is Raspberry Pi 4B 8GB model.
> please show affected dmesg output working and non working,
> the difference between 20210208-3 20210208-4 is minimal,
> hence it should be
Package: firmware-brcm80211
Version: 20210315-1~exp1
Followup-For: Bug #985632
Dear Maintainer,
This reported symptom also exists in
20210315-1~exp1.
Best regards, Ryutaroh
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500,
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
[ 265.746311] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x
[ 265.749815] mmc1: sdhci: Host ctl2: 0x
[ 265.752234] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x
[ 265.755739] mmc1: sdhci:
Best regards, Ryutaroh Matsumoto
Control: forwarded -1 https://github.com/systemd/systemd/issues/19060
I brought #982929 to the upstream as above.
Best regards, Ryutaroh
Hi Michael,
Thanks again for your attention.
>> Architecture: arm64 (aarch64)
> Might be an issue of trying to execute armhf on a arm64 kernel.
It was an error in testsuites running on linux-image-armmp-lpae on
qemu-system-arm, so the above should not be the case.
> But I'm no expert on this
Control: reassign -1 initramfs-tools 0.139
Control: tags -1 + pending
#977694 is going to be fixed by the commit
https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/a930e9a448d807cd23632c095a45d48842ff2f24
Ryutaroh
Hi Lucas,
> According to strace, it fails because /dev/dri does not exist.
When vc4.ko is not loaded, /dev/dri does not exist.
If vc4.ko is loaded, /dev/dri exists. Could you make sure that
vc4.ko is loaded by "lsmod | fgrep vc4"?
vc4.ko was disabled at Debian kernel 5.10.9.
Other Debian 5.10.?
.
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
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
Hi again,
>> The stderr is recoreded to "test name"-stderr by autopkgtest.
>> But that file is empty...
>
> Yes, that only lists non-redirected stderr. Since output on stderr
> causes the autopkgtest to fail by default the output of most commands is
> already redirected to /dev/null
Sorry, I
Hi Bernhard,
>one of the easyrsa commands fails, and since we redirect stderr to
>/dev/null we are not seeing any error message. Could you drop the
>redirects and check the output?
The stderr is recoreded to "test name"-stderr by autopkgtest.
But that file is empty...
Best regards, Ryutaroh
Hi Ritesh,
CC: Debian init-system-helpers maintainers,
Thank you very much for spending your time on investigating this issue.
I wonder if this issue should also be assigned to init-system-helpers package
including deb-systemd-helper, for example, by the following commands
clone 983737 -1
011 R11: 0246 R12: 7ff6723a6e2d
[7.198839] R13: R14: 55ee813330b0 R15: 55ee81379020
[7.198841] ---[ end trace 763ec261f802618a ]---
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Linux version 5.10.0-4-am
> rrs@lenovo:~$ autopkgtest -B -U -u debci -o /tmp/multipath-tools-qemu
> multipath-tools -- qemu -d --show-boot -c 1 --ram-size=3072
> /var/lib/debci/qemu/sid-amd64.img
This should work...
You could try the same command by root, but
it should work under an ordinary user.
> Booting from Hard
> What should be the steps to reproduce this bug on my machine using
> debci/autopkgtest ?
(Assuming you are using Debian Bullseye amd64.)
# debci setup -f -b qemu -a amd64 -s sid
The above will create /var/lib/debci/qemu/sid-amd64.img
"debci setup" sometimes fails, in such a case please
>> while "apt-get install open-iscsi" never finishes when
>> /sbin/init==systemd-sysv.
> I guess you meant sysvinit in the latter case.
I was wrong... The latter should have been sysvinit-core...
> So can you please point me to what the actual problem with the package
> is, when run on a system
Hi Ritesh,
Thanks again for paying attention to my report.
> I see nothing wrong here. What is the output you expect ?
On the qemu default configuration by virt-manager in Bullseye,
"apt-get install open-iscsi" finishes with no problem when
/sbin/init==systemd-sysv,
while "apt-get install
ld finish
root@host:~# exit
Script done on 2021-03-01 08:43:48+09:00 [COMMAND_EXIT_CODE="100"]
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: amd64 (
=1
I suspect that "Rectrictions: needs-root" is forgotten in the test
specification.
The full log of autopkgtest is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstab
rver-setup-with-ca FAIL non-zero exit status 1
server-setup-with-static-key FAIL non-zero exit status 1
Inspection to log files does not give any useful cues to identify the
cuase of the test failure.
Full log of autopkgtest is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debi
Module zfs not found in directory /lib/modules/5.10.0-3-amd64
The full log of autopkgtest is also attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd
for man-db (2.9.4-1) ...
Processing triggers for libc-bin (2.31-9) ...
root@bullseye-gnome:/var/tmp/zfs# exit
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: am
> Sorry I meant
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15
Sorry again, the above is obsolete for the newest sysvinit-core.
A correct patch is as follows:
--- usr/share/sysvinit/inittab 2021-02-21 22:53:09.0 +0900
+++ /tmp/inittab.lxc2021-02-26 15:47:39.711010978
> Could you consider to apply the known patch at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706676
Sorry I meant
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695568#15
Best regards, Ryutaroh Matsumoto
?bug=706676
Best regards, Ryutaroh Matsumoto
I was told that autopkg test scripts should not assume that an ordinary user
can sudo at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983432#10
an.org/cgi-bin/bugreport.cgi?bug=983367#15
for src:gvfs and src:libnfs.
If /usr/share/debci/backends/qemu/customize.sh adds the user debci
to the group sudo, the above test failures should be worked around.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
A
> Other than the tests, does multipath-tools work proper for you ?
> From the logs you've shared, multipath does report to see the iSCSI
> LUNs. Now whether a proper map was created or not, is not clear from
> the logs.
I have seen no problems in bin. packages from src:multipath-tools.
I run
age for mycontainer
lxc-create: mycontainer: tools/lxc_create.c: main: 319 Failed to create
container mycontainer
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental
: Simon McVittie
Subject: Re: Bug#983367: gvfs: autopkg test always fails on qemu testbed
Date: Tue, 23 Feb 2021 08:39:16 +
> On Tue, 23 Feb 2021 at 11:20:49 +0900, Ryutaroh Matsumoto wrote:
>> I made an autopkg qemu testbed by debci setup -f -s sid -a amd64 -b qemu.
>> Then I run
Hi Ritesh Raj Sarraf,
Thank you for paying your attention to this.
> I skimmed into the logs but I'm not sure what failure is being referred
> to here.
I meant the below part in "log" file. Feel free to downgrade the severity
if you consider this as a false positive.
In the following, the actual
qemu-system-aarch64: terminating on signal 15 from pid 166611 (/usr/bin/python3)
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
FAIL non-zero exit status 1
This seems a bug in testsuite. The log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel
in postfix.
On the other hand, the testsuite always passes on the lxc testbed and
ci.debian.net.
If the maintainer considers this as a bug in autopkgtest, please reassign this.
The log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers tes
ed:
linux-image-5.10.0-3-amd64-unsigned linux-image-5.10.0-3-amd64-dbg
--
Ran 1 test in 0.543s
FAILED (failures=1)
This seems a real error.
The log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debi
from standard input or configure an askpass helper
sudo: a password is required
The log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture
header claims that
the size of partition table
tgtbasedmpaths FAIL non-zero exit status 1
Looking at the log, failure of tgtbasedmpaths seems a real error.
The log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT
ap 0.7.5-1 on
ci.debian.net is "PASS",
which is different from both of the above.
I am unsure if this is a duplicate of #983197 or #983186.
Test logs are attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (9
, please let me know.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; PREEMPT)
Locale
so I chose "important" severity.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.16-preempt (SMP w/12 CPU threads; P
le it fails on qemu testbed.
I believe they should produce the same result, and this seems an important bug.
Log is attached.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'expe
ed core.\n\n
Stack trace of thread 833:\n
#0 0xb6eba0e8 kill (libc.so.6 + 0x2a0e8)\n'
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
-- System I
Control: retitle -1 requesting scsi_debug.ko for arm64 helping
systemd autopkgtest
Lack of scsi_debug.ko is also observed for ppc64el.
Ryutaroh
The lack of scsci_debug.ko for arm64 also makes the autopkgtest-virt-qemu
testsuite fail with udisks2.
Ryutaroh
not found in directory
/lib/modules/5.10.0-3-arm64
I talked with Michael Biebl on
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/113#note_227958
he wondered if it is possible to enable scsi_debug on arm64
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Lin
lt;'EOF'
[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no
EOF
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binuti
I do not
observe #980980, and 5.10.12 seems presence of vc4.ko...
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Linux version 5.10.0-3-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.1) #1 SMP
Debian
lowered severity to normal.
This is an upstream issue.
It is being discussed at "linux-rpi-kernel" mailing list.
Best regards, Ryutaroh Matsumoto
.
The network is configured by systemd-networkd and wpa_supplicant,
but I observe the same issue with ifupdown and NetworkManager.
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Linux version 5.10.0-3-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1
Patches are incorporated into the 5.10-stable branch as
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/diff/queue-5.10/drm-vc4-correct-lbm-size-and-calculation.patch?id=138ad5c64ba368c5e077b8c178c47f12b29b8701
Control: close -1 5.10.9-1
When "reset-raspberrypi.ko" and "raspberrypi-cpufreq.ko"
are loaded by initramfs, linux-image-arm64/sid can be booted from
my buggy USB MSD 056e:6a13.
It seems mysterious, but anyway I'd like to close #979187.
Best regards, Ryutaroh Matsumoto
Control: close -1 5.16
975392 is fixed in 5.16.
Best regards, Ryutaroh Matsumoto
sue in src:linux, please reassign this back.
Best regards, Ryutaroh Matsumoto
Control: forwarded -1
http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-January/007985.html
Forwarded to the linux-rpi-kernel list. Ryutaroh
I found that
CONFIG_RESET_RASPBERRYPI=y
is enough to fix #979187, while
CONFIG_RESET_RASPBERRYPI=m
is not.
I will submit an MR to salsa. Ryutaroh
cepted by the relevant upstream
> maintainer
> (aside from necessary adjustments for an older kernel version) before being
> applied.
Best regards, Ryutaroh Matsumoto
ages.
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.10raspi4usb (SMP w/4 CPU threads)
Kernel taint flags:
1 - 100 of 377 matches
Mail list logo
