Messages in this thread | | | Date | Wed, 25 May 2011 21:12:53 +0200 | From | Bruno Prémont <> | Subject | Re: [PATCH] fbmem: fix race condition between register_framebuffer() and fb_open() |
| |
On Wed, 25 May 2011 Fabio Erculiani <lxnay@sabayon.org> wrote: > On Wed, May 25, 2011 at 8:57 PM, Bruno Prémont wrote: > > On Wed, 25 May 2011 Fabio Erculiani <lxnay@sabayon.org> wrote: > >> On Wed, May 25, 2011 at 8:46 PM, Bruno Prémont wrote: > >> > On Wed, 25 May 2011 Fabio Erculiani <lxnay@sabayon.org> wrote: > >> >> I'm not a fbdev expert. So I leave the real fix to real men ( ;-) ). > >> >> It is causing deadlock during boot, so I would consider it quite critical. > >> >> Users using any fb driver will get into troubles. > >> >> The workaround is to boot with vga=normal. > >> > > >> > What is your system doing during boot? I've never seen it here but maybe > >> > my boot sequence is too simple. > >> > >> I'm using vesafb and vga=791. It is quite simple to reproduce. > >> Also see: http://bugs.gentoo.org/show_bug.cgi?id=368109 > > > > Looks like gentoo kernel, might be splash is related to the hang > > Then, if you say so, it must be the fbsplash patch for sure, I keep > forgetting of that :-/
I've had a look at the bug report which points at fbcon_decore patch.
Looking into that patch confirms my impression: fbcon_decor calls a userspace helper at the time fbcon takes over console and that userspace helper then tries to open fb device with the aim of calling some IOCTLs.
Probably changing fbcon_decor to just call the userspace helper in non-blocking mode (or having userspace helper "fork and detach") would avoid the deadlock as well. Though fbcon_decor seems to rely on helper's return code...
What is the matching piece on userspace side so I can look at it as well?
Bruno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |