[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdWM5z-vKRwhCgJHjU-S_L0WR=avmDN-b8dN87b=rgi08w@mail.gmail.com>
Date: Wed, 24 Feb 2021 12:35:37 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Tong Zhang <ztong0001@...il.com>
Cc: Randy Dunlap <rdunlap@...radead.org>,
"Gustavo A. R. Silva" <gustavoars@...nel.org>,
Sam Ravnborg <sam@...nborg.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
DRI Development <dri-devel@...ts.freedesktop.org>,
Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
Hi Tong,
On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang <ztong0001@...il.com> wrote:
> On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <rdunlap@...radead.org> wrote:
> > On 2/20/21 3:02 PM, Tong Zhang wrote:
> > > pm2fb_sync is called when doing /dev/fb read or write.
> > > The original pm2fb_sync wait indefinitely on hardware flags which can
> > > possibly stall kernel and make everything unresponsive.
> > > Instead of waiting indefinitely, we can timeout to give user a chance to
> > > get back control.
> >
> > Is this a real problem or theoretical?
> > Does someone still use this driver?
>
> I currently have this problem on my machine.
> I have submitted a revised patch -- which includes the console log.
Your machine is "QEMU Standard"?
Can this happen on real hardware, too, or is this a deficiency in QEMU,
which should be fixed there?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists