Bug#1067829: nfs-utils: FTBFS on arm{el,hf}: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]

[Thorsten Glaser]

Emanuele Rocca dixit:

>The attached patch by Vladimir Petko was sent upstream and fixes the
>FTBFS on armhf/armel.

The patch is catastrophically wrong.

+-  snprintf(flushtime, sizeof(flushtime), "%ld\n", now);
++  snprintf(flushtime, sizeof(flushtime), "%lld\n", now);

Change that to:

++  snprintf(flushtime, sizeof(flushtime), "%lld\n", (long long)now);

time_t is not guaranteed to be 64-bit (or even integer, by ISO C),
it must always be coerced into the expected type for printf.

Please forward this upstream as well.

Might as well want to check that flushtime is large enough, too.

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#1065698: update-initramfs: -k all stopped working

[Thorsten Glaser]

Package: initramfs-tools
Version: 0.142

The update-initramfs manpage documents -k all, and I know I used
that in Kubuntu hardy times several times, but it does not work
any longer, it just does nothing.

Calling without -k of course only updates the image for the current kernel.

Feel free to downgrade severity if needed.

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 2 root root 7.4M Mar  9 00:27 /boot/initrd.img-4.19.0-4-m68k
-rw-r--r-- 1 root root 5.3M Mar  9 04:21 /boot/initrd.img-6.6.15-m68k
-- /proc/cmdline
root=/dev/nfhd8p1 console=nfcon devtmpfs.mount=1 BOOT_IMAGE=vmlinux

-- resume
RESUME=none
-- /proc/filesystems
fuseblk
ext3
ext2
ext4

-- lsmod
Module  Size  Used by
evdev  16384  0
mac_hid12288  0
sg 20480  0
ext4  380928  1
crc16  12288  1 ext4
mbcache12288  1 ext4
jbd2   49152  1 ext4
crc32c_generic 12288  1
sd_mod 45056  0
t10_pi 12288  1 sd_mod
crc64_rocksoft 12288  1 t10_pi
crc64  16384  1 crc64_rocksoft
crc_t10dif 12288  1 t10_pi
crct10dif_generic  12288  1
crct10dif_common   12288  2 crct10dif_generic,crc_t10dif
pata_falcon12288  0
atari_scsi 20480  0
libata139264  1 pata_falcon

-- /etc/initramfs-tools/modules

-- /etc/kernel-img.conf
# Kernel Image management overrides
# See kernel-img.conf(5) for details
do_symlinks = No

-- /etc/initramfs-tools/initramfs.conf
MODULES=dep
BUSYBOX=auto
KEYMAP=n
COMPRESS=gzip
DEVICE=
NFSROOT=auto
RUNSIZE=10%
FSTYPE=auto

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- /sys/block
nfhd8
sda

-- mkinitramfs hooks
/etc/initramfs-tools/hooks/:

/usr/share/initramfs-tools/hooks:
early-rng-init-tools
fsck
keymap
klibc-utils
kmod
resume
thermal
udev
zz-busybox


-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 6.6.15-m68k
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages initramfs-tools depends on:
ii  initramfs-tools-core  0.142
ii  linux-base4.5

initramfs-tools recommends no packages.

Versions of packages initramfs-tools suggests:
pn  bash-completion  

-- no debconf information

Bug#627164: klibc-utils: ipconfig does not support IPv6 (was Re: ipconfig: fails to add default gateway)

[Thorsten Glaser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Dixi quod…

>>(I will probably have to see how I can rip ipconfig off initramfs-tools
>>and plug iproute2 in (YY! (NOT!)) since I also got a v6-only machine
>>and the “ip=” kernel parameter is Legacy IP-only. Unless both are solved
>>problems already. I could use v6 for this machine, too, if that would
>>be easier.)
>
>And that would be Debian #627164 from 2011.
>
>Damn, I guess this means I’ll have to hack this up myself, perhaps[…]

>(Adding this mostly for thread completeness, as the only thing of
>this that pertains to klibc would be lack of IPv6 support and lack
>of “onlink” flag support for a Legacy IP default route.)

I did it!

Extract the following shar archive into /etc/initramfs-tools/ first…

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
#   hooks/ipv6
#   scripts/init-top/ipv6
#   scripts/init-bottom/ipv6
#
echo x - hooks/ipv6
sed 's/^X//' >hooks/ipv6 << 'END-of-hooks/ipv6'
X#!/bin/sh
X
XPREREQ="dropbear klibc-utils zz-busybox"
Xprereqs() {
X   echo "$PREREQ"
X}
X
Xcase $1 in
X(prereqs)
X   prereqs
X   exit 0
X   ;;
Xesac
X
X. /usr/share/initramfs-tools/hook-functions
X
Xset -e
X
Xtest -x "$DESTDIR/bin/ipconfig" || {
X   echo >&2 "E: klibc ipconfig not found"
X   exit 1
X}
Xtest -x "$DESTDIR/bin/ip" || test -x "$DESTDIR/sbin/ip" || {
X   echo >&2 "E: ip(8), busybox or normal, not found"
X   exit 1
X}
X
Xmv "$DESTDIR/bin/ipconfig" "$DESTDIR/bin/ipconfig.klibc-dist"
Xcat >"$DESTDIR/bin/ipconfig" <<\EOSCRIPT
X#!/bin/sh
Xcase ${1}
${3}
${4} in
X(-t
-d
ipv6:*)
X   ;;
X(*)
X   echo >&2 "I: configuring something other than IPv6"
X   exec /bin/ipconfig.klibc-dist "$@"
X   exit 126
X   ;;
Xesac
Xset -e
Xecho >&2 "I: configuring IPv6"
X. /conf/param.conf
Xcase $ipv6_ra:$ipv6_if in
X([01]:?*)
X   ;;
X(*)
X   echo >&2 "E: cannot find IPv6 configuration"
X   exit 1
X   ;;
Xesac
Xtest -e "/proc/sys/net/ipv6/conf/$ipv6_if/accept_ra" || {
X   echo >&2 "E: cannot find interface for IPv6 configuration: $ipv6_if"
X   ( ( ip a | sed 's/^/N: /' >&3) 2>&1 | sed 's/^/E: /') >&2 3>&2
X   exit 1
X}
X
Xcat >"/run/net-$ipv6_if.conf" <>/conf/param.conf
Xecho $ipv6_ra >"/proc/sys/net/ipv6/conf/$ipv6_if/accept_ra"
X
Xip link set dev "$ipv6_if" up || {
X   echo >&2 E: could not enable interface
X   exit 1
X}
Xmaxwait=
Xwhile test x"$(cat "/sys/class/net/$ipv6_if/operstate")" != x"up"; do
X   if test x"$maxwait" = x"111"; then
X   echo >&2
X   echo >&2 'W: link still not up? continuing anyway :/'
X   maxwait=
X   break
X   else
X   test -n "$maxwait" || echo -n >&2 \
X   'I: waiting until link comes up or 15 seconds '
X   maxwait=1$maxwait
X   sleep 1
X   echo -n >&2 .
X   fi
Xdone
Xtest -z "$maxwait" || echo >&2 ' done'
Xif test -n "$ipv6_na"; then
X   ip -6 addr add "$ipv6_na" dev "$ipv6_if" || {
X   echo >&2 E: could not set up IP
X   exit 1
X   }
X   if ip -6 addr show dev "$ipv6_if" to "$ipv6_na" dadfailed >/dev/null 
2>&1; then
X   maxwait=
X   while test -n "$(ip -6 addr show dev "$ipv6_if" to "$ipv6_na" 
tentative)"; do
X   if test x"$maxwait" = x"111"; then
X   echo -n >&2 'timeout'
X   break
X   else
X   test -n "$maxwait" || echo -n >&2 \
X   'I: waiting for duplicate address detection 
'
X   maxwait=1$maxwait
X   sleep 1
X   echo -n >&2 .
X   fi
X   done
X   if test -z "$(ip -6 addr show dev "$ipv6_if" to "$ipv6_na" 
dadfailed)"; then
X   test -z "$maxwait" || echo >&2 ' done'
X   elif test -z "$maxwait"; then
X   echo >&2 'E: duplicate address detection FAILED!'
X   else
X   echo >&2 ' FAILED!'
X   fi
X   else
X   echo >&2 'W: busybox ip(8) cannot handle duplicate address 
detection'
X   sleep 1 # justin case
X   fi
Xfi
Xif test -n "$ipv6_gw"; then
X   ip -6 route replace default via "$ipv6_gw" dev "$ipv6_if" onlink || {
X   echo >&2 E: could not set up default route
X   exit 1
X   }
Xfi
Xtest -z "$ipv6_hn" || echo "$ipv6_hn" >/proc/sys/kernel/hostname
Xip addr show dev "$ipv6_if" | sed 's/^/N: /' >&2
Xip -6 route list | sed 's/^/N: /' >&2
Xecho >&2 I: IPv6 set up successfully
XEOSCRIPT
Xchmod 555 

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Thorsten Glaser]

Diederik de Haas dixit:

>So it was present on 5.9.0-2 (5.9.6-1), but no longer on 5.10.X?

Yes to the former, unsure to the latter.

>Do you want to keep the bug open for your other/original system?

If you’d rather not, I can keep a note on my TODO for when the
other system is back up, then reproduce and either unarchive or
let it rest, as I don’t have a timeframe for that.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Thorsten Glaser]

Diederik de Haas dixit:

>Is this issue still happening?

Good question. The system currently suffers from fan error and
I don’t have the tuits to repair it, so I switched to a different
X61 Thinkpad, for now.

>The firmware file iwlwifi-4965-2.ucode hasn't been updated since 2009-07-09,
>but maybe/hopefully the kernel deals better with it now?

Perhaps. On this different Thinkpad, I’m running bullseye and
don’t get the messages. iwl-related dmesg entries:

[   39.470604] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree:
[   39.484180] iwl4965: Copyright(c) 2003-2011 Intel Corporation
[   39.511132] iwl4965 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
control
[   39.536450] iwl4965 :03:00.0: Detected Intel(R) Wireless WiFi Link 
4965AGN, REV=0x4
[   39.606629] iwl4965 :03:00.0: device EEPROM VER=0x36, CALIB=0x5
[   39.620005] iwl4965 :03:00.0: Tunable channels: 13 802.11bg, 19 802.11a 
channels
[   39.701630] iwl4965 :03:00.0: firmware: direct-loading firmware 
iwlwifi-4965-2.ucode
[   39.715098] iwl4965 :03:00.0: loaded firmware version 228.61.2.24
[   39.729426] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs'

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs

[Thorsten Glaser]

On Fri, 10 Nov 2023, Sven Joachim wrote:

>|   'cp -n' and 'mv -n' now exit with nonzero status if they skip their
>|   action because the destination exists, and likewise for 'cp -i',

Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish
between error and declining to copy/move.

There is a good example in diff(1) for how to handle this better:
use distinct errorlevels for each case.

Michael, could you perhaps throw that upstream?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1043437: linux: report microcode upgrade *from* version as well

[Thorsten Glaser]

Package: src:linux
Version: 5.10.179-3
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de

I have this in dmesg:

[0.00] microcode: microcode updated early to revision 0xa4, date = 
2010-10-02

It would be very nice if this message also showed the revision *from*
which it was upgraded, so that info is available without going through
extra hoops to boot without µcode upgrade.


-- Package-specific info:
** Version:
Linux version 5.10.0-23-amd64 (debian-kernel@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 
Debian 5.10.179-2 (2023-07-14)

** Command line:
BOOT_IMAGE=/SDcardBoot/vmlinuz-5.10.0-23-amd64 
root=/dev/mapper/vg--cSD-lv--root ro net.ifnames=0 vga=792

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[cut, irrelevant]

** Model information
sys_vendor: LENOVO
product_name: 7674D67
product_version: ThinkPad X61
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 7NET30WW (1.11 )
board_vendor: LENOVO
board_name: 7674D67
board_version: Not Available

** Loaded modules:
cpuid
cpufreq_ondemand
fuse
tun
ctr
ccm
cpufreq_powersave
tp_smapi(OE)
thinkpad_ec(OE)
snd_hda_codec_analog
snd_hda_codec_generic
snd_hda_intel
i915
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
iwl4965
iwlegacy
snd_compress
soundwire_cadence
mac80211
snd_hda_codec
snd_hda_core
cfg80211
snd_hwdep
drm_kms_helper
soundwire_bus
thinkpad_acpi
snd_pcm
cec
pcmcia
evdev
ppdev
drm
libarc4
nvram
snd_timer
iTCO_wdt
ledtrig_audio
tpm_tis
yenta_socket
serio_raw
coretemp
intel_pmc_bxt
snd
pcspkr
rfkill
tpm_tis_core
iTCO_vendor_support
pcmcia_rsrc
watchdog
i2c_algo_bit
tpm
soundcore
pcmcia_core
sg
rng_core
parport_pc
parport
ac
acpi_cpufreq
button
ecb
aes_generic
libaes
crypto_simd
cryptd
glue_helper
xts
dm_crypt
dm_mod
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
sr_mod
cdrom
crct10dif_common
ata_generic
mmc_block
ehci_pci
ata_piix
sdhci_pci
uhci_hcd
cqhci
libata
ehci_hcd
sdhci
i2c_i801
psmouse
scsi_mod
i2c_smbus
mmc_core
usbcore
firewire_ohci
lpc_ich
firewire_core
crc_itu_t
e1000e
ptp
usb_common
pps_core
battery
video

** PCI devices:
not available

** USB devices:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 17ef:1000 Lenovo ThinkPad X6 UltraBase
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 0483:2016 STMicroelectronics Fingerprint Reader
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-5.10.0-23-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-23-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-23-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-3~deb11u5
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-23-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20210315-3
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,

Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

And:

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/qemu-arm-static...
Downloading separate debug info for /usr/bin/qemu-arm-static...
Reading symbols from 
/home/tglase/.cache/debuginfod_client/5a14d0155c981c94a528d6468ded2c203f1e1908/debuginfo...
(gdb) r
Starting program: /usr/bin/qemu-arm-static ./fstype --help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x77ff8700 (LWP 27273)]

Thread 1 "qemu-arm-static" received signal SIGSEGV, Segmentation fault.
0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) at 
./include/qemu/bswap.h:329
Download failed: Invalid argument.  Continuing without source file 
./b/user-static/./include/qemu/bswap.h.
329 ./include/qemu/bswap.h: No such file or directory.
(gdb) bt
#0  0x004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) 
at ./include/qemu/bswap.h:329
#1  0x0045c9ac in translator_lduw_swap (do_swap=false, pc=, env=0xcbed30)
at ./include/exec/translator.h:178
#2  arm_lduw_code (sctlr_b=false, addr=, env=0xcbed30) at 
../../target/arm/arm_ldst.h:44
#3  thumb_tr_translate_insn (dcbase=0x7fffdd50, cpu=) at 
../../target/arm/translate.c:9054
#4  0x004bc1e9 in translator_loop (ops=0xa7f180 , 
db=db@entry=0x7fffdd50,
cpu=cpu@entry=0xcb6a60, tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../accel/tcg/translator.c:103
#5  0x00463eb3 in gen_intermediate_code (cpu=cpu@entry=0xcb6a60,
tb=tb@entry=0x7fffe840 , 
max_insns=max_insns@entry=512)
at ../../target/arm/translate.c:9283
#6  0x00512d75 in tb_gen_code (cpu=cpu@entry=0xcb6a60, pc=3670264, 
cs_base=0, flags=1196288,
cflags=-16777216, cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
#7  0x004b4734 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, 
cpu=0xcb6a60)
at ../../accel/tcg/cpu-exec.c:414
#8  cpu_exec (cpu=cpu@entry=0xcb6a60) at ../../accel/tcg/cpu-exec.c:770
#9  0x00422608 in cpu_loop (env=env@entry=0xcbed30) at 
../../linux-user/arm/cpu_loop.c:237
#10 0x00402949 in main (argc=, argv=0x7fffe230, 
envp=)
at ../../linux-user/main.c:882
(gdb) info r
rax0x40d94000  1087979520
rbx0x7fffdd50  140737488346448
rcx0xd9a72814264104
rdx0xc64d6012995936
rsi0x3800f83670264
rdi0xcbed3013364528
rbp0x0 0x0
rsp0x7fffdc48  0x7fffdc48
r8 0xc64d6012995936
r9 0xc656e812998376
r100x0 0
r110x0 0
r120xcbed3013364528
r130x0 0
r140x0 0
r150x7fffdd50  140737488346448
rip0x4c5cb60x4c5cb6 
eflags 0x10246 [ PF ZF IF RF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) disas
Dump of assembler code for function cpu_lduw_code:
   0x004c5ca0 <+0>: movQWORD PTR fs:0xff58,0x1
   0x004c5cad <+13>:movesi,esi
   0x004c5caf <+15>:movrax,QWORD PTR [rip+0x79efa2]# 
0xc64c58 
=> 0x004c5cb6 <+22>:movzx  eax,WORD PTR [rax+rsi*1]
   0x004c5cba <+26>:movQWORD PTR fs:0xff58,0x0
   0x004c5cc7 <+39>:ret
End of assembler dump.


The content of rax (guest_base) looks legit:

$ cat /proc/27269/maps
0040-00401000 r--p  fd:00 2624234
/usr/bin/qemu-arm-static
00401000-0071e000 r-xp 1000 fd:00 2624234

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Hi Helge,

>Can you check if this patch fixes the problem:
>https://patchew.org/QEMU/mvmpm55qnno@suse.de/
>(linux-user: make sure brk(0) returns a page-aligned value,   from Andreas 
>Schwab)

I doubt it, klibc malloc uses mmap(2) normally.

(And given I tested it on a bullseye system, the mmap bug in the
bookworm kernel is also not applicable.)

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………

Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Thorsten Glaser]

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,
>which has multiple outstanding emulation bugs, some of which
>affecting klibc-built binaries especially, though this, since
>a statically linked mksh works, is probably an issue with how
>qemu-user handles .interp *shrug*

An interesting data point (here on a bullseye/amd64 system):

$ /usr/lib/klibc/bin/fstype --help
--help: No such file or directory
$ /lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so  /usr/lib/klibc/bin/fstype --help
Segmentation fault (core dumped)

So running the interpreter directly is already not supported.
I’m guessing that that is what qemu-user tries, though.

Wild shoot into the blue but maybe it helps…

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

[Thorsten Glaser]

retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks

venkata.p...@toshiba-tsip.com dixit:

>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ 
>http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
>qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>Segmentation fault
>```

Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
against klibc :/

My guess here is that it’s, as usual, the fault of qemu-user,
which has multiple outstanding emulation bugs, some of which
affecting klibc-built binaries especially, though this, since
a statically linked mksh works, is probably an issue with how
qemu-user handles .interp *shrug*

Since your one-stage debootstrap succeeds, can you not do the
remaining steps booting into the image-under-preparation and
run them there? Here, qemu-system-armhf should probably suffice.
I know, it’s just as a workaround, until the people in question
figure out why this happens.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1030673: klibc: [mips64el] struct stat mismatch

[Thorsten Glaser]

Source: klibc
Version: 2.0.11-1
Severity: serious
Justification: ABI issue on release architecture
Tags: patch

On 64-bit MIPS platforms, struct stat’s members st_{a,m,c}time{,nsec}
and following (st_blksize, st_blocks) are mislayouted. Upstream git
commit 12f259dda1ef59b5f1f2fb67631dcbf94c18c56c fixes this issue, but
I believe this should be in Debian ASAP, as it affects multiple klibc
tools as well as other software (mksh’s regression tests catch this
in bookworm/sid now).

Maybe it’s time for 2.0.12?

Thanks in advance,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1027325: /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh: inaccessible or not found

[Thorsten Glaser]

Package: linux-headers-5.10.0-20-common
Version: 5.10.158-2
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I think I reported the same thing against experimental some time ago,
but it now is a regression in stable. Building kernel modules shows:

tglase@tglase-edge:~/lnx/master/janz $ make
make -C '/lib/modules/5.10.0-20-amd64/build' M='/home/tglase/lnx/master/janz' 
modules
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-20-amd64'
W: /bin/sh: /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh: 
inaccessible or not found
W: /bin/sh: /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh: 
inaccessible or not found
  CC [M]  /home/tglase/lnx/master/janz/sch_janz.o
  CC [M]  /home/tglase/lnx/master/janz/sch_janzdbg.o
W: /bin/sh: /usr/src/linux-headers-5.10.0-20-common/scripts/pahole-flags.sh: 
inaccessible or not found
  MODPOST /home/tglase/lnx/master/janz/Module.symvers
  CC [M]  /home/tglase/lnx/master/janz/sch_janz.mod.o
  LD [M]  /home/tglase/lnx/master/janz/sch_janz.ko
  CC [M]  /home/tglase/lnx/master/janz/sch_janzdbg.mod.o
  LD [M]  /home/tglase/lnx/master/janz/sch_janzdbg.ko
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-20-amd64'



-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-20-amd64 (SMP w/3 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

Donald Buczek dixit:

> To be fair, this daemon doesn't use /proc/pid/stat for that, but 
> /proc/pid/comm

Yes, and that’s proper. The field in /proc/pid/stat is size-limited
and so not necessarily distinct.

> As /proc/pid/stat is also used in many places, it could as well use
> that to avoid code duplication or reuse data already read from the
> other source.

No, because the data in /stat is incomplete *and* anything using
it that would be affected by escaping was already broken.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1024811: Re: Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

Donald Buczek dixit:

>No, Escaping would break existing programs which parse the line by
>searching for the ')' from the right.

Huh? No!

The format is "(" + string + ") " after all, and only the string
part would get escaped.

The only visible change would be that programs containing a
whitespace character (and, ideally, a ‘(’) in their name would
be escaped, which are these that are currently broken anyway.
And perhaps backslashes, if you decide to encode unambiguous,
but given the field length limit, I don’t think that was ever
a goal (both because I suspect this file was intended to be
used to get a quick overview and therefore deliberately shortens
and because the full info is available elsewhere), so no need to
encode unambiguously.

>If some documentation suggests, that you can just parse it with scanf,
>the documentation should be corrected/improved instead.

No. Someone recently did a survey, and most code in existence splits
by whitespace. Fix the kernel bug instead.

>Are you referring to proc(5) "The fields, in order, with their proper
>scanf(3) format specifiers, are listed below" [1] or something else?

Yes.

>The referenced manual page is wrong in regard to the length, too. There
>is no 16 character limit to the field, because it can contain a
>workqueue task name, too:

Probably used to be cut off after 16. Go fix that in the manpage
then. But do fix the encoding kernel-side.

>In fact, if you start escaping now you might also break programs which
>rely on the current 64 character limit.

Just cut off at the end then, like I suspect was done at 16 bytes
initially.

Or strip whitespace and closing parenthesis if present instead
of encoding them, or replace them with a question mark.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

On Sat, 26 Nov 2022, Alexey Dobriyan wrote:

>/proc never escaped "comm" field of /proc/*/stat.

Yes, that’s precisely the bug.

>To parse /proc/*/stat reliably, search for '(' from the beginning, then
>for ')' backwards. Everything in between parenthesis is "comm".

That’s not guaranteed to stay reliable: fields can be, and have
been in the past, added, and new %s fields will break this. Do
not rely on it either.

>Everything else are numbers separated by spaces.

Currently, yes.

But the field is *clearly* documented as intended to be
parsable by scanf(3), which splits on white space. So the
Linux kernel MUST encode embedded whitespace so the
documented(!) access method works.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

superfluous environment variables

[Thorsten Glaser]

(this time with the correct address, sorry)

Hi,

I’ve noticed that sysvinit/sysv-rc start dæmons with a *lot* of
superfluous environment variables compared to manual invocation
with an environment cleaner of mine:

# cleanenv / env | sort
HOME=/
LC_ALL=C.UTF-8
PATH=/bin:/usr/bin:/sbin:/usr/sbin

I checked /proc//environ for (exemplarily) cron from bootup
and from a manual 'cleanenv / /etc/init.d/cron st{op,art}' and
found these:

--- e1  2022-12-12 18:02:21.549735648 +
+++ e2  2022-12-12 18:02:21.049737965 +
@@ -1,20 +1,5 @@
-BOOT_IMAGE=/vmlinuz-5.10.0-19-amd64
-CONSOLE=/dev/console
 HOME=/
-INIT_VERSION=sysvinit-2.96
 LANG=C.UTF-8
+LC_ALL=C.UTF-8
 PATH=/bin:/usr/bin:/sbin:/usr/sbin
-PREVLEVEL=N
-PWD=/
-RUNLEVEL=2
-SHELL=/bin/sh
-SHLVL=1
-TERM=linux
-VERBOSE=yes
 _=/sbin/start-stop-daemon
-drop_caps=
-init=/sbin/init
-ip=xxx.xxx.xxx.xx::xxx.xxx.xxx.1:255.255.255.0:.xx.xxx::off:xxx.xxx.xxx.xx:xxx.xxx.x.xx:xxx.xxx.xxx.xx
-previous=N
-rootmnt=/root
-runlevel=2

This means that, even for a manual invocation, these are added:

• LANG=C.UTF-8
• _=/sbin/start-stop-daemon

The former is set, but not exported, in /etc/default/locale and
therefore this is (probably) “as expected”, the second is from
the shell.

However, sysvinit at boot does extra things:

• The kernel commandline parameters are added:
  ‣ /proc/cmdline
BOOT_IMAGE, ip (but not the others!)
• The pid 1 environ is added, but I wonder at its contents;
  it seems to me that pid 1 is adding stuff over the kernel?
  ‣ HOME=/, PATH, PWD=/, SHLVL=1, TERM=linux, drop_caps=,
init=/sbin/init, rootmnt=/root
  ‣ I wouldn’t expect *anything* to ever export PWD, as that
makes no sense, and SHLVL is a GNU bash-specific thing
• Extra exports:
  ‣ CONSOLE, INIT_VERSION, PREVLEVEL, RUNLEVEL, SHELL,
VERBOSE, previous, runlevel
• PATH is not the same as in pid1 env, but that’s likely okay

I question a *lot* of these things. The kernel sets…

const char *envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };

… plus boot options (see near the end of the eMail).

The remainder is either set by init or, which occurred to me just
as I am writing this, the initrd… so I guess we probably should
include them in this discussion.

On my laptop:
# tr '\0' '\n' /dev/null | fgrep LC_CTYPE | sed 's/="\(.*\)"$/=\1/')
exec /usr/bin/env -i \
PATH=$p TZ=UTC ${lc:+"$lc"} \
DISPLAY="$DISPLAY" HOME="${HOME:-/}" TERM="${TERM:-vt100}" USER="${USER}" \
"$@"
-END cutting here may damage your screen surface-

The BSD version mostly differs in the definition of $p (adding
/usr/X11R6/bin).

Note how this uses a whitelist approach to environment filtering
instead of a blacklist approach. Given the kernel passes its
commandline (mostly) in the environment (unknown_bootoption in
init/main.c), this is needed at *some* point during boot, too.
AIUI all parameters are still available via /proc/cmdline anyway
so the only reason to keep things in the environment is if they
are part of an “interface” between caller and callee.

I only can think of one system at work I have ssh+root on that
runs systemd, and it’s a *buntu jammy system, but, for comparison,
the env of cron there is:

INVOCATION_ID=8420b4861ee34808a8eab08ee778191a
JOURNAL_STREAM=8:18703
LANG=de_DE.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SYSTEMD_EXEC_PID=414

So, rather cleaner and definitely a whitelist approach, though
I wonder whether the absence of HOME can be trouble or avoid it.

This means that individual services are prepared for this reduction
already, it’s only the init scripts and the init systems’ infra‐
structure that needs checking.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

superfluous environment variables

[Thorsten Glaser]

Hi,

I’ve noticed that sysvinit/sysv-rc start dæmons with a *lot* of
superfluous environment variables compared to manual invocation
with an environment cleaner of mine:

# cleanenv / env | sort
HOME=/
LC_ALL=C.UTF-8
PATH=/bin:/usr/bin:/sbin:/usr/sbin

I checked /proc//environ for (exemplarily) cron from bootup
and from a manual 'cleanenv / /etc/init.d/cron st{op,art}' and
found these:

--- e1  2022-12-12 18:02:21.549735648 +
+++ e2  2022-12-12 18:02:21.049737965 +
@@ -1,20 +1,5 @@
-BOOT_IMAGE=/vmlinuz-5.10.0-19-amd64
-CONSOLE=/dev/console
 HOME=/
-INIT_VERSION=sysvinit-2.96
 LANG=C.UTF-8
+LC_ALL=C.UTF-8
 PATH=/bin:/usr/bin:/sbin:/usr/sbin
-PREVLEVEL=N
-PWD=/
-RUNLEVEL=2
-SHELL=/bin/sh
-SHLVL=1
-TERM=linux
-VERBOSE=yes
 _=/sbin/start-stop-daemon
-drop_caps=
-init=/sbin/init
-ip=xxx.xxx.xxx.xx::xxx.xxx.xxx.1:255.255.255.0:.xx.xxx::off:xxx.xxx.xxx.xx:xxx.xxx.x.xx:xxx.xxx.xxx.xx
-previous=N
-rootmnt=/root
-runlevel=2

This means that, even for a manual invocation, these are added:

• LANG=C.UTF-8
• _=/sbin/start-stop-daemon

The former is set, but not exported, in /etc/default/locale and
therefore this is (probably) “as expected”, the second is from
the shell.

However, sysvinit at boot does extra things:

• The kernel commandline parameters are added:
  ‣ /proc/cmdline
BOOT_IMAGE, ip (but not the others!)
• The pid 1 environ is added, but I wonder at its contents;
  it seems to me that pid 1 is adding stuff over the kernel?
  ‣ HOME=/, PATH, PWD=/, SHLVL=1, TERM=linux, drop_caps=,
init=/sbin/init, rootmnt=/root
  ‣ I wouldn’t expect *anything* to ever export PWD, as that
makes no sense, and SHLVL is a GNU bash-specific thing
• Extra exports:
  ‣ CONSOLE, INIT_VERSION, PREVLEVEL, RUNLEVEL, SHELL,
VERBOSE, previous, runlevel
• PATH is not the same as in pid1 env, but that’s likely okay

I question a *lot* of these things. The kernel sets…

const char *envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };

… plus boot options (see near the end of the eMail).

The remainder is either set by init or, which occurred to me just
as I am writing this, the initrd… so I guess we probably should
include them in this discussion.

On my laptop:
# tr '\0' '\n' /dev/null | fgrep LC_CTYPE | sed 's/="\(.*\)"$/=\1/')
exec /usr/bin/env -i \
PATH=$p TZ=UTC ${lc:+"$lc"} \
DISPLAY="$DISPLAY" HOME="${HOME:-/}" TERM="${TERM:-vt100}" USER="${USER}" \
"$@"
-END cutting here may damage your screen surface-

The BSD version mostly differs in the definition of $p (adding
/usr/X11R6/bin).

Note how this uses a whitelist approach to environment filtering
instead of a blacklist approach. Given the kernel passes its
commandline (mostly) in the environment (unknown_bootoption in
init/main.c), this is needed at *some* point during boot, too.
AIUI all parameters are still available via /proc/cmdline anyway
so the only reason to keep things in the environment is if they
are part of an “interface” between caller and callee.

I only can think of one system at work I have ssh+root on that
runs systemd, and it’s a *buntu jammy system, but, for comparison,
the env of cron there is:

INVOCATION_ID=8420b4861ee34808a8eab08ee778191a
JOURNAL_STREAM=8:18703
LANG=de_DE.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SYSTEMD_EXEC_PID=414

So, rather cleaner and definitely a whitelist approach, though
I wonder whether the absence of HOME can be trouble or avoid it.

This means that individual services are prepared for this reduction
already, it’s only the init scripts and the init systems’ infra‐
structure that needs checking.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.

[Thorsten Glaser]

severity 1017760 normal
retitle 1017760 linux: possible data corruption on µSD card, might be the 
hardware though?
thanks

Dixi quod…

>I have somewhat reason to at least suspect the µSD card this was
>installed on. But there was never anything in syslog/dmesg about
>it, so the Linux kernel clearly didn’t find fault with it at all.

I now have reasonable reason to suspect not the µSD card itself,
or, at least, not alone, but the µSD-to-SD adapter. One noname
behaved even worse, a different brand to the original one seems
to behave better.

>Suggestions how I can prove/disprove this welcome; I now swapped

Still that.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#930522: linux: task md5_raid6:203 blocked for more than 120 seconds

[Thorsten Glaser]

close 930522
thanks

Salvatore Bonaccorso dixit:

>Is this issue still reproducible with a recent kernel?

I haven’t seen it in a while, indeed.

Bug#1024819: linux-headers-amd64: causes apt-listchanges error

[Thorsten Glaser]

Package: linux-headers-amd64
Version: 6.0.8+1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de

apt-listchanges: Reading changelogs...
Calling ['apt-get', '-qq', 'changelog', 'linux-headers-amd64=6.0.8+1'] to 
retrieve changelog
apt-listchanges: Unable to retrieve changelog for package linux-headers-amd64; 
'apt-get changelog' failed with: E: Version '6.0.8+1' for 'linux-headers-amd64' 
was not found
E: No packages found

Unsure where to best report this…

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-headers-amd64 depends on:
ii  linux-headers-6.0.0-3-amd64  6.0.7-1

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

-- no debconf information

Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

Dixi quod…

>The effect is that /proc/[pid]/stat cannot be parsed the way it is
>documented, as it does not escape embedded whitespace characters;

… nor parenthesēs:

tglase@x61w:~ $ ./mk\)sh -c 'echo $$; sleep 10' &
[1] 13375
tglase@x61w:~ $ 13375
tglase@x61w:~ $ cat /proc/13375/stat
13375 (mk)sh) S 13330 13375 13330 34837 13377 4194304 124 0 0 0 0 0 0 0 20 0 1 
0 59029474 2977792 180 18446744073709551615 94911056490496 94911056739789 
140721459110048 0 0 0 0 0 134307847 0 0 0 17 1 0 0 0 0 0 94911056765744 
94911056773808 94911059955712 140721459115917 140721459115946 140721459115946 
140721459118064 0

This is… sad — extremely so. It does not escape anything.
I found proc_task_name(), which has an escape parameter,
which is set to false here, but it’s only for /status
which must escape newlines.

It’s used with false in /stat and /comm… the latter indeed
needing no escapes.

I’d argue that it needs a tristate argument, 0 for /comm
to not escape anything, 1 for /status to escape newlines,
and 2 for /stat to escape whitespace (and perhaps also a
closing parenthesis, using \x29, so splitting both using
scanf as indicated in the manpage and using parenthesēs
as people seem to do on the ’net is fixed).

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

Package: src:linux
Version: 5.10.149-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de, adobri...@gmail.com

tglase@x61w:~ $ cp /bin/mksh mk\ sh
tglase@x61w:~ $ ./mk\ sh -c 'echo $$; sleep 10' &
[1] 12862
tglase@x61w:~ $ 12862
cat /proc/12862/stat
12862 (mk sh) S 12649 12862 12649 34838 12864 4194304 124 0 0 0 0 0 0 0 20 0 1 
0 58970609 2977792 211 18446744073709551615 93898845827072 93898846076365 
140724844598496 0 0 0 0 0 134307847 0 0 0 17 0 0 0 0 0 0 93898846102320 
93898846110384 93898853036032 140724844603277 140724844603306 140724844603306 
140724844605424 0
tglase@x61w:~ $ cat /proc/12862/stat | hd
  31 32 38 36 32 20 28 6d  6b 20 73 68 29 20 53 20  |12862 (mk sh) S |
[…]

This directly violates the documentation of proc(5) which says…

  The  fields,  in order, with their proper scanf(3) format speci‐
  fiers, are listed below.  Whether or not certain of these fields

… while scanf(3) indicates:

   s  Matches  a  sequence  of  non-white-space  characters;  the next

The effect is that /proc/[pid]/stat cannot be parsed the way it is
documented, as it does not escape embedded whitespace characters;
this, as a result, makes this file realistically useless and anything
relying on it broken.

-- Package-specific info:
** Version:
Linux version 5.10.0-19-amd64 (debian-kernel@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 
Debian 5.10.149-2 (2022-10-21)

** Command line:
BOOT_IMAGE=/SDcardBoot/vmlinuz-5.10.0-19-amd64 
root=/dev/mapper/vg--cSD-lv--root ro net.ifnames=0 vga=792

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 7673AG4
product_version: ThinkPad X61
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 7NET30WW (1.11 )
board_vendor: LENOVO
board_name: 7673AG4
board_version: Not Available

** Loaded modules:
cdc_acm
apple_mfi_fastcharge
fuse
cpufreq_ondemand
tun
ctr
ccm
cpufreq_powersave
snd_hda_codec_analog
snd_hda_codec_generic
snd_hda_intel
i915
snd_intel_dspcfg
soundwire_intel
soundwire_generic_allocation
snd_soc_core
iwl4965
iwlegacy
snd_compress
soundwire_cadence
mac80211
snd_hda_codec
coretemp
snd_hda_core
kvm_intel
snd_hwdep
drm_kms_helper
cfg80211
kvm
soundwire_bus
thinkpad_acpi
cec
snd_pcm
pcmcia
drm
iTCO_wdt
nvram
snd_timer
ppdev
ledtrig_audio
intel_pmc_bxt
libarc4
snd
evdev
yenta_socket
i2c_algo_bit
soundcore
rfkill
iTCO_vendor_support
irqbypass
pcmcia_rsrc
watchdog
parport_pc
pcmcia_core
serio_raw
pcspkr
sg
parport
ac
acpi_cpufreq
button
ecb
aes_generic
libaes
crypto_simd
cryptd
glue_helper
xts
dm_crypt
dm_mod
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
mmc_block
crct10dif_common
ata_generic
ahci
ata_piix
sdhci_pci
libahci
cqhci
ehci_pci
uhci_hcd
libata
e1000e
scsi_mod
ehci_hcd
sdhci
i2c_i801
i2c_smbus
psmouse
lpc_ich
mmc_core
usbcore
ptp
usb_common
pps_core
battery
video

** PCI devices:
not available

** USB devices:
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 17ef:1000 Lenovo ThinkPad X6 UltraBase
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-5.10.0-19-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-19-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-19-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.06-3~deb11u4
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-19-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20210315-3
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  

Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.

[Thorsten Glaser]

Thorsten Glaser dixit:

>I’ve recently been getting filesystem corruption on this system, which,
>incidentally, is a fresh-ish installation since I’ve been hit by the

I have somewhat reason to at least suspect the µSD card this was
installed on. But there was never anything in syslog/dmesg about
it, so the Linux kernel clearly didn’t find fault with it at all.

Suggestions how I can prove/disprove this welcome; I now swapped
the filesystem contents to a new fs on a new µSD card, so tests
that are destructive can be done, but they need to be doable from
a Grml live ISO and should be doable overnight (i.e. not block
the system for too long).

Thanks in advance,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (416 (445) bugs: 0 RC, 282 (302) I, 134 (143) M, 0 F) + 207
‣ src:dash (94 (109) bugs: 0 RC, 52 (55) I, 42 (54) M, 0 F) + 63 ubu
‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F)
dash has two RC bugs they just closed because they don’t care about quality…

Bug#1019107: linux-image-5.10.0-17-amd64: iwl4965: Hardware became unavailable during restart.

[Thorsten Glaser]

Package: src:linux
Version: 5.10.136-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

My network just ceased working, and I can’t get it back up,
even with rmmod.

More log follows. Notes (more inline):

• those “Microcode SW error detected” seem to be normal,
  I’m getting those all the time (but please fix if possible)
• I did not use the ifb devices, just modprobed it to see if
  Debian ships the LKM

Sep  4 01:17:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:27:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:37:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:47:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 01:57:41 x61w wpa_supplicant[1764]: wlan0: WPA: Group rekeying completed 
with 38:10:d5:48:ea:c0 [GTK=TKIP]
Sep  4 02:01:16 x61w vmunix: [1306377.643847] iwl4965 :03:00.0: Microcode 
SW error detected.  Restarting 0x8200.
Sep  4 02:01:16 x61w vmunix: [1306377.643872] iwl4965 :03:00.0: Loaded 
firmware version: 228.61.2.24
Sep  4 02:01:16 x61w vmunix: [1306377.643909] iwl4965 :03:00.0: Start IWL 
Error Log Dump:
Sep  4 02:01:16 x61w vmunix: [1306377.643921] iwl4965 :03:00.0: Status: 
0x000213E4, count: 5
Sep  4 02:01:16 x61w vmunix: [1306377.644417] iwl4965 :03:00.0: Desc
  Time   data1  data2  line
Sep  4 02:01:16 x61w vmunix: [1306377.644429] iwl4965 :03:00.0: 
NMI_INTERRUPT_WDG(0x0004) 2996016142 0x0002 0x0243 208
Sep  4 02:01:16 x61w vmunix: [1306377.644435] iwl4965 :03:00.0: pc  
blink1  blink2  ilink1  ilink2  hcmd
Sep  4 02:01:16 x61w vmunix: [1306377.64] iwl4965 :03:00.0: 0x0046C 
0x04BE0 0x004C2 0x006DE 0x04C7C 0x218001C
Sep  4 02:01:16 x61w vmunix: [1306377.644451] iwl4965 :03:00.0: FH register 
values:
Sep  4 02:01:16 x61w vmunix: [1306377.644474] iwl4965 :03:00.0:   
FH49_RSCSR_CHNL0_STTS_WPTR_REG: 0X107cea00
Sep  4 02:01:16 x61w vmunix: [1306377.644498] iwl4965 :03:00.0:  
FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0102c310
Sep  4 02:01:16 x61w vmunix: [1306377.644520] iwl4965 :03:00.0: 
   FH49_RSCSR_CHNL0_WPTR: 0X00f0
Sep  4 02:01:16 x61w vmunix: [1306377.644541] iwl4965 :03:00.0:   
FH49_MEM_RCSR_CHNL0_CONFIG_REG: 0X80809000
Sep  4 02:01:16 x61w vmunix: [1306377.644565] iwl4965 :03:00.0:
FH49_MEM_RSSR_SHARED_CTRL_REG: 0X003c
Sep  4 02:01:16 x61w vmunix: [1306377.644587] iwl4965 :03:00.0:  
FH49_MEM_RSSR_RX_STATUS_REG: 0X0243
Sep  4 02:01:16 x61w vmunix: [1306377.644609] iwl4965 :03:00.0:   
FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
Sep  4 02:01:16 x61w vmunix: [1306377.644631] iwl4965 :03:00.0: 
 FH49_TSSR_TX_STATUS_REG: 0X07ff0002
Sep  4 02:01:16 x61w vmunix: [1306377.644658] iwl4965 :03:00.0: 
  FH49_TSSR_TX_ERROR_REG: 0X
Sep  4 02:01:16 x61w vmunix: [1306377.646845] iwl4965 :03:00.0: Can't stop 
Rx DMA.
Sep  4 02:01:16 x61w vmunix: [1306377.646932] ieee80211 phy0: Hardware restart 
was requested
Sep  4 02:01:31 x61w vmunix: [1306392.681230] iwl4965 :03:00.0: Microcode 
SW error detected.  Restarting 0x8200.
Sep  4 02:01:31 x61w vmunix: [1306392.681245] iwl4965 :03:00.0: Loaded 
firmware version: 228.61.2.24
Sep  4 02:01:31 x61w vmunix: [1306392.681270] iwl4965 :03:00.0: Start IWL 
Error Log Dump:
Sep  4 02:01:31 x61w vmunix: [1306392.681278] iwl4965 :03:00.0: Status: 
0x000213E4, count: 5
Sep  4 02:01:31 x61w vmunix: [1306392.681451] iwl4965 :03:00.0: Desc
  Time   data1  data2  line
Sep  4 02:01:31 x61w vmunix: [1306392.681462] iwl4965 :03:00.0: 
NMI_INTERRUPT_WDG(0x0004) 3011053406 0x0002 0x0243 208
Sep  4 02:01:31 x61w vmunix: [1306392.681469] iwl4965 :03:00.0: pc  
blink1  blink2  ilink1  ilink2  hcmd
Sep  4 02:01:31 x61w vmunix: [1306392.681477] iwl4965 :03:00.0: 0x0046C 
0x04BE0 0x004C2 0x006DE 0x04C84 0x296001C
Sep  4 02:01:31 x61w vmunix: [1306392.681484] iwl4965 :03:00.0: FH register 
values:
Sep  4 02:01:31 x61w vmunix: [1306392.681507] iwl4965 :03:00.0:   
FH49_RSCSR_CHNL0_STTS_WPTR_REG: 0X107cea00
Sep  4 02:01:31 x61w vmunix: [1306392.681529] iwl4965 :03:00.0:  
FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0102c310
Sep  4 02:01:31 x61w vmunix: [1306392.681552] iwl4965 :03:00.0: 
   FH49_RSCSR_CHNL0_WPTR: 0X0020
Sep  4 02:01:31 x61w vmunix: [1306392.681573] iwl4965 :03:00.0:   
FH49_MEM_RCSR_CHNL0_CONFIG_REG: 0X80809000
Sep  4 02:01:31 x61w vmunix: [1306392.681595] iwl4965 :03:00.0:
FH49_MEM_RSSR_SHARED_CTRL_REG: 0X003c
Sep  4 02:01:31 x61w vmunix: [1306392.681652] iwl4965 :03:00.0:  
FH49_MEM_RSSR_RX_STATUS_REG: 

Bug#987116: Backport of firmware-iwlwifi (20210818-1) to fix major Bluetooth issue

[Thorsten Glaser]

On Wed, 31 Aug 2022, S. wrote:

> laptop. It would be great if the 20210818-1 firmware version could be offered
> in Backports.

Backports are not to fix bugs in stable. Issues like this should
be fixed via the normal stable channels if possible and the normal
bugtracker is used to track that.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1018002: linux: Skipping BTF generation for /my/own/lkm.ko due to unavailability of vmlinux

[Thorsten Glaser]

Package: linux-headers-5.19.0-trunk-amd64
Version: 5.19-1~exp1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

In building an out-of-tree kernel module I wrote on 5.19 (to test
compatibility), I noticed a new error message.

/usr/lib/linux-kbuild-5.19/scripts/Makefile.modfinal emits the
message, and an inserted pwd;ls -l shows that the command looks
for existence of a “vmlinux” file (or symlinked) in its cwd
/usr/src/linux-headers-5.19.0-trunk-amd64 which belongs to the
linux-headers-*-$arch package.

sudo ln -s /boot/vmlinuz-5.19.0-trunk-amd64 
/usr/src/linux-headers-5.19.0-trunk-amd64/vmlinux
brings me further. I now also have to install the pahole package,
which probably needs to be depended on by linux-kbuild-5.19 now,
but then I get:

libbpf: failed to get EHDR from vmlinux
Failed to parse base BTF 'vmlinux': -4001

What am I still missing?

Are these BTF files supposed to be generated for out-of-tree
modules in the first place? If not, I suggest skipping the
  BTF [M] /my/own/lkm.ko
and the error message altogether instead.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-headers-5.19.0-trunk-amd64 depends on:
ii  linux-compiler-gcc-11-x86  5.18.5-1
ii  linux-headers-5.19.0-trunk-common  5.19-1~exp1
ii  linux-kbuild-5.19  5.19-1~exp1

linux-headers-5.19.0-trunk-amd64 recommends no packages.

linux-headers-5.19.0-trunk-amd64 suggests no packages.

-- no debconf information

Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.

[Thorsten Glaser]

Package: src:linux
Version: 5.10.136-1
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: t...@mirbsd.de

I’ve recently been getting filesystem corruption on this system, which,
incidentally, is a fresh-ish installation since I’ve been hit by the
“forgot LUKS password for the main SSD” problem.

This also happened with 5.10.0-14-amd64, but I think not earlier. It
occasionally happens after some amount of uptime and hits random
directories apparently.


-- Package-specific info:
** Version:
Linux version 5.10.0-17-amd64 (debian-kernel@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 
Debian 5.10.136-1 (2022-08-13)

** Command line:
BOOT_IMAGE=/SDcardBoot/vmlinuz-5.10.0-17-amd64 
root=UUID=d7cfc3b2-8733-481c-9fcc-7de4d41a13d6 ro net.ifnames=0

** Not tainted

** Kernel log:
[119729.028638] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[119729.030412] iwl4965 :03:00.0: Can't stop Rx DMA.
[119729.030518] ieee80211 phy0: Hardware restart was requested
[120028.870081] iwl4965 :03:00.0: Microcode SW error detected.  Restarting 
0x8200.
[120028.870091] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[120028.870112] iwl4965 :03:00.0: Start IWL Error Log Dump:
[120028.870117] iwl4965 :03:00.0: Status: 0x000213E4, count: 5
[120028.870302] iwl4965 :03:00.0: Desc  
Time   data1  data2  line
[120028.870309] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 
4055082994 0x0002 0x0243 208
[120028.870314] iwl4965 :03:00.0: pc  blink1  blink2  ilink1  ilink2  
hcmd
[120028.870320] iwl4965 :03:00.0: 0x0046C 0x04BE0 0x004C2 0x006DE 0x04C7C 
0x27F001C
[120028.870324] iwl4965 :03:00.0: FH register values:
[120028.870344] iwl4965 :03:00.0:   FH49_RSCSR_CHNL0_STTS_WPTR_REG: 
0X10606300
[120028.870364] iwl4965 :03:00.0:  FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 
0X01060620
[120028.870383] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 
0X0008
[120028.870402] iwl4965 :03:00.0:   FH49_MEM_RCSR_CHNL0_CONFIG_REG: 
0X80809000
[120028.870422] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 
0X003c
[120028.870441] iwl4965 :03:00.0:  FH49_MEM_RSSR_RX_STATUS_REG: 
0X0243
[120028.870460] iwl4965 :03:00.0:   FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 
0X
[120028.870479] iwl4965 :03:00.0:  FH49_TSSR_TX_STATUS_REG: 
0X07ff0002
[120028.870498] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[120028.872274] iwl4965 :03:00.0: Can't stop Rx DMA.
[120028.872340] ieee80211 phy0: Hardware restart was requested
[121081.667715] iwl4965 :03:00.0: Microcode SW error detected.  Restarting 
0x8200.
[121081.667739] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[121081.667951] iwl4965 :03:00.0: Start IWL Error Log Dump:
[121081.667959] iwl4965 :03:00.0: Status: 0x000213E4, count: 5
[121081.668140] iwl4965 :03:00.0: Desc  
Time   data1  data2  line
[121081.668151] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 
0812904774 0x0002 0x0243 208
[121081.668158] iwl4965 :03:00.0: pc  blink1  blink2  ilink1  ilink2  
hcmd
[121081.668166] iwl4965 :03:00.0: 0x0046C 0x04BE0 0x004C2 0x006DE 0x04C7C 
0x298001C
[121081.668173] iwl4965 :03:00.0: FH register values:
[121081.668195] iwl4965 :03:00.0:   FH49_RSCSR_CHNL0_STTS_WPTR_REG: 
0X10606300
[121081.668218] iwl4965 :03:00.0:  FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 
0X01060620
[121081.668240] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 
0X0020
[121081.668260] iwl4965 :03:00.0:   FH49_MEM_RCSR_CHNL0_CONFIG_REG: 
0X80809000
[121081.668279] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 
0X003c
[121081.668302] iwl4965 :03:00.0:  FH49_MEM_RSSR_RX_STATUS_REG: 
0X0243
[121081.668324] iwl4965 :03:00.0:   FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 
0X
[121081.668347] iwl4965 :03:00.0:  FH49_TSSR_TX_STATUS_REG: 
0X07ff0002
[121081.668367] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[121081.670429] iwl4965 :03:00.0: Can't stop Rx DMA.
[121081.670535] ieee80211 phy0: Hardware restart was requested
[125434.083155] wlan0: deauthenticating from 38:10:d5:48:ea:c0 by local choice 
(Reason: 3=DEAUTH_LEAVING)
[128369.139128] e1000e :00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, 
Flow Control: Rx/Tx
[128369.139255] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO
[128369.139340] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[135660.818236] e1000e :00:19.0 eth0: NIC Link is Down
[135662.403058] e1000e :00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, 
Flow Control: Rx/Tx
[135662.403180] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>I proposed my patch to expedite things and (much) prefer that Thorsten would

I’m not the author…

>I can do it, but I would like Thorsten to test the patch and confirm it

It’s obviously correct, it moves the nil check to the correct place.

I tested “the reverse” by doing…

@@ -1275,11 +1275,12 @@ static void htb_destroy_class(struct Qdisc *sch, struct 
htb_class *cl)
WARN_ON(!cl->leaf.q);
 #if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 20, 0)) && \
 (!defined(JENS_LINUX_4_19_SL) || (JENS_LINUX_4_19_SL < 221))
qdisc_destroy(cl->leaf.q);
 #else
-   qdisc_put(cl->leaf.q);
+   if (cl->leaf.q)
+   qdisc_put(cl->leaf.q);
 #endif
}
gen_kill_estimator(>rate_est);
tcf_block_put(cl->block);
kfree(cl);

… so the net effect is tested.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>I'm talking here about 4.9, not 4.19 ...

Ah sorry, I can’t keep them distinguished in my head apparently, or
it’s too hot…

>> $ git tag --contains 92833e8b5db6
>> v4.19.221
>> […]
>
>Thanks for that command :-) I usually went through several manual steps to 
>figure out in which release(s) a certain commit was. This is much quicker!

There is also git branch --contains. HTH ☺

>But as said before, I'm going to leave it up to the maintainers on the best 
>way to go about fixing this issue.

Right.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>In branch 'linux-4.9.y' there is no qdisc_put function, so the above check 
>seems rightly in qdisc_destroy there.

Not any more. Since…

$ git tag --contains 92833e8b5db6
v4.19.221
[…]

… qdisc_destroy was renamed to qdisc_put in 4.19, breaking modules (grr).

So yes, this needs to also be fixed upstream (hence me including that tag
when reporbugging), but perhaps Debian can quickfix.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Control: tag -1 - moreinfo

Diederik de Haas dixit:

>In Debian, the release before 4.19.235-1 was 4.19.232-1 which should also have
>this bug. The release before that was 4.19.208-1, which shouldn't.
>Can you verify that?

Not easily any more, but I know it worked some weeks ago, and I *think*
I particularily remember 208 as working. But I do have a clone of linux
on another box and so I can look at ↓

>So I'm inclined to think that 92833e8b5db6c209e9311ac8c6a44d3bf1856659 is
>the commit which brought the bug back.

Yes, definitely. The lines…

if (!qdisc)
return;

… from near the beginning of the now-static qdisc_destroy must
be moved to the beginning of the new qdisc_put function.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Diederik de Haas dixit:

>It's a bit 'above my paygrade', but if qdisk_put() can accept a NULL pointer
>then I'm curious whether that would be allowed for other functions in that file
>as well ... there are several having "struct Qdisc *qdisc" as (only)
>parameter, but only qdisk_put() checks for NULL.
>That is also true for the current 'master' branch ...

AIUI the check was added because qdisc_destroy() could accept one,
and several qdiscs are using that, it’s like free(3) in that regard,
the other functions aren’t.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Thorsten Glaser]

Package: src:linux
Version: 4.19.235-1
Severity: critical
Tags: upstream
Justification: breaks the whole system

A recent upstream “stable” upgrade backported the removal of the
qdisc_destroy() function (which, in itself, is questionable enough
already and caused no small amount of fun) using qdisc_put() instead.

However, qdisc_put() does not accept NULL pointers, causing oopses
in several qdiscs that can be configured on a system. This breaks
sudo (su works), networking and even deconfiguration is not possible,
only /proc/sysrq-trigger makes it possible to recover.

https://www.mail-archive.com/netdev@vger.kernel.org/msg314288.html
fixes this but was not backported along.


-- Package-specific info:
** Version:
Linux version 4.19.0-20-amd64 (debian-kernel@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.235-1 (2022-03-17)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-20-amd64 root=/dev/vda2 ro net.ifnames=0 
nomodeset

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: QEMU
product_name: Standard PC (i440FX + PIIX, 1996)
product_version: pc-i440fx-2.8
chassis_vendor: QEMU
chassis_version: pc-i440fx-2.8
bios_vendor: SeaBIOS
bios_version: 1.14.0-2

** Loaded modules:
ipt_MASQUERADE
nf_conntrack_netlink
xfrm_user
xfrm_algo
nft_counter
nft_chain_nat_ipv4
nf_nat_ipv4
xt_addrtype
nft_compat
xt_conntrack
x_tables
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
br_netfilter
bridge
stp
llc
nf_tables
devlink
nfnetlink
overlay
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
fscache
sunrpc
loop
kvm_intel
ttm
kvm
drm_kms_helper
irqbypass
virtio_rng
joydev
drm
evdev
rng_core
virtio_balloon
serio_raw
pcspkr
button
qemu_fw_cfg
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
hid_generic
usbhid
hid
virtio_net
net_failover
failover
virtio_blk
ata_generic
ata_piix
uhci_hcd
libata
ehci_hcd
usbcore
psmouse
usb_common
virtio_pci
virtio_ring
i2c_piix4
crc32c_intel
scsi_mod
virtio
floppy

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:04.0 SCSI storage controller [0100]: Red Hat, Inc Virtio block device 
[1af4:1001]
Subsystem: Red Hat, Inc Virtio block device [1af4:0002]
Physical Slot: 4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:05.0 Unclassified device [00ff]: Red Hat, Inc Virtio memory balloon 
[1af4:1002]
Subsystem: Red Hat, Inc Virtio memory balloon [1af4:0005]
Physical Slot: 5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:06.0 Unclassified device [00ff]: Red Hat, Inc Virtio RNG [1af4:1005]
Subsystem: Red Hat, Inc Virtio RNG [1af4:0004]
Physical Slot: 6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci

00:07.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device 
[1af4:1000]
Subsystem: Red Hat, Inc Virtio network device [1af4:0001]
Physical Slot: 7
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: virtio-pci
Kernel modules: virtio_pci


** USB devices:
not available


-- System Information:
Debian Release: 10.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-20-amd64 (SMP w/3 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-4.19.0-20-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages 

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

[Thorsten Glaser]

Bastian Blank dixit:

>The pool size for an RPNG is only the size of the state, nothing else.

Yes, and that is the problem. It was small before, it’s ridiculous now.

>might not have had any value before anyway.  You just need to reseed on
>a regular interval.

Ugh. I recall reading something about this on LWN, but I thought I
had time until bookworm to invent something to deal with this…

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#1013192: linux-image-5.10.0-15-amd64: ridiculously small entropy pool

[Thorsten Glaser]

Package: src:linux
Version: 5.10.120-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 


/proc/sys/kernel/random/poolsize is now 256 instead of 4096 bits,
which was already small before.

Why was such a change allowed into stable?

This also breaks rngd’s --fill-watermark option when not set to
percent values. Another reason this should not be changed within
a stable series.


-- Package-specific info:
** Version:
Linux version 5.10.0-15-amd64 (debian-kernel@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 
Debian 5.10.120-1 (2022-06-09)

** Command line:
root=UUID=078df9a0-34f7-4171-b531-0cb628963204 ro clocksource=acpi_pm verbose

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information

** Loaded modules:
binfmt_misc
nfsd
auth_rpcgss
nfs_acl
nfs
lockd
grace
nfs_ssc
fscache
sunrpc
joydev
evdev
serio_raw
virtio_rng
rng_core
pcspkr
virtio_balloon
cirrus
drm_kms_helper
cec
drm
button
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_generic
usbhid
hid
virtio_blk
virtio_net
net_failover
failover
ata_generic
crc32c_intel
psmouse
virtio_pci
virtio_ring
virtio
i2c_piix4
ata_piix
uhci_hcd
libata
floppy
ehci_hcd
scsi_mod
usbcore
usb_common

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] 
[8086:1237] (rev 02)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-15-amd64 suggests:
pn  debian-kernel-handbook   
pn  grub-pc | grub-efi-amd64 | extlinux  
pn  linux-doc-5.10   

Versions of packages linux-image-5.10.0-15-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#522773: possible solutions for __unused problem

[Thorsten Glaser]

Diederik de Haas dixit:

>and the patch proposed by Ben, more then 6 years ago, hasn't been merged.
>
>As I don't know the reason it wasn't closed last year, I won't do it, but 
>maybe it's time to finally close it?

If the bug persists, it’s still a bug, so don’t close it.
Prod them occasionally.

I know that *some* __unused have been fixed; maybe the remaining
ones were an oversight?

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

problems getting the -common header package

[Thorsten Glaser]

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
says to use, for example…

$ fakeroot make -f debian/rules.gen binary-indep_amd64_none_real

… to get the -common package, but this doesn’t. You (also?) need:

$ fakeroot make -f debian/rules.gen binary-indep_none_real

Otherwise thanks for the excellent documentation to (re‑)build the
Debian kernel with minimal changes, switching HZ to 1000 for this
example.

I had one problem changing the ABI following
https://kernel-team.pages.debian.net/kernel-handbook/ch-versions.html#s-abi-name

I first set it to 14.kHz and…
$ fakeroot debian/rules debian/control-real
… passed, but then the build complained about a regex, quickly
confirmed to be the upper-case letter. The debian/control-real
target could, ideally, already check this.

(That being said, OT, but which (probably good, I’m sure) reason
is there to use 250 Hz by default?)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1008501: pahole-flags.sh: inaccessible or not found

[Thorsten Glaser]

Package: linux-headers-5.17.0-rc8-common
Version: 5.17~rc8-1~exp1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Trying to build a kernel module against 5.17 shows several warnings:

W: /bin/sh: /usr/src/linux-headers-5.17.0-rc8-common/scripts/pahole-flags.sh: 
inaccessible or not found

According to the PTS, a file called pahole-flags.sh does not exist in
experimental *or* sid.

I haven’t checked whether this bug also occurs on sid; bullseye does
not yet have it.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1004465: libklibc-dev: headers not installed

[Thorsten Glaser]

found 1004465 2.0.10-1
thanks

Dixi quod…

>Quite some files are missing:
[…]
>/usr/lib/klibc/include/alloca.h
[…]
>/usr/lib/klibc/include/arpa/inet.h
>   /usr/lib/klibc/include/asm
>   /usr/lib/klibc/include/asm-generic
>/usr/lib/klibc/include/assert.h
[…]

From this pattern, commit 8f680c0688151ce4d50072783a5b6fad7beabc1f
is suspect:

Since debhelper 11, dh_install and dh_installman have automatically
searched for the listed files/directories relative to debian/tmp/
as well as in the top directory.

--- a/debian/libklibc-dev.install
+++ b/debian/libklibc-dev.install
@@ -1,1 +1,1 @@
-debian/tmp/usr/lib/klibc/include/*
+usr/lib/klibc/include/*

My suspiction here is that since usr/lib/klibc/include/* exist
in the top-level directory, the alternative location is not
attempted.

I’d probably just rever that and not rely on such fragile
automatism that reek of bad magic and make the packaging
harder to understand… and easier to break (e.g. if upstream
adds files…)

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1004465: libklibc-dev: headers not installed

[Thorsten Glaser]

Package: libklibc-dev
Version: 2.0.10-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: t...@mirbsd.de

Quite some files are missing:

$ comm <($bullseye dpkg -L libklibc-dev | sort) <($sid dpkg -L libklibc-dev | 
sort)
/.
/usr
/usr/bin
/usr/bin/klcc
/usr/lib
/usr/lib/klibc
/usr/lib/klibc/include
/usr/lib/klibc/include/Kbuild
/usr/lib/klibc/include/alloca.h
/usr/lib/klibc/include/arch
/usr/lib/klibc/include/arch/alpha
/usr/lib/klibc/include/arch/alpha/klibc
/usr/lib/klibc/include/arch/alpha/klibc/archconfig.h
/usr/lib/klibc/include/arch/alpha/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/alpha/klibc/archsignal.h
/usr/lib/klibc/include/arch/alpha/klibc/archstat.h
/usr/lib/klibc/include/arch/alpha/machine
/usr/lib/klibc/include/arch/alpha/machine/asm.h
/usr/lib/klibc/include/arch/arm
/usr/lib/klibc/include/arch/arm/klibc
/usr/lib/klibc/include/arch/arm/klibc/archconfig.h
/usr/lib/klibc/include/arch/arm/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/arm/klibc/archsignal.h
/usr/lib/klibc/include/arch/arm/klibc/archstat.h
/usr/lib/klibc/include/arch/arm/klibc/asmmacros.h
/usr/lib/klibc/include/arch/arm64
/usr/lib/klibc/include/arch/arm64/klibc
/usr/lib/klibc/include/arch/arm64/klibc/archconfig.h
/usr/lib/klibc/include/arch/arm64/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/arm64/klibc/archsignal.h
/usr/lib/klibc/include/arch/arm64/klibc/archstat.h
/usr/lib/klibc/include/arch/i386
/usr/lib/klibc/include/arch/i386/klibc
/usr/lib/klibc/include/arch/i386/klibc/archconfig.h
/usr/lib/klibc/include/arch/i386/klibc/archinit.h
/usr/lib/klibc/include/arch/i386/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/i386/klibc/archsignal.h
/usr/lib/klibc/include/arch/i386/klibc/archstat.h
/usr/lib/klibc/include/arch/i386/klibc/diverr.h
/usr/lib/klibc/include/arch/i386/sys
/usr/lib/klibc/include/arch/i386/sys/io.h
/usr/lib/klibc/include/arch/i386/sys/vm86.h
/usr/lib/klibc/include/arch/ia64
/usr/lib/klibc/include/arch/ia64/klibc
/usr/lib/klibc/include/arch/ia64/klibc/archconfig.h
/usr/lib/klibc/include/arch/ia64/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/ia64/klibc/archsignal.h
/usr/lib/klibc/include/arch/ia64/klibc/archstat.h
/usr/lib/klibc/include/arch/m68k
/usr/lib/klibc/include/arch/m68k/klibc
/usr/lib/klibc/include/arch/m68k/klibc/archconfig.h
/usr/lib/klibc/include/arch/m68k/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/m68k/klibc/archsignal.h
/usr/lib/klibc/include/arch/m68k/klibc/archstat.h
/usr/lib/klibc/include/arch/mips
/usr/lib/klibc/include/arch/mips/klibc
/usr/lib/klibc/include/arch/mips/klibc/archconfig.h
/usr/lib/klibc/include/arch/mips/klibc/archfcntl.h
/usr/lib/klibc/include/arch/mips/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/mips/klibc/archsignal.h
/usr/lib/klibc/include/arch/mips/klibc/archsocket.h
/usr/lib/klibc/include/arch/mips/klibc/archstat.h
/usr/lib/klibc/include/arch/mips/machine
/usr/lib/klibc/include/arch/mips/machine/asm.h
/usr/lib/klibc/include/arch/mips/sgidefs.h
/usr/lib/klibc/include/arch/mips/spaces.h
/usr/lib/klibc/include/arch/mips64
/usr/lib/klibc/include/arch/mips64/klibc
/usr/lib/klibc/include/arch/mips64/klibc/archconfig.h
/usr/lib/klibc/include/arch/mips64/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/mips64/klibc/archsignal.h
/usr/lib/klibc/include/arch/mips64/klibc/archsocket.h
/usr/lib/klibc/include/arch/mips64/klibc/archstat.h
/usr/lib/klibc/include/arch/mips64/machine
/usr/lib/klibc/include/arch/mips64/machine/asm.h
/usr/lib/klibc/include/arch/parisc
/usr/lib/klibc/include/arch/parisc/klibc
/usr/lib/klibc/include/arch/parisc/klibc/archconfig.h
/usr/lib/klibc/include/arch/parisc/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/parisc/klibc/archsignal.h
/usr/lib/klibc/include/arch/parisc/klibc/archstat.h
/usr/lib/klibc/include/arch/ppc
/usr/lib/klibc/include/arch/ppc/klibc
/usr/lib/klibc/include/arch/ppc/klibc/archconfig.h
/usr/lib/klibc/include/arch/ppc/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/ppc/klibc/archsignal.h
/usr/lib/klibc/include/arch/ppc/klibc/archstat.h
/usr/lib/klibc/include/arch/ppc64
/usr/lib/klibc/include/arch/ppc64/klibc
/usr/lib/klibc/include/arch/ppc64/klibc/archconfig.h
/usr/lib/klibc/include/arch/ppc64/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/ppc64/klibc/archsignal.h
/usr/lib/klibc/include/arch/ppc64/klibc/archstat.h
/usr/lib/klibc/include/arch/riscv64
/usr/lib/klibc/include/arch/riscv64/klibc
/usr/lib/klibc/include/arch/riscv64/klibc/archconfig.h
/usr/lib/klibc/include/arch/riscv64/klibc/archsetjmp.h
/usr/lib/klibc/include/arch/riscv64/klibc/archsignal.h
/usr/lib/klibc/include/arch/riscv64/klibc/archstat.h
/usr/lib/klibc/include/arch/riscv64/machine
/usr/lib/klibc/include/arch/riscv64/machine/asm.h
/usr/lib/klibc/include/arch/s390
/usr/lib/klibc/include/arch/s390/klibc
/usr/lib/klibc/include/arch/s390/klibc/archconfig.h
/usr/lib/klibc/include/arch/s390/klibc/archsetjmp.h

Bug#988027: klibc: sigsetjmp ignores second argument, siglongjmp always restores signals

[Thorsten Glaser]

close 988027
thanks

I guess it works as documented for klibc, even though this is a porting
hindrance so no need to keep this bugreport open. Deliberately closing
per control instead of done as the underlying issue is still present.

Bug#943425: klibc: debdiff for NMU 2.0.8-6.1

[Thorsten Glaser]

Hi Ben, maks,

please find attached the debdiff fixing this release-critical bug.
I’ve uploaded to DELAYED/0 per devref.

Please integrate this into the next maintainer upload.

I’ve only added the patch for the wrong registers being saved,
not the one fixing sig{set,long}jmp because, apparently, klibc
documents its standard violation for these two functions, so
that’s best dealt with upstream. I’ll upload mksh using the
regular {set,long}jmp functions instead where signals are to
not be saved once klibc is built on all architectures.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-27 00:12:10.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Thorsten Glaser   Thu, 27 May 2021 00:12:10 +0200
+
 klibc (2.0.8-6) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
 
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
--- 
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
  1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
  2021-05-27 00:11:57.0 +0200
@@ -0,0 +1,57 @@
+Description: {set,long}jmp [s390x]: save/restore the correct registers
+ The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+ to be saved. (Closes: Debian #943425)
+Author: mirabilos 
+Forwarded: https://lists.zytor.com/archives/klibc/2021-May/004620.html
+
+--- a/usr/include/arch/s390/klibc/archsetjmp.h
 b/usr/include/arch/s390/klibc/archsetjmp.h
+@@ -16,7 +16,7 @@ struct __jmp_buf {
+ 
+ struct __jmp_buf {
+   uint64_t __gregs[10]; /* general registers r6-r15 */
+-  uint64_t __fpregs[4]; /* fp registers f1, f3, f5, f7 */
++  uint64_t __fpregs[8]; /* fp registers f8-f15 */
+ };
+ 
+ #endif /* __s390x__ */
+--- a/usr/klibc/arch/s390/setjmp.S
 b/usr/klibc/arch/s390/setjmp.S
+@@ -38,10 +38,14 @@ longjmp:
+ 
+ setjmp:
+   stmg%r6,%r15,0(%r2) # save all general registers
+-  std %f1,80(%r2) # save fp registers f4 and f6
+-  std %f3,88(%r2)
+-  std %f5,96(%r2)
+-  std %f7,104(%r2)
++  std %f8,80(%r2) # save fp registers f8 to f15
++  std %f9,88(%r2)
++  std %f10,96(%r2)
++  std %f11,104(%r2)
++  std %f12,112(%r2)
++  std %f13,120(%r2)
++  std %f14,128(%r2)
++  std %f15,136(%r2)
+   lghi%r2,0   # return 0
+   br  %r14
+ 
+@@ -54,10 +58,14 @@ setjmp:
+ longjmp:
+   lgr %r1,%r2 # jmp_buf
+   lgr %r2,%r3 # return value
+-  ld  %f7,104(%r1)# restore all saved registers
+-  ld  %f5,96(%r1)
+-  ld  %f3,88(%r1)
+-  ld  %f1,80(%r1)
++  ld  %f15,136(%r1)   # restore all saved registers
++  ld  %f14,128(%r1)
++  ld  %f13,120(%r1)
++  ld  %f12,112(%r1)
++  ld  %f11,104(%r1)
++  ld  %f10,96(%r1)
++  ld  %f9,88(%r1)
++  ld  %f8,80(%r1)
+   lmg %r6,%r15,0(%r1)
+   br  %r14# return to restored address
+ 
diff -Nru klibc-2.0.8/debian/patches/series klibc-2.0.8/debian/patches/series
--- klibc-2.0.8/debian/patches/series   2021-04-30 02:38:31.0 +0200
+++ klibc-2.0.8/debian/patches/series   2021-05-27 00:09:21.0 +0200
@@ -10,3 +10,4 @@
 0037-klibc-calloc-Fail-if-multiplication-overflows.patch
 0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
 0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
+0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch

Bug#943425: [klibc] #943425 [s390x] setjmp/longjmp do not save/restore all registers in use

[Thorsten Glaser]

Hello Ben,

any chance to upload at least the patch for s390x?
This affects a release architrecture, so I’d NMU this if
necessary, so we have it fixed in bullseye.

Thanks,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr

Bug#943425: [klibc] Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

[Thorsten Glaser]

tags 943425 + patch
tags 988027 + patch
thanks

Dixi quod…

>Patches for klibc upstream git attched; I’m currently trying to test
>them, will report.

This was really tricky given we can’t install patched B-Ds on
porterboxen, but I managed. I can confirm this fixes my issue.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-05 21:38:31.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix sig{set,long}jmp always saves the signal mask (Closes: #988027)
+  * [s390x] Fix {set,long}jmp registers to save (Closes: #943425)
+
+ -- Thorsten Glaser   Wed, 05 May 2021 21:38:31 +0200
+
 klibc (2.0.8-6) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
--- 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
  1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
  2021-05-05 21:38:31.0 +0200
@@ -0,0 +1,71 @@
+From ba9cce08553cb49fe077485b13ae99548bb2da5c Mon Sep 17 00:00:00 2001
+From: mirabilos 
+Date: Wed, 5 May 2021 21:02:37 +0200
+Subject: [PATCH 1/2] [klibc] sig{set,long}jmp: do not ignore sigsetjmp's
+ second argument
+
+Save and restore the signal mask only if that argument is nonzero,
+as required by the standards.  (Closes: Debian #988027)
+
+Signed-off-by: mirabilos 
+---
+ usr/include/setjmp.h   | 7 ++-
+ usr/klibc/CAVEATS  | 3 +--
+ usr/klibc/siglongjmp.c | 3 ++-
+ 3 files changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/usr/include/setjmp.h b/usr/include/setjmp.h
+index abebccde..5916cd8a 100644
+--- a/usr/include/setjmp.h
 b/usr/include/setjmp.h
+@@ -27,6 +27,7 @@ __extern __noreturn longjmp(jmp_buf, int);
+ struct __sigjmp_buf {
+   jmp_buf __jmpbuf;
+   sigset_t __sigs;
++  unsigned char __sigs_saved;
+ };
+ 
+ typedef struct __sigjmp_buf sigjmp_buf[1];
+@@ -34,7 +35,11 @@ typedef struct __sigjmp_buf sigjmp_buf[1];
+ #define sigsetjmp(__env, __save) \
+ ({ \
+   struct __sigjmp_buf *__e = (__env); \
+-  sigprocmask(0, NULL, &__e->__sigs); \
++  if (__save) { \
++sigprocmask(0, NULL, &__e->__sigs); \
++__e->__sigs_saved = 1; \
++  } else \
++__e->__sigs_saved = 0; \
+   setjmp(__e->__jmpbuf); \
+ })
+ 
+diff --git a/usr/klibc/CAVEATS b/usr/klibc/CAVEATS
+index 5e991cb7..39949c28 100644
+--- a/usr/klibc/CAVEATS
 b/usr/klibc/CAVEATS
+@@ -13,8 +13,7 @@ Compiling with -O0 is more likely to work on gcc 3.
+ setjmp()/longjmp():
+ ---
+ setjmp() and longjmp() *do not* save signal state.  sigsetjmp() and
+-siglongjmp() *do* save the signal mask -- regardless of the value of
+-the extra argument.
++siglongjmp() *do* save the signal mask if the extra argument is nonzero.
+ 
+ The standards actually state that if you pass longjmp() a final value
+ of zero the library should change that to a 1!  Presumably the reason
+diff --git a/usr/klibc/siglongjmp.c b/usr/klibc/siglongjmp.c
+index 31042cbd..45f4e400 100644
+--- a/usr/klibc/siglongjmp.c
 b/usr/klibc/siglongjmp.c
+@@ -10,6 +10,7 @@
+ 
+ __noreturn siglongjmp(sigjmp_buf buf, int retval)
+ {
+-  sigprocmask(SIG_SETMASK, >__sigs, NULL);
++  if (buf->__sigs_saved)
++  sigprocmask(SIG_SETMASK, >__sigs, NULL);
+   longjmp(buf->__jmpbuf, retval);
+ }
+-- 
+2.31.1
+
diff -Nru 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
--- 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
  1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
  2021-05-05 21:38:31.0 +0200
@@ -0,0 +1,76 @@
+From fc5a53932ee56d61a9fd8db75784e9f39ca474a3 Mon Sep 17 00:00:00 2001
+From: mirabilos 
+Date: Wed, 5 May 2021 21:26:33 +0200
+Subject: [PATCH 2/2] [klibc] {set,long}jmp [s390x]: save/restore the correct
+ registers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+to be saved. (Closes: Debian #943425)
+
+Signed-off-by: mirabilos 
+---
+ usr/include/arch/s390/klibc/archsetjmp.h |  2 +-
+ usr/

Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

[Thorsten Glaser]

Hi Andreas,

>>> Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>>> other FPU registers not:
>
>I can confirm this. It is f8-f15 for the z/Architecture (64 bit).

thanks!

>It is f1, f3, f5, f7 for the ESA
>architecture (32 bit) which is still supported by Glibc and GCC.

Is this what we know as s390 in Debian? (klibc saves f4 and f6 there
currently. If so, this also needs to change.)

>>> … GCC chooses to allocate an FPU register for a pointer value.
>
>GCC will put integer values into vector registers for
>auto-vectorization or for spilling. We also use call-clobbered FPRs as
>save slots for GPRs in leaf-functions if can get rid of allocating a
>stack frame that way.

Ah, interesting. Thanks!

>The vector registers are call-clobbered - exactly for the reason of
>setjmp / longjmp. Only f8-f15 need to be saved.

Right.

>You can find the latest version of our ABI here:
>https://github.com/IBM/s390x-abi/releases/download/v1.5/lzsabi_s390x.pdf
>
>However, it is still lacking the vector ABI extension. I wrote a
>document for that which we use internally and we are working on
>integrating it into the publicly available version.

OK, thanks for the information!

>>> @klibc list: as indicated earlier, I can provide a patch if needed
>>> (though it should be obvious).

hpa, maks, bwh: any of you taking these two or should I send patches
and possibly NMU klibc in Debian?

Thanks,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#943425: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use

[Thorsten Glaser]

Dixi quod…

>Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>other FPU registers not:

This needs to be fixed in klibc.

>>• klibc does not really support the FPU anyway
>
>… GCC chooses to allocate an FPU register for a pointer value.

This is a curiosity.

>>• the half of v10 that equals f10 just HAPPENS to be saved by
>>  glibc, but what if the upper half, that is outside of the FPU,
>>  is used?
>
>The question here is, does GCC only use the halves of the half
>of the vector registers that match the FPU registers?

04:41⎜«jrtc27:#debian-x32» hephaistor: re s390x vector registers, reading the 
gcc and llvm sources they're
 ⎜all call-clobbered by default, only the float parts are call-saved
04:41⎜«jrtc27:#debian-x32» so that's why setjmp/longjmp don't need to 
save/restore them
04:42⎜«jrtc27:#debian-x32» there *is* a vector calling convention, but it's not 
the default for the ABI,
 ⎜it's opt-in, and setjmp/longjmp won't be annotated as such

So we indeed need to only save the registers glibc does.

>@klibc list: as indicated earlier, I can provide a patch if needed
>(though it should be obvious).

bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

Bug#943425: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use (was Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2))

[Thorsten Glaser]

Dixi quod…

>So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
>https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
>“the z/Architecture ABI,[11] used in Linux” a page down), while
>glibc’s save f8–f15 instead.

Jessica Clarke brought out docs saying f8‥f15 must be saved, the
other FPU registers not:
https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.html#AEN413

This matches what glibc does. Maybe an s390x porter wishes to fix
Wikipedia?

>https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf
>shows that the vector registers overlap and extend the FPU registers.

>• is register v10 (vector extension) even supposed to be used?

This needs to be answered, I guess, because…

>• klibc does not really support the FPU anyway

… GCC chooses to allocate an FPU register for a pointer value.

>• the half of v10 that equals f10 just HAPPENS to be saved by
>  glibc, but what if the upper half, that is outside of the FPU,
>  is used?

The question here is, does GCC only use the halves of the half
of the vector registers that match the FPU registers?

@klibc list: as indicated earlier, I can provide a patch if needed
(though it should be obvious).

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#988027: klibc: sigsetjmp ignores second argument, siglongjmp always restores signals

[Thorsten Glaser]

Package: libklibc-dev
Version: 2.0.8-6
Severity: serious
Justification: spec violation, affecting release architectures
X-Debbugs-Cc: t...@debian.org

Found during debugging of #943425:

- usr/include/setjmp.h

struct __sigjmp_buf {
jmp_buf __jmpbuf;
sigset_t __sigs;
};
  => does not contain information whether __sigs was saved

#define sigsetjmp(__env, __save) \
({ \
  struct __sigjmp_buf *__e = (__env); \
  sigprocmask(0, NULL, &__e->__sigs); \
  setjmp(__e->__jmpbuf); \
})
  => ignores the __save argument

- usr/klibc/siglongjmp.c

__noreturn siglongjmp(sigjmp_buf buf, int retval)
{
sigprocmask(SIG_SETMASK, >__sigs, NULL);
longjmp(buf->__jmpbuf, retval);
  => always restores __sigs

This is in direct violation to the Debian sigsetjmp(3) docs...

   If, and only if, the savesigs argument provided to sigsetjmp() is  non-
   zero, the process's current signal mask is saved in env and will be re-
   stored if a siglongjmp() is later performed with this env.

... and POSIX:

 * The siglongjmp() function shall restore the saved signal mask if and
   only if the env argument was initialized by a call to [9]sigsetjmp()
   with a non-zero savemask argument.
  Q: https://pubs.opengroup.org/onlinepubs/9699919799/functions/siglongjmp.html


If necessary I can provide a patch to fix this.

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: s390x

Kernel: Linux 4.19.0-16-s390x (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libklibc-dev depends on:
ii  libklibc2.0.8-6
ii  linux-libc-dev  5.10.28-1

libklibc-dev recommends no packages.

libklibc-dev suggests no packages.

-- no debconf information

Bug#943425: Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2)

[Thorsten Glaser]

retitle 943425 klibc: [s390x] setjmp/longjmp do not save/restore all registers 
in use
# because this affects a release architecture
severity 943425 serious
thanks

Recapping for the benefit of d-s390@l.d.o:

> The code in question (where it crashes) is thus:

>1607  */
>1608 valsub(t, NULL);
>1609 subst_exstat = exstat & 0xFF;
>1610 /* rewind the tempfile and restore regular stdout */
>1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);

> The crash occurs in line 1611 because shf (a local variable) is nil.
>
> The really interesting part, though, is in line 1608, a call to valsub():

[…]
>2104 if (!kshsetjmp(e->jbuf))
>2105 execute(t, XXCOM | XERROK, NULL);
[…]

kshsetjmp(x) is sigsetjmp(x,0) (though klibc ignores the 0).

execute() calls siglongjmp().

> - it appears as if the combination of sigsetjmp/siglongjmp does not restore
>   all callee-saved variables correctly on s390x; comparing with glibc shows
>   that the wrong FPU registers seem to be saved but mksh does not use the
>   FPU anyway
>
> Setting breakpoints to lines 1608 (valsub call) and 1609:

[…]
> 1608valsub(t, NULL);
> (gdb) print shf
> $5 = (struct shf *) 0x3fffdfe5de8
> (gdb) print 
> Address requested for identifier "shf" which is in register $v10
> (gdb) print $v10
> $6 = {v4_float = {1.43352833e-42, -4.22639375e+37, 0, 0}, v2_double = 
> {2.1729070589754877e-311, 0}, v16_int8 = {
> 0, 0, 3, -1, -3, -2, 93, -24, 0, 0, 0, 0, 0, 0, 0, 0}, v8_int16 = {0, 
> 1023, -514, 24040, 0, 0, 0, 0},
>   v4_int32 = {1023, -33661464, 0, 0}, v2_int64 = {4398012849640, 0}, uint128 
> = 81129017470195127308370827018240}
>
> 0x3FFFDFE5DE8 is 4398012849640 which is in v2_int64, found.
[…]
> Breakpoint 2, comsub (fn=14, cp=0x0, xp=) at 
> ../../eval.c:1609
> 1609subst_exstat = exstat & 0xFF;
[…]
> (gdb) print $v10
> $7 = {v4_float = {0, 0, 0, 0}, v2_double = {0, 0}, v16_int8 = {0  times>}, v8_int16 = {0, 0, 0, 0,
> 0, 0, 0, 0}, v4_int32 = {0, 0, 0, 0}, v2_int64 = {0, 0}, uint128 = 0}

--

So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
“the z/Architecture ABI,[11] used in Linux” a page down), while
glibc’s save f8–f15 instead.

https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf
shows that the vector registers overlap and extend the FPU registers.

(gdb) info float
[…]
f102.172907066248134e-311 (raw 0x03fffdfe9768)
(gdb) print shf
$2 = (struct shf *) 0x3fffdfe9768

The real questions here are:

• is register v10 (vector extension) even supposed to be used?
• klibc does not really support the FPU anyway
• the half of v10 that equals f10 just HAPPENS to be saved by
  glibc, but what if the upper half, that is outside of the FPU,
  is used?
• where *is* the s390x̲ ABI documented anyway? syscall(2) has the
  kernel side only

Building with -mno-vx does not seem to help, %f* are still in
the .s files generated by gcc.

So I assume klibc should save registers f8–15 on s390x but what
happened to f1/f3/f5/f7?

Thanks,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)

Bug#943425: klibc: [s390x] SIGSEGV in mksh testcase funsub-2

[Thorsten Glaser]

Package: libklibc-dev
Version: 2.0.8-6
Followup-For: Bug #943425
X-Debbugs-Cc: t...@debian.org

I am able to track this down on the porterbox zelenka.

$ apt-get source mksh
$ cd mksh-59c
$ mkdir -p build/klibc
$ cd build/klibc
$ cp /usr/lib/klibc/bin/mksh .
$ chmod +x mksh   # because the x attribute is removed if testsfail
$ gdb --args ./mksh -c 'x=q; e=1; x=${ echo a; typeset e=2; return 3; echo 
x$e;}; echo 3:y$x,$e,$?.'
(gdb) r
[...]
Program received signal SIGSEGV, Segmentation fault.
0x01007c32 in comsub (fn=14, cp=0x0, xp=) at 
../../eval.c:1611
warning: Source file is more recent than executable.
1611lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
(gdb) bt
#0  0x01007c32 in comsub (fn=14, cp=0x0, xp=) at 
../../eval.c:1611
#1  expand (ccp=ccp@entry=0x3fffdfe4768 "\001x\001=\016\\echo a ; \\typeset e=2 
; \\return 3 ; \\echo x$e ",
wp=wp@entry=0x3ffed48, f=f@entry=4128) at ../../eval.c:346
#2  0x0100a366 in evalstr (
cp=0x3fffdfe4768 "\001x\001=\016\\echo a ; \\typeset e=2 ; \\return 3 ; 
\\echo x$e ", f=f@entry=4128)
at ../../eval.c:173
#3  0x0100d082 in comexec (t=0x3fffdfe4888, tp=tp@entry=0x0, 
ap=0x3fffdfe45e8, flags=,
xerrok=) at ../../exec.c:640
#4  0x0100bf0a in execute (t=, flags=, 
xerrok=xerrok@entry=0x0)
at ../../exec.c:162
#5  0x0100c0a2 in execute (t=t@entry=0x3fffdfe4588, 
flags=flags@entry=0, xerrok=xerrok@entry=0x0)
at ../../exec.c:204
#6  0x0101e048 in shell (s=s@entry=0x3fffdfe3b68, level=level@entry=0) 
at ../../main.c:954
#7  0x01000e78 in main (argc=, argv=) at 
../../main.c:742
(gdb) print shf
$1 = (struct shf *) 0x0


The code in question (where it crashes) is thus:

   1584 } else if (fn == FUNSUB) {
   1585 int ofd1;
   1586 struct temp *tf = NULL;
   1587 
   1588 /*
   1589  * create a temporary file, open for reading and 
writing,
   1590  * with an shf open for reading (buffered) but yet 
unused
   1591  */
   1592 maketemp(ATEMP, TT_FUNSUB, );
   1593 if (!tf->shf) {
   1594 errorf(Tf_temp,
   1595 Tcreate, tf->tffn, cstrerror(errno));
   1596 }
   1597 /* extract shf from temporary file, unlink and free it 
*/
   1598 shf = tf->shf;
   1599 unlink(tf->tffn);
   1600 afree(tf, ATEMP);
   1601 /* save stdout and let it point to the tempfile */
   1602 ofd1 = savefd(1);
   1603 ksh_dup2(shf_fileno(shf), 1, false);
   1604 /*
   1605  * run tree, with output thrown into the tempfile,
   1606  * in a new function block
   1607  */
   1608 valsub(t, NULL);
   1609 subst_exstat = exstat & 0xFF;
   1610 /* rewind the tempfile and restore regular stdout */
   1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
   1612 restfd(1, ofd1);

The crash occurs in line 1611 because shf (a local variable) is nil.

The really interesting part, though, is in line 1608, a call to valsub():

   2093 /* helper function due to setjmp/longjmp woes */
   2094 static char *
   2095 valsub(struct op *t, Area *ap)
   2096 {
   2097 char * volatile cp = NULL;
   2098 struct tbl * volatile vp = NULL;
   2099 
   2100 newenv(E_FUNC);
   2101 newblock();
   2102 if (ap)
   2103 vp = local(TREPLY, false);
   2104 if (!kshsetjmp(e->jbuf))
   2105 execute(t, XXCOM | XERROK, NULL);
   2106 if (vp)
   2107 strdupx(cp, str_val(vp), ap);
   2108 quitenv(NULL);
   2109 
   2110 return (cp);
   2111 }

Let's look again at the invocation that caused the crash:

x=q; e=1; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo 
3:y$x,$e,$?.

This one does not crash:

x=q; e=1; x=${ echo a; typeset e=2; echo x$e;}; echo 2:y$x,$e,$?.

The difference here is that 'return' is used in the crash case,
which executes a kshlongjmp(), that is siglongjmp(); kshsetjmp(x)
is sigsetjmp(x,0), which klibc defines as:

 34 #define sigsetjmp(__env, __save) \
 35 ({ \
 36   struct __sigjmp_buf *__e = (__env); \
 37   sigprocmask(0, NULL, &__e->__sigs); \
 38   setjmp(__e->__jmpbuf); \
 39 })

This apparently has two problems:

- the __save argument is ignored, contrary to sigsetjmp docs:

   If, and only if, the savesigs argument provided to sigsetjmp() is  non-
   zero, the process's current signal mask is saved in env and will be re-
   stored if a siglongjmp() is later performed with this env.

- it appears as if the combination of sigsetjmp/siglongjmp does not restore
  all callee-saved variables 

Bug#718415: Closing this bug (BTS maintenance for src:linux bugs)

[Thorsten Glaser]

Hi Salvatore,

>If you can reproduce it with
>
>- the current version in unstable/testing
>- the latest kernel from backports

I still have the occasional freezes or crashes on that machine,
with nouveau, but nothing to reliably reproduce it. Basically,
if Xorg is left running for long, either it or the entire machine
eventually crashes (mostly just the X server, symptom is the
session terminates, kdm shows up, rarely the entire machine).

It may be that nouveau support for that particular chip is buggy?

Since I currently use the box remotely only (due to Corona), I’ve
just not logged in graphically and stopped kdm so it reliably runs
(using xrdp or ssh), but I’ve recently seen this happen, I believe
a bit over three weeks ago (my syslog does not go back this far,
this is the uptime) I had to drive there and reset it by pressing
the power button long.

Do you consider this enough for reopening?

/var/log/dmesg:

[0.00] microcode: microcode updated early to revision 0x1d, date = 
2018-05-11
[0.00] Linux version 5.10.0-5-amd64 (debian-kernel@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 Debian 5.10.24-1 (2021-03-19)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-5-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr l1tf=flush,nosmt
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfec] usable
[0.00] BIOS-e820: [mem 0xcfed-0xcfed0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfed1000-0xcfed] ACPI data
[0.00] BIOS-e820: [mem 0xcfee-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00062fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. X58-USB3/X58-USB3, BIOS F5 
09/07/2011
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3064.502 MHz processor
[0.003119] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.003124] e820: remove [mem 0x000a-0x000f] usable
[0.003132] last_pfn = 0x63 max_arch_pfn = 0x4
[0.003138] MTRR default type: uncachable
[0.003140] MTRR fixed ranges enabled:
[0.003142]   0-9 write-back
[0.003143]   A-B uncachable
[0.003145]   C-CDFFF write-protect
[0.003146]   CE000-E uncachable
[0.003148]   F-F write-through
[0.003149] MTRR variable ranges enabled:
[0.003151]   0 base 0 mask F write-back
[0.003153]   1 base 0E000 mask FE000 uncachable
[0.003155]   2 base 0D000 mask FF000 uncachable
[0.003157]   3 base 1 mask F write-back
[0.003158]   4 base 2 mask E write-back
[0.003160]   5 base 4 mask C write-back
[0.003162]   6 base 5 mask F write-back
[0.003164]   7 base 6 mask FC000 write-back
[0.004135] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.004696] e820: update [mem 0xd000-0x] usable ==> reserved
[0.004704] last_pfn = 0xcfed0 max_arch_pfn = 0x4
[0.014278] found SMP MP-table at [mem 0x000f5a60-0x000f5a6f]
[0.028268] RAMDISK: [mem 0x33b95000-0x35dc1fff]
[0.028281] ACPI: Early table checksum verification disabled
[0.028286] ACPI: RSDP 0x000F7200 14 (v00 GBT   )
[0.028294] ACPI: RSDT 0xCFED1040 48 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.028303] ACPI: FACP 0xCFED1100 74 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.028313] ACPI: DSDT 0xCFED11C0 00391C (v01 GBTGBTUACPI 
1000 MSFT 010C)
[0.028321] ACPI: FACS 0xCFED 40
[0.028327] ACPI: MSDM 0xCFED4CC0 55 (v03 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.028334] ACPI: HPET 0xCFED4D80 38 (v01 GBTGBTUACPI 
42302E31 GBTU 0098)
[0.028341] ACPI: MCFG 0xCFED4E00 3C (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.028348] ACPI: EUDS 0xCFED4E40 0004D0 (v01 GBT 
  )
[0.028355] ACPI: MATS 0xCFED5310 34 (v01 GBT 
  )
[0.028362] ACPI: TAMG 0xCFED5380 000CFA (v01 GBTGBT   B0 
5455312E BG?? 53450101)
[0.028369] ACPI: 

Bug#983561: firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt and others

[Thorsten Glaser]

maximilian attems dixit:

>are there other dangling symlinks besides this three mentioned ones?

adequate reported only these three for this package; you can find
dangling symlinks, generally, with: (thanks XTaran)

find -L . -type l -ls

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#983561: firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt and others

[Thorsten Glaser]

Package: firmware-misc-nonfree
Version: 20210208-2
Severity: normal
User: debian...@lists.debian.org
Usertags: adequate broken-symlink
X-Debbugs-Cc: t...@mirbsd.de

firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt -> 
configs/t4-config-default.txt
firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t5-config.txt -> 
configs/t5-config-default.txt
firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t6-config.txt -> 
configs/t6-config-default.txt





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

Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.139

-- no debconf information

Bug#976258: linux: hibernation attempt results in shutdown and unclean filesystem

[Thorsten Glaser]

Package: src:linux
Version: 5.9.9-1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc: 
t...@mirbsd.de,reply+aagshfu5klm2qb2dozdxppf5z5jydevbnhhcvex...@reply.github.com

A bit of backstory, since this is not the first place I had to
report this to (feels like being sent from Pontius to Pilatus):

I’ve switched from consolekit to elogind once it became usable.

I accidentally hit Fn-F12 on a Thinkad X61, causing elogind to
attempt “hibernation” (sudpend to disc): Debian #971644

My system is not set up for hibernation as the swap space is
*much* smaller than the memory size, and no HIBERFIL.SYS is
set up. I do not use hibernation, nor do I want it.


tglase@tglase-nb:~ $ free
  totalusedfree  shared  buff/cache   available
Mem:8080564  350456 7152308   15316  577800 7481152
Swap:   3206140   0 3206140
tglase@tglase-nb:~ $ fdisk -l /dev/sda
fdisk: cannot open /dev/sda: Permission denied
1|tglase@tglase-nb:~ $ doch
Disk /dev/sda: 149.05 GiB, 160041885696 bytes, 312581808 sectors
Disk model: INTEL SSDSA2M160
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00011447

Device BootStart   End   Sectors  Size Id Type
/dev/sda1  *2048   2099200   20971531G 83 Linux
/dev/sda22101248   8513535   6412288  3.1G 82 Linux swap / Solaris
/dev/sda38513536  50456575  41943040   20G 27 Hidden NTFS WinRE
/dev/sda4   50456576 312581807 262125232  125G 83 Linux


The problem here is that, even if hibernation fails, the system
powers off but the filesystem is not in a clean state (as can be
seen easily from the e2fsck messages upon next powerup). This can
cause serious user data loss. I expect that a hibernation failure
will cause a message in syslog and otherwise the system to con‐
tinue working as normally, or at worst, a clean(!) shutdown (but
with still a message in syslog as to allow diagnosis).

I believe I’ve since figured out how to disable this in elogind.
From this, it might also affect systemd-based installations. I
might switch to no logind again…

In https://github.com/elogind/elogind/issues/177 the elogind upstream
maintainer asked me to do this:

# echo /dev/sda2 >/sys/power/resume
# cat /sys/power/resume
8:2
# echo platform >/sys/power/disk
# cat /sys/power/disk
[platform] shutdown reboot suspend test_resume
# echo disk >/sys/power/state

This indeed crashed my system just the same. The elogind maintainer
insists that “elogind has absolutely nothing to do with it.”

So this is probably a kernel issue.


-- Package-specific info:
** Version:
Linux version 5.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.0-17) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.9-1 (2020-11-19)

** Command line:
BOOT_IMAGE=/vmlinuz-5.9.0-3-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y 
vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0

** Not tainted

** Kernel log:
[3.164490] ata3.00: Enabling discard_zeroes_data
[3.165962] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/input/input2
[3.168150]  sda: sda1 sda2 sda3 sda4
[3.170404] ata3.00: Enabling discard_zeroes_data
[3.172392] sd 1:0:0:0: [sda] Attached SCSI disk
[9.250311] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[9.535687] random: crng init done
[9.595778] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist.
[   10.197469] input: Lid Switch as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input4
[   10.212554] ACPI: Lid Switch [LID]
[   10.213750] input: Sleep Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input5
[   10.218942] ACPI: Sleep Button [SLPB]
[   10.220538] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
[   10.221685] ACPI: Power Button [PWRF]
[   10.255108] parport_pc 00:06: reported by Plug and Play ACPI
[   10.269593] ACPI: AC Adapter [AC] (on-line)
[   10.269899] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
[   10.341046] Non-volatile memory driver v1.3
[   10.359109] yenta_cardbus :05:00.0: CardBus bridge found [17aa:20c6]
[   10.365576] iTCO_vendor_support: vendor-support=0
[   10.401729] thinkpad_acpi: ThinkPad ACPI Extras v0.26
[   10.403014] thinkpad_acpi: http://ibm-acpi.sf.net/
[   10.404302] thinkpad_acpi: ThinkPad BIOS 7NET30WW (1.11 ), EC 7MHT24WW-1.02
[   10.405666] thinkpad_acpi: Lenovo ThinkPad X61, model 7673AG4
[   10.411265] thinkpad_acpi: radio switch found; radios are enabled
[   10.412683] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
brightness control, supported by the ACPI video driver
[   10.414121] thinkpad_acpi: Disabling thinkpad-acpi brightness events by 
default...
[   10.417637] input: PC Speaker as /devices/platform/pcspkr/input/input8

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Thorsten Glaser]

Package: firmware-iwlwifi
Version: 20200918-1
Followup-For: Bug #934781
X-Debbugs-Cc: t...@mirbsd.de

It still happens.

[583944.226966] iwl4965 :03:00.0: Microcode SW error detected.  Restarting 
0x200.
[583944.226974] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24
[583944.226991] iwl4965 :03:00.0: Start IWL Error Log Dump:
[583944.226996] iwl4965 :03:00.0: Status: 0x000213E4, count: 5
[583944.227139] iwl4965 :03:00.0: Desc  
Time   data1  data2  line
[583944.227146] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 
2382371429 0x0002 0x0263 208
[583944.227150] iwl4965 :03:00.0: pc  blink1  blink2  ilink1  ilink2  
hcmd
[583944.227155] iwl4965 :03:00.0: 0x0046C 0x02156 0x004C2 0x006DA 0x005F2 
0x41E0048
[583944.227160] iwl4965 :03:00.0: FH register values:
[583944.227176] iwl4965 :03:00.0:   FH49_RSCSR_CHNL0_STTS_WPTR_REG: 
0X22aec200
[583944.227192] iwl4965 :03:00.0:  FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 
0X022ae4d0
[583944.227208] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 
0X0080
[583944.227224] iwl4965 :03:00.0:   FH49_MEM_RCSR_CHNL0_CONFIG_REG: 
0X80809000
[583944.227239] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 
0X003c
[583944.227255] iwl4965 :03:00.0:  FH49_MEM_RSSR_RX_STATUS_REG: 
0X0263
[583944.227271] iwl4965 :03:00.0:   FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 
0X
[583944.227286] iwl4965 :03:00.0:  FH49_TSSR_TX_STATUS_REG: 
0X07ff0002
[583944.227302] iwl4965 :03:00.0:   FH49_TSSR_TX_ERROR_REG: 
0X
[583944.228668] iwl4965 :03:00.0: Can't stop Rx DMA.
[583944.228708] ieee80211 phy0: Hardware restart was requested



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

Kernel: Linux 5.9.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.139

-- no debconf information

Bug#974646: W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for module i915

[Thorsten Glaser]

Package: firmware-misc-nonfree
Version: 20200918-1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de

I’m getting this during an upgrade in sid:

[…]
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.9.0-2-amd64
W: Possible missing firmware /lib/firmware/i915/rkl_dmc_ver2_01.bin for module 
i915
[…]

Graphics work, so I don’t know the impact.

This is on a Thinkpad X61, in case this is important.


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.139

-- no debconf information

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

On Mon, 3 Aug 2020, Thorsten Glaser wrote:

> keep the code I currently have that compares byte 0 and 3, using

Actually not. I’ve added some debugging code with…

static size_t
cmsg_actual_data_len(const struct cmsghdr *cmsg)
{
union {
const struct cmsghdr *cmsg;
const unsigned char *uc;
} ptr[(
/* compile-time assertions */
sizeof(socklen_t) <= sizeof(size_t)
) ? 1 : -1];
ptrdiff_t pd;

ptr[0].cmsg = cmsg;
pd = CMSG_DATA(cmsg) - ptr[0].uc;
return ((size_t)cmsg->cmsg_len - (size_t)pd);
}

… and dumping the received data on Linux and MidnightBSD
(the two systems I currently have access) and found varying
results but if this returns 4 I think I better consume an int.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

Hi Ben,

> For what it's worth, FreeBSD/Darwin and Windows also put 4 bytes of
> data in a IPV6_TCLASS cmsg.  So whether or not it's "right", it's
> consistent between three independent implementations.

oh, thank you, I don’t have any of these systems around at the
moment, so checking them was tricky for me.

So basically I should read an int in host endianness then (or
keep the code I currently have that compares byte 0 and 3, using
the one that’s not 0, if any). Great, thank you!

After some minor porting work, it turns out that the current code
does work on MidnightBSD (equivalent to FreeBSD 10.4) for IPv6.
I guess I’ll keep ints then.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

On Sun, 2 Aug 2020, Ben Hutchings wrote:

> The RFC says that the IPV6_TCLASS option's value is an int, and that

for setsockopt (“option's”), not cmsg

> No, the wording is *not* clear.

Agreed.

So perhaps let’s try to find out what’s actually right…

Thanks for helping,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

Ben Hutchings dixit:

>ip(7) also doesn't document IP_PKTOPIONS.

Hmm, I don’t use IP_PKTOPIONS though. I’m not exactly sure I found
the correct place in the kernel for what I do.

On the sending side, I use setsockopt with either
IPPROTO_IP,IP_TOS or IPPROTO_IPV6,IPV6_TCLASS to
set the default traffic class on outgoing packets.

On the receiving side I use setsockopt with either
IPPROTO_IP,IP_RECVTOS or IPPROTO_IPV6,IPV6_RECVTCLASS
to set up the socket then recvmsg to get a cmsg(3) of
IPPROTO_IP,IP_TOS/IPPROTO_IPV6,IPV6_TCLASS from which
I read the traffic class octet.

These are where I believe I found inconsistencies
between code and documentation.

>Those are two different APIs though: recvmsg() for datagram sockets, vs
>getsockopt(... IP_PKTOPTIONS ...) for stream sockets.  They obviously
>ought to be consistent, but mistakes happen.

OK, I’m currently looking at the datagram case only.
This may change later if there’s enough time.

>I see no point in changing the IPv6 behaviour: it seems to be
>consistent with itself and with the standard

Not really: if the kernel writes an int and userspace reads
its first byte, it only works by accident on little endian,
but not elsewhere.

>so only risks breaking user-space that works today.

Hrm. It risks breaking userspace that reads an int. But the
RFC clearly says it should read the first byte, not an int.

>But you should know that the highest priority for Linux API
>compatibility is to avoid breaking currently working user-space.  That
>means that ugly and inconsistent APIs won't get fixed if it causes a
>regression for the programs people actually use.  If the API never
>worked like it was supposed to on some architectures, that's not a
>regression, and is lower priority.

This is why I just put this up for discussion instead of
requesting a specific change.

That being said, given that the IPv6 API is *only* documented
in the RFC and *not* documented in the Linux manpages…

(Perhaps codesearching for IPV6_TCLASS might also help.
It’s unclear how many users this has…)



In the end, what I really want, is clear documentation for
how I should implement the following file that it works on
Linux, and ideally also other systems implementing the RFC
API (FreeBSD supposedly does but needs testing):

https://github.com/tarent/ECN-Bits/blob/master/linux-c/lib/ecn.c

Given that there’s no documentation, trying to read the
coffee grounds from the kernel source, finding it doesn’t
even match the RFC (which, again, doesn’t match what itojun
proposed, for some reason), does not instigate trust in the
things I *think* I’ve found.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#966459: linux: traffic class socket options (both IPv4/IPv6) inconsistent with docs/standards

[Thorsten Glaser]

Package: src:linux
Version: 5.7.6-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de

I’m using setsockopt to set the traffic class on sending and receive
it in control messages on receiving, for both IPv4 and IPv6.

The relevant documentation is the ip(7) manpage and, because the ipv6(7)
manpage doesn’t contain it, RFC3542.


For the receiving side, the corresponding socket options are:

• IPPROTO_IP ⇒ IP_RECVTOS, with an int argument 1 (as in the manpage)
• IPPROTO_IPV6 ⇒ IPV6_TCLASS, with an int argument 1 (as in the RFC)

The receiving CMSG is then supposed to contain the traffic class octet
as first byte in the corresponding CMSG_DATA:

   IP_RECVTOS (since Linux 2.2)
  If enabled, the IP_TOS ancillary message is passed with incoming
  packets.   It  contains  a byte which specifies the Type of Ser‐
  vice/Precedence field of the packet header.

… and…

   In the cmsghdr structure containing this ancillary data, the
   cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
   IPV6_TCLASS, and the first byte of cmsg_data[] will be the first byte
   of the integer traffic class.

However, Linux has net/ipv6/datagram.c…

int tclass = ipv6_get_dsfield(ipv6_hdr(skb));
put_cmsg(msg, SOL_IPV6, IPV6_TCLASS, sizeof(tclass), );

… and net/ipv6/ipv6_sockglue.c…

int tclass = (int)ip6_tclass(np->rcv_flowinfo);
put_cmsg(, SOL_IPV6, IPV6_TCLASS, 
sizeof(tclass), );

… both setting them as int, breaking standards/documentation-compliant
code on all big endian platforms. Same in net/ipv4/ip_sockglue.c…

int tos = inet->rcv_tos;
put_cmsg(, SOL_IP, IP_TOS, sizeof(tos), );
… in one place, but…

put_cmsg(msg, SOL_IP, IP_TOS, 1, _hdr(skb)->tos);

… in ip_cmsg_recv_tos(), yielding inconsistent results for IPv4(!).


For the sending side, we use:

• IPPROTO_IP, IP_TOS, with an argument…
• IPPROTO_IPV6, IPV6_TCLASS, with an argument…

This is funny. The documentation says to use a byte for IPv4…

   IP_TOS (since Linux 1.0)
  Set or receive the Type-Of-Service (TOS) field that is sent with
  every IP packet originating from this socket.   It  is  used  to
  prioritize  packets  on  the network.  TOS is a byte.  There are

… and setsockopt works with a byte argument, but for IPv6, using a
byte causes EINVAL (but this is because RFC3542 says int, overriding
the itojun draft which said byte).

Looking at the kernel code, IP_TOS indeed reads a byte if the size
given is less than 4, an int otherwise… except bpf_setsockopt, which
expects an int. OK, should be no problem for my userspace code.
IPV6_TCLASS always expects an int. Unexpected but apparently okay
wrt. the documentation.


tl;dr: Receiving traffic class values from IP traffic is broken on
big endian platforms.

I place the following suggestion for discussion, to achieve maximum
portability: put 4 bytes into the CMSG for both IPv4 and IPv6, where
the first and fourth byte are, identically, traffic class, second and
third 0.

Please forward this upstream. Thanks!



-- Package-specific info:
** Version:
Linux version 5.7.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 
(2020-06-24)

** Command line:
BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 root=/dev/sda4 ro rootdelay=5 syscall.x32=y 
vsyscall=emulate net.ifnames=0 kaslr pcie_aspm=force consoleblank=0

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 7673AG4
product_version: ThinkPad X61
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 7NET30WW (1.11 )
board_vendor: LENOVO
board_name: 7673AG4
board_version: Not Available

** Loaded modules:
ufs
hfs
dm_mod
loop
netlink_diag
snd_seq_dummy
cdc_acm
ctr
aes_generic
libaes
crypto_simd
cryptd
glue_helper
ccm
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
binfmt_misc
nft_counter
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
nft_compat
nf_tables
x_tables
nfnetlink
tun
snd_seq_midi
snd_seq_midi_event
snd_rawmidi
snd_seq
snd_seq_device
snd_hda_codec_analog
snd_hda_codec_generic
ppdev
iwl4965
coretemp
snd_hda_intel
iwlegacy
kvm_intel
snd_intel_dspcfg
pcmcia
kvm
snd_hda_codec
mac80211
snd_hda_core
snd_hwdep
snd_pcm_oss
irqbypass
snd_mixer_oss
cfg80211
serio_raw
pcspkr
snd_pcm
sg
iTCO_wdt
yenta_socket
iTCO_vendor_support
thinkpad_acpi
pcmcia_rsrc
watchdog
pcmcia_core
snd_timer
libarc4
nvram
ledtrig_audio
snd
soundcore
ac
rfkill
parport_pc
evdev
parport
button
acpi_cpufreq
ext4
crc16
mbcache
jbd2
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
ata_generic
i915
ata_piix
sdhci_pci
i2c_algo_bit
ahci

Bug#964681: klibc: FTBFS: ld: cannot use executable file 'usr/klibc/libc.so' as input to a link (was Re: Bug#964681: klibc: FTBFS: ENOENT (2) => "No such file or directory")

[Thorsten Glaser]

retitle 964681 klibc: FTBFS: ld: cannot use executable file 'usr/klibc/libc.so' 
as input to a link
thanks

Lucas Nussbaum dixit:

>>   ld -m elf_x86_64 --build-id=sha1 -o usr/kinit/ipconfig/shared/ipconfig  -e 
>> main usr/klibc/interp.o --start-group  usr/kinit/ipconfig/main.o 
>> usr/kinit/ipconfig/netdev.o usr/kinit/ipconfig/packet.o 
>> usr/kinit/ipconfig/dhcp_proto.o usr/kinit/ipconfig/bootp_proto.o  -R 
>> usr/klibc/libc.so /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a --end-group ; cp 
>> -f usr/kinit/ipconfig/shared/ipconfig usr/kinit/ipconfig/shared/ipconfig.g ; 
>> true --strip-all -R .comment -R .note --strip-all -R .comment -R .note 
>> --strip-all -R .comment -R .note usr/kinit/ipconfig/shared/ipconfig
>> ld: cannot use executable file 'usr/klibc/libc.so' as input to a link

This seems to be the real error.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)

[Thorsten Glaser]

Michael Biebl dixit:

>Is this workaround permanent or will systemd FTBFS again in the future?

I’ve just verified that the upstream-merged fix, appearing in
linux-libc-dev 5.7.6-1 in sid, fixes this permanently.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Thorsten Glaser]

Ben Hutchings dixit:

>This is the dpkg bug where it fails to replace a directory with a
>symlink.  For some reason that requires workarounds in every other
>package instead of being fixed in dpkg.

Yeah, this is annoying, but AIUI they call it a feature; a local
admin can symlink directories around if they suddenly lack space
on a partition (this was before bind mounts existed).

Thanks,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#962588: linux-image-amd64:amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Thorsten Glaser]

Package: linux-image-amd64
Version: 5.6.14-2
Severity: serious
Justification: Policy 2.3

tglase@tglase:~ $ ll /usr/share/doc/linux-image-amd64/
total 0
tglase@tglase:~ $ ll -d /usr/share/doc/linux-image-amd64
drwxr-xr-x 2 root root 4096 Okt 21  2019 /usr/share/doc/linux-image-amd64/


-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-amd64:amd64 depends on:
ii  linux-image-5.6.0-2-amd64  5.6.14-2

linux-image-amd64:amd64 recommends no packages.

linux-image-amd64:amd64 suggests no packages.

-- no debconf information

Bug#954294: [tip: x86/urgent] x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long" (fwd)

[Thorsten Glaser]

tags 954294 + fixed-upstream
thanks

-- Forwarded message --
From: tip-bot2 for Andy Lutomirski 
Message-ID: <159050477082.17951.1414743958663563425.tip-bot2@tip-bot2>
To: linux-tip-comm...@vger.kernel.org
Cc: Thorsten Glaser , Andy Lutomirski ,
Borislav Petkov , sta...@kernel.org, x86 ,
LKML 
Date: Tue, 26 May 2020 14:52:50 -
Subject: [tip: x86/urgent] x86/syscalls: Revert
"x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"
Reply-To: linux-ker...@vger.kernel.org

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: 700d3a5a664df267f01ec8887fd2d8ff98f67e7f
Gitweb:
https://git.kernel.org/tip/700d3a5a664df267f01ec8887fd2d8ff98f67e7f
Author:Andy Lutomirski 
AuthorDate:Fri, 08 May 2020 17:25:32 -07:00
Committer: Borislav Petkov 
CommitterDate: Tue, 26 May 2020 16:42:43 +02:00

x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"

Revert

  45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long")

and add a comment to discourage someone else from making the same
mistake again.

It turns out that some user code fails to compile if __X32_SYSCALL_BIT
is unsigned long. See, for example [1] below.

 [ bp: Massage and do the same thing in the respective tools/ header. ]

Fixes: 45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long")
Reported-by: Thorsten Glaser 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Borislav Petkov 
Cc: sta...@kernel.org
Link: [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294
Link: 
https://lkml.kernel.org/r/92e55442b744a5951fdc9cfee10badd0a5f7f828.1588983892.git.l...@kernel.org
---
 arch/x86/include/uapi/asm/unistd.h   | 11 +--
 tools/arch/x86/include/uapi/asm/unistd.h |  2 +-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/uapi/asm/unistd.h 
b/arch/x86/include/uapi/asm/unistd.h
index 196fdd0..be5e2e7 100644
--- a/arch/x86/include/uapi/asm/unistd.h
+++ b/arch/x86/include/uapi/asm/unistd.h
@@ -2,8 +2,15 @@
 #ifndef _UAPI_ASM_X86_UNISTD_H
 #define _UAPI_ASM_X86_UNISTD_H
 
-/* x32 syscall flag bit */
-#define __X32_SYSCALL_BIT  0x4000UL
+/*
+ * x32 syscall flag bit.  Some user programs expect syscall NR macros
+ * and __X32_SYSCALL_BIT to have type int, even though syscall numbers
+ * are, for practical purposes, unsigned long.
+ *
+ * Fortunately, expressions like (nr & ~__X32_SYSCALL_BIT) do the right
+ * thing regardless.
+ */
+#define __X32_SYSCALL_BIT  0x4000
 
 #ifndef __KERNEL__
 # ifdef __i386__
diff --git a/tools/arch/x86/include/uapi/asm/unistd.h 
b/tools/arch/x86/include/uapi/asm/unistd.h
index 196fdd0..30d7d04 100644
--- a/tools/arch/x86/include/uapi/asm/unistd.h
+++ b/tools/arch/x86/include/uapi/asm/unistd.h
@@ -3,7 +3,7 @@
 #define _UAPI_ASM_X86_UNISTD_H
 
 /* x32 syscall flag bit */
-#define __X32_SYSCALL_BIT  0x4000UL
+#define __X32_SYSCALL_BIT  0x4000
 
 #ifndef __KERNEL__
 # ifdef __i386__

Bug#959070: klibc-utils: fstype falsely claims to need an executable stack

[Thorsten Glaser]

Helge Deller dixit:

>On hppa/parisc we still need executable stacks for the signal
>trampoline return code. Might your patch then maybe break fstype on
>hppa? I didn't tested it...

I think it only changed the assembly parts of the library to
signal to the linker that there’s no need for an executable
stack on their account, but the signal handling code should¹
add one on hppa then.

① also not tested, maybe you should ☻

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#953522: W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw, rtl8168fp-3.fw for module r8169

[Thorsten Glaser]

Package: firmware-realtek
Version: 20190717-2
Followup-For: Bug #953522
Control: forcemerge 947356 953522
Control: retitle 947356 W: Possible missing firmware 
/lib/firmware/rtl_nic/rtl8125a-3.fw, rtl8168fp-3.fw for module r8169

The message is now:

update-initramfs: Generating /boot/initrd.img-5.5.0-2-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module 
r8169

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.136

-- no debconf information

Bug#954294: __X32_SYSCALL_BIT being defined as UL constant breaks userspace

[Thorsten Glaser]

On Wed, 8 Apr 2020, Andy Lutomirski wrote:

> One might reasonably ask whether it makes sense for syscall nrs to be
> signed at all.

It doesn’t, but it’s probably this way for hysteric raisins.

> But regardless, this breaks userspace and we should fix it.  I can
> whip up a patch to split it into X32_SYSCALL_BIT (unsigned long) and
> __X32_SYSCALL_BIT (uapi, int).  Thomas, etc, does this seem

This would help with the issue, thanks.

> reasonable?  (For those not following all the machinations, this
> change caused some userspace build failures in libseccomp and/or
> systemd for reasons that are vaguely silly.)

Not very silly:

printf("%d\n", __NR_mmap);

That with -Wformat and -Werror (or -Werror=format) rightfully warns,
as the compiler cannot, on x32 (where int=long), detect that, on
architectures where int≠long the constant is int.

Even worse, switching userspace to unsigned long globally would
completely hose this on LP64 architectures.

So this is, in my opinion, completely justified. (Disclaimer: I’m
not affiliated with systemd and not even running it except udev.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#956221: firmware-misc-nonfree: missing firmware i915/{icl_dmc_ver1_09,tgl_dmc_ver2_04,{skl,bxt,kbl,glk,cml,icl,ehl,tgl…

[Thorsten Glaser]

Package: firmware-misc-nonfree
Version: 20190717-2
Severity: normal

Setting up linux-image-5.5.0-1-amd64 (5.5.13-2) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-5.4.0-4-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-5.4.0-4-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-5.5.0-1-amd64
I: /initrd.img is now a symlink to boot/initrd.img-5.5.0-1-amd64
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-5.5.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_09.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/tgl_dmc_ver2_04.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_2.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_2.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/glk_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/cml_huc_4.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_33.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/icl_huc_9.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/ehl_huc_9.0.0.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_33.0.4.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/tgl_huc_7.0.3.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_35.2.0.bin for module 
i915


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

Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.136

-- no debconf information

Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to for

[Thorsten Glaser]

On Wed, 8 Apr 2020, Ben Hutchings wrote:

> You should not expect me to spend time talking to upstream about non-
> release architectures.  That is way down the priority list.

DevRef §5.8.3.(6) is a “must”, but you’re lucky: it turns out that
this is a recent isolated change, so I can write to the persons in
that commit. (Will do so in a follow-up mail, so they’re not confu‐
sed by Debian specifics.)

The rationale for DevRef §5.8.3.(6) is that I, as user, would not
know whom to contact on the upstream side: especially with the
Linux kernel, there’s tons of maintainers, subsystems, mailing
lists, etc. and I’d not have an idea where to contact. (Luckily,
I *was* able to isolate it… this time. But I expect you to do at
least the talking, generally.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#954294: __X32_SYSCALL_BIT being defined as UL constant breaks userspace

[Thorsten Glaser]

Hello,

I’m writing to you because your name shows up on this:

commit 45e29d119e9923ff14dfb840e3482bef1667bbfb
Author: Andy Lutomirski 
Date:   Wed Jul 3 13:34:05 2019 -0700

x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long

Currently, it's an int.  This is bizarre.  Fortunately, the code using it
still works: ~__X32_SYSCALL_BIT is also int, so, if nr is unsigned long,
then C kindly sign-extends the ~__X32_SYSCALL_BIT part, and it actually
results in the desired value.

This is far more subtle than it deserves to be.  Syscall numbers are, for
all practical purposes, unsigned long, so make __X32_SYSCALL_BIT be
unsigned long.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Thomas Gleixner 
Link: 
https://lkml.kernel.org/r/99b0d83ad891c67105470a1a6b63243fd63a5061.1562185330.git.l...@kernel.org

This commit changed an uapi header, breaking userspace. Long debugging
story (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294 if you
are interested) short, it goes like this:

libseccomp exposes an interface SCMP_SYS() which is designed to expand
to an int and be usable in cpp context. It redirects to the __NR_*
constants from .

Example: SCMP_SYS(mmap) becomes __NR_mmap or __NR_mmap2 (depending on
the architecture).

Now, most architectures define __NR_mmap as a mere integer number:

asm/unistd_32.h:#define __NR_mmap 90
asm/unistd_64.h:#define __NR_mmap 9

x32 differs:

asm/unistd_x32.h:#define __NR_mmap (__X32_SYSCALL_BIT + 9)

This construct is, thankfully, still usable in something like
#if (__NR_mmap > __NR_somethingelse)
but as __X32_SYSCALL_BIT is no longer int its type also isn’t.

Therefore I ask you to revert this change, bringing x32 closer
to all other architectures.

> Syscall numbers are, for
> all practical purposes, unsigned long

Yes, except for the one purpose of the C data type of the
syscall constants exposed to userspace, they are.

Feel free to handle __X32_SYSCALL_BIT differently in the
kernel (although even there it *will* introduce subtle
differences from other architectures), but please keep it
as int as visible from userspace.

Thanks in advance,
//mirabilos

PS: Please keep both me *and* the Debian bug in Cc, but
feel free to forward to relevant lists and persons;
I’m unsure where exactly to write to about this.

@bwh: commit 45e29d119e9923ff14dfb840e3482bef1667bbfb is
literally just this…
-#define __X32_SYSCALL_BIT  0x4000
+#define __X32_SYSCALL_BIT  0x4000UL
… so can you please revert it in Debian in the meantime,
even if you said you won’t spend time on this?
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#954294: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to format string errors, need explicit casts)

[Thorsten Glaser]

On Wed, 8 Apr 2020, Michael Biebl wrote:

>> Is this workaround permanent or will systemd FTBFS again in the future?

It is not inherently permanent. If a new libseccomp version gets
uploaded it will pop back up. In these cases, I’ll most likely
notice it due to Multi-Arch skew (my x32 system has libudev1:i386
and libudev1:x32 installed, so when the former shows up in apt’s
output of “not updated” packages I’ll know), and it’s a matter of
maybe half an hour to bring the hack back, and I’ve got permissions
to give-back the systemd package so the buildds will build it.

>> If seccomp support on x32 is causing so much trouble, we can just as
>> well disable it in systemd for the time being by dropping libseccomp-dev
>> from Build-Depends.

My hope is to get this fixed in the kernel headers instead; it
seems like a straight-forward fix, aligns x32 more with other
architectures and seems to be the technically more correct solution,
plus other packages might be similarily affected (but don’t show
it as they don’t build with -Werror=format).

>... on x32 only, of course.

Yes, of course.

>> Let me know what you prefer.

For now, don’t take any action in systemd, and we’ll hope some
kernel developer picks it up, but thanks for the offer.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#954294: linux: __X32_SYSCALL_BIT being defined as UL constant breaks userspace (was Re: libseccomp-dev: API break: SCMP_SYS() is unsigned long (was Re: Bug#954294: systemd: FTBFS on x32 due to for

[Thorsten Glaser]

Dear kernel team,

libseccomp uses the __NR_* constants from  in its
macro SCMP_SYS() which is designed to return int.

However, on x32 some codes return unsigned long instead, breaking this.
The cause is that this…

> /usr/include/x86_64-linux-gnux32/asm/unistd.h:#define __X32_SYSCALL_BIT 
> 0x4000UL

… is OR’d into the numbers.

I’d like to propose the change…
-#define __X32_SYSCALL_BIT 0x4000UL
+#define __X32_SYSCALL_BIT 0x4000
… which should be safe to do as the number fits into signed int,
but must be checked against other users (especially in the kernel
itself I’d guess).

This should also technically be correct, since on all(?) other
architectures syscall numbers are int constants.

Please forward this to upstream.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#941597: linux: [dtb] Raspberry Pi 3B+: does not shut down (regression against buster)

[Thorsten Glaser]

retitle 941597 linux: [dtb] Raspberry Pi 3B+: does not shut down (regression 
against buster)
found 941597 5.2.9-2~bpo10+1
found 941597 5.2.17-1~bpo10+1
found 941597 5.3.9-3
thanks

As I wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939633#29
this is an issue in the DTB shipped with the 5.x kernel (and it applies
to both 5.2 in backports and 5.3 in sid), working with the DTB from the
buster kernel (with the bpo/sid kernel).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#939633: linux: rpi3b+ hangs with kernels 5.2, 5.3 (device tree issue?)

[Thorsten Glaser]

On Wed, 20 Nov 2019, Thorsten Glaser wrote:

> Please advice as to a fix ☻

By the advice of the original poster of this bugreport, we tried to
use the DTB from the buster kernel instead:

+ cp /usr/lib/linux-image-4.19.0-6-arm64/broadcom/bcm2837-rpi-3-b.dtb 
/boot/firmware/bcm2710-rpi-3-b.dtb
+ cp /usr/lib/linux-image-4.19.0-6-arm64/broadcom/bcm2837-rpi-3-b-plus.dtb 
/boot/firmware/bcm2710-rpi-3-b-plus.dtb
+ cp /usr/lib/linux-image-4.19.0-6-arm64/broadcom/bcm2837-rpi-cm3-io3.dtb 
/boot/firmware/bcm2710-rpi-cm3.dtb

I’m attaching full serial console output of a boot with the stable DTB
and one with the unstable DTB. In both cases, we tried to get the system
to crash; in the 5.x one it died quickly, in the 4.x case we didn’t manage.

Notable differences:

• with the 4.x DTB, 'reboot' works (cf. #941597)
  (like with the stable kernel)
• with the 4.x DTB, WLAN firmware is missing, which does work with 5.x
• with the 4.x DTB, audio is not working (like with the stable kernel)
• with the 4.x DTB, 3D graphics still works (unlike the stable kernel)
• with the 4.x DTB (like the stable kernel), we get some lines à la…
[  570.800140] alloc_contig_range: [33550, 33552) PFNs busy
  … which are almost (but not completely) unheard of with the 5.x DTB
  (and which are, incidentally, also mentioned in #925334)

The 5.x DTB log ends with the CMA having been filled up (by a program
written in python3-pygame, at that) before the crashing line. This is
the same as #925334, except it afterwards crashes with…

[  307.942205] bcm2835-power bcm2835-power: Failed to disable ASB master for v3d

… whereas, in #925334, it continued with…

[  739.334049] vc4_v3d 3fc0.v3d: Failed to allocate memory for tile 
binning: -12. You may need to enable CMA or give it more memory.

… and ceased updating the screen until reboot (but did not crash the
system). *HOWEVER*, we also managed to crash the 5.x system without
overrunning the CMA, earlier, but we forgot to save serial console
output for that run (it was directly before I wrote the previous mail
to this bugreport).

The memory overrunning issue is effectively a local DoS, given it can
be triggered from unprivilegued userspace. (But, as I said above, the
crash can also be triggered without overrunning memory; mostly using
OpenGL.)

It might be useful to diff and bisect the DTB sources (with includes
expanded, probably), but I’ve not got any experience with DTBs or ARM
devices.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 5.3.0-2-arm64 (debian-kernel@lists.debian.org) 
(gcc version 9.2.1 20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-3 
(2019-11-19)
[0.00] Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: UEFI not found.
[0.00] cma: Reserved 128 MiB at 0x3340
[0.00] NUMA: No NUMA configuration found
[0.00] NUMA: Faking a node at [mem 
0x-0x3b3f]
[0.00] NUMA: NODE_DATA [mem 0x3320d840-0x3320efff]
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x-0x3b3f]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x3b3f]
[0.00] Initmem setup node 0 [mem 0x-0x3b3f]
[0.00] percpu: Embedded 32 pages/cpu s93016 r8192 d29864 u131072
[0.00] Detected VIPT I-cache on CPU0
[0.00] CPU features: detected: ARM erratum 845719
[0.00] CPU features: kernel page table isolation forced ON by KASLR
[0.00] CPU features: detected: Kernel page table isolation (KPTI)
[0.00] CPU features: detected: ARM erratum 843419
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 238896
[0.00] Policy zone: DMA32
[0.00] Kernel command line: video=HDMI-A-1:1920x1080@60 
dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0xa5e576b6 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:E5:76:B6 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=ttyS1,115200 
console=tty0 root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes 
net.ifnames=0 cma=128M rootwait
[0.00] Dentry cache hash table entries: 131072 (order: 8, 1048576 
bytes, lin

Bug#939633: linux: rpi3b+ hangs with kernels 5.2, 5.3 (device tree issue?)

[Thorsten Glaser]

retitle 939633 linux: rpi3b+ hangs with kernels 5.2, 5.3 (device tree issue?)
notfound 939633 4.19.67-2+deb10u1
notfound 939633 4.19.67-2+deb10u2
found 939633 5.2.9-2~bpo10+1
found 939633 5.2.17-1~bpo10+1
found 939633 5.3.9-3
thanks

We’re currently suffering from a similar situation.

Debian buster/arm64 installation, straight from this script:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=posix/mkrpi3b%2Bimg.sh;hb=HEAD

With the buster kernel, the analog audio doesn’t work, and
3D graphics using llvmpipe are really slow, but the system
is, overall, stable.

With the backports kernel and either buster’s raspi3-firmware
or sid’s raspi-firmware (tested both), 3D graphics are accelerated,
poweroff/reboot don’t work, and the system crashes after some
uptime (confirmed it’s not a thermal issue, and the official
PSU is used, so power is enough).

With the sid kernel and sid’s raspi-firmware, the same issue
happens. We managed to get a serial console running, and the
crash message is what led us to this bugreport:

[timestamp] bcm2835-power bcm2835-power: Failed to disable ASB master for v3d

This is a fairly stock setup, with CMA raised to 128M and
consoles fixed (see the outstanding bugreports in the
raspi3-firmware/raspi-firmware package), and video size fixed:

tglase@tglase:/mnt $ grep '^[^#]' etc/default/raspi-firmware
CMA=128M
CONSOLES='ttyS1,115200 tty0'
tglase@tglase:/mnt $ cat etc/default/raspi-firmware-custom 
disable_overscan=1


Incidentally, shortly before, we see this in syslog:

Jan  1 01:00:26 rpi3bplus kernel: [   26.255342] broken atomic modeset 
userspace detected, disabling atomic

Unsure whether it’s related.


Other things are reports in Fedora with instabilities relating
to the RPi 3B+ and power management…

Please advice as to a fix ☻

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#943425: klibc: [s390x] SIGSEGV in mksh testcase funsub-2

[Thorsten Glaser]

Control: block 943425 by 925358

I can’t debug this currently ☹ hitting qemu-user-static bugs.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#925358: klibc: [m68k] SIGKILL in mksh testcase mtest-external and others (in qemu only?)

[Thorsten Glaser]

tags 925358 - unreproducible
severity 925358 minor
affects 925358 src:mksh
retitle 925358 klibc: [m68k] SIGKILL in mksh testcase mtest-external and others 
(in qemu only?)
found 925358 2.0.7-1
affects 943425 src:mksh
thanks

This still happens. I’ll keep the bug so I can track it down.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#943425: klibc: [s390x] SIGSEGV in mksh testcase funsub-2

[Thorsten Glaser]

Package: libklibc-dev
Version: 2.0.7-1

When building mksh against klibc on s390x, one testcase positively fails:

FAIL ../../check.t:funsub-2
Description:
You can now reliably use local and return in funsubs
(not exit though)
unexpected exit status 11 (signal 11), expected 0
unexpected stdout - got too little output
wanted: 
1:ya x2,2,0.
2:ya x2,1,0.
3:ya,1,3.
got:
1:ya x2,2,0.
2:ya x2,1,0.

I’ll need to track this down later, filing the bug to remember.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#942861: linux-image-amd64: missing-copyright-file /usr/share/doc/linux-image-amd64/copyright

[Thorsten Glaser]

Package: linux-image-amd64
Version: 5.3.7-1
Severity: serious
Justification: Policy 12.5

adequate reports the file is missing, and is right. The directory is there,
but not a symbolic link and empty.

tglase@tglase-nb:~ $ ll -d /usr/share/doc/linux-image-amd64
drwxr-xr-x 2 root root 4096 Oct 22 15:50 /usr/share/doc/linux-image-amd64/
tglase@tglase-nb:~ $ ll  /usr/share/doc/linux-image-amd64
total 0


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.3.0-1-amd64  5.3.7-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#941597: linux-image-5.2.0-0.bpo.2-arm64: Raspberry Pi 3B+: does not shut down (regression against buster)

[Thorsten Glaser]

On Wed, 2 Oct 2019, Thorsten Glaser wrote:

> With the backports kernel, a Raspberry Pi 3B+ cannot be shut down

The messages when poweroff’ing:

Will now halt.
I: executing reboot "-d" "-f" "-i" "-p" "-h" regardless of check results.
[ 5182.389595] kvm: exiting hardware virtualization
[ 5182.398772] reboot: System halted

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#941597: linux-image-5.2.0-0.bpo.2-arm64: Raspberry Pi 3B+: does not shut down (regression against buster)

[Thorsten Glaser]

Package: src:linux
Version: 5.2.9-2~bpo10+1
Severity: normal

With the backports kernel, a Raspberry Pi 3B+ cannot be shut down
or rebooted; the buster kernel manages that (but does not have sound).

I’ve captured the last couple of lines on the screen: the first two
are from sysvinit, three kernel ones follow:


Will now restart.
I: executing reboot "-d" "-f" "-i" regardless of check results.
[ 1168.343056] kvm: exiting hardware virtualization
[ 1168.352199] reboot: Restarting system
[ 1168.358391] Reboot failed -- System halted


Note I have the following firmware package installed:

ii  raspi3-firmware 1.20190215-1+deb10u1 arm64Raspberry Pi 2 and 3 GPU 
firmware and bootloaders

I know unstable carries a later one, but that’s not in backports.
Not sure whether that would make a difference. Currently, the
kernel is the only backports package I have installed.


-- Package-specific info:
** Version:
Linux version 5.2.0-0.bpo.2-arm64 (debian-kernel@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 5.2.9-2~bpo10+1 (2019-08-25)

** Command line:
bcm2708_fb.fbwidth=1280 bcm2708_fb.fbheight=1024 bcm2708_fb.fbswap=1 
dma.dmachans=0x7f35 bcm2709.boardrev=0xa020d3 bcm2709.serial=0xa5e576b6 
bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=29 
bcm2709.disk_led_active_low=0 smsc95xx.macaddr=B8:27:EB:E5:76:B6 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  console=ttyS0,115200 
console=tty0 root=/dev/mmcblk0p2 rw elevator=deadline fsck.repair=yes 
net.ifnames=0 cma=128M rootwait

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[5.053654] dwc2 3f98.usb: irq 41, io mem 0x3f98
[5.059640] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, 
bcdDevice= 5.02
[5.065497] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[5.071349] usb usb1: Product: DWC OTG Controller
[5.077130] usb usb1: Manufacturer: Linux 5.2.0-0.bpo.2-arm64 dwc2_hsotg
[5.082902] usb usb1: SerialNumber: 3f98.usb
[5.089579] hub 1-0:1.0: USB hub found
[5.095483] hub 1-0:1.0: 1 port detected
[5.495140] usb 1-1: new high-speed USB device number 2 using dwc2
[5.713780] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, 
bcdDevice= b.b3
[5.719700] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[5.727468] hub 1-1:1.0: USB hub found
[5.733423] hub 1-1:1.0: 4 ports detected
[5.746030] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Opts: (null)
[6.027120] usb 1-1.1: new high-speed USB device number 3 using dwc2
[6.049550] Not activating Mandatory Access Control as /sbin/tomoyo-init 
does not exist.
[6.131504] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2514, 
bcdDevice= b.b3
[6.137581] usb 1-1.1: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[6.144425] hub 1-1.1:1.0: USB hub found
[6.150479] hub 1-1.1:1.0: 3 ports detected
[6.443150] usb 1-1.1.2: new low-speed USB device number 4 using dwc2
[6.561074] usb 1-1.1.2: New USB device found, idVendor=1241, 
idProduct=1177, bcdDevice= 2.70
[6.567077] usb 1-1.1.2: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[6.655174] usb 1-1.1.3: new low-speed USB device number 5 using dwc2
[6.764926] usb 1-1.1.3: New USB device found, idVendor=413c, 
idProduct=2106, bcdDevice= 1.01
[6.771086] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[6.777081] usb 1-1.1.3: Product: Dell QuietKey Keyboard
[6.782996] usb 1-1.1.3: Manufacturer: DELL
[7.011214] usb 1-1.1.1: new high-speed USB device number 6 using dwc2
[7.119877] usb 1-1.1.1: New USB device found, idVendor=0424, 
idProduct=7800, bcdDevice= 3.00
[7.125885] usb 1-1.1.1: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[7.262851] random: crng init done
[7.381018] systemd-udevd[357]: Network interface NamePolicy= disabled on 
kernel command line, ignoring.
[8.250758] vchiq: module is from the staging directory, the quality is 
unknown, you have been warned.
[8.273456] vchiq: vchiq_init_state: slot_zero = fa164383
[8.316841] bcm2835-rng 3f104000.rng: hwrng registered
[8.380910] systemd-udevd[374]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
[8.589125] hidraw: raw HID events driver (C) Jiri Kosina
[8.614860] libphy: Fixed MDIO Bus: probed
[8.700164] usbcore: registered new interface driver usbhid
[8.707013] usbhid: USB HID core driver
[8.919856] lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No 
External EEPROM. Setting MAC Speed
[8.928383] libphy: lan78xx-mdiobus: probed
[9.113656] media: Linux media interface: v0.10
[9.174565] usbcore: registered new interface driver lan78xx
[9.237491] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio 
for chip BCM4345/6
[9.245368] usbcore: registered new 

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Thorsten Glaser]

Package: firmware-iwlwifi
Version: 20190717-1
Severity: normal

My WLAN just crashed, no load (an ssh session and some chat).

Full dmesg (microcode error shown near bootom) follows:

[0.00] microcode: microcode updated early to revision 0xba, date = 
2010-10-03
[0.00] Linux version 4.19.0-5-amd64 (debian-kernel@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 4.19.37-6 (2019-07-18)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/sda4 
ro rootdelay=5 syscall.x32=y vsyscall=emulate net.ifnames=0 kaslr 
pcie_aspm=force consoleblank=0
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbf6a] usable
[0.00] BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf70-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023bff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: LENOVO 7673AG4/7673AG4, BIOS 7NET30WW (1.11 ) 11/15/2007
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 1995.136 MHz processor
[0.011703] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.011707] e820: remove [mem 0x000a-0x000f] usable
[0.011715] last_pfn = 0x23c000 max_arch_pfn = 0x4
[0.011723] MTRR default type: uncachable
[0.011724] MTRR fixed ranges enabled:
[0.011725]   0-9 write-back
[0.011726]   A-B uncachable
[0.011727]   C-C write-protect
[0.011728]   D-D uncachable
[0.011729]   E-F write-protect
[0.011730] MTRR variable ranges enabled:
[0.011732]   0 base 0C000 mask FC000 uncachable
[0.011734]   1 base 23C00 mask FFC00 uncachable
[0.011735]   2 base 0 mask E write-back
[0.011736]   3 base 2 mask FC000 write-back
[0.011738]   4 base 0BF70 mask 0 uncachable
[0.011739]   5 base 0BF80 mask FFF80 uncachable
[0.011740]   6 disabled
[0.011741]   7 disabled
[0.012744] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.013193] e820: update [mem 0xbf70-0x] usable ==> reserved
[0.013201] last_pfn = 0xbf6b0 max_arch_pfn = 0x4
[0.021443] found SMP MP-table at [mem 0x000f6980-0x000f698f]
[0.027758] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.027765] BRK [0x21ea01000, 0x21ea01fff] PGTABLE
[0.027768] BRK [0x21ea02000, 0x21ea02fff] PGTABLE
[0.027770] BRK [0x21ea03000, 0x21ea03fff] PGTABLE
[0.027823] BRK [0x21ea04000, 0x21ea04fff] PGTABLE
[0.027826] BRK [0x21ea05000, 0x21ea05fff] PGTABLE
[0.028021] BRK [0x21ea06000, 0x21ea06fff] PGTABLE
[0.028042] BRK [0x21ea07000, 0x21ea07fff] PGTABLE
[0.028089] BRK [0x21ea08000, 0x21ea08fff] PGTABLE
[0.028155] BRK [0x21ea09000, 0x21ea09fff] PGTABLE
[0.028176] BRK [0x21ea0a000, 0x21ea0afff] PGTABLE
[0.028197] BRK [0x21ea0b000, 0x21ea0bfff] PGTABLE
[0.028217] BRK [0x21ea0c000, 0x21ea0cfff] PGTABLE
[0.028267] RAMDISK: [mem 0x33f8b000-0x35fbcfff]
[0.028279] ACPI: Early table checksum verification disabled
[0.028358] ACPI: RSDP 0x000F6950 24 (v02 LENOVO)
[0.028364] ACPI: XSDT 0xBF6BD48C 94 (v01 LENOVO TP-7N
1110  LTP )
[0.028372] ACPI: FACP 0xBF6BD600 F4 (v03 LENOVO TP-7N
1110 LNVO 0001)
[0.028378] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Gpe0Block: 64/32 (20180810/tbfadt-569)
[0.028382] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid 
Address but zero Length: 0x102C/0x0 (20180810/tbfadt-624)
[0.028389] ACPI: DSDT 0xBF6BD9DB 00E206 (v01 LENOVO TP-7N
1110 MSFT 0300)
[0.028394] ACPI: FACS 0xBF6E4000 40
[0.028398] ACPI: 

Re: Bug#932199: insserv: warning: could not find all dependencies for $portmap

[Thorsten Glaser]

On Thu, 18 Jul 2019, Dmitry Bogatov wrote:

> On my system, $x-display-manager is defined in /etc/insserv.conf.d/xdm;
> on headless box there is no display manager, hence warning.  Situation
> with $portmap seems similar.

Indeed, I also ran into the $x-display-manager one after having
reported the $portmap one.

> This warning was introduced in upstream [ddd9d38] with following
> changelog:
> 
>   - When an initscript contains a "$service" dependency which cannot be
> resolved (ie $service does not expand or does not exist) insserv
> will display a warning. The initscript is still added.
> 
> Seems problem is that warning emitted not only for hard, but only for
> soft dependencies. Patch at bottom.
> 
> Please check whether is solves all problems.

I’d assume so but since it was only a warning I can now reboot without
fear ☻

> > /etc/init.d/mountnfs.sh is from initscripts (= 2.93-8).  Perhaps it
> > ought to be moved to nfs-common or so? That being said, nfs-common
> > does not Depends on portmap either…

That being said, it Depends on rpcbind which Provides portmap nowadays,
so I’d guess that will be it.

> Sounds reasonable. Created bug.

OK, thanks!

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#930522: linux: task md5_raid6:203 blocked for more than 120 seconds

[Thorsten Glaser]

On Fri, 14 Jun 2019, Thorsten Glaser wrote:

> Currently hanging processes:

Of course, sending the bug mail also failed, while I could
still do “virsh -c qemu:///system list --all”, which was
almost certainly not in the cache.

13610 ?D  0:00 /usr/sbin/postdrop -r
13615 ?D  0:00 cleanup -z -t unix -u -c

Funny thing though, trying to write a mail with pine showed
a temporary text file comprised of only 0x55 (and a hanging
alpine process) while others worked:

tglase@tglase:~ $ touch down
tglase@tglase:~ $ echo down >downdown
tglase@tglase:~ $ ll
[…]
-rw-r--r--   1 tglase tglase 0 Jun 14 16:03 down
-rw-r--r--   1 tglase tglase 5 Jun 14 16:03 downdown
[…]
tglase@tglase:~ $ cat downdown
down
tglase@tglase:~ $ cat ./\#pico13934\#
UUU[…]


I eventually had to reboot by power-cycling, and all those
files never showed up in ls after it, whereas /lost+found
is still empty; fsck (and RAID rebuild) messages were a lot
during the new boot though… so, _something_ probably made
it to disc.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#930522: linux: task md5_raid6:203 blocked for more than 120 seconds

[Thorsten Glaser]

Package: linux-image-4.19.0-5-amd64
Version: 4.19.37-3
Severity: important

We’re back to tasks hanging, 99% of CPU being in wait.
This is somewhat similar to #913138 but not identical:
HDD reads seem to still work, as do some new writes,
but not all of them (e.g. I can run reportbug, but not
“man reportbug”; I can start new shells, which call
ansiweather and store the result, but I cannot run a
new Firefox instance; I can run sudo dmesg (below),
but not zless the linux-image-4.19.0-5-amd64 changelog).

dmesg has this:

[0.00] microcode: microcode updated early to revision 0x1d, date = 
2018-05-11
[0.00] Linux version 4.19.0-5-amd64 (debian-kernel@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr l1tf=flush,nosmt
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfec] usable
[0.00] BIOS-e820: [mem 0xcfed-0xcfed0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfed1000-0xcfed] ACPI data
[0.00] BIOS-e820: [mem 0xcfee-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00062fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. X58-USB3/X58-USB3, BIOS F5 
09/07/2011
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3064.513 MHz processor
[0.005423] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.005427] e820: remove [mem 0x000a-0x000f] usable
[0.005436] last_pfn = 0x63 max_arch_pfn = 0x4
[0.005443] MTRR default type: uncachable
[0.005444] MTRR fixed ranges enabled:
[0.005445]   0-9 write-back
[0.005447]   A-B uncachable
[0.005448]   C-CDFFF write-protect
[0.005449]   CE000-E uncachable
[0.005450]   F-F write-through
[0.005451] MTRR variable ranges enabled:
[0.005453]   0 base 0 mask F write-back
[0.005455]   1 base 0E000 mask FE000 uncachable
[0.005456]   2 base 0D000 mask FF000 uncachable
[0.005458]   3 base 1 mask F write-back
[0.005459]   4 base 2 mask E write-back
[0.005460]   5 base 4 mask C write-back
[0.005462]   6 base 5 mask F write-back
[0.005463]   7 base 6 mask FC000 write-back
[0.006397] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.006911] e820: update [mem 0xd000-0x] usable ==> reserved
[0.006918] last_pfn = 0xcfed0 max_arch_pfn = 0x4
[0.016355] found SMP MP-table at [mem 0x000f5a60-0x000f5a6f]
[0.029287] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.029295] BRK [0x33d401000, 0x33d401fff] PGTABLE
[0.029297] BRK [0x33d402000, 0x33d402fff] PGTABLE
[0.029299] BRK [0x33d403000, 0x33d403fff] PGTABLE
[0.029341] BRK [0x33d404000, 0x33d404fff] PGTABLE
[0.029345] BRK [0x33d405000, 0x33d405fff] PGTABLE
[0.029479] BRK [0x33d406000, 0x33d406fff] PGTABLE
[0.029504] BRK [0x33d407000, 0x33d407fff] PGTABLE
[0.029528] BRK [0x33d408000, 0x33d408fff] PGTABLE
[0.029577] BRK [0x33d409000, 0x33d409fff] PGTABLE
[0.030140] RAMDISK: [mem 0x34252000-0x36120fff]
[0.030152] ACPI: Early table checksum verification disabled
[0.033915] ACPI: RSDP 0x000F7200 14 (v00 GBT   )
[0.033921] ACPI: RSDT 0xCFED1040 48 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033930] ACPI: FACP 0xCFED1100 74 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033939] ACPI: DSDT 0xCFED11C0 00391C (v01 GBTGBTUACPI 
1000 MSFT 010C)
[0.033946] ACPI: FACS 0xCFED 40
[0.033951] ACPI: MSDM 0xCFED4CC0 55 (v03 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033957] ACPI: HPET 0xCFED4D80 38 (v01 GBTGBTUACPI 
42302E31 GBTU 0098)
[0.033964] ACPI: MCFG 0xCFED4E00 3C (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.033970] ACPI: EUDS 0xCFED4E40 0004D0 (v01 GBT 
  )
[0.033976] ACPI: MATS 0xCFED5310 34 (v01 GBT 
  )
[

Bug#925379: linux-base: linux-version vmlinuz/vmlinux dichotomy, breaks at least m68k

[Thorsten Glaser]

Package: linux-base
Version: 4.5
Severity: important
Control: affects -1 initramfs-tools

Some time between 4.1.0-2 and 4.19.0-3, m68k kernels switched
from vmlinuz-* to vmlinux-*:

-rwxr-xr-x 1 root root 5933276 Feb 11 16:55 vmlinux-4.19.0-3-m68k*
-rwxr-xr-x 1 root root 5933284 Mar 15 02:16 vmlinux-4.19.0-4-m68k*
-rw-r--r-- 1 root root 1769849 Aug 26  2015 vmlinuz-4.1.0-2-m68k

I was surprised by that 4.1.0-2 was the initrd updated by the
initramfs-tools trigger on e2fsprogs update, before I purged
(apt-get --purge autoremove) the 4.1.0-2 kernel, having just
received the 4.19.0-4 one in a dist-upgrade.

This is because /usr/share/perl5/DebianLinux.pm was not updated
accordingly:

# Find kernel image name stem for this architecture
my $image_stem;
if ((uname())[4] =~ /^(?:mips|parisc|powerpc|ppc)/) {
$image_stem = 'vmlinux';
} else {
$image_stem = 'vmlinuz';
}

Since architectures can have both vmlinux-* and vmlinuz-*,
I think this logic should be reconsidered and removed, as
to instead take kernel images from both basenames.

At the absolutely very least, it must be brought in line
with current practicēs… however, that may break during
upgrades, so, please redo it taking both names into account.

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k

Kernel: Linux 4.19.0-3-m68k
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages linux-base depends on:
ii  debconf [debconf-2.0]  1.5.71

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
* linux-base/disk-id-convert-auto: true
  linux-base/removing-title:
* linux-base/disk-id-manual-boot-loader:
  linux-base/disk-id-convert-plan-no-relabel: true
* linux-base/disk-id-convert-plan: true
  linux-base/removing-running-kernel: true
  linux-base/disk-id-manual:
  linux-base/do-bootloader-default-changed:
  linux-base/disk-id-update-failed:

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Thorsten Glaser]

Hi Cesare,

> But, in the meantime, doesn't the workaround of disabling blk_mq work
> for you?

I don’t know, because I have no means to trigger the bug. The three
other virtualisators I’ve upgraded at the same time did not trigger it.
My desktop machine also hits it only occasionally.

I’ve rebooted all four of them with the two kernel options, in the hopes
of staving off the bug, but in grub.cfg only, so they go away when the
fixed kernel will arrive.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Thorsten Glaser]

Hi Debian Linux kernel maintainers,

On Wed, 27 Feb 2019, Dragan Milenkovic wrote:
> > Hello Dragan, do you know if the patch was eventually included upstream and
> > possibly in which version?
> 
> Hello, Cesare. It was included in 4.20.11 and 4.19.24.

please do consider uploading 4.19.24 to buster/sid with some haste.
We have headless virtualisation hosts being unreachable/frozen now,
and while these are “only” development systems, this is untenable.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Thorsten Glaser]

severity 913119 serious
found 913119 4.19.16-1
thanks

On Wed, 13 Feb 2019, Dragan Milenkovic wrote:

> Jens Axboe has determined that the proper fix is quite different:
> 
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus=85bd6e61f34dffa8ec2dc75ff3c02ee7b2f1cbce
> 
> This patch is already on its way to stable branches. I have tested it and
> confirmed that it resolves the problem.

I haven’t, but I’ve just run into this in a very uncomfortable
situation: I’ve just upgraded several virtualisation hosts from
jessie or stretch to buster, and one of them just started to
hang with exactly this problem. (They are all set up as LVM on
RAID, too, no cryptsetup.)

Ben et al. please do consider the fix for buster, otherwise
it’ll be unusable for this kind of setup.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#923272: linux: 50 s delay during boot [m68k, atari, ARAnyM]

[Thorsten Glaser]

Package: src:linux
Version: 4.19.20-1
Severity: normal

linux-image-4.19.0-3-m68k takes massively longer to boot
than linux-image-4.1.0-2-m68k did (on an ARAnyM VM Atari
using NatFeat network/disc/…):

-BEGIN boot log of linux-image-4.19.0-3-m68k-
Running Aranym headlessly
ARAnyM 1.0.2
Using config file: 'aranym.config.ssh'
Could not open joystick 0
ARAnyM RTC Timer: /dev/rtc: Permission denied
Blitter tried to read byte from register ff8a00 at 006dee
[0.00] Linux version 4.19.0-3-m68k (debian-kernel@lists.debian.org) 
(gcc version 8.2.0 (Debian 8.2.0-19)) #1 Debian 4.19.20-1 (2019-02-11)
[0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC 
DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
[0.00] NatFeats found (ARAnyM, 1.0)
[0.00] initrd: 2ff5ec00 - 3100
[0.00] Built 2 zonelists, mobility grouping on.  Total pages: 198237
[0.00] Kernel command line: root=/dev/nfhd8p1 console=nfcon 
devtmpfs.mount=1 BOOT_IMAGE=vmlinux
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 768812K/800768K available (2867K kernel code, 393K 
rwdata, 1004K rodata, 156K init, 202K bss, 31956K reserved, 0K cma-reserved)
[0.00] random: get_random_u32 called from 
__kmem_cache_create+0x2c/0x498 with crng_init=0
[0.00] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=8
[0.00] NR_IRQS: 200
[0.00] Console: colour dummy device 80x25
[0.09] Calibrating delay loop... 64.71 BogoMIPS (lpj=323584)
[0.09] pid_max: default: 32768 minimum: 301
[0.09] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.09] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.14] devtmpfs: initialized
[0.16] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.16] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.17] NET: Registered protocol family 16
[0.25] SCSI subsystem initialized
[0.26] VFS: Disk quotas dquot_6.6.0
[0.26] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[0.36] NET: Registered protocol family 2
[0.38] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 
bytes)
[0.38] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[0.38] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[0.38] TCP: Hash tables configured (established 8192 bind 8192)
[0.38] UDP hash table entries: 512 (order: 1, 8192 bytes)
[0.38] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
[0.39] NET: Registered protocol family 1
[0.39] NET: Registered protocol family 44
[0.39] Unpacking initramfs...
[1.96] Freeing initrd memory: 17028K
[1.96] nfhd8: found device with 20971440 blocks (512 bytes)
[1.97]  nfhd8: AHDI p1 p2
[1.98] console [nfcon0] enabled
[1.98] nfeth: API 5
[1.99] eth0: nfeth addr:192.168.0.1 (192.168.0.2) 
HWaddr:52:54:00:22:00:01
[2.00] workingset: timestamp_bits=11 max_order=18 bucket_order=7
[2.20] zbud: loaded
[2.56] random: fast init done
[   51.43] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
251)
[   51.43] io scheduler noop registered
[   51.44] io scheduler cfq registered (default)
[   51.44] io scheduler mq-deadline registered
[   51.45] atafb_init: start
[   51.45] atafb_init: initializing Falcon hw
[   51.45] atafb: screen_base (ptrval) phys_screen_base ccb000 screen_len 
311296
[   51.45] Determined 640x480, depth 4
[   51.45]virtual 640x972
[   51.47] Console: switching to colour frame buffer device 80x30
[   51.49] fb0: frame buffer device, using 304K of video memory
[   51.50] pmac_zilog: 0.6 (Benjamin Herrenschmidt 
)
[   51.50] Non-volatile memory driver v1.3
[   51.51] mousedev: PS/2 mouse device common for all mice
[   51.76] input: Atari Keyboard as /devices/virtual/input/input0
[   51.82] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[   51.82] ledtrig-cpu: registered to indicate activity on CPUs
[   51.82] NET: Registered protocol family 17
[   51.82] mpls_gso: MPLS GSO support
[   51.83] registered taskstats version 1
[   51.83] zswap: loaded using pool lzo/zbud
[   51.90] rtc-generic rtc-generic: setting system clock to 2019-02-25 
17:04:44 UTC (1551114284)
[   51.90] Freeing unused kernel memory: 156K
[   51.90] This architecture does not have kernel memory protection.
[   51.90] Run /init as init process
Loading, please wait...
Starting version 241
[   56.89] scsi host0: Atari native SCSI, irq 15, io_port 0x0, base 0x0, 
can_queue 1, cmd_per_lun 

Bug#913138: many processes hanging in D state on RAID + LVM + ext4fs

[Thorsten Glaser]

Dixi quod…

>I’ve managed to write 'w' to sysctl during this,

Interestingly enough, the system recovered in the meantime,
but dmesg doesn’t have anything new.

This is really annoying!

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#913138: many processes hanging in D state on RAID + LVM + ext4fs

[Thorsten Glaser]

I’ve managed to write 'w' to sysctl during this,
perhaps the extra info helps:

[5441048.401704] sysrq: SysRq : This sysrq operation is disabled.
[5441118.394845] sysrq: SysRq : Show Blocked State
[5441118.394853]   taskPC stack   pid father
[5441118.394904] md5_raid6   D0   224  2 0x8000
[5441118.394909] Call Trace:
[5441118.394921]  ? __schedule+0x2b7/0x880
[5441118.394925]  schedule+0x28/0x80
[5441118.394937]  md_super_wait+0x6e/0xa0 [md_mod]
[5441118.394943]  ? finish_wait+0x80/0x80
[5441118.394951]  write_page+0x249/0x330 [md_mod]
[5441118.394955]  ? __schedule+0x2bf/0x880
[5441118.394963]  md_update_sb.part.65+0x367/0x840 [md_mod]
[5441118.394972]  md_check_recovery+0x4ab/0x570 [md_mod]
[5441118.394981]  raid5d+0x56/0x660 [raid456]
[5441118.394987]  ? lock_timer_base+0x67/0x80
[5441118.394990]  ? try_to_del_timer_sync+0x4d/0x80
[5441118.394994]  ? del_timer_sync+0x35/0x40
[5441118.394998]  ? schedule_timeout+0x181/0x380
[5441118.395006]  ? md_rdev_init+0xb0/0xb0 [md_mod]
[5441118.395012]  ? md_thread+0x122/0x160 [md_mod]
[5441118.395019]  ? handle_active_stripes.isra.61+0x5c0/0x5c0 [raid456]
[5441118.395026]  md_thread+0x122/0x160 [md_mod]
[5441118.395030]  ? finish_wait+0x80/0x80
[5441118.395034]  kthread+0x113/0x130
[5441118.395038]  ? kthread_create_worker_on_cpu+0x70/0x70
[5441118.395041]  ret_from_fork+0x35/0x40
[5441118.395047] jbd2/dm-0-8 D0   307  2 0x8000
[5441118.395051] Call Trace:
[5441118.395055]  ? __schedule+0x2b7/0x880
[5441118.395059]  ? finish_wait+0x80/0x80
[5441118.395063]  schedule+0x28/0x80
[5441118.395070]  md_write_start+0x1ad/0x210 [md_mod]
[5441118.395074]  ? finish_wait+0x80/0x80
[5441118.395078]  ? finish_wait+0x80/0x80
[5441118.395084]  raid5_make_request+0x85/0xb30 [raid456]
[5441118.395090]  ? generic_make_request+0x64/0x400
[5441118.395093]  ? finish_wait+0x80/0x80
[5441118.395103]  ? __split_and_process_non_flush+0x116/0x220 [dm_mod]
[5441118.395107]  ? finish_wait+0x80/0x80
[5441118.395114]  md_handle_request+0x119/0x190 [md_mod]
[5441118.395123]  md_make_request+0x65/0x150 [md_mod]
[5441118.395126]  generic_make_request+0x1a4/0x400
[5441118.395130]  ? submit_bio+0x6c/0x140
[5441118.395133]  submit_bio+0x6c/0x140
[5441118.395138]  ? guard_bio_eod+0x2c/0xf0
[5441118.395142]  submit_bh_wbc+0x163/0x190
[5441118.395151]  jbd2_journal_commit_transaction+0x669/0x1810 [jbd2]
[5441118.395155]  ? __switch_to_asm+0x40/0x70
[5441118.395158]  ? __switch_to_asm+0x34/0x70
[5441118.395162]  ? __switch_to_asm+0x40/0x70
[5441118.395170]  ? kjournald2+0xbd/0x270 [jbd2]
[5441118.395176]  kjournald2+0xbd/0x270 [jbd2]
[5441118.395181]  ? finish_wait+0x80/0x80
[5441118.395187]  ? commit_timeout+0x10/0x10 [jbd2]
[5441118.395190]  kthread+0x113/0x130
[5441118.395194]  ? kthread_create_worker_on_cpu+0x70/0x70
[5441118.395197]  ret_from_fork+0x35/0x40
[5441118.395286] tlsmgr  D0  1744  29176 0x6000
[5441118.395290] Call Trace:
[5441118.395294]  ? __schedule+0x2b7/0x880
[5441118.395298]  ? finish_wait+0x80/0x80
[5441118.395302]  schedule+0x28/0x80
[5441118.395309]  md_write_start+0x1ad/0x210 [md_mod]
[5441118.395314]  ? finish_wait+0x80/0x80
[5441118.395317]  ? finish_wait+0x80/0x80
[5441118.395324]  raid5_make_request+0x85/0xb30 [raid456]
[5441118.395328]  ? generic_make_request+0x64/0x400
[5441118.395332]  ? finish_wait+0x80/0x80
[5441118.395340]  ? __split_and_process_non_flush+0x116/0x220 [dm_mod]
[5441118.395344]  ? finish_wait+0x80/0x80
[5441118.395351]  md_handle_request+0x119/0x190 [md_mod]
[5441118.395359]  md_make_request+0x65/0x150 [md_mod]
[5441118.395363]  generic_make_request+0x1a4/0x400
[5441118.395367]  ? submit_bio+0x6c/0x140
[5441118.395371]  ? tag_pages_for_writeback+0xf5/0x170
[5441118.395375]  submit_bio+0x6c/0x140
[5441118.395379]  ? kmem_cache_alloc+0x1aa/0x1c0
[5441118.395406]  ext4_io_submit+0x48/0x60 [ext4]
[5441118.395425]  ext4_writepages+0x3ee/0xea0 [ext4]
[5441118.395432]  ? do_writepages+0x4b/0xe0
[5441118.395450]  ? ext4_mark_inode_dirty+0x1d0/0x1d0 [ext4]
[5441118.395453]  do_writepages+0x4b/0xe0
[5441118.395457]  ? __generic_file_write_iter+0x192/0x1c0
[5441118.395461]  ? unix_stream_recvmsg+0x53/0x70
[5441118.395464]  ? __unix_insert_socket+0x50/0x50
[5441118.395481]  ? ext4_file_write_iter+0x20c/0x3e0 [ext4]
[5441118.395484]  ? __filemap_fdatawrite_range+0xc1/0x100
[5441118.395487]  __filemap_fdatawrite_range+0xc1/0x100
[5441118.395492]  file_write_and_wait_range+0x4c/0xa0
[5441118.395508]  ext4_sync_file+0x106/0x3a0 [ext4]
[5441118.395513]  do_fsync+0x38/0x60
[5441118.395517]  __x64_sys_fdatasync+0x13/0x20
[5441118.395522]  do_syscall_64+0x55/0x110
[5441118.395526]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[5441118.395530] RIP: 0033:0xf59d5624
[5441118.395532] Code: Bad RIP value.
[5441118.395539] RSP: 002b:ffd102d8 EFLAGS: 0246 ORIG_RAX: 
404b
[5441118.395543] RAX: ffda RBX: 0064 RCX: 
f59d5624
[5441118.395546] RDX: 

Bug#918036: [PATCH v15 23/26] sched: early boot clock (was Re: Bug#918036: linux: uptime after reboot wrong (kvm-clock related?))

[Thorsten Glaser]

Hi Salvatore,

>p.s.: my earlier reply to you seem to have been rejected and never
>  reached you, hope this one does now.

if you sent from Googlemail, it may reach me in the next weeks or
never *shrug* they don’t play nice with greylisting. The -submitter
or @d.o works, though. I’m following up from my $dayjob address as
the issue occurred there (which is also Googlemail, unfortunately).

>There was now a followup on this, and if you can I think it's best if
>you can followup there.
>
>https://lore.kernel.org/lkml/ca+ck2bc70pnl0wimb0xt99j4nnfi8w3zuuhgak-jspuop9j...@mail.gmail.com/

OK, doing now:


Pavel Tatashin wrote:

>Could you please send the config file and qemu arguments that were
>used to reproduce this problem.

This is from a libvirt-managed system. The arguments as shown by
“ps axwww” are:

qemu-system-x86_64 -enable-kvm -name ci-busyapps -S -machine 
pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 
2,sockets=2,cores=1,threads=1 -uuid 09536d92-dd73-8993-78fb-e0c885acf763 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/ci-busyapps.monitor,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/dev/vms/ci-busyapps,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:05:6e:fd,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-device usb-tablet,id=input0 -vnc 127.0.0.1:0 -device 
cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on

I’ve attached the kernel configuration; this is a stock Debian
unstable/amd64 system, just upgraded. After upgrading the guest,
I merely issued a “reboot” in the guest and did not stop/start
qemu.

The host is Debian jessie/amd64 (Linux 3.16.0-7-amd64 / 3.16.59-1)
in case that matters.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#918036: linux: uptime after reboot wrong (kvm-clock related?)

[Thorsten Glaser]

Package: src:linux
Version: 4.19.13-1
Severity: normal

I’ve just rebooted this VM and get:

root@ci-busyapps:~ # uptime
 16:06:57 up 58 days, 21:22,  1 user,  load average: 0.62, 0.98, 0.46

In syslog, I see this:

Jan  2 15:55:01 ci-busyapps CRON[3287]: (root) CMD (command -v debian-sa1 > 
/dev/null && debian-sa1 1 1)
Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection 
rate 1/60s for (smtp:172.26.1.40) at Jan  2 15:52:51
Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max connection 
count 1 for (smtp:172.26.1.40) at Jan  2 15:52:51
Jan  2 15:56:11 ci-busyapps postfix/anvil[3005]: statistics: max cache size 1 
at Jan  2 15:52:51
Jan  2 15:57:20 ci-busyapps sensord: sensord stopped
Jan  2 15:58:05 ci-busyapps dhclient[1031]: DHCPREQUEST of 172.26.1.40 on eth0 
to 172.26.100.2 port 67
Jan  2 15:58:05 ci-busyapps dhclient[1031]: DHCPACK of 172.26.1.40 from 
172.26.100.2
Jan  2 15:58:05 ci-busyapps dhclient[1031]: bound to 172.26.1.40 -- renewal in 
19447 seconds.
Jan  2 15:59:04 ci-busyapps shutdown[7314]: shutting down for system reboot
Jan  2 15:59:05 ci-busyapps init: Switching to runlevel: 6
Jan  2 15:59:09 ci-busyapps jenkins: jenkins: client (pid 1579) exited with 143 
status 
Jan  2 15:59:10 ci-busyapps ntpd[1608]: ntp engine exiting
Jan  2 15:59:10 ci-busyapps ntpd[1607]: Terminating
Jan  2 15:59:10 ci-busyapps postfix/master[22032]: terminating on signal 15
Jan  2 15:59:18 ci-busyapps syslogd: exiting on signal 15
Jan  2 16:00:47 ci-busyapps syslogd (GNU inetutils 1.9.4): restart
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Linux version 4.19.0-1-amd64 
(debian-kernel@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-13)) #1 SMP 
Debian 4.19.13-1 (2018-12-30)
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.19.0-1-amd64 
root=/dev/mapper/vg--ci--busyapps-lv--root ro net.ifnames=0 kaslr nomodeset
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] x86/fpu: x87 FPU will use 
FXSAVE
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-provided physical RAM 
map:
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x-0x0009fbff] usable
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x0009fc00-0x0009] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x000f-0x000f] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x0010-0xdfffdfff] usable
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0xdfffe000-0xdfff] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0xfeffc000-0xfeff] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0xfffc-0x] reserved
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] BIOS-e820: [mem 
0x0001-0x00021fff] usable
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] NX (Execute Disable) 
protection: active
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] SMBIOS 2.4 present.
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] DMI: Bochs Bochs, BIOS Bochs 
01/01/2011
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] Hypervisor detected: KVM
Jan  2 16:00:47 ci-busyapps vmunix: [0.00] kvm-clock: Using msrs 
4b564d01 and 4b564d00
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332663] kvm-clock: cpu 0, msr 
3ffd7001, primary cpu clock
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332663] clocksource: kvm-clock: 
mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.332665] tsc: Detected 3064.488 MHz 
processor
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334831] e820: update [mem 
0x-0x0fff] usable ==> reserved
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334833] e820: remove [mem 
0x000a-0x000f] usable
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334837] last_pfn = 0x22 
max_arch_pfn = 0x4
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334862] MTRR default type: 
write-back
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334863] MTRR fixed ranges enabled:
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334864]   0-9 write-back
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334865]   A-B uncachable
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334866]   C-F write-protect
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334866] MTRR variable ranges 
enabled:
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334867]   0 base 00E000 mask 
FFE000 uncachable
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334868]   1 disabled
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334868]   2 disabled
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334869]   3 disabled
Jan  2 16:00:47 ci-busyapps vmunix: [5087690.334869]   4 disabled
Jan  2 16:00:47 ci-busyapps 

Bug#907911: linux: Resetting chip after gpu hang (crash dump) when zooming on the opencaching.de map

[Thorsten Glaser]

found 907911 4.18.10-2+b1
thanks

Hi *,

this also happens-ish on my desktop: it becomes sluggish to unusable
for a couple of up to minutes after zooming on the map in Firefox a
few times in quick succession. It also is not restricted to Intel…

Matching dmesg (around 2221237):

[0.00] microcode: microcode updated early to revision 0x1d, date = 
2018-05-11
[0.00] Linux version 4.18.0-2-amd64 (debian-kernel@lists.debian.org) 
(gcc version 7.3.0 (Debian 7.3.0-30)) #1 SMP Debian 4.18.10-2 (2018-11-02)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.18.0-2-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 
syscall.x32=y vsyscall=emulate kaslr
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009dbff] usable
[0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcfec] usable
[0.00] BIOS-e820: [mem 0xcfed-0xcfed0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcfed1000-0xcfed] ACPI data
[0.00] BIOS-e820: [mem 0xcfee-0xcfef] reserved
[0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00062fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. X58-USB3/X58-USB3, BIOS F5 
09/07/2011
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0x63 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-CDFFF write-protect
[0.00]   CE000-E uncachable
[0.00]   F-F write-through
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F write-back
[0.00]   1 base 0E000 mask FE000 uncachable
[0.00]   2 base 0D000 mask FF000 uncachable
[0.00]   3 base 1 mask F write-back
[0.00]   4 base 2 mask E write-back
[0.00]   5 base 4 mask C write-back
[0.00]   6 base 5 mask F write-back
[0.00]   7 base 6 mask FC000 write-back
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0xd000-0x] usable ==> reserved
[0.00] last_pfn = 0xcfed0 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f5a60-0x000f5a6f] mapped at 
[(ptrval)]
[0.00] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.00] BRK [0x5f224b000, 0x5f224bfff] PGTABLE
[0.00] BRK [0x5f224c000, 0x5f224cfff] PGTABLE
[0.00] BRK [0x5f224d000, 0x5f224dfff] PGTABLE
[0.00] BRK [0x5f224e000, 0x5f224efff] PGTABLE
[0.00] BRK [0x5f224f000, 0x5f224] PGTABLE
[0.00] BRK [0x5f225, 0x5f2250fff] PGTABLE
[0.00] BRK [0x5f2251000, 0x5f2251fff] PGTABLE
[0.00] BRK [0x5f2252000, 0x5f2252fff] PGTABLE
[0.00] BRK [0x5f2253000, 0x5f2253fff] PGTABLE
[0.00] RAMDISK: [mem 0x3492a000-0x3648cfff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F7200 14 (v00 GBT   )
[0.00] ACPI: RSDT 0xCFED1040 48 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.00] ACPI: FACP 0xCFED1100 74 (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.00] ACPI: DSDT 0xCFED11C0 00391C (v01 GBTGBTUACPI 
1000 MSFT 010C)
[0.00] ACPI: FACS 0xCFED 40
[0.00] ACPI: MSDM 0xCFED4CC0 55 (v03 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.00] ACPI: HPET 0xCFED4D80 38 (v01 GBTGBTUACPI 
42302E31 GBTU 0098)
[0.00] ACPI: MCFG 0xCFED4E00 3C (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.00] ACPI: EUDS 0xCFED4E40 0004D0 (v01 GBT 
  )
[0.00] ACPI: MATS 0xCFED5310 34 (v01 GBT 
  )
[0.00] ACPI: TAMG 0xCFED5380 000CFA (v01 GBTGBT   B0 
5455312E BG?? 53450101)
[0.00] ACPI: APIC 0xCFED4B40 00012C (v01 GBTGBTUACPI 
42302E31 GBTU 01010101)
[0.00] ACPI: SSDT 0xCFED6080 002B1C (v01 INTEL  PPM RCM  
8001 INTL 20061109)
[0.00] ACPI: Local APIC address 

Bug#915954: inteldrmfb: screen black in 4.18.0-3 (works in 4.18.0-2)

[Thorsten Glaser]

Package: src:linux
Version: 4.18.20-2
Severity: serious

When booting with 4.18.0-3, as soon as the display switches from
the 80x25 GRUB left the screen in to the framebugger text console
the screen instead goes completely blank.

Booting the previous kernel, it works.

I could try booting with nofb, but I don’t know if that gives
you useful debug information… do tell me if I should.

dmesg of 4.18.0-2 (the WORKING one) follows:

[0.00] microcode: microcode updated early to revision 0xba, date = 
2010-10-03
[0.00] Linux version 4.18.0-2-amd64 (debian-kernel@lists.debian.org) 
(gcc version 7.3.0 (Debian 7.3.0-30)) #1 SMP Debian 4.18.10-2 (2018-11-02)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.18.0-2-amd64 root=/dev/sda4 
ro rootdelay=5 syscall.x32=y vsyscall=emulate net.ifnames=0 kaslr 
pcie_aspm=force consoleblank=0
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbf6a] usable
[0.00] BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf70-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023bff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: LENOVO 7673AG4/7673AG4, BIOS 7NET30WW (1.11 ) 11/15/2007
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] last_pfn = 0x23c000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0C000 mask FC000 uncachable
[0.00]   1 base 23C00 mask FFC00 uncachable
[0.00]   2 base 0 mask E write-back
[0.00]   3 base 2 mask FC000 write-back
[0.00]   4 base 0BF70 mask 0 uncachable
[0.00]   5 base 0BF80 mask FFF80 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: update [mem 0xbf70-0x] usable ==> reserved
[0.00] last_pfn = 0xbf6b0 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000f6980-0x000f698f] mapped at 
[(ptrval)]
[0.00] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.00] BRK [0x1f764b000, 0x1f764bfff] PGTABLE
[0.00] BRK [0x1f764c000, 0x1f764cfff] PGTABLE
[0.00] BRK [0x1f764d000, 0x1f764dfff] PGTABLE
[0.00] BRK [0x1f764e000, 0x1f764efff] PGTABLE
[0.00] BRK [0x1f764f000, 0x1f764] PGTABLE
[0.00] BRK [0x1f765, 0x1f7650fff] PGTABLE
[0.00] BRK [0x1f7651000, 0x1f7651fff] PGTABLE
[0.00] BRK [0x1f7652000, 0x1f7652fff] PGTABLE
[0.00] RAMDISK: [mem 0x34689000-0x3633bfff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F6950 24 (v02 LENOVO)
[0.00] ACPI: XSDT 0xBF6BD48C 94 (v01 LENOVO TP-7N
1110  LTP )
[0.00] ACPI: FACP 0xBF6BD600 F4 (v03 LENOVO TP-7N
1110 LNVO 0001)
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Gpe0Block: 64/32 (20180531/tbfadt-569)
[0.00] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid 
Address but zero Length: 0x102C/0x0 (20180531/tbfadt-624)
[0.00] ACPI: DSDT 0xBF6BD9DB 00E206 (v01 LENOVO TP-7N
1110 MSFT 0300)
[0.00] ACPI: FACS 0xBF6E4000 40
[0.00] ACPI: FACS 0xBF6E4000 40
[

Bug#913138: linux: I/O on md RAID 6 hangs completely

[Thorsten Glaser]

On Wed, 7 Nov 2018, Thorsten Glaser wrote:

> Normally, if I leave the system alone for a while (half an hour or
> so), it resolves itself, but that’s unacceptable for a work system,

The system hasn’t recovered yet today. There’s nothing new in dmesg.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg