Bug#928189: Bug#922666: confirmed bug report

[Antoine Beaupré]

On 2021-05-03 20:44:31, Antoine Beaupré wrote:
> On 2021-05-03 20:27:26, Antoine Beaupré wrote:
>
> [...]
>
>> Interestingly, it seems that the machine indeed doesn't go to sleep: it
>> loops over a failure to sleep and fills up syslog with errors as long as
>> it's trying to sleep, pretty catastrophic, from a battery usage
>> perspective.
>>
>> I attach the two logs and am continuing my investigation. User now
>> reports situation is actually much worse than before the backports
>> upgrade: at least 5.7 was intermittent, now the crash is systematic.
>
> Relevant: booting into 4.19.132, from plain buster, doesn't reproduce
> the above failure to suspend. The machine suspends fine, and resumes,
> and the mouse even still works correctly.
>
> I wonder if this is a regression introduced in backports. But I could
> have sworn this was happening *before* I upgraded to the backported
> kernels...

And that is confirmed: it does happen in older kernels, just less
reliably.

a.

-- 
We know the road to freedom has always been stalked by death.
- Angela Davis

Bug#922666: confirmed bug report

[Antoine Beaupré]

On 2021-05-03 20:27:26, Antoine Beaupré wrote:

[...]

> Interestingly, it seems that the machine indeed doesn't go to sleep: it
> loops over a failure to sleep and fills up syslog with errors as long as
> it's trying to sleep, pretty catastrophic, from a battery usage
> perspective.
>
> I attach the two logs and am continuing my investigation. User now
> reports situation is actually much worse than before the backports
> upgrade: at least 5.7 was intermittent, now the crash is systematic.

Relevant: booting into 4.19.132, from plain buster, doesn't reproduce
the above failure to suspend. The machine suspends fine, and resumes,
and the mouse even still works correctly.

I wonder if this is a regression introduced in backports. But I could
have sworn this was happening *before* I upgraded to the backported
kernels...

And here I was hoping that upgrading to bullseye might fix this, maybe
it would make things even worse because the old kernel wouldn't be
available anymore (although if it's an interoperability issue, then
maybe it would fix it, who knows nowadays...)

-- 
No animal has more liberty than the cat; but it buries the mess it
makes. The cat is the best anarchist. Until they learn that from the cat
I cannot respect them.
- For whom the bell tolls, Ernest Hemingway

Bug#922666: confirmed bug report

[Antoine Beaupré]

On 2021-05-03 07:37:42, Salvatore Bonaccorso wrote:
> Control: found -1 5.10.24-1
>
> Hi Antoine,
>
> On Sun, May 02, 2021 at 08:22:07PM -0400, Antoine Beaupré wrote:
>> On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
>> > Hi Antoine
>> >
>> > On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
>> >> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
>> >> > Control: tags -1 + moreinfo
>> >> >
>> >> > Hi Tollef, Antoine,
>> >> >
>> >> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> >> >> Control: forcemerge 922666 928189
>> >> >> Control: severity 922666 important
>> >> >> Control: tags 922666 +patch +confirmed
>> >> >> 
>> >> >> I also see a regression with touchpads and trackpoint on a Thinkpad 
>> >> >> E431
>> >> >> after upgrading from Debian stretch to buster. My research indicates
>> >> >> this is a kernel regression, as yet to be fixed.
>> >> >> 
>> >> >> This is the result of my research, as available online at:
>> >> >> 
>> >> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> >> >> 
>> >> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> >> >> freezes after sleep. Keyboard still works but not mouse until a
>> >> >> reboot.
>> >> >> 
>> >> >> There's [bug 922666][] in Debian buster, without a fix. It also says
>> >> >> it eventually recovers, which is not our experience. Possible dupe is
>> >> >> [bug 928189][].
>> >> >> 
>> >> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> >> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> >> >> 
>> >> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> >> >> which proposes the following workarounds:
>> >> >> 
>> >> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> >> >> disabled`
>> >> >> 
>> >> >>  * A .service file:
>> >> >> 
>> >> >> # /etc/systemd/system/touchpad-sleep.service
>> >> >> # restore touchpad on suspend
>> >> >> 
>> >> >> [Unit]
>> >> >> Description=Restore Touchpad on suspend
>> >> >> Before=sleep.target
>> >> >> StopWhenUnneeded=yes
>> >> >> 
>> >> >> [Service]
>> >> >> #Type=oneshot
>> >> >> Type=idle
>> >> >> RemainAfterExit=yes
>> >> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/unbind'
>> >> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/bind'
>> >> >> 
>> >> >> [Install]
>> >> >> WantedBy=sleep.target
>> >> >> 
>> >> >>  * "Maybe try xserver-xorg-input-evdev instead of 
>> >> >> xserver-xorg-input-libinput?"
>> >> >> 
>> >> >>  * reloading `psmouse`:
>> >> >>  
>> >> >> sudo modprobe -r psmouse
>> >> >> sudo modprobe psmouse
>> >> >> 
>> >> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` 
>> >> >> seems to solve the issue."
>> >> >> 
>> >> >>  * whatever this is:
>> >> >>  
>> >> >> # echo 1 > /sys/devices/rmi4-00/nosleep
>> >> >> 
>> >> >>  * "Anyone who still affected by touchpad issues after S3. Please
>> >> >>switch back to suspend-to-idle in BIOS if s2idle is
>> >> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>> >> >>suspend-to-idle in BIOS->config->power menu."
>> >> >> 
>> >> >> [bug 1791427]: 
>> >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
>> >> >> 
>> >> >> There's also [bug 1442699][] in Fedora, which suggests those
>> >> >> workarounds:
>> >> >> 
>> >> >>  * another module reload:
>> >> >>  
>> >> >> sudo rmmod i2c_hid
>> >> >> sudo modprobe i2c_hid
>> >> >> 
>> >> >>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>> >> >>and this issue seems to have been resolved (for me)."
>> >> >> 
>> >> >>  * another `/proc` hack:
>> >> >>  
>> >> >> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
>> >> >> 
>> >> >>  * "The `psmouse.synaptics_intertouch=0` workaround still works for 
>> >> >> me."
>> >> >> 
>> >> >> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
>> >> >> 
>> >> >> Also related is this [libinput bug][] that's closed as "not our bug"
>> >> >> because they claim it's a bug in the kernel.
>> >> >> 
>> >> >> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
>> >> >> 
>> >> >> There are [two][] [patches][] on the Linux kernel which apparently fix 
>> >> >> the
>> >> >> issue, still pending approval:
>> >> >> 
>> >> >> [two]: https://lkml.org/lkml/2019/2/20/700
>> >> >> [patches]: https://lkml.org/lkml/2019/2/20/701
>> >> >> 
>> >> >> Possibly related: https://lkml.org/lkml/2016/8/18/134
>> >> >> 
>> >> >> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
>> >> >> [pull request][] has been merged in mainline with two other fixes on
>> >> >> the module./ [5.0.11][] also has fixes on the module. It's clearly a
>> >> >> 

Bug#943425: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use (was Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2))

[Thorsten Glaser]

Dixi quod…

>So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
>https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
>“the z/Architecture ABI,[11] used in Linux” a page down), while
>glibc’s save f8–f15 instead.

Jessica Clarke brought out docs saying f8‥f15 must be saved, the
other FPU registers not:
https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.html#AEN413

This matches what glibc does. Maybe an s390x porter wishes to fix
Wikipedia?

>https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf
>shows that the vector registers overlap and extend the FPU registers.

>• is register v10 (vector extension) even supposed to be used?

This needs to be answered, I guess, because…

>• klibc does not really support the FPU anyway

… GCC chooses to allocate an FPU register for a pointer value.

>• the half of v10 that equals f10 just HAPPENS to be saved by
>  glibc, but what if the upper half, that is outside of the FPU,
>  is used?

The question here is, does GCC only use the halves of the half
of the vector registers that match the FPU registers?

@klibc list: as indicated earlier, I can provide a patch if needed
(though it should be obvious).

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> affects 988027 src:mksh
Bug #988027 [libklibc-dev] klibc: sigsetjmp ignores second argument, siglongjmp 
always restores signals
Added indication that 988027 affects src:mksh
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
988027: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988027
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Thorsten Glaser]

Package: libklibc-dev
Version: 2.0.8-6
Severity: serious
Justification: spec violation, affecting release architectures
X-Debbugs-Cc: t...@debian.org

Found during debugging of #943425:

- usr/include/setjmp.h

struct __sigjmp_buf {
jmp_buf __jmpbuf;
sigset_t __sigs;
};
  => does not contain information whether __sigs was saved

#define sigsetjmp(__env, __save) \
({ \
  struct __sigjmp_buf *__e = (__env); \
  sigprocmask(0, NULL, &__e->__sigs); \
  setjmp(__e->__jmpbuf); \
})
  => ignores the __save argument

- usr/klibc/siglongjmp.c

__noreturn siglongjmp(sigjmp_buf buf, int retval)
{
sigprocmask(SIG_SETMASK, >__sigs, NULL);
longjmp(buf->__jmpbuf, retval);
  => always restores __sigs

This is in direct violation to the Debian sigsetjmp(3) docs...

   If, and only if, the savesigs argument provided to sigsetjmp() is  non-
   zero, the process's current signal mask is saved in env and will be re-
   stored if a siglongjmp() is later performed with this env.

... and POSIX:

 * The siglongjmp() function shall restore the saved signal mask if and
   only if the env argument was initialized by a call to [9]sigsetjmp()
   with a non-zero savemask argument.
  Q: https://pubs.opengroup.org/onlinepubs/9699919799/functions/siglongjmp.html


If necessary I can provide a patch to fix this.

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: s390x

Kernel: Linux 4.19.0-16-s390x (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libklibc-dev depends on:
ii  libklibc2.0.8-6
ii  linux-libc-dev  5.10.28-1

libklibc-dev recommends no packages.

libklibc-dev suggests no packages.

-- no debconf information

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

[Thorsten Glaser]

retitle 943425 klibc: [s390x] setjmp/longjmp do not save/restore all registers 
in use
# because this affects a release architecture
severity 943425 serious
thanks

Recapping for the benefit of d-s390@l.d.o:

> The code in question (where it crashes) is thus:

>1607  */
>1608 valsub(t, NULL);
>1609 subst_exstat = exstat & 0xFF;
>1610 /* rewind the tempfile and restore regular stdout */
>1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);

> The crash occurs in line 1611 because shf (a local variable) is nil.
>
> The really interesting part, though, is in line 1608, a call to valsub():

[…]
>2104 if (!kshsetjmp(e->jbuf))
>2105 execute(t, XXCOM | XERROK, NULL);
[…]

kshsetjmp(x) is sigsetjmp(x,0) (though klibc ignores the 0).

execute() calls siglongjmp().

> - it appears as if the combination of sigsetjmp/siglongjmp does not restore
>   all callee-saved variables correctly on s390x; comparing with glibc shows
>   that the wrong FPU registers seem to be saved but mksh does not use the
>   FPU anyway
>
> Setting breakpoints to lines 1608 (valsub call) and 1609:

[…]
> 1608valsub(t, NULL);
> (gdb) print shf
> $5 = (struct shf *) 0x3fffdfe5de8
> (gdb) print 
> Address requested for identifier "shf" which is in register $v10
> (gdb) print $v10
> $6 = {v4_float = {1.43352833e-42, -4.22639375e+37, 0, 0}, v2_double = 
> {2.1729070589754877e-311, 0}, v16_int8 = {
> 0, 0, 3, -1, -3, -2, 93, -24, 0, 0, 0, 0, 0, 0, 0, 0}, v8_int16 = {0, 
> 1023, -514, 24040, 0, 0, 0, 0},
>   v4_int32 = {1023, -33661464, 0, 0}, v2_int64 = {4398012849640, 0}, uint128 
> = 81129017470195127308370827018240}
>
> 0x3FFFDFE5DE8 is 4398012849640 which is in v2_int64, found.
[…]
> Breakpoint 2, comsub (fn=14, cp=0x0, xp=) at 
> ../../eval.c:1609
> 1609subst_exstat = exstat & 0xFF;
[…]
> (gdb) print $v10
> $7 = {v4_float = {0, 0, 0, 0}, v2_double = {0, 0}, v16_int8 = {0  times>}, v8_int16 = {0, 0, 0, 0,
> 0, 0, 0, 0}, v4_int32 = {0, 0, 0, 0}, v2_int64 = {0, 0}, uint128 = 0}

--

So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
“the z/Architecture ABI,[11] used in Linux” a page down), while
glibc’s save f8–f15 instead.

https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf
shows that the vector registers overlap and extend the FPU registers.

(gdb) info float
[…]
f102.172907066248134e-311 (raw 0x03fffdfe9768)
(gdb) print shf
$2 = (struct shf *) 0x3fffdfe9768

The real questions here are:

• is register v10 (vector extension) even supposed to be used?
• klibc does not really support the FPU anyway
• the half of v10 that equals f10 just HAPPENS to be saved by
  glibc, but what if the upper half, that is outside of the FPU,
  is used?
• where *is* the s390x̲ ABI documented anyway? syscall(2) has the
  kernel side only

Building with -mno-vx does not seem to help, %f* are still in
the .s files generated by gcc.

So I assume klibc should save registers f8–15 on s390x but what
happened to f1/f3/f5/f7?

Thanks,
//mirabilos
-- 
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
   veni, vidi, fixi(t) ;-)

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

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 943425 klibc: [s390x] setjmp/longjmp do not save/restore all 
> registers in use
Bug #943425 [libklibc-dev] klibc: [s390x] SIGSEGV in mksh testcase funsub-2
Changed Bug title to 'klibc: [s390x] setjmp/longjmp do not save/restore all 
registers in use' from 'klibc: [s390x] SIGSEGV in mksh testcase funsub-2'.
> # because this affects a release architecture
> severity 943425 serious
Bug #943425 [libklibc-dev] klibc: [s390x] setjmp/longjmp do not save/restore 
all registers in use
Severity set to 'serious' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
943425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943425
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[Thorsten Glaser]

Package: libklibc-dev
Version: 2.0.8-6
Followup-For: Bug #943425
X-Debbugs-Cc: t...@debian.org

I am able to track this down on the porterbox zelenka.

$ apt-get source mksh
$ cd mksh-59c
$ mkdir -p build/klibc
$ cd build/klibc
$ cp /usr/lib/klibc/bin/mksh .
$ chmod +x mksh   # because the x attribute is removed if testsfail
$ gdb --args ./mksh -c 'x=q; e=1; x=${ echo a; typeset e=2; return 3; echo 
x$e;}; echo 3:y$x,$e,$?.'
(gdb) r
[...]
Program received signal SIGSEGV, Segmentation fault.
0x01007c32 in comsub (fn=14, cp=0x0, xp=) at 
../../eval.c:1611
warning: Source file is more recent than executable.
1611lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
(gdb) bt
#0  0x01007c32 in comsub (fn=14, cp=0x0, xp=) at 
../../eval.c:1611
#1  expand (ccp=ccp@entry=0x3fffdfe4768 "\001x\001=\016\\echo a ; \\typeset e=2 
; \\return 3 ; \\echo x$e ",
wp=wp@entry=0x3ffed48, f=f@entry=4128) at ../../eval.c:346
#2  0x0100a366 in evalstr (
cp=0x3fffdfe4768 "\001x\001=\016\\echo a ; \\typeset e=2 ; \\return 3 ; 
\\echo x$e ", f=f@entry=4128)
at ../../eval.c:173
#3  0x0100d082 in comexec (t=0x3fffdfe4888, tp=tp@entry=0x0, 
ap=0x3fffdfe45e8, flags=,
xerrok=) at ../../exec.c:640
#4  0x0100bf0a in execute (t=, flags=, 
xerrok=xerrok@entry=0x0)
at ../../exec.c:162
#5  0x0100c0a2 in execute (t=t@entry=0x3fffdfe4588, 
flags=flags@entry=0, xerrok=xerrok@entry=0x0)
at ../../exec.c:204
#6  0x0101e048 in shell (s=s@entry=0x3fffdfe3b68, level=level@entry=0) 
at ../../main.c:954
#7  0x01000e78 in main (argc=, argv=) at 
../../main.c:742
(gdb) print shf
$1 = (struct shf *) 0x0


The code in question (where it crashes) is thus:

   1584 } else if (fn == FUNSUB) {
   1585 int ofd1;
   1586 struct temp *tf = NULL;
   1587 
   1588 /*
   1589  * create a temporary file, open for reading and 
writing,
   1590  * with an shf open for reading (buffered) but yet 
unused
   1591  */
   1592 maketemp(ATEMP, TT_FUNSUB, );
   1593 if (!tf->shf) {
   1594 errorf(Tf_temp,
   1595 Tcreate, tf->tffn, cstrerror(errno));
   1596 }
   1597 /* extract shf from temporary file, unlink and free it 
*/
   1598 shf = tf->shf;
   1599 unlink(tf->tffn);
   1600 afree(tf, ATEMP);
   1601 /* save stdout and let it point to the tempfile */
   1602 ofd1 = savefd(1);
   1603 ksh_dup2(shf_fileno(shf), 1, false);
   1604 /*
   1605  * run tree, with output thrown into the tempfile,
   1606  * in a new function block
   1607  */
   1608 valsub(t, NULL);
   1609 subst_exstat = exstat & 0xFF;
   1610 /* rewind the tempfile and restore regular stdout */
   1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
   1612 restfd(1, ofd1);

The crash occurs in line 1611 because shf (a local variable) is nil.

The really interesting part, though, is in line 1608, a call to valsub():

   2093 /* helper function due to setjmp/longjmp woes */
   2094 static char *
   2095 valsub(struct op *t, Area *ap)
   2096 {
   2097 char * volatile cp = NULL;
   2098 struct tbl * volatile vp = NULL;
   2099 
   2100 newenv(E_FUNC);
   2101 newblock();
   2102 if (ap)
   2103 vp = local(TREPLY, false);
   2104 if (!kshsetjmp(e->jbuf))
   2105 execute(t, XXCOM | XERROK, NULL);
   2106 if (vp)
   2107 strdupx(cp, str_val(vp), ap);
   2108 quitenv(NULL);
   2109 
   2110 return (cp);
   2111 }

Let's look again at the invocation that caused the crash:

x=q; e=1; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo 
3:y$x,$e,$?.

This one does not crash:

x=q; e=1; x=${ echo a; typeset e=2; echo x$e;}; echo 2:y$x,$e,$?.

The difference here is that 'return' is used in the crash case,
which executes a kshlongjmp(), that is siglongjmp(); kshsetjmp(x)
is sigsetjmp(x,0), which klibc defines as:

 34 #define sigsetjmp(__env, __save) \
 35 ({ \
 36   struct __sigjmp_buf *__e = (__env); \
 37   sigprocmask(0, NULL, &__e->__sigs); \
 38   setjmp(__e->__jmpbuf); \
 39 })

This apparently has two problems:

- the __save argument is ignored, contrary to sigsetjmp docs:

   If, and only if, the savesigs argument provided to sigsetjmp() is  non-
   zero, the process's current signal mask is saved in env and will be re-
   stored if a siglongjmp() is later performed with this env.

- it appears as if the combination of sigsetjmp/siglongjmp does not restore
  all callee-saved variables 

Bug#959757: This is a regression

[Salvatore Bonaccorso]

Hi Peter,

On Sun, May 02, 2021 at 05:32:19PM +0200, Peter Leipold wrote:
> Hi, I'm the original reporter. FYI, the problem was fixed with one of the
> kernel updates on last summer. It's stable since then.

Thanks for reporting back!

Regards,
Salvatore

[bts-link] source package src:linux

[debian-bts-link]

#
# bts-link upstream status pull for source package src:linux
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#

user debian-bts-l...@lists.debian.org

# remote status report for #987598 (http://bugs.debian.org/987598)
# Bug title: linux-image-5.10.0-6-amd64: no longer accounting guest CPU time in 
/proc/stat
#  * http://bugzilla.kernel.org/show_bug.cgi?id=209831
#  * remote status changed: (?) -> NEW
usertags 987598 + status-NEW

# remote status report for #987598 (http://bugs.debian.org/987598)
# Bug title: linux-image-5.10.0-6-amd64: no longer accounting guest CPU time in 
/proc/stat
#  * http://bugzilla.kernel.org/show_bug.cgi?id=209831
#  * remote status changed: (?) -> NEW
usertags 987598 + status-NEW

thanks

Bug#964734: reopened / test with 5.12.0-11146-g8ca5297e7e3

[Bernhard Turmann]

Hallo Salvatore,

Am 02.05.21 um 15:00 schrieb Salvatore Bonaccorso:

Reopened until the resolution is clarified upstream.

Was there some further progress/clarification from upstream?
I just tested with 5.12.0-11146-g8ca5297e7e3 to no avail and reported 
the result upstream / asked for any update, if available.

Other than that, I am not much of any help here, I am afraid.

Regards
Berni

Bug#988005: linux: Debian installation fails in qemu-system-s390x due to missing virtio_blk module

[Valentin Vidic]

Source: linux
Version: 5.10.28-1
Severity: normal

Dear Maintainer,

Debian installer for bullseye fails to find any disks for installation
due to a missing module for virtio block device. Merge request for
including virtio_blk (and other standard scsi modules) is here:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/355

-- 
Valentin

Bug#928189: Bug#922666: confirmed bug report

[Antoine Beaupré]

On 2021-05-03 07:37:42, Salvatore Bonaccorso wrote:
> Control: found -1 5.10.24-1
>
> Hi Antoine,
>
> On Sun, May 02, 2021 at 08:22:07PM -0400, Antoine Beaupré wrote:
>> On 2021-05-01 07:59:01, Salvatore Bonaccorso wrote:
>> > Hi Antoine
>> >
>> > On Fri, Apr 30, 2021 at 07:34:04PM -0400, Antoine Beaupré wrote:
>> >> On 2021-04-30 21:04:29, Salvatore Bonaccorso wrote:
>> >> > Control: tags -1 + moreinfo
>> >> >
>> >> > Hi Tollef, Antoine,
>> >> >
>> >> > On Wed, Sep 11, 2019 at 08:20:22PM -0400, Antoine Beaupré wrote:
>> >> >> Control: forcemerge 922666 928189
>> >> >> Control: severity 922666 important
>> >> >> Control: tags 922666 +patch +confirmed
>> >> >> 
>> >> >> I also see a regression with touchpads and trackpoint on a Thinkpad 
>> >> >> E431
>> >> >> after upgrading from Debian stretch to buster. My research indicates
>> >> >> this is a kernel regression, as yet to be fixed.
>> >> >> 
>> >> >> This is the result of my research, as available online at:
>> >> >> 
>> >> >> https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep
>> >> >> 
>> >> >> On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
>> >> >> freezes after sleep. Keyboard still works but not mouse until a
>> >> >> reboot.
>> >> >> 
>> >> >> There's [bug 922666][] in Debian buster, without a fix. It also says
>> >> >> it eventually recovers, which is not our experience. Possible dupe is
>> >> >> [bug 928189][].
>> >> >> 
>> >> >> [bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
>> >> >> [bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666
>> >> >> 
>> >> >> There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
>> >> >> which proposes the following workarounds:
>> >> >> 
>> >> >>  * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method 
>> >> >> disabled`
>> >> >> 
>> >> >>  * A .service file:
>> >> >> 
>> >> >> # /etc/systemd/system/touchpad-sleep.service
>> >> >> # restore touchpad on suspend
>> >> >> 
>> >> >> [Unit]
>> >> >> Description=Restore Touchpad on suspend
>> >> >> Before=sleep.target
>> >> >> StopWhenUnneeded=yes
>> >> >> 
>> >> >> [Service]
>> >> >> #Type=oneshot
>> >> >> Type=idle
>> >> >> RemainAfterExit=yes
>> >> >> ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/unbind'
>> >> >> ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
>> >> >> /sys/bus/pci/drivers/i801_smbus/bind'
>> >> >> 
>> >> >> [Install]
>> >> >> WantedBy=sleep.target
>> >> >> 
>> >> >>  * "Maybe try xserver-xorg-input-evdev instead of 
>> >> >> xserver-xorg-input-libinput?"
>> >> >> 
>> >> >>  * reloading `psmouse`:
>> >> >>  
>> >> >> sudo modprobe -r psmouse
>> >> >> sudo modprobe psmouse
>> >> >> 
>> >> >>  * "`modprobe i2c-i801` after removing it from the `blacklist.conf` 
>> >> >> seems to solve the issue."
>> >> >> 
>> >> >>  * whatever this is:
>> >> >>  
>> >> >> # echo 1 > /sys/devices/rmi4-00/nosleep
>> >> >> 
>> >> >>  * "Anyone who still affected by touchpad issues after S3. Please
>> >> >>switch back to suspend-to-idle in BIOS if s2idle is
>> >> >>supported. ThinkPad Carbon 6th and Yoga 3rd do support
>> >> >>suspend-to-idle in BIOS->config->power menu."
>> >> >> 
>> >> >> [bug 1791427]: 
>> >> >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427
>> >> >> 
>> >> >> There's also [bug 1442699][] in Fedora, which suggests those
>> >> >> workarounds:
>> >> >> 
>> >> >>  * another module reload:
>> >> >>  
>> >> >> sudo rmmod i2c_hid
>> >> >> sudo modprobe i2c_hid
>> >> >> 
>> >> >>  * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
>> >> >>and this issue seems to have been resolved (for me)."
>> >> >> 
>> >> >>  * another `/proc` hack:
>> >> >>  
>> >> >> echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl
>> >> >> 
>> >> >>  * "The `psmouse.synaptics_intertouch=0` workaround still works for 
>> >> >> me."
>> >> >> 
>> >> >> [bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699
>> >> >> 
>> >> >> Also related is this [libinput bug][] that's closed as "not our bug"
>> >> >> because they claim it's a bug in the kernel.
>> >> >> 
>> >> >> [libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149
>> >> >> 
>> >> >> There are [two][] [patches][] on the Linux kernel which apparently fix 
>> >> >> the
>> >> >> issue, still pending approval:
>> >> >> 
>> >> >> [two]: https://lkml.org/lkml/2019/2/20/700
>> >> >> [patches]: https://lkml.org/lkml/2019/2/20/701
>> >> >> 
>> >> >> Possibly related: https://lkml.org/lkml/2016/8/18/134
>> >> >> 
>> >> >> [5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
>> >> >> [pull request][] has been merged in mainline with two other fixes on
>> >> >> the module./ [5.0.11][] also has fixes on the module. It's clearly a
>> >> >> 

Bug#866314: linux-image-4.9.0-3-686-pae: 100+ times slower disk writes on 4.x+/i386/16+RAM, compared to 3.x

[Holger Levsen]

Hi Salvatore,

On Sun, May 02, 2021 at 11:39:05AM +0200, Salvatore Bonaccorso wrote:
> Doing some maintenance on open bugs for src:linux to bring unnecessary
> still open bugs down, this one appeared as well on the radar of older
> bugs for older kernels.
> 
> Do you still want to keep this bug open for some reason, or should we
> close it? I'm fine either way, but here I wanted to ask epxlicitly, as
> there was still some movements up to february 2020 in the referenced
> upstream report.
> 
> I just wonder if it will be worth off, but maybe yes.

I suppose it might be time to reduce memory on our i386 nodes to 15gb and
see how that goes. We're still seeing our i386 nodes hanging basically
every other day and I hope reducing memory will fix that.

I suppose it would be nice to keep this bug open but I don't care that much
either way. I understand i386 with lots of memory is super uncommon.

cc:ing Mattia for his opinion on this.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#926539: marked as done (rootskel: steal-ctty no longer works on at least sparc64)

[Debian Bug Tracking System]

Your message dated Mon, 3 May 2021 12:47:03 +0200
with message-id <82898247-7c4c-2e2c-358a-5724ce5fc...@physik.fu-berlin.de>
and subject line Re: Bug#926539: Bug#987441: s390x installation bugs
has caused the Debian Bug report #926539,
regarding rootskel: steal-ctty no longer works on at least sparc64
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
926539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: rootskel
Version: 1.128
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

I built updated installation images [1] for Debian Ports today and tested
the sparc64 image on our SPARC T5 in an LDOM.

Unfortunately, it seems that the recent changes to rootskel broke the
serial console on sparc64 in d-i. The kernel boots fine but d-i never
starts, the boot stops with:

steal-ctty: No such file or directory

My suspicion is that the support multiple consoles in parallel [2] introduced
this particular regression. I haven't done any debugging yet though as I'm
not sure where to start, I haven't touched the rootskel package before and
therefore would be interested in any pointers how to debug this.

Thanks,
Adrian

> [1] https://cdimage.debian.org/cdimage/ports/2019-04-06/
> [2] 
> https://salsa.debian.org/installer-team/rootskel/commit/b6048aafed7d73ba42da04d6f7a798710f271384

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- End Message ---
--- Begin Message ---
Hi!

On 5/3/21 12:21 PM, Valentin Vidic wrote:
>>> I'd suggest at least retitling the bug report to mention s390x (release
>>> arch, affected) instead of sparc64 (port arch, no longer affected), to
>>> lower the chances people could overlook this issue, thinking it's only
>>> about a port arch.
>>
>> We could also unmerge #926539 and #961056 again, then close the former bug
>> which was sparc64-specific.
> 
> I have unmerged the bugs now, so the sparc one can be closed.

Alright, done.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913--- End Message ---

Bug#961056: Bug#926539: Bug#987441: s390x installation bugs

[John Paul Adrian Glaubitz]

Hi!

On 5/3/21 12:21 PM, Valentin Vidic wrote:
>>> I'd suggest at least retitling the bug report to mention s390x (release
>>> arch, affected) instead of sparc64 (port arch, no longer affected), to
>>> lower the chances people could overlook this issue, thinking it's only
>>> about a port arch.
>>
>> We could also unmerge #926539 and #961056 again, then close the former bug
>> which was sparc64-specific.
> 
> I have unmerged the bugs now, so the sparc one can be closed.

Alright, done.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#796882: marked as done (hyperv-daemons: include debian specific versions of hv_get* scripts)

[Debian Bug Tracking System]

Your message dated Mon, 3 May 2021 12:21:14 +0200
with message-id <20210503102114.gb11...@lorien.valinor.li>
and subject line Re: Bug#796882: hyperv-daemons: include debian specific 
versions of hv_get* scripts
has caused the Debian Bug report #796882,
regarding hyperv-daemons: include debian specific versions of hv_get* scripts
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
796882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796882
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hyperv-daemons
Version: 4.1.4-2~bpo8+1
Severity: normal

hv_kvp_daemon gives the following errors:

hv_kvp_daemon[941]: sh: 1: hv_get_dns_info: not found
hv_kvp_daemon[941]: sh: 1: hv_get_dhcp_info: not found
hv_kvp_daemon[941]: sh: 1: hv_get_dns_info: not found
hv_kvp_daemon[941]: sh: 1: hv_get_dhcp_info: not found

These scripts are missing from the package. 
Debian should include there own disto specific versions of this scripts.

Examples are in the linux-tools source in the directory tools/hv/

Yours
Christoph

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages hyperv-daemons depends on:
ii  init-system-helpers  1.22
ii  libc62.19-18

hyperv-daemons recommends no packages.

hyperv-daemons suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 4.5.1-1

On Mon, May 03, 2021 at 11:27:45AM +0200, Christoph Martin wrote:
> I don't see the reported error messages in Stretch and Buster.
> I think the issue is resolve.

Thanks, doing so now.

Regards,
Salvatore--- End Message ---

Processed: Re: Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 795991 + wontfix
Bug #795991 [src:linux] linux-image-3.16.0-4-amd64: duplicate request cache is 
too small for NFS 4.1 servers
Added tag(s) wontfix.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
795991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795991
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#795991: marked as done (linux-image-3.16.0-4-amd64: duplicate request cache is too small for NFS 4.1 servers)

[Debian Bug Tracking System]

Your message dated Mon, 3 May 2021 12:20:16 +0200
with message-id <20210503102016.ga11...@lorien.valinor.li>
and subject line Re: Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate 
request cache is too small for NFS 4.1 servers
has caused the Debian Bug report #795991,
regarding linux-image-3.16.0-4-amd64: duplicate request cache is too small for 
NFS 4.1 servers
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795991
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 3.16.7-ckt11-1+deb8u3~bpo70+1
Severity: normal
File: /boot/vmlinuz-3.16.0-0.bpo.4-amd64

The drc (duplicate request cache) for NFS 4.1 in the vanilla kernel
has a fixed size only depending on the RAM of the machine.

For example, when setting up a vm which should only serve as a
nfs referral server with 768 MB RAM it could only server about
20 clients. So it is roughly 32 clients per GB.

The problem is, that in nfssvc.c the size of drc is calculated with
a shift of NFSD_DRC_SIZE_SHIFT bits from the RAM size.

I attach a patch for this which I also sent to linux-nfs.
(See http://www.spinics.net/lists/linux-nfs/msg51791.html)

It implements a module variable to set the size on module load.

It hope that such a patch can make it into Debian soon.

Yours
Christoph


-- System Information:
Debian Release: 7.8
  APT prefers oldstable-updates
  APT policy: (700, 'oldstable-updates'), (700, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.7-ckt9 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-3.16.0-0.bpo.4-amd64 depends on:
ii  debconf [debconf-2.0]  1.5.49
ii  initramfs-tools0.115~bpo70+1
ii  kmod   9-3
ii  linux-base 3.5
ii  module-init-tools  9-3

Versions of packages linux-image-3.16.0-0.bpo.4-amd64 recommends:
ii  firmware-linux-free  3.2
ii  irqbalance   1.0.3-3

Versions of packages linux-image-3.16.0-0.bpo.4-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 1.99-27+deb7u2
pn  linux-doc-3.16  

Versions of packages linux-image-3.16.0-0.bpo.4-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
pn  firmware-iwlwifi
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
pn  firmware-ralink 
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  
linux-image-3.16.0-0.bpo.4-amd64/postinst/depmod-error-initrd-3.16.0-0.bpo.4-amd64:
 false
  linux-image-3.16.0-0.bpo.4-amd64/postinst/mips-initrd-3.16.0-0.bpo.4-amd64:
  
linux-image-3.16.0-0.bpo.4-amd64/prerm/removing-running-kernel-3.16.0-0.bpo.4-amd64:
 true
--- linux-source-3.16/fs/nfsd/nfssvc.c	2015-03-30 12:09:09.0 +0200
+++ linux-source-3.16.nfsd/fs/nfsd/nfssvc.c	2015-06-17 09:28:37.880443867 +0200
@@ -359,11 +359,19 @@ void nfsd_reset_versions(void)
  * For now this is a #defined shift which could be under admin control
  * in the future.
  */
+
+static ulong drc_size = 0;
+module_param(drc_size, ulong, 0444);
+MODULE_PARM_DESC(drc_size,
+		 "size of NFSv4.1 DRC cache memory (default and minimum: free_buffer_size >> 10)");
+
 static void set_max_drc(void)
 {
 	#define NFSD_DRC_SIZE_SHIFT	10
-	nfsd_drc_max_mem = (nr_free_buffer_pages()
-	>> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE;
+	nfsd_drc_max_mem = max(drc_size,
+			   (nr_free_buffer_pages()
+>> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE);
+	drc_size = nfsd_drc_max_mem;
 	nfsd_drc_mem_used = 0;
 	spin_lock_init(_drc_lock);
 	dprintk("%s nfsd_drc_max_mem %lu \n", __func__, nfsd_drc_max_mem);
--- End Message ---
--- Begin Message ---
tags 795991 + wontfix
thanks

Hi Christoph,

On Mon, May 03, 2021 at 11:46:30AM +0200, Christoph Martin wrote:
> Hi Salvatore
> 
> Am 01.05.21 um 07:55 schrieb Salvatore Bonaccorso:
> > 
> > Ack thans for confirming. So either someone tries to bring that issue
> > again to upstream or alternatively we could then close this bug
> > marking (and possibly marking it wontfix).
> > 
> 
> I'm fine with closing and marking wontfix because upstream does so also.

Okay thanks a lot for confirming. I will do now so then.

Sorry :(

Regards,
Salvatore--- End Message ---

Bug#926539: Bug#987441: s390x installation bugs

[Valentin Vidic]

On Mon, May 03, 2021 at 08:58:02AM +0200, John Paul Adrian Glaubitz wrote:
> > The same issue exists on s390x but isn't apparently going to get fixed
> > so we need to have d-i be smarter (hence the merge request)?
> 
> Seems so.

QEMU console might get fixed in the kernel, but it looks like LPAR could
have a similar problem (don't have access to test this). So it seems
better (and future proof) to fix this on the Debian side too. I have
updated the merge request to trigger the new code only on s390x as
suggested:

https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2

> > I'd suggest at least retitling the bug report to mention s390x (release
> > arch, affected) instead of sparc64 (port arch, no longer affected), to
> > lower the chances people could overlook this issue, thinking it's only
> > about a port arch.
> 
> We could also unmerge #926539 and #961056 again, then close the former bug
> which was sparc64-specific.

I have unmerged the bugs now, so the sparc one can be closed.

-- 
Valentin

Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Christoph Martin]

Hi Salvatore

Am 01.05.21 um 07:55 schrieb Salvatore Bonaccorso:
> 
> Ack thans for confirming. So either someone tries to bring that issue
> again to upstream or alternatively we could then close this bug
> marking (and possibly marking it wontfix).
> 

I'm fine with closing and marking wontfix because upstream does so also.

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#796882: hyperv-daemons: include debian specific versions of hv_get* scripts

[Christoph Martin]

I don't see the reported error messages in Stretch and Buster.
I think the issue is resolve.

Am 30.04.21 um 14:36 schrieb Salvatore Bonaccorso:
> 
> This should have been resolved in 4.5.1-1, when we got own init and
> systemd service units, is this correct?
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Christoph Martin]

Sorry, please ignore this message. Wrong Bug report.

Am 03.05.21 um 11:25 schrieb Christoph Martin:
> Hi Salvator,
> 
>>
>> is this problem still relevant?
>>
> 
> I don't see the reported error messages in Stretch and Buster.
> I think the issue is resolve.
> 
> Christoph
> 



OpenPGP_signature
Description: OpenPGP digital signature

Bug#795991: /boot/vmlinuz-3.16.0-0.bpo.4-amd64: duplicate request cache is too small for NFS 4.1 servers

[Christoph Martin]

Hi Salvator,

> 
> is this problem still relevant?
> 

I don't see the reported error messages in Stretch and Buster.
I think the issue is resolve.

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Processed: unmerging 961056

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unmerge 961056
Bug #961056 [src:linux,rootskel] debian-installer: qemu-system-s390x 
installation fails due to incorrect serial device
Bug #926539 [src:linux,rootskel] rootskel: steal-ctty no longer works on at 
least sparc64
Disconnected #961056 from all other report(s).
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
926539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
961056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961056
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#926539: Bug#987441: s390x installation bugs

[John Paul Adrian Glaubitz]

Hi!

On 5/3/21 8:36 AM, Cyril Brulebois wrote:
> From skimming through the bug log, it seems it was initially a sparc64
> problem, that was fixed in the kernel (inconsistent naming) eventually.

Correct.

> The same issue exists on s390x but isn't apparently going to get fixed
> so we need to have d-i be smarter (hence the merge request)?

Seems so.

> I'd suggest at least retitling the bug report to mention s390x (release
> arch, affected) instead of sparc64 (port arch, no longer affected), to
> lower the chances people could overlook this issue, thinking it's only
> about a port arch.

We could also unmerge #926539 and #961056 again, then close the former bug
which was sparc64-specific.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#926539: Bug#987441: s390x installation bugs

[Cyril Brulebois]

Control: block 987441 by 926539
Control: block 987441 by 987788

Hi Valentin,

Thanks for your suggestions.

Valentin Vidic  (2021-05-02):
> Probably not critical, but maybe these installation bugs on s390x
> could be fixed for the release?
> 
> rootskel: steal-ctty no longer works on at least sparc64
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539

From skimming through the bug log, it seems it was initially a sparc64
problem, that was fixed in the kernel (inconsistent naming) eventually.
The same issue exists on s390x but isn't apparently going to get fixed
so we need to have d-i be smarter (hence the merge request)?

I'd suggest at least retitling the bug report to mention s390x (release
arch, affected) instead of sparc64 (port arch, no longer affected), to
lower the chances people could overlook this issue, thinking it's only
about a port arch.

I know it's been around for a while, but trying to get that merged right
now doesn't feeel right; trying to make the change only kick in on s390x
(in an attempt to fix s390x while not risking regressing elsewhere)
might eat up some time (lots of conditionals there), but it would feel a
little safer.

Would it make sense to have two for loops (one version “after” for s390x
only, and one version “before” for all archs) as a temporary measure for
bullseye? We could then switch all archs to the “after” version at the
beginning of the bookworm release cycle and deal with possible
regressions then?

In any cases, I'm happy to keep an eye on #926539 via #987441, even if
we don't block the release on it.

> debian-installer: qemu-system-s390x installation fails due to segfault in 
> main-menu
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987788

Yes, it seems works keeping an eye on. I had asked on tips on how to
test s390x but haven't had a chance to follow up on this yet.

Also adding to the list of bugs to keep an eye on (again, possibly not
blocking the release on its being resolved; we could have the issue
listed in errata, and possibly fixed in a point release).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: Re: Bug#987441: s390x installation bugs

[Debian Bug Tracking System]

Processing control commands:

> block 987441 by 926539
Bug #987441 [src:debian-installer] debian-installer: D-I must get ready for 
Bullseye
987441 was blocked by: 987587 987377 987568 987449 987368
987441 was not blocking any bugs.
Added blocking bug(s) of 987441: 926539 and 961056
> block 987441 by 987788
Bug #987441 [src:debian-installer] debian-installer: D-I must get ready for 
Bullseye
987441 was blocked by: 987449 987568 961056 987377 987368 987587 926539
987441 was not blocking any bugs.
Added blocking bug(s) of 987441: 987788

-- 
926539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
987441: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987441
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems