Processed: fixed 925908 in 4.19.67-1
Processing commands for cont...@bugs.debian.org:
> fixed 925908 4.19.67-1
Bug #925908 {Done: Ivo De Decker } [src:linux]
"drm/i915/fbdev: Actually configure untiled displays" breaks xserver
Marked as fixed in versions linux/4.19.67-1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
925908: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925908
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#925908: marked as done ("drm/i915/fbdev: Actually configure untiled displays" breaks xserver)
Your message dated Sat, 28 Mar 2020 19:54:06 +0100
with message-id <20200328185404.ga1...@debian.org>
and subject line Re: buster fails to boot as far as lightdm greeter on N3050
has caused the Debian Bug report #925908,
regarding "drm/i915/fbdev: Actually configure untiled displays" breaks xserver
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.)
--
925908: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925908
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 4.19.28-2
Severity: important
Tags: upstream
Dear Maintainer,
after booting, nothing happens after the line
[ OK ] Started Session 1 of user kalle.
I could wait forever, only when hitting Ctrl-Alt-F1, I get an unlock screen,
and after unlocking, my Gnome desktop appears.
The syslog shows an error message which isn't there normally:
Mar 28 08:59:26 Travelmate /usr/lib/gdm3/gdm-x-session[612]: (EE) modeset(0):
failed to set mode: Invalid argument
I was confronted with this for the first time some weeks ago when installed
kernel 4.20.13 from kernel.org, which was the first version with commit
d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 ("drm/i915/fbdev: Actually configure
untiled displays").
According to other users, this commit is the reason for the modeset error, but
according to Maarten Lankhorst, it is a bug in x.org's modesetting driver.
Please see the following bug reports:
https://bbs.archlinux.org/viewtopic.php?id=244624
https://bugs.freedesktop.org/show_bug.cgi?id=109806
https://gitlab.freedesktop.org/xorg/xserver/issues/542#login-pane
I'm using Debian testing and decided to stick with Debian testing's kernels
until there is a fix for X.
Just now, I did my usual "sudo apt-get update && sudo apt-get dist-upgrade",
and now I have kernel 4.19.28 and the issue is back again. Looking through the
changelogs, I found that the problematic commit was made in 4.19.26.
-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64
root=UUID=8d9bb90c-21f4-4c6c-b8cd-08bc31016efc ro
** Not tainted
** Kernel log:
[ 11.899100] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0
(0x0/0x0/0x0/0x0/0x0)
[ 11.901029] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1
(0x21/0x0/0x0/0x0/0x0)
[ 11.902948] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[ 11.904820] snd_hda_codec_realtek hdaudioC0D0:inputs:
[ 11.910819] snd_hda_codec_realtek hdaudioC0D0: Mic=0x12
[ 11.941812] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC
7265, REV=0x210
[ 11.970891] iTCO_vendor_support: vendor-support=0
[ 11.974263] acer_wmi: Acer Laptop ACPI-WMI Extras
[ 11.977164] acer_wmi: Function bitmap for Communication Button: 0x1
[ 11.986289] iwlwifi :02:00.0: base HW address: c8:21:58:65:5d:92
[ 11.988412] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 11.990483] iTCO_wdt: Found a Braswell SoC TCO device (Version=3,
TCOBASE=0x0460)
[ 11.991653] input: SYNA7DA1:00 06CB:7DA2 Mouse as
/devices/pci:00/808622C1:00/i2c-0/i2c-SYNA7DA1:00/0018:06CB:7DA2.0001/input/input8
[ 12.005002] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 12.017780] input: SYNA7DA1:00 06CB:7DA2 Touchpad as
/devices/pci:00/808622C1:00/i2c-0/i2c-SYNA7DA1:00/0018:06CB:7DA2.0001/input/input9
[ 12.021309] input: Acer WMI hotkeys as /devices/virtual/input/input11
[ 12.025314] hid-generic 0018:06CB:7DA2.0001: input,hidraw0: I2C HID v1.00
Mouse [SYNA7DA1:00 06CB:7DA2] on i2c-SYNA7DA1:00
[ 12.093143] intel_rapl: Found RAPL domain package
[ 12.093146] intel_rapl: Found RAPL domain core
[ 12.106809] input: HDA Digital PCBeep as
/devices/pci:00/:00:1b.0/sound/card0/input7
[ 12.135934] input: SYNA7DA1:00 06CB:7DA2 Touchpad as
/devices/pci:00/808622C1:00/i2c-0/i2c-SYNA7DA1:00/0018:06CB:7DA2.0001/input/input15
[ 12.137149] hid-multitouch 0018:06CB:7DA2.0001: input,hidraw0: I2C HID v1.00
Mouse [SYNA7DA1:00 06CB:7DA2] on i2c-SYNA7DA1:00
[ 12.138686] input: HDA Intel PCH Front Headphone as
/devices/pci:00/:00:1b.0/sound/card0/input12
[ 12.138945] usb 1-3: new high-speed USB device number 2 using xhci_hcd
[ 12.145441] input: HDA Intel PCH HDMI/DP,pcm=3 as
/devices/pci:00/:00:1b.0/sound/card0/input13
[ 12.174655] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[ 12.175142] thermal thermal_zone6: failed to read out thermal zone (-61)
[ 12.187784] iwlwifi
Processed: Re: Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Processing control commands:
> reopen -1
Bug #926539 {Done: John Paul Adrian Glaubitz }
[src:linux,rootskel] rootskel: steal-ctty no longer works on at least sparc64
Bug reopened
Ignoring request to alter fixed versions of bug #926539 to the same values
previously set
--
926539: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926539
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#926539: rootskel: steal-ctty no longer works on at least sparc64
Control: reopen -1 On 3/28/20 6:16 PM, John Paul Adrian Glaubitz wrote: > On 3/28/20 5:39 PM, Ivo De Decker wrote: >> 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. > > I fixed the bug upstream [1], so we can safely close the issue here. Ah, I just realized this bug also affected s390x. Sorry, I will reopen it. 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: marked as done (rootskel: steal-ctty no longer works on at least sparc64)
Your message dated Sat, 28 Mar 2020 18:16:42 +0100 with message-id <244c123a-be6d-6dff-383d-1560cdfd0...@physik.fu-berlin.de> and subject line Re: Bug#926539: rootskel: steal-ctty no longer works on at least sparc64 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 3/28/20 5:39 PM, Ivo De Decker wrote: > 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. I fixed the bug upstream [1], so we can safely close the issue here. Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07a6d63eb1b54b5fb38092780fe618dfe1d96e23 -- .''`. 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#955232: Please add 9p kernel module to the cloud image.
Package: linux-image-cloud-amd64 Severity: wishlist Please consider adding kernel module '9p' to the cloud image. It is impossible to passthrough filesystem from hypervisor with the current cloud image and there are no additional packages to install it. The only way that I know to passthrough filesystem currently is to remove linux-image-cloud-amd64 and install linux-image-amd64. - Albert Akchurin -- System Information: Debian Release: 10 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-cloud-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-cloud-amd64 depends on: pn linux-image-4.19.0-8-cloud-amd64 linux-image-cloud-amd64 recommends no packages. linux-image-cloud-amd64 suggests no packages.
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
Bug#949369: i915: kernel crash in i915_active_acquire()
FYI My bug report https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1868551 I ported the patch https://launchpadlibrarian.net/470860672/ubuntu-focal-1868551-i915_active_acquire.patch Official Issue #827 https://gitlab.freedesktop.org/drm/intel/issues/827 Good article on the subject https://linuxreviews.org/Linux_Kernel_5.5_Will_Not_Fix_The_Frequent_Intel_GPU_Hangs_In_Recent_Kernels Best Regards, Guy Baconniere
Bug#953569:
Thanks! Looks good to me. I appreciate that you were able to reconstruct the original upstream commits for each of these. (WireGuard has a capital G btw.)
