Re: RTNET setup issue

["Bezdeka, Florian" <florian.bezdeka@siemens.com>]

On Thu, 2022-03-24 at 16:27 +0100, Paal Tamas wrote:
> > I started the debug session using the rtifconfig.c file, since the
> > rtifconfig command "fails fine". I added some trace to the
> > rtifconfig.c (into the do_display() function) and rtnet_chrdev.c
> > (into the rtnet_core_ioctl() function) files. In "all 64bit mode",
> > when RTNET works as expected I see the followings in the user mode
> > console and kernel trace:
> > do_display enter
> > do_display: IOC_RT_IFINFO=0xc0500082, sizeof(rtnet_core_cmd)=80
> >  
> > [   36.616917] rtnet_core_ioctl:
> > request=0xc0500082,sizeof(rtnet_core_cmd)=80
> > [   36.616919] rtnet_core_ioctl: IOC_RT_IFINFO decoded
> >  
> > This means the ioctl() call hit the target succesfully.
> >  
> > When I compile the userland to 32bit the user mode trace is the
> > following:
> >  
> > do_display enter
> > do_display: IOC_RT_IFINFO=0xc0500082, sizeof(rtnet_core_cmd)=80
> > do_display: ret=-1
> > ioctl: Inappropriate ioctl for device
> >  
> > but nothing appears in the kernel trace. This means to me that the
> > ioctl() call did not reach the rtnet_core_ioctl() funtion, rather
> > failed somewhere in between the userspace and that kernel function
> > call.
> >  
> > I need some help here. I need to add more traces to the system, to
> > find the place where the ioctl() call hits the wall. When the
> > do_display() function of rtifconfig.c calls ioctl(), where can I
> > find that certain ioctl() function? I am lost in the jungle of
> > macros...

Your mail client has a strange configuration / citation style. Took
some time to realize that there is a question.

Whenever you call ioctl() you end up in the Xenomai (libcobalt)
wrapper. See lib/cobalt/rtdm.c (~ line 195). If do_ioctl (which
triggers the Xenomai / RT syscall) fails, it will fall back to the
Linux / NON-RT path. I guess that is where the "Inappropriate ioctl for
device" is coming from. Linux simply doesn't know the requested call.

I guess you have to figure out why the RT path fails. The interesting
entry point inside the kernel should be in kernel/cobalt/posix/io.c
(~line 63) calling rtdm_fd_ioctl() located in kernel/cobalt/rtdm/fd.c.

rtdm_fd_ioctl() might bail out in some error conditions before
triggering the trace infrastructure. That might be the reason why your
trace did not mention any RT syscall.

CONFIG_XENO_ARCH_SYS3264 is enabled on your end?

HTH,
Florian