| Refresh |
This website lore-kernel.gnuweeb.org/all/453FC4C0.5070105@domain.hid/t/ is currently offline. Cloudflare\'s Always Online™ shows a snapshot of this web page from the Internet Archive\'s Wayback Machine. To check for the live version, click Refresh. |
* [Xenomai-core] Xenomai v2.2.4 @ 2006-10-15 21:32 Philippe Gerum 2006-10-25 20:10 ` [Xenomai-help] switchtest and Xenomai 2.2.4 Jeff Webb 0 siblings, 1 reply; 15+ messages in thread From: Philippe Gerum @ 2006-10-15 21:32 UTC (permalink / raw) To: xenomai Here is the fourth maintenance release for the v2.2.x branch. Short log follows: [nucleus] * Raise XNBREAK as required when resuming a forcibly suspended shadow thread upon Linux signal receipt. * Rework the watchdog implementation, so that it does not depend on the Linux tick to be relayed through the nucleus (e.g. CONFIG_X86_LOCAL_APIC). Export the watchdog status to /proc/xenomai/timer. * Fix __xn_copy_from/to_user() so that none of their arguments could be shadowed by the internal variable used to hold the return value. This issue affects _all_ architectures. * x86: partially revert commit #1595 to fix FPU management regression issues that surfaced in 2.2.3. Fix CONFIG_PCI_MSI issue by upgrading to Adeos 2.6.17-1.5-00. * blackfin: Sync with Blackfin's CVS head as of 2006-10-08. [hal] * powerpc: Fix computation of periodic tick value to prevent 32bit arithmetic overflow. Add Adeos support for Linux 2.6.18. * blackfin: Upgrade generic Adeos support to the latest release. * arm: Fix syscall propagation issue with previous Adeos 1.5-00 release. [uvm] * Iron context switch emulation to prevent spurious wakeups upon Linux signal receipts. [posix] * Add missing wrapper to __real_pthread_getschedparam(). [rtdm] * Fix return value from copy_to/from_user(). [psos] * Fix size information passed to internal msgQLib routines. * Reschedule after task mode change (t_mode). As a sidenote, you will notice that the latest Adeos patches for i386, powerpc and Blackfin are bigger than they used to; this is due to the integration of the I-pipe tracer feature into the standard Adeos support, that used to live in a separate patch up to now. This feature is currently forcibly disabled for the Blackfin architecture though, since it is not fully functional yet, but this should improve with the next releases. See the ChangeLog for details. http://download.gna.org/xenomai/stable/xenomai-2.2.4.tar.bz2 -- Philippe. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-15 21:32 [Xenomai-core] Xenomai v2.2.4 Philippe Gerum @ 2006-10-25 20:10 ` Jeff Webb 2006-10-25 23:43 ` Jeff Webb ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Jeff Webb @ 2006-10-25 20:10 UTC (permalink / raw) To: xenomai When I upgraded to Xenomai 2.2.4, I tried the switchtest program: cd /usr/xenomai/testsuite/switchtest ./run The program appeared to run properly, but <ctrl>-c would not stop the application. I was not able to kill the process cleanly, and /proc/xenomai/stat showed lots of processes still running. The other tests (latency, cyclic, switchbench) and the program I am developing seem to work normally. I have not experienced this problem with previous versions of Xenomai. System details: adeos-ipipe-2.6.17-i386-1.5-00.patch Linux version 2.6.17.13 AMD Athlon(tm)64 X2 Dual Core Processor 4400+ Fedora Core 5 SMP kernel Is there anything I can do to help find the problem? Thanks, Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-25 20:10 ` [Xenomai-help] switchtest and Xenomai 2.2.4 Jeff Webb @ 2006-10-25 23:43 ` Jeff Webb 2006-10-26 8:21 ` Gilles Chanteperdrix 2006-10-26 7:35 ` Gilles Chanteperdrix [not found] ` <454078AD.5000907@domain.hid> 2 siblings, 1 reply; 15+ messages in thread From: Jeff Webb @ 2006-10-25 23:43 UTC (permalink / raw) To: xenomai Jeff Webb wrote: > When I upgraded to Xenomai 2.2.4, I tried the switchtest program: > > cd /usr/xenomai/testsuite/switchtest > ./run > > The program appeared to run properly, but <ctrl>-c would not stop the > application. I was not able to kill the process cleanly, and > /proc/xenomai/stat showed lots of processes still running. I get the same result with svn trunk (rev 1749) plus this FPU patch: https://mail.gna.org/public/xenomai-core/2006-10/msg00069.html I think the bug may be SMP related. When I press <ctrl>-c the first time, I see no more references to CPU 0. When I press <ctrl>-c a second time, all output stops. I have attached the output below. Thanks, Jeff [root switchtest]# ./run * * * Type ^C to stop this application. * * == Testing FPU check routines... r0: 1 != 2 r1: 1 != 2 r2: 1 != 2 r3: 1 != 2 r4: 1 != 2 r5: 1 != 2 r6: 1 != 2 r7: 1 != 2 == FPU check routines: OK. == Threads: sleeper_ufps0-0 rtk0-1 rtk0-2 rtk_fp0-3 rtk_fp0-4 rtk_fp_ufpp0-5 rtk_fp_ufpp0-6 rtup0-7 rtup0-8 rtup_ufpp0-9 rtup_ufpp0-10 rtus0-11 rtus0-12 rtus_ufps0-13 rtus_ufps0-14 rtuo0-15 rtuo0-16 rtuo_ufpp0-17 rtuo_ufpp0-18 rtuo_ufps0-19 rtuo_ufps0-20 rtuo_ufpp_ufps0-21 rtuo_ufpp_ufps0-22 sleeper_ufps1-0 rtk1-1 rtk1-2 rtk_fp1-3 rtk_fp1-4 rtk_fp_ufpp1-5 rtk_fp_ufpp1-6 rtup1-7 rtup1-8 rtup_ufpp1-9 rtup_ufpp1-10 rtus1-11 rtus1-12 rtus_ufps1-13 rtus_ufps1-14 rtuo1-15 rtuo1-16 rtuo_ufpp1-17 rtuo_ufpp1-18 rtuo_ufps1-19 rtuo_ufps1-20 rtuo_ufpp_ufps1-21 rtuo_ufpp_ufps1-22 RTT| 00:00:01 RTH|---------cpu|ctx switches|-------total RTD| 1| 5750| 5750 RTD| 0| 5704| 5704 RTD| 1| 5773| 11523 RTD| 0| 5750| 11454 RTD| 1| 5773| 17296 RTD| 0| 5750| 17204 RTD| 1| 5773| 23069 RTD| 0| 5750| 22954 RTD| 1| 5773| 28842 RTD| 0| 5750| 28704 RTD| 1| 5773| 34615 RTD| 0| 5750| 34454 RTD| 1| 5773| 40388 RTD| 0| 5750| 40204 RTD| 0| 5750| 45954 RTD| 1| 5773| 46161 RTD| 1| 5773| 51934 RTD| 0| 5750| 51704 RTD| 1| 5773| 57707 RTD| 0| 5750| 57454 RTD| 1| 5773| 63480 RTT| 00:00:11 RTH|---------cpu|ctx switches|-------total RTD| 0| 5750| 63204 RTD| 1| 5773| 69253 RTD| 0| 5750| 68954 RTD| 1| 5773| 75026 RTD| 0| 5750| 74704 RTD| 1| 5773| 80799 RTD| 0| 5750| 80454 RTD| 1| 5773| 86572 RTD| 0| 5750| 86204 RTD| 1| 5773| 92345 RTD| 1| 5773| 98118 RTD| 1| 5773| 103891 RTD| 1| 5773| 109664 RTD| 1| 5773| 115437 RTD| 1| 5773| 121210 RTD| 1| 5773| 126983 RTD| 1| 5773| 132756 RTD| 1| 5773| 138529 RTD| 1| 5773| 144302 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-25 23:43 ` Jeff Webb @ 2006-10-26 8:21 ` Gilles Chanteperdrix 2006-10-26 15:51 ` Jeff Webb 0 siblings, 1 reply; 15+ messages in thread From: Gilles Chanteperdrix @ 2006-10-26 8:21 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai Jeff Webb wrote: > Jeff Webb wrote: > >> When I upgraded to Xenomai 2.2.4, I tried the switchtest program: >> >> cd /usr/xenomai/testsuite/switchtest >> ./run >> >> The program appeared to run properly, but <ctrl>-c would not stop the >> application. I was not able to kill the process cleanly, and >> /proc/xenomai/stat showed lots of processes still running. > > > I get the same result with svn trunk (rev 1749) plus this FPU patch: > > https://mail.gna.org/public/xenomai-core/2006-10/msg00069.html > > I think the bug may be SMP related. When I press <ctrl>-c the first > time, I see no more references to CPU 0. When I press <ctrl>-c a second > time, all output stops. I have attached the output below. > Are you using NPTL or Linuxthreads ? Could you tell us in what state the switchtest threads are when running ps and in /proc/xenomai/sched ? After the second Ctrl-C, are the threads still alive ? Since after the first Ctrl-C, CPU 0 switches are no longer displayed, the program probably started the cleanup correctly; if gdb does not tell you where the main thread is blocked, could you try adding some printfs in the main thread ? -- Gilles Chanteperdrix ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-26 8:21 ` Gilles Chanteperdrix @ 2006-10-26 15:51 ` Jeff Webb 2006-10-26 15:56 ` Gilles Chanteperdrix 0 siblings, 1 reply; 15+ messages in thread From: Jeff Webb @ 2006-10-26 15:51 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Gilles Chanteperdrix wrote: > After the first Ctrl-C that does not work, could you try and attach gdb > to see where the threads are stopped ? I tried to do this, but was unable to determine the stopping point using gdb. > Are you using NPTL or Linuxthreads ? I'm running a stock Fedora Core 5 configuration, so I think that means NPTL. > Could you tell us in what state the > switchtest threads are when running ps and in /proc/xenomai/sched ? > After the second Ctrl-C, are the threads still alive ? See the output below. > Since after the first Ctrl-C, CPU 0 switches are no longer displayed, > the program probably started the cleanup correctly; if gdb does not > tell you where the main thread is blocked, could you try adding some > printfs in the main thread ? I will try this next. Here is the process information while switchtest is running, but before I press ctrl-c: [root]# cat /proc/xenomai/stat CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 52285 0 01400080 98.5 ROOT/0 1 0 0 53287 0 01400080 98.5 ROOT/1 0 2723 1 1 0 00c00180 0.0 switchtest 0 0 0 5086 0 00000082 0.1 rtk1/0 0 0 0 5086 0 00000082 0.1 rtk2/0 0 0 0 5086 0 00400082 0.1 rtk3/0 0 0 0 5086 0 00400082 0.1 rtk4/0 0 0 0 5086 0 00400082 0.1 rtk5/0 0 0 0 5086 0 00400082 0.1 rtk6/0 0 2725 3 3 0 00c00180 0.0 rtup0-7 0 2726 3 3 0 00c00180 0.0 rtup0-8 0 2727 3 3 0 00c00180 0.0 rtup_ufpp0-9 0 2728 3 3 0 00c00180 0.0 rtup_ufpp0-10 0 2729 2 5088 0 00c00082 0.1 rtus0-11 0 2730 2 5088 0 00c00082 0.1 rtus0-12 0 2731 2 5088 0 00c00082 0.1 rtus_ufps0-13 0 2732 2 5088 0 00c00082 0.1 rtus_ufps0-14 0 2733 2545 5087 0 00c00180 0.1 rtuo0-15 0 2734 2545 5087 0 00c00180 0.1 rtuo0-16 0 2735 2545 5087 0 00c00180 0.1 rtuo_ufpp0-17 0 2736 2545 5087 0 00c00180 0.1 rtuo_ufpp0-18 0 2737 2545 5087 0 00c00180 0.1 rtuo_ufps0-19 0 2738 2545 5087 0 00c00180 0.1 rtuo_ufps0-20 0 2739 2545 5087 0 00c00180 0.1 rtuo_ufpp_ufps0-21 0 2740 2545 5087 0 00c00180 0.1 rtuo_ufpp_ufps0-22 1 0 0 5184 0 00000082 0.1 rtk1/1 1 0 0 5184 0 00000082 0.1 rtk2/1 1 0 0 5184 0 00400082 0.1 rtk3/1 1 0 0 5184 0 00400082 0.1 rtk4/1 1 0 0 5184 0 00400082 0.1 rtk5/1 1 0 0 5184 0 00400082 0.1 rtk6/1 1 2742 3 3 0 00c00180 0.0 rtup1-7 1 2743 3 3 0 00c00180 0.0 rtup1-8 1 2744 3 3 0 00c00180 0.0 rtup_ufpp1-9 1 2745 3 3 0 00c00180 0.0 rtup_ufpp1-10 1 2746 2 5186 0 00c00082 0.1 rtus1-11 1 2747 2 5186 0 00c00082 0.1 rtus1-12 1 2748 2 5186 0 00c00082 0.1 rtus_ufps1-13 1 2749 2 5186 0 00c00082 0.1 rtus_ufps1-14 1 2750 2594 5185 0 00c00180 0.1 rtuo1-15 1 2751 2594 5185 0 00c00180 0.1 rtuo1-16 1 2752 2594 5185 0 00c00180 0.1 rtuo_ufpp1-17 1 2753 2594 5185 0 00c00180 0.1 rtuo_ufpp1-18 1 2754 2594 5185 0 00c00180 0.1 rtuo_ufps1-19 1 2755 2594 5185 0 00c00180 0.1 rtuo_ufps1-20 1 2756 2594 5185 0 00c00180 0.1 rtuo_ufpp_ufps1-21 1 2757 2594 5185 0 00c00180 0.1 rtuo_ufpp_ufps1-22 [root]# ps a -T PID SPID TTY STAT TIME COMMAND 2656 2656 pts/0 S+ 0:00 /bin/sh /usr/xenomai/bin/xeno-load 2679 2679 pts/0 S+ 0:00 /bin/sh /usr/xenomai/bin/xeno-load 2723 2723 pts/0 SLl+ 0:00 ./switchtest 2723 2724 pts/0 SLl+ 0:00 ./switchtest 2723 2725 pts/0 SLl+ 0:00 ./switchtest 2723 2726 pts/0 SLl+ 0:00 ./switchtest 2723 2727 pts/0 SLl+ 0:00 ./switchtest 2723 2728 pts/0 SLl+ 0:00 ./switchtest 2723 2729 pts/0 SLl+ 0:00 ./switchtest 2723 2730 pts/0 SLl+ 0:00 ./switchtest 2723 2731 pts/0 SLl+ 0:00 ./switchtest 2723 2732 pts/0 SLl+ 0:00 ./switchtest 2723 2733 pts/0 SLl+ 0:00 ./switchtest 2723 2734 pts/0 SLl+ 0:00 ./switchtest 2723 2735 pts/0 SLl+ 0:00 ./switchtest 2723 2736 pts/0 SLl+ 0:00 ./switchtest 2723 2737 pts/0 SLl+ 0:00 ./switchtest 2723 2738 pts/0 SLl+ 0:00 ./switchtest 2723 2739 pts/0 SLl+ 0:00 ./switchtest 2723 2740 pts/0 SLl+ 0:00 ./switchtest 2723 2741 pts/0 SLl+ 0:00 ./switchtest 2723 2742 pts/0 SLl+ 0:00 ./switchtest 2723 2743 pts/0 SLl+ 0:00 ./switchtest 2723 2744 pts/0 SLl+ 0:00 ./switchtest 2723 2745 pts/0 SLl+ 0:00 ./switchtest 2723 2746 pts/0 SLl+ 0:00 ./switchtest 2723 2747 pts/0 SLl+ 0:00 ./switchtest 2723 2748 pts/0 SLl+ 0:00 ./switchtest 2723 2749 pts/0 SLl+ 0:00 ./switchtest 2723 2750 pts/0 SLl+ 0:00 ./switchtest 2723 2751 pts/0 SLl+ 0:00 ./switchtest 2723 2752 pts/0 SLl+ 0:00 ./switchtest 2723 2753 pts/0 SLl+ 0:00 ./switchtest 2723 2754 pts/0 SLl+ 0:00 ./switchtest 2723 2755 pts/0 SLl+ 0:00 ./switchtest 2723 2756 pts/0 SLl+ 0:00 ./switchtest 2723 2757 pts/0 SLl+ 0:00 ./switchtest After I press ctrl-c once: [root]# cat /proc/xenomai/stat CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 158228 0 01400080 98.5 ROOT/0 1 0 0 174623 0 01400080 98.5 ROOT/1 0 2723 1 1 0 00c00180 0.0 switchtest 0 0 0 15399 0 00000082 0.1 rtk1/0 0 0 0 15399 0 00000082 0.1 rtk2/0 0 0 0 15399 0 00400082 0.1 rtk3/0 0 0 0 15399 0 00400082 0.1 rtk4/0 0 0 0 15399 0 00400082 0.1 rtk5/0 0 0 0 15399 0 00400082 0.1 rtk6/0 0 2729 2 15401 0 00c03088 0.1 rtus0-11 0 2730 2 15401 0 00c03088 0.1 rtus0-12 0 2731 2 15401 0 00c03088 0.1 rtus_ufps0-13 0 2732 2 15401 0 00c03088 0.1 rtus_ufps0-14 0 2733 7701 15400 0 00c03088 0.1 rtuo0-15 0 2734 7701 15400 0 00c03088 0.1 rtuo0-16 0 2735 7701 15400 0 00c03088 0.1 rtuo_ufpp0-17 0 2736 7701 15400 0 00c03088 0.1 rtuo_ufpp0-18 0 2737 7701 15400 0 00c03088 0.1 rtuo_ufps0-19 0 2738 7701 15400 0 00c03088 0.1 rtuo_ufps0-20 0 2739 7701 15400 0 00c03088 0.1 rtuo_ufpp_ufps0-21 0 2740 7701 15400 0 00c03088 0.1 rtuo_ufpp_ufps0-22 1 0 0 16995 0 00000082 0.1 rtk1/1 1 0 0 16995 0 00000082 0.1 rtk2/1 1 0 0 16995 0 00400082 0.1 rtk3/1 1 0 0 16995 0 00400082 0.1 rtk4/1 1 0 0 16995 0 00400082 0.1 rtk5/1 1 0 0 16995 0 00400082 0.1 rtk6/1 1 2742 3 3 0 00c00180 0.0 rtup1-7 1 2743 3 3 0 00c00180 0.0 rtup1-8 1 2744 3 3 0 00c00180 0.0 rtup_ufpp1-9 1 2745 3 3 0 00c00180 0.0 rtup_ufpp1-10 1 2746 2 16997 0 00c00082 0.1 rtus1-11 1 2747 2 16997 0 00c00082 0.1 rtus1-12 1 2748 2 16997 0 00c00082 0.1 rtus_ufps1-13 1 2749 2 16997 0 00c00082 0.1 rtus_ufps1-14 1 2750 8499 16996 0 00c00082 0.1 rtuo1-15 1 2751 8499 16996 0 00c00082 0.1 rtuo1-16 1 2752 8499 16996 0 00c00082 0.1 rtuo_ufpp1-17 1 2753 8499 16996 0 00c00082 0.1 rtuo_ufpp1-18 1 2754 8499 16996 0 00c00082 0.1 rtuo_ufps1-19 1 2755 8499 16996 0 00c00082 0.1 rtuo_ufps1-20 1 2756 8499 16996 0 00c00082 0.1 rtuo_ufpp_ufps1-21 1 2757 8499 16996 0 00c00082 0.1 rtuo_ufpp_ufps1-22 [root]# ps a -T PID SPID TTY STAT TIME COMMAND 2656 2656 pts/0 S+ 0:00 /bin/sh /usr/xenomai/bin/xeno-load 2679 2679 pts/0 S+ 0:00 /bin/sh /usr/xenomai/bin/xeno-load 2723 2723 pts/0 SLl+ 0:00 ./switchtest 2723 2729 pts/0 SLl+ 0:00 ./switchtest 2723 2730 pts/0 SLl+ 0:00 ./switchtest 2723 2731 pts/0 SLl+ 0:00 ./switchtest 2723 2732 pts/0 SLl+ 0:00 ./switchtest 2723 2733 pts/0 SLl+ 0:00 ./switchtest 2723 2734 pts/0 SLl+ 0:00 ./switchtest 2723 2735 pts/0 SLl+ 0:00 ./switchtest 2723 2736 pts/0 SLl+ 0:00 ./switchtest 2723 2737 pts/0 SLl+ 0:00 ./switchtest 2723 2738 pts/0 SLl+ 0:00 ./switchtest 2723 2739 pts/0 SLl+ 0:00 ./switchtest 2723 2740 pts/0 SLl+ 0:00 ./switchtest 2723 2741 pts/0 SLl+ 0:00 ./switchtest 2723 2742 pts/0 SLl+ 0:00 ./switchtest 2723 2743 pts/0 SLl+ 0:00 ./switchtest 2723 2744 pts/0 SLl+ 0:00 ./switchtest 2723 2745 pts/0 SLl+ 0:00 ./switchtest 2723 2746 pts/0 SLl+ 0:00 ./switchtest 2723 2747 pts/0 SLl+ 0:00 ./switchtest 2723 2748 pts/0 SLl+ 0:00 ./switchtest 2723 2749 pts/0 SLl+ 0:00 ./switchtest 2723 2750 pts/0 SLl+ 0:00 ./switchtest 2723 2751 pts/0 SLl+ 0:00 ./switchtest 2723 2752 pts/0 SLl+ 0:00 ./switchtest 2723 2753 pts/0 SLl+ 0:00 ./switchtest 2723 2754 pts/0 SLl+ 0:00 ./switchtest 2723 2755 pts/0 SLl+ 0:00 ./switchtest 2723 2756 pts/0 SLl+ 0:00 ./switchtest 2723 2757 pts/0 SLl+ 0:00 ./switchtest After I press ctrl-c a second time: [root]# cat /proc/xenomai/stat CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 158240 0 01400080 100.0 ROOT/0 1 0 0 249722 0 01400080 98.9 ROOT/1 0 0 0 15399 0 00000082 0.0 rtk1/0 0 0 0 15399 0 00000082 0.0 rtk2/0 0 0 0 15399 0 00400082 0.0 rtk3/0 0 0 0 15399 0 00400082 0.0 rtk4/0 0 0 0 15399 0 00400082 0.0 rtk5/0 0 0 0 15399 0 00400082 0.0 rtk6/0 1 0 0 24306 0 00000082 0.0 rtk1/1 1 0 0 24306 0 00000082 0.0 rtk2/1 1 0 0 24306 0 00400082 0.0 rtk3/1 1 0 0 24306 0 00400082 0.0 rtk4/1 1 0 0 24306 0 00400082 0.0 rtk5/1 1 0 0 24306 0 00400082 0.0 rtk6/1 1 2747 2 24308 0 00c03088 0.1 rtus1-12 1 2748 2 24308 0 00c03088 0.1 rtus_ufps1-13 1 2749 2 24308 0 00c03088 0.1 rtus_ufps1-14 [root]# ps a -T PID SPID TTY STAT TIME COMMAND 2656 2656 pts/0 S+ 0:00 /bin/sh /usr/xenomai/bin/xeno-load 2679 2679 pts/0 S+ 0:00 /bin/sh /usr/xenomai/bin/xeno-load 2723 2723 pts/0 Zl+ 0:00 [switchtest] <defunct> 2723 2747 pts/0 SLl+ 0:00 [switchtest] 2723 2748 pts/0 SLl+ 0:00 [switchtest] 2723 2749 pts/0 SLl+ 0:00 [switchtest] 2765 2765 pts/1 R+ 0:00 ps a -T ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-26 15:51 ` Jeff Webb @ 2006-10-26 15:56 ` Gilles Chanteperdrix 2006-10-26 16:44 ` Jeff Webb 0 siblings, 1 reply; 15+ messages in thread From: Gilles Chanteperdrix @ 2006-10-26 15:56 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai Jeff Webb wrote: > Gilles Chanteperdrix wrote: > >> After the first Ctrl-C that does not work, could you try and attach gdb >> to see where the threads are stopped ? > > > I tried to do this, but was unable to determine the stopping point using > gdb. type simply: "info threads" then change thread to the main thread with "thread x", where x is the lowest thread id as listed by "info threads" then type: "backtrace" > >> Are you using NPTL or Linuxthreads ? > > > I'm running a stock Fedora Core 5 configuration, so I think that means > NPTL. > >> Could you tell us in what state the >> switchtest threads are when running ps and in /proc/xenomai/sched ? >> After the second Ctrl-C, are the threads still alive ? > > > See the output below. /proc/xenomai/sched gives an information on the status that is easier to understand. -- Gilles Chanteperdrix ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-26 15:56 ` Gilles Chanteperdrix @ 2006-10-26 16:44 ` Jeff Webb 2006-10-26 16:55 ` Jan Kiszka 0 siblings, 1 reply; 15+ messages in thread From: Jeff Webb @ 2006-10-26 16:44 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai Gilles Chanteperdrix wrote: > Jeff Webb wrote: >> Gilles Chanteperdrix wrote: >> >>> After the first Ctrl-C that does not work, could you try and attach gdb >>> to see where the threads are stopped ? >> >> >> I tried to do this, but was unable to determine the stopping point >> using gdb. > > type simply: "info threads" > then change thread to the main thread with "thread x", where x is the > lowest thread id as listed by "info threads" > then type: "backtrace" If I try to connect to the process after I press the ctrl-c one time, I get: # gdb --pid=2660 Attaching to process 2660 warning: The current VSYSCALL page code requires an existing excuitable. [sic] Use "add-symbol-file-from-memory" to load the VSYSCALL page by hand Then the whole machine locks up, and I am forced to reboot. I am able to connect before I press ctrl-c: (gdb) thread 1 [Switching to thread 1 (Thread -1208273216 (LWP 2634))]#0 0xffffe410 in ?? () (gdb) backtrace #0 0xffffe410 in ?? () #1 0xbfd96294 in ?? () #2 0x00000000 in ?? () (gdb) c Continuing. Then I type ctrl-c, and the machine locks up, as before. The machine does not lock up, if I am not connected via gdb. > /proc/xenomai/sched gives an information on the status that is easier to > understand. Before pressing ctrl-c: $ cat /proc/xenomai/sched CPU PID PRI PERIOD TIMEOUT STAT NAME 0 0 -1 0 0 R ROOT/0 1 0 -1 0 0 R ROOT/1 0 2641 0 0 0 X switchtest 0 0 1 0 0 W rtk1/0 0 0 1 0 0 W rtk2/0 0 0 1 0 0 Wf rtk3/0 0 0 1 0 0 Wf rtk4/0 0 0 1 0 0 Wf rtk5/0 0 0 1 0 0 Wf rtk6/0 0 2643 1 0 0 X rtup0-7 0 2644 1 0 0 X rtup0-8 0 2645 1 0 0 X rtup_ufpp0-9 0 2646 1 0 0 X rtup_ufpp0-10 0 2647 1 0 0 W rtus0-11 0 2648 1 0 0 W rtus0-12 0 2649 1 0 0 W rtus_ufps0-13 0 2650 1 0 0 W rtus_ufps0-14 0 2651 1 0 0 X rtuo0-15 0 2652 1 0 0 X rtuo0-16 0 2653 1 0 0 X rtuo_ufpp0-17 0 2654 1 0 0 X rtuo_ufpp0-18 0 2655 1 0 0 X rtuo_ufps0-19 0 2656 1 0 0 X rtuo_ufps0-20 0 2657 1 0 0 X rtuo_ufpp_ufps0-21 0 2658 1 0 0 X rtuo_ufpp_ufps0-22 1 0 1 0 0 W rtk1/1 1 0 1 0 0 W rtk2/1 1 0 1 0 0 Wf rtk3/1 1 0 1 0 0 Wf rtk4/1 1 0 1 0 0 Wf rtk5/1 1 0 1 0 0 Wf rtk6/1 1 2660 1 0 0 X rtup1-7 1 2661 1 0 0 X rtup1-8 1 2662 1 0 0 X rtup_ufpp1-9 1 2663 1 0 0 X rtup_ufpp1-10 1 2664 1 0 0 W rtus1-11 1 2665 1 0 0 W rtus1-12 1 2666 1 0 0 W rtus_ufps1-13 1 2667 1 0 0 W rtus_ufps1-14 1 2668 1 0 0 W rtuo1-15 1 2669 1 0 0 W rtuo1-16 1 2670 1 0 0 W rtuo_ufpp1-17 1 2671 1 0 0 W rtuo_ufpp1-18 1 2672 1 0 0 W rtuo_ufps1-19 1 2673 1 0 0 W rtuo_ufps1-20 1 2674 1 0 0 W rtuo_ufpp_ufps1-21 1 2675 1 0 0 W rtuo_ufpp_ufps1-22 After pressing ctrl-c once: $ cat /proc/xenomai/sched CPU PID PRI PERIOD TIMEOUT STAT NAME 0 0 -1 0 0 R ROOT/0 1 0 -1 0 0 R ROOT/1 0 2641 0 0 0 X switchtest 0 0 1 0 0 W rtk1/0 0 0 1 0 0 W rtk2/0 0 0 1 0 0 Wf rtk3/0 0 0 1 0 0 Wf rtk4/0 0 0 1 0 0 Wf rtk5/0 0 0 1 0 0 Wf rtk6/0 0 2647 1 0 0 R rtus0-11 0 2648 1 0 0 R rtus0-12 0 2649 1 0 0 R rtus_ufps0-13 0 2650 1 0 0 R rtus_ufps0-14 0 2651 1 0 0 R rtuo0-15 0 2652 1 0 0 R rtuo0-16 0 2653 1 0 0 R rtuo_ufpp0-17 0 2654 1 0 0 R rtuo_ufpp0-18 0 2655 1 0 0 R rtuo_ufps0-19 0 2656 1 0 0 R rtuo_ufps0-20 0 2657 1 0 0 R rtuo_ufpp_ufps0-21 0 2658 1 0 0 R rtuo_ufpp_ufps0-22 1 0 1 0 0 W rtk1/1 1 0 1 0 0 W rtk2/1 1 0 1 0 0 Wf rtk3/1 1 0 1 0 0 Wf rtk4/1 1 0 1 0 0 Wf rtk5/1 1 0 1 0 0 Wf rtk6/1 1 2660 1 0 0 X rtup1-7 1 2661 1 0 0 X rtup1-8 1 2662 1 0 0 X rtup_ufpp1-9 1 2663 1 0 0 X rtup_ufpp1-10 1 2664 1 0 0 W rtus1-11 1 2665 1 0 0 W rtus1-12 1 2666 1 0 0 W rtus_ufps1-13 1 2667 1 0 0 W rtus_ufps1-14 1 2668 1 0 0 X rtuo1-15 1 2669 1 0 0 X rtuo1-16 1 2670 1 0 0 X rtuo_ufpp1-17 1 2671 1 0 0 X rtuo_ufpp1-18 1 2672 1 0 0 X rtuo_ufps1-19 1 2673 1 0 0 X rtuo_ufps1-20 1 2674 1 0 0 X rtuo_ufpp_ufps1-21 1 2675 1 0 0 X rtuo_ufpp_ufps1-22 After pressing ctrl-c twice: webb-ja@domain.hid:~$ cat /proc/xenomai/sched CPU PID PRI PERIOD TIMEOUT STAT NAME 0 0 -1 0 0 R ROOT/0 1 0 -1 0 0 R ROOT/1 0 0 1 0 0 W rtk1/0 0 0 1 0 0 W rtk2/0 0 0 1 0 0 Wf rtk3/0 0 0 1 0 0 Wf rtk4/0 0 0 1 0 0 Wf rtk5/0 0 0 1 0 0 Wf rtk6/0 1 0 1 0 0 W rtk1/1 1 0 1 0 0 W rtk2/1 1 0 1 0 0 Wf rtk3/1 1 0 1 0 0 Wf rtk4/1 1 0 1 0 0 Wf rtk5/1 1 0 1 0 0 Wf rtk6/1 1 2665 1 0 0 R rtus1-12 1 2666 1 0 0 R rtus_ufps1-13 1 2667 1 0 0 R rtus_ufps1-14 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-26 16:44 ` Jeff Webb @ 2006-10-26 16:55 ` Jan Kiszka 2006-10-26 18:53 ` Jeff Webb 0 siblings, 1 reply; 15+ messages in thread From: Jan Kiszka @ 2006-10-26 16:55 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai [-- Attachment #1: Type: text/plain, Size: 1056 bytes --] Jeff Webb wrote: > Gilles Chanteperdrix wrote: >> Jeff Webb wrote: >>> Gilles Chanteperdrix wrote: >>> >>>> After the first Ctrl-C that does not work, could you try and attach gdb >>>> to see where the threads are stopped ? >>> >>> >>> I tried to do this, but was unable to determine the stopping point >>> using gdb. >> >> type simply: "info threads" >> then change thread to the main thread with "thread x", where x is the >> lowest thread id as listed by "info threads" >> then type: "backtrace" > > If I try to connect to the process after I press the ctrl-c one time, I > get: > > # gdb --pid=2660 > Attaching to process 2660 > warning: The current VSYSCALL page code requires an existing excuitable. > [sic] Then why not trying to provide it? # gdb switchtest (gdb) r > Use "add-symbol-file-from-memory" to load the VSYSCALL page by hand > > Then the whole machine locks up, and I am forced to reboot. That's bad. Is the Xenomai watchdog active (if not, this might be some RT thread running wild)? Jan [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 250 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-26 16:55 ` Jan Kiszka @ 2006-10-26 18:53 ` Jeff Webb 0 siblings, 0 replies; 15+ messages in thread From: Jeff Webb @ 2006-10-26 18:53 UTC (permalink / raw) To: xenomai Jan Kiszka wrote: > Jeff Webb wrote: >> If I try to connect to the process after I press the ctrl-c one time, I >> get: >> >> # gdb --pid=2660 >> Attaching to process 2660 >> warning: The current VSYSCALL page code requires an existing excuitable. >> [sic] > > Then why not trying to provide it? The machine locks up, so I can't do anything after this point. Even the machine didn't crash, I don't understand what file it wants me to load with "add-symbol-file-from-memory". This may be a non-issue, though. Gilles has sent me some patches off list, and I think he is close to getting the program to clean up properly. Why my machine behaves differently than other people's, I don't know. No progress on the FPU/mqueue bug, though. >> Then the whole machine locks up, and I am forced to reboot. > > That's bad. Is the Xenomai watchdog active (if not, this might be some > RT thread running wild)? The watchdog is not enabled. I will turn it on for the next build. -Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-25 20:10 ` [Xenomai-help] switchtest and Xenomai 2.2.4 Jeff Webb 2006-10-25 23:43 ` Jeff Webb @ 2006-10-26 7:35 ` Gilles Chanteperdrix [not found] ` <454078AD.5000907@domain.hid> 2 siblings, 0 replies; 15+ messages in thread From: Gilles Chanteperdrix @ 2006-10-26 7:35 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai Jeff Webb wrote: > Is there anything I can do to help find the problem? After the first Ctrl-C that does not work, could you try and attach gdb to see where the threads are stopped ? -- Gilles Chanteperdrix ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <454078AD.5000907@domain.hid>]
[parent not found: <4540DE60.40209@domain.hid>]
[parent not found: <4540E1AB.2040200@domain.hid>]
[parent not found: <4540EABD.10403@domain.hid>]
[parent not found: <4540ECA6.5000604@domain.hid>]
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 [not found] ` <4540ECA6.5000604@domain.hid> @ 2006-10-26 19:49 ` Jeff Webb 2006-10-27 8:18 ` Gilles Chanteperdrix 0 siblings, 1 reply; 15+ messages in thread From: Jeff Webb @ 2006-10-26 19:49 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai help Gilles Chanteperdrix wrote: > In the file ksrc/drivers/testing/switchtest.c, try commenting the calls > to try_module_get and module_put. You will need to recompile kernel > space support. I am afraid the module counter is decreased several times > when close is called several times, so we basically screw it up. > > The attached patch also closes the file descriptors only once the > threads are joined. It looks like this did the trick. After commenting out the try_module_get/module_put calls and applying your latest patch to switchtest.c, switchtest appears to be working properly once again. Thanks, Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-26 19:49 ` Jeff Webb @ 2006-10-27 8:18 ` Gilles Chanteperdrix 2006-10-27 14:45 ` Jeff Webb 0 siblings, 1 reply; 15+ messages in thread From: Gilles Chanteperdrix @ 2006-10-27 8:18 UTC (permalink / raw) To: Jeff Webb; +Cc: Xenomai help [-- Attachment #1: Type: text/plain, Size: 899 bytes --] Jeff Webb wrote: > Gilles Chanteperdrix wrote: > >> In the file ksrc/drivers/testing/switchtest.c, try commenting the calls >> to try_module_get and module_put. You will need to recompile kernel >> space support. I am afraid the module counter is decreased several >> times when close is called several times, so we basically screw it up. >> >> The attached patch also closes the file descriptors only once the >> threads are joined. > > > It looks like this did the trick. After commenting out the > try_module_get/module_put calls and applying your latest patch to > switchtest.c, switchtest appears to be working properly once again. Ok, could you try one last thing: keep try_module_get and module_put in ksrc/drivers/testing/switchtest.c and apply the attached patch to src/testsuite/switchtest/switchtest.c -- Gilles Chanteperdrix [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: xeno-switchtest-join-after-cancel-all.4.diff --] [-- Type: text/x-patch; name="xeno-switchtest-join-after-cancel-all.4.diff", Size: 591 bytes --] Index: src/testsuite/switchtest/switchtest.c =================================================================== --- src/testsuite/switchtest/switchtest.c (révision 1749) +++ src/testsuite/switchtest/switchtest.c (copie de travail) @@ -1173,8 +1173,12 @@ if (param->type != RTK && param->thread) pthread_cancel(param->thread); } + } + + for (i = 0; i < nr_cpus; i ++) { + struct cpu_tasks *cpu = &cpus[i]; - /* join them. */ + /* join the user-space tasks. */ for (j = 0; j < cpu->tasks_count; j++) { struct task_params *param = &cpu->tasks[j]; ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-27 8:18 ` Gilles Chanteperdrix @ 2006-10-27 14:45 ` Jeff Webb 2006-10-27 15:05 ` Gilles Chanteperdrix 0 siblings, 1 reply; 15+ messages in thread From: Jeff Webb @ 2006-10-27 14:45 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai help Gilles Chanteperdrix wrote: > Ok, could you try one last thing: keep try_module_get and module_put in > ksrc/drivers/testing/switchtest.c and apply the attached patch to > src/testsuite/switchtest/switchtest.c This does not seem to fix the problem completely. Output stops after pressing ctrl-c one time, and I get: [root xeno-build-r1749p5]# ps a -T PID SPID TTY STAT TIME COMMAND 19878 19878 pts/1 SLl+ 0:00 ./switchtest 19878 19884 pts/1 SLl+ 0:00 ./switchtest 19878 19885 pts/1 SLl+ 0:00 ./switchtest 19878 19886 pts/1 SLl+ 0:00 ./switchtest 19878 19887 pts/1 SLl+ 0:00 ./switchtest [root xeno-build-r1749p5]# cat /proc/xenomai/sched CPU PID PRI PERIOD TIMEOUT STAT NAME 0 0 -1 0 0 R ROOT/0 1 0 -1 0 0 R ROOT/1 0 19878 0 0 0 X switchtest 0 0 1 0 0 W rtk1/0 0 0 1 0 0 W rtk2/0 0 0 1 0 0 Wf rtk3/0 0 0 1 0 0 Wf rtk4/0 0 0 1 0 0 Wf rtk5/0 0 0 1 0 0 Wf rtk6/0 0 19884 1 0 0 R rtus0-11 0 19885 1 0 0 R rtus0-12 0 19886 1 0 0 R rtus_ufps0-13 0 19887 1 0 0 R rtus_ufps0-14 1 0 1 0 0 W rtk1/1 1 0 1 0 0 W rtk2/1 1 0 1 0 0 Wf rtk3/1 1 0 1 0 0 Wf rtk4/1 1 0 1 0 0 Wf rtk5/1 1 0 1 0 0 Wf rtk6/1 After pressing ctrl-c a second time, switchtest exits leaving a clean 'ps', but I get: [root xeno-build-r1749p5]# cat /proc/xenomai/sched CPU PID PRI PERIOD TIMEOUT STAT NAME 0 0 -1 0 0 R ROOT/0 1 0 -1 0 0 R ROOT/1 0 0 1 0 0 W rtk1/0 0 0 1 0 0 W rtk2/0 0 0 1 0 0 Wf rtk3/0 0 0 1 0 0 Wf rtk4/0 0 0 1 0 0 Wf rtk5/0 0 0 1 0 0 Wf rtk6/0 1 0 1 0 0 W rtk1/1 1 0 1 0 0 W rtk2/1 1 0 1 0 0 Wf rtk3/1 1 0 1 0 0 Wf rtk4/1 1 0 1 0 0 Wf rtk5/1 1 0 1 0 0 Wf rtk6/1 Removing the module then fails: [root switchtest]# /sbin/rmmod xeno_switchtest ERROR: Module xeno_switchtest is in use [root switchtest]# I can run switchtest multiple times, but I get more and more leftover threads in /proc/xenomai/stat. -Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-27 14:45 ` Jeff Webb @ 2006-10-27 15:05 ` Gilles Chanteperdrix 2006-10-27 16:25 ` Jeff Webb 0 siblings, 1 reply; 15+ messages in thread From: Gilles Chanteperdrix @ 2006-10-27 15:05 UTC (permalink / raw) To: Jeff Webb; +Cc: xenomai Jeff Webb wrote: > Gilles Chanteperdrix wrote: > >> Ok, could you try one last thing: keep try_module_get and module_put in >> ksrc/drivers/testing/switchtest.c and apply the attached patch to >> src/testsuite/switchtest/switchtest.c > > > This does not seem to fix the problem completely. Output stops after > pressing ctrl-c one time, and I get: > > [root xeno-build-r1749p5]# ps a -T > PID SPID TTY STAT TIME COMMAND > 19878 19878 pts/1 SLl+ 0:00 ./switchtest > 19878 19884 pts/1 SLl+ 0:00 ./switchtest > 19878 19885 pts/1 SLl+ 0:00 ./switchtest > 19878 19886 pts/1 SLl+ 0:00 ./switchtest > 19878 19887 pts/1 SLl+ 0:00 ./switchtest > > [root xeno-build-r1749p5]# cat /proc/xenomai/sched > CPU PID PRI PERIOD TIMEOUT STAT NAME > 0 0 -1 0 0 R ROOT/0 > 1 0 -1 0 0 R ROOT/1 > 0 19878 0 0 0 X switchtest > 0 0 1 0 0 W rtk1/0 > 0 0 1 0 0 W rtk2/0 > 0 0 1 0 0 Wf rtk3/0 > 0 0 1 0 0 Wf rtk4/0 > 0 0 1 0 0 Wf rtk5/0 > 0 0 1 0 0 Wf rtk6/0 > 0 19884 1 0 0 R rtus0-11 > 0 19885 1 0 0 R rtus0-12 > 0 19886 1 0 0 R rtus_ufps0-13 > 0 19887 1 0 0 R rtus_ufps0-14 > 1 0 1 0 0 W rtk1/1 > 1 0 1 0 0 W rtk2/1 > 1 0 1 0 0 Wf rtk3/1 > 1 0 1 0 0 Wf rtk4/1 > 1 0 1 0 0 Wf rtk5/1 > 1 0 1 0 0 Wf rtk6/1 > > After pressing ctrl-c a second time, switchtest exits leaving a clean > 'ps', but I get: > > [root xeno-build-r1749p5]# cat /proc/xenomai/sched > CPU PID PRI PERIOD TIMEOUT STAT NAME > 0 0 -1 0 0 R ROOT/0 > 1 0 -1 0 0 R ROOT/1 > 0 0 1 0 0 W rtk1/0 > 0 0 1 0 0 W rtk2/0 > 0 0 1 0 0 Wf rtk3/0 > 0 0 1 0 0 Wf rtk4/0 > 0 0 1 0 0 Wf rtk5/0 > 0 0 1 0 0 Wf rtk6/0 > 1 0 1 0 0 W rtk1/1 > 1 0 1 0 0 W rtk2/1 > 1 0 1 0 0 Wf rtk3/1 > 1 0 1 0 0 Wf rtk4/1 > 1 0 1 0 0 Wf rtk5/1 > 1 0 1 0 0 Wf rtk6/1 > > Removing the module then fails: > > [root switchtest]# /sbin/rmmod xeno_switchtest > ERROR: Module xeno_switchtest is in use > [root switchtest]# > > I can run switchtest multiple times, but I get more and more leftover > threads in /proc/xenomai/stat. Ok, thanks, I will commit yesterday version then. -- Gilles Chanteperdrix ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] switchtest and Xenomai 2.2.4 2006-10-27 15:05 ` Gilles Chanteperdrix @ 2006-10-27 16:25 ` Jeff Webb 0 siblings, 0 replies; 15+ messages in thread From: Jeff Webb @ 2006-10-27 16:25 UTC (permalink / raw) To: xenomai Gilles Chanteperdrix wrote: > > Ok, thanks, I will commit yesterday version then. > For what it's worth.... The stock switchtest under xenomai 2.2.4 works fine, if I compile for UP instead of SMP. -Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2006-10-27 16:25 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-15 21:32 [Xenomai-core] Xenomai v2.2.4 Philippe Gerum
2006-10-25 20:10 ` [Xenomai-help] switchtest and Xenomai 2.2.4 Jeff Webb
2006-10-25 23:43 ` Jeff Webb
2006-10-26 8:21 ` Gilles Chanteperdrix
2006-10-26 15:51 ` Jeff Webb
2006-10-26 15:56 ` Gilles Chanteperdrix
2006-10-26 16:44 ` Jeff Webb
2006-10-26 16:55 ` Jan Kiszka
2006-10-26 18:53 ` Jeff Webb
2006-10-26 7:35 ` Gilles Chanteperdrix
[not found] ` <454078AD.5000907@domain.hid>
[not found] ` <4540DE60.40209@domain.hid>
[not found] ` <4540E1AB.2040200@domain.hid>
[not found] ` <4540EABD.10403@domain.hid>
[not found] ` <4540ECA6.5000604@domain.hid>
2006-10-26 19:49 ` Jeff Webb
2006-10-27 8:18 ` Gilles Chanteperdrix
2006-10-27 14:45 ` Jeff Webb
2006-10-27 15:05 ` Gilles Chanteperdrix
2006-10-27 16:25 ` Jeff Webb
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.