[Xenomai-help] Advice needed: Xenomai / USB access from kernel task

[Xenomai-help] Advice needed: Xenomai / USB access from kernel task

[G.P.M. Haagh]

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


One of our trainees has written a LKM that accesses the standard Linux
kernel's usb_core facilities from a Xenomai real-time thread running in
kernel space.
I am doing some follow up on his work and run into problems.
I would appreciate some help/advise.

1)
The main question to start with: is it Ok to submit urbs to usb_core
(usb_submit_urb)  from a Xenomai kernel task (task created in a LKM) ?

2) If Ok (Xenomai 2.3.4 / kernel 2.6.20.1)

- A task, created with rt_task_created in the LKM, reads a rt_pipe and
submits a (bulk-) URB.
Most times, the  URB submits works OK.
However occasionally (once every 10-15 minutes at 6 submits/s) the kernel
runs into problems --
the ata driver starts complaining about timeouts and cannot recover,
ethernet stops working, the USB mouse and keyboard stop working
or the system becomes completely silent and unresponsive.

- When using Xenomai 2.4.2 kernel 2.6.23.x, the USB submit always fails in
the sense that an exception (6) occurs in the xenomai thread when calling
usb_submit_urb; so the submit urb call never returns.
(saw this logged in /var/log/messages).

- The same USB related code does not cause problems when used as part of a
'normal' Linux character driver. The submit URB calls are then made from
the file write context.


Can anyone give me some advise/hints on how I can approach this problem?


thanks in advance,
Gerard

G.P.M. Haagh
Philips Applied Technologies
Eindhoven, The Netherlands

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

Re: [Xenomai-help] Advice needed: Xenomai / USB access from kernel task

[Gilles Chanteperdrix]

On Fri, Feb 22, 2008 at 10:13 AM, G.P.M. Haagh <g.p.m.haagh@domain.hid> wrote:
>
>
> One of our trainees has written a LKM that accesses the standard Linux
> kernel's usb_core facilities from a Xenomai real-time thread running in
> kernel space.
>  I am doing some follow up on his work and run into problems.
>  I would appreciate some help/advise.
>
>  1)
>  The main question to start with: is it Ok to submit urbs to usb_core
> (usb_submit_urb) from a Xenomai kernel task (task created in a LKM) ?

Without looking at the function implementation, it is hard to answer.
The short answer to this question is "no". In general, it ils not
possible to call regular Linux services from a Xenomai task. Now, it
may happen that it is possible, if the said service does not rely on
any Linux services such as spinlocks, mutex, etc...

Note that there is an USB stack for Xenomai, so, using this stack
could be a better solution:
http://developer.berlios.de/projects/usb4rt

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Advice needed: Xenomai / USB access from kernel task

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> On Fri, Feb 22, 2008 at 10:13 AM, G.P.M. Haagh <g.p.m.haagh@domain.hid> wrote:
>>
>> One of our trainees has written a LKM that accesses the standard Linux
>> kernel's usb_core facilities from a Xenomai real-time thread running in
>> kernel space.
>>  I am doing some follow up on his work and run into problems.
>>  I would appreciate some help/advise.
>>
>>  1)
>>  The main question to start with: is it Ok to submit urbs to usb_core
>> (usb_submit_urb) from a Xenomai kernel task (task created in a LKM) ?
> 
> Without looking at the function implementation, it is hard to answer.
> The short answer to this question is "no". In general, it ils not
> possible to call regular Linux services from a Xenomai task. Now, it
> may happen that it is possible, if the said service does not rely on
> any Linux services such as spinlocks, mutex, etc...

If we are in fact discussing a call from Xenomai RT context into the
vanilla USB stack, the answer is a clear "no". Even if we ignore the
incompatible (/wrt Xenomai) locking mechanisms the vanilla stack uses
(*), there is still the design issue that this stacks performs buffer
allocation on demand, and not in advance (like RTnet does for networking).

> Note that there is an USB stack for Xenomai, so, using this stack
> could be a better solution:
> http://developer.berlios.de/projects/usb4rt

There is another stack, usb20rt, which even supports USB 2.0 (the above
is limit to 1.1 so far). But I recently received a private mail
confirming my original review of usb20rt: It is only half-converted to
RT, still including incompatible Linux calls.

Conceptually, I consider usb4rt as the cleaner approach (not only
because it was a former student of mine who wrote it :->), but it also
suffers from its experimental state, having at least one known issue,
and lacking EHCI support.

Jan

(*) Switch on CONFIG_IPIPE_DEBUG_CONTEXT to learn about such problems
_before_ they happen to cause spurious crashes.

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux