[Xenomai] something wrong with drivers/xenomai/net/driver/r8169.c

[Jack Lee]

When I build Linux 4.9.51 with the latest 
xenomai-3-7a038dfad8d1e48b065542c8cc2e39f6b5ee4f82.tar.bz2 



there get an error.


  CC [M]  drivers/xenomai/net/drivers/r8169.o
drivers/xenomai/net/drivers/r8169.c:131:12: error: ‘debug’ redeclared as 
different kind of symbol

 static int debug = -1;
    ^
In file included from arch/x86/xenomai/include/asm/xenomai/thread.h:25:0,
 from include/xenomai/cobalt/kernel/thread.h:35,
 from include/xenomai/cobalt/kernel/sched.h:24,
 from include/xenomai/rtdm/driver.h:37,
 from drivers/xenomai/net/stack/include/rtnet.h:99,
 from drivers/xenomai/net/stack/include/rtskb.h:32,
 from drivers/xenomai/net/stack/include/rtdev.h:37,
 from drivers/xenomai/net/stack/include/rtnet_port.h:32,
 from drivers/xenomai/net/drivers/r8169.c:82:
./arch/x86/include/asm/traps.h:13:17: note: previous declaration of 
‘debug’ was here

 asmlinkage void debug(void);

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

Re: [Xenomai] matching patch version to kernel version

[Greg Gallagher]

Hi,
  In my experience I usually try to get the patch that is the closest
match to my kernel version.  So I would try
ipipe-core-4.9.51-x86-4.patch, you will probably have to do some hand
fixes to resolve any conflicts if the patch doesn't apply cleanly.
That's usually how I approach it.  There could be better ways but for
me that's the most straight forward.

Hope this helps,

Greg

On Wed, Nov 29, 2017 at 4:53 PM, Steve Pavao  wrote:
> Hi all,
>
> I am building Yocto poky linux for an Intel board at head in Master branch in 
> Yocto poky, which currently results in a kernel version 4.9.61.
>
> I see that the latest patch file in the xenomai download area is 
> ipipe-core-4.9.51-x86-4.patch.
>
> Will this patch work OK with the 4.9.61 kernel version, or should I use a 
> different approach to ensure a better match?
>
> Steve Pavao
> Korg R
>
>
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

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

[Xenomai] matching patch version to kernel version

[Steve Pavao]

Hi all,

I am building Yocto poky linux for an Intel board at head in Master branch in 
Yocto poky, which currently results in a kernel version 4.9.61.

I see that the latest patch file in the xenomai download area is 
ipipe-core-4.9.51-x86-4.patch.

Will this patch work OK with the 4.9.61 kernel version, or should I use a 
different approach to ensure a better match?

Steve Pavao
Korg R



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

Re: [Xenomai] Gpio-core question

[Greg Gallagher]

Hi,
  Sorry for the formatting in the last email I'm not sure what
happened in my editor.  I've had some time to look into this issue.
For my case that is outlined above it looks like we insert the fd into
the tree in create instance, then when we fail the call to
dev->ops.open, the fd is cleaned up with linux by using put_unused_fd
but we never remove it from the tree.  On the next call to open we get
the same fd back from get_unused_fd_flags we then call create_instance
and fail because that fd is already in the tree from the previous
attempt.  I'll test out my theory tonight.  If this is what is
happening should the fd be removed from the tree in cleanup_instance?
I can play around with xnid_remove and see if working it into
cleanup_instance will solve the issue.

-Greg

