Bug#794468: general: no watchdog support in installer kernel

[Thorsten Glaser]

Ben Hutchings dixit:

Which watchdog device is this, that is enabled by the BIOS?  Normally I
expect them to be enabled only by the kernel driver.

It’s a 19″ server from Supermicro; Dominik would’ve to provide details.

install time since the watchdog devices are not enabled by the system
firmware.

Oh well… apparently, the firmware setup screens don’t signal the
watchdog either, so you can’t use that one for five minutes while
the watchdog is enabled. This all points to buggy firmware. Again,
details would have to come from Nik.

bye,
//mirabilos
-- 
Thorsten Glaser
Teckids e.V. – Erkunden, Entdecken, Erfinden.
https://www.teckids.org/


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1508091336430.29...@herc.mirbsd.org

Bug#799250: Still freezing, may be SATA and/or md related

[Thorsten Glaser]

Version: 4.2.3-2

The BTS is down enough for reportbug at the moment, so a manual
follow-up: this also happens with linux-image-4.2.0-1-amd64:amd64
but seems to be SATA related. I seem to have a bad disc or cable
or mainboard port, and 4.1.0-2 and 4.2.0-1 seem to get hung up
over this while 4.1.0-1 just threw a bit of message into dmesg
and continued to work.

With 4.1.0-1, I have these in syslog once every couple of days:

Oct 25 02:32:11 tglase vmunix: [2910705.554295] ata7.00: exception Emask 0x0 
SAct 0x10 SErr 0x0 action 0x0
Oct 25 02:32:11 tglase vmunix: [2910705.554300] ata7.00: irq_stat 0x4008
Oct 25 02:32:11 tglase vmunix: [2910705.554302] ata7.00: failed command: READ 
FPDMA QUEUED
Oct 25 02:32:11 tglase vmunix: [2910705.554306] ata7.00: cmd 
60/04:a0:54:ee:24/00:00:0e:00:00/40 tag 20 ncq 2048 in
Oct 25 02:32:11 tglase vmunix: [2910705.554306]  res 
41/40:00:56:ee:24/00:00:0e:00:00/40 Emask 0x409 (media error) 
Oct 25 02:32:11 tglase vmunix: [2910705.554309] ata7.00: status: { DRDY ERR }
Oct 25 02:32:11 tglase vmunix: [2910705.554310] ata7.00: error: { UNC }
Oct 25 02:32:11 tglase vmunix: [2910705.556329] ata7.00: configured for UDMA/133
Oct 25 02:32:11 tglase vmunix: [2910705.556342] sd 6:0:0:0: [sdc] tag#20 FAILED 
Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 25 02:32:11 tglase vmunix: [2910705.556345] sd 6:0:0:0: [sdc] tag#20 Sense 
Key : Medium Error [current] [descriptor]
Oct 25 02:32:11 tglase vmunix: [2910705.556347] sd 6:0:0:0: [sdc] tag#20 Add. 
Sense: Unrecovered read error - auto reallocate failed
Oct 25 02:32:11 tglase vmunix: [2910705.556350] sd 6:0:0:0: [sdc] tag#20 CDB: 
Read(10) 28 00 0e 24 ee 54 00 00 04 00
Oct 25 02:32:11 tglase vmunix: [2910705.556352] blk_update_request: I/O error, 
dev sdc, sector 237301334
Oct 25 02:32:11 tglase vmunix: [2910705.556367] ata7: EH complete

