On Wed, 25 May 2011 Fabio Erculiani <lxnay@xxxxxxxxxxx> wrote: > On Wed, May 25, 2011 at 8:57 PM, Bruno PrÃmont wrote: > > On Wed, 25 May 2011 Fabio Erculiani <lxnay@xxxxxxxxxxx> wrote: > >> On Wed, May 25, 2011 at 8:46 PM, Bruno PrÃmont wrote: > >> > On Wed, 25 May 2011 Fabio Erculiani <lxnay@xxxxxxxxxxx> 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-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
