Bug#962485: Please revert CONFIG_MIPS_O32_FP64_SUPPORT change mipsel
Hi, On Mon, Jun 08, 2020 at 08:15:38PM +0300, Adrian Bunk wrote: > On Fri, May 29, 2020 at 11:03:14PM +0200, Aurelien Jarno wrote: > > On 2020-05-28 09:04, YunQiang Su wrote: > > > Adrian Bunk 于2020年5月21日周四 下午3:40写道： > > > > On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote: > > > > > Adrian Bunk 于2020年5月21日周四 上午4:44写道： > > > > > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote: > > > > > > > > > > > > > > FTR, after giving back golang-1.14 mipsel several times, it's > > > > > > > finally > > > > > > > built, by a longson builder. > > > > > > > So I guess it only occurs on octeon. Since the porterbox eller is > > > > > > > also > > > > > > > octeon, it also can't build any go program. > > > > > > > > > > > > On eller golang-1.14 fails to build both in sid and buster chroots. > > > > > > > > > > > > golang-1.11 also fails to build in a buster chroot with floating > > > > > > point > > > > > > test errors. > > > > > > > > > > > > golang-1.14 gets unbroken by GOMIPS=softfloat. > > > > > > > > > > > > The only kernel configuration change on eller in the buster point > > > > > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would > > > > > > make sense if the problem is that golang-1.11 and golang-1.14 are > > > > > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT. > > > > > > > > > > It is just support O32_FP64. I don't expect it will have any effect. > > > > > Since currently, the toolchain/libraries are all FPXX. > > > > > > > > Only the gcc/binutils toolchain/libraries or also the Go toolchain? > > > > > > you are right. the current golang still output FP32 object... > > > So, we think that it is buggy. > > > > > > Since Loongson CPU has some strange behaviour, it even can work... > > > Let's try to patch golang to support FPXX or FP64. > > > > > > https://github.com/golang/go/issues/39289 > > > > That's probably a solution for bullseye/sid, however we can't backport > > such changes and rebuild the go world in buster. I therefore think that > > for buster the kernel change has to be reverted. > > What is clear at this point is that the kernel change should be reverted > in buster since it causes a regression (including build failures on > buildds). I am cloning this bug for a revert in the kernel of > https://salsa.debian.org/kernel-team/linux/-/commit/947fbc66183d022fe3de7871dfb262d2b87af826 > > I am marking the version in bullseye as found since we might run into > the same problem again when buster DSAs will be built on machines > running the bullseye kernel after the release of bullseye. It might be > possible to mitigate this problem (e.g. in the kernel or by keeping some > buildd running with the buster kernel), but without an open bug this > issue might get forgotten and then resurface after the bullseye release. Could the mips porters comment on this? Given that we're close to the release of bullseye, I'm not convinced it's a good idea to change this now. Cheers, Ivo
Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information
Control: severity -1 important Control: fixed -1 5.4.19-1 Control: retitle -1 linux-image-4.19.0-5-amd64: nouveau driver sometimes crashes Hi, Thanks for the clarification. On Mon, Mar 30, 2020 at 01:05:20PM +0200, Vincent Lefevre wrote: > On 2020-03-30 09:06:15 +0200, Ivo De Decker wrote: > > On Sun, Mar 29, 2020 at 09:43:42PM +0200, Vincent Lefevre wrote: > > > I don't think so, except the use of the nouveau driver, of course. > > > But there were no issues for years. I think that problems started > > > to occur after some kernel upgrade. Now, I haven't had any problem > > > since December, I think. > > > > Do you think the problem is gone with the kernel you are running now? > > I don't know. I don't use this machine often, except remotely > (via ssh). But problems with the nouveau driver were common > (and a crash could occur in the nouveau driver even when using > the machine remotely only), and I haven't seen any issue recently, > even the last few times I logged in physically. It seems the main issue you were seeing was (is?) that the nouveau driver wasn't always very stable. I suspect this wasn't limited to logout only. > > What version is that? > > linux-image-5.4.0-4-amd64 5.4.19-1 > > ypig:~> uname -a > Linux ypig 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux Ok, let's assume the issue is no longer present there. > > > > Also, I don't think this bug is really 'grave'. Even if private > > > > information remains on the screen, the user can see that, and > > > > take action to avoid it. > > > > > > Not if one logs out remotely. > > > > What do you mean by that? > > I sometimes log in physically, but go away without logging out first > (there are sometimes a good reason, e.g. if some computation program > hasn't finished yet and I had not started it in "screen"). I can > later log in via ssh and kill the X session. Oh. I assumed you were talking about a text console, but it seems you're talking about a graphical login. In any case, I don't think this qualifies as a grave bug, so I'm downgrading it. Cheers, Ivo
Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information
Hi, On Sun, Mar 29, 2020 at 09:43:42PM +0200, Vincent Lefevre wrote: > On 2020-03-29 19:10:30 +0200, Ivo De Decker wrote: > > On Fri, Jun 14, 2019 at 04:31:16PM +0200, Vincent Lefevre wrote: > > > When logging out, a part of the previous session is still visible. > > > This might be used to compromise the user's account or leak other > > > private information, depending on what was written on the screen. > > > > What do you mean exactly? Is the screen only erased partially, or not at > > all? > > It was partially erased. > > > Is there something specific about your setup that you think might be > > relevant > > here? > > I don't think so, except the use of the nouveau driver, of course. > But there were no issues for years. I think that problems started > to occur after some kernel upgrade. Now, I haven't had any problem > since December, I think. Do you think the problem is gone with the kernel you are running now? What version is that? > > Also, I don't think this bug is really 'grave'. Even if private information > > remains on the screen, the user can see that, and take action to avoid it. > > Not if one logs out remotely. What do you mean by that? Cheers, Ivo
Bug#930527: linux-image-4.19.0-5-amd64: when logging out, not the whole screen is erased, leaving private information
Hi, On Fri, Jun 14, 2019 at 04:31:16PM +0200, Vincent Lefevre wrote: > When logging out, a part of the previous session is still visible. > This might be used to compromise the user's account or leak other > private information, depending on what was written on the screen. What do you mean exactly? Is the screen only erased partially, or not at all? Is there something specific about your setup that you think might be relevant here? When I try logging in on the console, and then log out, my screen is erased completely. Also, I don't think this bug is really 'grave'. Even if private information remains on the screen, the user can see that, and take action to avoid it. Cheers, Ivo
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Hi,
On Wed, Jun 26, 2019 at 10:18:37PM +0100, James Clarke wrote:
> (Don't know if this is a blocker for the release, but it should at
> least be reviewed before we release IMO, hence the severity)
>
> On Sun, Apr 07, 2019 at 12:53:35AM +0100, Ben Hutchings wrote:
> > On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> > > On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > > > 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.
> > >
> > > The problem seems to be the fact that the sparc64 kernel uses different
> > > names
> > > for /proc/console and the actual console name:
> > >
> > > root@landau:~# cat /proc/consoles
> > > ttyHV0 -W- (EC p )4:64
> > > tty0 -WU (E )4:1
> > > root@landau:~# readlink /sys/dev/char/4:64
> > > ../../devices/root/f0299a70/f029b788/tty/ttyS0
> >
> > The inconsistent name seems like a kernel bug...
> >
> > > root@landau:~#
> > >
> > > And this is what used to make it work [1]:
> > >
> > > *) # >= 2.6.38
> > > console_major_minor="$(get-real-console-linux)"
> > > console_raw="$(readlink "/sys/dev/char/${console_major_minor}")"
> > > console="${console_raw##*/}"
> > > ;;
> >
> > So maybe rootskel should use that again, but applied to each console's
> > char device number.
> >
> > (Though directly using the symlinks under /dev/char seems cleaner than
> > poking in sysfs.)
>
> Just got a report in #debian-cd of a user running into this issue on
> s390x with Hercules; a subset of the messages sent in conversation are
> below:
>
> [20:12:18]steal-ctty: No such file or directory
> [20:12:29]will go hunt this down once i find time
> [20:12:52](DI buster RC2 / s390x)
> [21:52:40]gruetzkopf: cat /proc/consoles ?
> [21:54:00]should give something like:
> [21:54:00]ttyS0-W- (EC p )4:64
> [21:54:22]rootskel will prefer a console which has the C flag
> [21:55:17]now let's see how to get there
> [21:55:57](note: running in hercules, not real hw or qemu
> where i'd have virtio console)
> [22:01:39]cat /proc/consoles
> [22:01:40]ttyS0-W- (EC p )4:64
> [22:02:05]and ls -l /dev/ttyS0?
> [22:03:06]ls: /dev/ttyS0: No such file or directory
> [22:03:06]oh, fun!
> [22:04:36]and ls -l /sys/dev/char/4:64 ?
> [22:06:06]ls -l /sys/dev/char/4:64
> [22:06:06]lrwxrwxrwx1 root root 0 Jun
> 26 21:05 /sys/dev/char/4:64 -> .
> [22:06:06]./../devices/virtual/tty/sclp_line0
> [22:06:28]ok, so, it's not /dev/ttyS0, it's /dev/sclp_line0?
> [22:06:32](does that exist?)
> [22:06:48]we had an issue like this on sparc64 (#926539)
> [22:07:38]i just found that
> [22:07:53]does that device node exist for you?
> [22:08:13]crw--w1 root root4, 64 Jun
> 26 20:58 /dev/sclp_line0
> [22:08:43](and so does /dev/ttysclp0)
>
> This is the "fault" of drivers/s390/char/sclp_tty.c. I don't know what
> the best fix is; we could also patch the kernel to ensure this shows up
> as /dev/sclp_line0 in /proc/consoles like sparc64 now does for sunhv,
> but I worry now that this might be a game of whack-a-mole and there are
> other character device drivers out there that also suffer from this.
> Perhaps therefore we need to go back to looking up the device name from
> the device number as has been suggested already...
This bug wasn't fixed in time for buster. Is it still present in bullseye? If
so, it might be good to try to fix it this time.
Cheers,
Ivo
Re: Bits from the Release Team: ride like the wind, Bullseye!
Hi Ben, Sorry for not getting back to you about this earlier. On 7/7/19 3:43 PM, Ben Hutchings wrote: On Sun, 2019-07-07 at 02:47 +0100, Jonathan Wiltshire wrote: [...] No binary maintainer uploads for bullseye = The release of buster also means the bullseye release cycle is about to begin. From now on, we will no longer allow binaries uploaded by maintainers to migrate to testing. This means that you will need to do source-only uploads if you want them to reach bullseye. I support this move in principle, but: Q: I already did a binary upload, do I need to do a new (source-only) upload? A: Yes (preferably with other changes, not just a version bump). Q: I needed to do a binary upload because my upload went to the NEW queue, do I need to do a new (source-only) upload for it to reach bullseye? A: Yes. We also suggest going through NEW in experimental instead of unstable where possible, to avoid disruption in unstable. [...] This is not going to fly for src:linux. We can't stage ABI bumps in experimental as we typically have a different upstream versions in unstable and experimental. We even need to do ABI bumps in stable from time to time. We are aware that src:linux is a special case here. I added an exception for the arch:all binaries from src:linux. When the next ABI bump in unstable happens, feel free to let me know, so that I can check if it works as expected. Thanks, Ivo
Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
Hi Ben, On Sun, Feb 10, 2019 at 05:07:07PM +, Ben Hutchings wrote: > On Tue, 3 Jul 2018 18:51:49 -0700 Ryan Tandy wrote: > > Control: found -1 4.17.3-1 > > > > Hi, > > > > On Mon, Jul 02, 2018 at 08:42:45PM -0700, Ryan Tandy wrote: > > >However it looks like it might be resolved with the kernel in > > >unstable. I will run some more iterations and let you know. > > > > The issue still reproduces with stretch userland and the current > > unstable kernel. > > > > It cannot be reproduced with buster's glibc because lock elision was > > disabled in #878071, citing this issue. > > This bug has been open for over 18 months with no sign of a solution, > which is really not acceptable for a release architecture. I propose > to disable CONFIG_PPC_TRANSACTIONAL_MEMORY in both stretch and > unstable, until a fix is available for TM. We're getting pretty close to the release. Are you planning to disable CONFIG_PPC_TRANSACTIONAL_MEMORY for buster? Thanks, Ivo
Bug#903824: please build usb-serial-modules udeb on armhf and arm64
package: linux version: 4.16.16-2 severity: wishlist Hi, The usb-serial-modules udeb is available on a number of architectures. Please also build it on armhf and arm64. Thanks! Cheers, Ivo
Bug#862400: several bios updates exist since 2007
Hi, On Fri, May 19, 2017 at 01:58:31PM +0200, Arturo Borrero Gonzalez wrote: > We managed to upgrade the BIOS (not the last one, though). > > Still no luck, kernel 4.9 doesn't boot while 4.7 does. Does it work with 4.11 (available in experimental)? Cheers, Ivo
