Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-28 Thread Philippe Gerum 
On 06/28/2018 12:40 PM, Pintu Kumar wrote:
>> FWIW, all of my rtnet fixes that went in since 3.0.6 have been tested on
>> x86 exclusively.
> 
> For us, even the xeno-test/net_udp fails on both x86/arm.
> I also verified the udp test (loopback) that exists on rtnet repo:
> https://git.code.sf.net/p/rtnet/code
> Under: examples/generic/
> 
> Then, I also developed a common rtnet udp server/client using posix skin.
> When I build and verify it on normal kernel it works fine.
> But when I build it with Xenomai posix skin, I get the kernel oops on
> both x86/arm.
> > Now it fails with xenomai-3/next (latest) and with Kernel 4.9, on x86.
> Earlier (1.5 months ago), I remember, rtnet loopback worked on x86_64
> with 3.0.6, with "nosmap".
>  If I run the same on Virtual Box Ubuntu 32-bit with same Kernel 4.9, it 
> works.
> 
> So, I wonder, normally how do you verify rtnet sample application.

Sorry, I don't maintain rtnet.

> Please share the test applications and the steps you follow.
> 

Run the smokey test suite over real x86 hw and a real ethernet
interface, not the loopback. These were the tests conditions for the
changes addressing the smap issue.

I have no bandwidth to invest in rtnet at the moment, so you may want to
confront and debug the issue directly. I'm sure that any proposal for a
fix once the bug is spotted would be welcome, reviewed and commented on
this list.

-- 
Philippe.

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-28 Thread Pintu Kumar 
> FWIW, all of my rtnet fixes that went in since 3.0.6 have been tested on
> x86 exclusively.

For us, even the xeno-test/net_udp fails on both x86/arm.
I also verified the udp test (loopback) that exists on rtnet repo:
https://git.code.sf.net/p/rtnet/code
Under: examples/generic/

Then, I also developed a common rtnet udp server/client using posix skin.
When I build and verify it on normal kernel it works fine.
But when I build it with Xenomai posix skin, I get the kernel oops on
both x86/arm.

Now it fails with xenomai-3/next (latest) and with Kernel 4.9, on x86.
Earlier (1.5 months ago), I remember, rtnet loopback worked on x86_64
with 3.0.6, with "nosmap".
 If I run the same on Virtual Box Ubuntu 32-bit with same Kernel 4.9, it works.

So, I wonder, normally how do you verify rtnet sample application.
Please share the test applications and the steps you follow.


Thanks,
Pintu

On Wed, Jun 27, 2018 at 11:40 PM Philippe Gerum  wrote:
>
> On 06/27/2018 07:29 PM, Pintu Kumar wrote:
> > On Wed, Jun 27, 2018 at 10:47 PM Greg Gallagher  
> > wrote:
> >>
> >> I don't think Beaglebone is supported currently in RTNet.
> >>
> >
> > But I am just checking loopback interface with 127.0.0.1
> > I hope that should work on all boards and arch, even without
> > installing the net driver.
> >
>
> You must be the first and only user giving any feedback about rtnet over
> ARM if my memory serves me well. So either all others have been hiding
> behind for all these years, or you may be the only specimen of that species.
>
> FWIW, all of my rtnet fixes that went in since 3.0.6 have been tested on
> x86 exclusively.
>
> --
> Philippe.

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Philippe Gerum 
On 06/27/2018 07:29 PM, Pintu Kumar wrote:
> On Wed, Jun 27, 2018 at 10:47 PM Greg Gallagher  wrote:
>>
>> I don't think Beaglebone is supported currently in RTNet.
>>
> 
> But I am just checking loopback interface with 127.0.0.1
> I hope that should work on all boards and arch, even without
> installing the net driver.
> 

You must be the first and only user giving any feedback about rtnet over
ARM if my memory serves me well. So either all others have been hiding
behind for all these years, or you may be the only specimen of that species.

FWIW, all of my rtnet fixes that went in since 3.0.6 have been tested on
x86 exclusively.

-- 
Philippe.

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Philippe Gerum 
On 06/27/2018 06:17 PM, Jan Kiszka wrote:
> On 2018-06-27 16:12, Pintu Kumar wrote:
>>> With nosmap, that particular issue should no longer occur (at least as
>>> long as we can ask the kernel for this relaxation), so I suspect the
>>> other effect you see now is something else.
>>
>> Just for the information, that issue occurred even on Beagle bone, and
>> there is no smap on arm.
>> However, it works on virtual box. how ?
> 
> Does it work when you go back to Xenomai 3.0.6? Then it would be a
> regression of the copy-to/from-userspace improvements done after that
> release, you could start bisecting which commit introduced it.
> 
> But I'm not sure right now if there isn't something similar to smap
> (then just without a knob to turn it off) in the ARM architecture as well...
> 

AFAIR, use of protection domains is built in depending on a selection by
the CPU support code.

-- 
Philippe.

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Pintu Kumar 
On Wed, Jun 27, 2018 at 10:47 PM Greg Gallagher  wrote:
>
> I don't think Beaglebone is supported currently in RTNet.
>

But I am just checking loopback interface with 127.0.0.1
I hope that should work on all boards and arch, even without
installing the net driver.

> On Wed, Jun 27, 2018 at 1:13 PM, Pintu Kumar  wrote:
> > On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka  wrote:
> >>
> >> On 2018-06-27 16:12, Pintu Kumar wrote:
> >> >> With nosmap, that particular issue should no longer occur (at least as
> >> >> long as we can ask the kernel for this relaxation), so I suspect the
> >> >> other effect you see now is something else.
> >> >
> >> > Just for the information, that issue occurred even on Beagle bone, and
> >> > there is no smap on arm.
> >> > However, it works on virtual box. how ?
> >>
> >> Does it work when you go back to Xenomai 3.0.6? Then it would be a
> >> regression of the copy-to/from-userspace improvements done after that
> >> release, you could start bisecting which commit introduced it.
> >>
> >
> > Nope, I never had success with rtnet on arm architecture (mainly
> > beagle bone), even with the old 3.0.6.
> > At least earlier, on x86_64 (SkyLake), I saw the loopback part working
> > with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet
> > fixes) and with "nosmap" in commandline.
> >
> > But now it looks like the situation becomes more worse.
> > I will have to freshly look into it, but since I use prepare_kernel to
> > apply as single patch, it might be painful to bisect it.
> > Will try to find the root cause though
> >
> > Hoping for the best...
> >
> >> But I'm not sure right now if there isn't something similar to smap
> >> (then just without a knob to turn it off) in the ARM architecture as 
> >> well...
> >>
> >> Jan
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> >
> > ___
> > Xenomai mailing list
> > Xenomai@xenomai.org
> > https://xenomai.org/mailman/listinfo/xenomai

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Greg Gallagher 
I don't think Beaglebone is supported currently in RTNet.

On Wed, Jun 27, 2018 at 1:13 PM, Pintu Kumar  wrote:
> On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka  wrote:
>>
>> On 2018-06-27 16:12, Pintu Kumar wrote:
>> >> With nosmap, that particular issue should no longer occur (at least as
>> >> long as we can ask the kernel for this relaxation), so I suspect the
>> >> other effect you see now is something else.
>> >
>> > Just for the information, that issue occurred even on Beagle bone, and
>> > there is no smap on arm.
>> > However, it works on virtual box. how ?
>>
>> Does it work when you go back to Xenomai 3.0.6? Then it would be a
>> regression of the copy-to/from-userspace improvements done after that
>> release, you could start bisecting which commit introduced it.
>>
>
> Nope, I never had success with rtnet on arm architecture (mainly
> beagle bone), even with the old 3.0.6.
> At least earlier, on x86_64 (SkyLake), I saw the loopback part working
> with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet
> fixes) and with "nosmap" in commandline.
>
> But now it looks like the situation becomes more worse.
> I will have to freshly look into it, but since I use prepare_kernel to
> apply as single patch, it might be painful to bisect it.
> Will try to find the root cause though
>
> Hoping for the best...
>
>> But I'm not sure right now if there isn't something similar to smap
>> (then just without a knob to turn it off) in the ARM architecture as well...
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Pintu Kumar 
On Wed, Jun 27, 2018 at 9:47 PM Jan Kiszka  wrote:
>
> On 2018-06-27 16:12, Pintu Kumar wrote:
> >> With nosmap, that particular issue should no longer occur (at least as
> >> long as we can ask the kernel for this relaxation), so I suspect the
> >> other effect you see now is something else.
> >
> > Just for the information, that issue occurred even on Beagle bone, and
> > there is no smap on arm.
> > However, it works on virtual box. how ?
>
> Does it work when you go back to Xenomai 3.0.6? Then it would be a
> regression of the copy-to/from-userspace improvements done after that
> release, you could start bisecting which commit introduced it.
>

Nope, I never had success with rtnet on arm architecture (mainly
beagle bone), even with the old 3.0.6.
At least earlier, on x86_64 (SkyLake), I saw the loopback part working
with 3.0.6 and my old xenomai kernel 4.9.51 (without those rtnet
fixes) and with "nosmap" in commandline.

But now it looks like the situation becomes more worse.
I will have to freshly look into it, but since I use prepare_kernel to
apply as single patch, it might be painful to bisect it.
Will try to find the root cause though

Hoping for the best...

> But I'm not sure right now if there isn't something similar to smap
> (then just without a knob to turn it off) in the ARM architecture as well...
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Jan Kiszka 
On 2018-06-27 16:12, Pintu Kumar wrote:
>> With nosmap, that particular issue should no longer occur (at least as
>> long as we can ask the kernel for this relaxation), so I suspect the
>> other effect you see now is something else.
> 
> Just for the information, that issue occurred even on Beagle bone, and
> there is no smap on arm.
> However, it works on virtual box. how ?

Does it work when you go back to Xenomai 3.0.6? Then it would be a
regression of the copy-to/from-userspace improvements done after that
release, you could start bisecting which commit introduced it.

But I'm not sure right now if there isn't something similar to smap
(then just without a knob to turn it off) in the ARM architecture as well...

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Pintu Kumar 
> With nosmap, that particular issue should no longer occur (at least as
> long as we can ask the kernel for this relaxation), so I suspect the
> other effect you see now is something else.

Just for the information, that issue occurred even on Beagle bone, and
there is no smap on arm.
However, it works on virtual box. how ?

This is the back trace seen on ARM Beagle bone:
{{{
[  970.717610] Unhandled fault: page domain fault (0x01b) at 0xbe926678
[  970.724030] pgd = da83
[  970.726755] [be926678] *pgd=9cda7831, *pte=9a61634f, *ppte=9a61683f
[  970.733107] Internal error: : 1b [#1] PREEMPT SMP ARM
[  970.738188] Modules linked in: rt_loopback rtpacket rtudp rtipv4 rtnet
[  970.744831] CPU: 0 PID: 564 Comm: rtnet-client Not tainted 4.9.51-scel-beagle
bone #6
[  970.752611] Hardware name: Generic AM33XX (Flattened Device Tree)
[  970.758733] I-pipe domain: Linux
[  970.761979] task: dce0d740 task.stack: dce08000
[  970.766567] PC is at rt_udp_getfrag+0x48/0x118 [rtudp]
[  970.771796] LR is at rt_ip_build_xmit+0x230/0x2f4 [rtipv4]
[  970.777313] pc : []lr : []psr: 20060013
[  970.777313] sp : dce09cf0  ip : bf026bb0  fp : dce09d14
[  970.788846] r10: dcb35824  r9 : 0400  r8 : c12050a0
[  970.794099] r7 : dcd9e364  r6 : 000a  r5 : dce09db4  r4 : 
[  970.800659] r3 : be926678  r2 :   r1 : be926678  r0 : 
[  970.807221] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[  970.814392] Control: 10c5387d  Table: 9a830019  DAC: 0051
[  970.820168] Process rtnet-client (pid: 564, stack limit = 0xdce08220)
[  970.826642] Stack: (0xdce09cf0 to 0xdce0a000)
[  970.831025] 9ce0: dce09d14 dce09d00 dcc0b
600 dcd9e2c0
[  970.839249] 9d00: 0040 dcd9e364 dce09d6c dce09d18 bf019688 bf026ba4 c1205
0a0 
[  970.847470] 9d20: dce09d6c dce09d30 bf017d4c bf01c13c 000a dce09db4 bf026
b98 000f
[  970.855692] 9d40:  c120418c dce09e64 0002 dce09d98 dcb35800 dce09
dd4 
[  970.863912] 9d60: dce09ebc dce09d70 bf027098 bf019464 dce09e64  0
000 e015
[  970.872133] 9d80: 017f c1199b50 c12050a0  c0173fd0 dce09dd4 be926
6cc 0010
[  970.880354] 9da0: be926678 0001    e015a816 0
a00 017f
[  970.888576] 9dc0: 017f dcb35800 be926678 0001  be926714 0
002 c0179034
[  970.896798] 9de0: c12095fc 0002 c120 c010332c c0103340 c015ef90 c0103
32c 
[  970.905020] 9e00: c1209f90 0002 c120 c0112abc c0112ad0 c015ef90 dce09
e4c dce09e28
[  970.913240] 9e20:    dce08000 c01ab530 c015f2d4 0
000 
[  970.921461] 9e40: 0003 0001 c020cdec c027ea78 c1199b50 e0150002 01000
07f 
[  970.929682] 9e60:  017f     0
000 
[  970.937904] 9e80:   dcc0b600 00040933 dce09ebc dcb35800 c119a
cf0 40060013
[  970.946124] 9ea0:  0003 dce09efc c11989b0 dce09ef4 dce09ec0 c027f
6f0 bf026cbc
[  970.954346] 9ec0: 0052 dce0d740  0003  0051 0
001 e0580008
[  970.962568] 9ee0: c0285920 c11989b0 dce09f34 dce09ef8 c02859b0 c027f65c e0580
008 be9266cc
[  970.970789] 9f00: 0010 be926678 0001    dce09
fb0 dce09fb0
[  970.979010] 9f20: 0052 c12050a0 dce09f6c dce09f38 c029351c c028592c 0
000 dce09f48
[  970.987231] 9f40: c02d1f68 df9429b0 df9419b0 c12050a0 20060013 c13f7600 c13f7
600 c11989b0
[  970.995452] 9f60: dce09fac dce09f70 c020d5a0 c029340c c11989b0 c119acf0 c13f7
600 dce09fb0
[  971.003675] 9f80: c02d8de4 00022080  be926680 000f0042 c0109288 dce08
000 0002
[  971.011896] 9fa0:  dce09fb0 c01091d4 c020d4a8 1054 0003 be926
680 
[  971.020119] 9fc0: 00022080  be926680 000f0042 0003 0002 1
5e0 
[  971.028340] 9fe0: b6f482d0 be926650  b6f2f044 00060030 1054 0
000 
[  971.036617] [] (rt_udp_getfrag [rtudp]) from [] (rt_ip_bu
ild_xmit+0x230/0x2f4 [rtipv4])
[  971.046445] [] (rt_ip_build_xmit [rtipv4]) from [] (rt_ud
p_sendmsg+0x3e8/0x45c [rtudp])
[  971.056256] [] (rt_udp_sendmsg [rtudp]) from [] (rtdm_fd_
sendmsg+0xa0/0x248)
[  971.065095] [] (rtdm_fd_sendmsg) from [] (CoBaLt_sendmsg+
0x90/0x98)
[  971.073156] [] (CoBaLt_sendmsg) from [] (ipipe_syscall_ho
ok+0x11c/0x400)
[  971.081647] [] (ipipe_syscall_hook) from [] (__ipipe_noti
fy_syscall+0x104/0x1d4)
[  971.090841] [] (__ipipe_notify_syscall) from [] (pipeline
_syscall+0x8/0x24)
[  971.099591] Code: da0a e5953014 e1a02000 e0831184 (e7930184)
[  971.105740] ---[ end trace 0e2d3ec12e870a84 ]---
}}}

I will try to debug this issue if my time permits.

Thanks,
Pintu
On Wed, Jun 27, 2018 at 4:44 PM Jan Kiszka  wrote:
>
> On 2018-06-27 12:56, Pintu Kumar wrote:
> > Dear Jan,
> >
> >> What means "now"? Did it work before? What was the setup then?
> > rtnet loopback test is working (even with older kernel) on

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Jan Kiszka 
On 2018-06-27 12:56, Pintu Kumar wrote:
> Dear Jan,
> 
>> What means "now"? Did it work before? What was the setup then?
> rtnet loopback test is working (even with older kernel) on my Virtual
> Box with Ubuntu 32-bit.
> 
> But it never worked for me on x86_64 machine.
> So, at first I wonder what is the minimum criteria to make rtnet work
> on any system.
> I am sure it would have definitely worked in the past. No?

It surely worked, but it wasn't looked after consistently in the (even
not so) recent past since then.

> 
>> Either you drill deeper, systematically, and report your
>> findings for discussions and suggestions on the list
> Yes sure, I am ready to do that.
> Once I know the little bit of history and current problems with rtnet,
> I can definitely start contributing.
> At first I assumed that there might be some fix already available.
> So, instead of reinventing the wheel, I thought to first check out.

