Re: [directfb-users] A question about SaWMan

[Edison_lin-林俊翰]

Hi,
While I traced down, I noticed a situation. As usual, I ran testman, and 
then df_window, with more debug messages; I found that df_window requests a 
sawman lock X before calling sawman_call() for window reconfig, and after 
testman receives this event, it then calls reconfig handler within which 
sawman lock X is requested again. The requesting seems to fail because it 
hangs in skirmish prevail. Is this a bug ?

Appreciate,
Edison Lin

----- Original Message ----- 
From: "Richard Lee" <rd...@tivo.com>
To: "Niels Roest" <ni...@directfb.org>
Cc: "Edison_Lin-林俊翰" <edison_...@gemtek.com.tw>; 
<directfb-users@directfb.org>
Sent: Saturday, August 15, 2009 12:08 AM
Subject: Re: [directfb-users] A question about SaWMan


Not sure if this is at all related to the deadlock I believe I found in
sawman/directfb that I posted to the directfb-dev mailing list, but it
sounds familiar.  I provided copious information that demonstrates the
source of the deadlock, which occurs when one process is actively
drawing when another attempts to start up and add a window in a new layer.

Richard

Niels Roest wrote:
Hi Edison.

No idea, so I will give you some hints.

I noticed that when you first start e.g. df_window, and only then
testman, some redraws are missed, but this is a minor issue and does not
cause locking up of the system. This is on a recent X11 system. Your
versions look ok to me.

If you cannot use gdb to see where the application is stuck, I would
advise to build directfb with debug and trace options: --enable-debug
and --enable-trace. If you then stop an application with control-C, it
will dump a stracktrace of all the threads running.

Also, you can check /proc/fusion/0 for the files there, to see if there
is a lock still pending at the moment. look at the file called skirmish,
here you can see which process ID is taking the lock, and - if there are
any - which IDs are trying to take it, and therefore waiting. If you
have a deadlock then obviously on skirmish X app A waits for app B, and
on skirmish Y app B waits for app A.

Greets
Niels


Edison_lin-林俊翰 wrote:
Hi,
Please allow me to make a complement. I think maybe it's due to the
deadlock of competing fusion skirmish locks. I found two un-dismiss
locks in the df_window side, and one un-dismiss lock in the testman
side. I guess it may be the case that df_window got a lock first, and
then testman tried to get the lock but failed, and at this moment
df_window tried to get the lock again, which results in a deadlock
situation...I'm not sure about the answer, but I'll keep tracing. Any
suggestion is welcome.

Appreciate,
Edison Lin

----- Original Message ----- From: "Edison_lin-林俊翰"
<edison_...@gemtek.com.tw>
To: <directfb-users@directfb.org>
Cc: "Niels Roest" <ni...@directfb.org>
Sent: Friday, August 14, 2009 12:09 PM
Subject: Re: A question about SaWMan


Hi,
Thanks for your replying. I did enable the multi-application core
option, and install the linux fusion module as well. The following is
the log from testman after I started testman first and then
df_window, for your reference. I use SaWMan 1.4.0, Directfb-1.2.0,
Directfb-example-1.2.0, and linux-fusion-8.0.0.

I add some debug message in the code. The testman did sense the
running directfb application and try to add one's windows to its
control, but locked. Is it related to the versions I use ?

<==================================log==================================================>

./testman
(*) SaWMan/TestMan: Initializing...

~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.2.0 |~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2001-2008 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
----------------------------------------------------------------

(*) DirectFB/Core: Multi Application Core. (2009-08-10 16:11)
(*) 316,dfb_core_create
(*) Fusion/SHM: Using MADV_REMOVE (2.6.23.1 >= 2.6.19.2)
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'Fusion Dispatch' (25555) [MESSAGING
OTHER/OTHER 0/0] <10485760>...
(*) 322,dfb_core_create
(*) 335,dfb_core_create
(*) 337,dfb_core_create
(*) 97,fusion_skirmish_prevail
(ignore)
(*) 97,fusion_skirmish_prevail
(*) 124,fusion_arena_enter
(*) 97,fusion_skirmish_prevail
(ignore)
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER
0/0] <10485760>...
(*) 97,fusion_skirmish_prevail
(ignore)
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER
0/0] <10485760>...
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<10485760>...
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Input: Macintosh mouse button emulatio (1) 0.1
(directfb.org)
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<10485760>...
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Input: AT Translated Set 2 keyboard (2) 0.1 (directfb.org)
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<10485760>...
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Input: ImPS/2 Generic Wheel Mouse (3) 0.1 (directfb.org)
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0]
<10485760>...
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Input: Power Button (FF) (4) 0.1 (directfb.org)
(*) 97,fusion_skirmish_prevail
(*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0]
<10485760>...
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org)
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: MMX Software Rasterizer 0.6 (directfb.org)
(*) 97,fusion_skirmish_prevail
(ignore)
(*) 97,fusion_skirmish_prevail
(*) DirectFB/Core/WM: SaWMan 0.2 (directfb.org)
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 171,dfb_wm_core_initialize
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 168,register_process
(*) 171,register_process
(*) 174,register_process
(*) 181,dfb_wm_core_initialize
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 345,dfb_core_create
(*) 97,fusion_skirmish_prevail
(*) 362,dfb_core_create
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) SaWMan: Initializing stack 0x20138400 for tier 0x255c3000, 0x0,
layer 0, context 0x20017000 [3]...
(*) 97,fusion_skirmish_prevail
(ignore)
(*) 97,fusion_skirmish_prevail
(*) SaWMan/Init: Layer 0: 800x600, RGB16, options: 0
(*) SaWMan/Init: Border 0: 800x600, RGB16, options: 8
(*) 97,fusion_skirmish_prevail
(*) 97,fusion_skirmish_prevail
(*) SaWMan/TestMan: Process added (25534) [1]!
(*) SaWMan/TestMan: Process added (25567) [2]!
(*) SaWMan/TestMan: Window preconfig (20,120-300x200)!
(*) SaWMan/TestMan: Window added (20,120-300x200)!
(*) 745,window_reconfig
(*) 377,LayoutWindowAdd
(*) 307,MosaicAddWindow
(*) 404,ISaWManManager_Lock
(*) 97,fusion_skirmish_prevail

<==================================log
end==================================================>


Appreciate,
Edison Lin

----- Original Message ----- From: "Niels Roest" <ni...@directfb.org>
To: "Edison_Lin-林俊翰" <edison_...@gemtek.com.tw>
Cc: <directfb-...@directfb.org>
Sent: Thursday, August 13, 2009 5:30 PM
Subject: Re: A question about SaWMan


Hi Edison.

first off, you are posting to the CVS/change control list; Can you
please use the "users" list for any following questions?

you are right, testman must be run first, and then df_window and other
applications should be started. This is exactly how I am using it 
also.
Did you ./configure with --enable-multi, and are you insmod'ding the
fusion kernel module? Otherwise it is not possible to run DirectFB 
with
multiple applications at the same time (of which testman is already
one).

If this is not the case, it would be interesting to know where the 
lock
happens.

hth
Niels

Edison_lin-林俊翰 wrote:
Hi,
If I ran df_window and other directfb applications before testman,
everything went fine; I got a screen of tiled windows. But why can't 
I
run these applications after testman ? It seems to trap into a sawman
lock for the application to run, and after I removed the lock/unlock
part, then the applications can be run. I think it's more reasonable
for a window manager application to be run first, and any directfb
application added later can be managed through it.
Appreciate,
Edison Lin
------------------------------------------------------------------------


_______________________________________________
directfb-cvs mailing list
directfb-...@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-cvs


--

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"


_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users




_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users