* [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 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
* 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
[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.