Bug#1022202: failed to validate module [usbserial] BTF: -22

[Brilliantov Kirill Vladimirovich]

Hello!
package linux-image-6.0.0-5-amd64 6.0.10-2
```
$ uname -r
6.0.0-5-amd64
```
At connect RS232-USB adapter dmesg contain follow lines
```
.
[  792.056242] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  792.056249] usb 1-2: Product: TTL232R-3V3
[  792.056255] usb 1-2: Manufacturer: FTDI
[  792.056260] usb 1-2: SerialNumber: FTHEC1HL
[  792.085092] BPF:  type_id=75 bits_offset=128
[  792.085106] BPF:
[  792.085111] BPF: Invalid name
[  792.085116] BPF:
[  792.085122] failed to validate module [usbserial] BTF: -22
[ 1372.750421] rmi4_f12 rmi4-00.fn12: Failed to read object data. Code: -6.
...
```

Bug#1013731: linux-image-5.10.0-13-amd64: 5.10.0-13-amd64 RTL8153 power management kernel hang

[Ian Turner]

On 12/6/22 03:43, Renato Gallo wrote:

have you tried with 6.0 ?
Can you clarify to whom your question is addressed? If to me, I haven't 
done any further troubleshooting since opening this issue.

Bug#1025730: initramfs-tools-core: configure_networking timeout causes entire init script to die

[Paul Aurich]

Package: initramfs-tools-core
Version: 0.142
Severity: normal

configure_networking tries to source /run/net-*.conf files at the end of its
run.  If the networking timed out, no files exist. If the shell is also dash,
the '.' operator failing to find any file to source causes the entire shell to
exit, regardless of 'set -e' or not.

Naturally, this causes problems since the calling init script is
unceremoniously killed off in the middle of execution. I'd prefer if the init
script continued running, so it has an opportunity to retry the networking or
take other actions.

(I've encountered a few circumstances where configure_networking times out
before the network and DHCP are functional after a power outage.)


Just a brief demonstration of the surprising-to-me(-and-of-course-documented)
behavior:

paul@haley ~ % cat repro.sh
#!/bin/sh

. /nonexistent
echo hello
paul@haley ~ % dash ./repro.sh
./repro.sh: 3: .: cannot open /nonexistent: No such file
paul@haley ~ % sh ./repro.sh
./repro.sh: 3: .: cannot open /nonexistent: No such file
paul@haley ~ % bash ./repro.sh
./repro.sh: line 3: /nonexistent: No such file or directory
hello
paul@haley ~ %


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages initramfs-tools-core depends on:
ii  coreutils9.1-1
ii  cpio 2.13+dfsg-7.1
ii  e2fsprogs1.46.6~rc1-1+b1
ii  klibc-utils  2.0.11-1
ii  kmod 30+20220905-1
ii  logsave  1.46.6~rc1-1+b1
ii  udev 252.2-2

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.35.0-4
ii  zstd 1.5.2+dfsg-1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.11-6

-- no debconf information

Bug#1019700: testing with 6.1 kernel

[Hank Barta]

On Wed, Dec 7, 2022 at 8:34 PM Hank Barta  wrote:

> I tested with the 6.1 kernel from testing.
>

The kernel was from experimental, not testing. Apologies for the error.

-- 
Beautiful Sunny Winfield

Bug#1019700: testing with 6.1 kernel

[Hank Barta]

I tested with the 6.1 kernel from testing.

hbarta@boson:~$ uname -a
Linux boson 6.1.0-0-arm64 #1 SMP Debian 6.1~rc7-1~exp1 (2022-12-01) aarch64
GNU/Linux
hbarta@boson:~$

The problem seems to be worse. It manifests with every cold boot (4 tries.)
I was only able to test one warm boot immediately following installation of
6.1 (and shutting down 6.0) and the issue manifested then also. I was
unable to further test warm boot because the system never completed
shutdown even after waiting 10 minutes. Inserting an SD card got the
following message (from dmesg)

[   46.858495] mmc1: new high speed SDIO card at address 0001

That message was followed by a single block from the timeout message
referencing mmc1 and which seemed not to be repeated. The /dev/ entry for
the SD card was never created.

Update: While composing this message it did complete a shutdown and reboot.
Unfortunately the SD card was (sort of) bootable and the system tried to
boot from it and hung, forcing a power cycle and cold boot. On this
subsequent cold boot the timeout did not manifest. A subsequent warm boot
also did not manifest. The third warm boot *did* manifest the timeout.

best,

-- 
Beautiful Sunny Winfield

Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.

[Hank Barta]

Hi Diederik,

This may not be the same bug. The one you referenced was provoked when the
SD card slot was empty and could be suppressed by putting a card in the
slot. Also that bug was fixed and the work around was no longer necessary.
The one I experienced could happen with the SD card in place and at various
times, the SD card would be recognized or would not be recognized (when a
card was in place and the timeout was reported.) Let me clarify the
situations I encountered while testing. Again, I performed testing while
booting from a USB connected SSD.

* Normal boot, no timeout reported and SD card recognized.
* Timeout reported following boot and SD card recognized and working.
* Timeout reported and SD card not recognized.

Repeating the boot process could result in any of the three conditions and
it did not seem to matter if a warm or cold boot was involved.

I have updated my test install to the 6.0 kernel, identified as

hbarta@boson:~$ uname -a
Linux boson 6.0.0-5-arm64 #1 SMP Debian 6.0.10-1 (2022-11-26) aarch64
GNU/Linux
hbarta@boson:~$

I rebooted and power cycled several times and was ready to declare this
fixed, but the most recent reboot is den=monstrating the issue - e.g. MMC
timeouts and no SD card in /dev. I inserted an SD card in the slot and the
timeout messages are continuing after the card is initialized.

[  274.788978] mmc1: new ultra high speed DDR50 SDHC card at address 
[  274.805432] mmcblk1: mmc1: SL16G 14.8 GiB
[  274.837154]  mmcblk1: p1 p2
[  281.828861] mmc0: Timeout waiting for hardware cmd interrupt.
[  281.836160] mmc0: sdhci:  SDHCI REGISTER DUMP ===
[  281.844122] mmc0: sdhci: Sys addr:  0x | Version:  0x9902
[  281.852082] mmc0: sdhci: Blk size:  0x | Blk cnt:  0x
[  281.860026] mmc0: sdhci: Argument:  0x0c00 | Trn mode: 0x
[  281.867973] mmc0: sdhci: Present:   0x01ff0001 | Host ctl: 0x0001
[  281.875905] mmc0: sdhci: Power: 0x000f | Blk gap:  0x
[  281.883839] mmc0: sdhci: Wake-up:   0x | Clock:0x7187
[  281.891779] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
[  281.899716] mmc0: sdhci: Int enab:  0x00ff0003 | Sig enab: 0x00ff0003
[  281.907658] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
[  281.915602] mmc0: sdhci: Caps:  0x | Caps_1:   0x
[  281.923543] mmc0: sdhci: Cmd:   0x341a | Max curr: 0x0001
[  281.931481] mmc0: sdhci: Resp[0]:   0x | Resp[1]:  0x
[  281.939414] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
[  281.947338] mmc0: sdhci: Host ctl2: 0x
[  281.953232] mmc0: sdhci: 

I'm not sure if this matters, but when the timeouts are reported, orderly
shutdown takes several minutes longer than normal but eventually completes.

best,


On Tue, Dec 6, 2022 at 6:10 PM Diederik de Haas 
wrote:

> Control: tag -1 moreinfo
>
> Hi Hank,
>
> On Tuesday, 13 September 2022 17:48:22 CET Hank Barta wrote:
> > Package: src:linux
> > Version: 5.19.6-1
> >
> >* What led up to the situation?
> >
> > Apparent inability to initialize/connect to the SD card H/W. This leads
> to
> > the message below that is repeated about every 10s. It can manifest three
> > ways.
> >
> > 1. Failure to boot - continuous retries to read SD card.
> > 2. If a USB SSD is connected, it can skip the SD card and boot from the
> SATA
> > SSD. (That is the coneition as I prepare this report.)
> > 3. Completes boot, message repeats and there are no /dev/mmc* entries and
> > WiFi H/W is not recognozed.
> > 4. Completes boot, messages are repeated but /dev/mmc entries are present
> > and can mount/read an SD card. And WiFi appears to be working
> > 5. Completes boot, no SD card timeout messages are reported and system
> > operates normally.
> >
> > ** Kernel log:
> > [  723.735217] mmc0: sdhci: Timeout:   0x | Int stat: 0x00018000
> > [  723.741743] mmc0: sdhci: Int enab:  0x00ff1003 | Sig enab: 0x00ff1003
> > [  723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001
> > [  723.754797] mmc0: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
> > [  723.761324] mmc0: sdhci: Cmd:   0x0502 | Max curr: 0x00080008
> > [  723.767851] mmc0: sdhci: Resp[0]:   0x01aa | Resp[1]:  0x
> > [  723.774379] mmc0: sdhci: Resp[2]:   0x | Resp[3]:  0x
> > [  723.780905] mmc0: sdhci: Host ctl2: 0x
> > [  723.785404] mmc0: sdhci: ADMA Err:  0x | ADMA Ptr: 0x
> > [  723.791930] mmc0: sdhci: 
> > [  733.923993] mmc0: Timeout waiting for hardware cmd interrupt.
> > [  733.929837] mmc0: sdhci:  SDHCI REGISTER DUMP ===
> > [  733.936364] mmc0: sdhci: Sys addr:  0x | Version:  0x1002
> > [  733.942892] mmc0: sdhci: Blk size:  0x | Blk cnt:  0x
> > [  733.949420] mmc0: sdhci: Argument:  0x | Trn mode: 

Processed: tagging 985002

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 985002 + upstream
Bug #985002 [nfs-common] nfs-common: Degraded system state if nfs-common 
installed and /etc/krb5.keytab present
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
985002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985002
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: bug 985002 is forwarded to https://lore.kernel.org/linux-nfs/20221207202841.525930-1-joachim.f...@gmx.de/T/#u

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 985002 
> https://lore.kernel.org/linux-nfs/20221207202841.525930-1-joachim.f...@gmx.de/T/#u
Bug #985002 [nfs-common] nfs-common: Degraded system state if nfs-common 
installed and /etc/krb5.keytab present
Set Bug forwarded-to-address to 
'https://lore.kernel.org/linux-nfs/20221207202841.525930-1-joachim.f...@gmx.de/T/#u'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
985002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985002
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: failed to insert STA entry for the AP (error -2)

[Cyril Brulebois]

Hallo Christoph,

Christoph Hellwig  (2022-12-07):
> It turns out that while d-i comes with the ath11k and ath11k_pci
> drivers, but misses the qrtr, qrtr-mki and michael_mic modules that
> are needed for the driver to actually work and not just load.

Reminds me of: https://bugs.debian.org/761902 which meant my wireless
adapter was happy with WEP but not WPA.

> Yes.  I'm not quite sure how the packages for d-i select which modules
> to include where, but given that other wifi hardware seems to work in
> the installer they must have figured this out somehow.

What modules end up in what udebs is decided in src:linux, under
debian/installer/modules.

Commit fixing the bug mentioned above:
  
https://salsa.debian.org/kernel-team/linux/-/commit/782d644da7ab74e04bfebd30b66c264654028da3


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: failed to insert STA entry for the AP (error -2)

[Christoph Hellwig]

Hi all,

adding the debian-kernel list due to issues with using debian-installer
daily snapshot to install on my brand new laptop with an ath11k_pci
supported wifi chip.

It turns out that while d-i comes with the ath11k and ath11k_pci
drivers, but misses the qrtr, qrtr-mki and michael_mic modules that
are needed for the driver to actually work and not just load.

On Wed, Dec 07, 2022 at 02:49:37PM +0200, Kalle Valo wrote:
> Thanks. But this makes me wonder is it sensible to randomly install a
> set of .ko files and drop the rest, like Debian's installer apparently
> does? The dependency for drivers is pretty well documented in Kconfig
> files, thanks to build testers testing with random configurations, but
> if the installer omits all that there will be problems just like you are
> experiencing. So for me MODULE_SOFTDEP() feels just like a band aid and
> not a robust solution.

I think a driver that a driver that has a runtime depedency on a
certain module, but doesn't import symbols is always going to be
somewhat problematic.  But I also agree that the arbitrary splitting
of kernel modules into separate packages for the installer, or
in fact not packaging them at all for the installer is rather
problematic.  I'm not sure what the rationale is behind that, but
I've added the debian-kernel and debian-boot lists.


> Though I am happy to take your MODULE_SOFTDEP() patch, just wondering if
> there is a better way to solve this. For example net/mac80211 (the
> 802.11 stack) has a lot of crypto dependencies:
> 
>   select CRYPTO
>   select CRYPTO_LIB_ARC4
>   select CRYPTO_AES
>   select CRYPTO_CCM
>   select CRYPTO_GCM
>   select CRYPTO_CMAC
>   select CRC32
> 
> And it's not using MODULE_SOFTDEP() at all.

Yes.  I'm not quite sure how the packages for d-i select which
modules to include where, but given that other wifi hardware
seems to work in the installer they must have figured this out
somehow.

Bug#1010482: marked as done (firmware-realtek: loss of wireless connection during use)

[Debian Bug Tracking System]

Your message dated Wed, 07 Dec 2022 14:57:08 +0100
with message-id <2094970.7ObL1VQbli@prancing-pony>
and subject line Re: Bug#1010482: firmware-realtek: loss of wireless connection 
during use
has caused the Debian Bug report #1010482,
regarding firmware-realtek: loss of wireless connection during use
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1010482: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010482
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-realtek
Version: 20210315-3
Severity: important

Dear Maintainer,

I installed Debian stable "bullseye" on my Lenovo T440S equiped with a Realtek 
8192EE 802.11n PCI wirelesscard.

As explained on the wiki, I installed firmware-realtek to use it and connect to 
my WiFi home network and use a Bluetooth mouse.

As a result, I managed to access the available wireless networks and connect to 
my own one. I also managed to connect and use my Buletooth mouse.

But once connected, I encounter a loss of my WiFi connection without being able 
to identify an event causing this.

The result of this loss is:
* I can't list any wireless network.
* In connman, but this is also the case with network-manager provided with 
Gnome as a default, the card appears to run correctly as I can activate or 
deactivate it. Doing so has no effect.
* In connman, my BT mouse is not visible anymore wherease it is still usable.
* In the Gnome tray menu, the WiFi icon is grayed. No network is available.
* In the Gnome tray menu, my BT mouse is visible.
* If I try to list the wireless networks available, the system keeps searching 
in vain.
* The only mean to get the connection back identified so far is to reboot. This 
is quite painfull.

My WiFi router is configured to use WPA and WPA2 mixed.

I tried to deactivate the power management but this had no effect.
root@uranus:~# iwconfig wlp3s0 power off

I also tried to add options, still no effect.
root@uranus:~# cat /etc/modprobe.d/rtl8192ee.conf 
options rtl8192ee ips=N fwlps=N

Here is my current state, as I plugged my cable to continue working:
root@uranus:~# lspci -nnkd ::0280
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8192EE 
PCIe Wireless Network Adapter [10ec:818b]
Subsystem: Realtek Semiconductor Co., Ltd. RTL8192EE PCIe Wireless 
Network Adapter [10ec:001b]
Kernel driver in use: rtl8192ee
Kernel modules: rtl8192ee
root@uranus:~# iwconfig wlp3s0 
wlp3s0IEEE 802.11  ESSID:off/any  
  Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm   
  Retry short limit:7   RTS thr=2347 B   Fragment thr:off
  Encryption key:off
  Power Management:on
root@uranus:~# nmcli device wifi 
IN-USE  BSSID  SSID  MODE  CHAN  RATE  SIGNAL  BARS  SECURITY 

root@uranus:~# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller 
[8086:0a04] (rev 0b)
00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT 
Integrated Graphics Controller [8086:0a16] (rev 0b)
00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller 
[8086:0a0c] (rev 0b)
00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC 
[8086:9c31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 
[8086:9c3a] (rev 04)
00:19.0 Ethernet controller [0200]: Intel Corporation Ethernet Connection 
I218-LM [8086:155a] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller 
[8086:9c20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 6 
[8086:9c1a] (rev e4)
00:1c.1 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 
[8086:9c14] (rev e4)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 
[8086:9c26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation 8 Series LPC Controller 
[8086:9c43] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series SATA Controller 1 
[AHCI mode] [8086:9c03] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series SMBus Controller [8086:9c22] 
(rev 04)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227 PCI 
Express Card Reader [10ec:5227] (rev 01)
03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8192EE 
PCIe Wireless Network Adapter [10ec:818b]

It seems this card is known to have issues with all Linux distros, but as I 
couldn't find a bug report describing this issue, here it is.

Many thanks for the great work, and thanks in advance for the help.

Clément

-- System 

Bug#1010482: firmware-realtek: loss of wireless connection during use

[Clément VERDET]

Hello,

The laptop I had bought, which was reconditionned, had another issue. 
Since it has been replaced I don't have anymore this issue and my WiFi 
connection is working well.


The bug report can be closed.

Best regards.

Clément

Bug#1024735: [klibc] klibc sh segfault on invalid substitutions

[Diederik de Haas]

On Wednesday, 7 December 2022 05:57:55 CET Christoph Anton Mitterer wrote:
> A patch has now been posted for dash at:
> https://lore.kernel.org/dash/y47zlpwkqy+ji...@gondor.apana.org.au/
> which is apparently scheduled to be merged into their git.

FTR: a v2 of that patch has been posted:
https://lore.kernel.org/dash/y5btwr28ngvmm...@gondor.apana.org.au/

signature.asc
Description: This is a digitally signed message part.