Re: [Xenomai-help] Xenomai on i7-870

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

On 16 June 2011 08:01, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 06/15/2011 10:43 PM, Jakub Nowacki wrote:
>> On 15/06/2011 17:51, Gilles Chanteperdrix wrote:
>>> On 06/15/2011 06:21 PM, Jakub Nowacki wrote:
>>>> I have SMI workaround switched on.
>>>
>>> Have you verified that the your chipset is supported by SMI workaround?
>>> http://www.xenomai.org/index.php/Configuring_x86_kernels#In_case_of_high_latencies
>>>
>> Indeed, it's not on, nothing SMI-related shown in Krenel's log. I've
>> found that my LPC is 'Intel Corporation 5 Series Chipset LPC Interface
>> Controller (rev 06)' (full lspci log is enclosed for a reference).
>
> You should use lspci -n in order to get the numerical ids.

Yes, I noticed that after I went home and looked into the log. 'lspci
-nn' gives:

00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC
Interface Controller [8086:3b0a] (rev 06)

BTW the above wiki entry is slightly misleading because it suggest
'lspci -vv', whereas, if you want the actual numerical IDs you need
the -n or -nn option.

Cheers,

Jakub

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/16/2011 11:18 AM, Jakub Nowacki wrote:
> On 16 June 2011 08:01, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
>> On 06/15/2011 10:43 PM, Jakub Nowacki wrote:
>>> On 15/06/2011 17:51, Gilles Chanteperdrix wrote:
>>>> On 06/15/2011 06:21 PM, Jakub Nowacki wrote:
>>>>> I have SMI workaround switched on.
>>>>
>>>> Have you verified that the your chipset is supported by SMI workaround?
>>>> http://www.xenomai.org/index.php/Configuring_x86_kernels#In_case_of_high_latencies
>>>>
>>> Indeed, it's not on, nothing SMI-related shown in Krenel's log. I've
>>> found that my LPC is 'Intel Corporation 5 Series Chipset LPC Interface
>>> Controller (rev 06)' (full lspci log is enclosed for a reference).
>>
>> You should use lspci -n in order to get the numerical ids.
> 
> Yes, I noticed that after I went home and looked into the log. 'lspci
> -nn' gives:
> 
> 00:1f.0 ISA bridge [0601]: Intel Corporation 5 Series Chipset LPC
> Interface Controller [8086:3b0a] (rev 06)
> 
> BTW the above wiki entry is slightly misleading because it suggest
> 'lspci -vv', whereas, if you want the actual numerical IDs you need
> the -n or -nn option.

wiki updated. Thanks.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

>
>
> I've added my ID to the table in smi.c file as:

{PCI_DEVICE(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_5_3400_SERIES_LPC_MIN+0xa)}

Everything complies OK but during the startup I get message:

[    2.137733] Xenomai: SMI-enabled chipset found
[    2.137744] Xenomai: SMI workaround failed!

Should I do something extra apart from adding it to the table?

Best wishes,

Jakub

[-- Attachment #2: Type: text/html, Size: 754 bytes --]

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/17/2011 04:05 PM, Jakub Nowacki wrote:
>>
>>
>> I've added my ID to the table in smi.c file as:
> 
> {PCI_DEVICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_5_3400_SERIES_LPC_MIN+0xa)}
> 
> Everything complies OK but during the startup I get message:
> 
> [    2.137733] Xenomai: SMI-enabled chipset found
> [    2.137744] Xenomai: SMI workaround failed!
> 
> Should I do something extra apart from adding it to the table?

There are two reasons why it may not work:
- the way to globally disable SMIs has changed with the chipset version
you are using;
- the BIOS of your PC locks the SMI disabling bit.

So, the next step is to check the chipset datasheet.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/17/2011 09:00 PM, Gilles Chanteperdrix wrote:
> On 06/17/2011 04:05 PM, Jakub Nowacki wrote:
>>>
>>>
>>> I've added my ID to the table in smi.c file as:
>>
>> {PCI_DEVICE(PCI_VENDOR_ID_INTEL,
>> PCI_DEVICE_ID_INTEL_5_3400_SERIES_LPC_MIN+0xa)}
>>
>> Everything complies OK but during the startup I get message:
>>
>> [    2.137733] Xenomai: SMI-enabled chipset found
>> [    2.137744] Xenomai: SMI workaround failed!
>>
>> Should I do something extra apart from adding it to the table?
> 
> There are two reasons why it may not work:
> - the way to globally disable SMIs has changed with the chipset version
> you are using;
> - the BIOS of your PC locks the SMI disabling bit.
> 
> So, the next step is to check the chipset datasheet.

>From your first mail, the chipset you use is a Q57, the datasheet says 
that the GLB_SMI_EN is still there. So, what you should do is check 
whether the SMI_LOCK bit is set. The following (untested) patch should 
print the lock bit value:

diff --git a/ksrc/arch/x86/smi.c b/ksrc/arch/x86/smi.c
index d80b14b..97e6774 100644
--- a/ksrc/arch/x86/smi.c
+++ b/ksrc/arch/x86/smi.c
@@ -157,7 +157,8 @@ void rthal_smi_disable(void)
        mask_bits(rthal_smi_masked_bits, rthal_smi_en_addr);
 
        if (inl(rthal_smi_en_addr) & rthal_smi_masked_bits)
-               printk("Xenomai: SMI workaround failed!\n");
+               printk("Xenomai: SMI workaround failed!, BIOS lock: d\n",
+                      !!(inl(rthal_smi_en_addr + 0xA0 - SMI_CTRL_ADDR) & (1 << 4)));
        else
                printk("Xenomai: SMI workaround enabled\n");
 


> 


-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

On 17/06/2011 20:00, Gilles Chanteperdrix wrote:
> On 06/17/2011 04:05 PM, Jakub Nowacki wrote:
>>>
>>>
>>> I've added my ID to the table in smi.c file as:
>>
>> {PCI_DEVICE(PCI_VENDOR_ID_INTEL,
>> PCI_DEVICE_ID_INTEL_5_3400_SERIES_LPC_MIN+0xa)}
>>
>> Everything complies OK but during the startup I get message:
>>
>> [    2.137733] Xenomai: SMI-enabled chipset found
>> [    2.137744] Xenomai: SMI workaround failed!
>>
>> Should I do something extra apart from adding it to the table?
>
> There are two reasons why it may not work:
> - the way to globally disable SMIs has changed with the chipset version
> you are using;
> - the BIOS of your PC locks the SMI disabling bit.
>
> So, the next step is to check the chipset datasheet.
>
Following the datasheet available at:

http://www.intel.com/Assets/PDF/datasheet/322169.pdf

SMI_EN—SMI Control and Enable Register has address: PMBASE + 30 (see p. 
531), which seems to be the same as in 'smi.c' (PMBASE is 0x40-0x43; see 
p. 460). Structure seems to be the same, namely, GBL_SMI_EN_BIT is the 
first bit. However, SMI enable can be locked using SMI_LOC bit in 
GEN_PMCON_1—General PM Configuration 1 Register
(PM—D31:F0) with Offset Address: A0h; see p. 513. Hence, this one can 
potentially stop 'smi.c' from applying the workaround. Sorry for 
slightly descriptive approach but I don't know 'smi.c' code that well to 
fiddle with it.

Hope it helps slightly.

Best wishes,

Jakub

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

On 17/06/2011 20:44, Gilles Chanteperdrix wrote:
> On 06/17/2011 09:00 PM, Gilles Chanteperdrix wrote:
>> On 06/17/2011 04:05 PM, Jakub Nowacki wrote:
>>>>
>>>>
>>>> I've added my ID to the table in smi.c file as:
>>>
>>> {PCI_DEVICE(PCI_VENDOR_ID_INTEL,
>>> PCI_DEVICE_ID_INTEL_5_3400_SERIES_LPC_MIN+0xa)}
>>>
>>> Everything complies OK but during the startup I get message:
>>>
>>> [    2.137733] Xenomai: SMI-enabled chipset found
>>> [    2.137744] Xenomai: SMI workaround failed!
>>>
>>> Should I do something extra apart from adding it to the table?
>>
>> There are two reasons why it may not work:
>> - the way to globally disable SMIs has changed with the chipset version
>> you are using;
>> - the BIOS of your PC locks the SMI disabling bit.
>>
>> So, the next step is to check the chipset datasheet.
>
>  From your first mail, the chipset you use is a Q57, the datasheet says
> that the GLB_SMI_EN is still there. So, what you should do is check
> whether the SMI_LOCK bit is set. The following (untested) patch should
> print the lock bit value:
>
> diff --git a/ksrc/arch/x86/smi.c b/ksrc/arch/x86/smi.c
> index d80b14b..97e6774 100644
> --- a/ksrc/arch/x86/smi.c
> +++ b/ksrc/arch/x86/smi.c
> @@ -157,7 +157,8 @@ void rthal_smi_disable(void)
>          mask_bits(rthal_smi_masked_bits, rthal_smi_en_addr);
>
>          if (inl(rthal_smi_en_addr)&  rthal_smi_masked_bits)
> -               printk("Xenomai: SMI workaround failed!\n");
> +               printk("Xenomai: SMI workaround failed!, BIOS lock: d\n",
> +                      !!(inl(rthal_smi_en_addr + 0xA0 - SMI_CTRL_ADDR)&  (1<<  4)));
>          else
>                  printk("Xenomai: SMI workaround enabled\n");
>

You were faster. Thanks! Sorry for slight cross posting. I have this 
machine at work so I probably test it on Monday.

Cheers,

Jakub

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/17/2011 09:52 PM, Jakub Nowacki wrote:
> 
> 
> On 17/06/2011 20:44, Gilles Chanteperdrix wrote:
>> On 06/17/2011 09:00 PM, Gilles Chanteperdrix wrote:
>>> On 06/17/2011 04:05 PM, Jakub Nowacki wrote:
>>>>>
>>>>>
>>>>> I've added my ID to the table in smi.c file as:
>>>>
>>>> {PCI_DEVICE(PCI_VENDOR_ID_INTEL,
>>>> PCI_DEVICE_ID_INTEL_5_3400_SERIES_LPC_MIN+0xa)}
>>>>
>>>> Everything complies OK but during the startup I get message:
>>>>
>>>> [    2.137733] Xenomai: SMI-enabled chipset found
>>>> [    2.137744] Xenomai: SMI workaround failed!
>>>>
>>>> Should I do something extra apart from adding it to the table?
>>>
>>> There are two reasons why it may not work:
>>> - the way to globally disable SMIs has changed with the chipset version
>>> you are using;
>>> - the BIOS of your PC locks the SMI disabling bit.
>>>
>>> So, the next step is to check the chipset datasheet.
>>
>>  From your first mail, the chipset you use is a Q57, the datasheet says
>> that the GLB_SMI_EN is still there. So, what you should do is check
>> whether the SMI_LOCK bit is set. The following (untested) patch should
>> print the lock bit value:
>>
>> diff --git a/ksrc/arch/x86/smi.c b/ksrc/arch/x86/smi.c
>> index d80b14b..97e6774 100644
>> --- a/ksrc/arch/x86/smi.c
>> +++ b/ksrc/arch/x86/smi.c
>> @@ -157,7 +157,8 @@ void rthal_smi_disable(void)
>>          mask_bits(rthal_smi_masked_bits, rthal_smi_en_addr);
>>
>>          if (inl(rthal_smi_en_addr)&  rthal_smi_masked_bits)
>> -               printk("Xenomai: SMI workaround failed!\n");
>> +               printk("Xenomai: SMI workaround failed!, BIOS lock: d\n",
>> +                      !!(inl(rthal_smi_en_addr + 0xA0 - SMI_CTRL_ADDR)&  (1<<  4)));
>>          else
>>                  printk("Xenomai: SMI workaround enabled\n");
>>
> 
> You were faster. Thanks! Sorry for slight cross posting. I have this 
> machine at work so I probably test it on Monday.

The next step is to try disabling the individual bits (TC0, USB legacy,
etc...), as they may not affected by the SMI_LOCK bit.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

On 18 June 2011 16:17, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On 06/17/2011 09:52 PM, Jakub Nowacki wrote:
>> On 17/06/2011 20:44, Gilles Chanteperdrix wrote:
>>>  From your first mail, the chipset you use is a Q57, the datasheet says
>>> that the GLB_SMI_EN is still there. So, what you should do is check
>>> whether the SMI_LOCK bit is set. The following (untested) patch should
>>> print the lock bit value:
>>>
>>> diff --git a/ksrc/arch/x86/smi.c b/ksrc/arch/x86/smi.c
>>> index d80b14b..97e6774 100644
>>> --- a/ksrc/arch/x86/smi.c
>>> +++ b/ksrc/arch/x86/smi.c
>>> @@ -157,7 +157,8 @@ void rthal_smi_disable(void)
>>>          mask_bits(rthal_smi_masked_bits, rthal_smi_en_addr);
>>>
>>>          if (inl(rthal_smi_en_addr)&  rthal_smi_masked_bits)
>>> -               printk("Xenomai: SMI workaround failed!\n");
>>> +               printk("Xenomai: SMI workaround failed!, BIOS lock: d\n",
>>> +                      !!(inl(rthal_smi_en_addr + 0xA0 - SMI_CTRL_ADDR)&  (1<<  4)));
>>>          else
>>>                  printk("Xenomai: SMI workaround enabled\n");
>>>
>>
>> You were faster. Thanks! Sorry for slight cross posting. I have this
>> machine at work so I probably test it on Monday.
>
> The next step is to try disabling the individual bits (TC0, USB legacy,
> etc...), as they may not affected by the SMI_LOCK bit.
>

I've added the patch to smi.c and, as suspected, the SMI_LOCK is on,
namely, kernel log looks like:

[    2.111453] Xenomai: SMI workaround failed!, BIOS lock: 1

I switched off the global SMI disable leaving the particular bits
disabled and it seems to work:

[    2.121558] Xenomai: SMI-enabled chipset found
[    2.121568] Xenomai: SMI workaround enabled

BTW I've found that often motherboards have SMI locked and it is not
changeable in BIOS.

As for latency tests it helped, I think. I did series of tests with
large load (8x'dd if=/dev/zero of=/dev/null') and the results look
something like that:

Latency for user task (-t0), period 100 us:
RTS|     -2.363|     -1.936|     20.443|       0|     0|    00:30:00/00:30:00
Latency for kernel task (-t1), period 100 us:
RTS|     -2.924|     -2.500|     12.974|       0|     0|    00:30:00/00:30:00
Latency for timer IRQ (-t2), period 100 us:
RTS|     -3.327|     -2.970|     10.572|       0|     0|    00:30:00/00:30:00

Interestingly, I'm getting the same results for core2 kernel without
SMI workaround working. I was just getting high latencies approx. 70
us for generic kernel. I'm not sure though how is it possible. Also,
the higher latencies of above 10 us are arriving not too often but
relatively regularly (without any visible pattern, though). I'm not
sure if such a latencies are rather normal or caused by something
'bad'.

Moreover, I seem not be able to do switch test; when I run it I'm getting:

== 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.
ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
== 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
sleeper_ufps2-0 rtk2-1 rtk2-2 rtk_fp2-3RTT|  363494:24:53
RTH|---------cpu|ctx switches|-------total
RTD|           0|           0|           0
RTD|           1|           0|           0
RTD|           2|           0|           0

Thanks again for the a lot of help I received so far.

Best wishes,

Jakub

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/20/2011 04:34 PM, Jakub Nowacki wrote:
> Interestingly, I'm getting the same results for core2 kernel without
> SMI workaround working. I was just getting high latencies approx. 70
> us for generic kernel. I'm not sure though how is it possible. Also,
> the higher latencies of above 10 us are arriving not too often but
> relatively regularly (without any visible pattern, though). I'm not
> sure if such a latencies are rather normal or caused by something
> 'bad'.

To make proper benchmarks, you should:
- let the latency run long
- provide some load, you can use the dohell script in xenomai-head to
generate the load.

That said, having some spikes is not abnormal. The real question is to
know whether the latencies your get are sufficient for your application.

> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory

You have to increase CONFIG_XENO_OPT_SYS_STACKPOOLSZ.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

On 06/20/2011 04:02 PM, Gilles Chanteperdrix wrote:
> To make proper benchmarks, you should:
> - let the latency run long
> - provide some load, you can use the dohell script in xenomai-head to
> generate the load.
>
I've generated a load using 'dd if=/dev/zero of=/dev/null' one for each 
core (8 in total), which is roughly the way how xeno-test does it. The 
test was running for 30 min, which is not very long but I should see the 
long latencies by that time, I think at least.

> That said, having some spikes is not abnormal. The real question is to
> know whether the latencies your get are sufficient for your application.
>
Well, I think it should be OK for peak latencies < 20 us, that is what 
I'm getting now.

>> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
>
> You have to increase CONFIG_XENO_OPT_SYS_STACKPOOLSZ.
>
It is 128 Kb now. Should it be more? Is there any (thumb) rule for this 
value?

Best wishes,

Jakub

Re: [Xenomai-help] Xenomai on i7-870

[Philippe Gerum]

On Mon, 2011-06-20 at 16:25 +0100, Jakub Nowacki wrote:
> On 06/20/2011 04:02 PM, Gilles Chanteperdrix wrote:
> > To make proper benchmarks, you should:
> > - let the latency run long
> > - provide some load, you can use the dohell script in xenomai-head to
> > generate the load.
> >
> I've generated a load using 'dd if=/dev/zero of=/dev/null' one for each 
> core (8 in total), which is roughly the way how xeno-test does it. The 
> test was running for 30 min, which is not very long but I should see the 
> long latencies by that time, I think at least.
> 
> > That said, having some spikes is not abnormal. The real question is to
> > know whether the latencies your get are sufficient for your application.
> >
> Well, I think it should be OK for peak latencies < 20 us, that is what 
> I'm getting now.
> 
> >> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
> >
> > You have to increase CONFIG_XENO_OPT_SYS_STACKPOOLSZ.
> >
> It is 128 Kb now. Should it be more? Is there any (thumb) rule for this 
> value?

Max # of concurrent kernel-based Xenomai threads x stack_size. 8k stack
minimum is a safe bet for x86_64.

Typically, RTDM (driver) tasks in kernel space are Xenomai ones, so you
would need to reserve stack space for each of them in this amount.

The switchtest driver is RTDM-based, and may run a number of RTDM tasks,
depending on the test scenario.

> 
> Best wishes,
> 
> Jakub
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/20/2011 06:16 PM, Philippe Gerum wrote:
> On Mon, 2011-06-20 at 16:25 +0100, Jakub Nowacki wrote:
>> On 06/20/2011 04:02 PM, Gilles Chanteperdrix wrote:
>>> To make proper benchmarks, you should:
>>> - let the latency run long
>>> - provide some load, you can use the dohell script in xenomai-head to
>>> generate the load.
>>>
>> I've generated a load using 'dd if=/dev/zero of=/dev/null' one for each 
>> core (8 in total), which is roughly the way how xeno-test does it. The 
>> test was running for 30 min, which is not very long but I should see the 
>> long latencies by that time, I think at least.
>>
>>> That said, having some spikes is not abnormal. The real question is to
>>> know whether the latencies your get are sufficient for your application.
>>>
>> Well, I think it should be OK for peak latencies < 20 us, that is what 
>> I'm getting now.
>>
>>>> ioctl(RTTST_RTIOC_SWTEST_CREATE_KTASK): Cannot allocate memory
>>>
>>> You have to increase CONFIG_XENO_OPT_SYS_STACKPOOLSZ.
>>>
>> It is 128 Kb now. Should it be more? Is there any (thumb) rule for this 
>> value?
> 
> Max # of concurrent kernel-based Xenomai threads x stack_size. 8k stack
> minimum is a safe bet for x86_64.
> 
> Typically, RTDM (driver) tasks in kernel space are Xenomai ones, so you
> would need to reserve stack space for each of them in this amount.
> 
> The switchtest driver is RTDM-based, and may run a number of RTDM tasks,
> depending on the test scenario.

The default scenario being to run 6 rtdm tasks by cpu (that would make
48 on an 8 cores processor).

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Gilles Chanteperdrix]

On 06/20/2011 05:25 PM, Jakub Nowacki wrote:
> On 06/20/2011 04:02 PM, Gilles Chanteperdrix wrote:
>> To make proper benchmarks, you should:
>> - let the latency run long
>> - provide some load, you can use the dohell script in xenomai-head to
>> generate the load.
>>
> I've generated a load using 'dd if=/dev/zero of=/dev/null' one for each 
> core (8 in total), which is roughly the way how xeno-test does it. The 
> test was running for 30 min, which is not very long but I should see the 
> long latencies by that time, I think at least.

xeno-test adds many more way to generate load, which you should use if
you intend to have good results (I mean, really pessimistic ones). If
you do not have time to run LTP completely, you can use hackbench for a
few hours.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on i7-870

[Jakub Nowacki]

On 20/06/2011 18:34, Gilles Chanteperdrix wrote:
> On 06/20/2011 06:16 PM, Philippe Gerum wrote:
>> On Mon, 2011-06-20 at 16:25 +0100, Jakub Nowacki wrote:
>>> On 06/20/2011 04:02 PM, Gilles Chanteperdrix wrote:
>>>> You have to increase CONFIG_XENO_OPT_SYS_STACKPOOLSZ.
>>>>
>>> It is 128 Kb now. Should it be more? Is there any (thumb) rule for this
>>> value?
>>
>> Max # of concurrent kernel-based Xenomai threads x stack_size. 8k stack
>> minimum is a safe bet for x86_64.
>>
>> Typically, RTDM (driver) tasks in kernel space are Xenomai ones, so you
>> would need to reserve stack space for each of them in this amount.
>>
>> The switchtest driver is RTDM-based, and may run a number of RTDM tasks,
>> depending on the test scenario.
>
> The default scenario being to run 6 rtdm tasks by cpu (that would make
> 48 on an 8 cores processor).
>
Thanks for the explanation. I've changed the stack pool size to 512kb, 
which is slightly more then minimum, and it allowed the test to run.

As for the tests, I don't think I have to be more pessimistic in it. I 
have to (finally) do some lab testing, which would potentially reveal 
some problems. Nonetheless, thanks for the suggestions.

Cheers,

Jakub

[Xenomai-help] Xenomai beagleboard xm ethernet not working

[David Wiebe]

Hello,

I haven't been able to get the ethernet to work with linux 2.6.35.9 
patched with Xenomai. I've been in menuconfig turning on anything and 
everything related to networking and usb and still nothing.

David

Re: [Xenomai-help] Xenomai beagleboard xm ethernet not working

[Gilles Chanteperdrix]

On 06/21/2011 12:54 AM, David Wiebe wrote:
> Hello,
> 
> I haven't been able to get the ethernet to work with linux 2.6.35.9 
> patched with Xenomai. I've been in menuconfig turning on anything and 
> everything related to networking and usb and still nothing.

If you disable CONFIG_XENOMAI and CONFIG_IPIPE in the kernel
configuration, does ethernet work?

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai beagleboard xm ethernet not working

[David Wiebe]

On 11-06-20 11:54 PM, Gilles Chanteperdrix wrote:
> On 06/21/2011 12:54 AM, David Wiebe wrote:
>> Hello,
>>
>> I haven't been able to get the ethernet to work with linux 2.6.35.9
>> patched with Xenomai. I've been in menuconfig turning on anything and
>> everything related to networking and usb and still nothing.
> If you disable CONFIG_XENOMAI and CONFIG_IPIPE in the kernel
> configuration, does ethernet work?
>
Hi Gilles,

I've got the usb ethernet interface up. I can ping it from my pc. The 
beagleboard hangs. I'm investigating. I've used the usb ethernet adaptor 
successfully many times with the bbc4 so I doubt its the problem.

Here's the serial output dump

*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Beagle Rev C4
timed out in wait_for_pin: I2C_STAT=0
No EEPROM on expansion board
Die ID #5484000400000000040373050d00801d
Hit any key to stop autoboot:  0
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
reading uImage

2272764 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 82000000 ...
    Image Name:   Linux-2.6.35.9-ipipe
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2272700 Bytes = 2.2 MiB
    Load Address: 80008000
    Entry Point:  80008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.35.9-ipipe (david@domain.hid) 
