Re: [PATCH] fbmem: fix race condition between

On Wed, 25 May 2011 Fabio Erculiani [off-list ref] wrote:

On Wed, May 25, 2011 at 8:57 PM, Bruno Prémont wrote:

quoted

On Wed, 25 May 2011 Fabio Erculiani [off-list ref] wrote:

quoted

On Wed, May 25, 2011 at 8:46 PM, Bruno Prémont wrote:

quoted

On Wed, 25 May 2011 Fabio Erculiani [off-list ref] wrote:

quoted

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 vgay1. It is quite simple to reproduce.
Also see: http://bugs.gentoo.org/show_bug.cgi?id68109

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