The main recent problem was (and still is) related to SMAP (supervisor
mode access prevention) which started to bite RTnet due to its sloppy
way of taken data from user space or pushing it back there (not using
proper copy-to/from services). The problem in the UDP code you ran into
is related to the code still doing direct access (checksum generation
over userspace data, rather than over the kernel copy).

With nosmap, that particular issue should no longer occur (at least as
long as we can ask the kernel for this relaxation), so I suspect the
other effect you see now is something else.

Jan

> 
> I am really sorry for troubling you!
> I will try to look into this issue and see if I can find something.
> 
> Thank you!
> Pintu
> 
> On Wed, Jun 27, 2018 at 3:50 PM Jan Kiszka  wrote:
>>
>> On 2018-06-26 13:08, Pintu Kumar wrote:
>>> Dear Jan,
>>>
>>> Till now I haven't had any success for running my rtnet demo test
>>> either or x86 or arm.
>>> I even upgraded to xenomai-next (both kernel and user space) but still no 
>>> luck.
>>>
>>> Now even the "loopback" test is not working on xenomai-next.
>>
>> What means "now"? Did it work before? What was the setup then?
>>
>>>
>>> Can you confirm, if any of the below rtnet test works for you with
>>> Kernel 4.9 and xenomai-next.
>>> - xenomai-3-next/testsuite/smokey/net_udp
>>> - url = https://git.code.sf.net/p/rtnet/code  => examples/generic/
>>> - Or a simple UDP client/server program, compiled with xenomai posix skin
>>>
>>> I already tried with "nosmap" but there are no response coming (I am
>>> getting no prints on console, but client is terminated).
>>> If there is any work around to make rtnet works, please let me know.
>>>
>>
>> I'm afraid there is currently a lack of bandwidth here to dive into the
>> details. Either you drill deeper, systematically, and report your
>> findings for discussions and suggestions on the list, or you need to be
>> patient until someone finds the time to reproduce and resolve the issue(s).
>>
>> Jan
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux


-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-27 Thread Pintu Kumar 
Dear Jan,

> What means "now"? Did it work before? What was the setup then?
rtnet loopback test is working (even with older kernel) on my Virtual
Box with Ubuntu 32-bit.

But it never worked for me on x86_64 machine.
So, at first I wonder what is the minimum criteria to make rtnet work
on any system.
I am sure it would have definitely worked in the past. No?

> Either you drill deeper, systematically, and report your
> findings for discussions and suggestions on the list
Yes sure, I am ready to do that.
Once I know the little bit of history and current problems with rtnet,
I can definitely start contributing.
At first I assumed that there might be some fix already available.
So, instead of reinventing the wheel, I thought to first check out.

I am really sorry for troubling you!
I will try to look into this issue and see if I can find something.

Thank you!
Pintu

On Wed, Jun 27, 2018 at 3:50 PM Jan Kiszka  wrote:
>
> On 2018-06-26 13:08, Pintu Kumar wrote:
> > Dear Jan,
> >
> > Till now I haven't had any success for running my rtnet demo test
> > either or x86 or arm.
> > I even upgraded to xenomai-next (both kernel and user space) but still no 
> > luck.
> >
> > Now even the "loopback" test is not working on xenomai-next.
>
> What means "now"? Did it work before? What was the setup then?
>
> >
> > Can you confirm, if any of the below rtnet test works for you with
> > Kernel 4.9 and xenomai-next.
> > - xenomai-3-next/testsuite/smokey/net_udp
> > - url = https://git.code.sf.net/p/rtnet/code  => examples/generic/
> > - Or a simple UDP client/server program, compiled with xenomai posix skin
> >
> > I already tried with "nosmap" but there are no response coming (I am
> > getting no prints on console, but client is terminated).
> > If there is any work around to make rtnet works, please let me know.
> >
>
> I'm afraid there is currently a lack of bandwidth here to dive into the
> details. Either you drill deeper, systematically, and report your
> findings for discussions and suggestions on the list, or you need to be
> patient until someone finds the time to reproduce and resolve the issue(s).
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-26 Thread Pintu Kumar 
Dear Jan,

Till now I haven't had any success for running my rtnet demo test
either or x86 or arm.
I even upgraded to xenomai-next (both kernel and user space) but still no luck.

Now even the "loopback" test is not working on xenomai-next.

Can you confirm, if any of the below rtnet test works for you with
Kernel 4.9 and xenomai-next.
- xenomai-3-next/testsuite/smokey/net_udp
- url = https://git.code.sf.net/p/rtnet/code  => examples/generic/
- Or a simple UDP client/server program, compiled with xenomai posix skin

I already tried with "nosmap" but there are no response coming (I am
getting no prints on console, but client is terminated).
If there is any work around to make rtnet works, please let me know.


Thanks,
Pintu

On Mon, Jun 25, 2018 at 6:26 PM Pintu Kumar  wrote:
>
> > As a workaround, run the kernel with nosmap.
> OK, I guessed it correctly and tried with kernel commandline "nosmap".
> Because it works normally on virtual box.
>
> With "nosmap" I don't see any kernel oops, but there are no prints either.
> I mean in my rtnet-server/client, I have given some print statement.
> But I am not seeing those print statement coming on the console now.
> The print statements are coming for normal "xeno_task" application.
>
> Is there any clue for this ?
>
>
> Thanks,
> Pintu
>
>
>
>
>
> On Thu, Jun 21, 2018 at 8:27 PM Jan Kiszka  wrote:
> >
> > On 2018-06-21 15:41, Jan Kiszka wrote:
> > > On 2018-06-21 13:55, Jan Kiszka wrote:
> > >> On 2018-06-21 13:20, Pintu Kumar wrote:
> > >>> Dear Jan, Greg,
> > >>>
> > >>> Is there any pointer about this issue?
> > >>> This is blocking my next work..
> > >>
> > >> Does this solve the issue AND still generate valid UDP checksums (please
> > >> check with wireshark or against a normal networking stack?
> > >>
> > >> diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
> > >> b/kernel/drivers/net/stack/ipv4/udp/udp.c
> > >> index 8e80d3e0b..bb0b0fc12 100644
> > >> --- a/kernel/drivers/net/stack/ipv4/udp/udp.c
> > >> +++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
> > >> @@ -556,18 +556,17 @@ static int rt_udp_getfrag(const void *p, unsigned 
> > >> char *to,
> > >>  if (offset)
> > >>  return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
> > >> fraglen);
> > >>
> > >> -/* Checksum of the complete data part of the UDP message: */
> > >> -for (i = 0; i < ufh->iovlen; i++) {
> > >> -ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
> > >> ufh->iov[i].iov_len,
> > >> -   ufh->wcheck);
> > >> -}
> > >> -
> > >>  ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
> > >>to + sizeof(struct udphdr),
> > >>fraglen - sizeof(struct udphdr));
> > >>  if (ret)
> > >>  return ret;
> > >>
> > >> +/* Checksum of the complete data part of the UDP message: */
> > >> +ufh->wcheck = csum_partial(to + sizeof(struct udphdr),
> > >> +   fraglen - sizeof(struct udphdr),
> > >> +   ufh->wcheck);
> > >> +
> > >>  /* Checksum of the udp header: */
> > >>  ufh->wcheck = csum_partial((unsigned char *)ufh,
> > >> sizeof(struct udphdr), ufh->wcheck);
> > >>
> > >
> > > This was definitely wrong. Here is another try:
> > >
> > > diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
> > > b/kernel/drivers/net/stack/ipv4/udp/udp.c
> > > index 8e80d3e0b..6cf1d369e 100644
> > > --- a/kernel/drivers/net/stack/ipv4/udp/udp.c
> > > +++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
> > > @@ -549,6 +549,7 @@ static int rt_udp_getfrag(const void *p, unsigned 
> > > char *to,
> > >unsigned int offset, unsigned int fraglen)
> > >  {
> > >  struct udpfakehdr *ufh = (struct udpfakehdr *)p;
> > > +unsigned int datalen = 0;
> > >  int i, ret;
> > >
> > >
> > > @@ -556,18 +557,18 @@ static int rt_udp_getfrag(const void *p, unsigned 
> > > char *to,
> > >  if (offset)
> > >   return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
> > > fraglen);
> > >
> > > -/* Checksum of the complete data part of the UDP message: */
> > > -for (i = 0; i < ufh->iovlen; i++) {
> > > -ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
> > > ufh->iov[i].iov_len,
> > > -   ufh->wcheck);
> > > -}
> > > -
> > >  ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
> > > to + sizeof(struct udphdr),
> > > fraglen - sizeof(struct udphdr));
> > >  if (ret)
> > >   return ret;
> > >
> > > +/* Checksum of the complete data part of the UDP message: */
> > > +for (i = 0; i < ufh->iovlen; i++)
> > > + datalen += ufh->iov[i].iov_len;
> > > +ufh->wcheck = csum_partial(to + sizeof(struct udphdr), datalen,
> > > +ufh->wcheck);
> > > +
> > >  /* Checksum of the

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-21 Thread Jan Kiszka 
On 2018-06-21 15:41, Jan Kiszka wrote:
> On 2018-06-21 13:55, Jan Kiszka wrote:
>> On 2018-06-21 13:20, Pintu Kumar wrote:
>>> Dear Jan, Greg,
>>>
>>> Is there any pointer about this issue?
>>> This is blocking my next work..
>>
>> Does this solve the issue AND still generate valid UDP checksums (please
>> check with wireshark or against a normal networking stack?
>>
>> diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
>> b/kernel/drivers/net/stack/ipv4/udp/udp.c
>> index 8e80d3e0b..bb0b0fc12 100644
>> --- a/kernel/drivers/net/stack/ipv4/udp/udp.c
>> +++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
>> @@ -556,18 +556,17 @@ static int rt_udp_getfrag(const void *p, unsigned char 
>> *to,
>>  if (offset)
>>  return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
>> fraglen);
>>  
>> -/* Checksum of the complete data part of the UDP message: */
>> -for (i = 0; i < ufh->iovlen; i++) {
>> -ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
>> ufh->iov[i].iov_len,
>> -   ufh->wcheck);
>> -}
>> -
>>  ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
>>to + sizeof(struct udphdr),
>>fraglen - sizeof(struct udphdr));
>>  if (ret)
>>  return ret;
>>  
>> +/* Checksum of the complete data part of the UDP message: */
>> +ufh->wcheck = csum_partial(to + sizeof(struct udphdr),
>> +   fraglen - sizeof(struct udphdr),
>> +   ufh->wcheck);
>> +
>>  /* Checksum of the udp header: */
>>  ufh->wcheck = csum_partial((unsigned char *)ufh,
>> sizeof(struct udphdr), ufh->wcheck);
>>
> 
> This was definitely wrong. Here is another try:
> 
> diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
> b/kernel/drivers/net/stack/ipv4/udp/udp.c
> index 8e80d3e0b..6cf1d369e 100644
> --- a/kernel/drivers/net/stack/ipv4/udp/udp.c
> +++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
> @@ -549,6 +549,7 @@ static int rt_udp_getfrag(const void *p, unsigned char 
> *to,
>unsigned int offset, unsigned int fraglen)
>  {
>  struct udpfakehdr *ufh = (struct udpfakehdr *)p;
> +unsigned int datalen = 0;
>  int i, ret;
>  
>  
> @@ -556,18 +557,18 @@ static int rt_udp_getfrag(const void *p, unsigned char 
> *to,
>  if (offset)
>   return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
> fraglen);
>  
> -/* Checksum of the complete data part of the UDP message: */
> -for (i = 0; i < ufh->iovlen; i++) {
> -ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
> ufh->iov[i].iov_len,
> -   ufh->wcheck);
> -}
> -
>  ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
> to + sizeof(struct udphdr),
> fraglen - sizeof(struct udphdr));
>  if (ret)
>   return ret;
>  
> +/* Checksum of the complete data part of the UDP message: */
> +for (i = 0; i < ufh->iovlen; i++)
> + datalen += ufh->iov[i].iov_len;
> +ufh->wcheck = csum_partial(to + sizeof(struct udphdr), datalen,
> +ufh->wcheck);
> +
>  /* Checksum of the udp header: */
>  ufh->wcheck = csum_partial((unsigned char *)ufh,
>  sizeof(struct udphdr), ufh->wcheck);
> 

OK, this won't work either if fraglen < datalen. We have to rework this
more fundamentally.

As a workaround, run the kernel with nosmap.

Jan

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-21 Thread Jan Kiszka 
On 2018-06-21 13:55, Jan Kiszka wrote:
> On 2018-06-21 13:20, Pintu Kumar wrote:
>> Dear Jan, Greg,
>>
>> Is there any pointer about this issue?
>> This is blocking my next work..
> 
> Does this solve the issue AND still generate valid UDP checksums (please
> check with wireshark or against a normal networking stack?
> 
> diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
> b/kernel/drivers/net/stack/ipv4/udp/udp.c
> index 8e80d3e0b..bb0b0fc12 100644
> --- a/kernel/drivers/net/stack/ipv4/udp/udp.c
> +++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
> @@ -556,18 +556,17 @@ static int rt_udp_getfrag(const void *p, unsigned char 
> *to,
>  if (offset)
>   return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
> fraglen);
>  
> -/* Checksum of the complete data part of the UDP message: */
> -for (i = 0; i < ufh->iovlen; i++) {
> -ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
> ufh->iov[i].iov_len,
> -   ufh->wcheck);
> -}
> -
>  ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
> to + sizeof(struct udphdr),
> fraglen - sizeof(struct udphdr));
>  if (ret)
>   return ret;
>  
> +/* Checksum of the complete data part of the UDP message: */
> +ufh->wcheck = csum_partial(to + sizeof(struct udphdr),
> +fraglen - sizeof(struct udphdr),
> +ufh->wcheck);
> +
>  /* Checksum of the udp header: */
>  ufh->wcheck = csum_partial((unsigned char *)ufh,
>  sizeof(struct udphdr), ufh->wcheck);
> 

This was definitely wrong. Here is another try:

diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
b/kernel/drivers/net/stack/ipv4/udp/udp.c
index 8e80d3e0b..6cf1d369e 100644
--- a/kernel/drivers/net/stack/ipv4/udp/udp.c
+++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
@@ -549,6 +549,7 @@ static int rt_udp_getfrag(const void *p, unsigned char *to,
   unsigned int offset, unsigned int fraglen)
 {
 struct udpfakehdr *ufh = (struct udpfakehdr *)p;
+unsigned int datalen = 0;
 int i, ret;
 
 
@@ -556,18 +557,18 @@ static int rt_udp_getfrag(const void *p, unsigned char 
*to,
 if (offset)
return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
fraglen);
 
-/* Checksum of the complete data part of the UDP message: */
-for (i = 0; i < ufh->iovlen; i++) {
-ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
ufh->iov[i].iov_len,
-   ufh->wcheck);
-}
-
 ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
  to + sizeof(struct udphdr),
  fraglen - sizeof(struct udphdr));
 if (ret)
return ret;
 
+/* Checksum of the complete data part of the UDP message: */
+for (i = 0; i < ufh->iovlen; i++)
+   datalen += ufh->iov[i].iov_len;
+ufh->wcheck = csum_partial(to + sizeof(struct udphdr), datalen,
+  ufh->wcheck);
+
 /* Checksum of the udp header: */
 ufh->wcheck = csum_partial((unsigned char *)ufh,
   sizeof(struct udphdr), ufh->wcheck);

Jan

>>
>> If there is already a fix available for it, please let me know.
>> Or, should I need analyze this freshly
>> I wonder why no body else is facing this issue
> 
> Users may still have the related memory protection features off which
> surface this issue.
> 
> Jan
> 


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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-21 Thread Jan Kiszka 
On 2018-06-21 13:20, Pintu Kumar wrote:
> Dear Jan, Greg,
> 
> Is there any pointer about this issue?
> This is blocking my next work..

