Advanced search
Log In
New Account
  
Home My Page Project Cloud Code Snippets Project Openings ESbox
Summary Forums Tracker Lists Tasks News SCM Files Wiki

Bugs: Browse | Download .csv

[#4045] Starting Maemo Application Framework takes a long time

Please login

State:
Open
Date:
2009-05-04 13:28
Priority:
3
Submitted By:
Ed Swartz (eswartz)
Assigned To:
Nobody (None)
Summary:
Starting Maemo Application Framework takes a long time

Detailed description
Something in the networking configuration used with some virtual machines causes the Maemo AF to delay for a long time
when starting up.  Local firewalls seem to be involved in this.  We need to investigate further.



Email extracts below:

----

I tested this issue with my home pc, where I can control Windows Firewall settings.

If firewall is enabled this 6 minutes delay happens also with VMware Player,
but if I disable firewall, Maemo start normally with VMware player, but not with QEMU.

So with QEMU, there is always 6 minutes delay when you start Maemo from ESBox.

I tested this with QEMU 0.9.0 and 0.10.2 ( Qemu Manager v6.0).

-------



Ok.  I think I've seen this happen too (I don't wait 6 minutes, I just never see the desktop come up :( ).  Can you
launch applications and have them show up with the proper decorations?

[[aoh]] Applications can be lauched right away ESBox Console informs "hildon-input-method[16395]: GLIB MESSAGE
default - ui up and running", but decoration is not ok (see attacment).

I'm not sure Raul's note about proxy/firewall settings applies (this happens for me even with the firewall disabled).  
 Was this a recent change in your experience? 
[[aoh]] yes
 Did it use to come up much sooner in this environment? 
[[aoh]] no 

----


More details about testing environment.

Windows XP, SP2, firewall disabled
qemu-0.9.1-windows.zip
Kqemu-1.3.0pre11-install.exe
maemosdk_server_intrepid-10-08 
esbox_2.0.0-I200904220915

ESBox Settings:
Build machine: QEMU Linux Build Machine

QEMU Options:
Command pattern: "${QEMU}" -kernel-kqemu ${DISK_OPTIONS} -usb -L "${INSTALL_PATH}" -m ${MEMORY}
-redir tcp:${SSH_PORT}::22
Memory size (Mb): 512 (tested also with 1024)

Machine access:
Target Address: 127.0.0.1
Target SSH port: 2222
Host address: 10.120.148.42
Host SSH port: 22

Tested with Targets:
Scratchbox 1
 DIABLO_ARMEL (OS2008; Diablo version 4.1)
 DIABLO_X86 (OS2008; Diablo version 4.1)

Starting Hildon Desktop takes time over 6 minutes and after that Home-menu is usable.
Then if you start and close some application, Home-menu disappears and it takes
another 6 minutes to come back.

----


Testing environment:
    Windows XP / QEMU with  QEMU Accelerator / maemosdk_server_intrepid-10-08 / esbox_2.0.0-I200904220915

Right after starting Maemo (Hildon Desktop), ESBox Console informs:
    hildon-input-method[16395]: GLIB MESSAGE default - ui up and running
but it takes over 6 minutes that Hildon Desktop really starts in X server.

ESBox Console - Starting X Server
---------------------------------------------------
Vendor: The Cygwin/X Project
Release: 1.5.3.0 (20090205)
Contact: cygwin-xfree@cygwin.com
XWin was started with the following command line:
/usr/bin/Xwin :2 -lesspointer -swcursor -screen 0 800x480x16 -dpi 96 
 -ac -extension Composite 
winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
(II) XF86Config is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
winPrefsLoadPreferences: /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 00000007
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winScreenInit - Using software cursor
MIT-SHM extension disabled due to lack of kernel support
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(--) 3 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "0000040B" (0000040b) 
(--) Using preset keyboard for "Finnish" (40b), type "4"
Rules = "xorg" Model = "pc105" Layout = "fi" Variant = "(null)" Options
= "(null)"
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
>                   Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server
winPointerWarpCursor - Discarding first warp: 400 240
winProcEstablishConnection - Hello
winProcEstablishConnection - Clipboard is not enabled, returning.

ESBox Console - DIABLO_X86 - Running Maemo command (start)
------------------------------------------------------------------------------------------------
Sample files present.
Starting DBUS system bus
Starting D-BUS session bus daemon
Starting Maemo Launcher: maemo-launcher.
Starting Sapwood image server
sapwood-server[16359]: GLIB INFO default - server started
Starting Matchbox window manager
mbpixbuf: no shared memory extension
Starting clipboard-manager
Starting Keyboard
Starting Hildon Desktop
/home/maemo/.osso/current-gtk-key-theme:1: Unable to find include file: "keybindings.rc"
hildon-input-method[16395]: GLIB MESSAGE default - ui up and running






Followup

Message
Date: 2009-11-24 21:35
Sender: Ed Swartz

Marked in documentation as a known issue, will not address.
Date: 2009-08-14 09:39
Sender: Toni Pulkkinen

I have not found solution that, but I have learned more about
the issue:
	- That works correctly with the Fremantle SDK, so that is not
related on firewall configurations.
	- An application starts normally without the hildon-desktop.
	- The 6 minute delay is inside Diablo’s Hildon-desktop
implementation, so there might need to be done some workaround(
to areas that are related on network communication).
	- Host is not able to see traffic between host and virtual machine,
but virtual machine sees the traffic.
	- All works fine only with VMWare. The biggest difference between
them is VMWare use virtual network adapter to communication,
whereas VirtualBox/Qemu communicates via localhost.

Attached Files:

Name Download
No Files Currently Attached

Changes:

Field Old Value Date By
ResolutionNone2009-11-24 21:35eswartz
VersionNone2009-11-24 21:35eswartz
assigned_totopulkki2009-08-14 09:39topulkki
assigned_tonone2009-08-07 12:40topulkki

Terms of Use    Privacy Policy    Contribution Guidelines    Feedback

Powered By GForge Collaborative Development Environment