This is G o o g l e's cache of http://zaurus.wynn.com/problems/ as retrieved on Jul 26, 2005 09:48:49 GMT.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
This cached page may reference images which are no longer available. Click here for the cached text only.
To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:54abkKL5Dc4J:zaurus.wynn.com/problems/+site:zaurus.wynn.com&hl=en&client=firefox-a


Google is neither affiliated with the authors of this page nor responsible for its content.

zaurus:problems


The Zaurus SL5000D and SL5500 are palmtop computers with great potential, but the maker, Sharp Electronics, has botched several things and has not taken any steps to deal with the issues even though they have had feedback about most of the problems below on the developer web site for months. Unfortunantly Sharp has not answered the concerns raised by developers durring the beta period. The SL5500 is now a released product and the general public will begin to run into these problems. It is sad that Sharp has refused to fix the problems with their unit as the Zaurus may be a first introduction to Linux/Unix systems for many users. The problems the Zaurus has will give the false impression to new users that the problems are with Linux in general rather than with the choices that Sharp made in implementing Linux on the Zaurus.

Problems:

  • Frequent system & application lockups - These lockups seem to be realted to processes going into disk wait state and never leaving disk wait. Once one process goes into disk wait it seems that it is only a matter of time before all of them are in disk wait. If qpe is the first process to get stuck in disk wait then the GUI is totally locked and no interaction is possible with the unit via it's console.

  • Network security problems - The Zaurus ships with open unencrypted services running on the following ports:

    4242 - ftp server login: root passwword: NONE!

    4243 - behaves a little like rsync

    4992 - probably also part of the desktop sync

  • su broken - /bin/tinylogin is not installed suid root. This breaks su, which is a link to /bin/tinylogin

  • adduser broken - using adduser to creat a new user account results in a mangled password file and some root owned directories being changed to be owned by the user just created! This is very bad!

  • SD cards not FSCKed at boot/insert - SD cards that are formated and newfsed as Linux ext2 filesystems are not fscked at boot, or insertion.

  • CF cards not FSCKed at boot/insert - CF cards that are formated and newfsed as Linux ext2 filesystems are not fscked at boot, or insertion.

  • clock loses time - The system clock loses several minutes a day . After several days this makes the apointment calendar alarm useless.

  • SD cards disapear - When the system wakes up from suspend the SD card is not always recognized.

  • QTE ( QT Embeded GUI ) runs as root - When the system goes to init level 5 qte starts as root. This means that all user apps run as root! Some users have already reported accidently deleting system files. There is no need to run the UI as root!

  • NFS writes cause system lockup - Nfs writes lead to immidiate disk wait state by the process attempting the write action. In time this leads to all processes blocking and the system must be power cycled to become usable again.

  • QPE dies on resume - qpe (the console gui) dies when the system wakes up from suspend. This kills any gui apps that were running and the system is unusable until qpe restarts, which sometimes does not happen. When qpe does restart if you have many files on your SD or CF card it takes for ever while qpe does a find from / to build the list of files for the docuemnt tab.

    2002/01/05 - Found the cause of QPE death

    It seems that QPE was being killed and restarted after suspend/resume cycles due to the supplied Sharp Mobile software being installed on the SD. It seems that the little white icon at the bottom of the Zaurus screen is from an applette that is linked into QPE at run time. The SD manager software thinks that on resume it must kill QPE since it has the applet open, and then unmount and remount the SD. This can be looked at as both a bug with the Sharp Mobile software and a problem with the SD manager.

    It seems to be a waste of memory and cpu horsepower to link the applet that allows one to change e-mail and proxy settings into the QPE desktop application. It would make much more sense to set up a tab on the system that would have in it the enfora modem manager, a proxy controler, and a small program to do the work of this applet. Sure it looks cool to always have your own private icon on the screen, but this is a system with very limited resources!

    The SD manager must also be considered at fault because it should not be trying to kill processes, or unmounting and remounting a filesystem just because of a suspend/resume transition.

  • gzip improperly installed - When one builds and installs gzip, gzcat, and gunzip only one binary is installed and it is linked to 3 times. this saves lots of disk space since the same binary preforms all 3 functions and knows which function to do based on either command line arguments, or the name it is called by. A proper gzip install looks like this:

    wa3yre.wynn.com: ls -l | grep 90112
    -rwxr-xr-x  3 root        90112 Oct  1  1994 gunzip
    -rwxr-xr-x  3 root        90112 Oct  1  1994 gzcat
    -rwxr-xr-x  3 root        90112 Oct  1  1994 gzip
    wa3yre.wynn.com:
    
    The Zaurus gzip install looks like this:
    
    zbox.wynn.com:ls -l | grep  55120
    -rwxrwxr-x    1 root     root         55120 Apr 28 00:33 gunzip
    -rwxrwxr-x    1 root     root         55120 Apr 21 23:14 gzip
    -rwxrwxr-x    1 root     root         55120 Feb  4 05:25 zcat
    zbox.wynn.com:
    
    

    Note also that gzcat is called zcat, Sharp should really put the g back to avoid confussion with the real zcat which is far less usefull. We have these packages taking up 3 times the space they need to in a system with very limited disk space. Is the person at sharp that builds the roms for the Zaurus a Unix Novice?

    Furhter investigation of the system shows that the waste of space is even worse because busybox includes gzip and gunzip.

    zbox.wynn.com:busybox
    BusyBox v0.52 (2001.08.30-07:09+0000) multi-call binary
    
    Usage: busybox [function] [arguments]...
       or: [function] [arguments]...
    
            BusyBox is a multi-call binary that combines many common Unix
            utilities into a single executable.  Most people will create a
            link to busybox for each function they wish to use, and BusyBox
            will act like whatever it was invoked as.
    
    Currently defined functions:
            basename, busybox, cat, chgrp, chmod, chown, chroot, chvt, clear,
            cp, cut, date, dc, dd, deallocvt, df, dirname, dmesg, dpkg, dpkg-deb,
            du, dumpkmap, dutmp, echo, env, false, fbset, fdflush, find, free,
            freeramdisk, fsck.minix, grep, gunzip, gzip, halt, head, hostid,
            hostname, id, init, kill, killall, klogd, length, linuxrc, ln,
            loadacm, loadfont, loadkmap, logger, logname, ls, lsmod, makedevs,
            md5sum, mkdir, mkfifo, mkfs.minix, mknod, mkswap, mktemp, more,
            mount, mt, mv, nc, nslookup, ping, poweroff, printf, ps, pwd,
            reboot, reset, rm, rmdir, sed, setkeycodes, sh, sleep, sort, swapoff,
            swapon, sync, syslogd, tail, tar, tee, telnet, touch, tr, true,
            tty, umount, uname, uniq, update, uptime, usleep, uudecode, uuencode,
            wc, wget, which, whoami, xargs, yes, zcat
    
    zbox.wynn.com:
    
    

    This means that almost all the space taken by gzip, gunzip and zcat is wasted. While the current busybox does not have gzcat defined, it could be recompiled to have it with very little overhead added. If that is not desired gzcat can be simulated with the simple shell program below.

    #! /bin/sh
    #
    # gzcat - wrapper for gunzip applet of busy box to simulate the real
    #         gzcat.  Copyright 2002/04/28 by Brett Wynkoop
    #         wynkoop@wynn.com.  
    # This software is released under the GNU public license.  You can
    # obtain a copy of the GPL at 
    #      http://www.gnu.org/licenses/gpl.txt
    #
    
    PATH=/bin:/usr/bin
    LD_LIBRARY_PATH=/lib:/usr/lib
    export PATH LD_LIBRARY_PATH
    
    MYNAME=`basename $0`
    
    echo $@ | grep "\-h"
    if [ $? -eq 0 ]
    then
         echo "usage: $MYNAME  [-dfhlLnNrtvV19] [-S suffix] [file ...]"
         gunzip -h 2>&1 | grep -v gunzip | grep -v stdout
         echo
         exit 0
    fi
    
    exec gunzip -c $@
    
    

    Let's hope Sharp cuts this waste of disk space in future Rom Images. The wasted 165K of disk space is enough for several other programs to be installed.

  • qinstall (QT GUI Package installer) is broken - qtinstall fails to install packages that install from the command line with no errors or problems when ipkg is used directly.

  • Wasted Disk Space - /root contains 3 files that contain the default files that are extracted to the system at first boot and after a forced reset. Unfortunantly these files are uncompressed tar files that take up 1.3Mb of space.

    [localhost:/tmp/zaurus] wynkoop% ls -la
    total 1304
    drwxr-xr-x   5 wynkoop  staff      126 Apr 29 12:50 .
    drwxrwxrwt  10 root     staff      296 Apr 29 12:49 ..
    -rw-r--r--   1 wynkoop  staff   133120 Apr 29 12:50 .dev_default.tar
    -rw-r--r--   1 wynkoop  staff  1187840 Apr 29 12:50 .home_default.tar
    -rw-r--r--   1 wynkoop  staff    10240 Apr 29 12:50 .var_default.tar
    [localhost:/tmp/zaurus] wynkoop% du -s .
    1304    .
    [localhost:/tmp/zaurus] wynkoop% 
    

    If these files were gzipped with a -9 compression level they would take up much less space. This space could be used for disk space ( I could use another 1Mb) or main memory. Here is the size after compressing these files:

    [localhost:/tmp/zaurus] wynkoop% gzip -v -9 .???*tar
    .dev_default.tar:        97.6% -- replaced with .dev_default.tar.gz
    .home_default.tar:       86.8% -- replaced with .home_default.tar.gz
    .var_default.tar:        96.7% -- replaced with .var_default.tar.gz
    [localhost:/tmp/zaurus] wynkoop% ls -la
    total 164
    drwxr-xr-x   5 wynkoop  staff     126 Apr 29 12:59 .
    drwxrwxrwt  10 root     staff     296 Apr 29 12:49 ..
    -rw-r--r--   1 wynkoop  staff    3114 Apr 29 12:50 .dev_default.tar.gz
    -rw-r--r--   1 wynkoop  staff  156544 Apr 29 12:50 .home_default.tar.gz
    -rw-r--r--   1 wynkoop  staff     372 Apr 29 12:50 .var_default.tar.gz
    [localhost:/tmp/zaurus] wynkoop% du -s .
    164     .
    [localhost:/tmp/zaurus] wynkoop% 
    

    Of course we can't do the compression ourselves because this is a read only section of the disk and without the SD drivers it is not possible to rebuild the system with the sources Sharp provides.

  • Sharp Mobile Issues - Sharp Mobile Problems have thier own page

  • Filesystem Issues - Filesystem Issues have their own page.

  • Wasted memory - At boot time the system seems to start ppp against the built in serial port and a number of other processes that seem to be dedicated to syncing. If you attempt to kill them to free more memory you find they return. This indicates that they are being started from init. A check of /etc/inittab shows that the processes are there. If you comment them out and send init a HUP signal you can then kill the sync related processes. Unfortunantly this only lasts until the next boot as init seems to read the inittab in ROM at boot rather than the one in /etc that is writable! This must be considered 2 bugs! The first bug is running ppp and the other processes needed to sync all the time. There should be a control to turn them on and off! The second bug is init reading the inittab in rom at boot instead of the one the owner of the zaurus can modify. This needs to be fixed. Did sharp forget this is a system with limited memory?

  • Sharp Responds - I got a phone call 2002/05/06 from Sharp assuring me that they are working to try and fix the problems as soon as possible. I sure hope they can fix them fast so this platform becomes popular!

  • Last update 2002/05/06 - more to come when I have time to type the info in. Check back offten!

    zaurus:problems.
    Wynn Data Limited has served l l m r visitors this page.