RE: [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

[Pham, Phong via Xenomai]

Hi Sebastian,

Your patch (fixing TCP flags endianness issue) does work.  (I was under the 
impression to use tcp_flag_word and fix it in rt_tcp_set_flags() which I 
reported doesn't work earlier.)

Phong.

-Original Message-
From: Sebastian Smolorz [mailto:sebastian.smol...@gmx.de]
Sent: Monday, November 05, 2018 10:38 AM
To: Pham, Phong
Cc: Jan Kiszka; Hillman, Robert; xenomai@xenomai.org
Subject: Re: [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

Hi,

Pham, Phong wrote:
> Hi Sebastian,
>
> " Phong, can you test this on your machine?"
> No the fix does not work.  It overwrites the window field.

Did you try the patch I sent here?

https://www.xenomai.org/pipermail/xenomai/2018-November/039831.html

--
Sebastian
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here<http://www.ddc-web.com/Profile/EmailPrivacy.aspx> to view our 
privacy statement.

RE: [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

[Pham, Phong via Xenomai]

Hi Sebastian,

" Phong, can you test this on your machine?"
No the fix does not work.  It overwrites the window field.

Phong.


-Original Message-
From: Sebastian Smolorz [mailto:sebastian.smol...@gmx.de]
Sent: Friday, November 02, 2018 7:42 AM
To: Jan Kiszka
Cc: Pham, Phong; Hillman, Robert; xenomai@xenomai.org
Subject: Re: [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

On 31.10.18 19:18, Jan Kiszka wrote:
> On 31.10.18 17:55, Pham, Phong wrote:
> > Hi Sebastian,
> >
> > The issue has to do with endianness.  We are running PowerPC (big
> > endian).  So in rt_tcp_set_flags(), flags is 32-bit wide and *tf is
> > 16-bit wide.  I modified the line from:
> >
> > *tf = flags;
> >
> > to
> >
> > *tf = *(__be16 *)&flags;
>
> Something is fishy with rt_tcp_set_flags. Shouldn't we rather ensure
> that only a __be16 flag value is passed to it?

I think the reason why flags are passed as __be32 is that they are defined
with the help of __constant_cpu_to_be32().

After reading some TCP related code in the kernel I think that this
issue is properly fixed by

tcp_flag_word(th) = flags;

I will test this for little endian. Phong, can you test this on your
machine?

--
Sebastian



Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here<http://www.ddc-web.com/Profile/EmailPrivacy.aspx> to view our 
privacy statement.

RE: [Xenomai] [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

[Pham, Phong]

Hi Sebastian,

The issue has to do with endianness.  We are running PowerPC (big endian).  So 
in rt_tcp_set_flags(), flags is 32-bit wide and *tf is 16-bit wide.  I modified 
the line
from:

*tf = flags;

to

*tf = *(__be16 *)&flags;

and that does the job.

Now I encounter a different problem,

recv() returns 0 bytes but I know my FTP server sends a packet (seen by 
WireShark).  Can you point me where is the recv() implemented in tcp.c?  Is it 
rt_tcp_rcv or rt_tcp_recvmsg?

Phong.


-Original Message-
From: Sebastian Smolorz [mailto:sebastian.smol...@gmx.de]
Sent: Wednesday, October 31, 2018 7:08 AM
To: Pham, Phong
Cc: Jan Kiszka; xenomai@xenomai.org; Hillman, Robert
Subject: Re: [Xenomai] [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to 
be built

Pham, Phong wrote:
> This is what I see when my RTnet box, my laptop, and my FTP server
> (local on laptop) is on the same subnet 192.168.7.0:
>
> 192.168.7.79 is my RTnet box.

Which processor architecture is it?

> I used my laptop (192.168.7.106) to
> ping the RTnet box which is what you see with ICMP protocol.  The
> first TCP packet sent by my RTnet box (packet # 11) has the SYN bit
> not set.  (see attached image.  I pulled in your patch along with the
> patch named "rtdm: add integer file descriptor to struct rtdm_fd" to
> get TCP to compile.

So you don't use latest next? Do you use stable? Did you made changes to
the source code we are not aware of?

> Any advice you may have?  Do you know which
> relevant routine goes and set the TCP SYN bit that I can start
> looking?

It is set in rt_tcp_connect() line 1536:

ret = rt_tcp_send(ts, TCP_FLAG_SYN);

in kernel/drivers/net/stack/ipv4/tcp/tcp.c

--
Sebastian



Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here<http://www.ddc-web.com/Profile/EmailPrivacy.aspx> to view our 
privacy statement.

RE: [Xenomai] [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

[Pham, Phong]

Hi Sebastian,

This is what I see when my RTnet box, my laptop, and my FTP server (local on 
laptop) is on the same subnet 192.168.7.0:

192.168.7.79 is my RTnet box.  I used my laptop (192.168.7.106) to ping the 
RTnet box which is what you see with ICMP protocol.  The first TCP packet sent 
by my RTnet box (packet # 11) has the SYN bit not set.  (see attached image.  I 
pulled in your patch along with the patch named "rtdm: add integer file 
descriptor to struct rtdm_fd" to get TCP to compile.  Any advice you may have?  
Do you know which relevant routine goes and set the TCP SYN bit that I can 
start looking?

Phong.


-Original Message-
From: Sebastian Smolorz [mailto:sebastian.smol...@gmx.de]
Sent: Tuesday, October 30, 2018 1:17 PM
To: Pham, Phong
Cc: Jan Kiszka; xenomai@xenomai.org; Hillman, Robert
Subject: Re: [Xenomai] [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to 
be built

Hi,

on 10/19/18 04:00 AM, Pham, Phong wrote:
> I do see a TCP packet sent out on the LAN when rt_dev_connect() is
> invoked; however, the packet itself is not valid.  The SYN flag in
> the TCP protocol is not set when the first TCP packet was sent.

Strange. Wireshark shows me that a connection initiated by a RTnet box
can be successfully established and that the SYN flag indeed is set.

--
Sebastian



Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here<http://www.ddc-web.com/Profile/EmailPrivacy.aspx> to view our 
privacy statement.
-- next part --
A non-text attachment was scrubbed...
Name: wireshark_capture.png
Type: image/png
Size: 135068 bytes
Desc: wireshark_capture.png
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20181030/3faf5119/attachment.png>
-- next part --
A non-text attachment was scrubbed...
Name: wireshark_capture.png
Type: image/png
Size: 135068 bytes
Desc: wireshark_capture.png
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20181030/3faf5119/attachment-0001.png>

Re: [Xenomai] [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to be built

[Pham, Phong]

Hi Sebastian,

I verified your changes on a real hardware, Xenomai stack + network drivers.  
rt_dev_connect  returns 0 when attempting to connect to my FTP server 
204.75.16.51; however, there is no packet sent on the network.  Below is my 
routing table.

# ./rtroute
Host Routing Table
HashDestination HW Address  Device
01  192.168.7.1 A8:9D:21:34:8C:65   rteth0
3F  192.168.7.255   FF:FF:FF:FF:FF:FF   rteth0

Network Routing Table
HashDestination MaskGateway
10  204.75.16.51255.255.255.255 192.168.7.1

Another observation is if I setup my local FTP server (192.168.7.152) on the 
same LAN (my system has IP 192.168.7.79)
# ./rtroute
Host Routing Table
HashDestination HW Address  Device
18  192.168.7.152   50:7B:9D:2D:95:01   rteth0
3F  192.168.7.255   FF:FF:FF:FF:FF:FF   rteth0

Network Routing Table
HashDestination MaskGateway
10  204.75.16.51255.255.255.255 192.168.7.1

I do see a TCP packet sent out on the LAN when rt_dev_connect() is invoked; 
however, the packet itself is not valid.  The SYN flag in the TCP protocol is 
not set when the first TCP packet was sent.

Could you look into these issues where at least one box talking to another over 
a LAN?  One best ex. is a socket programming exercise downloading a simple file 
using FTP protocol?  (no need for bells & whistle of FTP completeness; just 
simple download).  Also let me know if I can help you in anyway since I have 
the hw and my Ethernet driver is functional (able to ping).

Thanks,
Phong.

-Original Message-
From: Xenomai [mailto:xenomai-boun...@xenomai.org] On Behalf Of Sebastian 
Smolorz
Sent: Wednesday, October 17, 2018 9:10 AM
To: Jan Kiszka
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] [PATCH 0/4] net/tcp: Fix several bugs and allow rttcp to 
be built

On 17.10.18 13:44, Jan Kiszka wrote:
> On 17.10.18 13:31, Sebastian Smolorz wrote:
> > This patch series makes RTnet's tcp module usable again. It was not
> > selectable in Kconfig for a long time. Now it is supposed to work in
> > the way it worked when RTnet was a separate project for Xenomai 2.
>
> Despite the "supposed", can I assume you tested it already
> successfully with some real workload?

Tested it under QEMU with the rttcp example (rttcp-server and rttcp-
client) over rtlo. Tests on real hardware are pending and planned in the
next few days. No problem if you want to postpone the patches until I
report the successful outcome of those tests.

--
Sebastian



___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here to view our 
privacy statement.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Does RTNET supports TCP?

[Pham, Phong]

Hi Sebastian,

You wrote:
>Currently, I am working on fixing two additional bugs in rttcp and I can
>include this compile bug in rt_tcp_accept() Phong found. I will soon
>come up with a patch series, I think.

Thanks and looking for your fix.  Actually the compilation is probably a 
trivial fix for you; however, since I have no familiarity of the code at this 
moment, could you provide the instruction on how to modify the code to make it 
compilable?  I am still in the early process of establishing a connection so I 
can work out any further issues while waiting for your official fix (which 
includes several other bugs)?  Thanks.

Hi Steven,

You wrote:
> Try SOCK_DGRAM and see if it
> works. If not, then are you sure you have rtnet drivers for your
> network device compiled and ready to use? Remember, the driver for
> your network device must be realtime-safe.

My current network device driver is actually working because it is the one 
provided/ported by Xenomai (even though I did have to modify the buffer size on 
one of the buffers).  In fact, I am able to ping to successfully (but ping uses 
ICMP).  I need TCP because our current application (VxWorks based) accesses a 
FTP server to retrieve files and I would like to maintain that resemblance in 
Linux.  What I don't need is the real-time functionality.  I choose to use 
RTNET b/c the network driver is supported by Xenomai and hope for a quick path 
to completion.

Phong.


-Original Message-
From: Xenomai [mailto:xenomai-boun...@xenomai.org] On Behalf Of Sebastian 
Smolorz
Sent: Saturday, October 06, 2018 1:08 AM
To: xenomai@xenomai.org; steven.see...@nasa.gov
Cc: Hillman, Robert
Subject: Re: [Xenomai] Does RTNET supports TCP?

Hi all,

Steven Seeger wrote:
> On Thursday, October 4, 2018 9:02:46 PM EDT Pham, Phong wrote:
> > Hi,
> >
> > I noticed starting Xenomai 3.0.1 until now (3.0.7), there is net/ in
> > .../kernel/drivers/ and in ../kernel/drivers/net/stack/ipv4/Kconfig
> >
> > # source "drivers/xenomai/net/stack/ipv4/tcp/Kconfig"
>
> I don't know why this is commented out. It looks like Gilles's initial
> import of this file in commit
> 106ffba7b55d506143966ff16158ee79b0007336 had it commented out.
>
> I know that UDP is typically used with RTNET. TCP is complicated and
> has a lot of timers and dynamic state that makes it less than
> desirable for hard- realtime systems. Probably Jan should chime in on
> this. I think he has the most experience using RTnet at this point.
>
> > 5)  When I created a socket with rt_dev_socket(AF_INET,
> > SOCK_STREAM, 0); and attempting to rt_dev_connect(fd,
> > server_ip_addr,
> > sizeof(server_ip_addr)), I get errno = 25 (Inappropriate ioctl for
> > device).>
> >  Does it mean b/c TCP is not supported in RTnet and I attempt to
> >  connect>
> > via TCP (w/ socket SOCK_STREAM)?
>
> Sorry I can't answer the other questions, as I am not working on rtnet
> myself. However, I would suspect that since TCP doesn't compile that
> is why SOCK_STREAM is not working.

In the old days of Xenomai 2.6 rttcp worked so I am confident that we can
make it work again.

Currently, I am working on fixing two additional bugs in rttcp and I can
include this compile bug in rt_tcp_accept() Phong found. I will soon
come up with a patch series, I think.

> Try SOCK_DGRAM and see if it
> works. If not, then are you sure you have rtnet drivers for your
> network device compiled and ready to use? Remember, the driver for
> your network device must be realtime-safe. I recall seeing a guide
> for some simple changes to make to a Linux ethernet driver to use as
> a starting point for porting it to RTNET, but I can't seem to find
> it. Anyone?

Do you mean kernel/drivers/net/doc/README.drvporting?

--
Sebastian





___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here<http://www.ddc-web.com/Profile/EmailPrivacy.aspx> to view our 
privacy statement.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Does RTNET supports TCP?

[Pham, Phong]

Hi,

I noticed starting Xenomai 3.0.1 until now (3.0.7), there is net/ in 
.../kernel/drivers/ and in ../kernel/drivers/net/stack/ipv4/Kconfig

# source "drivers/xenomai/net/stack/ipv4/tcp/Kconfig"

If I uncomment out the above line, it leads to compilation error in tcp.c.

Questions:

1)  Is the commented out line intentional? (short run and long run)

2)  When will TCP be supported in RTnet?

3)  Will it ever be supported?

4)  Will this statement still holds true in tcp/Kconfig? "When the RTnet 
IPv4 is enabled while this feature is disabled, TCP will be forwarded to the 
Linux network stack."

5)  When I created a socket with rt_dev_socket(AF_INET, SOCK_STREAM, 0); 
and attempting to rt_dev_connect(fd, server_ip_addr, sizeof(server_ip_addr)), I 
get errno = 25 (Inappropriate ioctl for device).  Does it mean b/c TCP is not 
supported in RTnet and I attempt to connect via TCP (w/ socket SOCK_STREAM)?

Phong.

Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here to view our 
privacy statement.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] thread executing udd_register_device() is not rescheduled again

[Pham, Phong]

Hi Philippe and all,

While I may have too many questions from my previous email, I think what I 
really need is someone to confirm my question #2 where calling 
udd_register_device() (in kernel space of course) is inappropriate in Xenomai 
when initiating the process is from a user space via an ioctl of an RTDM device?

Specifically,

User space:
ioctl(fd_from_mmap_rtdm_device, DO_MY_WORK, NULL);

where the rtdm_device provides my custom ioctl implementation.

Kernel space:
struct udd_device my_new_device;
rtdm_device_iotcl(struct rtdm_fd *fd, unsigned int request, void *arg)
{
switch (request)
{
  case DO_MY_WORK:
...
udd_register_device(&my_new_device);
...
  break;
}

is illegal in Xenomai?

Any way of getting around this?
Thanks,
Phong.

-Original Message-
From: Pham, Phong
Sent: Thursday, June 14, 2018 3:58 PM
To: 'Philippe Gerum'; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: RE: [Xenomai] thread executing udd_register_device() is not 
rescheduled again



Hi Philippe,

I dig up a little more; the Linux "current" thread calls device_create() Linux 
API eventually lead to devtmpfs_create_node(); upon wake_up_process(kdevtmpfs 
thread), kdevtmpfs becomes available (expected).  However, after 
wait_for_completion(), the "current" running thread is no longer "current" but 
rather "current" thread is now switched to the initial process I invoked which 
was sleeping when device_create() is called.  The once current thread that 
execute device_create() eventually calls xnthread_suspend() and hang.  The 
"current" thread now doesn't do anything either.

1) Does the detailed description above "fits" with what you mentioned 
"secondary mode"?
2) Does it mean that udd_register_device() usage is inappropriate when calling 
from a user space via an ioctl of an RTDM device?

3) I noticed there is nrt calls in kernel/xenomai/posix/memory.c.  Will this be 
a good example of calling an ioctl that will create a rtdm device mapper?  (I 
haven't read the code in detail and hope you would provide a quick yes/no 
suggestion before I proceed to save time.)
4) If (3) is not an ex., does it mean I have to create a Linux file mapper 
(instead of rtdm file mapper) without Xenomai involvement, (ie. equivalent to 
udd_register_device() functionality but strictly Linux)?

Phong.

-Original Message-----
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Wednesday, June 13, 2018 11:10 PM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: [Xenomai] thread executing udd_register_device() is not 
rescheduled again

On 06/13/2018 10:26 PM, Pham, Phong wrote:
>
> Hi,
>
> I currently have a bunch of rtdm devices.  One of the devices, from 
> userspace, I use ioctl() to get to kernel space.  When in kernel space, I 
> create anther rtdm device (using udd_register_device() API).  The API returns 
> success without any issue.  However, upon exiting the kernel space, in 
> handle_root_syscall (), execute xnthread_relax(),xnthread_suspend(),
>
>   /*
>   * If the current thread is being relaxed, we must have been
>   * called from xnthread_relax(), in which case we introduce an
>   * opportunity for interrupt delivery right before switching
>   * context, which shortens the uninterruptible code path.
>   *
>   * We have to shut irqs off before __xnsched_run() though: if
>   * an interrupt could preempt us in ___xnsched_run() right
>   * after the call to xnarch_escalate() but before we grab the
>   * nklock, we would enter the critical section in
>   * xnsched_run() while running in secondary mode, which would
>   * defeat the purpose of xnarch_escalate().
>   */
>   if (likely(thread == sched->curr)) {
>  xnsched_set_resched(sched);
>  if (unlikely(mask & XNRELAX)) {
>xnlock_clear_irqon(&nklock);
>splmax();
>__xnsched_run(sched);
>return;
>  }
>  /*
>  * If the thread is runnning on another CPU,
>  * xnsched_run will trigger the IPI as required.
>  */
>  __xnsched_run(sched);
>  goto out;
>   }
>
> and the current thread never runs again (ie. never exits xnthread_suspend()).
>
> I noticed that  udd_register_device() eventually uses device_create() Linux 
> API to create the files

Re: [Xenomai] thread executing udd_register_device() is not rescheduled again

[Pham, Phong]

Hi Philippe,

I dig up a little more; the Linux "current" thread calls device_create() Linux 
API eventually lead to devtmpfs_create_node(); upon wake_up_process(kdevtmpfs 
thread), kdevtmpfs becomes available (expected).  However, after 
wait_for_completion(), the "current" running thread is no longer "current" but 
rather "current" thread is now switched to the initial process I invoked which 
was sleeping when device_create() is called.  The once current thread that 
execute device_create() eventually calls xnthread_suspend() and hang.  The 
"current" thread now doesn't do anything either.

1) Does the detailed description above "fits" with what you mentioned 
"secondary mode"?
2) Does it mean that udd_register_device() usage is inappropriate when calling 
from a user space via an ioctl of an RTDM device?