(gc1
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction ca
Memory policy: ECC disabled, Data cache writeback
OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000r, mobility 
groupi4
Kernel command line: console=ttyS2,115200n8 mpurate=720 vram=12M 
omapfb.modet
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128MB 128MB = 256MB total
Memory: 255148k/255148k available, 6996k reserved, 0K highmem
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)
     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .init : 0xc0008000 - 0xc0029000   ( 132 kB)
       .text : 0xc0029000 - 0xc0411000   (4000 kB)
       .data : 0xc042c000 - 0xc0466d80   ( 236 kB)
Hierarchical RCU implementation.
         Verbose stalled-CPUs detection is disabled.
NR_IRQS:402
Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
omap_hwmod: l3_hwmod: cannot be enabled (3)
omap_hwmod: l4_core_hwmod: cannot be enabled (3)
omap_hwmod: l4_per_hwmod: cannot be enabled (3)
omap_hwmod: l4_wkup_hwmod: cannot be enabled (3)
Reprogramming SDRC clock to 332000000 Hz
GPMC revision 5.0
IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP GPIO hardware version 2.5
OMAP clockevent source: GPTIMER2 at 13000000 Hz
I-pipe, 13.000 MHz clocksource
I-pipe 1.18-01: pipeline enabled.
Console: colour dummy device 80x30
Calibrating delay loop... 498.07 BogoMIPS (lpj=2490368)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
regulator: core version 0.5
NET: Registered protocol family 16
Using McSPI for SPI
Found NAND on CS0
Registering NAND on CS0
Unable to get DVI reset GPIO
Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/332 MHz
OMAP DMA hardware revision 4.0
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered n2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
regulator: VUSB1V5: 1500 mV normal standby
regulator: VUSB1V8: 1800 mV normal standby
regulator: VUSB3V1: 3100 mV normal standby
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
regulator: VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby
regulator: VDAC: 1800 mV normal standby
regulator: VDVI: 1800 mV normal standby
regulator: VSIM: 1800 <--> 3000 mV at 1800 mV normal standby
i2c_omap i2c_omap.3: bus 3 rev3.12 at 100 kHz
Switching to clocksource ipipe_tsc
musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
musb_hdrc musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
msgmni has been set to 498
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
usbcore: registered new interface driver catc
catc: v2.8:CATC EL1210A NetMate USB Ethernet driver
usbcore: registered new interface driver kaweth
pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
usbcore: registered new interface driver pegasus
rtl8150: v0.6.2 (2004/08/27):rtl8150 based usb-ethernet driver
usbcore: registered new interface driver rtl8150
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver cdc_eem
usbcore: registered new interface driver dm9601
usbcore: registered new interface driver smsc75xx
usbcore: registered new interface driver smsc95xx
usbcore: registered new interface driver gl620a
usbcore: registered new interface driver net1080
usbcore: registered new interface driver plusb
usbcore: registered new interface driver rndis_host
usbcore: registered new interface driver cdc_subset
usbcore: registered new interface driver zaurus
usbcore: registered new interface driver MOSCHIP usb-ethernet driver
usbmon: deb USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OMAP-EHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.35.9-ipipe ehci_hcd
usb usb1: SerialNumber: ehci-omap.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Power Management for TI OMAP3.
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
regulator_init_complete: incomplete constraints, leaving VDVI on
regulator_init_complete: incomplete constraints, leaving VDAC on
Waiting for root device /dev/mmcblk0p2...
usb 1-2: new high speed USB device using ehci-omap and address 2
mmc0: new high speed SDHC card at address fde5
mmcblk0: mmc0:fde5 SD04G 3.69 GiB
  mmcblk0: p1 p2
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds
EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running 
e2fsck isd
EXT3-fs (mmcblk0p2): using internal journal
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) on device 179:2.
Freeing init memory: 132K
usb 1-2: New USB device found, idVendor=0b95, idProduct=7720
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: AX88772
usb 1-2: Manufacturer: ASIX Elec. Corp.
usb 1-2: SerialNumber: 000001
INIT: version 2.86 booting
Please wait: booting...
Starting udev
Illegal instruction
asix 1-2:1.0: eth0: register 'asix' at usb-ehci-omap.0-2, ASIX AX88772 
USB 2a
Remounting root file system...
Caching udev devnodes
Populating dev cache
ALSA: Restoring mixer settings...
Configuring network interfaces... /usr/sbin/alsactl: load_state:1610: No 
sou.
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
udhcpc (v1.13.2) started
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
Sending discover...
Sending select for 192.168.0.101...
Lease of 192.168.0.101 obtained, lease time 10800
run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
adding dns 192.168.0.1
ifconfig: SIOCGIFFLAGS: No such device
done.
Starting portmap daemon: portmap.
portmap: fork: No such deviceeth0: link up, 100Mbps, full-duplex, lpa 0x41E1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
hwclock: can't open '/dev/misc/rtc': No such file or directory

Re: [Xenomai-help] Xenomai beagleboard xm ethernet working!

[David Wiebe]

Hello,

In menuconfig, unselect realtime clock. lol! Boots fine, ethernet 
support works! I also patched the kernel to support spi which works in 
userland.

Now to make it all work as a rtos. If anyone has suggestions or 
whatever, I need to work on a spi to ethernet bridge. I need to read 
360bytes every 1mS and send it out over ethernet. I've done this with a 
non-rtos and achieved 360byte read and send every ~740uS. The problem 
was sometimes it would vary between  700 and 900uS etc. I need this to 
be isochronous and 1mS will work fine.

There you have it!
Cheers!

David


On 11-06-21 01:18 AM, David Wiebe wrote:
> On 11-06-20 11:54 PM, Gilles Chanteperdrix wrote:
>> On 06/21/2011 12:54 AM, David Wiebe wrote:
>>> Hello,
>>>
>>> I haven't been able to get the ethernet to work with linux 2.6.35.9
>>> patched with Xenomai. I've been in menuconfig turning on anything and
>>> everything related to networking and usb and still nothing.
>> If you disable CONFIG_XENOMAI and CONFIG_IPIPE in the kernel
>> configuration, does ethernet work?
>>
> Hi Gilles,
>
> I've got the usb ethernet interface up. I can ping it from my pc. The 
> beagleboard hangs. I'm investigating. I've used the usb ethernet 
> adaptor successfully many times with the bbc4 so I doubt its the problem.
>
> Here's the serial output dump
>
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Beagle Rev C4
> timed out in wait_for_pin: I2C_STAT=0
> No EEPROM on expansion board
> Die ID #5484000400000000040373050d00801d
> Hit any key to stop autoboot:  0
> reading boot.scr
>
> ** Unable to read "boot.scr" from mmc 0:1 **
> reading uImage
>
> 2272764 bytes read
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 82000000 ...
>    Image Name:   Linux-2.6.35.9-ipipe
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    2272700 Bytes = 2.2 MiB
>    Load Address: 80008000
>    Entry Point:  80008000
>    Verifying Checksum ... OK
>    Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Linux version 2.6.35.9-ipipe 
> (david@domain.hid) (gc1
> CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
> CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction ca
> Memory policy: ECC disabled, Data cache writeback
> OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
> SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000r, mobility 
> groupi4
> Kernel command line: console=ttyS2,115200n8 mpurate=720 vram=12M 
> omapfb.modet
> PID hash table entries: 1024 (order: 0, 4096 bytes)
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 128MB 128MB = 256MB total
> Memory: 255148k/255148k available, 6996k reserved, 0K highmem
> Virtual kernel memory layout:
>     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
>     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
>     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
>     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)
>     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
>     modules : 0xbf000000 - 0xc0000000   (  16 MB)
>       .init : 0xc0008000 - 0xc0029000   ( 132 kB)
>       .text : 0xc0029000 - 0xc0411000   (4000 kB)
>       .data : 0xc042c000 - 0xc0466d80   ( 236 kB)
> Hierarchical RCU implementation.
>         Verbose stalled-CPUs detection is disabled.
> NR_IRQS:402
> Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
> omap_hwmod: l3_hwmod: cannot be enabled (3)
> omap_hwmod: l4_core_hwmod: cannot be enabled (3)
> omap_hwmod: l4_per_hwmod: cannot be enabled (3)
> omap_hwmod: l4_wkup_hwmod: cannot be enabled (3)
> Reprogramming SDRC clock to 332000000 Hz
> GPMC revision 5.0
> IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
> Total of 96 interrupts on 1 active controller
> OMAP GPIO hardware version 2.5
> OMAP clockevent source: GPTIMER2 at 13000000 Hz
> I-pipe, 13.000 MHz clocksource
> I-pipe 1.18-01: pipeline enabled.
> Console: colour dummy device 80x30
> Calibrating delay loop... 498.07 BogoMIPS (lpj=2490368)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> regulator: core version 0.5
> NET: Registered protocol family 16
> Using McSPI for SPI
> Found NAND on CS0
> Registering NAND on CS0
> Unable to get DVI reset GPIO
> Switched to new clocking rate (Crystal/Core/MPU): 26.0/720/332 MHz
> OMAP DMA hardware revision 4.0
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered n2c_omap.1: bus 1 rev3.12 at 2600 kHz
> twl4030: PIH (irq 7) chaining IRQs 368..375
> twl4030: power (irq 373) chaining IRQs 376..383
> twl4030: gpio (irq 368) chaining IRQs 384..401
> regulator: VUSB1V5: 1500 mV normal standby
> regulator: VUSB1V8: 1800 mV normal standby
> regulator: VUSB3V1: 3100 mV normal standby
> twl4030_usb twl4030_usb: Initialized TWL4030 USB module
> regulator: VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby
> regulator: VDAC: 1800 mV normal standby
> regulator: VDVI: 1800 mV normal standby
> regulator: VSIM: 1800 <--> 3000 mV at 1800 mV normal standby
> i2c_omap i2c_omap.3: bus 3 rev3.12 at 100 kHz
> Switching to clocksource ipipe_tsc
> musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
> musb_hdrc musb_hdrc: USB OTG mode controller at fa0ab000 using DMA, 
> IRQ 92
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> NetWinder Floating Point Emulator V0.97 (double precision)
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/arm started.
> Xenomai: scheduling class idle registered.
> Xenomai: scheduling class rt registered.
> Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> VFS: Disk quotas dquot_6.5.2
> Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> JFFS2 version 2.2. (NAND) �© 2001-2006 Red Hat, Inc.
> msgmni has been set to 498
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
> serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
> serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
> console [ttyS2] enabled
> brd: module loaded
> loop: module loaded
> usbcore: registered new interface driver catc
> catc: v2.8:CATC EL1210A NetMate USB Ethernet driver
> usbcore: registered new interface driver kaweth
> pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
> usbcore: registered new interface driver pegasus
> rtl8150: v0.6.2 (2004/08/27):rtl8150 based usb-ethernet driver
> usbcore: registered new interface driver rtl8150
> usbcore: registered new interface driver asix
> usbcore: registered new interface driver cdc_ether
> usbcore: registered new interface driver cdc_eem
> usbcore: registered new interface driver dm9601
> usbcore: registered new interface driver smsc75xx
> usbcore: registered new interface driver smsc95xx
> usbcore: registered new interface driver gl620a
> usbcore: registered new interface driver net1080
> usbcore: registered new interface driver plusb
> usbcore: registered new interface driver rndis_host
> usbcore: registered new interface driver cdc_subset
> usbcore: registered new interface driver zaurus
> usbcore: registered new interface driver MOSCHIP usb-ethernet driver
> usbmon: deb USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
> ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1
> ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
> ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00
> usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: OMAP-EHCI Host Controller
> usb usb1: Manufacturer: Linux 2.6.35.9-ipipe ehci_hcd
> usb usb1: SerialNumber: ehci-omap.0
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i2c /dev entries driver
> TCP cubic registered
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> Power Management for TI OMAP3.
> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
> regulator_init_complete: incomplete constraints, leaving VDVI on
> regulator_init_complete: incomplete constraints, leaving VDAC on
> Waiting for root device /dev/mmcblk0p2...
> usb 1-2: new high speed USB device using ehci-omap and address 2
> mmc0: new high speed SDHC card at address fde5
> mmcblk0: mmc0:fde5 SD04G 3.69 GiB
>  mmcblk0: p1 p2
> EXT3-fs: barriers not enabled
> kjournald starting.  Commit interval 5 seconds
> EXT3-fs (mmcblk0p2): warning: maximal mount count reached, running 
> e2fsck isd
> EXT3-fs (mmcblk0p2): using internal journal
> EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
> VFS: Mounted root (ext3 filesystem) on device 179:2.
> Freeing init memory: 132K
> usb 1-2: New USB device found, idVendor=0b95, idProduct=7720
> usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-2: Product: AX88772
> usb 1-2: Manufacturer: ASIX Elec. Corp.
> usb 1-2: SerialNumber: 000001
> INIT: version 2.86 booting
> Please wait: booting...
> Starting udev
> Illegal instruction
> asix 1-2:1.0: eth0: register 'asix' at usb-ehci-omap.0-2, ASIX AX88772 
> USB 2a
> Remounting root file system...
> Caching udev devnodes
> Populating dev cache
> ALSA: Restoring mixer settings...
> Configuring network interfaces... /usr/sbin/alsactl: load_state:1610: 
> No sou.
> eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
> udhcpc (v1.13.2) started
> run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
> Sending discover...
> Sending select for 192.168.0.101...
> Lease of 192.168.0.101 obtained, lease time 10800
> run-parts: /etc/udhcpc.d/00avahi-autoipd exited with code 1
> adding dns 192.168.0.1
> ifconfig: SIOCGIFFLAGS: No such device
> done.
> Starting portmap daemon: portmap.
> portmap: fork: No such deviceeth0: link up, 100Mbps, full-duplex, lpa 
> 0x41E1
> net.ipv4.conf.default.rp_filter = 1
> net.ipv4.conf.all.rp_filter = 1
> hwclock: can't open '/dev/misc/rtc': No such file or directory
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

Re: [Xenomai-help] Xenomai beagleboard xm ethernet working!

[Gilles Chanteperdrix]

On 06/21/2011 10:38 AM, David Wiebe wrote:
> Hello,
> 
> In menuconfig, unselect realtime clock. lol! Boots fine, ethernet 
> support works! I also patched the kernel to support spi which works in 
> userland.
> 
> Now to make it all work as a rtos. If anyone has suggestions or 
> whatever, I need to work on a spi to ethernet bridge. I need to read 
> 360bytes every 1mS and send it out over ethernet. I've done this with a 
> non-rtos and achieved 360byte read and send every ~740uS. The problem 
> was sometimes it would vary between  700 and 900uS etc. I need this to 
> be isochronous and 1mS will work fine.
> 
> There you have it!
> Cheers!

If you want deterministic access to ethernet, you will need RTnet.
http://rtnet.org/

-- 
                                                                Gilles.