Does this solve the issue AND still generate valid UDP checksums (please
check with wireshark or against a normal networking stack?

diff --git a/kernel/drivers/net/stack/ipv4/udp/udp.c 
b/kernel/drivers/net/stack/ipv4/udp/udp.c
index 8e80d3e0b..bb0b0fc12 100644
--- a/kernel/drivers/net/stack/ipv4/udp/udp.c
+++ b/kernel/drivers/net/stack/ipv4/udp/udp.c
@@ -556,18 +556,17 @@ static int rt_udp_getfrag(const void *p, unsigned char 
*to,
 if (offset)
return rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen, to, 
fraglen);
 
-/* Checksum of the complete data part of the UDP message: */
-for (i = 0; i < ufh->iovlen; i++) {
-ufh->wcheck = csum_partial(ufh->iov[i].iov_base, 
ufh->iov[i].iov_len,
-   ufh->wcheck);
-}
-
 ret = rtnet_read_from_iov(ufh->fd, ufh->iov, ufh->iovlen,
  to + sizeof(struct udphdr),
  fraglen - sizeof(struct udphdr));
 if (ret)
return ret;
 
+/* Checksum of the complete data part of the UDP message: */
+ufh->wcheck = csum_partial(to + sizeof(struct udphdr),
+  fraglen - sizeof(struct udphdr),
+  ufh->wcheck);
+
 /* Checksum of the udp header: */
 ufh->wcheck = csum_partial((unsigned char *)ufh,
   sizeof(struct udphdr), ufh->wcheck);

> 
> If there is already a fix available for it, please let me know.
> Or, should I need analyze this freshly
> I wonder why no body else is facing this issue

Users may still have the related memory protection features off which
surface this issue.

Jan
-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-21 Thread Pintu Kumar 
Dear Jan, Greg,

Is there any pointer about this issue?
This is blocking my next work..

If there is already a fix available for it, please let me know.
Or, should I need analyze this freshly
I wonder why no body else is facing this issue

Thanks,
Pintu



On Wed, Jun 20, 2018 at 1:24 PM Pintu Kumar  wrote:
>
> Hi,
>
> Can someone help me with this issue.
> I compared the xenomai-3 next repo
> (next/kernel/drivers/net/stack/ipv4/udp/udp.c) and the changes are
> almost same.
> Now I am stuck with this..
> Please help!
>
> Is there any test available for rtnet loopback ?
>
> Regards,
> Pintu
> On Tue, Jun 19, 2018 at 7:18 PM Pintu Kumar  wrote:
> >
> > Hi,
> > I upgraded to xenomai-3-next branch for x86, but still rtnet loopback
> > is crashing for me.
> > The xenomai kernel is used from 4.9.51 until
> > commit: 10605b427b1408cdc6926f7c25d4a4eda527da8d
> > Author: Philippe Gerum 
> > Date:   Mon Mar 26 09:17:02 2018 +0200
> >
> > ipipe-core-4.9.51-x86-5
> >
> > Is the rtnet loopback working with 4.9 ?
> > Please let me know if this issue is fixed already ?
> >
> > This is the kernel logs:
> > --
> > [612871.612307]
> > *** RTnet for Xenomai v3.1-devel ***
> >
> > [612871.612310] RTnet: initialising real-time networking
> > [612906.855980] initializing loopback...
> > [612906.855998] RTnet: registered rtlo
> > [613075.162006] BUG: unable to handle kernel paging request at 
> > 7ffc7893b148
> > [613075.162009] IP: [] rt_udp_getfrag+0x3e/0x110 [rtudp]
> > [613075.162013] PGD 744f76067
> > [613075.162014] PUD 80e1ae067
> > [613075.162015] PMD 6893dd067
> > [613075.162015] PTE 800581853867
> >
> > [613075.162018] Oops: 0001 [#1] SMP
> > [613075.162019] Modules linked in: rt_loopback rtpacket rtudp rtipv4
> > rtnet binfmt_misc 8021q garp mrp stp llc rfcomm bnep
> > snd_hda_codec_hdmi nls_iso8859_1 eeepc_wmi intel_rapl btusb asus_wmi
> > x86_pkg_temp_thermal btrtl sparse_keymap intel_powerclamp coretemp
> > ath10k_pci kvm ath10k_core irqbypass ath mac80211 crct10dif_pclmul
> > crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek
> > aes_x86_64 snd_hda_codec_generic lrw cfg80211 gf128mul glue_helper
> > ablk_helper snd_hda_intel cryptd snd_hda_codec snd_hda_core input_leds
> > snd_hwdep mei_me mei shpchp serio_raw hci_uart btbcm btqca btintel
> > bluetooth acpi_als kfifo_buf intel_lpss_acpi industrialio intel_lpss
> > mac_hid acpi_pad autofs4 hid_generic usbhid nouveau mxm_wmi ttm
> > psmouse e1000e ptp pps_core ahci libahci i2c_hid pinctrl_sunrisepoint
> > wmi hid video
> > [613075.162049]  pinctrl_intel fjes
> > [613075.162052] CPU: 0 PID: 12658 Comm: rtnet-client Not tainted
> > 4.9.51-amd-x86-64-pintu-xeno3-rtdm #4
> > [613075.162053] Hardware name: System manufacturer System Product Name/xxx
> > [613075.162054] I-pipe domain: Linux
> > [613075.162055] task: 903e8921da00 task.stack: 9e2f03348000
> > [613075.162056] RIP: 0010:[]  []
> > rt_udp_getfrag+0x3e/0x110 [rtudp]
> > [613075.162058] RSP: 0018:9e2f0334bb70  EFLAGS: 00010202
> > [613075.162059] RAX:  RBX: 000a RCX:
> > 7ffc7893b140
> > [613075.162060] RDX:  RSI: 903e88e431e4 RDI:
> > 9e2f0334bc40
> > [613075.162061] RBP: 9e2f0334bb90 R08: 9e2f0334bdb8 R09:
> > 
> > [613075.162062] R10: 903e88e43100 R11: 90400c1c8800 R12:
> > 903e88e431e4
> > [613075.162063] R13: 0001 R14: 9e2f0334bc40 R15:
> > 001e
> > [613075.162064] FS:  7f310b789740() GS:90401620()
> > knlGS:
> > [613075.162065] CS:  0010 DS:  ES:  CR0: 8005003b
> > [613075.162066] CR2: 7ffc7893b148 CR3: 000744e5b000 CR4:
> > 003406f0
> > [613075.162067] DR0:  DR1:  DR2:
> > 
> > [613075.162067] DR3:  DR6: fffe0ff0 DR7:
> > 0400
> > [613075.162068] Stack:
> > [613075.162069]  9040121bec00 90400e262240 9e2f0334bdb8
> > 000a
> > [613075.162071]  9e2f0334bc00 c0a0f204 903dd1a84500
> > 9e2f0334bc10
> > [613075.162074]  00033768 9e2f0334bc40 c0a05000
> > 000f
> > [613075.162076] Call Trace:
> > [613075.162091]  [] rt_ip_build_xmit+0x1c4/0x2a0 [rtipv4]
> > [613075.162093]  [] ? 0xc0a05000
> > [613075.162094]  [] rt_udp_sendmsg+0x37b/0x3d0 [rtudp]
> > [613075.162097]  [] ? update_curr+0x66/0x180
> > [613075.162098]  [] ? dequeue_entity+0x268/0xc00
> > [613075.162100]  [] ? ___xnsched_run.part.73+0x3d7/0x400
> > [613075.162102]  [] ? hrtick_update+0x5/0x70
> > [613075.162103]  [] ? dequeue_task_fair+0x587/0x900
> > [613075.162105]  [] ? CoBaLt_recvmmsg+0x30/0x30
> > [613075.162106]  [] ? CoBaLt_recvmmsg+0x30/0x30
> > [613075.162108]  [] rtdm_fd_sendmsg+0xcb/0x240
> > [613075.162109]  [] ? CoBaLt_recvmmsg+0x30/0x30
> > [613075.162111]  []

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-20 Thread Pintu Kumar 
Hi,

Can someone help me with this issue.
I compared the xenomai-3 next repo
(next/kernel/drivers/net/stack/ipv4/udp/udp.c) and the changes are
almost same.
Now I am stuck with this..
Please help!

Is there any test available for rtnet loopback ?

Regards,
Pintu
On Tue, Jun 19, 2018 at 7:18 PM Pintu Kumar  wrote:
>
> Hi,
> I upgraded to xenomai-3-next branch for x86, but still rtnet loopback
> is crashing for me.
> The xenomai kernel is used from 4.9.51 until
> commit: 10605b427b1408cdc6926f7c25d4a4eda527da8d
> Author: Philippe Gerum 
> Date:   Mon Mar 26 09:17:02 2018 +0200
>
> ipipe-core-4.9.51-x86-5
>
> Is the rtnet loopback working with 4.9 ?
> Please let me know if this issue is fixed already ?
>
> This is the kernel logs:
> --
> [612871.612307]
> *** RTnet for Xenomai v3.1-devel ***
>
> [612871.612310] RTnet: initialising real-time networking
> [612906.855980] initializing loopback...
> [612906.855998] RTnet: registered rtlo
> [613075.162006] BUG: unable to handle kernel paging request at 
> 7ffc7893b148
> [613075.162009] IP: [] rt_udp_getfrag+0x3e/0x110 [rtudp]
> [613075.162013] PGD 744f76067
> [613075.162014] PUD 80e1ae067
> [613075.162015] PMD 6893dd067
> [613075.162015] PTE 800581853867
>
> [613075.162018] Oops: 0001 [#1] SMP
> [613075.162019] Modules linked in: rt_loopback rtpacket rtudp rtipv4
> rtnet binfmt_misc 8021q garp mrp stp llc rfcomm bnep
> snd_hda_codec_hdmi nls_iso8859_1 eeepc_wmi intel_rapl btusb asus_wmi
> x86_pkg_temp_thermal btrtl sparse_keymap intel_powerclamp coretemp
> ath10k_pci kvm ath10k_core irqbypass ath mac80211 crct10dif_pclmul
> crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek
> aes_x86_64 snd_hda_codec_generic lrw cfg80211 gf128mul glue_helper
> ablk_helper snd_hda_intel cryptd snd_hda_codec snd_hda_core input_leds
> snd_hwdep mei_me mei shpchp serio_raw hci_uart btbcm btqca btintel
> bluetooth acpi_als kfifo_buf intel_lpss_acpi industrialio intel_lpss
> mac_hid acpi_pad autofs4 hid_generic usbhid nouveau mxm_wmi ttm
> psmouse e1000e ptp pps_core ahci libahci i2c_hid pinctrl_sunrisepoint
> wmi hid video
> [613075.162049]  pinctrl_intel fjes
> [613075.162052] CPU: 0 PID: 12658 Comm: rtnet-client Not tainted
> 4.9.51-amd-x86-64-pintu-xeno3-rtdm #4
> [613075.162053] Hardware name: System manufacturer System Product Name/xxx
> [613075.162054] I-pipe domain: Linux
> [613075.162055] task: 903e8921da00 task.stack: 9e2f03348000
> [613075.162056] RIP: 0010:[]  []
> rt_udp_getfrag+0x3e/0x110 [rtudp]
> [613075.162058] RSP: 0018:9e2f0334bb70  EFLAGS: 00010202
> [613075.162059] RAX:  RBX: 000a RCX:
> 7ffc7893b140
> [613075.162060] RDX:  RSI: 903e88e431e4 RDI:
> 9e2f0334bc40
> [613075.162061] RBP: 9e2f0334bb90 R08: 9e2f0334bdb8 R09:
> 
> [613075.162062] R10: 903e88e43100 R11: 90400c1c8800 R12:
> 903e88e431e4
> [613075.162063] R13: 0001 R14: 9e2f0334bc40 R15:
> 001e
> [613075.162064] FS:  7f310b789740() GS:90401620()
> knlGS:
> [613075.162065] CS:  0010 DS:  ES:  CR0: 8005003b
> [613075.162066] CR2: 7ffc7893b148 CR3: 000744e5b000 CR4:
> 003406f0
> [613075.162067] DR0:  DR1:  DR2:
> 
> [613075.162067] DR3:  DR6: fffe0ff0 DR7:
> 0400
> [613075.162068] Stack:
> [613075.162069]  9040121bec00 90400e262240 9e2f0334bdb8
> 000a
> [613075.162071]  9e2f0334bc00 c0a0f204 903dd1a84500
> 9e2f0334bc10
> [613075.162074]  00033768 9e2f0334bc40 c0a05000
> 000f
> [613075.162076] Call Trace:
> [613075.162091]  [] rt_ip_build_xmit+0x1c4/0x2a0 [rtipv4]
> [613075.162093]  [] ? 0xc0a05000
> [613075.162094]  [] rt_udp_sendmsg+0x37b/0x3d0 [rtudp]
> [613075.162097]  [] ? update_curr+0x66/0x180
> [613075.162098]  [] ? dequeue_entity+0x268/0xc00
> [613075.162100]  [] ? ___xnsched_run.part.73+0x3d7/0x400
> [613075.162102]  [] ? hrtick_update+0x5/0x70
> [613075.162103]  [] ? dequeue_task_fair+0x587/0x900
> [613075.162105]  [] ? CoBaLt_recvmmsg+0x30/0x30
> [613075.162106]  [] ? CoBaLt_recvmmsg+0x30/0x30
> [613075.162108]  [] rtdm_fd_sendmsg+0xcb/0x240
> [613075.162109]  [] ? CoBaLt_recvmmsg+0x30/0x30
> [613075.162111]  [] CoBaLt_sendmsg+0x4e/0x70
> [613075.162113]  [] ipipe_syscall_hook+0x117/0x340
> [613075.162114]  [] __ipipe_notify_syscall+0xbf/0x170
> [613075.162116]  [] pipeline_syscall+0x8/0x1b
> [613075.162118] Code: 54 49 89 f4 53 89 cb 8b 57 20 0f 85 c3 00 00 00
> 85 d2 7e 2f 8b 47 24 45 31 ed 49 63 cd 89 c2 41 83 c5 01 48 c1 e1 04
> 49 03 4e 18 <8b> 71 08 48 8b 39 e8 e7 f4 a0 e6 41 8b 56 20 41 89 46 24
> 44 39
> [613075.162141] RIP  [] rt_udp_getfrag+0x3e/0x110 [rtudp]
> [613075.162143]  RSP 
> [613075.162144] CR2: 7ffc7893b148
>

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-06-19 Thread Pintu Kumar 
Hi,
I upgraded to xenomai-3-next branch for x86, but still rtnet loopback
is crashing for me.
The xenomai kernel is used from 4.9.51 until
commit: 10605b427b1408cdc6926f7c25d4a4eda527da8d
Author: Philippe Gerum 
Date:   Mon Mar 26 09:17:02 2018 +0200

ipipe-core-4.9.51-x86-5

Is the rtnet loopback working with 4.9 ?
Please let me know if this issue is fixed already ?

This is the kernel logs:
--
[612871.612307]
*** RTnet for Xenomai v3.1-devel ***

[612871.612310] RTnet: initialising real-time networking
[612906.855980] initializing loopback...
[612906.855998] RTnet: registered rtlo
[613075.162006] BUG: unable to handle kernel paging request at 7ffc7893b148
[613075.162009] IP: [] rt_udp_getfrag+0x3e/0x110 [rtudp]
[613075.162013] PGD 744f76067
[613075.162014] PUD 80e1ae067
[613075.162015] PMD 6893dd067
[613075.162015] PTE 800581853867

[613075.162018] Oops: 0001 [#1] SMP
[613075.162019] Modules linked in: rt_loopback rtpacket rtudp rtipv4
rtnet binfmt_misc 8021q garp mrp stp llc rfcomm bnep
snd_hda_codec_hdmi nls_iso8859_1 eeepc_wmi intel_rapl btusb asus_wmi
x86_pkg_temp_thermal btrtl sparse_keymap intel_powerclamp coretemp
ath10k_pci kvm ath10k_core irqbypass ath mac80211 crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek
aes_x86_64 snd_hda_codec_generic lrw cfg80211 gf128mul glue_helper
ablk_helper snd_hda_intel cryptd snd_hda_codec snd_hda_core input_leds
snd_hwdep mei_me mei shpchp serio_raw hci_uart btbcm btqca btintel
bluetooth acpi_als kfifo_buf intel_lpss_acpi industrialio intel_lpss
mac_hid acpi_pad autofs4 hid_generic usbhid nouveau mxm_wmi ttm
psmouse e1000e ptp pps_core ahci libahci i2c_hid pinctrl_sunrisepoint
wmi hid video
[613075.162049]  pinctrl_intel fjes
[613075.162052] CPU: 0 PID: 12658 Comm: rtnet-client Not tainted
4.9.51-amd-x86-64-pintu-xeno3-rtdm #4
[613075.162053] Hardware name: System manufacturer System Product Name/xxx
[613075.162054] I-pipe domain: Linux
[613075.162055] task: 903e8921da00 task.stack: 9e2f03348000
[613075.162056] RIP: 0010:[]  []
rt_udp_getfrag+0x3e/0x110 [rtudp]
[613075.162058] RSP: 0018:9e2f0334bb70  EFLAGS: 00010202
[613075.162059] RAX:  RBX: 000a RCX:
7ffc7893b140
[613075.162060] RDX:  RSI: 903e88e431e4 RDI:
9e2f0334bc40
[613075.162061] RBP: 9e2f0334bb90 R08: 9e2f0334bdb8 R09:

[613075.162062] R10: 903e88e43100 R11: 90400c1c8800 R12:
903e88e431e4
[613075.162063] R13: 0001 R14: 9e2f0334bc40 R15:
001e
[613075.162064] FS:  7f310b789740() GS:90401620()
knlGS:
[613075.162065] CS:  0010 DS:  ES:  CR0: 8005003b
[613075.162066] CR2: 7ffc7893b148 CR3: 000744e5b000 CR4:
003406f0
[613075.162067] DR0:  DR1:  DR2:

[613075.162067] DR3:  DR6: fffe0ff0 DR7:
0400
[613075.162068] Stack:
[613075.162069]  9040121bec00 90400e262240 9e2f0334bdb8
000a
[613075.162071]  9e2f0334bc00 c0a0f204 903dd1a84500
9e2f0334bc10
[613075.162074]  00033768 9e2f0334bc40 c0a05000
000f
[613075.162076] Call Trace:
[613075.162091]  [] rt_ip_build_xmit+0x1c4/0x2a0 [rtipv4]
[613075.162093]  [] ? 0xc0a05000
[613075.162094]  [] rt_udp_sendmsg+0x37b/0x3d0 [rtudp]
[613075.162097]  [] ? update_curr+0x66/0x180
[613075.162098]  [] ? dequeue_entity+0x268/0xc00
[613075.162100]  [] ? ___xnsched_run.part.73+0x3d7/0x400
[613075.162102]  [] ? hrtick_update+0x5/0x70
[613075.162103]  [] ? dequeue_task_fair+0x587/0x900
[613075.162105]  [] ? CoBaLt_recvmmsg+0x30/0x30
[613075.162106]  [] ? CoBaLt_recvmmsg+0x30/0x30
[613075.162108]  [] rtdm_fd_sendmsg+0xcb/0x240
[613075.162109]  [] ? CoBaLt_recvmmsg+0x30/0x30
[613075.162111]  [] CoBaLt_sendmsg+0x4e/0x70
[613075.162113]  [] ipipe_syscall_hook+0x117/0x340
[613075.162114]  [] __ipipe_notify_syscall+0xbf/0x170
[613075.162116]  [] pipeline_syscall+0x8/0x1b
[613075.162118] Code: 54 49 89 f4 53 89 cb 8b 57 20 0f 85 c3 00 00 00
85 d2 7e 2f 8b 47 24 45 31 ed 49 63 cd 89 c2 41 83 c5 01 48 c1 e1 04
49 03 4e 18 <8b> 71 08 48 8b 39 e8 e7 f4 a0 e6 41 8b 56 20 41 89 46 24
44 39
[613075.162141] RIP  [] rt_udp_getfrag+0x3e/0x110 [rtudp]
[613075.162143]  RSP 
[613075.162144] CR2: 7ffc7893b148
[613075.162145] ---[ end trace 90458bf1f92e3557 ]---
On Thu, Apr 26, 2018 at 9:53 PM Jan Kiszka  wrote:
>
> On 2018-04-25 13:36, Pintu Kumar wrote:
> > Dear Jan,
> >
> > Thank you so much for your reply.
> > I will try the latest stable version to check again.
> > Is ipipe patches (linux: 4.9.51) also needs to be upgraded for this
> > issue? Or only xenomai-3/kernel patches are enough?
>
> This particular issue was addressed in the Xenomai core, not the I-pipe
> patch.
>
> >
> > Actually, now I am stuck with another

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-04-26 Thread Jan Kiszka 
On 2018-04-25 13:36, Pintu Kumar wrote:
> Dear Jan,
> 
> Thank you so much for your reply.
> I will try the latest stable version to check again.
> Is ipipe patches (linux: 4.9.51) also needs to be upgraded for this
> issue? Or only xenomai-3/kernel patches are enough?

This particular issue was addressed in the Xenomai core, not the I-pipe
patch.

> 
> Actually, now I am stuck with another question.
> Hope if you could help me.
> 
> As I said, I applied xenomai-3.0.6, kernel patches (using
> prepare_kernel script) to my x86_64 kernel, around 4 months back.
> I am using it since then. After that I never upgraded any patches.
> 
> Now my concern is, how do I apply/upgrade only the latest patches?
> I did not remember the last commit until which I applied the patches.
> 
> Is prepare_kernel script in intelligent enough to find the patch
> difference, and apply on the latest patches ?
> 
> Normally how you people upgrade to the latest xenomai patches.
> If you have any suggestions, please guide me.

Well, best practice is versioning control and build automation. You can
pull the patch into your local kernel or use the i-pipe kernel git tree
as feed (if you have no own patches). Then you just need
prepare-kernel.sh to refresh the xenomai core.

And building everything can also be automated by scripts or more
advanced systems that also track the source revisions for you. Can be
git, can be something like yocto, buildroot etc.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

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

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-04-25 Thread Pintu Kumar 
Dear Jan,

Thank you so much for your reply.
I will try the latest stable version to check again.
Is ipipe patches (linux: 4.9.51) also needs to be upgraded for this
issue? Or only xenomai-3/kernel patches are enough?

Actually, now I am stuck with another question.
Hope if you could help me.

As I said, I applied xenomai-3.0.6, kernel patches (using
prepare_kernel script) to my x86_64 kernel, around 4 months back.
I am using it since then. After that I never upgraded any patches.

Now my concern is, how do I apply/upgrade only the latest patches?
I did not remember the last commit until which I applied the patches.

Is prepare_kernel script in intelligent enough to find the patch
difference, and apply on the latest patches ?

Normally how you people upgrade to the latest xenomai patches.
If you have any suggestions, please guide me.


Thanks,
Pintu



On Wed, Apr 25, 2018 at 3:35 PM, Jan Kiszka  wrote:
> On 2018-04-25 10:39, Pintu Kumar wrote:
>> Hi,
>>
>> I got kernel oops when using rtnet loopback with simple udp socket on
>> Xenomai 3.0
>>
>> STEPS:
>> =
>> # lspci -knn | grep -i ethernet -A 3
>> 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
>> Connection (2) I219-V [8086:15b8] (rev 31)
>> Subsystem: ASUSTeK Computer Inc. Ethernet Connection (2)
>> I219-V [1043:8672]
>> Kernel driver in use: e1000e
>> Kernel modules: e1000e
>>
>> -
>> sudo ifconfig lo down
>> sudo modprobe rtnet
>> sudo modprobe rtipv4
>> sudo modprobe rtudp
>> sudo modprobe rtpacket
>> sudo modprobe rt_loopback
>> sudo /usr/xenomai/sbin/rtifconfig rtlo up 127.0.0.1
>>
>> # /usr/xenomai/sbin/rtifconfig
>> rtlo  Medium: Local Loopback
>>   IP address: 127.0.0.1
>>   UP LOOPBACK RUNNING  MTU: 1500
>> -
>> Note: I am not installing e1000e driver, as I am checking on loopback
>> interface now.
>>
>> # ./rtnet-udp-server 5600 &
>> # ./rtnet-udp-client 5800 127.0.0.1 5600
>>
>> server => establish the UDP connection and wait for some message from client.
>> client => just send the "hello" message to the server
>>
>> Note: the same program works when build with normal Linux.
>>
>> INFO:
>> =
>> # xeno-config --info
>> Xenomai version: Xenomai/cobalt v3.0.6 -- #5956064 (2018-03-20 12:13:33 
>> +0100)
>> Linux 4.9.51-x86-64-pintu-xeno3-rtdm #2 SMP Wed Apr 25 16:30:53 JST
>> 2018 x86_64 x86_64 x86_64 GNU/Linux
>> Kernel parameters: initrd=0:\initrd.img-4.9.51-x86-64-pintu-xeno3-rtdm
>> root=/dev/disk/by-partlabel/system ro ip=off
>> I-pipe release #4 detected
>> Cobalt core 3.0.6 detected
>> Compiler: gcc version 5.4.0
>> Build args:
>>
>> =
>>
>>
>> -
>> [  377.304363]
>>*** RTnet for Xenomai v3.0.6 ***
>>
>> [  377.304366] RTnet: initialising real-time networking
>> [  377.319430] Intel(R) PRO/1000 Network Driver - version 7.1.9
>> [  377.319433] Copyright (c) 1999-2006 Intel Corporation.
>> [  379.632211] initializing loopback...
>> [  379.632218] RTnet: registered rtlo
>> [  474.312740] BUG: unable to handle kernel paging request at 
>> 7ffcb25562e8
>> [  474.312744] IP: [] rt_udp_ioctl+0x45/0x5f [rtudp]
>> [  474.312748] PGD 80bccc067
>> [  474.312749] PUD 80f039067
>> [  474.312750] PMD 80c364067
>> [  474.312751] PTE 800806e09867
>>
>> [  474.312754] Oops: 0001 [#1] SMP
>> [  474.312755] Modules linked in: rt_loopback rtpacket rtudp rt_e1000
>> rtipv4 rtnet arc4 8021q garp mrp stp llc rfcomm bnep
>> snd_hda_codec_hdmi nls_iso8859_1 ath10k_pci ath10k_core ath mac80211
>> intel_rapl eeepc_wmi asus_wmi x86_pkg_temp_thermal sparse_keymap
>> intel_powerclamp mxm_wmi coretemp kvm irqbypass crct10dif_pclmul
>> cfg80211 crc32_pclmul ghash_clmulni_intel aesni_intel
>> snd_hda_codec_realtek aes_x86_64 snd_hda_codec_generic lrw gf128mul
>> glue_helper snd_hda_intel ablk_helper snd_hda_codec cryptd btusb
>> snd_hda_core btrtl snd_hwdep mei_me mei shpchp serio_raw hci_uart
>> btbcm btqca btintel bluetooth wmi acpi_als kfifo_buf industrialio
>> intel_lpss_acpi intel_lpss mac_hid acpi_pad autofs4 e1000e psmouse ptp
>> pps_core ahci libahci video i2c_hid pinctrl_sunrisepoint pinctrl_intel
>> hid fjes
>> [  474.312806] CPU: 0 PID: 3232 Comm: rtnet-server Not tainted
>> 4.9.51-x86-64-pintu-xeno3-rtdm #2
>> [  474.312808] Hardware name: SkyLake
>> [  474.312809] I-pipe domain: Linux
>> [  474.312810] task: 8eaa4d090f00 task.stack: a4cc080d4000
>> [  474.312811] RIP: 0010:[]  []
>> rt_udp_ioctl+0x45/0x5f [rtudp]
>> [  474.312814] RSP: 0018:a4cc080d7e20  EFLAGS: 00010246
>> [  474.312815] RAX: 7ffcb25562e0 RBX: 8eaa4cf52800 RCX: 
>> 8eaa4cf52840
>> [  474.312816] RDX:  RSI: 40100022 RDI: 
>> 8eaa4cf52800
>> [  474.312817] RBP: a4cc080d7e20 R08: 7fa113b57d78 R09: 
>> 0105
>> [  474.312819] R10: 0001aa3a R11: 8eaa50e39600 R12: 
>> 0003
>> [  474.312820] R13: 8eaa4d090f00 R14:

Re: [Xenomai] Kernel oops during rtnet loopback usage on x86_64 (e1000e)

2018-04-25 Thread Jan Kiszka 
On 2018-04-25 10:39, Pintu Kumar wrote:
> Hi,
> 
> I got kernel oops when using rtnet loopback with simple udp socket on
> Xenomai 3.0
> 
> STEPS:
> =
> # lspci -knn | grep -i ethernet -A 3
> 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet
> Connection (2) I219-V [8086:15b8] (rev 31)
> Subsystem: ASUSTeK Computer Inc. Ethernet Connection (2)
> I219-V [1043:8672]
> Kernel driver in use: e1000e
> Kernel modules: e1000e
> 
> -
> sudo ifconfig lo down
> sudo modprobe rtnet
> sudo modprobe rtipv4
> sudo modprobe rtudp
> sudo modprobe rtpacket
> sudo modprobe rt_loopback
> sudo /usr/xenomai/sbin/rtifconfig rtlo up 127.0.0.1
> 
> # /usr/xenomai/sbin/rtifconfig
> rtlo  Medium: Local Loopback
>   IP address: 127.0.0.1
>   UP LOOPBACK RUNNING  MTU: 1500
> -
> Note: I am not installing e1000e driver, as I am checking on loopback
> interface now.
> 
> # ./rtnet-udp-server 5600 &
> # ./rtnet-udp-client 5800 127.0.0.1 5600
> 
> server => establish the UDP connection and wait for some message from client.
> client => just send the "hello" message to the server
> 
> Note: the same program works when build with normal Linux.
> 
> INFO:
> =
> # xeno-config --info
> Xenomai version: Xenomai/cobalt v3.0.6 -- #5956064 (2018-03-20 12:13:33 +0100)
> Linux 4.9.51-x86-64-pintu-xeno3-rtdm #2 SMP Wed Apr 25 16:30:53 JST
> 2018 x86_64 x86_64 x86_64 GNU/Linux
> Kernel parameters: initrd=0:\initrd.img-4.9.51-x86-64-pintu-xeno3-rtdm
> root=/dev/disk/by-partlabel/system ro ip=off
> I-pipe release #4 detected
> Cobalt core 3.0.6 detected
> Compiler: gcc version 5.4.0
> Build args:
> 
> =
> 
> 
> -
> [  377.304363]
>*** RTnet for Xenomai v3.0.6 ***
> 
> [  377.304366] RTnet: initialising real-time networking
> [  377.319430] Intel(R) PRO/1000 Network Driver - version 7.1.9
> [  377.319433] Copyright (c) 1999-2006 Intel Corporation.
> [  379.632211] initializing loopback...
> [  379.632218] RTnet: registered rtlo
> [  474.312740] BUG: unable to handle kernel paging request at 7ffcb25562e8
> [  474.312744] IP: [] rt_udp_ioctl+0x45/0x5f [rtudp]
> [  474.312748] PGD 80bccc067
> [  474.312749] PUD 80f039067
> [  474.312750] PMD 80c364067
> [  474.312751] PTE 800806e09867
> 
> [  474.312754] Oops: 0001 [#1] SMP
> [  474.312755] Modules linked in: rt_loopback rtpacket rtudp rt_e1000
> rtipv4 rtnet arc4 8021q garp mrp stp llc rfcomm bnep
> snd_hda_codec_hdmi nls_iso8859_1 ath10k_pci ath10k_core ath mac80211
> intel_rapl eeepc_wmi asus_wmi x86_pkg_temp_thermal sparse_keymap
> intel_powerclamp mxm_wmi coretemp kvm irqbypass crct10dif_pclmul
> cfg80211 crc32_pclmul ghash_clmulni_intel aesni_intel
> snd_hda_codec_realtek aes_x86_64 snd_hda_codec_generic lrw gf128mul
> glue_helper snd_hda_intel ablk_helper snd_hda_codec cryptd btusb
> snd_hda_core btrtl snd_hwdep mei_me mei shpchp serio_raw hci_uart
> btbcm btqca btintel bluetooth wmi acpi_als kfifo_buf industrialio
> intel_lpss_acpi intel_lpss mac_hid acpi_pad autofs4 e1000e psmouse ptp
> pps_core ahci libahci video i2c_hid pinctrl_sunrisepoint pinctrl_intel
> hid fjes
> [  474.312806] CPU: 0 PID: 3232 Comm: rtnet-server Not tainted
> 4.9.51-x86-64-pintu-xeno3-rtdm #2
> [  474.312808] Hardware name: SkyLake
> [  474.312809] I-pipe domain: Linux
> [  474.312810] task: 8eaa4d090f00 task.stack: a4cc080d4000
> [  474.312811] RIP: 0010:[]  []
> rt_udp_ioctl+0x45/0x5f [rtudp]
> [  474.312814] RSP: 0018:a4cc080d7e20  EFLAGS: 00010246
> [  474.312815] RAX: 7ffcb25562e0 RBX: 8eaa4cf52800 RCX: 
> 8eaa4cf52840
> [  474.312816] RDX:  RSI: 40100022 RDI: 
> 8eaa4cf52800
> [  474.312817] RBP: a4cc080d7e20 R08: 7fa113b57d78 R09: 
> 0105
> [  474.312819] R10: 0001aa3a R11: 8eaa50e39600 R12: 
> 0003
> [  474.312820] R13: 8eaa4d090f00 R14: 4cf52800 R15: 
> a4cc03856040
> [  474.312821] FS:  7fa1145b3740() GS:8eaa5620()
> knlGS:
> [  474.312823] CS:  0010 DS:  ES:  CR0: 8005003b
> [  474.312824] CR2: 7ffcb25562e8 CR3: 00080f0a9000 CR4: 
> 003406f0
> [  474.312825] DR0:  DR1:  DR2: 
> 
> [  474.312826] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [  474.312827] Stack:
> [  474.312828]  a4cc080d7eb0 a419a0e7 7ffcb25562e0
> 401000220003
> [  474.312831]  8eaa0010 a4cc080d7ec0 a4cc080d7e58
> 8eaa4d090f00
> [  474.312834]  a419e590 7ffcb25562e0 a4cc080d7e90
> a409a6f1
> [  474.312836] Call Trace:
> [  474.312840]  [] rtdm_fd_ioctl+0xe7/0x280
> [  474.312842]  [] ? CoBaLt_fcntl+0x20/0x20
> [  474.312844]  [] ? __ipipe_migrate_head+0x51/0xb0
> [  474.312846]  [] ? CoBaLt_fcntl+0x20/0x20
> [  474.312848]  [] CoBaLt_ioctl+0xe/0x20
> [  474.312850]  []