tux-droid-user Mailing List for Tux Droid CE (Page 10)
Status: Beta
Brought to you by:
ks156
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
(129) |
Apr
(96) |
May
(38) |
Jun
(70) |
Jul
(7) |
Aug
(27) |
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(9) |
Feb
(7) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: xAD <xa...@xb...> - 2007-04-19 09:50:53
|
OK David, you are right. thanks. On Thu, 2007-04-19 at 07:57 +0200, David Bourgeois wrote: > On Thu, 19 Apr 2007 01:44:37 +0200, xAD <xa...@xb...> wrote: > > > Hi all, > > > > I don't know if is a fault of my TuxDroid or a bug in the Core Firmware > > of the Tux. > > > > Reset your tux with a poweroff / poweron. > > > > Beak are closed > > Eyes are open with both LED on. > > > > Open the Tux Droid Interface (gtdi.py) > > > > now Close the Eyes (eyes and led's are off) OK. > > > > now Open the Beak .. and voila' the Eyes they are opened without LED on. > > > > David. > > > > There's been a post about this a few days ago, probably just before you > joined the ML: > http://article.gmane.org/gmane.comp.hardware.tuxdroid.user/184 > > The fact that the eyes open when you move the mouth is not a bug, just a > limitation of the mechanics in the gearbox. > > david > > p.s. when you do a reply and change the subject to create a new post that > has nothing to do with the former one, you don't create a new thread for > your new subject, it's just threaded with the old subject (in Gmane and > most mail clients), the good practice is to create (compose) a new message > when you start a new topic, unless you explicitely want to continue the > thread with a new subject of course. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ tux-droid-user mailing list tux...@li... https://lists.sourceforge.net/lists/listinfo/tux-droid-user |
From: David B. <da...@ja...> - 2007-04-19 05:57:52
|
On Thu, 19 Apr 2007 01:44:37 +0200, xAD <xa...@xb...> wrote: > Hi all, > > I don't know if is a fault of my TuxDroid or a bug in the Core Firmware > of the Tux. > > Reset your tux with a poweroff / poweron. > > Beak are closed > Eyes are open with both LED on. > > Open the Tux Droid Interface (gtdi.py) > > now Close the Eyes (eyes and led's are off) OK. > > now Open the Beak .. and voila' the Eyes they are opened without LED on. > > David. > There's been a post about this a few days ago, probably just before you joined the ML: http://article.gmane.org/gmane.comp.hardware.tuxdroid.user/184 The fact that the eyes open when you move the mouth is not a bug, just a limitation of the mechanics in the gearbox. david p.s. when you do a reply and change the subject to create a new post that has nothing to do with the former one, you don't create a new thread for your new subject, it's just threaded with the old subject (in Gmane and most mail clients), the good practice is to create (compose) a new message when you start a new topic, unless you explicitely want to continue the thread with a new subject of course. |
From: xAD <xa...@xb...> - 2007-04-18 23:44:47
|
Hi all, I don't know if is a fault of my TuxDroid or a bug in the Core Firmware of the Tux. Reset your tux with a poweroff / poweron. Beak are closed Eyes are open with both LED on. Open the Tux Droid Interface (gtdi.py) now Close the Eyes (eyes and led's are off) OK. now Open the Beak .. and voila' the Eyes they are opened without LED on. David. |
From: Philippe T. <ph...@te...> - 2007-04-18 22:42:11
|
> So it's like there is no pthreads, only forked processes > One more tip: HOST: ps -eLf|grep tux UID PID PPID LWP C NLWP STIME TTY TIME CMD nobody 8386 1 8386 0 3 00:30 ? 00:00:00 /opt/tuxdroid/bin/tuxdaemo nobody 8386 1 8387 0 3 00:30 ? 00:00:00 /opt/tuxdroid/bin/tuxdaemo nobody 8386 1 8388 0 3 00:30 ? 00:00:00 /opt/tuxdroid/bin/tuxdaemo NSLU2: ps -eLf|grep tux UID PID PPID LWP C NLWP STIME TTY TIME CMD root 3677 2311 3677 1 1 00:37 pts/1 00:00:00 ./tuxdaemon root 3678 3677 3678 0 1 00:37 pts/1 00:00:00 ./tuxdaemon root 3679 3678 3679 1 1 00:37 pts/1 00:00:00 ./tuxdaemon root 3680 3678 3680 0 1 00:37 pts/1 00:00:00 ./tuxdaemon Look at PID column, looks like 3 threads on the i686 and 4 processes on the XScale. Phil |
From: Philippe T. <ph...@te...> - 2007-04-18 21:35:06
|
> Big diffs: much more mprotect calls, pthreads seem different (and ps ax > shows me the 4 "threads" on the slug) > Mmm seems this has to to with pthreads. I commented out the setuid() setgid() and now the tcp part starts too. I can connect from python but I cannot do anything there and even not ctrl-c to quit. From daemon logs I can see many client 0 connected client 0 connected I've to kill -9 python The script I tried: #!/usr/bin/python import sys sys.path.append('/opt/tuxdroid/api/python') from tux import * tux.cmd.leds_blink(2,10) tux.sys.wait(1) Now on daemon side. Ctrl-c on the daemon gives: Daemon closed Daemon closed Could not delete PID file Daemon closed Could not delete PID file Yep looks like we go 3 times through some code where we should go only once. When the daemon was running ps ax gave me root 2467 0.3 3.2 6776 960 pts/1 S+ 23:30 0:00 ./tuxdaemon root 2468 0.0 3.2 6776 960 pts/1 S+ 23:30 0:00 ./tuxdaemon root 2469 0.0 3.2 6776 960 pts/1 S+ 23:30 0:00 ./tuxdaemon root 2470 0.0 3.2 6776 960 pts/1 S+ 23:30 0:00 ./tuxdaemon And with the setuid() code: root 2476 2.0 3.1 6776 940 pts/1 S+ 23:31 0:00 tuxdaemon root 2477 0.0 3.1 6776 940 pts/1 S+ 23:31 0:00 tuxdaemon nobody 2478 0.0 3.1 6776 940 pts/1 S+ 23:31 0:00 tuxdaemon root 2479 0.0 3.1 6776 940 pts/1 S+ 23:31 0:00 tuxdaemon So it's like there is no pthreads, only forked processes and with setuid, only the current process changes actually. And when closing, all forked processes go through the same duplicated code from main(). Phil |
From: Philippe T. <ph...@te...> - 2007-04-18 20:56:56
|
> Could you please give an strace output? > Here is an attempt to make a diff with the laptop + slug - laptop Big diffs: much more mprotect calls, pthreads seem different (and ps ax shows me the 4 "threads" on the slug) +mprotect(0x400b6000, 32392, PROT_NONE) = 0 +mprotect(0x400c2000, 29828, PROT_NONE) = 0 -open("/lib/tls/i686/cmov/libpthread.so.0", O_RDONLY) = 3 +open("/lib/libpthread.so.0", O_RDONLY) = 3 +mprotect(0x400d9000, 306432, PROT_NONE) = 0 +mprotect(0x4012a000, 36064, PROT_NONE) = 0 -open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3 +open("/lib/libc.so.6", O_RDONLY) = 3 +mprotect(0x4023a000, 50820, PROT_NONE) = 0 -open("/lib/tls/i686/cmov/librt.so.1", O_RDONLY) = 3 +open("/lib/librt.so.1", O_RDONLY) = 3 +mprotect(0x4024e000, 77416, PROT_NONE) = 0 -set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d2fba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 -set_tid_address(0xb7d2fbe8) = 5845 +mprotect(0x40241000, 8192, PROT_READ) = 0 +mprotect(0x400e0000, 4096, PROT_READ) = 0 +mprotect(0x4001c000, 4096, PROT_READ) = 0 -uname({sys="Linux", node="mercure", ...}) = 0 +setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) = 0 +getpid() = 2234 +rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0 +rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0 +getpid() = 2234 -mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb752d000 -mprotect(0xb752d000, 4096, PROT_NONE) = 0 -clone(child_stack=0xb7d2d4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xb7d2dbf8, {entry_number:6, base_addr:0xb7d2dbb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb7d2dbf8) = 5846 -mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6d2c000 -mprotect(0xb6d2c000, 4096, PROT_NONE) = 0 -clone(child_stack=0xb752c4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xb752cbf8, {entry_number:6, base_addr:0xb752cbb0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb752cbf8) = 5847 +sched_get_priority_max(SCHED_OTHER) = 0 +sched_get_priority_min(SCHED_OTHER) = 0 +clone(child_stack=0x1dff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 2235 +write(4, "\330\244\1@\5\0\0\0\324*\2@\221\2\0\0\264H\2@\0\0\0\0\270"..., 148) = 148 +rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 +write(4, "`\22\16@\0\0\0\0t\375\260\276\270\243\6@ \264\1\0\0\0\0"..., 148) = 148 +rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 +rt_sigsuspend([] <unfinished ...> +--- SIGRTMIN (Unknown signal 32) @ 0 (0) --- +<... rt_sigsuspend resumed> ) = 32 +sigreturn() = ? (mask now [QUIT TRAP ABRT FPE USR2 TERM CONT SYS]) +sched_get_priority_max(SCHED_OTHER) = 0 +sched_get_priority_min(SCHED_OTHER) = 0 +rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 +write(4, "`\22\16@\0\0\0\0t\375\260\276\270\243\6@\310\250\1\0\0"..., 148) = 148 +rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 +rt_sigsuspend([] <unfinished ...> +--- SIGRTMIN (Unknown signal 32) @ 0 (0) --- +<... rt_sigsuspend resumed> ) = 32 +sigreturn() = ? (mask now [QUIT TRAP ABRT FPE USR2 TERM CONT SYS]) +pipe([5, 6]) = 0 -[{fd=3, events=POLLIN}], 1, -1) = -1 EINTR (Interrupted system call) ---- SIGRT_1 (Unknown signal 33) @ 0 (0) --- -setgid32(65534) = 0 -futex(0xb7d2d3c0, FUTEX_WAKE, 1) = 1 -rt_sigreturn(0x8052310) = -1 EINTR (Interrupted system call) ---- SIGRT_1 (Unknown signal 33) @ 0 (0) --- -setuid32(65534) = 0 -futex(0xb7d2d3c0, FUTEX_WAKE, 1) = 1 -rt_sigreturn(0x8052310) = -1 EINTR (Interrupted system call) -poll(usb_os_init: Found USB VFS at /dev/bus/usb Full strace: execve("/usr/local/bin/tuxdaemon", ["tuxdaemon"], [/* 12 vars */]) = 0 uname({sys="Linux", node="LKG63472F", ...}) = 0 brk(0) = 0x19000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=14761, ...}) = 0 mmap2(NULL, 14761, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libglib-2.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\354\317\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=622556, ...}) = 0 mmap2(NULL, 654984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4001e000 mprotect(0x400b6000, 32392, PROT_NONE) = 0 mmap2(0x400bd000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x97) = 0x400bd000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/usr/lib/libgthread-2.0.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\21\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=14532, ...}) = 0 mmap2(NULL, 46212, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x400be000 mprotect(0x400c2000, 29828, PROT_NONE) = 0 mmap2(0x400c9000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x400c9000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260=\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=92378, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000 mmap2(NULL, 367872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x400ca000 mprotect(0x400d9000, 306432, PROT_NONE) = 0 mmap2(0x400e0000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe) = 0x400e0000 mmap2(0x400e2000, 269568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400e2000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libusb-0.1.so.4", O_RDONLY) = 3 read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h\22\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=28892, ...}) = 0 mmap2(NULL, 60640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40124000 mprotect(0x4012a000, 36064, PROT_NONE) = 0 mmap2(0x40131000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0x40131000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0HO\1\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1091040, ...}) = 0 mmap2(NULL, 1128068, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40133000 mprotect(0x4023a000, 50820, PROT_NONE) = 0 mmap2(0x40241000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x106) = 0x40241000 mmap2(0x40244000, 9860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40244000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0000\35\0\000"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=30548, ...}) = 0 mmap2(NULL, 106088, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40247000 mprotect(0x4024e000, 77416, PROT_NONE) = 0 mmap2(0x40255000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0x40255000 mmap2(0x40257000, 40552, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40257000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001b000 mprotect(0x40255000, 4096, PROT_READ) = 0 mprotect(0x40241000, 8192, PROT_READ) = 0 mprotect(0x400e0000, 4096, PROT_READ) = 0 mprotect(0x4001c000, 4096, PROT_READ) = 0 munmap(0x40016000, 14761) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 setrlimit(RLIMIT_STACK, {rlim_cur=2044*1024, rlim_max=RLIM_INFINITY}) = 0 getpid() = 2234 rt_sigaction(SIGRTMIN, {0x400d1e98, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x400d1b1c, [RTMIN], 0x4000000 /* SA_??? */}, NULL, 8) = 0 rt_sigaction(SIGRT_2, {0x400d1894, [], 0x4000000 /* SA_??? */}, NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RT_1], NULL, 8) = 0 rt_sigaction(SIGINT, {0x400d6898, [INT], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGKILL, {0x400d6898, [KILL], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = -1 EINVAL (Invalid argument) brk(0) = 0x19000 brk(0x3a000) = 0x3a000 open("/var/run/tuxdaemon.pid", O_RDONLY) = -1 ENOENT (No such file or directory) open("/var/run/tuxdaemon.pid", O_RDWR|O_CREAT|O_TRUNC, 0644) = 3 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 _llseek(3, 0, [0], SEEK_CUR) = 0 flock(3, LOCK_EX|LOCK_NB) = 0 getpid() = 2234 write(3, "2234\n", 5) = 5 flock(3, LOCK_UN) = 0 close(3) = 0 chown32("/var/run/tuxdaemon.pid", 65534, 65534) = 0 fstat64(1, {st_mode=S_IFREG|0644, st_size=6108, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 write(2, "usb_set_debug: Setting debugging"..., 49usb_set_debug: Setting debugging level to 1 (on) ) = 49 open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=100, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 getdents64(3, /* 5 entries */, 4096) = 120 close(3) = 0 write(2, "usb_os_init: Found USB VFS at /d"..., 43usb_os_init: Found USB VFS at /dev/bus/usb ) = 43 sched_getscheduler(2234) = 0 (SCHED_OTHER) sched_getparam(2234, { 0 }) = 0 sched_get_priority_min(SCHED_OTHER) = 0 sched_get_priority_max(SCHED_OTHER) = 0 sched_get_priority_max(SCHED_OTHER) = 0 gettimeofday({1176925211, 226099}, NULL) = 0 open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/share/locale/locale.alias", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=2582, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 read(3, "# Locale name alias data base.\n#"..., 4096) = 2582 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40018000, 4096) = 0 sched_get_priority_max(SCHED_OTHER) = 0 sched_get_priority_min(SCHED_OTHER) = 0 pipe([3, 4]) = 0 clone(child_stack=0x1dff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 2235 write(4, "\330\244\1@\5\0\0\0\324*\2@\221\2\0\0\264H\2@\0\0\0\0\270"..., 148) = 148 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 write(4, "`\22\16@\0\0\0\0t\375\260\276\270\243\6@ \264\1\0\0\0\0"..., 148) = 148 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] <unfinished ...> --- SIGRTMIN (Unknown signal 32) @ 0 (0) --- <... rt_sigsuspend resumed> ) = 32 sigreturn() = ? (mask now [QUIT TRAP ABRT FPE USR2 TERM CONT SYS]) sched_get_priority_max(SCHED_OTHER) = 0 sched_get_priority_min(SCHED_OTHER) = 0 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 write(4, "`\22\16@\0\0\0\0t\375\260\276\270\243\6@\310\250\1\0\0"..., 148) = 148 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] <unfinished ...> --- SIGRTMIN (Unknown signal 32) @ 0 (0) --- <... rt_sigsuspend resumed> ) = 32 sigreturn() = ? (mask now [QUIT TRAP ABRT FPE USR2 TERM CONT SYS]) pipe([5, 6]) = 0 poll(usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 usb_os_init: Found USB VFS at /dev/bus/usb skipping descriptor 0x25 skipping descriptor 0x25 skipping descriptor 0x25 <unfinished ...> Could not delete PID file |
From: David B. <da...@ja...> - 2007-04-18 18:07:02
|
On Wed, 18 Apr 2007 17:51:41 +0200, xAD <xa...@xb...> wrote: > Yes, AVRUsb, i have used a Vendor-ID/Product-ID only for personal use, > this is only a prototype ;-D > > AVRUsb: http://www.obdev.at/products/avrusb/index.html > > but you know it. Yes I found these software implementations around 2 years ago thinking we could use that for tux but I didn't know anything about USB at that time (still don't know much but have a better feeling). There was the Igor version and a C version ongoing which is probably the current AVR-USB. They improved the website though :-) We finally choosed the AT89C5130 as it was cheap and could support USB in hardware. But now there are a few cheap USB AVR recently released (AT90USB82 AT90USB162) which look interesting. david |
From: xAD <xa...@xb...> - 2007-04-18 15:51:58
|
Yes, AVRUsb, i have used a Vendor-ID/Product-ID only for personal use, this is only a prototype ;-D AVRUsb: http://www.obdev.at/products/avrusb/index.html but you know it. On Wed, 2007-04-18 at 16:51 +0200, David Bourgeois wrote: > On Wed, 18 Apr 2007 14:36:18 +0200, xAD <xa...@xb...> wrote: > > > I have made a simple Power Switch via USB (i have used the open-source > > usb lib for Atmel) and with Perl GTK i test the gui for debugging. > > You mean the software USB implementation? > > > > > > > - About Email/Clock Interface without the fix the apps freez ;-D i > > looking for a SVN commit. > > It's been fixed, I guess they'll update svn tomorrow. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ tux-droid-user mailing list tux...@li... https://lists.sourceforge.net/lists/listinfo/tux-droid-user |
From: David B. <da...@ja...> - 2007-04-18 14:53:39
|
The daemon and the api have been tagged as new versions so the trunks are free again. Let's patch :D |
From: David B. <da...@ja...> - 2007-04-18 14:51:23
|
On Wed, 18 Apr 2007 14:36:18 +0200, xAD <xa...@xb...> wrote: > I have made a simple Power Switch via USB (i have used the open-source > usb lib for Atmel) and with Perl GTK i test the gui for debugging. You mean the software USB implementation? > > > - About Email/Clock Interface without the fix the apps freez ;-D i > looking for a SVN commit. It's been fixed, I guess they'll update svn tomorrow. |
From: Florent T. <ft...@gm...> - 2007-04-18 12:40:21
|
> > I have made a simple Power Switch via USB (i have used the open-source usb > lib for Atmel) > I want one :) Your tux can fire your coffee machine.... |
From: David B. <da...@ja...> - 2007-04-18 12:01:41
|
Mine is still in the box, no time to play with it :( |
From: David B. <da...@ja...> - 2007-04-18 11:00:03
|
On Wed, 18 Apr 2007 01:42:19 +0200, xAD <xa...@xb...> wrote: > Hi all, > > I'm David , i have received today the TuxDroid .. i'm a developer and i > love it ;-D Welcome David, I've seen from the pictures on your blog that you're playing with USB stuff. Just for fun? What CPU do you use? > this is a fix for email and clock gui , both apps crash A new release of tuxsetup will be done very shortly now I guess (normally tomorrow) and as they spent quite some time testing it, I hope they found this already though there's nothing committed on svn. > this is a easy script for run tuxTTSdaemon and TuxDaemon > via /etc/init.d/ We also recently added support for udev to launch the 2 daemons when the dongle is plugged and the daemons exit themselves when the dongle is removed. (There's some information in the bug tracker about this and it should be part of the next tuxsetup release. I'll also add some information in the manual install notes.) Cheers, david - the other one ;-) |
From: Florent T. <ft...@gm...> - 2007-04-18 08:43:09
|
Thanks for your report! Glad to see that most of it is working... I'm adding it ot the wiki NAS article. > * running tuxdaemon *FAIL* > o USB part seems ok (displays tux events properly) but not TCP > part, seems not to be listening on port Could you please give an strace output? > * compiling tuxup *OK* > * compiling dfu-programmer *OK* > * compiling svncrev *OK* > * compiling tuxcore tuxaudio *OK* > * flashing tuxcore.hex tuxcore.eep tuxaudio.hex tuxaudio.eep *OK* Well, that you can always do on your destkop... > * sound *PARTLY* > o ALSA and OSS-emulation layers are up > o tests with mpg321 and aplay: the sound is quite hashed and > lot of "alsa underrun" msgs, slightly better results through > oss than alsa > o recording at 8000 Hz mono is very poor (played on host) > o playing at 8000 Hz mono is poor (recorded on host) > o madplay -b8 -R8000 ...mp3 is correct > > Note that madplay is a fixed point mp3 player. Aow, i guess this will be the hard part :( |
From: xAD <xa...@xb...> - 2007-04-17 23:42:30
|
Hi all, I'm David , i have received today the TuxDroid .. i'm a developer and i love it ;-D My photo of the tux: http://www.tuxisalive.com/author/xad this is a fix for email and clock gui , both apps crash (on_bt_cancel_clicked and window1_destroy) if used with the latest SVN code (tuxdaemon) fix for both : cut out: tux.disconnect_from_daemon() and paste: tux.destroy() - this is a easy script for run tuxTTSdaemon and TuxDaemon via /etc/init.d/ (Debian) TUXTTSDAEMON: #! /bin/sh DAEMON=/usr/local/bin/tuxttsdaemon NAME=tttsdaemon DESC="TuxDroid TTS Daemon" . /lib/lsb/init-functions test -x $DAEMON || exit 0 case "$1" in start) $DAEMON -d ;; stop) killproc $DAEMON ;; reload|force-reload|restart) killproc $DAEMON sleep 1 $DAEMON -d ;; *) N=/etc/init.d/$NAME echo "Usage: $N {start|stop|restart|reload| force-reload}" >&2 retval=2 ;; esac exit $retval TUXDAEMON: #! /bin/sh DAEMON=/usr/local/bin/tuxdaemon NAME=tdaemon DESC="TuxDroid Daemon" . /lib/lsb/init-functions test -x $DAEMON || exit 0 case "$1" in start) $DAEMON -d ;; stop) killall -q -9 $DAEMON ;; reload|force-reload|restart) killall -q -9 $DAEMON sleep 1 $DAEMON -d ;; *) N=/etc/init.d/$NAME echo "Usage: $N {start|stop|restart|reload| force-reload}" >&2 retval=2 ;; esac exit $retval |
From: Philippe T. <ph...@te...> - 2007-04-17 22:08:07
|
Hi all, I got my NSLU2 yesterday so I couldn't resist. (http://en.wikipedia.org/wiki/NSLU2 if you don't know what's about) First I installed Debian on it this evening. Then I tried the various tuxdroid bits. Here are the very first conclusions: * compiling tuxdaemon *OK* * running tuxdaemon *FAIL* o USB part seems ok (displays tux events properly) but not TCP part, seems not to be listening on port * compiling tuxup *OK* * compiling dfu-programmer *OK* * compiling svncrev *OK* * compiling tuxcore tuxaudio *OK* * flashing tuxcore.hex tuxcore.eep tuxaudio.hex tuxaudio.eep *OK* * sound *PARTLY* o ALSA and OSS-emulation layers are up o tests with mpg321 and aplay: the sound is quite hashed and lot of "alsa underrun" msgs, slightly better results through oss than alsa o recording at 8000 Hz mono is very poor (played on host) o playing at 8000 Hz mono is poor (recorded on host) o madplay -b8 -R8000 ...mp3 is correct Note that madplay is a fixed point mp3 player. So we can compile and flash the tux, try to get audio running better and we definitively need to work on the daemon part. Of course I couldn't try the tts daemon. BTW does Acapela allow you to compile on ARM with your current agreements and does it support fixed point mode? Phil |
From: David B. <da...@ja...> - 2007-04-16 19:42:41
|
On Mon, 16 Apr 2007 19:32:08 +0200, Damien <ror...@gm...> wrote: > Le lundi 16 avril 2007, > "David Bourgeois" <da...@ja...> a écrit : > [...] >> reason. Anybody else got that problem? As soon as he could fix that, > > No such problem here. Well, didn't get it myself neither :-) I'll check again with Rémi tomorrow and push for the release. |
From: David B. <da...@ja...> - 2007-04-16 19:11:27
|
I just added a new tracker issue about the control of the led's when the eyes are closed. iirc there've been some questions about that here and we now found what happens. There's a flag masking the blue led's so they won't light when the eyes are closed, tux looks better that way. The mask is applied when the close command is issued (store the state) and removed (restore the state) when the open command is issued. There are 2 problems: 1. the status of the led's can be changed when the eyes are closed but will be lost when they reopen because of the restore function; 2. if the eyes reopen without the open command, like when moving the mouth, the mask will not be removed and the led's won't change until you issue some eyes commands. Steps to reproduce: - close the eyes - ove the mouth, most tux will reopen the eyes automatically at that time - try to toggle the led's, it won't work I'll fix that in the next release, there start to be a few improvements to do so I'll spend some time reworking the firmware soon. david |
From: Damien <ror...@gm...> - 2007-04-16 17:32:16
|
Le lundi 16 avril 2007, "David Bourgeois" <da...@ja...> a =C3=A9crit : =20 [...] > reason. Anybody else got that problem? As soon as he could fix that, No such problem here. > So it's probably better to wait for his tag before applying the > indent changes otherwise they'll have to test everything again. I'll > keep you posted with the release status in order to apply that patch. Ack. Damien |
From: Philippe T. <ph...@te...> - 2007-04-16 16:32:50
|
> I know Rémi is having some problems now with the trunk, he told me the > daemon sometimes quit. Don't know if that comes from a recent patch or a > bug lying there that didn't show up before for any reason. Anybody else > got that problem? As soon as he could fix that, he'll do the release. Nope. Only the ttsdaemon eating all my CPU sometimes. If Rémi manages to reproduce the bug he can post the steps so can can try out too. > So it's probably better to wait for his tag before applying the indent > changes otherwise they'll have to test everything again. I'll keep you > posted with the release status in order to apply that patch. Sir yes sir! Phil |
From: David B. <da...@ja...> - 2007-04-16 10:46:44
|
On Sun, 15 Apr 2007 13:15:19 +0200, Philippe Teuwen <ph...@te...> wrote: > After some discussions with neimad, here is a proposed set > of options for indent. Sounds good to me, glad also to discover that great tool :-) Now there's a tuxsetup release planned for this week (well, already planned 2 weeks ago...) and that will include all stuff that we have now on svn. I know they're testing it now, there've been some great contributions since the first beta and they want to be sure it somehow works for the newbies that are going to use tuxsetup a bit blindly. I know Rémi is having some problems now with the trunk, he told me the daemon sometimes quit. Don't know if that comes from a recent patch or a bug lying there that didn't show up before for any reason. Anybody else got that problem? As soon as he could fix that, he'll do the release. So it's probably better to wait for his tag before applying the indent changes otherwise they'll have to test everything again. I'll keep you posted with the release status in order to apply that patch. cheers, david |
From: David B. <da...@ja...> - 2007-04-16 10:28:11
|
On Sat, 14 Apr 2007 16:48:08 +0200, Damien <ror...@gm...> wrote: > Le samedi 14 avril 2007, > Philippe Teuwen <ph...@te...> a écrit : > >> Sometimes the refresh of the GUI doesn't happen, I can click and the >> tux reacts but the gui is not updated. >> When it happens, it happens from the start of the launch of gtdi, >> sometimes frozen with still the red cross on the ttsdaemon status. > > Haven't witnessed this, but I didn't use gtdi much lately. > >> If I click on radio button flips down, it does down,up,down >> If I click on radio button flips up, it does up,down,up,down,small >> pause,up >> If I click flap (1), it does up+down or down+up so 2 >> movements (compared to 1 talk or 1 blink) > > Same bug here. It's not a bug, it's a feature ;-) Short story: To use the flippers, the API should keep track of their position. So if they're low, you move them one time to get them up. It seems the API now uses the reset function to set the position to low, then move one more time to set it high. Long story: There are 3 flipper functions in tux's firmware: stop_wings, wave_wings and reset_wings. The reset is the only one that sets the position of the flippers to a defined state. The position of the flippers is not known inside tux because there's just one switch which is pushed each time the flipper position is toggled, it doesn't tell the absolute position. Now if I run the flipper motor, the time it takes to raise the wings is longer than to lower them (or the opposite) so the reset function uses that, runs the motor, measures the delays to get the absolute position and sets the flippers low. The reset function is called when you power tux in order to always start in the low poition. I plan to add a status that will do it's best to track the absolute wing position but that's a bit more complex than simply toggling a bit when the switch is pressed. When the wings are stopped, usually the switch is pressed or just release. As soon as you push on the flippers manually, the switch may toggle a couple of times as the wings are moving. Moving the flippers manually or triggering the clutch when the motor is running by holding the flippers will also corrupt the position. So we could momentarily change the API but the long term solution will come from new firmware functions to raise/lower the flippers and send back their absolute position. I plan to do some work on the firmware next week when I'll come back at the lab. david |
From: Srikanta P. <sri...@gm...> - 2007-04-15 16:10:31
|
Perfect! Except, imho, I feel -ncdw is not needed. I feel, } while () is natural, though, I can live if it is done otherwise too :-) On 4/15/07, Philippe Teuwen <ph...@te...> wrote: > Hi all, > > After some discussions with neimad, here is a proposed set > of options for indent. > This defines most of the current coding style of the major part > of the code so if nobody objects, we'll run indent against > all the current svn code, at least the C files, to fix the other > parts not yet coding-style compliant. > > Look at the man page of indent for the option description. > > indent > -nut > -i4 > -bad > -bap > -bbb > -sob > -sc > -bl > -cli0 > -cbi4 > -nce > -ncdw > -ss > -bls > -npsl > -npcs > -bli0 > -ncs > -nprs > -saf > -sai > -saw > > Phil > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > tux-droid-user mailing list > tux...@li... > https://lists.sourceforge.net/lists/listinfo/tux-droid-user > |
From: Philippe T. <ph...@te...> - 2007-04-15 11:19:49
|
I forgot also: -l80 |
From: Philippe T. <ph...@te...> - 2007-04-15 11:15:42
|
Hi all, After some discussions with neimad, here is a proposed set of options for indent. This defines most of the current coding style of the major part of the code so if nobody objects, we'll run indent against all the current svn code, at least the C files, to fix the other parts not yet coding-style compliant. Look at the man page of indent for the option description. indent -nut -i4 -bad -bap -bbb -sob -sc -bl -cli0 -cbi4 -nce -ncdw -ss -bls -npsl -npcs -bli0 -ncs -nprs -saf -sai -saw Phil |