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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 >
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]
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
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
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
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
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
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 ?
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
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
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
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
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
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
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,
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
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 :-)
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.
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
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
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
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
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
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,
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
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
>
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
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
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
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
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
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
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
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
>>
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 •
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
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
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
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
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
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
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-
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.”
) (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
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
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
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 */
>
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;
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
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
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
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:
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
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.
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
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
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
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.
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
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
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.
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
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
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
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,
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
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
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
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,
101 - 200 of 226 matches
Mail list logo