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

2020-04-09 Thread Thomas Gleixner
Andy Lutomirski writes: > On Wed, Apr 8, 2020 at 7:34 AM Thorsten Glaser wrote: >> asm/unistd_x32.h:#define __NR_mmap (__X32_SYSCALL_BIT + 9) >> >> This construct is, thankfully, still usable in something like >> #if (__NR_mmap > __NR_somethingelse) >> but as __X32_SYSCALL_BIT is no

Bug#940942: Acknowledgement (alpine: S/MIME signed mails sent from alpine cannot be verified due to a digest mismatch)

2019-09-22 Thread Thomas Gleixner
On Sun, 22 Sep 2019, Debian Bug Tracking System wrote: > Your message has been sent to the package maintainer(s): > Asheesh Laroia > > If you wish to submit further information on this problem, please > send it to 940...@bugs.debian.org. This message is S/MIME signed to illustrate the problem.

Bug#940942: alpine: S/MIME signed mails sent from alpine cannot be verified due to a digest mismatch

2019-09-22 Thread Thomas Gleixner
Package: alpine Version: 2.21+dfsg1-1.1 Severity: important Tags: upstream Dear Maintainer, S/MIME signed mail sent from alpine fails to verify even if sent to myself and read with alpine. The same S/MIME key/crt pair is valid and is working perfectly fine on other mail clients, e.g. evolution.

Bug#900784: Update

2018-06-05 Thread Thomas Gleixner
The upstream git repository has already a better fix, which makes the sed regex case insensitive: 360b85e1f6b6 ("mail: Fix patch set threading") Can this please be added to the debian package? Thanks, tglx

Bug#900784: quilt: mail threading is broken

2018-06-04 Thread Thomas Gleixner
procmail 3.22-26 -- debconf-show failed *** /home/tglx/work/projects/quilt/patches/mail--Use-Message-ID-consistently.patch Subject: mail: Use Message-ID consistently From: Thomas Gleixner Date: Mon, 04 Jun 2018 22:09:21 +0200 The Message-ID extraction from the cover letter fai

Bug#855183: linux-image-4.9.0-0.bpo.1-amd64: modprobe intel_rapl_perf stay in uninterruptible sleep

2017-02-20 Thread Thomas Gleixner
On Mon, 20 Feb 2017, Miloslav Hůla wrote: > Dne 17.02.2017 v 11:47 Thomas Gleixner napsal(a): > > What's really confusing is this information from the bug report: > > > > " When I changed: > > > > Power technology: > > - from Energy Efficient >

Bug#855183: linux-image-4.9.0-0.bpo.1-amd64: modprobe intel_rapl_perf stay in uninterruptible sleep

2017-02-17 Thread Thomas Gleixner
On Fri, 17 Feb 2017, Ben Hutchings wrote: > On Wed, 2017-02-15 at 09:08 +0100, Miloslav Hula wrote: > [...] > > When I boot the system up, there is a constant load 1.0. I found one > > process systemd-udevd in uninterruptible sleep. > > Digging in proc/PID/fd I found, this proces usees fd 7 for >

Bug#817816: [PATCH V2] x86/irq: Cure live lock in fixup_irqs()

2016-03-14 Thread Thomas Gleixner
Junior <harr...@outlook.fr> Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: sta...@vger.kernel.org --- arch/x86/include/asm/hw_irq.h |1 arch/x86/kernel/apic/vector.c | 88 +- 2 files changed, 71 insertions(+), 18 deletions(-) -

Bug#700333: Stack trace

2013-04-28 Thread Thomas Gleixner
On Sun, 28 Apr 2013, Borislav Petkov wrote: On Sun, Apr 28, 2013 at 05:26:07PM +0400, vita...@yourcmc.ru wrote: When you do a suspend/resume cycle. OK, yes, I've found it there. The bug says The photo shows a BUG in hrtimer_interrupt() after making the hibernation image and while

Bug#700333: Stack trace

2013-04-25 Thread Thomas Gleixner
On Mon, 22 Apr 2013, Thomas Gleixner wrote: With the patch below, the box should survive and we should see a Spurious HPET timer interrupt on HPET timer... entry in dmesg. That's a first workaround to confirm my theory. I'll look into the HPET code how we can avoid that at all. Looks

Bug#700333: Stack trace

2013-04-22 Thread Thomas Gleixner
On Sun, 21 Apr 2013, Borislav Petkov wrote: + tglx. On Sun, Apr 21, 2013 at 01:38:33AM +0400, vita...@yourcmc.ru wrote: Stack trace picture is here: http://vmx.yourcmc.ru/var/pics/IMG_20130306_141045.jpg Vitaliy reported that his system crashes when suspending to disk. This was a