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

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

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

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

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#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: 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 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: 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#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#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: 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#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#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#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#763614: m68k machines not coming up after last update

2014-10-02 Thread Thorsten Glaser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 #763614 causes our machines to no longer boot, since they usually at most use klibc-utils to get small ramdisks. AIUI, the “fix” is to install busybox or busybox-static. This is not enough, you have to run “update-initramfs -u” manually afterwards.

Bug#763614: Bug#763049: m68k machines not coming up after last update

2014-10-02 Thread Thorsten Glaser
John Paul Adrian Glaubitz dixit: SCNR but to note that mksh has a realpath builtin and compiles cleanly with klibc. Yes, but unfortunately, most people agreed on using bash and often you have no other choice but to use it. I'd also rather use zsh. initrd uses klibc’s flavour of dash ☹ or some

Re: [klibc] [PATCH 2/2] readlink: Add -f option

2014-09-28 Thread Thorsten Glaser
Ben Hutchings dixit: This is needed to support mounting non-root filesystems in initramfs-tools. As an alternative, you can use mksh (built against klibc) which has a “realpath” builtin. It just takes one argument, the path to resolve, and no flags. bye, //mirabilos -- Wish I had pine to hand

Bug#762836: linux-image-3.16-2-amd64: reg_process_hint call trace in dmesg

2014-09-25 Thread Thorsten Glaser
Package: src:linux Version: 3.16.3-2 Severity: minor I have weird backtraces in dmesg I wanted to report, in case they are relevant. Full dmesg attached. -- Package-specific info: ** Version: Linux version 3.16-2-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-11) ) #1

Re: Bug#755471: ifupdown: fails to bring up network: cannot access '/dev/net/tun': ENOENT

2014-07-21 Thread Thorsten Glaser
Andrew Shadura dixit: Thorsten Glaser t...@mirbsd.de wrote: I am not sure whether ifupdown is the correct package for this bugreport. Please reassign to whatever is, if it isn't. I'm not sure what causes this, but /dev/net/tun is missing, as the logs say. Could be a kernel problem, or a bug

Re: I/O schedulers for m68k

2014-07-11 Thread Thorsten Glaser
Ben Hutchings dixit: I think this is a mistake and that cfq should be reverted to built-in so it can be the default, as on other architectures. Any objection to me doing that? None from me, I was probably just saving space pre-initrd. Which one is chosen, I will leave up to the experts, i.e.

Bug#689962: linux-image-3.2.0-4-amd64: Compile with CONFIG_VIRTIO_CONSOLE=y

2014-06-11 Thread Thorsten Glaser
On Sat, 13 Oct 2012, Vincent Bernat wrote: In fact, as of 3.6, it is not possible to use virtconsole as an initial console. I don't know if this will be fixed later but this makes the bug It’s fixed. I just installed Ubuntu’s 3.15 on Debian wheezy and booted with “console=hvc0” and it worked.

Bug#746618: linux-latest: actually build-depend on the linux version depended on

2014-05-01 Thread Thorsten Glaser
Source: linux-latest Version: 57 Severity: wishlist Hi, would be really cool if src:linux-latest actually build-depended on the architecture-specific binaries of the sec:linux version its binaries are going to depend on. AFAICT, a versioned B-D on linux-libc-dev would do the trick, in an

Bug#744193: linux-image-3.13-1-amd64: fails to shut down: handle_exit: unexpected exit_int_info ...

2014-04-30 Thread Thorsten Glaser
On Mon, 14 Apr 2014, Ben Hutchings wrote: Do you mean that when there is a VM that won't shutdown cleanly, rebooting the host consistently works but power-off consistently fails? After quite some more test runs (although I admit not trying without the nvidia nonfree module), I can confirm that

Bug#744193: linux-image-3.13-1-amd64: fails to shut down: handle_exit: unexpected exit_int_info ...

2014-04-15 Thread Thorsten Glaser
On Mon, 14 Apr 2014, Ben Hutchings wrote: Do you mean that when there is a VM that won't shutdown cleanly, rebooting the host consistently works but power-off consistently fails? Sorry, no. I meant: without a VM that will not respond to ACPI shutdown events, “sudo poweroff” works. I’ll test a