With 4.2.0-1, I have a lot more… I only could get the system
back to be responsible at all by --fail’ing the disc in the
RAID; complete dmesg follows:

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.2.0-1-amd64 (debian-kernel@lists.debian.org) 
(gcc version 4.9.3 (Debian 4.9.3-4) ) #1 SMP Debian 4.2.3-2 (2015-10-14)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.2.0-1-amd64 
root=/dev/mapper/vg--tglase-lv--tglase ro syscall.x32=y
[0.00] tseg: 00
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xc7e8] usable
[0.00] BIOS-e820: [mem 0xc7e9-0xc7ea7fff] ACPI data
[0.00] BIOS-e820: [mem 0xc7ea8000-0xc7ec] ACPI NVS
[0.00] BIOS-e820: [mem 0xc7ed-0xc7ef] reserved
[0.00] BIOS-e820: [mem 0xff70-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x000437ff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: System manufacturer System Product Name/M4A785TD-V EVO, 
BIOS 210507/23/2010
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x438000 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-E uncachable
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask 8000 write-back
[0.00]   1 base 8000 mask C000 write-back
[0.00]   2 base C000 mask F800 write-back
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] TOM2: 00043800 aka 17280M
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT
[0.00] e820: update [mem 0xc800-0x] usable ==> reserved
[0.00] e820: last_pfn = 0xc7e90 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at 
[880ff780]
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] BRK [0x01d2c000, 

Bug#805122: linux: kernel panic instead of boot on m68k (ARAnyM)

[Thorsten Glaser]

Ben Hutchings dixit:

>> Instead of starting up, we get a kernel panic. ARAnyM console log:
>[...]
>
>Have you raised this with the upstream maintainers?

No, this is kinda your job (DevRef §3.1.4 first paragraph last sentence)
although I did put debian-68k@ on Cc, which I know upstream reads.

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#805122: linux: kernel panic instead of boot on m68k (ARAnyM)

[Thorsten Glaser]

Source: linux
Version: 4.2.5-1
Severity: important
Control: notfound -1 4.1.6-1

Instead of starting up, we get a kernel panic. ARAnyM console log:

=== running aranym on Sat Nov 14 22:21:12 UTC 2015 ===

ARAnyM 0.9.16
tcgetattr error: 25!
Using config file: 'buildd.nym-x11'
>>> Missing value in Config file buildd.nym-x11 on line 8 !!!
Could not open joystick 0
ARAnyM RTC Timer: /dev/rtc: No such file or directory
cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.2.0-1-m68k (debian-kernel@lists.debian.org) (gcc 
version 4.8.5 (Debian 4.8.5-1) ) #1 Debian 4.2.5-1 (2015-10-27)
[0.00] console [debug0] enabled
[0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC 
DSP56K SCC ANALOG_JOY Blitter tried to read byte from register ff8a00 at 006e42
BLITTER IDE TT_CLK FDC_SPEED 
[0.00] On node 0 totalpages: 3584
[0.00] free_area_init_node: node 0, pgdat 0032fab0, node_mem_map 
00485000
[0.00]   DMA zone: 35 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3584 pages, LIFO batch:0
[0.00] On node 1 totalpages: 245760
[0.00] free_area_init_node: node 1, pgdat 003303ac, node_mem_map 

[0.00]   DMA zone: 2400 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 245760 pages, LIFO batch:31
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address   (null)
[0.00] Oops: 
[0.00] Modules linked in:
[0.00] PC: [<00375560>] memmap_init_zone+0x74/0xfe
[0.00] SR: 2704  SP: 002ffe94  a2: 00300310
[0.00] d0: 0100d1: d2: 1000d3: 
[0.00] d4: d5: 0018a0: a1: 003303ac
[0.00] Process swapper (pid: 0, task=00300310)
[0.00] Frame format=7 eff addr= ssw=0505 faddr=
[0.00] wb 1 stat/addr/data:   
[0.00] wb 2 stat/addr/data:   
[0.00] wb 3 stat/addr/data:   
[0.00] push data:    
[0.00] Stack from 002ffefc:
0003c000  1000  0200 002d1ee6 003303ac 003303ac
00364db8 0003c000 0001  1000  0001 0030db74
00330ca8 1000 0003d000  0032f558 002fff9c 00330c80 00364b4c
0003c000 0001 0035e32a 0001 002fff9c 1000  00361446
00361668 0008   0037e0a4 00231530 003611fa 003613ba
0003c000   0035d66a    
[0.00] Call Trace: [<0003c000>] free_pid+0x7a/0xea
[0.00]  [<1000>] kernel_pg_dir+0x0/0x1000
[0.00]  [<00364db8>] free_area_init_node+0x26c/0x29e
[0.00]  [<0003c000>] free_pid+0x7a/0xea
[0.00]  [<1000>] kernel_pg_dir+0x0/0x1000
[0.00]  [<1000>] kernel_pg_dir+0x0/0x1000
[0.00]  [<0003d000>] add_sysfs_param.isra.8+0x34/0x196
[0.00]  [<00364b4c>] free_area_init_node+0x0/0x29e
[0.00]  [<0003c000>] free_pid+0x7a/0xea
[0.00]  [<0035e32a>] paging_init+0x2a2/0x2cc
[0.00]  [<1000>] kernel_pg_dir+0x0/0x1000
[0.00]  [<00361446>] mvme16x_parse_bootinfo+0x0/0x16
[0.00]  [<00361668>] bvme6000_parse_bootinfo+0x0/0x10
[0.00]  [<00231530>] printk+0x0/0x1a
[0.00]  [<003611fa>] apollo_parse_bootinfo+0x0/0x1a
[0.00]  [<003613ba>] mvme147_parse_bootinfo+0x0/0x16
[0.00]  [<0003c000>] free_pid+0x7a/0xea
[0.00]  [<0035d66a>] setup_arch+0x29e/0x3a2
[0.00]  [<00231530>] printk+0x0/0x1a
[0.00]  [<0035bad6>] start_kernel+0x7e/0x462
[0.00]  [<0035a872>] _sinittext+0x872/0x11f8
[0.00] 
[0.00] Code: 08d0 2801 e78c 2044 eb89 d1c1 d1e9 08c8 <2210> 0281 07ff 
 8283 8286 2081 7201 2141 0010 78ff 2144 000c 43e8 0014 2149
[0.00] Disabling lock debugging due to kernel taint
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
[0.00] ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address   (null)
[0.00] Oops: 
[0.00] Modules linked in:
[0.00] PC: [<>]   (null)
[0.00] SR: 2404  SP: 002ffcbc  a2: 00300310
[0.00] d0: d1: 0038d2: d3: 
[0.00] d4: d5: 0018a0: 002fe000a1: 0033a989
[0.00] Process swapper (pid: 0, task=00300310)
[0.00] Frame format=7 eff addr= ssw=0546 faddr=
[0.00] wb 1 stat/addr/data:   
[0.00] wb 2 stat/addr/data:   
[0.00] wb 3 stat/addr/data:   
[0.00] push data:    

Bug#799250: linux-image-4.1.0-2-amd64: sporadic freezes overnight

[Thorsten Glaser]

Package: linux-image-4.1.0-2-amd64
Version: 4.1.6-1
Severity: normal

Hi,

I’ve been hit twice by a weird sporadic freeze now. They both
were after upgrading to linux-image-4.1.0-2-amd64 from -1-,
but that may or may not have been the actual cause.

I usually start xlock when going away from the system; over
night (or, recently, over the weekend), the system completely
freezes: the xlock animation stops, no keyboard input works
(even Alt-SysRq-S+U+S+B doesn’t), and the machine does not
respond to IPv4 ping over the LAN. The CPU fans continue to
spin as if BOINC was still running, that may just be the CPU
governour not doing anything due to a kernel crash.

amd64-microcode (2.20141028.1) is installed.

I have no further information: absolutely zero in syslog.
I also have no reproducers, this “just sporadically happens”.

I’d hook up a serial console, but unfortunately, this is one
of those modern desktop-style systems without a COM port…


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

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

Versions of packages linux-image-4.1.0-2-amd64:amd64 depends on:
ii  debconf [debconf-2.0]   1.5.57
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod21-1
ii  linux-base  4.0

Versions of packages linux-image-4.1.0-2-amd64:amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.0.6-3

Versions of packages linux-image-4.1.0-2-amd64:amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta2-28
pn  linux-doc-4.1   

-- no debconf information

Bug#799250: linux-image-4.1.0-2-amd64: sporadic freezes overnight

[Thorsten Glaser]

Dixi quod…

> I’m trying now with linux-image-4.1.0-1-amd64:amd64 (= 4.1.3-1)

Linux tglase.lan.tarent.de 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) 
x86_64 GNU/Linux

The problem indeed does not appear to happen here (up 6 days).

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#799250: linux-image-4.1.0-2-amd64: sporadic freezes overnight

[Thorsten Glaser]

More info:

This happened three more times, the last of which I was actually
using the computer (as opposed to screensaver engaged and me afk).

I noticed, after reboot, that there was lots of I/O wait (three
or even all for CPUs) and extreme lag in starting new xterms or
other applications for quite a while, although neither dmesg nor
/proc/mdstat showed any reason for it (no resync active, etc).
I did not manage to catch which programs were in D state in top,
though.

I’m trying now with linux-image-4.1.0-1-amd64:amd64 (= 4.1.3-1)
which already looks better (not the I/O(?) wait after booting,
except once during fsck of a BSD VM, and much shorter then).

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#824543: update-initramfs: cp: cannot stat '/etc/modprobe.d/*': No such file or directory

[Thorsten Glaser]

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

During a package upgrade:

[…]
Setting up ffmpeg (7:3.0.2-2) ...
Processing triggers for libc-bin (2.22-9) ...
Processing triggers for initramfs-tools (0.125) ...
update-initramfs: Generating /boot/initrd.img-4.5.0-2-amd64
cp: cannot stat '/etc/modprobe.d/*': No such file or directory
[…]

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages initramfs-tools-core depends on:
ii  cpio 2.11+dfsg-5
ii  klibc-utils  2.0.4-9
ii  kmod 22-1.1
ii  udev 229-6

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.22.0-19

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

-- no debconf information

Bug#854695: firmware-linux-nonfree: more missing i915 firmware

[Thorsten Glaser]

Package: firmware-linux-nonfree
Version: 20161130-2
Severity: normal

Related to #838476:

W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module 
i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module 
i915


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20161130-2
ii  firmware-misc-nonfree  20161130-2

Versions of packages firmware-linux-nonfree recommends:
pn  amd64-microcode  
ii  intel-microcode  3.20161104.1

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#851680: Please upload signed kernel images at the same time as unsigned ones

[Thorsten Glaser]

On Tue, 17 Jan 2017, Julien Aubin wrote:

> ... or even better : the unsigned image is the default image (ends with
> -amd64) and the signed image (ends with -amd64-signed) provides the kernel
> unsigned package

That would be even better, yes.

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#851680: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Bug#851680: Please provide linux-image-amd64-unsigned et al. metapackages (was Re: Please upload signed kernel images at the same time a

[Thorsten Glaser]

Hello Ben,

>No, there will be no such meta-packages.  The -unsigned packages are
>only meant for developer testing and as build dependencies for signed
>binary packages.

then, would you please kindly explain how you plan to address the
issue of not getting the security updates from newer kernel packages
installed on Debian systems for a week or so?


On Tue, 17 Jan 2017, Julien Aubin wrote:

> Could you raise a ticket about this instead of the -unsigned metapackage?
> (Actually a -signed metapackage would make much more sense)

That’s precisely what I already did, which you might have noticed.
And yes, that would make much more sense, because 90% or more of
Debian users have absolutely zero need, nor any surplus value a̲t̲
a̲l̲l̲, from the signed images.


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#851680: Please provide linux-image-amd64-unsigned et al. metapackages (was Re: Please upload signed kernel images at the same time as unsigned ones)

[Thorsten Glaser]

Package: linux-image-amd64
Version: 4.9+78
Severity: wishlist

On Tue, 17 Jan 2017, Julien Cristau wrote:

> On 01/17/2017 02:16 PM, Julien Aubin wrote:

> > Signed linux kernel images tend to become the default as package
> > linux-latest is updated when linux-signed is updated.

> > So could you please publish both signed and unsigned kernels at the same
> > time ? (As of now 4.8.15)

> That would be hard, seeing how that would mean signing content before
> that content even exists.

There seem to be no metapackages linux-latest-unsigned though,
which would eliminate this problem (for the 90%+ of us who don’t
need the signed images).

Can those please be provided?

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#838476: firmware-linux-nonfree: warnings about missing i915 firmware after upgrading

[Thorsten Glaser]

Package: firmware-linux-nonfree
Version: 20160824-1
Severity: normal

Hi,

unsure about package and severity, please change if necessary.

I just upgraded my system (last upgrade was about 24 hours ago),
and now I get the following messages:

Unpacking firmware-linux-nonfree (20160824-1) over (20160110-1) ...
[…]
Processing triggers for initramfs-tools (0.125) ...
update-initramfs: Generating /boot/initrd.img-4.7.0-1-amd64
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_ver6.bin for module i915

Currently installed are:

tglase@tglase-nb:~ $ dpkg-query -W | fgrep firmware
firmware-amd-graphics   20160824-1
firmware-iwlwifi20160824-1
firmware-linux  20160824-1
firmware-linux-free 3.4
firmware-linux-nonfree  20160824-1
firmware-misc-nonfree   20160824-1

The hardware is an IBM Thinkpad X61.

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

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

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20160824-1
ii  firmware-misc-nonfree  20160824-1

Versions of packages firmware-linux-nonfree recommends:
pn  amd64-microcode  
ii  intel-microcode  3.20160714.1

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#869681: firmware-linux: again missing i915 firmware for Thinkpad X61

[Thorsten Glaser]

Package: firmware-linux
Version: 20161130-3
Severity: normal

Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.11.0-2-amd64
W: Possible missing firmware /lib/firmware/i915/kbl_huc_ver02_00_1810.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_07_1398.bin for 
module i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_ver01_07_1398.bin for 
module i915


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

Kernel: Linux 4.11.0-1-amd64 (SMP w/2 CPU cores)
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 firmware-linux depends on:
ii  firmware-linux-free 3.4
ii  firmware-linux-nonfree  20161130-3

Versions of packages firmware-linux recommends:
pn  amd64-microcode  
ii  intel-microcode  3.20170707.1

firmware-linux suggests no packages.

-- no debconf information

Bug#865928: linux-image-4.9.0-3-m68k: fails to boot on ARAnyM due to NMI watchdog / soft stuck

[Thorsten Glaser]

Finn Thain dixit:

>On Mon, 26 Jun 2017, John Paul Adrian Glaubitz wrote:
>> Which can be worked-around by adding
>> "initcall_blacklist=atari_scsi_driver_init" to the kernel command line.
>> The buildd "mama" is running 4.11 with that work around.

Looks like it:
Linux ara5.mirbsd.org 4.9.0-3-m68k #1 Debian 4.9.30-2 (2017-06-12) m68k 
GNU/Linux

ARAnyM 1.0.2
Using config file: 'buildd.nym-ssh'
>>> Missing value in Config file buildd.nym-ssh on line 8 !!!
Could not open joystick 0
ARAnyM RTC Timer: /dev/rtc: No such file or directory
Blitter tried to read byte from register ff8a00 at 006f86
[0.00] Linux version 4.9.0-3-m68k (debian-kernel@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 Debian 4.9.30-2 (2017-06-12)
[0.00] Atari hardware found:
[0.00] VIDEL
[0.00] STDMA-SCSI
[0.00] ST_MFP
[0.00] YM2149
[0.00] PCM
[0.00] CODEC
[0.00] DSP56K
[0.00] SCC
[0.00] ANALOG_JOY
[0.00] BLITTER
[0.00] IDE
[0.00] TT_CLK
[0.00] FDC_SPEED
[0.00]
[0.00] NatFeats found (ARAnyM, 1.0)
[0.00] initrd: 302a7e00 - 3100
[0.00] Built 2 zonelists in Zone order, mobility grouping on.  Total 
pages: 198237
[0.00] Kernel command line: root=/dev/nfhd8p1 console=nfcon 
devtmpfs.mount=1 initcall_blacklist=atari_scsi_driver_init BOOT_IMAGE=vmlinux
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[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: 772724K/800768K available (2445K kernel code, 426K 
rwdata, 828K rodata, 144K init, 205K bss, 28044K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x0036d858 - 0x0036dc58   (   1 KiB)
[0.00] kmap: 0xd000 - 0xf000   ( 512 MiB)
[0.00] vmalloc : 0x3180 - 0xd000   (2536 MiB)
[0.00] lowmem  : 0x - 0x3100   ( 784 MiB)
[0.00]   .init : 0x003a1000 - 0x003c5000   ( 144 KiB)
[0.00]   .text : 0x1000 - 0x002646d4   (2446 KiB)
[0.00]   .data : 0x002672a0 - 0x003a0d0c   (1255 KiB)
[0.00]   .bss  : 0x0036d760 - 0x003a0d0c   ( 206 KiB)
[0.00] NR_IRQS:200
[0.00] Console: colour dummy device 80x25
[0.07] Calibrating delay loop... 139.67 BogoMIPS (lpj=698368)
[0.07] pid_max: default: 32768 minimum: 301
[0.07] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.07] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.09] devtmpfs: initialized
[0.11] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.11] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.11] NET: Registered protocol family 16
[0.15] SCSI subsystem initialized
[0.15] VFS: Disk quotas dquot_6.6.0
[0.15] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[0.20] NET: Registered protocol family 2
[0.21] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[0.21] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[0.21] TCP: Hash tables configured (established 8192 bind 8192)
[0.21] UDP hash table entries: 512 (order: 1, 8192 bytes)
[0.21] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
[0.21] NET: Registered protocol family 1
[0.21] Unpacking initramfs...
[0.75] Freeing initrd memory: 13664K (302a8000 - 3100)
[0.75] nfhd8: found device with 37748592 blocks (512 bytes)
[0.75]  nfhd8: AHDI p1 p2 p3
[0.77] console [nfcon0] enabled
[0.77] nfeth: API 5
[0.77] eth0: nfeth addr:192.168.0.1 (192.168.0.2) 
HWaddr:52:54:00:22:81:00
[0.78] workingset: timestamp_bits=11 max_order=18 bucket_order=7
[0.78] zbud: loaded
[0.81] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
252)
[0.81] io scheduler noop registered
[0.81] io scheduler cfq registered (default)
[0.81] atafb_init: start
[0.81] atafb_init: initializing Falcon hw
[0.81] atafb: screen_base 00c42000 phys_screen_base c42000 screen_len 
311296
[0.81] Determined 640x480, depth 4
[0.81]virtual 640x972
[0.85] Console: switching to colour frame buffer device 80x30
[0.90] fb0: frame buffer device, using 304K of video memory
[0.90] pmac_zilog: 0.6 (Benjamin Herrenschmidt 
)
[0.90] Non-volatile memory driver v1.3
[0.90] mousedev: PS/2 mouse device common for all mice
[1.15] input: Atari Keyboard as /devices/virtual/input/input0
[1.40] rtc-generic rtc-generic: rtc core: 