3) I noticed there is nrt calls in kernel/xenomai/posix/memory.c.  Will this be 
a good example of calling an ioctl that will create a rtdm device mapper?  (I 
haven't read the code in detail and hope you would provide a quick yes/no 
suggestion before I proceed to save time.)
4) If (3) is not an ex., does it mean I have to create a Linux file mapper 
(instead of rtdm file mapper) without Xenomai involvement, (ie. equivalent to 
udd_register_device() functionality but strictly Linux)?

Phong.

-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Wednesday, June 13, 2018 11:10 PM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: [Xenomai] thread executing udd_register_device() is not 
rescheduled again

On 06/13/2018 10:26 PM, Pham, Phong wrote:
>
> Hi,
>
> I currently have a bunch of rtdm devices.  One of the devices, from 
> userspace, I use ioctl() to get to kernel space.  When in kernel space, I 
> create anther rtdm device (using udd_register_device() API).  The API returns 
> success without any issue.  However, upon exiting the kernel space, in 
> handle_root_syscall (), execute xnthread_relax(),xnthread_suspend(),
>
>   /*
>   * If the current thread is being relaxed, we must have been
>   * called from xnthread_relax(), in which case we introduce an
>   * opportunity for interrupt delivery right before switching
>   * context, which shortens the uninterruptible code path.
>   *
>   * We have to shut irqs off before __xnsched_run() though: if
>   * an interrupt could preempt us in ___xnsched_run() right
>   * after the call to xnarch_escalate() but before we grab the
>   * nklock, we would enter the critical section in
>   * xnsched_run() while running in secondary mode, which would
>   * defeat the purpose of xnarch_escalate().
>   */
>   if (likely(thread == sched->curr)) {
>  xnsched_set_resched(sched);
>  if (unlikely(mask & XNRELAX)) {
>xnlock_clear_irqon(&nklock);
>splmax();
>__xnsched_run(sched);
>return;
>  }
>  /*
>  * If the thread is runnning on another CPU,
>  * xnsched_run will trigger the IPI as required.
>  */
>  __xnsched_run(sched);
>  goto out;
>   }
>
> and the current thread never runs again (ie. never exits xnthread_suspend()).
>
> I noticed that  udd_register_device() eventually uses device_create() Linux 
> API to create the files.  If I do not call device_create() and execute 
> everything else, then my current thread does not hang (ie. runs til 
> completion).  Any insight into Xenomai implementation causes the Xenomai 
> scheduler to behave this way when Linux device_create() API is invoked?
>