Bug#744193: linux-image-3.13-1-amd64: fails to shut down: handle_exit: unexpected exit_int_info ...

2014-04-14 Thread Thorsten Glaser
On Fri, 11 Apr 2014, Ben Hutchings wrote: I typed “sudo poweroff” as usual on Debian… the system switched to the text console and mostly hung. Is this reproducible when not using the nvidia module? Hrm. I’d have to try, but first a quick shot… [.xxx] handle_exit: unexpected

Bug#744193: linux-image-3.13-1-amd64: fails to shut down: handle_exit: unexpected exit_int_info ...

2014-04-14 Thread Thorsten Glaser
On Mon, 14 Apr 2014, Thorsten Glaser wrote: … I still had a VM running in kvm/libvirt, which would not respond to normal ACPI shutdown commands. Maybe this is the cause of this issue? FWIW, I was able to reboot without a VM “hanging”, just fine. bye, //mirabilos -- tarent solutions GmbH

Bug#744193: linux-image-3.13-1-amd64: fails to shut down: handle_exit: unexpected exit_int_info ...

2014-04-11 Thread Thorsten Glaser
Package: src:linux Version: 3.13.7-1 Severity: normal Hi *, I had to reboot to cleanse my system of running KDE, dbus, etc. again (since KDEPIM didn’t want to “see” new incoming eMails… this used to work better in KDE 3… but offtopic for here), and since reboots heal problems anyway, and since

Re: Problem with packages version(on m68k architecture, but also on amd64 and maybe somewhere else)

2014-04-01 Thread Thorsten Glaser
Ondrej Riha dixit: linux-headers-2.6-* and linux-image-2.6-* and linux-doc-2.6-* These packages no longer exist, they have been removed from unstable. Debian-Ports mini-dak does not generally follow this sort¹ of removals automatically, so they will eventually be cleaned up manually. The

Bug#734289: linux: please add CONFIG_EARLY_PRINTK=y on m68k

2014-01-05 Thread Thorsten Glaser
Source: linux Severity: wishlist Tags: patch Dear Maintainers, please add the following patch to your next upload of src:linux, as per discussion with upstream in… I’d include a link, but article.gmane.org is currently down. This option used to be always enabled, then the default changed

Bug#728392: linux: Please update m68k config

2013-11-14 Thread Thorsten Glaser
Dixi quod… Ben Hutchings dixit: One’s to add back CONFIG_BRK which is apparently needed to run a popular ramdisk image used e.g. when testing the hardware or setting up a completely new system. You mean CONFIG_COMPAT_BRK. I don't like this but I doubt anyone cares to write exploits for m68k

Bug#728392: linux: Please update m68k config

2013-11-10 Thread Thorsten Glaser
Ben Hutchings dixit: One’s to add back CONFIG_BRK which is apparently needed to run a popular ramdisk image used e.g. when testing the hardware or setting up a completely new system. You mean CONFIG_COMPAT_BRK. I don't like this but I doubt anyone cares to write exploits for m68k any more.

Bug#728392: linux: Please update m68k config

2013-10-31 Thread Thorsten Glaser
) UNRELEASED; urgency=low + + [ Thorsten Glaser ] + * Update m68k config: +- enable BRK by explicit upstream (m68k maintainer) request +- re-enable FPU emulation after discussion upstream, by popular request +- disable ADB_MACIISI by upstream (Mac68k maintainer) request + + -- Thorsten Glaser

Bug#719531: linux: please apply another m68k patch

2013-08-12 Thread Thorsten Glaser
.patch: patch from Andreas +Schwab to handle do_div being called with a nōn-u32 second argument + * m68k: begin working on d-i kernel configs (just enough to not FTBFS) + + -- Thorsten Glaser t...@mirbsd.de Fri, 09 Aug 2013 20:36:12 + + linux (3.10.5-1) unstable; urgency=low * New

Re: linux 3.10.1 with initrd

2013-07-30 Thread Thorsten Glaser
Geert Uytterhoeven dixit: 404 Sorry, bit slow ;-) http://www.freewrt.org/~tg/dp/dists/hacks/clean/Notyet/linux-image-3.10-1-m68k_3.10.3-1_m68k.deb bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig

Bug#718271: FTBFS: could not find kernel image at …/kernel-wedge/…/install-files line 101, KVERS line 2.

2013-07-29 Thread Thorsten Glaser
Source: linux Version: 3.10.3-1 Severity: important Justification: fails to build from source (but built successfully in the past) Hi, the latest Linux kernel source package fails to build: […] make[2]: Entering directory `/tmp/buildd/linux-3.10.3' dh_testdir dh_prep kernel-wedge install-files

Bug#718271: linux: FTBFS: could not find kernel image at …/kernel-wedge/…/install-files line 101, KVERS line 2.

2013-07-29 Thread Thorsten Glaser
Sorry, of course I forgot the attachment… bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and

Bug#718271: FTBFS: could not find kernel image at …/kernel-wedge/…/install-files line 101, KVERS line 2.

2013-07-29 Thread Thorsten Glaser
Ben Hutchings dixit: Well you gave us the new m68k configuration. I kind of hoped you'd at least done a full build test. I wasn’t quick enough, it all takes a lot of time. I literally could not have finished before you uploaded. The installer udeb configuration under debian/installer/m68k

Re: Bug#717689: linux: please review and merge m68k patch

2013-07-27 Thread Thorsten Glaser
Ben Hutchings dixit: I've split it this time, but please separate your changes into a proper patch series in future. Okay, will do, if I’m aware what should be split of course. Also it's not clear where the patch ethernat-kconfig.patch comes from. I wondered why I couldn’t select it, looked at

Re: Bug#717689: linux: please review and merge m68k patch

2013-07-27 Thread Thorsten Glaser
Ben Hutchings dixit: Also it's not clear where the patch ethernat-kconfig.patch comes from. Here you are. Geert, I’ve noticed that this particular bit seems to not have made it into torvalds/linux.git yet, even though the remainder of it has; can you please have a look at it and submit?

Re: Bug#717689: linux: please review and merge m68k patch

2013-07-27 Thread Thorsten Glaser
Michael Schmitz dixit: There's no harm in including the Kconfig patch to enable building the smc91x module, but there'd no gain in that either - you still need the patch to smc91x.h to make it work. Oh okay. From the presence of the new driver options in the architecture config I thought it

Re: Bug#717689: linux: please review and merge m68k patch

2013-07-26 Thread Thorsten Glaser
Ben Hutchings dixit: then I think it should be enabled for all architectures - as a separate change from the m68k config update. Sure, no complaints from me there. Is the patch I sent enough (splitting it is easy)? bye, //mirabilos -- “Having a smoking section in a restaurant is like having

Re: Bug#717689: linux: please review and merge m68k patch

2013-07-24 Thread Thorsten Glaser
On Wed, 24 Jul 2013, Ben Hutchings wrote: [ ext2/3/4 ] I think we may want to enable this at the top level later, but there is no reason to override it now. OK, will remove that. +CONFIG_NFS_SWAP=y Really? Not? Is there something better? Hm, Wouter would probably say swap over nbd :D

Bug#717689: linux: please review and merge m68k patch

2013-07-24 Thread Thorsten Glaser
Dixi quod… Another thing that puzzles me: config SMC91X depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \ MN10300 || COLDFIRE || ARM64) Maybe just an explicit || ATARI_ETHERNAT here? Add || ATARI_ETHERNEC to NE2000 as well I’d say, so everyone Ah this is

Re: Bug#717689: linux: please review and merge m68k patch

2013-07-24 Thread Thorsten Glaser
Ben Hutchings dixit: Yes, but why should this be m68k-specific? OK. I’ll resend a patch that makes CONFIG_NFS_SWAP global and addresses the other things raised. Will you also want the Macintosh codepages for HFS+ be made global? (I assume so, since HFS+ is globally enabled.) bye, //mirabilos

Bug#717689: linux: please review and merge m68k patch

2013-07-23 Thread Thorsten Glaser
Dixi quod… Even if this may have some minor issues still, it’ll be better than building kernel images that fail to boot at all, that’s why Ah well. Of course it didn’t boot. /lib/modules/3.10-0+m68k.2-m68k/kernel/arch/m68k/emu/nfblock.ko is the “IDE” driver for ARAnyM machines (like

  1   2   >