Bug#865928: linux-image-4.9.0-3-m68k: fails to boot on ARAnyM due to NMI watchdog / soft stuck

[Thorsten Glaser]

Package: src:linux
Version: 4.9.30-2
Severity: important

I cannot boot Linux 4.9, but 4.1 still works. (I think 4.3 also failed,
but I had autoremoved that already.)

ARAnyM console log for failed build:

-cutting here may damage your screen surface-
ARAnyM 1.0.2
Using config file: 'buildd.nym-ssh'
>>> Missing value in Config file buildd.nym-ssh on line 8 !!!
Could not open joystick 0
ARAnyM RTC Timer: /dev/rtc: No such file or directory
Blitter tried to read byte from register ff8a00 at 006f86
[0.00] Linux version 4.9.0-3-m68k (debian-kernel@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 Debian 4.9.30-2 (2017-06-12)
[0.00] Atari hardware found:
[0.00] VIDEL
[0.00] STDMA-SCSI
[0.00] ST_MFP
[0.00] YM2149
[0.00] PCM
[0.00] CODEC
[0.00] DSP56K
[0.00] SCC
[0.00] ANALOG_JOY
[0.00] BLITTER
[0.00] IDE
[0.00] TT_CLK
[0.00] FDC_SPEED
[0.00]
[0.00] NatFeats found (ARAnyM, 1.0)
[0.00] initrd: 302a7e00 - 3100
[0.00] Built 2 zonelists in Zone order, mobility grouping on.  Total 
pages: 198237
[0.00] Kernel command line: root=/dev/nfhd8p1 console=nfcon 
devtmpfs.mount=1 BOOT_IMAGE=vmlinux
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[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: 772724K/800768K available (2445K kernel code, 426K 
rwdata, 828K rodata, 144K init, 205K bss, 28044K reserved, 0K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x0036d858 - 0x0036dc58   (   1 KiB)
[0.00] kmap: 0xd000 - 0xf000   ( 512 MiB)
[0.00] vmalloc : 0x3180 - 0xd000   (2536 MiB)
[0.00] lowmem  : 0x - 0x3100   ( 784 MiB)
[0.00]   .init : 0x003a1000 - 0x003c5000   ( 144 KiB)
[0.00]   .text : 0x1000 - 0x002646d4   (2446 KiB)
[0.00]   .data : 0x002672a0 - 0x003a0d0c   (1255 KiB)
[0.00]   .bss  : 0x0036d760 - 0x003a0d0c   ( 206 KiB)
[0.00] NR_IRQS:200
[0.01] Console: colour dummy device 80x25
[0.01] Calibrating delay loop... 138.64 BogoMIPS (lpj=693248)
[0.08] 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.11] devtmpfs: initialized
[0.12] clocksource: jiffies: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.12] futex hash table entries: 256 (order: -1, 3072 bytes)
[0.12] NET: Registered protocol family 16
[0.16] SCSI subsystem initialized
[0.16] VFS: Disk quotas dquot_6.6.0
[0.16] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[0.21] NET: Registered protocol family 2
[0.21] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[0.22] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[0.22] TCP: Hash tables configured (established 8192 bind 8192)
[0.22] UDP hash table entries: 512 (order: 1, 8192 bytes)
[0.22] UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
[0.22] NET: Registered protocol family 1
[0.22] Unpacking initramfs...
[0.75] Freeing initrd memory: 13664K (302a8000 - 3100)
[0.76] nfhd8: found device with 37748592 blocks (512 bytes)
[0.77]  nfhd8: AHDI p1 p2 p3
[0.79] console [nfcon0] enabled
[0.79] nfeth: API 5
[0.79] eth0: nfeth addr:192.168.0.1 (192.168.0.2) 
HWaddr:52:54:00:22:81:00
[0.81] workingset: timestamp_bits=11 max_order=18 bucket_order=7
[0.81] zbud: loaded
[0.85] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
252)
[0.85] io scheduler noop registered
[0.85] io scheduler cfq registered (default)
[0.85] atafb_init: start
[0.85] atafb_init: initializing Falcon hw
[0.85] atafb: screen_base 00c42000 phys_screen_base c42000 screen_len 
311296
[0.85] Determined 640x480, depth 4
[0.85]virtual 640x972
[0.86] Console: switching to colour frame buffer device 80x30
[0.88] fb0: frame buffer device, using 304K of video memory
[0.88] pmac_zilog: 0.6 (Benjamin Herrenschmidt 
)
[0.88] Non-volatile memory driver v1.3
[0.88] mousedev: PS/2 mouse device common for all mice
[1.13] input: Atari Keyboard as /devices/virtual/input/input0
[1.38] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
[1.38] ledtrig-cpu: registered to indicate activity on CPUs
[1.38] NET: Registered 

Bug#862109: linux-image-4.9.0-3-amd64: trace log and screen gets unusable when closing the lid, Thinkpad X61

[Thorsten Glaser]

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

After dist-upgrading and rebooting into today’s kernel, running X
(using exec startx from the command line), locking the screen and
closing the lid, I get a trace log in the syslog and the TFT gets
unusable; SSH to the system however still works.

This is a Thinkpad X61 in its docking station.

-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170425 (Debian 6.3.0-16) ) #1 SMP Debian 4.9.25-1 (2017-05-02)

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

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[7.635166] iwl4965 :03:00.0: Tunable channels: 13 802.11bg, 19 802.11a 
channels
[7.641389] iwl4965 :03:00.0: firmware: direct-loading firmware 
iwlwifi-4965-2.ucode
[7.643261] iwl4965 :03:00.0: loaded firmware version 228.61.2.24
[7.671103] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs'
[7.672400] intel_powerclamp: No package C-state available
[7.672710] yenta_cardbus :05:00.0: ISA IRQ mask 0x0c38, PCI irq 16
[7.676532] yenta_cardbus :05:00.0: Socket status: 3006
[7.678590] yenta_cardbus :05:00.0: pcmcia: parent PCI bridge window: 
[io  0x4000-0x7fff]
[7.681109] yenta_cardbus :05:00.0: pcmcia: parent PCI bridge window: 
[mem 0xd400-0xd7ef]
[7.683509] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xd400-0xd7ef:
[7.687896]  excluding 0xd7b1-0xd7ef
[7.689975] yenta_cardbus :05:00.0: pcmcia: parent PCI bridge window: 
[mem 0xd800-0xdbff 64bit pref]
[7.693455] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xd800-0xdbff:
[7.695662]  excluding 0xd800-0xdbff
[7.710861] ppdev: user-space parallel port driver
[7.760424] iTCO_vendor_support: vendor-support=0
[7.765233] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[7.768419] iTCO_wdt: Found a ICH8M-E TCO device (Version=2, TCOBASE=0x1060)
[7.777260] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[7.801160] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f:
[7.801815]  excluding 0xc-0xd3fff 0xe-0xf
[7.801837] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xa000-0xa0ff:
[7.801849]  excluding 0xa000-0xa0ff
[7.801863] pcmcia_socket pcmcia_socket0: cs: memory probe 
0x6000-0x60ff:
[7.801874]  excluding 0x6000-0x60ff
[7.940471] snd_hda_codec_analog hdaudioC0D0: autoconfig for AD1984: 
line_outs=1 (0x12/0x0/0x0/0x0/0x0) type:speaker
[7.949348] snd_hda_codec_analog hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[7.953070] snd_hda_codec_analog hdaudioC0D0:hp_outs=1 
(0x11/0x0/0x0/0x0/0x0)
[7.957154] snd_hda_codec_analog hdaudioC0D0:mono: mono_out=0x0
[7.962753] snd_hda_codec_analog hdaudioC0D0:inputs:
[7.968250] snd_hda_codec_analog hdaudioC0D0:  Internal Mic=0x15
[7.970672] snd_hda_codec_analog hdaudioC0D0:  Mic=0x14
[7.972947] snd_hda_codec_analog hdaudioC0D0:  Dock Mic=0x1c
[7.986087] input: HDA Intel Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input9
[7.988542] input: HDA Intel Dock Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input10
[7.993291] input: HDA Intel Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[8.370761] Adding 3730428k swap on /dev/sda1.  Priority:-1 extents:1 
across:3730428k SSDscFS
[8.384064] usb 3-1: new full-speed USB device number 2 using uhci_hcd
[8.392868] EXT4-fs (sda4): re-mounted. Opts: errors=remount-ro
[8.726269] EXT4-fs (sda2): mounted filesystem without journal. Opts: (null)
[8.778113] usb 3-1: New USB device found, idVendor=0a5c, idProduct=2110
[8.780802] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[8.783417] usb 3-1: Product: BCM2045B
[8.785920] usb 3-1: Manufacturer: Broadcom Corp
[8.818094] Bluetooth: Core ver 2.22
[8.820630] NET: Registered protocol family 31
[8.823017] Bluetooth: HCI device and connection manager initialized
[8.826021] Bluetooth: HCI socket layer initialized
[8.828419] Bluetooth: L2CAP socket layer initialized
[8.830674] Bluetooth: SCO socket layer initialized
[8.837699] usbcore: registered new interface driver btusb
[8.996800] tun: Universal TUN/TAP device driver, 1.6
[8.999397] tun: (C) 1999-2004 Max Krasnyansky 
[9.014762] IPv6: ADDRCONF(NETDEV_UP): tap4: link is not ready
[9.039456] ip_tables: (C) 2000-2006 Netfilter Core Team
[9.048864] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[   11.828029] random: crng init done
[  107.292316] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  109.057621] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: 