You are basically looking at your thread running in secondary mode -
therefore suspended Xenomai-wise - caused by the non-rt ioctl() call it
just issued. It still runs, but under the control of the Linux
scheduler. I'm unsure to understand which problem you would like to report.

--
Philippe.
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the c

[Xenomai] thread executing udd_register_device() is not rescheduled again

[Pham, Phong]

Hi,

I currently have a bunch of rtdm devices.  One of the devices, from userspace, 
I use ioctl() to get to kernel space.  When in kernel space, I create anther 
rtdm device (using udd_register_device() API).  The API returns success without 
any issue.  However, upon exiting the kernel space, in handle_root_syscall (), 
execute xnthread_relax(),xnthread_suspend(),

  /*
  * If the current thread is being relaxed, we must have been
  * called from xnthread_relax(), in which case we introduce an
  * opportunity for interrupt delivery right before switching
  * context, which shortens the uninterruptible code path.
  *
  * We have to shut irqs off before __xnsched_run() though: if
  * an interrupt could preempt us in ___xnsched_run() right
  * after the call to xnarch_escalate() but before we grab the
  * nklock, we would enter the critical section in
  * xnsched_run() while running in secondary mode, which would
  * defeat the purpose of xnarch_escalate().
  */
  if (likely(thread == sched->curr)) {
 xnsched_set_resched(sched);
 if (unlikely(mask & XNRELAX)) {
   xnlock_clear_irqon(&nklock);
   splmax();
   __xnsched_run(sched);
   return;
 }
 /*
 * If the thread is runnning on another CPU,
 * xnsched_run will trigger the IPI as required.
 */
 __xnsched_run(sched);
 goto out;
  }

