Original Summary: absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers produce vast raster right and bottom borders on the larger resolution of two displays To reproduce: 1-connect two unequal native resolution displays to a Tesla or Firmi GPU 2-don't have plymouth in use (I don't ever have it installed, so don't know whether it impacts) 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines 4-boot Tumbleweed or Fedora 38 5-switch to a vtty, e.g. Ctrl-Alt-F3 Actual behavior: 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display 2-Lower resolution display behaves as expected (light text on black background) 3-Higher resolution display uses same pixels as lower resolution display, with light text on black background, leaving right side and bottom raster instead of black Expected behavior: 1-Both displays utilize the resolution (same pixel grid) of the lower resolution display 2-Lower resolution display behaves as expected 3-Entire higher resolution display's background is black instead of portions in raster Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes both displays to use the same nominal mode on the full display space. Typical other linu line options: noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full mitigations=none My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 displays. My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 displays. Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with 6.2.15 on Fedora 38, and (partially with Tesla, right side only) with 6.2.12 and 6.3.3 on Mageia 9. Does not occur with 6.1.12 kernel-default on NVidia, or with AMD Caicos (Terascale2) GPU, or with Intel Eaglelake GPU. Tested only on legacy booting (no UEFI support). Others might describe what I call "raster" as multicolored snow.
(In reply to Felix Miata from comment #0) > Original Summary: > absent both plymouth, and video= on linu lines, vtty[1-6] framebuffers > produce vast raster right and bottom borders on the larger resolution of two > displays > > To reproduce: > 1-connect two unequal native resolution displays to a Tesla or Firmi GPU > 2-don't have plymouth in use (I don't ever have it installed, so don't know > whether it impacts) > 3-don't include e.g. video=1440x900@60 directive on Grub's linu lines > 4-boot Tumbleweed or Fedora 38 > 5-switch to a vtty, e.g. Ctrl-Alt-F3 > > Actual behavior: > 1-Both displays utilize the resolution (same pixel grid) of the lower > resolution display > 2-Lower resolution display behaves as expected (light text on black > background) > 3-Higher resolution display uses same pixels as lower resolution display, > with light text on black background, leaving right side and bottom raster > instead of black > > Expected behavior: > 1-Both displays utilize the resolution (same pixel grid) of the lower > resolution display > 2-Lower resolution display behaves as expected > 3-Entire higher resolution display's background is black instead of portions > in raster > > Workaround: add e.g. video=1440x900@60 to Grub's linu lines, which causes > both displays to use the same nominal mode on the full display space. > > Typical other linu line options: > noresume consoleblank=0 net.ifnames=0 ipv6.disable=1 preempt=full > mitigations=none > > My Tesla has HDMI and DVI outputs, tested with 1920x1200 and 1680x1050 > displays. > My Fermi has dual DisplayPort, tested with 2560x1440 and 1680x1050 displays. > Occurs Tumbleweed with 6.3.2 and 6.2.12 kernel-default, and with 6.2.15 on > Fedora 38, and (partially with Tesla, right side only) with 6.2.12 and 6.3.3 > on Mageia 9. > Does not occur with 6.1.12 kernel-default on NVidia, or with AMD Caicos > (Terascale2) GPU, or with Intel Eaglelake GPU. > Tested only on legacy booting (no UEFI support). > Others might describe what I call "raster" as multicolored snow. Can you show dmesg?
Created attachment 304317 [details] dmesg from openSUSE TW 6.3.2 kernel
Can you reproduce this bug on latest mainline (v6.4-rc3)?
Created attachment 304319 [details] dmesg from TW's 6.4-rc3 (In reply to Bagas Sanjaya from comment #3) > Can you reproduce this bug on latest mainline (v6.4-rc3)? Yes with http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/kernel-default-6.4~rc3-2.1.g0fce5ba.x86_64.rpm
On 5/25/23 18:12, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217479 > > --- Comment #4 from Felix Miata (mrmazda@earthlink.net) --- > Created attachment 304319 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=304319&action=edit > dmesg from TW's 6.4-rc3 > > (In reply to Bagas Sanjaya from comment #3) >> Can you reproduce this bug on latest mainline (v6.4-rc3)? > > Yes with > > http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/kernel-default-6.4~rc3-2.1.g0fce5ba.x86_64.rpm > Can you bisect between v6.1 and v6.2 to find the culprit? Hint: see Documentation/admin-guide/bug-bisect.rst.
(In reply to Bagas Sanjaya from comment #5) > Can you bisect between v6.1 and v6.2 to find the culprit? Hint: see > Documentation/admin-guide/bug-bisect.rst. I don't know how to use build service or compile from source, and am not interested in learning. I am willing to try kernel rpms anyone else is willing to provide for Tumbleweed, Fedora 38 or Mageia 9. Mageia 9's 6.1.14 also does not reproduce this on Tesla 10de:0a65. Following does not reproduce (same host & Fermi as comment #0): # uname -v #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) # (currently on the mirrors) # inxi -G -Sa System: Host: p5bse Kernel: 6.1.0-9-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: ro root=LABEL=<filter> ipv6.disable=1 net.ifnames=0 selinux=0 plymouth.enable=0 consoleblank=0 preempt=full mitigations=none Graphics: Device-1: NVIDIA GF119 [NVS 310] driver: nouveau v: kernel Display: server: X.org v: 1.21.1.7 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: nouveau gpu: nouveau resolution: 1: 2560x1440 2: 1680x1050 On the following, behavior is different: # grep tty .bashrc tty=$(tty); [ "$tty" != "${tty#/dev/tty[0-9]}" ] && setterm --background blue --foreground white --bold on --store # inxi -SG System: Host: p5bse Kernel: 6.2.12-desktop-1.mga9 arch: x86_64 bits: 64 Console: pty pts/0 Distro: Mageia 9 Graphics: Device-1: NVIDIA GF119 [NVS 310] driver: nouveau v: kernel Display: server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: modesetting unloaded: vesa dri: nouveau gpu: nouveau resolution: 1: 2560x1440 2: 1680x1050 # Initially on leaving Grub, the 2560x1440 display lights up using all available space for 80x25 text. Apparently when KMS initially engages, kernel switches to native 2560x1440 mode with 320x90 character space. Quickly thereafter, the 1680x1050 lights up with 210x65 characters as expected, but the 2560x1440 display's output becomes limited to the upper left 210x65 character space. Below that space, the last 3.5 white on blue rows from before the mode switch remain fixed in place. The rest of the bottom of the screen remains blue, and so does most of the right side, but not the top approximately 110x9 columns & rows, which are snow/raster. What's weird is I commented away the setterm line from .bashrc and rebooted to find no change in framebuffer behavior, still blue background on bottom and most of right, with snow/raster at top right. Without the setterm line in .bashrc, I'm at a loss to the source of blue background rather than black, unless it's a leftover from Grub's Gfxboot, or residue from Mageia's non-removable Plymouth entanglement. Since booting Mageia on p5bse today, booting Fedora matches the just described variation in behavior, blue background instead of raster in most of the unused screen space. Booting TW does a similar variation, substituting white for blue as background. Apparently this may be a distinction between the Fermi and the Tesla, as the Tesla today is sticking to snow/raster. Or, maybe it's because the kernel's choice of primary is the larger display on the Fermi, and the kernel's choice of primary is the smaller on the Tesla. A third host with a different Fermi 10de:0f00 is matching the Tesla's snow/raster in TW, Fedora & Mageia. Another variation appears on a fourth host with another different Tesla. Black background is everywhere in TW, Fedora & Mageia post-6.1.x, except for what looks like a 240x180 patch in upper right corner, which I finally recognized to be a mangled Grub gfxboot screen, 800x600 IIRC. I tried a couple of times appending nosimplefb=1, but it had no apparent effect. Note1: AFAIK, all my installations use the upstream default 16x8 framebuffer font. I don't alter /etc/vconsole.conf or equivalent. Note2: All my non-UEFI Linux booting, which includes all hosts with old NVidia GPUS, is done from openSUSE's (mostly v13.2 or older) no longer supported Grub Legacy 0.97 with gfxboot. Grub2 here is limited to UEFI environments using AMD APU or Intel IGP graphics.
On 5/26/23 05:25, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=217479 > > --- Comment #6 from Felix Miata (mrmazda@earthlink.net) --- > (In reply to Bagas Sanjaya from comment #5) >> Can you bisect between v6.1 and v6.2 to find the culprit? Hint: see >> Documentation/admin-guide/bug-bisect.rst. > > I don't know how to use build service or compile from source, and am not > interested in learning. I am willing to try kernel rpms anyone else is > willing > to provide for Tumbleweed, Fedora 38 or Mageia 9. > See Documentation/admin-guide/quickly-build-trimmed-linux.rst in kernel sources for how to build the kernel yourself. If lucky, someone else runs into your issue can bisect (on your behalf) or developers can take a look at the code and trying to figure out the culprit without bisection. But if neither happens, you have to bisect yourself. Bye!
Since you're using Nouveau driver, please also report this regression on Freedesktop Gitlab [1]. Thanks! [1]: https://gitlab.freedesktop.org/drm/nouveau/-/issues
Reproduces also with Fedora 38's 6.2.7 and Mageia 9's 6.2.7 on Fermi 10de:0f00 and Tesla 10de:0a65. Reproduces also with TW's 6.2.6, Fedora 36's 6.2.6 and Mageia 9's 6.2.6 on Fermi 10de:107d. All installations on these slow 2 core old multiboot hosts that these 4 GPUs are installed in are on root filesystems of 6.4G or less with little to no freespace available for adding build environment or other non-essential software, much less room for construction of kernel packages. At least I've narrowed the window to between 6.1.14 and 6.2.6.
I stumbled onto a TW with Intel GPU and a 6.2.4 kernel that hadn't been removed yet, so I got my spare Tesla 10de:0402 off the shelf into it, and reproduced the snow & raster, narrowing the regression window to between 6.1.14 and 6.2.4.
(In reply to Bagas Sanjaya from comment #8) > Since you're using Nouveau driver, please also report this regression on > Freedesktop Gitlab [1]. https://gitlab.freedesktop.org/drm/nouveau/-/issues/214
Upstream report updated. Bisect range narrowed to exclude all of 6.1.x, which in current Bookworm provides .deb 6.1.0-21 aka 6.1.90-1.