Bug#862109: linux-image-4.9.0-3-amd64: trace log and screen gets unusable when closing the lid, Thinkpad X61

[Thorsten Glaser]

On Mon, 8 May 2017, Thorsten Glaser wrote:

> unusable; SSH to the system however still works.

Trying to shut it down kills the ssh session, but the system
doesn’t power off either, it just spins the fan a lot.

Holding the power button pressed for several seconds then does
turn it off, but that’s likely not good.

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

Re: Fixing Linux getrandom() in stable

[Thorsten Glaser]

Adrian Bunk dixit:

>As an example, what happens if I debootstrap and deploy the resulting
>filesytem to a large number of identical embedded systems without
>entropy sources?

Just get into a habit of not doing so, for example by modifying the
image during each writing process.

Having the bootloader inject entropy into the kernel would of course
help (something OpenBSD actually did, which I’d dreamt of only until).
Reuse is only problematic then if the system actually booted, i.e. an
early userspace thing reading and immediately writing to a file will
stave off the remaining issues.

>As far as I can see, any solution above would either give me boot hangs
>or might result in nasty security issues due to the same (known) entropy
>being fed to /dev/random on many machines.
>
>Similar problems for cases like live CDs and installers.

And CPUs, and architectures, without usable boot entropy.

For the “CD image” case, though, adding stuff like the MAC addresses
of the onboard NICs and the current time would at least shuffle the
existing (albeit known) entropy around enough for it to begin to differ.

A web service for getting random bits sounds like an idea, until you
get to the privacy implications of that (as well as reliability). But
if it’s inhouse, it’s doable.

>I wonder whether the current issue is just the tip of the iceberg,
>and usage of /dev/urandom is a gazillion CVEs waiting to be reported.

Did you see the fallback code for Linux in OpenBSD’s code for libbsd?
It’s… like trying to find randomly-looking things on an 1990s Unix.

This is best fixed in the kernel and earlier, plus an extra read/write
in early userspace. Of course, embedding some entropy into the kernel
image itself will make the reproducible-builds people entirely unhappy…
(this one *is* implemented in MirBSD, complete with a tool to update
it).

>Due to the gdm bugs mentioned above we know that there are real-life
>situations where gdm currently uses "random" data that might be
>predictable.

The question is which uses actually need entropy estimated good enough?

>>b. Tolerate a longer wait for getrandom() to return
>
>I suspect there might be no guaranteed upper bound for the waiting time.

On a discless system with no hardware sources (possibly no network)
and no keyboard interaction? Infinite.

Of course, if early userspace could reliably update a file, then the
file’s content could be estimated as good enough and be credited to
the RNG, at least for non-identical/readonly-/shared-media systems.

>never block but might return predictable data in some cases.

“What level of predictability?”

>It would then be up to the application to decide whether predictable
>data is acceptable, and what to do in entropy-starved situations.

I guess most application authors have no answer for you here.

It’s also no solution for the arc4random API… seems like a cultural
clash (BSD expectations vs. what Linux can actually deliver).

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

Re: Fixing Linux getrandom() in stable

[Thorsten Glaser]

Theodore Y. Ts'o dixit:

>that problems helps most of our users, and we shouldn't let the
>perfect be the enemy of the good.

Agreed. Start small, then enhance one bootloader at a time.
Or boot protocol, I assume.

>Also note that the bootloader has depend on userspace to refresh the
>seed entropy, both in early boot (in case the syscrashes), and at
>shutdown (so the entropy captured while the system is running can be

Definitely!

>saved as seed entropy).  And this is trickier in Linux because the
>bootloader lives in a different source tree, and is maintained by
>different people from the systemd and/or initscripts people, and for

Yes, unfortunately.

>that matter the bootloader doesn't know which distribution it is

But in this case, the distribution can tell the bootloader the
path to the file to load.

>the *BSD's has its advantages.  And this is where perhaps Debian as a
>distribution can solve this problem by coordinating action across
>multiple Debian packages.)

Of course.

>The *point* is that we can't really make a turn-key solution which
>will work for everyone.  For as much we have the desire for a
>"Universal OS", something that works for all hardware, all users, and
>all workloads, is probably just not attainable here.

As Debian, we can try to come close, but, as you said, don’t let
the perfect be the enemy of the good. Perhaps there are multiple
somethings that, together (or having the local admin choose) can
help more people than one simple solution, even if the latter may
help a majority. (I’m a fan of minorities, in case you couldn’t
tell. I run an x32 system, after all, and helped out m68k a bit…)

>(It never was a complete solution, BTW; even before the patches to
>address CVE-2018-1108, there were already hardware systems where you
>couldn't count on the RNG being initialized in time and getrandom(2)

Another question is what it means that the RNG is initialised.
It all depends on what in the end boils down to guesswork,
although I tip my hat because that RNG code of yours, both the
Linux and the BSD version, are pretty impressive.

But the point here is that, even if the RNG thinks it’s fully
initialised, it may not be “good” yet, depending on circumstances.
(Again, it should not stop us from trying.)

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#890326: linux: Thinkpad X61 brightness reset to 0% on each boot

[Thorsten Glaser]

Package: src:linux
Version: 4.14.13-1
Severity: minor

Ever since a recent kernel upgrade (I *think* 4.13 to 4.14; if
necessary, I can check), on each boot, my LCD brightness gets
reset to the minimum.

This is annoying; I currently work around it by putting
cat /sys/class/backlight/intel_backlight/max_brightness \
>/sys/class/backlight/intel_backlight/brightness
into /etc/rc.local, but it makes it virtually impossible to read
boot messages.

Furthermore, I have a slight feeling that the maximum brightness
is lower than it was before, or compared to my IBM Thinkpad X40.
That being said, several minutes after booting, it seems to be
becoming a bit brighter, so it’s maybe only on a cold start.

-- Package-specific info:
** Version:
Linux version 4.14.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.2.0 (Debian 7.2.0-19)) #1 SMP Debian 4.14.13-1 (2018-01-14)

** Command line:
BOOT_IMAGE=/vmlinuz-4.14.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:
[2.336544] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 (SET FEATURES) succeeded
[2.336546] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) 
filtered out
[2.336547] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 (SET FEATURES) filtered 
out
[2.336775] ata1.00: configured for UDMA/100
[2.444822] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[2.462065] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/input/input5
[2.480472] usb 1-4: New USB device found, idVendor=17ef, idProduct=1000
[2.480475] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[2.480883] hub 1-4:1.0: USB hub found
[2.480927] hub 1-4:1.0: 4 ports detected
[2.586157] Console: switching to colour frame buffer device 128x48
[2.688444] i915 :00:02.0: fb0: inteldrmfb frame buffer device
[2.704395] scsi 0:0:0:0: Direct-Access ATA  INTEL SSDSA2M160 02HA 
PQ: 0 ANSI: 5
[2.712571] ata1.00: Enabling discard_zeroes_data
[2.714155] sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 
GiB)
[2.715443] sd 0:0:0:0: [sda] Write Protect is off
[2.716761] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[2.717396] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[2.718811] ata1.00: Enabling discard_zeroes_data
[2.720798]  sda: sda1 sda2 sda3 sda4
[2.722570] ata1.00: Enabling discard_zeroes_data
[2.724084] sd 0:0:0:0: [sda] Attached SCSI disk
[7.951700] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[8.459119] parport_pc 00:06: reported by Plug and Play ACPI
[8.463622] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
[8.483053] ACPI: Battery Slot [BAT0] (battery present)
[8.484975] ACPI: AC Adapter [AC] (on-line)
[8.499012] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[8.535866] ACPI Warning: SystemIO range 
0x1028-0x102F conflicts with OpRegion 
0x1000-0x107F (\_SB.PCI0.LPC.PMIO) 
(20170728/utaddress-247)
[8.539070] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.545082] sd 0:0:0:0: Attached scsi generic sg0 type 0
[8.548186] Non-volatile memory driver v1.3
[8.559618] ACPI Warning: SystemIO range 
0x11B0-0x11BF conflicts with OpRegion 
0x1180-0x11BF (\_SB.PCI0.LPC.LPIO) 
(20170728/utaddress-247)
[8.563081] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.565878] ACPI Warning: SystemIO range 
0x1180-0x11AF conflicts with OpRegion 
0x1180-0x11BF (\_SB.PCI0.LPC.LPIO) 
(20170728/utaddress-247)
[8.569374] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.571124] lpc_ich: Resource conflict(s) found affecting gpio_ich
[8.573177] yenta_cardbus :05:00.0: CardBus bridge found [17aa:20c6]
[8.589883] input: PC Speaker as /devices/platform/pcspkr/input/input7
[8.592433] thinkpad_acpi: ThinkPad ACPI Extras v0.25
[8.594648] thinkpad_acpi: http://ibm-acpi.sf.net/
[8.596444] thinkpad_acpi: ThinkPad BIOS 7NET30WW (1.11 ), EC 7MHT24WW-1.02
[8.598220] thinkpad_acpi: Lenovo ThinkPad X61, model 7673AG4
[8.617124] thinkpad_acpi: radio switch found; radios are enabled
[8.619014] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
brightness control, supported by the ACPI video driver
[8.620877] thinkpad_acpi: Disabling thinkpad-acpi brightness events by 
default...
[8.647113] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree:
[8.648901] iwl4965: Copyright(c) 2003-2011 Intel Corporation
[8.652264] iwl4965 :03:00.0: Detected 

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

[Thorsten Glaser]

forwarded 907911 https://bugs.freedesktop.org/show_bug.cgi?id=107824
thanks

Ben Hutchings dixit:

>Please can you also report this upstream as requested in the error

According to DevRef §3.1.4 that’s your job as maintainer, but, in
this instance, it was easy enough. I am not qualified enough (not
knowledgeable about the entire kernel, DR-whatever-i-or-m, X.org,
etc. stack) to respond to their backquestions though.

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: linux: I/O on md RAID 6 hangs completely

[Thorsten Glaser]

Package: linux-image-4.18.0-2-amd64
Version: 4.18.10-2
Severity: normal

Occasionally, my system begins freezing (processes doing a lot of
I/O enter D state). It is still somewhat usable for already cached
stuff (starting a new shell tab in GNU screen works, lynx does, …
but e.g. the debsums verify of reportbug freezes it, a new reportbug
with --no-verify again works though).

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,
especially if I can’t engage the screen lock (most of the time, I
can, though).

This has happened a few times over the last weeks, sometimes twice
in a single day, oftentimes not at all, and with multiple recent
kernel images.

Today’s occurrence is from
Linux tglase.lan.tarent.de 4.18.0-2-amd64 #1 SMP Debian 4.18.10-2 (2018-10-07) 
x86_64 GNU/Linux


dmesg:

[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-29)) #1 SMP Debian 4.18.10-2 (2018-10-07)
[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 [0x2ba84b000, 0x2ba84bfff] PGTABLE
[0.00] BRK [0x2ba84c000, 0x2ba84cfff] PGTABLE
[0.00] BRK [0x2ba84d000, 0x2ba84dfff] PGTABLE
[0.00] BRK [0x2ba84e000, 0x2ba84efff] PGTABLE
[0.00] BRK [0x2ba84f000, 0x2ba84] PGTABLE
[0.00] BRK [0x2ba85, 0x2ba850fff] PGTABLE
[0.00] BRK [0x2ba851000, 0x2ba851fff] PGTABLE
[0.00] BRK [0x2ba852000, 0x2ba852fff] PGTABLE
[0.00] BRK [0x2ba853000, 0x2ba853fff] PGTABLE
[0.00] RAMDISK: [mem 0x34928000-0x3648bfff]
[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 

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

Bug#912936: linux: kernel WARNING in ieee80211_delayed_tailroom_dec

[Thorsten Glaser]

Package: src:linux
Version: 4.18.10-2+b1
Severity: minor

I got the warning you see below, and the WLAN reset after a while.

-- Package-specific info:
** Version:
Linux version 4.18.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-29)) #1 SMP Debian 4.18.10-2 (2018-10-07)