and the current thread never runs again (ie. never exits xnthread_suspend()).

I noticed that  udd_register_device() eventually uses device_create() Linux API 
to create the files.  If I do not call device_create() and execute everything 
else, then my current thread does not hang (ie. runs til completion).  Any 
insight into Xenomai implementation causes the Xenomai scheduler to behave this 
way when Linux device_create() API is invoked?

Thanks,
Phong.

Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here to view our 
privacy statement.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] 2 potential udd drivers fixes

[Pham, Phong]

Hi,

Currently, a user space driver write() API does not clear the number of 
interrupts occurred since the last read() API.  Instead it disable interrupt 
unless a UDD_RTIOC_IRQEN request comes in to enable interrupt.  The fact that 
ioctl() does support these requests makes write(UDD_RTIOC_IRQEN/anything) a 
redundant and inappropriate API.  Code change is to set both event  count and 
context->event_count to 0.

The second issue is the event ur->pulse needs to be cleared in udd_read_rt() 
because a select() on the file descriptor will return immediately as a result 
of a previous select() call when both select() invocation is on the same file 
descriptor even when the read() is sandwiched in between the select() calls 
while no interrupt occurs for the second select() call.

Below are the suggested code fixes for both issues.  I am using 4.9.51 Linux 
kernel with patch: ipipe-core-4.9.51-powerpc-3.