On Wed, Nov 29, 2017 at 2:10 AM, Greg Gallagher  wrote:
> Hi,
>   I was testing out my changes and came across some strange behaviour.
> I tried two approaches for my changes one where I add two ioctrl commands
> to request and release a pin and another where the driver requests and
> releases the pin
> without the user having to make a call to ioctl.  For the second approach
> I added an open call to the gpio driver to handle checking if the pin is
> available. During
> testing I found that if one pin fails to open all attempts to open any other
> pin will also
> fail.
>For example I have three pins 953, 954, 957.  I created a test where I
> open 953,
> then 954 and then 957.  For one test run I export 953 via sysfs, I expect
> the output of
> my test to fail to open 953 with EBUSY and then successfully open 954 and
> 957.
> I expect to see my open call executed three times.  What I actually see is
> all the pins
> fail to open.  The driver's open function is only executed once, after that
> it looks like
> open fails before the call to the drivers open function. The error returned
> for all attempts after
> the first failure  is EBUSY.  I experimented with the order in which the
> test opens pins and found
> that after open fails as expected (drivers open function is invoked and
> returns EBUSY) every
> other call to open also fails but doesn't invoke the drivers open function
> but returns EBUSY.
> I traced back through cobalt to see what was happening and found we are
> failing in the
> call to xnid_enter() in rtdm_fd_enter(). The function xnid_enter fails with
> EEXIST when trying
> to insert into the tree.  I'm not sure if I'm missing something in my open()
> function to handle
> cleaning up resources after an unsuccessful attempt to open a pin.
>   For my open call I used the open operations that are in the serial and spi
> drivers as a guide.
> If request_gpio() fails, I return that value from open(), I've included my
> code for open():
>
> int gpio_pin_open(struct rtdm_fd *fd, int oflags)
> {
> struct rtdm_gpio_chan *chan = rtdm_fd_to_private(fd);
> struct rtdm_device *dev = rtdm_fd_device(fd);
> unsigned int gpio = rtdm_fd_minor(fd);
> int ret = 0;
> struct rtdm_gpio_pin *pin;
>
> pin = container_of(dev, struct rtdm_gpio_pin, dev);
> ret = gpio_request(gpio, pin->name);
> if (ret) {
> printk(XENO_ERR "failed to request pin %d : %d\n", gpio, ret);
> return ret;
> } else {
> chan->requested = true;
> }
>
> return 0;
> }
>
> I can also post my test code if that helps, I'm not sure if this is a bug or
> if I'm missing some clean
> up code in my open function to handle unsuccessful attempts to open a pin.
>
> Thanks
>
> Greg
>
> On Fri, Nov 24, 2017 at 5:26 AM, Philippe Gerum  wrote:
>>
>> On 11/24/2017 06:37 AM, Greg Gallagher wrote:
>> > Hi,
>> >   I'm finishing up my work on a patch to add a RTDM gpio driver for
>> > the zynq-7000 platform.  I ran into a situation where I needed to call
>> > gpio_request in gpio-core because the zynq gpio driver uses the
>> > gpio_request function to enable the gpio pins on the board.
>> > A side effect that I found when testing is that the driver will fail
>> > to
>> > load
>> > if another application has exported a gpio pin via sysfs and likewise
>> > sysfs
>> > won't allow anyone to export gpio pins once the rtdm gpio driver has
>> > been
>> > loaded.
>> > My implementation calls gpio_request on each pin as they are  registered
>> > under /dev/rtdm.
>> > I'm not sure if the above is an issue or not, if the RTDM driver has
>> > claimed the
>> > gpio pins then I think it would make sense for them not to be accessible
>> > by
>> > applications
>> > via sysfs.  If my assumption is not correct then maybe one option could
>> > be
>> > to only call gpio_request on each pin as need, maybe via ioctl?
>> >
>> > Any guidance would be appreciated,
>> >
>>
>> gpio-core deals with entire GPIO controllers, so claiming every pin from
>> every bank on the controller for rt usage unconditionally seems overkill.
>>
>> The ioctl option seems a better option, but then you would have to be
>> careful about not conflicting with 

Re: [Xenomai] Library cannot be dlopen()ed

[Giulio Moro]

> From: Philippe Gerum 
> As mentioned in the documentation, --enable-dlopen-libs is needed when 
> configuring

Brilliant, thanks. The docs mentions

> Enabling dynamic loading introduces some overhead in TLS accesses when 
> enabled (see --enable-tls), which might be noticeable depending on the 
> architecture.

Can you make an example of what operations incur overhead?

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

Re: [Xenomai] Library cannot be dlopen()ed

[Philippe Gerum]

On 11/29/2017 12:24 AM, Giulio Moro wrote:
> Again, armv7 BeagleBone Black, Xenomai 3.0.5
> 
> My main executable uses the posix API, hence ldd tells me :
>   libcobalt.so.2 => /usr/xenomai/lib/libcobalt.so.2 (0xb6ed3000)
>   libmodechk.so.0 => /usr/xenomai/lib/libmodechk.so.0 (0xb6f39000)
> 
> I am trying to dlopen() a library which uses the native API 
> (alchemy+transition kit):
>   libtrank.so.0 => /usr/xenomai/lib/libtrank.so.0 (0xb6e71000)
>   libalchemy.so.0 => /usr/xenomai/lib/libalchemy.so.0 (0xb6e58000)
>   libcopperplate.so.0 => /usr/xenomai/lib/libcopperplate.so.0 (0xb6e3d000)
>   libcobalt.so.2 => /usr/xenomai/lib/libcobalt.so.2 (0xb6e18000)
>   libmodechk.so.0 => /usr/xenomai/lib/libmodechk.so.0 (0xb6e07000)
> 
> the call to dlopen() fails with the following message:
> libtrank.so.0: shared object cannot be dlopen()ed
> 
> grepping the configured Xenomai source for "nodlopen" shows that all (or 
> most) of the libraries are compiled with -Wl,nodlopen, which is what is 
> preventing dlopen() from working.
> 
> I have two questions:
> - is it possible to dynamically load a library which uses the alchemy API 
> from a program that uses the cobalt API?
> - is it at all possible to dynamically load a library that uses xenomai in a 
> program that was not linked against xenomai?
> 
> Thanks,
> Giulio
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
> 

As mentioned in the documentation, --enable-dlopen-libs is needed when
configuring:

https://xenomai.org/installing-xenomai-3-x/#Generic_configuration_options_both_cores

-- 
Philippe.

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