** 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

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[9.549441] EXT4-fs (sda2): mounted filesystem without journal. Opts: 
auto_da_alloc
[9.754104] random: dd: uninitialized urandom read (512 bytes read)
[9.877824] tun: Universal TUN/TAP device driver, 1.6
[9.886225] systemd-udevd[1084]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
[9.891566] systemd-udevd[1084]: Could not generate persistent MAC address 
for tap4: No such file or directory
[9.899906] IPv6: ADDRCONF(NETDEV_UP): tap4: link is not ready
[   10.646921] random: edac-ctl: uninitialized urandom read (4 bytes read)
[   10.877000] random: mktemp: uninitialized urandom read (8 bytes read)
[   10.899966] random: arngc-slrd: uninitialized urandom read (16 bytes read)
[   22.473625] random: crng init done
[   44.544893] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   48.923166] wlan0: authenticate with 38:10:d5:48:ea:c0
[   48.935976] wlan0: send auth to 38:10:d5:48:ea:c0 (try 1/3)
[   48.943379] wlan0: authenticated
[   48.947404] wlan0: waiting for beacon from 38:10:d5:48:ea:c0
[   49.044119] wlan0: associate with 38:10:d5:48:ea:c0 (try 1/3)
[   49.053519] wlan0: RX AssocResp from 38:10:d5:48:ea:c0 (capab=0x431 status=0 
aid=6)
[   49.083221] wlan0: associated
[   50.121982] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   70.989126] systemd-udevd[2529]: link_config: autonegotiation is unset or 
enabled, the speed and duplex are not writable.
[53281.316867] yenta_cardbus :05:00.0: CardBus bridge to [bus 06-07]
[53281.323237] yenta_cardbus :05:00.0:   bridge window [io  0x4000-0x40ff]
[53281.329552] yenta_cardbus :05:00.0:   bridge window [io  0x4400-0x44ff]
[53281.335692] yenta_cardbus :05:00.0:   bridge window [mem 
0xd800-0xdbff pref]
[53281.335704] yenta_cardbus :05:00.0:   bridge window [mem 
0xc000-0xc3ff]
[57283.196066] systemd-udevd[375]: Network interface NamePolicy= disabled on 
kernel command line, ignoring.
[57326.418304] systemd-udevd[375]: Network interface NamePolicy= disabled on 
kernel command line, ignoring.
[57326.422419] device-mapper: uevent: version 1.0.3
[57326.422665] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: 
dm-de...@redhat.com
[65468.521360] atkbd serio0: Unknown key released (translated set 2, code 0x5b 
on isa0060/serio0).
[65468.521374] atkbd serio0: Use 'setkeycodes 5b ' to make it known.
[69219.864468] b1: revision 1.1.2.2
[69219.870212] c4: revision 1.1.2.2
[100425.180073] iwl4965 :03:00.0: Queue 4 stuck for 2048 ms.
[100425.180097] iwl4965 :03:00.0: On demand firmware reload
[100425.184134] iwl4965 :03:00.0: Timeout stopping DMA channel 1 
[0xa5a5a5a2]
[100425.186121] iwl4965 :03:00.0: Timeout stopping DMA channel 3 
[0xa5a5a5a2]
[100425.186121] iwl4965 :03:00.0: Timeout stopping DMA channel 4 
[0xa5a5a5a2]
[100425.186121] iwl4965 :03:00.0: Timeout stopping DMA channel 6 
[0xa5a5a5a2]
[100425.199265] ieee80211 phy0: Hardware restart was requested
[100425.449449] WARNING: CPU: 1 PID: 15591 at 
/build/linux-s3QDK1/linux-4.18.10/net/mac80211/key.c:741 
ieee80211_enable_keys+0x114/0x120 [mac80211]
[100425.449454] Modules linked in: c4 b1 kernelcapi dm_mod cpuid snd_seq_dummy 
ctr ccm devlink cpufreq_conservative cpufreq_userspace cpufreq_powersave 
binfmt_misc nft_counter nft_chain_nat_ipv4 ipt_MASQUERADE nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 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 arc4 ppdev pcmcia 
iwl4965 coretemp iwlegacy kvm_intel snd_hda_intel snd_hda_codec mac80211 kvm 
snd_hda_core irqbypass snd_hwdep snd_pcm_oss snd_mixer_oss pcspkr serio_raw 
iTCO_wdt yenta_socket sg iTCO_vendor_support pcmcia_rsrc pcmcia_core cfg80211 
snd_pcm thinkpad_acpi snd_timer nvram snd soundcore ac rfkill battery 
pcc_cpufreq parport_pc parport button acpi_cpufreq evdev
[100425.449515]  ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb 
crypto_simd cryptd glue_helper aes_x86_64 sd_mod ata_generic ahci libahci 
ata_piix psmouse sdhci_pci i2c_i801 cqhci libata sdhci mmc_core i915 scsi_mod 
lpc_ich i2c_algo_bit drm_kms_helper video uhci_hcd ehci_pci ehci_hcd drm 
usbcore e1000e usb_common thermal
[100425.449554] CPU: 1 PID: 15591 Comm: kworker/1:1 Not tainted 4.18.0-2-amd64 
#1 Debian 4.18.10-2
[100425.449556] Hardware name: LENOVO 7673AG4/7673AG4, BIOS 

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

[Thorsten Glaser]

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

When I zoom on the opencaching.de map in Firefox, the GPU crashes pretty 
reliably.

I’m attaching the crash dump.

-- Package-specific info:
** Version:
Linux version 4.17.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-28)) #1 SMP Debian 4.17.17-1 (2018-08-18)

** Command line:
BOOT_IMAGE=/vmlinuz-4.17.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:
[2.798289] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[2.800096] ata3.00: Enabling discard_zeroes_data
[2.802147]  sda: sda1 sda2 sda3 sda4
[2.803954] ata3.00: Enabling discard_zeroes_data
[2.805493] sd 2:0:0:0: [sda] Attached SCSI disk
[2.960353] psmouse serio1: trackpoint: IBM TrackPoint firmware: 0x0e, 
buttons: 3/3
[2.979661] input: TPPS/2 IBM TrackPoint as 
/devices/platform/i8042/serio1/input/input5
[7.910449] cryptd: max_cpu_qlen set to 1000
[8.075900] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: 
(null)
[8.571302] parport_pc 00:06: reported by Plug and Play ACPI
[8.573106] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
[8.577685] ACPI: AC Adapter [AC] (on-line)
[8.598869] Non-volatile memory driver v1.3
[8.613853] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[8.618969] ACPI: Battery Slot [BAT0] (battery present)
[8.636049] thinkpad_acpi: ThinkPad ACPI Extras v0.26
[8.637722] thinkpad_acpi: http://ibm-acpi.sf.net/
[8.639372] thinkpad_acpi: ThinkPad BIOS 7NET30WW (1.11 ), EC 7MHT24WW-1.02
[8.640972] thinkpad_acpi: Lenovo ThinkPad X61, model 7673AG4
[8.650574] iTCO_vendor_support: vendor-support=0
[8.663371] thinkpad_acpi: radio switch found; radios are enabled
[8.664943] thinkpad_acpi: This ThinkPad has standard ACPI backlight 
brightness control, supported by the ACPI video driver
[8.666473] thinkpad_acpi: Disabling thinkpad-acpi brightness events by 
default...
[8.67] yenta_cardbus :05:00.0: CardBus bridge found [17aa:20c6]
[8.679721] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[8.685779] iTCO_wdt: Found a ICH8M-E TCO device (Version=2, TCOBASE=0x1060)
[8.688734] thinkpad_acpi: Standard ACPI backlight interface available, not 
loading native one
[8.690621] sd 2:0:0:0: Attached scsi generic sg0 type 0
[8.692810] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[8.693410] thinkpad_acpi: battery 1 registered (start 0, stop 0)
[8.694380] battery: new extension: ThinkPad Battery Extension
[8.703188] input: PC Speaker as /devices/platform/pcspkr/input/input8
[8.706785] input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input7
[8.722056] snd_hda_intel :00:1b.0: probe_mask set to 0x1 for device 
17aa:20ac
[8.799156] intel_powerclamp: No package C-state available
[8.821071] yenta_cardbus :05:00.0: ISA IRQ mask 0x0c38, PCI irq 16
[8.822680] yenta_cardbus :05:00.0: Socket status: 3006
[8.829765] yenta_cardbus :05:00.0: pcmcia: parent PCI bridge window: 
[io  0x4000-0x7fff]
[8.831544] yenta_cardbus :05:00.0: pcmcia: parent PCI bridge window: 
[mem 0xd400-0xd7ef]
[8.833369] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xd400-0xd7ef:
[8.834920]  excluding 0xd7b1-0xd7ef
[8.836503] yenta_cardbus :05:00.0: pcmcia: parent PCI bridge window: 
[mem 0xd800-0xdbff 64bit pref]
[8.838453] iwl4965: Intel(R) Wireless WiFi 4965 driver for Linux, in-tree:
[8.840202] iwl4965: Copyright(c) 2003-2011 Intel Corporation
[8.841333] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xd800-0xdbff:
[8.843318] iwl4965 :03:00.0: Detected Intel(R) Wireless WiFi Link 
4965AGN, REV=0x4
[8.844841]  excluding 0xd800-0xdbff
[8.886448] iwl4965 :03:00.0: device EEPROM VER=0x36, CALIB=0x5
[8.887405] iwl4965 :03:00.0: Tunable channels: 13 802.11bg, 19 802.11a 
channels
[8.896935] ppdev: user-space parallel port driver
[8.900990] iwl4965 :03:00.0: firmware: direct-loading firmware 
iwlwifi-4965-2.ucode
[8.900996] iwl4965 :03:00.0: loaded firmware version 228.61.2.24
[8.941695] ieee80211 phy0: Selected rate control algorithm 'iwl-4965-rs'
[8.951790] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f:
[8.951798]  excluding 0xc-0xd3fff 0xe-0xf
[8.951826] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xa000-0xa0ff:
[8.951835]  excluding 0xa000-0xa0ff
[8.951855] pcmcia_socket pcmcia_socket0: cs: memory probe 
0x6000-0x60ff:
[8.951864]  excluding 0x6000-0x60ff
[9.124038] snd_hda_codec_analog hdaudioC0D0: autoconfig for AD1984: 
line_outs=1 (0x12/0x0/0x0/0x0/0x0) type:speaker
[9.124042] 

