similar to: [REGRESSION]: acpi/nouveau: Hardware unavailable upon resume or suspend fails

Hi Owen, On Fri, Nov 10, 2023 at 5:55?AM Owen T. Heisler <writer at owenh.net> wrote: > > #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0 > #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273 > #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124 Thanks for the bug report. Do you prefer to continue the discussion here, on gitlab or

Hi All, On 11/10/23 07:09, Kai-Heng Feng wrote: > Hi Owen, > > On Fri, Nov 10, 2023 at 5:55?AM Owen T. Heisler <writer at owenh.net> wrote: >> >> #regzbot introduced: 89c290ea758911e660878e26270e084d862c03b0 >> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/273 >> #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=218124 >

Hi, On 11/10/23 17:58, Owen T. Heisler wrote: > Hi everyone, > > On 11/10/23 06:52, Kai-Heng Feng wrote: >> On Fri, Nov 10, 2023 at 2:19?PM Hans de Goede <hdegoede at redhat.com> wrote: >>> On 11/10/23 07:09, Kai-Heng Feng wrote: >>>> On Fri, Nov 10, 2023 at 5:55?AM Owen T. Heisler <writer at owenh.net> wrote: >>>>> #regzbot

Hi Thorsten and others, On 12/5/23 06:33, Thorsten Leemhuis wrote: > On 29.11.23 01:37, Owen T. Heisler wrote: >> On 11/21/23 14:23, Owen T. Heisler wrote: >>> On 11/21/23 09:16, Linux regression tracking (Thorsten Leemhuis) wrote: >>>> On 15.11.23 07:19, Owen T. Heisler wrote: >>>>> On 10/31/23 04:18, Linux regression tracking (Thorsten Leemhuis)

[adding various lists and the two other nouveau maintainers to the list of recipients] For the rest of this mail: [TLDR: I'm adding this report to the list of tracked Linux kernel regressions; the text you find below is based on a few templates paragraphs you might have encountered already in similar form. See link in footer if these mails annoy you.] On 18.01.23 21:59, Chris Clayton wrote:

On Fri, Mar 10, 2023 at 10:26?AM Chris Clayton <chris2553 at googlemail.com> wrote: > > Hi. > > Is it likely that this fix will be sumbmitted to mainline during the ongoing 6.3 development cycle? > yes, it's already pushed to drm-misc-fixed, which then will go into the current devel cycle. I just don't know when it's the next time it will be pushed upwards, but it

On Mon, Feb 20, 2023 at 11:51 AM Chris Clayton <chris2553 at googlemail.com> wrote: > > > > On 20/02/2023 05:35, Ben Skeggs wrote: > > On Sun, 19 Feb 2023 at 04:55, Chris Clayton <chris2553 at googlemail.com> wrote: > >> > >> > >> > >> On 18/02/2023 15:19, Chris Clayton wrote: > >>> > >>> > >>> On

Hi All, Am I the only one that doesn't see the GlusterFS v6.6 ? It was released last week and I thought that it will be here in a day or 2 . Best Regards, Strahil Nikolov

https://bugs.freedesktop.org/show_bug.cgi?id=28524 Summary: Debian Testing Kernel Upgrade Enables KMS, Disables External Monitor Product: xorg Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Hi All, I've been running Gentoo on a ZBook with great success for a couple years, but I've been stymied in my attempts to implement SecureBoot by an apparent problem with efifb to nouveaufb handoff, but only when external monitors are attached. The handoff works without issue when the BIOS is in Mixed EFI mode, with and without external monitors, and works in Native EFI mode without

Hello, Commit 2541626cfb79 breaks GM20B probe with the following kernel log: [ 2.153892] ------------[ cut here ]------------ [ 2.153897] WARNING: CPU: 1 PID: 36 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 gf100_vmm_valid+0x2c4/0x390 [ 2.153916] Modules linked in: [ 2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1 [ 2.153929] Hardware name: Google

Hello, I find "discard":"unmap" is defaultly enabled in qemu cmdline(libvirt v6.6, qemu v5.1): XML: <disk type="file" device="disk"> <driver name="qemu" type="qcow2"/> <source file="/var/lib/libvirt/images/new.qcow2" index="2"/> <backingStore/> <target

On 09/22/2017 06:10 PM, Mark D. Baushke wrote: > I suppose you want to be more paranoid: > > DH * > dh_new_group_fallback(int max) > { > debug3("%s: requested max size %d", __func__, max); > if (max <= 2048) { > debug3("using 2k bit group 14"); > return dh_new_group14(); > }

[adding a bunch of list and people as well as Timur Tabi, who authored the culprit] Sid Pranjale, thx for the report. FWIW, I'm just replying to add this to the regression tracking to ensure it does not fall through the cracks. Nevertheless let me mention two things while at it: On 29.02.24 18:58, Sid Pranjale wrote: > Nouveau deallocates a few buffers post GPU init which are required for

On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton <chris2553 at googlemail.com> wrote: > > > > On 15/02/2023 11:09, Karol Herbst wrote: > > On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update > > (Thorsten Leemhuis) <regressions at leemhuis.info> wrote: > >> > >> On 13.02.23 10:14, Chris Clayton wrote: > >>> On 13/02/2023

On Sun, 19 Feb 2023 at 04:55, Chris Clayton <chris2553 at googlemail.com> wrote: > > > > On 18/02/2023 15:19, Chris Clayton wrote: > > > > > > On 18/02/2023 12:25, Karol Herbst wrote: > >> On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton <chris2553 at googlemail.com> wrote: > >>> > >>> > >>> > >>> On

On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote: > Finally! For a very long time, our MST helpers have had one very > annoying issue: They don't know how to reprobe the topology state when > coming out of suspend. This means that if a user has a machine connected > to an MST topology and decides to suspend their machine, we lose all > topology changes that happened

Hi Lv, I am trying to reduce the number of parallel discussion we have on the same subject, but there is something here I can't let you have. On Fri, May 12, 2017 at 8:08 AM, Zheng, Lv <lv.zheng at intel.com> wrote: > Hi, > > If my previous reply is not persuasive enough. > Let me do that in a different way. > >> From: linux-acpi-owner at vger.kernel.org

Hi, I'm using CentOS on a laptop that part of the time is connected to a docking station with two monitor connected to it. When the laptop lid is docked, its lid is closed, as the system is placed in a position where it's not convenient to keep it open, let alone look at the screen. Now in the past, with CentOS 5 (on a different laptop, but same physical config) and 6, the screen has

Does what it says on the tin. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland <hwentlan at amd.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Sean Paul <sean at poorly.run> Signed-off-by: Lyude Paul <lyude at redhat.com> ---