Hi,
Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations")
seems to be breaking Hyper-V framebuffer
(drivers/video/fbdev/hyperv_fb.c) driver for me: Hyper-V guest boots
well and plymouth even works but when I try starting Gnome, virtual
screen just goes black. Reverting the above mentioned commit on top of
5.13-rc4 saves the day. The behavior is 100% reproducible. I'm using
Gen2 guest runing on Hyper-V 2019. It was also reported that Gen1 guests
are equally broken.
Is this something known?
--
Vitaly
From: Wei Liu <wei.liu@kernel.org> Date: 2021-06-04 13:00:20
On Fri, Jun 04, 2021 at 02:25:01PM +0200, Vitaly Kuznetsov wrote:
Hi,
Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations")
seems to be breaking Hyper-V framebuffer
(drivers/video/fbdev/hyperv_fb.c) driver for me: Hyper-V guest boots
well and plymouth even works but when I try starting Gnome, virtual
screen just goes black. Reverting the above mentioned commit on top of
5.13-rc4 saves the day. The behavior is 100% reproducible. I'm using
Gen2 guest runing on Hyper-V 2019. It was also reported that Gen1 guests
are equally broken.
Is this something known?
I've heard a similar report from Vineeth but we didn't get to the bottom
of this.
Wei.
On Fri, Jun 04, 2021 at 02:25:01PM +0200, Vitaly Kuznetsov wrote:
quoted
Hi,
Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations")
seems to be breaking Hyper-V framebuffer
(drivers/video/fbdev/hyperv_fb.c) driver for me: Hyper-V guest boots
well and plymouth even works but when I try starting Gnome, virtual
screen just goes black. Reverting the above mentioned commit on top of
5.13-rc4 saves the day. The behavior is 100% reproducible. I'm using
Gen2 guest runing on Hyper-V 2019. It was also reported that Gen1 guests
are equally broken.
Is this something known?
I've heard a similar report from Vineeth but we didn't get to the bottom
of this.
I have just tried reverting the commit mentioned above and it solves the
GUI freeze
I was also seeing. Previously, login screen was just freezing, but VM
was accessible
through ssh. With the above commit reverted, I can login to Gnome.
Looks like I am also experiencing the same bug mentioned here.
Thanks,
Vineeth
From: Dexuan Cui <decui@microsoft.com> Date: 2021-06-04 18:17:02
From: Vineeth Pillai <redacted>
Sent: Friday, June 4, 2021 8:47 AM
To: Wei Liu <wei.liu@kernel.org>; vkuznets <vkuznets@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>; dri-devel@lists.freedesktop.org;
linux-hyperv@vger.kernel.org; linux-fbdev@vger.kernel.org;
linux-kernel@vger.kernel.org; Michael Kelley [off-list ref];
Dexuan Cui [off-list ref]
Subject: Re: [bug report] Commit ccf953d8f3d6 ("fb_defio: Remove custom
address_space_operations") breaks Hyper-V FB driver
On 6/4/2021 9:00 AM, Wei Liu wrote:
quoted
On Fri, Jun 04, 2021 at 02:25:01PM +0200, Vitaly Kuznetsov wrote:
quoted
Hi,
Commit ccf953d8f3d6 ("fb_defio: Remove custom
address_space_operations")
quoted
quoted
seems to be breaking Hyper-V framebuffer
(drivers/video/fbdev/hyperv_fb.c) driver for me: Hyper-V guest boots
well and plymouth even works but when I try starting Gnome, virtual
screen just goes black. Reverting the above mentioned commit on top of
5.13-rc4 saves the day. The behavior is 100% reproducible. I'm using
Gen2 guest runing on Hyper-V 2019. It was also reported that Gen1 guests
are equally broken.
Is this something known?
I've heard a similar report from Vineeth but we didn't get to the bottom
of this.
I have just tried reverting the commit mentioned above and it solves the
GUI freeze
I was also seeing. Previously, login screen was just freezing, but VM
was accessible
through ssh. With the above commit reverted, I can login to Gnome.
Looks like I am also experiencing the same bug mentioned here.
Thanks,
Vineeth
From: Dexuan Cui <decui@microsoft.com> Date: 2021-06-04 18:37:58
From: Dexuan Cui
Sent: Friday, June 4, 2021 11:17 AM
quoted
quoted
quoted
...
I've heard a similar report from Vineeth but we didn't get to the bottom
of this.
I have just tried reverting the commit mentioned above and it solves the
GUI freeze
I was also seeing. Previously, login screen was just freezing, but VM
was accessible
through ssh. With the above commit reverted, I can login to Gnome.
Looks like I am also experiencing the same bug mentioned here.
Thanks,
Vineeth
From: Matthew Wilcox <willy@infradead.org> Date: 2021-06-04 18:53:21
On Fri, Jun 04, 2021 at 06:37:49PM +0000, Dexuan Cui wrote:
quoted
From: Dexuan Cui
Sent: Friday, June 4, 2021 11:17 AM
quoted
quoted
quoted
...
I've heard a similar report from Vineeth but we didn't get to the bottom
of this.
I have just tried reverting the commit mentioned above and it solves the
GUI freeze
I was also seeing. Previously, login screen was just freezing, but VM
was accessible
through ssh. With the above commit reverted, I can login to Gnome.
Looks like I am also experiencing the same bug mentioned here.
Thanks,
Vineeth
Hi Matthew,
With today's latest mainline 16f0596fc1d78a1f3ae4628cff962bb297dc908c,
the Xorg works again in Linux VM on Hyper-V, but when I reboot the VM, I
always see a lot of "BUG: Bad page state in process Xorg " warnings (there
are about 60 such warnings) before the VM reboots.
BTW, I happen to have an older Mar-28 mainline kernel (36a14638f7c0654),
which has the same warnings.
Any idea which change introduced the warnings?
Looks like someone forgot to call fb_deferred_io_cleanup()?