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

2015-08-09 Thread Thorsten Glaser
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

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

2015-10-26 Thread 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

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

2015-11-15 Thread 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.

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

2015-11-14 Thread 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

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

2015-09-17 Thread 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

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

2015-09-28 Thread 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,

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

2015-09-21 Thread 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

Bug#824543: update-initramfs: cp: cannot stat '/etc/modprobe.d/*': No such file or directory

2016-05-17 Thread 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

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

2017-02-09 Thread 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

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

2017-01-17 Thread 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

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

2017-01-17 Thread 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

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)

2017-01-17 Thread 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

Bug#838476: firmware-linux-nonfree: warnings about missing i915 firmware after upgrading

2016-09-21 Thread 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

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

2017-07-25 Thread 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

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

2017-06-25 Thread 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

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

2017-06-25 Thread 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:

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

2017-05-08 Thread 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

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

2017-05-08 Thread 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

Re: Fixing Linux getrandom() in stable

2018-05-13 Thread 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

Re: Fixing Linux getrandom() in stable

2018-05-13 Thread 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

Bug#890326: linux: Thinkpad X61 brightness reset to 0% on each boot

2018-02-13 Thread 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

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

2018-09-04 Thread 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

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

2018-11-07 Thread 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

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

2018-11-07 Thread 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 solution

Bug#912936: linux: kernel WARNING in ieee80211_delayed_tailroom_dec

2018-11-04 Thread 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

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

2018-09-03 Thread 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

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

2018-09-22 Thread 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

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

2019-01-23 Thread 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

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

2019-01-23 Thread 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

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

2018-12-08 Thread 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

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

2019-01-03 Thread 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

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

2019-01-02 Thread 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 >

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

2018-12-19 Thread 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]

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

2019-03-23 Thread 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

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

2019-02-25 Thread 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

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

2019-02-28 Thread 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

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

2019-03-06 Thread 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

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

2019-02-26 Thread 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

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

2019-06-14 Thread 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 ?

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

2019-06-14 Thread 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

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

2019-08-14 Thread 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

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

2019-07-18 Thread 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

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

2019-10-02 Thread 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

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

2019-10-02 Thread 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

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

2019-10-24 Thread 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

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

2019-10-24 Thread 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,

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

2019-10-22 Thread 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

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

2019-10-25 Thread 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?)

2019-11-20 Thread 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.

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

2019-11-20 Thread 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

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

2019-11-20 Thread 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

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

2020-04-08 Thread 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

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)

2020-04-08 Thread 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

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

2020-04-08 Thread 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

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

2020-04-08 Thread 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,

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

2020-04-09 Thread 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

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

2020-04-07 Thread 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 >

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

2020-04-21 Thread 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

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

2020-04-29 Thread 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

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

2020-05-26 Thread 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

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

2020-08-03 Thread 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

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

2020-08-04 Thread 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 *c

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

2020-08-02 Thread 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

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

2020-08-02 Thread 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

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")

2020-07-09 Thread 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 >>

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)

2020-06-25 Thread 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 •

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

2020-06-16 Thread 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

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

2020-06-10 Thread 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

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

2020-07-28 Thread 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

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

2020-11-21 Thread 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

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

2020-12-02 Thread 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

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

2020-11-13 Thread 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

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

2021-05-05 Thread Thorsten Glaser
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-

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

2021-05-21 Thread 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.”

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

2021-05-26 Thread Thorsten Glaser
) (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

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

2021-04-24 Thread 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

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

2021-05-03 Thread 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

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

2021-05-03 Thread 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 */ >

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

2021-05-03 Thread 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;

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

2021-05-04 Thread 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

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

2021-05-05 Thread 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

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

2021-05-03 Thread 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

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

2021-02-26 Thread 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:

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

2021-02-26 Thread 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

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

2021-10-10 Thread 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

2022-03-27 Thread 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

Bug#1004465: libklibc-dev: headers not installed

2022-01-27 Thread 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

Bug#1004465: libklibc-dev: headers not installed

2022-01-28 Thread 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

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

2023-11-10 Thread 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.

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

2022-06-21 Thread 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

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

2022-06-29 Thread 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

Bug#522773: possible solutions for __unused problem

2022-06-09 Thread 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.

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

2022-06-18 Thread 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

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

2022-06-18 Thread 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

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

2022-06-21 Thread 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

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

2022-06-21 Thread 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,

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

2022-06-21 Thread 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

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

2022-06-21 Thread 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

problems getting the -common header package

2022-06-02 Thread 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

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

2022-08-23 Thread 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,

<    1   2   3   >