Phong.

PS: If you cannot see the image , enclosed is the file with fix and the 
original file.
[cid:image002.png@01D3EE17.938016A0]
Phong.


Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's and its subsidiaries privileged and proprietary information. It 
is intended solely for the use of the individual or entity to whom it is 
addressed. If you are not the named recipient of this transmission, any 
disclosure, copying, distribution or reliance on the contents of this message 
is prohibited. If you received this e-mail in error, please destroy it and any 
attached files and notify me immediately.

Click Here to view our 
privacy statement.
-- next part --
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 166033 bytes
Desc: image002.png
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: udd.c.orig
Type: application/octet-stream
Size: 17134 bytes
Desc: udd.c.orig
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: udd.c
URL: 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] potentially missing timer rating check in select_root_only_timer()

[Pham, Phong]

Hi Jan,

In my scenario, it is a single CPU Powerpc system.  What I was intending to do 
is replacing the decrementer (Powerpc specific count down timer) clockevent 
with my timer clockevent.  (My timer is located somewhere else on the chip 
accessible via memory mapped IO).   According to Linux, user can change the 
rating and kernel will select the highest rating timer for you.  So I change my 
timer rating to be higher than the decrementer.  In ipipe_select_timers(), it 
will pick the first timer found on the timers linked list.  That linked list of 
timers is also sorted by highest priority first.  However, when 
select_root_only_timer() is executed, the code goes thru the entire list and 
select the last one, the one with the lowest rating.

W/ regard to "percpu_timer->rating" coding style, yes, this can be done better 
but since I am on single cpu, what I did "does the job".  I recalled there are 
a bunch of macros just to change a variable; this can certainly be changed.  
The focus is more on checking the ratings.

I am also not familiar with the code enough so I may have misunderstandings on 
their intended usage.  Maybe you could clarify them for me.

Thanks,
Phong.

PS: For our need, I decided I will no longer pusue the path of replace the 
decrementer with a different timer.  But I just thought to bring up my 
observation with regard to selecting the highest timer rating.

-Original Message-
From: Jan Kiszka [mailto:jan.kis...@siemens.com]
Sent: Tuesday, May 01, 2018 10:34 PM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: potentially missing timer rating check in select_root_only_timer()

Hi Phong,

On 2018-05-02 03:13, Pham, Phong wrote:
> Hi,
>
> I am suspecting that in kernel/ipipe/timer.c:select_root_only_timer()
>
> When t->irq == per_cpu(ipipe_percpu.hrtimer_irq, icpu), a condition to test 
> the timer rating against current timer rating before installing the timer is 
> missing.  That is t->rating > percpu_timer->rating (combined with same irq #) 
> before the condition becomes true.

Conceptually, I-pipe timers should have highest rating. Can you explain
in more details why it should be there?

Also note that your own code looks suspicious: percpu_timer is a per-cpu
variable but is not accesses as such.

Jan

--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] potentially missing timer rating check in select_root_only_timer()

[Pham, Phong]

Hi,

I am suspecting that in kernel/ipipe/timer.c:select_root_only_timer()

When t->irq == per_cpu(ipipe_percpu.hrtimer_irq, icpu), a condition to test the 
timer rating against current timer rating before installing the timer is 
missing.  That is t->rating > percpu_timer->rating (combined with same irq #) 
before the condition becomes true.

Here's screenshot:
[cid:image001.png@01D3E177.63116AC0]

Phong.

Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 100938 bytes
Desc: image001.png
URL: 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] mmap when using in conjunction with mapper to retrieve memory mapped IO space

[Pham, Phong]

Hi Philippe,

Below are the snippets compiled with -fPIC in the DSO.  If I don't compile with 
-fPIC, I get this error:

# bin/vxapp
bin/vxapp: error while loading shared libraries: /usr/xenomai/lib/libscs750.so: 
R_PPC_REL24 relocation at 0x0ffacec4 for symbol `munmap' out of range

If I do compile with -fPIC for my DSO, this is the snippet on the executable 
(ie. from your example, that would be "vxapp" executable.)

...
...
int fd_eeprom = open("/dev/rtdm/eeprom,mapper0", O_RDWR);
uint32_t baseAddr_eeprom = (volatile uint32_t)mmap(NULL, 
SCS_EEPROM_PHYSICAL_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd_eeprom, 0);
printf("%s():  baseAddr_eeprom = 0x%08x\n", __func__, baseAddr_eeprom);
...
...

Below is the snippet from my DSO:

...
...
int fdm = open("/dev/rtdm/eeprom,mapper0", O_RDWR);
uint32_t baseAddr = -2;

printf("%s(): baseAddr = 0x%08x, errno = %d\n", __func__, baseAddr, errno);
baseAddr = (volatile uint32_t)mmap(NULL, SCS_EEPROM_PHYSICAL_SIZE, PROT_READ | 
PROT_WRITE, MAP_SHARED, fdm, 0);

if (baseAddr = -1)
{
printf("%s(): baseAddr = 0x%08x, errno = %d\n", __func__, baseAddr, errno);
}


For my DSO, LDFLAGS := $(shell $(XENO_CONFIG) --no-auto-init --posix --vxworks 
--ldflags) is in the makefile.  For my "vxapp", LDFLAGS := $(shell 
$(XENO_CONFIG) --posix --vxworks --ldflags)

Output:
scsEepromTest():  baseAddr_eeprom = 0x366ee000
sysEepromSet(): baseAddr = 0xfffe, errno = 0
sysEepromSet(): baseAddr = 0x, errno = 0

scsEepromTest() resides in the "vxapp" executable and sysEepromSet() resides in 
the DSO.

Phong.

-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, April 19, 2018 12:26 AM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: [Xenomai] mmap when using in conjunction with mapper to retrieve 
memory mapped IO space

On 04/19/2018 01:02 AM, Pham, Phong wrote:
> “This is likely happening because the default auto-init glue module for
> a final executable is mentioned in the flags, you either want to pass
> --auto-init-solib if you do need auto-init for bootstrapping a DSO, or
> --no-auto-init if you don't care about auto-bootstrap, along with
> --ldflags to xeno-config.
>
>
>
> http://www.xenomai.org/documentation/xenomai-3/html/man1/xeno-config/index.html“
>
>
>
>
>
> I see.  After adding either --auto-init-solib or --no-auto-init when
> compiling for library, along with compiler option -fPIC, mmap() still
> returns -1; (W/out -fPIC, munmap() cannot be relocated (similar types of
> error like before).

xeno-config --ldflags will return the Xenomai-related flags for linking,
which -fPIC is not. If you plan for building a DSO, you need to apply
the common rules stated in the ld documentation, which include
mentioning  -fPIC / -fpic for shared libs. This is not a Xenomai issue.

  However, errno is 0.  How come errno returns “no
> error” when mmap() returns failure?
>

Please post a test code snippet illustrating the problem.

--
Philippe.
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] mmap when using in conjunction with mapper to retrieve memory mapped IO space

[Pham, Phong]

“This is likely happening because the default auto-init glue module for a final 
executable is mentioned in the flags, you either want to pass --auto-init-solib 
if you do need auto-init for bootstrapping a DSO, or --no-auto-init if you 
don't care about auto-bootstrap, along with --ldflags to xeno-config.



http://www.xenomai.org/documentation/xenomai-3/html/man1/xeno-config/index.html“





I see.  After adding either --auto-init-solib or --no-auto-init when compiling 
for library, along with compiler option -fPIC, mmap() still returns -1; (W/out 
-fPIC, munmap() cannot be relocated (similar types of error like before).  
However, errno is 0.  How come errno returns “no error” when mmap() returns 
failure?



Phong.



-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Wednesday, April 18, 2018 12:58 PM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: [Xenomai] mmap when using in conjunction with mapper to retrieve 
memory mapped IO space



On 04/18/2018 09:33 PM, Pham, Phong wrote:

>

> Hi,

>

> Instead of  symbol `mmap' out of range, I now have symbol `malloc' out of 
> range.  I removed  all the -fPIC in my environment.  I have to recompile 
> libc???  I never compiled libc and wants to avoid it.