Bug#909365: linux: backtrace when exiting X.org with Ctrl-Alt-Backspace

[Thorsten Glaser]

Package: src:linux
Version: 4.17.17-1
Severity: minor

I exited X.org after a quick session and got the following backtrace,
also spit on the console.

-- Package-specific info:
** Version:
Linux version 4.17.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-28)) #1 SMP Debian 4.17.17-1 (2018-08-18)

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

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[ 1890.801314]  cryptd glue_helper aes_x86_64 sd_mod ata_generic psmouse 
ata_piix i2c_i801 ahci uhci_hcd ehci_pci libahci sdhci_pci cqhci ehci_hcd sdhci 
libata lpc_ich scsi_mod mmc_core i915 usbcore e1000e usb_common i2c_algo_bit 
drm_kms_helper video drm button thermal
[ 1890.801365] CPU: 0 PID: 2673 Comm: Xorg Tainted: GW 
4.17.0-3-amd64 #1 Debian 4.17.17-1
[ 1890.801367] Hardware name: LENOVO 7673AG4/7673AG4, BIOS 7NET30WW (1.11 ) 
11/15/2007
[ 1890.801448] RIP: 0010:assert_plane+0x87/0x90 [i915]
[ 1890.801451] RSP: 0018:b532c200b808 EFLAGS: 00010282
[ 1890.801455] RAX:  RBX: 9b48ebb6b400 RCX: 0002
[ 1890.801458] RDX:  RSI: 0002 RDI: 0202
[ 1890.801461] RBP:  R08:  R09: 0035
[ 1890.801464] R10:  R11:  R12: 9b48ea6554b0
[ 1890.801467] R13: 9b48ee76 R14:  R15: 9b48ea6d8000
[ 1890.801472] FS:  7f2cd777ea40() GS:9b48fbc0() 
knlGS:
[ 1890.801476] CS:  0010 DS:  ES:  CR0: 80050033
[ 1890.801479] CR2: 556440d22ff0 CR3: 00022f97e000 CR4: 06f0
[ 1890.801481] Call Trace:
[ 1890.801567]  assert_planes_disabled.isra.100+0x48/0x60 [i915]
[ 1890.801647]  intel_enable_pipe+0x4a/0x200 [i915]
[ 1890.801729]  i9xx_crtc_enable+0x352/0x480 [i915]
[ 1890.801811]  intel_update_crtc+0x39/0x90 [i915]
[ 1890.801892]  intel_update_crtcs+0x47/0x60 [i915]
[ 1890.801972]  intel_atomic_commit_tail+0x1db/0xcc0 [i915]
[ 1890.802053]  intel_atomic_commit+0x29a/0x2d0 [i915]
[ 1890.802083]  restore_fbdev_mode_atomic+0x1af/0x220 [drm_kms_helper]
[ 1890.802104]  drm_fb_helper_restore_fbdev_mode_unlocked+0x45/0x90 
[drm_kms_helper]
[ 1890.802122]  drm_fb_helper_set_par+0x29/0x50 [drm_kms_helper]
[ 1890.802199]  intel_fbdev_set_par+0x16/0x60 [i915]
[ 1890.802209]  fb_set_var+0x179/0x3e0
[ 1890.802218]  ? __schedule+0x299/0x860
[ 1890.802224]  ? __switch_to_asm+0x40/0x70
[ 1890.802233]  fbcon_blank+0x26f/0x320
[ 1890.802244]  do_unblank_screen+0xb3/0x1a0
[ 1890.802249]  vt_ioctl+0x4d7/0x1120
[ 1890.802257]  ? filename_parentat+0x10b/0x190
[ 1890.802262]  tty_ioctl+0xef/0x890
[ 1890.802270]  ? current_time+0x18/0x70
[ 1890.802276]  do_vfs_ioctl+0xa4/0x630
[ 1890.802281]  ? dput.part.24+0x95/0x120
[ 1890.802288]  ? __fput+0x164/0x1e0
[ 1890.802293]  ksys_ioctl+0x70/0x80
[ 1890.802298]  __x64_sys_ioctl+0x16/0x20
[ 1890.802305]  do_syscall_64+0x55/0x110
[ 1890.802311]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1890.802316] RIP: 0033:0x7f2cd8684067
[ 1890.802319] RSP: 002b:7ffc0c7044e8 EFLAGS: 0246 ORIG_RAX: 
0010
[ 1890.802324] RAX: ffda RBX: 55644039d720 RCX: 7f2cd8684067
[ 1890.802327] RDX:  RSI: 4b3a RDI: 000c
[ 1890.802330] RBP:  R08: 556440d1e430 R09: 7f2cd86d1ee0
[ 1890.802333] R10: 0038 R11: 0246 R12: 5564403c0740
[ 1890.802336] R13:  R14: 5564403bc6e8 R15: 5564403a1b90
[ 1890.802340] Code: e6 19 42 c0 84 c0 48 c7 c2 e9 19 42 c0 48 89 f1 48 c7 c7 
48 4e 43 c0 48 0f 44 ca 40 84 ed 48 0f 45 d6 48 8b 73 18 e8 49 91 4d dc <0f> 0b 
eb 92 0f 1f 44 00 00 66 66 66 66 90 c1 e6 0c 53 89 d3 81 
[ 1890.802423] ---[ end trace 7f3b33238a1964b8 ]---
[ 1891.102331] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe A FIFO underrun
[ 1891.103547] [ cut here ]
[ 1891.103552] cursor A assertion failure (expected off, current on)
[ 1891.103742] WARNING: CPU: 1 PID: 2673 at 
/build/linux-LgHyGB/linux-4.17.17/drivers/gpu/drm/i915/intel_display.c:1231 
assert_plane+0x87/0x90 [i915]
[ 1891.103744] Modules linked in: ctr ccm devlink cpufreq_conservative 
cpufreq_userspace cpufreq_powersave binfmt_misc ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack libcrc32c ip_tables x_tables tun snd_seq_midi 
snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_hda_codec_analog 
snd_hda_codec_generic arc4 pcmcia ppdev iwl4965 iwlegacy coretemp kvm_intel 
snd_hda_intel mac80211 snd_hda_codec kvm irqbypass snd_hda_core sg pcspkr 
serio_raw iTCO_wdt snd_hwdep snd_pcm_oss yenta_socket snd_mixer_oss pcmcia_rsrc 
cfg80211 iTCO_vendor_support pcmcia_core thinkpad_acpi snd_pcm nvram snd_timer 
snd shpchp 

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#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#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#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#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#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#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: 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: 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#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#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#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#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#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#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#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#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#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#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#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: 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]

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: __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#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#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#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#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#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 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]

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]

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#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#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#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#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#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#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: [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: 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#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#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#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#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: 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: 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 (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#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#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#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#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]

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#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#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#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:

>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#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

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#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#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#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]

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]

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

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#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