rtnet-developers Mailing List for RTnet - Real-Time Networking for Linux (Page 2)
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-developers — development-related list
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(12) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(13) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(7) |
Jun
(13) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(11) |
| 2006 |
Jan
(2) |
Feb
|
Mar
(13) |
Apr
|
May
(6) |
Jun
(7) |
Jul
(8) |
Aug
(13) |
Sep
(28) |
Oct
(5) |
Nov
(17) |
Dec
(5) |
| 2007 |
Jan
(2) |
Feb
(18) |
Mar
(22) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(22) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(2) |
| 2008 |
Jan
|
Feb
(3) |
Mar
(15) |
Apr
(7) |
May
(2) |
Jun
(18) |
Jul
(19) |
Aug
(6) |
Sep
(7) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
| 2009 |
Jan
(8) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(16) |
Dec
(16) |
| 2010 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(8) |
Oct
(20) |
Nov
|
Dec
(10) |
| 2011 |
Jan
(15) |
Feb
(33) |
Mar
(5) |
Apr
(8) |
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(21) |
Oct
(21) |
Nov
(12) |
Dec
(7) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2014 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(8) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <huy...@wa...> - 2014-03-11 16:45:42
|
> On 2014-03-11 16:18, Anders Blomdell wrote: >> On 2014-03-11 14:23, VU Huy Cong wrote: >>>> >>>> On 2014-02-27 16:06, Anders Blomdell wrote: >>>>> ...due to the lack of create_proc_entry in newer kernels. >>>>> >>>>> ... >>>>> >>>>> Is a stack/kcompat.h (and changes to stack/rtnet_module.c) the way to >>> handle this? >>>>> >>>> >>>> Attached is a first shot at making rtnet run with 3.10.18. So far only >>>> the parts I'm interested in are touched, but if you think it looks OK, >>>> I'll >>>> look inte the rest next week. >>>> >>>> Regards >>>> >>>> Anders >>>> >>> >>> Hi Anders, >>> >>> I'm interested in your patch. Could you post the rest of the patch >>> modification here? After your patch there are still errors due to the >>> compilation. Here's what I got: >>> >>> . >>> . >>> . >>> /usr/src/rtnet-code/stack/ipv4/route.c: In function >>> ârtnet_ipv4_route_showâ: >>> /usr/src/rtnet-code/stack/ipv4/route.c:132:3: warning: label âdoneâ >>> defined >>> but not used [-Wunused-label] >>> CC [M] /usr/src/rtnet-code/stack/ipv4/protocol.o >>> CC [M] /usr/src/rtnet-code/stack/ipv4/arp.o >>> CC [M] /usr/src/rtnet-code/stack/ipv4/af_inet.o >>> /usr/src/rtnet-code/stack/ipv4/af_inet.c: In function >>> ârt_ipv4_proto_initâ: >>> /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:5: error: implicit >>> declaration >>> of function âcreate_proc_entryâ >>> [-Werror=implicit-function-declaration] >>> /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:20: warning: assignment >>> makes >>> pointer from integer without a cast [enabled by default] >>> cc1: some warnings being treated as errors >>> make[5]: *** [/usr/src/rtnet-code/stack/ipv4/af_inet.o] Error 1 >>> make[4]: *** [_module_/usr/src/rtnet-code/stack/ipv4] Error 2 >>> make[4]: Leaving directory `/usr/src/linux-3.10.18' >>> make[3]: *** [all-local.ko] Error 2 >>> make[3]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' >>> make[2]: *** [all-recursive] Error 1 >>> make[2]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' >>> make[1]: *** [all-recursive] Error 1 >>> make[1]: Leaving directory `/usr/src/rtnet-code/stack' >>> make: *** [all-recursive] Error 1 >> I know, don't use IPv4 from RTnet here, so that is disabled. Wanted >> Jan's >> keen eye before doing a lot of work (basically I would need input on >> what >> compatibility stuff is needed to support older kernels [some kernel list >> macros has changed signature, ugh...]) >> >> I will not have time this week, but maybe next... > > Sorry, still had no time to look at this very welcome fix/cleanup. It's > scheduled for my vacation days in about two weeks. > > Jan > > After disabling the IPv4, there are still problems for some define in e1000e driver: /usr/src/rtnet-code/drivers/e1000e/netdev.c: In function e1000_set_multi: /usr/src/rtnet-code/drivers/e1000e/netdev.c:2207:25: error: NETIF_F_HW_VLAN_RX undeclared (first use in this function) /usr/src/rtnet-code/drivers/e1000e/netdev.c:2207:25: note: each undeclared identifier is reported only once for each function it appears in /usr/src/rtnet-code/drivers/e1000e/netdev.c: In function e1000_probe: /usr/src/rtnet-code/drivers/e1000e/netdev.c:4105:8: error: NETIF_F_HW_VLAN_RX undeclared (first use in this function) /usr/src/rtnet-code/drivers/e1000e/netdev.c:4106:8: error: NETIF_F_HW_VLAN_TX undeclared (first use in this function) /usr/src/rtnet-code/drivers/e1000e/netdev.c:4113:23: error: NETIF_F_HW_VLAN_FILTER undeclared (first use in this function) If you have time take a look at it, it's not very urgent so I can wait. Thanks a lot, Huy Cong |
|
From: Jan K. <jan...@we...> - 2014-03-11 15:37:07
|
On 2014-03-11 16:18, Anders Blomdell wrote: > On 2014-03-11 14:23, VU Huy Cong wrote: >>> >>> On 2014-02-27 16:06, Anders Blomdell wrote: >>>> ...due to the lack of create_proc_entry in newer kernels. >>>> >>>> ... >>>> >>>> Is a stack/kcompat.h (and changes to stack/rtnet_module.c) the way to >> handle this? >>>> >>> >>> Attached is a first shot at making rtnet run with 3.10.18. So far only >>> the parts I'm interested in are touched, but if you think it looks OK, I'll >>> look inte the rest next week. >>> >>> Regards >>> >>> Anders >>> >> >> Hi Anders, >> >> I'm interested in your patch. Could you post the rest of the patch >> modification here? After your patch there are still errors due to the >> compilation. Here's what I got: >> >> . >> . >> . >> /usr/src/rtnet-code/stack/ipv4/route.c: In function ‘rtnet_ipv4_route_show’: >> /usr/src/rtnet-code/stack/ipv4/route.c:132:3: warning: label ‘done’ defined >> but not used [-Wunused-label] >> CC [M] /usr/src/rtnet-code/stack/ipv4/protocol.o >> CC [M] /usr/src/rtnet-code/stack/ipv4/arp.o >> CC [M] /usr/src/rtnet-code/stack/ipv4/af_inet.o >> /usr/src/rtnet-code/stack/ipv4/af_inet.c: In function ‘rt_ipv4_proto_init’: >> /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:5: error: implicit declaration >> of function ‘create_proc_entry’ [-Werror=implicit-function-declaration] >> /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:20: warning: assignment makes >> pointer from integer without a cast [enabled by default] >> cc1: some warnings being treated as errors >> make[5]: *** [/usr/src/rtnet-code/stack/ipv4/af_inet.o] Error 1 >> make[4]: *** [_module_/usr/src/rtnet-code/stack/ipv4] Error 2 >> make[4]: Leaving directory `/usr/src/linux-3.10.18' >> make[3]: *** [all-local.ko] Error 2 >> make[3]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/usr/src/rtnet-code/stack' >> make: *** [all-recursive] Error 1 > I know, don't use IPv4 from RTnet here, so that is disabled. Wanted Jan's > keen eye before doing a lot of work (basically I would need input on what > compatibility stuff is needed to support older kernels [some kernel list > macros has changed signature, ugh...]) > > I will not have time this week, but maybe next... Sorry, still had no time to look at this very welcome fix/cleanup. It's scheduled for my vacation days in about two weeks. Jan |
|
From: Anders B. <and...@co...> - 2014-03-11 15:18:27
|
On 2014-03-11 14:23, VU Huy Cong wrote: >> >> On 2014-02-27 16:06, Anders Blomdell wrote: >>> ...due to the lack of create_proc_entry in newer kernels. >>> >>> ... >>> >>> Is a stack/kcompat.h (and changes to stack/rtnet_module.c) the way to > handle this? >>> >> >> Attached is a first shot at making rtnet run with 3.10.18. So far only >> the parts I'm interested in are touched, but if you think it looks OK, I'll >> look inte the rest next week. >> >> Regards >> >> Anders >> > > Hi Anders, > > I'm interested in your patch. Could you post the rest of the patch > modification here? After your patch there are still errors due to the > compilation. Here's what I got: > > . > . > . > /usr/src/rtnet-code/stack/ipv4/route.c: In function ‘rtnet_ipv4_route_show’: > /usr/src/rtnet-code/stack/ipv4/route.c:132:3: warning: label ‘done’ defined > but not used [-Wunused-label] > CC [M] /usr/src/rtnet-code/stack/ipv4/protocol.o > CC [M] /usr/src/rtnet-code/stack/ipv4/arp.o > CC [M] /usr/src/rtnet-code/stack/ipv4/af_inet.o > /usr/src/rtnet-code/stack/ipv4/af_inet.c: In function ‘rt_ipv4_proto_init’: > /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:5: error: implicit declaration > of function ‘create_proc_entry’ [-Werror=implicit-function-declaration] > /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:20: warning: assignment makes > pointer from integer without a cast [enabled by default] > cc1: some warnings being treated as errors > make[5]: *** [/usr/src/rtnet-code/stack/ipv4/af_inet.o] Error 1 > make[4]: *** [_module_/usr/src/rtnet-code/stack/ipv4] Error 2 > make[4]: Leaving directory `/usr/src/linux-3.10.18' > make[3]: *** [all-local.ko] Error 2 > make[3]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/src/rtnet-code/stack' > make: *** [all-recursive] Error 1 I know, don't use IPv4 from RTnet here, so that is disabled. Wanted Jan's keen eye before doing a lot of work (basically I would need input on what compatibility stuff is needed to support older kernels [some kernel list macros has changed signature, ugh...]) I will not have time this week, but maybe next... /Anders -- Anders Blomdell Email: and...@co... Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden |
|
From: VU H. C. <huy...@wa...> - 2014-03-11 13:30:16
|
> > On 2014-02-27 16:06, Anders Blomdell wrote: > > ...due to the lack of create_proc_entry in newer kernels. > > > >... > > > > Is a stack/kcompat.h (and changes to stack/rtnet_module.c) the way to handle this? > > > > Attached is a first shot at making rtnet run with 3.10.18. So far only > the parts I'm interested in are touched, but if you think it looks OK, I'll > look inte the rest next week. > > Regards > > Anders > Hi Anders, I'm interested in your patch. Could you post the rest of the patch modification here? After your patch there are still errors due to the compilation. Here's what I got: . . . /usr/src/rtnet-code/stack/ipv4/route.c: In function ‘rtnet_ipv4_route_show’: /usr/src/rtnet-code/stack/ipv4/route.c:132:3: warning: label ‘done’ defined but not used [-Wunused-label] CC [M] /usr/src/rtnet-code/stack/ipv4/protocol.o CC [M] /usr/src/rtnet-code/stack/ipv4/arp.o CC [M] /usr/src/rtnet-code/stack/ipv4/af_inet.o /usr/src/rtnet-code/stack/ipv4/af_inet.c: In function ‘rt_ipv4_proto_init’: /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:5: error: implicit declaration of function ‘create_proc_entry’ [-Werror=implicit-function-declaration] /usr/src/rtnet-code/stack/ipv4/af_inet.c:308:20: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors make[5]: *** [/usr/src/rtnet-code/stack/ipv4/af_inet.o] Error 1 make[4]: *** [_module_/usr/src/rtnet-code/stack/ipv4] Error 2 make[4]: Leaving directory `/usr/src/linux-3.10.18' make[3]: *** [all-local.ko] Error 2 make[3]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/rtnet-code/stack/ipv4' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/rtnet-code/stack' make: *** [all-recursive] Error 1 . . . Thanks for your help Anders Blomdell <anders.blomdell <at> control.lth.se> writes: |
|
From: Anders B. <and...@co...> - 2014-02-28 16:29:35
|
On 2014-02-27 16:06, Anders Blomdell wrote: > ...due to the lack of create_proc_entry in newer kernels. > >... > > Is a stack/kcompat.h (and changes to stack/rtnet_module.c) the way to handle this? > Attached is a first shot at making rtnet run with 3.10.18. So far only the parts I'm interested in are touched, but if you think it looks OK, I'll look inte the rest next week. Regards Anders -- Anders Blomdell Email: and...@co... Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden |
|
From: Anders B. <and...@co...> - 2014-02-27 15:36:21
|
...due to the lack of create_proc_entry in newer kernels.
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c: In function ‘rtnet_proc_register’:
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:212:5: error: implicit declaration of function ‘create_proc_entry’ [-Werror=implicit-function-declaration]
rtnet_proc_root = create_proc_entry("rtnet", S_IFDIR, 0);
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:212:21: warning: assignment makes pointer from integer without a cast [enabled by default]
rtnet_proc_root = create_proc_entry("rtnet", S_IFDIR, 0);
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:216:16: warning: assignment makes pointer from integer without a cast [enabled by default]
proc_entry = create_proc_entry("devices", S_IFREG | S_IRUGO | S_IWUSR,
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:220:15: error: dereferencing pointer to incomplete type
proc_entry->read_proc = rtnet_read_proc_devices;
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:222:16: warning: assignment makes pointer from integer without a cast [enabled by default]
proc_entry = create_proc_entry("rtskb", S_IFREG | S_IRUGO | S_IWUSR,
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:226:15: error: dereferencing pointer to incomplete type
proc_entry->read_proc = rtnet_read_proc_rtskb;
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:228:16: warning: assignment makes pointer from integer without a cast [enabled by default]
proc_entry = create_proc_entry("version", S_IFREG | S_IRUGO | S_IWUSR,
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:232:15: error: dereferencing pointer to incomplete type
proc_entry->read_proc = rtnet_read_proc_version;
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:234:16: warning: assignment makes pointer from integer without a cast [enabled by default]
proc_entry = create_proc_entry("stats", S_IRUGO, rtnet_proc_root);
^
/usr/src/rtnet-7c8ba10/stack/rtnet_module.c:237:15: error: dereferencing pointer to incomplete type
proc_entry->read_proc = rtnet_read_proc_stats;
^
cc1: some warnings being treated as errors
Is a stack/kcompat.h (and changes to stack/rtnet_module.c) the way to handle this?
/Anders
--
Anders Blomdell Email: and...@co...
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
|
|
From: <nic...@wa...> - 2014-02-24 16:15:49
|
Hello, We have developed and tested a patch to go from the actual rt_e1000e present on the git repository based on the driver in the source of Linux Kernel 3.2 (Intel version 1.5.1) to e1000e's version of the Linux Kernel 3.8 (Intel version 2.1.4) which supports latest Ethernet adapter i217/i218 of the Intel's 4th generation of Core (Haswell). We have tested it on i218V and 82579V with Xenomai 2.6.3 and Linux Kernel 3.8.13. Could you look at it and merged it if it's okay for you ? Best regards, Nicolas Simon |
|
From: Jan K. <jan...@we...> - 2013-12-01 15:53:57
|
On 2013-10-11 10:16, Ilesh Patel wrote: > Hello, > > I want to implement Panda board's ethernet driver for RTnet.So, Is it > possible to implement ? how ? > > > Panda board having Ethernet interface via usb.it is based on OMAP4430 > > For,Panda board system reference manual > http://pandaboard.org/sites/default/files/board_reference/pandaboard-ea1/panda-ea1-manual.pdf > Possible, but lots of work and likely suboptimal latencies due to USB being in the loop. What is lacking for this support is not only the Ethernet driver itself but also a realtime stack for the USB controller. There is the usb4rt, but it is USB 1.1 only. Jan |
|
From: Ilesh P. <pat...@gm...> - 2013-10-11 08:16:23
|
Hello, I want to implement Panda board's ethernet driver for RTnet.So, Is it possible to implement ? how ? Panda board having Ethernet interface via usb.it is based on OMAP4430 For,Panda board system reference manual http://pandaboard.org/sites/default/files/board_reference/pandaboard-ea1/panda-ea1-manual.pdf Thanks & Regards, Ilesh |
|
From: Manuel H. <man...@gm...> - 2013-06-22 18:47:00
|
Hey, I'm sorry if it's false alarm, but Jan pointed out that the
implementation of rt_udp_recvmsg regarding msg_namelen seems wrong. So
I compared the piece of code to Linux and tried to figure out, how it
should be handled... I starred at it for quite a while but I don't get
this part:
0393 struct sockaddr_in *sin;
0419 sin = msg->msg_name;
0420
0421 /* copy the address */
0422 msg->msg_namelen = sizeof(*sin);
0423 if (sin) {
0424 sin->sin_family = AF_INET;
0425 sin->sin_port = uh->source;
0426 sin->sin_addr.s_addr = skb->nh.iph->saddr;
0427 }
Isn't msg->msg_name a user space buffer? Why is it possible to access
it from kernel space (Line 424 - 426)? I'm not really familiar with
the Linux kernel that much, therefore I checked some other parts of
RTnet (ipv4/tcp/tcp.c) and there is something strange as well:
2053 len = msg->msg_iov[0].iov_len;
2054 buf = msg->msg_iov[0].iov_base;
So I'm really getting confused... I mean wouldn't such a bug cause
serious problems? I'm running RTnet since months using the recvmsg
system call (udp) all the time and never encountered a problem. Sorry
ifthis question is somehow stupid, I really tried to figure it out
myself...
|
|
From: Jan K. <jan...@we...> - 2013-06-16 18:21:35
|
On 2013-06-16 20:13, Manuel Huber wrote: > Hi! > > Sorry for the delay, I tried to build a patch for RTAI as well... I have > written a > request to the RTAI Mailing List... > > I'll wait for the RTAI guys to answer the request, and then send the > patch to the Xenomai > mailing list (or is it sufficient to just send you a short mail?). I > believe it's important > that both projects use RTDM the same. Sure, but - just like for the kernel patches - development takes place in Xenomai. RTAI usually picks up once upstream has merged it. So push you Xenomai patch first. > > I think I will rebase the actual modification in RTnet (timestamping) > once again to > match the style of previous changes in RTnet. Is it a problem that I > first add a new > source file (commit 1) and then recreate autotools configuration and change > GNUmakefile.am in a second commit (commit 2)? Commit 1 will not build... No, this is how I merge stuff as well. Autotools diffs get too huge and make patch review too hard. Jan |
|
From: Manuel H. <man...@gm...> - 2013-06-16 18:13:19
|
Hi! Sorry for the delay, I tried to build a patch for RTAI as well... I have written a request to the RTAI Mailing List... I'll wait for the RTAI guys to answer the request, and then send the patch to the Xenomai mailing list (or is it sufficient to just send you a short mail?). I believe it's important that both projects use RTDM the same. I think I will rebase the actual modification in RTnet (timestamping) once again to match the style of previous changes in RTnet. Is it a problem that I first add a new source file (commit 1) and then recreate autotools configuration and change GNUmakefile.am in a second commit (commit 2)? Commit 1 will not build... Thanks for all your help! Manuel |
|
From: Jan K. <jan...@we...> - 2013-06-14 06:08:02
|
On 2013-06-13 18:28, Manuel Huber wrote: > Hello! > >> Xenomai only dispatches the IOCTL syscall to the driver's IOCTL handler. >> It does not interpret the request issued this way. What happens then can >> easily be traced by following the handler in RTnet: IOCTLs on UDP >> sockets, e.g., enter at rt_udp_ioctl. There you also find a use case of >> rt_socket_common_ioctl. > > Okay, I was a little confused, but I think I understood it now. > > I'm not sure if the current implementation is okay, I'm still a little > confused with the levels (SOL_IP, SOL_SOCKET) and their relation > and purpose... I have just moved the control of the timestamping > to ipv4's /ioctl/ call which checks the level and either calls > rt_ip_setsockopt > or rt_socket_setsockopt (same for ...getsockopt). > > I have also tried to fix my repository, but it's still not perfect I > fear. I > was amazed how powerfull rebase and add -p are ;) > Intermediate commits won't really work. Shall I fix this as well or > reduce some more commits? The current state can be viewed at > https://bitbucket.org/robinreal/rtnetts/overview tmp_rebase_2 branch. > > It's not finished yet, I plan to test everything once again on different > machines > but at least SCM_TIMESTAMPNS64 (the new timestamping mechanism) should > work. > >> But I think I have already figured out: it's on line 2166 and 2169 in >> __sys_recvmsg (net/socket.c). The socket level recvmsg functions >> operate on a copy in kernel space and the original user structure >> doesn't get modified (therefore the original address is still >> available in msg_control); the __put_user function just updates the >> msg_controllen field. More precisely, msg_controllen and msg_flags are written back. I didn't find an explicit statement in the POSIX spec that says the other fields have to remain unchanged, but I guess there is code assuming this. > What do you think about the different handling of struct msghdr in > regular linux > and RTDM? I believe the cmsg part should get fixed in RTDM instead of > udp.c. > > RTAI 3.5 > Should there be a change in addons/rtdm/module.c the function > sys_rtdm_recvmsg in Line 116 > > Xenomai > Should there be a change in ksrc/skins/rtdm/syscall.c the function > sys_rtdm_recvmsg in Line 96 > > Or is it better (and less effort) to just pay attention to fix the cmsg > struct in udp_recvmsg as it's > currently done and maybe do that again if the feature should be > implemented for some other > protocol? I'm fine with changing the write-back logic at RTDM level. Send a patch, and I will ack it for Xenomai. Jan |
|
From: Manuel H. <man...@gm...> - 2013-06-13 16:28:36
|
Hello! > Xenomai only dispatches the IOCTL syscall to the driver's IOCTL handler. > It does not interpret the request issued this way. What happens then can > easily be traced by following the handler in RTnet: IOCTLs on UDP > sockets, e.g., enter at rt_udp_ioctl. There you also find a use case of > rt_socket_common_ioctl. Okay, I was a little confused, but I think I understood it now. I'm not sure if the current implementation is okay, I'm still a little confused with the levels (SOL_IP, SOL_SOCKET) and their relation and purpose... I have just moved the control of the timestamping to ipv4's /ioctl/ call which checks the level and either calls rt_ip_setsockopt or rt_socket_setsockopt (same for ...getsockopt). I have also tried to fix my repository, but it's still not perfect I fear. I was amazed how powerfull rebase and add -p are ;) Intermediate commits won't really work. Shall I fix this as well or reduce some more commits? The current state can be viewed at https://bitbucket.org/robinreal/rtnetts/overview tmp_rebase_2 branch. It's not finished yet, I plan to test everything once again on different machines but at least SCM_TIMESTAMPNS64 (the new timestamping mechanism) should work. > But I think I have already figured out: it's on line 2166 and 2169 in > __sys_recvmsg (net/socket.c). The socket level recvmsg functions > operate on a copy in kernel space and the original user structure > doesn't get modified (therefore the original address is still > available in msg_control); the __put_user function just updates the > msg_controllen field. What do you think about the different handling of struct msghdr in regular linux and RTDM? I believe the cmsg part should get fixed in RTDM instead of udp.c. RTAI 3.5 Should there be a change in addons/rtdm/module.c the function sys_rtdm_recvmsg in Line 116 Xenomai Should there be a change in ksrc/skins/rtdm/syscall.c the function sys_rtdm_recvmsg in Line 96 Or is it better (and less effort) to just pay attention to fix the cmsg struct in udp_recvmsg as it's currently done and maybe do that again if the feature should be implemented for some other protocol? Best regards, Manuel |
|
From: Jan K. <jan...@we...> - 2013-06-13 05:20:59
|
On 2013-06-03 12:06, Manuel Huber wrote: >>> * I couldn't really find out, where the "normal" Linux Kernel fixes >>> the cmsg structure. After all messages have been added to the >>> buffer, the original start address and the resulting length has to >>> be written to the structure. I'm currently doing this in >>> rt_udp_recvmsg (just before "return") but I believe there is a >>> better place... >> You could run the kernel against a debugger (kgdb or the built-in >> gdbserver of QEMU/KVM) and set a watchpoint... > Sounds interesting, I haven't used either of these two, but I should > definitely set up QEMU! But I think I have already figured out: it's on > line 2166 and 2169 in __sys_recvmsg (net/socket.c). The socket level > recvmsg functions operate on a copy in kernel space and the original > user structure doesn't get modified (therefore the original address is > still available in msg_control); the __put_user function just updates > the msg_controllen field. > > So maybe that's something that should be changed in Xenomai? Is > sys_rtdm_recvmsg (ksrc/skins/rtdm/syscall.c) the function that is always > called, no matter which skin is used? Or are there system call numbers > defined for every skin? So if I use RTnet together with POSIX skin, and > I'm using the recvmsg function, __wrap_recvmsg is called (compiler > magic), which uses: > > set_errno(XENOMAI_SKINCALL3(__rtdm_muxid, __rtdm_recvmsg, fd - > __rtdm_fd_start, msg, flags)); > > which will actually resolve to a call to sys_rdtm_recvmsg? > Yes. RTDM is a skin of its own, and even POSIX uses it to provide send/recv services. >>> I don't understand how to implement socket options. Is it okay to >>> just introduce a new ioctl, or is it better to use setsockopt? I'm >>> just unsure where to implement this. Currently I wrote some code to >>> ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work >>> because of the level... The Linux Kernel has got the file sock.c >>> which implements a handler for SOL_SOCKET. Is there a simple method >>> to use setsockopt, or is it better to just introduce a new ioctl? >> You receive setsockopt request via an official IOCTL from the RTDM >> layer. Watch out for _RTIOC_SETSOCKOPT. > I'm not sure which function is supposed to handle this request. In > Linux, for example, I believe sock_setsock... only handles requests on > SOL_SOCKET level. I can't really figure out, how this is done on RTnet. > It would require some changes to (for example) add SO_TIMESTAMPNS to > rt_socket_common_ioctl: I would have to handle _RTIOC_SETSOCKOPT, and > then filter SO_TIMESTAMPNS and if it's some other option or some other > level, just return -EOPNOTSUPP? > > What's the difference between rt_socket_if_ioctl and > rt_socket_common_ioctl? It's a little complicated to figure out what > exactly happens if ioctl is called (on a socket)... Maybe I will try > again in a few days... I think I have to first check Xenomai, and then > it may be obvious which function is called first... Most likely Xenomai > will already call the function defined in some RTDM device structure, > which will call rt_socket_if_ioctl and rt_socket_common_ioctl ... Xenomai only dispatches the IOCTL syscall to the driver's IOCTL handler. It does not interpret the request issued this way. What happens then can easily be traced by following the handler in RTnet: IOCTLs on UDP sockets, e.g., enter at rt_udp_ioctl. There you also find a use case of rt_socket_common_ioctl. Jan |
|
From: Manuel H. <man...@gm...> - 2013-06-03 10:06:45
|
>> * I couldn't really find out, where the "normal" Linux Kernel fixes
>> the cmsg structure. After all messages have been added to the
>> buffer, the original start address and the resulting length has to
>> be written to the structure. I'm currently doing this in
>> rt_udp_recvmsg (just before "return") but I believe there is a
>> better place...
> You could run the kernel against a debugger (kgdb or the built-in
> gdbserver of QEMU/KVM) and set a watchpoint...
Sounds interesting, I haven't used either of these two, but I should
definitely set up QEMU! But I think I have already figured out: it's on
line 2166 and 2169 in __sys_recvmsg (net/socket.c). The socket level
recvmsg functions operate on a copy in kernel space and the original
user structure doesn't get modified (therefore the original address is
still available in msg_control); the __put_user function just updates
the msg_controllen field.
So maybe that's something that should be changed in Xenomai? Is
sys_rtdm_recvmsg (ksrc/skins/rtdm/syscall.c) the function that is always
called, no matter which skin is used? Or are there system call numbers
defined for every skin? So if I use RTnet together with POSIX skin, and
I'm using the recvmsg function, __wrap_recvmsg is called (compiler
magic), which uses:
set_errno(XENOMAI_SKINCALL3(__rtdm_muxid, __rtdm_recvmsg, fd -
__rtdm_fd_start, msg, flags));
which will actually resolve to a call to sys_rdtm_recvmsg?
>> I don't understand how to implement socket options. Is it okay to
>> just introduce a new ioctl, or is it better to use setsockopt? I'm
>> just unsure where to implement this. Currently I wrote some code to
>> ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work
>> because of the level... The Linux Kernel has got the file sock.c
>> which implements a handler for SOL_SOCKET. Is there a simple method
>> to use setsockopt, or is it better to just introduce a new ioctl?
> You receive setsockopt request via an official IOCTL from the RTDM
> layer. Watch out for _RTIOC_SETSOCKOPT.
I'm not sure which function is supposed to handle this request. In
Linux, for example, I believe sock_setsock... only handles requests on
SOL_SOCKET level. I can't really figure out, how this is done on RTnet.
It would require some changes to (for example) add SO_TIMESTAMPNS to
rt_socket_common_ioctl: I would have to handle _RTIOC_SETSOCKOPT, and
then filter SO_TIMESTAMPNS and if it's some other option or some other
level, just return -EOPNOTSUPP?
What's the difference between rt_socket_if_ioctl and
rt_socket_common_ioctl? It's a little complicated to figure out what
exactly happens if ioctl is called (on a socket)... Maybe I will try
again in a few days... I think I have to first check Xenomai, and then
it may be obvious which function is called first... Most likely Xenomai
will already call the function defined in some RTDM device structure,
which will call rt_socket_if_ioctl and rt_socket_common_ioctl ...
> On x86, the conversion will be barely visible. But on low-end archs, it
> may make a little difference. However, supporting a standard interface
> makes some sense to ease portability, so you should have SO_TIMESTAMPNS.
> An optimized interface could be added on demand.
I think it's best to support both interfaces, letting the user decide.
For my task, the conversion is pointless, since I have to convert to
nanosecs_abs_t again. It doesn't add a lot of complexity to the code to
support both.
> First remark: You are mixing changes of different kind in your commits.
> Specifically changes to generated autotools are better kept separate
> from code changes (including changes to autotools input files). Same for
> coding style changes. That will ease the review later on. Fortunately,
> git allows you reorganize things as often as you like.
>
> Oh, and something is fairly broken in your tree over there. Looks like
> one commit deletes all the generated autotools files...
>
> BTW, I don't think this feature has to be optional at compile time. It
> only adds a single if to the hotpath, not really expensive. And you
> should really measure the difference between TIMESTAMPNS64 and
> TIMESTAMPNS.
Oh, sorry. I know, it's currently a mess. I plan to re-base exp and
squash it to a single commit since actual code is just about 100 lines
or so... I know that's not what you are supposed to do, but all
intermediate commits don't add any value. The actual code isn't that
complicated; As soon as I have figured out how it should be done. I used
git to transfer between the PC I test on, and the PC I develop on, so
the exp branch is really messed up...
I can remove CONFIG_RTNET_SO_TIMESTAMPNS, I just thought it's a good
idea because the feature is new and it could cause problems (maybe on
other architectures...), but of course, it decreases code readability.
I will try to keep different changes separate. I have recently checked
another repository and it's really annoying, so thanks for the hint ;)
> What is your target arch?
My target is x86, but the patch should be available for all targets!
Therefore I think it's best to leave the decision to the user...
Thanks for your help!
|
|
From: Jan K. <jan...@we...> - 2013-05-27 18:18:26
|
On 2013-05-27 07:45, Jan Kiszka wrote: > On 2013-05-19 10:24, Manuel Huber wrote: >> Hello! >> >> I'm currently working on a patch for RTnet >> (https://bitbucket.org/robinreal/rtnetts/overview exp branch) that >> enables the user to retrieve time stamps from the driver (via >> recvmsg). Currently development is not finished, there are still >> bugs and I need to rewrite commit messages. Overview: >> >> * I hooked into the rt_udp_recvmsg function to optionally add time >> stamps to the msghdr struct. The rt_socket_recv_timestamp function >> is used to actually retrieve put the time stamp into the cmsg >> buffer. This could maybe also be used for other protocols (?). >> >> * In stack/scm.c the original put_cmsg function has been ported to >> RTDM. Currently I haven't yet implemented the put_cmsg_compat >> function. >> >> * In rtnet_socket.h I added a member sk_flags, which could be used for >> various other functions. This is used to activate and deactivate >> passing time stamps to the user (through msghdr structure). >> >> * CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet >> stack supports passing timestamps to user-space or not. > > Still need to study this. Will have a look these days while traveling. First remark: You are mixing changes of different kind in your commits. Specifically changes to generated autotools are better kept separate from code changes (including changes to autotools input files). Same for coding style changes. That will ease the review later on. Fortunately, git allows you reorganize things as often as you like ;). Oh, and something is fairly broken in your tree over there. Looks like one commit deletes all the generated autotools files... BTW, I don't think this feature has to be optional at compile time. It only adds a single if to the hotpath, not really expensive. And you should really measure the difference between TIMESTAMPNS64 and TIMESTAMPNS. What is your target arch? Jan |
|
From: Jan K. <jan...@we...> - 2013-05-27 05:45:38
|
On 2013-05-19 10:24, Manuel Huber wrote: > Hello! > > I'm currently working on a patch for RTnet > (https://bitbucket.org/robinreal/rtnetts/overview exp branch) that > enables the user to retrieve time stamps from the driver (via > recvmsg). Currently development is not finished, there are still > bugs and I need to rewrite commit messages. Overview: > > * I hooked into the rt_udp_recvmsg function to optionally add time > stamps to the msghdr struct. The rt_socket_recv_timestamp function > is used to actually retrieve put the time stamp into the cmsg > buffer. This could maybe also be used for other protocols (?). > > * In stack/scm.c the original put_cmsg function has been ported to > RTDM. Currently I haven't yet implemented the put_cmsg_compat > function. > > * In rtnet_socket.h I added a member sk_flags, which could be used for > various other functions. This is used to activate and deactivate > passing time stamps to the user (through msghdr structure). > > * CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet > stack supports passing timestamps to user-space or not. Still need to study this. Will have a look these days while traveling. > > > During implementation I ran into some problems: > > * I couldn't really find out, where the "normal" Linux Kernel fixes > the cmsg structure. After all messages have been added to the > buffer, the original start address and the resulting length has to > be written to the structure. I'm currently doing this in > rt_udp_recvmsg (just before "return") but I believe there is a > better place... You could run the kernel against a debugger (kgdb or the built-in gdbserver of QEMU/KVM) and set a watchpoint... > > * I don't understand how to implement socket options. Is it okay to > just introduce a new ioctl, or is it better to use setsockopt? I'm > just unsure where to implement this. Currently I wrote some code to > ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work > because of the level... The Linux Kernel has got the file sock.c > which implements a handler for SOL_SOCKET. Is there a simple method > to use setsockopt, or is it better to just introduce a new ioctl? You receive setsockopt request via an official IOCTL from the RTDM layer. Watch out for _RTIOC_SETSOCKOPT. > > * Is it a good idea to support a similar interface as normal > SO_TIMESTAMPNS which requires to transform nanosecs_abs_t to a > timespec structure? To support this, I would have to evaluate a > division and a modulo operation of a 64bits variable and a 32bit > constant. I'm not sure whether this is a good idea or not. Currently > I'm thinking about inventing a new cmsg identifier and flag to just > copy the nanosecs variable and also support SO_TIMESTAMPNS (which > will introduce some extra latency when active). On x86, the conversion will be barely visible. But on low-end archs, it may make a little difference. However, supporting a standard interface makes some sense to ease portability, so you should have SO_TIMESTAMPNS. An optimized interface could be added on demand. Jan |
|
From: Manuel H. <man...@gm...> - 2013-05-19 08:25:22
|
Hello! I'm currently working on a patch for RTnet (https://bitbucket.org/robinreal/rtnetts/overview exp branch) that enables the user to retrieve time stamps from the driver (via recvmsg). Currently development is not finished, there are still bugs and I need to rewrite commit messages. Overview: * I hooked into the rt_udp_recvmsg function to optionally add time stamps to the msghdr struct. The rt_socket_recv_timestamp function is used to actually retrieve put the time stamp into the cmsg buffer. This could maybe also be used for other protocols (?). * In stack/scm.c the original put_cmsg function has been ported to RTDM. Currently I haven't yet implemented the put_cmsg_compat function. * In rtnet_socket.h I added a member sk_flags, which could be used for various other functions. This is used to activate and deactivate passing time stamps to the user (through msghdr structure). * CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet stack supports passing timestamps to user-space or not. During implementation I ran into some problems: * I couldn't really find out, where the "normal" Linux Kernel fixes the cmsg structure. After all messages have been added to the buffer, the original start address and the resulting length has to be written to the structure. I'm currently doing this in rt_udp_recvmsg (just before "return") but I believe there is a better place... * I don't understand how to implement socket options. Is it okay to just introduce a new ioctl, or is it better to use setsockopt? I'm just unsure where to implement this. Currently I wrote some code to ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work because of the level... The Linux Kernel has got the file sock.c which implements a handler for SOL_SOCKET. Is there a simple method to use setsockopt, or is it better to just introduce a new ioctl? * Is it a good idea to support a similar interface as normal SO_TIMESTAMPNS which requires to transform nanosecs_abs_t to a timespec structure? To support this, I would have to evaluate a division and a modulo operation of a 64bits variable and a 32bit constant. I'm not sure whether this is a good idea or not. Currently I'm thinking about inventing a new cmsg identifier and flag to just copy the nanosecs variable and also support SO_TIMESTAMPNS (which will introduce some extra latency when active). I'm looking forward to your comments. Please let me know if you have better ideas to implement this, I would love to improve the current implementation ;) Best regards, Manuel |
|
From: Jan K. <jan...@we...> - 2012-12-12 08:27:37
|
On 2012-12-10 22:29, Glen Wernersbach wrote: > Jan or RTNet developers, > > > We are planning to have a host DHCP server computer assigned ip address to a > number of our devices which are daisy chained together via an a 2 port > switch on each of our devices. > > We would like our host DHCP server to be able to determine which of these ip > address is first in the chain and which is second which is third and so on. > > MY question is if we were running a real time os and rtnet do you think it > is possible to ping each of the of the ip address and the measure the > average its time to takes to get a response and to be able to accurate > determine where in the chain each ip address it? Already a passive switch adds at least a few microseconds latency to the round trip. So, provided to measure a statistically significant number of rounds, you should be able to detect the number of switches and, thus, the position of the node this way. Jan |
|
From: Glen W. <gl...@je...> - 2012-12-10 21:50:18
|
Jan or RTNet developers, We are planning to have a host DHCP server computer assigned ip address to a number of our devices which are daisy chained together via an a 2 port switch on each of our devices. We would like our host DHCP server to be able to determine which of these ip address is first in the chain and which is second which is third and so on. MY question is if we were running a real time os and rtnet do you think it is possible to ping each of the of the ip address and the measure the average its time to takes to get a response and to be able to accurate determine where in the chain each ip address it? Each device is in the chain is the same hardware. Glen |
|
From: Jan K. <jan...@si...> - 2012-09-20 11:05:39
|
On 2012-09-20 12:55, ILESH PATEL wrote: > Hi, > > Thank you, for your reply, > > We have Intel X-540 dual port adapter card. > Its have ixgbe driver. > > So I unload ixgbe driver using > rmmod ixgbe > > its done successful . > > Than after in rtnet.config file at > > RT_DIRVER=" .......??" what should i have to use. > > i can not find any real time driver for X-540. > if any is compatible than please suggest me. Apparently, you need some "rt_ixgbe" - which doesn't exit yet. Two options: port the Linux driver to RTnet or use a different, supported NIC. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux |
|
From: ILESH P. <pat...@gm...> - 2012-09-20 10:55:31
|
Hi, Thank you, for your reply, We have Intel X-540 dual port adapter card. Its have ixgbe driver. So I unload ixgbe driver using rmmod ixgbe its done successful . Than after in rtnet.config file at RT_DIRVER=" .......??" what should i have to use. i can not find any real time driver for X-540. if any is compatible than please suggest me. Thanks, -Ilesh |
|
From: Jan K. <jan...@si...> - 2012-09-20 10:09:28
|
On 2012-09-20 11:37, ILESH PATEL wrote: > Hi, > > My rtnet installation is done successesfuli done. > We are using > X-540 10G NIC. > Xenomia patched ubuntu linux. > > I received error as below when i start rtnet loopback test or single node > testing. > > *root@NEWI5:/usr/local/rtnet/sbin# ./rtnet start > insmod: error inserting '/usr/local/rtnet/modules/rtnet.ko': -1 File exists Which means that the module was still loaded from previous tests. Doesn't rtnet stop properly unload everything for you? Then try to find out what is blocking the unload. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux |
|
From: ILESH P. <pat...@gm...> - 2012-09-20 09:37:08
|
Hi,
My rtnet installation is done successesfuli done.
We are using
X-540 10G NIC.
Xenomia patched ubuntu linux.
I received error as below when i start rtnet loopback test or single node
testing.
*root@NEWI5:/usr/local/rtnet/sbin# ./rtnet start
insmod: error inserting '/usr/local/rtnet/modules/rtnet.ko': -1 File exists
**for your reference*
*My Some debug messages of command "ethtool -i ethx" , "lspci -k" and
"lsmod" are as follow.
*
*root@NEWI5:/usr/local/rtnet/sbin# ethtool -i eth1*
driver: ixgbe
version: 3.6.7-k
firmware-version: 0x80000389
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
*root@NEWI5:/usr/local/rtnet/sbin# ethtool -i eth2
*driver: ixgbe
version: 3.6.7-k
firmware-version: 0x80000389
bus-info: 0000:01:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
*root@NEWI5:/usr/local/rtnet/sbin# ethtool -i eth0*
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168f-1_0.0.4 03/27/12
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
root@NEWI5:/usr/local/rtnet/sbin#
*root@NEWI5:~# lsmod*
Module Size Used by
iptable_filter 12706 0
ip_tables 17791 1 iptable_filter
ip6table_filter 12711 0
ip6_tables 18115 1 ip6table_filter
x_tables 21864 4
iptable_filter,ip_tables,ip6table_filter,ip6_tables
tdma 25485 0
rtmac 14363 1 tdma
rtcfg 48344 0
rtcap 13006 0
rt_loopback 12531 2
rtpacket 12837 0
rtudp 17228 0
rt_igb 50636 0
rtipv4 24458 2 rtcfg,rtudp
rtnet 44141 9
tdma,rtmac,rtcfg,rtcap,rt_loopback,rtpacket,rtudp,rt_igb,rtipv4
uas 17525 0
usb_storage 39225 2
nls_utf8 12493 1
udf 83567 1
crc_itu_t 12627 1 udf
8021q 23253 0
garp 14057 1 8021q
stp 12811 1 garp
bnep 17711 2
rfcomm 37291 0
bluetooth 147510 10 bnep,rfcomm
parport_pc 31968 1
ppdev 12782 0
snd_hda_codec_hdmi 31514 1
snd_hda_codec_via 45508 1
i915 395624 3
snd_hda_intel 28244 2
snd_hda_codec 103402 3
snd_hda_codec_hdmi,snd_hda_codec_via,snd_hda_intel
snd_hwdep 13276 1 snd_hda_codec
drm_kms_helper 32561 1 i915
drm 196349 4 i915,drm_kms_helper
snd_pcm 75860 3
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_seq_midi 13132 0
snd_rawmidi 25381 1 snd_seq_midi
snd_seq_midi_event 14475 1 snd_seq_midi
psmouse 62573 0
snd_seq 47159 2 snd_seq_midi,snd_seq_midi_event
snd_timer 24503 2 snd_pcm,snd_seq
snd_seq_device 14137 3 snd_seq_midi,snd_rawmidi,snd_seq
snd 61194 14
snd_hda_codec_hdmi,snd_hda_codec_via,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
serio_raw 13027 0
i2c_algo_bit 13171 1 i915
mac_hid 13037 0
mei 35837 0
soundcore 14599 1 snd
snd_page_alloc 14036 2 snd_hda_intel,snd_pcm
lp 13299 0
parport 40762 3 parport_pc,ppdev,lp
usbhid 41525 0
hid 77011 1 usbhid
ixgbe 155704 0
r8169 51182 0
dca 14642 1 ixgbe
mdio 13530 1 ixgbe
*root@NEWI5:~# lspci -k*
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family
DRAM Controller (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: agpgart-intel
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core
Processor Family PCI Express Root Port (rev 09)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: i915
Kernel modules: i915
00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host
Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation Panther Point MEI
Controller #1 (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: mei
Kernel modules: mei
00:1a.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
Controller #2 (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: ehci_hcd
00:1b.0 Audio device: Intel Corporation Panther Point High Definition Audio
Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 8415
Kernel driver in use: snd_hda_intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1
(rev c4)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.4 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 5
(rev c4)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller: Intel Corporation Panther Point USB Enhanced Host
Controller #1 (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel modules: iTCO_wdt
00:1f.2 IDE interface: Intel Corporation Panther Point 4 port SATA
Controller [IDE mode] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: ata_piix
00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel modules: i2c-i801
00:1f.5 IDE interface: Intel Corporation Panther Point 2 port SATA
Controller [IDE mode] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device 84ca
Kernel driver in use: ata_piix
01:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10
Gigabit X540-AT2 (rev 01)
Subsystem: Intel Corporation Ethernet Converged Network Adapter X540-T2
Kernel driver in use: ixgbe
Kernel modules: ixgbe
01:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10
Gigabit X540-AT2 (rev 01)
Subsystem: Intel Corporation Ethernet Converged Network Adapter X540-T2
Kernel driver in use: ixgbe
Kernel modules: ixgbe
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B
PCI Express Gigabit Ethernet controller (rev 09)
Subsystem: ASUSTeK Computer Inc. Device 8505
Kernel driver in use: r8169
Kernel modules: r8169
|
4 messages has been excluded from this view by a project administrator.