Of course not.



>

> Any suggestion on

> R_PPC_REL24 relocation at 0x0ffacd3c for symbol `mmap/malloc' out of

> range

>



This is likely happening because the default auto-init glue module for a final 
executable is mentioned in the flags, you either want to pass --auto-init-solib 
if you do need auto-init for bootstrapping a DSO, or --no-auto-init if you 
don't care about auto-bootstrap, along with --ldflags to xeno-config.



http://www.xenomai.org/documentation/xenomai-3/html/man1/xeno-config/index.html



>

> I suggest you add the missing --posix in the LDFLAGS as well.  After all, I 
> copied my app from this very snippet and that's why I get the error.

>



As mentioned in the doc you are referring to, this example is about building a 
trivial VxWorks app, not a POSIX one.



--

Philippe.

Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] mmap when using in conjunction with mapper to retrieve memory mapped IO space

[Pham, Phong]

Hi,

Instead of  symbol `mmap' out of range, I now have symbol `malloc' out of 
range.  I removed  all the -fPIC in my environment.  I have to recompile 
libc???  I never compiled libc and wants to avoid it.

Any suggestion on
R_PPC_REL24 relocation at 0x0ffacd3c for symbol `mmap/malloc' out of range

is appreciated.

This is after I add LDFLAGS (from xeno-config) during the process of creating a 
shared library.

Phong.

-Original Message-----
From: Pham, Phong
Sent: Tuesday, April 17, 2018 7:22 PM
To: 'Philippe Gerum'; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: RE: [Xenomai] mmap when using in conjunction with mapper to retrieve 
memory mapped IO space


Hi Philippe and all,

Regarding "Your app may be missing symbol wrapping. Please check out this doc:

https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__cobalt__api.html";

Thanks for the tip.  In the Makefile fragment from this link:
https://xenomai.org/building-applications-with-xenomai-3-x/

I suggest you add the missing --posix in the LDFLAGS as well.  After all, I 
copied my app from this very snippet and that's why I get the error.

On the same idea (using LDFLAGS from xeno-config), I would like to create a 
dynamically linked library (.so).  Without the LDFLAGS from xeno-config, my 
library loads fine (but will fail when mmap is called); with the LDFLAGS that 
has --posix, I get this error when loading:

R_PPC_REL24 relocation at 0x0ffacd3c for symbol `mmap' out of range

Does this mean I have to recompile all of the Xenomai library with -fPIC?  I 
didn't see anything regarding that choice during "configure" but peeking into 
the configure script, there are a few -fPIC occurrences.  Currently, I am using 
"Building the PPC32 libraries" instruction and also I didn't need to perform 
./script/bootstrap b/c I am building it from the release tarball.

$xenomai_root/configure --host=powerpc-linux --with-core=cobalt 
--enable-debug=symbols

Suggestion on the error above and/or compiling Xenomai library w/ -fPIC is 
appreciated.

Just fyi w/ regard to your updated "comment fix" on how to mmap(), I don't know 
if you need to update udd.h (right above struct udd_memregion) as well.  i.e. 
the same comment exists there but don't know if the comment there is retrieved 
from the location where you made the "comment fix".

Phong.

-Original Message-----
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, April 12, 2018 1:58 AM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: [Xenomai] mmap when using in conjunction with mapper to retrieve 
memory mapped IO space

On 04/10/2018 09:03 PM, Pham, Phong wrote:
>
> Hi,
>
> According to page 651
> https://xenomai.org/documentation/xenomai-3/pdf/xeno3prm.pdf
>
>
> This will make such region accessible via the mapper device using the
> following sequence of code, via the default ->mmap() handler from the UDD 
> core:
> int fd, fdm;
> void *p;
> fd = open("/dev/foocard", O_RDWR);
> fdm = open("/dev/foocard,mapper@2", O_RDWR); p = mmap(NULL, 4096,
> PROT_READ|PROT_WRITE, 0, fdm, 0);
>
>
> I have several questions:
>
> 1)  It looks like the 4th argument of mmap (the one to the left of "fdm") 
> needs to be either MAP_SHARED or MAP_PRIVATE
>
> 2)  The "@" character right after "mapper" is not valid (ie. there should 
> be no "@" character at all)
>
> 3)  /dev/foocard should be /dev/rtdm/foocard


Fixed, thanks.

https://xenomai.org/documentation/xenomai-3/html/xeno3prm/structudd__memregion.html#udd_memory_region

>
> here's my real question:
>
> Assuming all 3 of the above is valid from user space, and on the
> kernel space, I followed the ex. to create memory region, etc. such
> that I do see my device
>
> # ls -l dev/rtdm
> crw---1 root root  252,   0 Jan  1 00:00 autotune
> crw---1 root root  247,   0 Jan  1 00:00 eeprom
> crw---1 root root  246,   0 Jan  1 00:00 eeprom,mapper0
> crw---1 root root  254,   0 Jan  1 00:00 memdev-private
> crw---1 root root  254,   1 Jan  1 00:00 memdev-shared
> crw---1 root root  253,   0 Jan  1 00:00 memdev-sys
> crw---1 root root  249,   0 Jan  1 00:00 mmio
> crw---1 root root  248,   0 Jan  1 00:00 mmio,mapper0
> crw---1 root root  248,   1 Jan  1 00:00 mmio,mapper1
> crw---1 root root  248,   2 Jan  1 00:00 mmio,mapper2
> crw---1 root root  248,   3 Jan  1 00:00 mmio,mapper3
> crw---1 root root  248,   4 Jan  1 00:00 mmio,mapper4
> crw---1 root root  250,   0 Jan  1 00:00 switcht

Re: [Xenomai] mmap when using in conjunction with mapper to retrieve memory mapped IO space

[Pham, Phong]

Hi Philippe and all,

Regarding "Your app may be missing symbol wrapping. Please check out this doc:

https://xenomai.org/documentation/xenomai-3/html/xeno3prm/group__cobalt__api.html";

Thanks for the tip.  In the Makefile fragment from this link:
https://xenomai.org/building-applications-with-xenomai-3-x/

I suggest you add the missing --posix in the LDFLAGS as well.  After all, I 
copied my app from this very snippet and that's why I get the error.

On the same idea (using LDFLAGS from xeno-config), I would like to create a 
dynamically linked library (.so).  Without the LDFLAGS from xeno-config, my 
library loads fine (but will fail when mmap is called); with the LDFLAGS that 
has --posix, I get this error when loading:

R_PPC_REL24 relocation at 0x0ffacd3c for symbol `mmap' out of range

Does this mean I have to recompile all of the Xenomai library with -fPIC?  I 
didn't see anything regarding that choice during "configure" but peeking into 
the configure script, there are a few -fPIC occurrences.  Currently, I am using 
"Building the PPC32 libraries" instruction and also I didn't need to perform 
./script/bootstrap b/c I am building it from the release tarball.

$xenomai_root/configure --host=powerpc-linux --with-core=cobalt 
--enable-debug=symbols

Suggestion on the error above and/or compiling Xenomai library w/ -fPIC is 
appreciated.

Just fyi w/ regard to your updated "comment fix" on how to mmap(), I don't know 
if you need to update udd.h (right above struct udd_memregion) as well.  i.e. 
the same comment exists there but don't know if the comment there is retrieved 
from the location where you made the "comment fix".

Phong.

-Original Message-
From: Philippe Gerum [mailto:r...@xenomai.org]
Sent: Thursday, April 12, 2018 1:58 AM
To: Pham, Phong; xenomai@xenomai.org
Cc: Hillman, Robert
Subject: Re: [Xenomai] mmap when using in conjunction with mapper to retrieve 
memory mapped IO space

On 04/10/2018 09:03 PM, Pham, Phong wrote:
>
> Hi,
>
> According to page 651
> https://xenomai.org/documentation/xenomai-3/pdf/xeno3prm.pdf
>
>
> This will make such region accessible via the mapper device using the
> following sequence of code, via the default ->mmap() handler from the UDD 
> core:
> int fd, fdm;
> void *p;
> fd = open("/dev/foocard", O_RDWR);
> fdm = open("/dev/foocard,mapper@2", O_RDWR); p = mmap(NULL, 4096,
> PROT_READ|PROT_WRITE, 0, fdm, 0);
>
>
> I have several questions:
>
> 1)  It looks like the 4th argument of mmap (the one to the left of "fdm") 
> needs to be either MAP_SHARED or MAP_PRIVATE
>
> 2)  The "@" character right after "mapper" is not valid (ie. there should 
> be no "@" character at all)
>
> 3)  /dev/foocard should be /dev/rtdm/foocard


Fixed, thanks.

https://xenomai.org/documentation/xenomai-3/html/xeno3prm/structudd__memregion.html#udd_memory_region

>
> here's my real question:
>
> Assuming all 3 of the above is valid from user space, and on the
> kernel space, I followed the ex. to create memory region, etc. such
> that I do see my device
>
> # ls -l dev/rtdm
> crw---1 root root  252,   0 Jan  1 00:00 autotune
> crw---1 root root  247,   0 Jan  1 00:00 eeprom
> crw---1 root root  246,   0 Jan  1 00:00 eeprom,mapper0
> crw---1 root root  254,   0 Jan  1 00:00 memdev-private
> crw---1 root root  254,   1 Jan  1 00:00 memdev-shared
> crw---1 root root  253,   0 Jan  1 00:00 memdev-sys
> crw---1 root root  249,   0 Jan  1 00:00 mmio
> crw---1 root root  248,   0 Jan  1 00:00 mmio,mapper0
> crw---1 root root  248,   1 Jan  1 00:00 mmio,mapper1
> crw---1 root root  248,   2 Jan  1 00:00 mmio,mapper2
> crw---1 root root  248,   3 Jan  1 00:00 mmio,mapper3
> crw---1 root root  248,   4 Jan  1 00:00 mmio,mapper4
> crw---1 root root  250,   0 Jan  1 00:00 switchtest
> crw---1 root root  251,   0 Jan  1 00:00 timerbench
>
>
> like /dev/rtdm/eeprom and /dev/rtdm/eeprom,mapper0  etc. I don't see
> my kernel hook ever gets called
>
>
> static struct udd_device eeprom = {
>   .device_flags = RTDM_NAMED_DEVICE,
>   .device_name = "eeprom",
>   .ops = {
>  .close = phong_scs750_close,
>  .open = phong_scs750_open,
>  .mmap = phong_scs750_mmap,
>   }
>
> By that, I mean phong_scs750_open, phong_scs750_mmap never gets invoked.  
> mmap() from user space returns

[Xenomai] mmap when using in conjunction with mapper to retrieve memory mapped IO space

[Pham, Phong]

Hi,

According to page 651
https://xenomai.org/documentation/xenomai-3/pdf/xeno3prm.pdf


This will make such region accessible via the mapper device using the following 
sequence of code, via
the default ->mmap() handler from the UDD core:
int fd, fdm;
void *p;
fd = open("/dev/foocard", O_RDWR);
fdm = open("/dev/foocard,mapper@2", O_RDWR);
p = mmap(NULL, 4096, PROT_READ|PROT_WRITE, 0, fdm, 0);


I have several questions:

1)  It looks like the 4th argument of mmap (the one to the left of "fdm") 
needs to be either MAP_SHARED or MAP_PRIVATE

2)  The "@" character right after "mapper" is not valid (ie. there should 
be no "@" character at all)

3)  /dev/foocard should be /dev/rtdm/foocard

here's my real question:

Assuming all 3 of the above is valid from user space, and on the kernel space, 
I followed the ex. to create memory region, etc. such that I do see my device

# ls -l dev/rtdm
crw---1 root root  252,   0 Jan  1 00:00 autotune
crw---1 root root  247,   0 Jan  1 00:00 eeprom
crw---1 root root  246,   0 Jan  1 00:00 eeprom,mapper0
crw---1 root root  254,   0 Jan  1 00:00 memdev-private
crw---1 root root  254,   1 Jan  1 00:00 memdev-shared
crw---1 root root  253,   0 Jan  1 00:00 memdev-sys
crw---1 root root  249,   0 Jan  1 00:00 mmio
crw---1 root root  248,   0 Jan  1 00:00 mmio,mapper0
crw---1 root root  248,   1 Jan  1 00:00 mmio,mapper1
crw---1 root root  248,   2 Jan  1 00:00 mmio,mapper2
crw---1 root root  248,   3 Jan  1 00:00 mmio,mapper3
crw---1 root root  248,   4 Jan  1 00:00 mmio,mapper4
crw---1 root root  250,   0 Jan  1 00:00 switchtest
crw---1 root root  251,   0 Jan  1 00:00 timerbench


like /dev/rtdm/eeprom and /dev/rtdm/eeprom,mapper0  etc. I don't see my kernel 
hook ever gets called


static struct udd_device eeprom = {
  .device_flags = RTDM_NAMED_DEVICE,
  .device_name = "eeprom",
  .ops = {
 .close = phong_scs750_close,
 .open = phong_scs750_open,
 .mmap = phong_scs750_mmap,
  }

By that, I mean phong_scs750_open, phong_scs750_mmap never gets invoked.  
mmap() from user space returns -1 with errno value of 19 (ENODEV).  Any advise?

Phong.
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] git://git.xenomai.org/ipipe.git points to Linux 3.18

[Pham, Phong]

Hi Greg,

If I git checkout v4.9.51 and then apply a patch, say 
ipipe-core-4.9.51-powerpc-3.patch, then it seems like the patch command is fine 
with it.  (I did the --dry-run and patch didn't ask any question)

However, if I git checkout ipipe-core-4.9.51-powerpc-3 and then issue the same 
patch command

patch -p1 --dry-run < ../ipipe-core-4.9.51-powerpc-3.patch

It asks me "Reversed (or previously applied) patch detected!  Assume -R? [n]

For a bunch of files.  If I answer y then there are some files the patch tool 
say "The next patch would create the file , which already exists!  
Assume -R [n]

So is it illegal to perform the patch on the same tag name like in my case 
ipipe-core-4.9.51-powerpc-3.patch?

Phong.

-Original Message-
From: Greg Gallagher [mailto:g...@embeddedgreg.com]
Sent: Monday, March 26, 2018 12:11 PM
To: Pham, Phong
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] git://git.xenomai.org/ipipe.git points to Linux 3.18

What branch did you checkout?  Try git checkout ipipe-4.9.y or if you want 
4.9.51 you can use the git tag  ipipe-core-4.9.51-x86-5.

On Mon, Mar 26, 2018 at 3:05 PM, Pham, Phong  wrote:
>
> Hi,
>
> git clone git://git.xenomai.org/ipipe.git and I get Linux version 3.18
> w/ the Xenomai patch included.  (In my .gitconfig, I remapped git://
> to use https:// protocol to get around my company blocking git port.)
>
> Should the Linux version be 4.9.51 (latest) instead of the older version?
>
> Is the https protocol link points to Linux 3.10 but the git protocol link 
> actually points to 4.9.51?
> Phong.
>
> Notice: This e-mail and any files transmitted with it may contain Data Device 
> Corporation's privileged and proprietary information. It is intended solely 
> for the use of the individual or entity to whom it is addressed. If you are 
> not the named recipient of this transmission, any disclosure, copying, 
> distribution or reliance on the contents of this message is prohibited. If 
> you received this e-mail in error, please destroy it and any attached files 
> and notify me immediately.
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] git://git.xenomai.org/ipipe.git points to Linux 3.18

[Pham, Phong]

Hi,

git clone git://git.xenomai.org/ipipe.git and I get Linux version 3.18 w/ the 
Xenomai patch included.  (In my .gitconfig, I remapped git:// to use https:// 
protocol to get around my company blocking git port.)

Should the Linux version be 4.9.51 (latest) instead of the older version?

Is the https protocol link points to Linux 3.10 but the git protocol link 
actually points to 4.9.51?
Phong.

Notice: This e-mail and any files transmitted with it may contain Data Device 
Corporation's privileged and proprietary information. It is intended solely for 
the use of the individual or entity to whom it is addressed. If you are not the 
named recipient of this transmission, any disclosure, copying, distribution or 
reliance on the contents of this message is prohibited. If you received this 
e-mail in error, please destroy it and any attached files and notify me 
immediately.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai