mount sshfs with access for all users

sudo sshfs user@host:/path mount_path -o allow_other

Slow boot of Ubuntu into Unity 3D with proprietary nVidia drivers

I have Ubuntu Oneiric Oncelot 11.10 with proprietary nVidia (nvidia-current: 290.10-0ubuntu1~oneiric~xup1) drivers.

And there're 2 things I'm tired of:

1. Slow boot. Mostly a black screen after nVidia drivers are already loaded.
   It turned out it lasts more then a minute (73 seconds for example, compared to booting into Unity 2D - 38 seconds).
2. Slow wake-up from suspend. Don't have precise numbers but Unity 2D wakes just immediately while Unity 3D shows me a black screen more then a minute.

So I decided to try "bootchart".
Installed it with: sudo apt-get install bootchart
And booted into:
Unity 3D - got 1:12.98 min

Unity 2D - got 0:38.66 min

Then looked if some processes related to nVidia differ in both boot logs.
And indeed I found out that "nvidia-settings" process was mentioned proc_ps.log in such proportion:
- 66 times for Unity 3D and
- 21 times for Unity 2D.

That lead me to conclusion that disabling "nvidia-settings" may improve boot performance.
So I did "sudo chmod a-x /usr/bin/nvidia-settings" and the next boot in Unity 3D took the same 37 seconds (0:37.76) as with Unity 2D.

For sure it is not the solution, but at least a direction to look.

Moreover this unfortunately has nothing to do with wake-up delay, so keep looking into it.

Anyway, hope this helps.

P.S. Make sure you know what are you doing while dealing with system files.

Fix FlexNET License Server Manager

For some reason in FlexNET tools version 11.4 license server manager application stopped working. Actually it won't start at all:
=========
 ./lmgrd 
bash: ./lmgrd: No such file or directory
=========

the most probable reason for such sort of problem is unavailability of some dependence (i.e. shared library).

So let's look at dependencies:
=========
$ ldd lmgrd 

linux-gate.so.1 =>  (0xb784b000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb781a000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb77f0000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb77d1000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7655000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7650000)
/lib/ld-lsb.so.3 => /lib/ld-linux.so.2 (0xb784c000)

=========

The first suspect is definitely (for me at least it was so) "linux-gate.so.1"

But it turned out that it's ok: http://www.cyberciti.biz/faq/linux-linux-gate-so-1-library-dynamic-shared-object-vdso/ refers to http://www.ibm.com/developerworks/linux/library/l-lpic1-v3-102-3/

=========

This virtual library provides the necessary logic to allow user programs to access system functions through the fastest means available on the particular processor, either interrupt, or with most newer processors, fast system call.

=========

Others look pretty solid except the last one:  /lib/ld-lsb.so.3

=========

$ file /lib/ld-lsb.so.3

/lib/ld-lsb.so.3: ERROR: cannot open `/lib/ld-lsb.so.3' (No such file or directory)

=========

For some reason in some modern Linux distributions this symlink is not set by default and one needs to fix it whether manually or simply installing "LSB core" (Linux Standard Base core support package)  package.

In RedHat:
=========
yum install redhat-lsb.i686
=========


or for Debian/Ubuntu
=========
apt-get install lsb-core package

=========

Now it resolves correctly:

=========

$ file /lib/ld-lsb.so.3

/lib/ld-lsb.so.3: symbolic link to `ld-linux.so.2'

=========

And as a consequence lmmgr starts and acts properly now!

LCD bring-up tips

During Embedded Linux Conference Europe 2011 I attended one very interesting presentation regarding new LCD bring-up procedures.


Among other nice things we were presented with extremely useful utility that may save a bunch of time while guessing what is wrong with this brand new LCD.
And this is fb-test utility.


Feel free to check it out from here http://www.elinux.org/images/0/09/Fb-test.c and then simply build it with your cross-toolchain of choise.
Then on target run it.


More on this you may find here http://www.elinux.org/Board_Bringup_Utilities

These are slides from ELCE http://elinux.org/images/d/d5/Elce-2011-anders.pdf

Video of this presentation (39 minutes)
FullHD (242M): http://free-electrons.com/pub/video/2011/elce/elce-2011-anders-board-bringup-lcd-display.webm
450x800 (98M): http://free-electrons.com/pub/video/2011/elce/elce-2011-anders-board-bringup-lcd-display-450p.webm

Mount jffs2 image in your development system

Devices with embedded linux quite often have root file-system stored in flash-memory. And quite often it is whether jffs2 or yaffs2. For partitions of small size (say < 100-200 Mb) one may easily use jffs2, while for larger partitions it is recommended to use yaffs2 because of its better scalability (smaller RAM requirements and better performance).
Another big advantage of jffs2 over yaffs2 is its native support in mainline linux kernel. For sure yaffs2 patch could be easily applied to your kernel tree it is always very nice to have a feature in mainline.

So basically you prepare proper file-system image and put it on MTD-device of your embedded board.
And sometimes you need to get some data from prepared file-system image or even modify it on your host development machine.

I found a nice bash script on Maemo Wiki http://wiki.maemo.org/Modifying_the_root_image#Shell_script_to_mount.2Funmount_JFFS2_using_block_device_emulating_MTD
But since I have kernel of version 3.0 on my machine I decided to remove parts for 2.4 kernel (corresponding branches were used for 3.0 kernel as well because of improper tests that were not written for 3.0 obviously). And also I added automatic pick-up of an empty loop device.
So here's a very helpful script for mounting jffs2 image:

#!/bin/sh
JFFSIMG=$1 # jffs image
LOOP=$(losetup --find) # loop device
MP="/media/jffs2" # mount point
MTDBLOCK="/tmp/mtdblock0" # MTD device file
BLKMTD="block2mtd"
UMNT=""
 
echo "$0" | grep unmount_ >/dev/null 2>&1
[ $? -eq 0 ] && UMNT=1
if [ $# -gt 1 -a x"$2"x = x"unmount"x ]; then
  UMNT=1
fi
  
if [ x"${UMNT}"x = x""x ]; then
  if [ ! -b ${MTDBLOCK} ] ; then
    mknod ${MTDBLOCK} b 31 0 || exit 1
  fi
  lsmod | grep loop >/dev/null 2>&1
  if [ $? -ne 0 ]; then
    modprobe loop
    [ $? -ne 0 ] && echo "loopback loading failed" && exit 1
    sleep 1
  fi
  losetup ${LOOP} ${JFFSIMG} || exit 1
  sleep 1
  modprobe mtdblock
  modprobe ${BLKMTD} || exit 1
  echo "${LOOP}" > /sys/module/block2mtd/parameters/block2mtd
  sleep 1
  modprobe jffs2
  [ ! -d ${MP} ] && mkdir -p ${MP}
  mount -t jffs2 ${MTDBLOCK} ${MP} || exit 1
else
  umount ${MP}
  if [ $? -ne 0 ]; then
    echo "Cannot unmount JFFS2 at $MP" && exit 1
  fi
  modprobe -r jffs2
  modprobe -r ${BLKMTD}
  modprobe -r mtdblock
  sleep 1
  losetup -d ${LOOP}
fi