rtnet-users Mailing List for RTnet - Real-Time Networking for Linux (Page 5)
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-users — support, discussion, and announcement list
You can subscribe to this list here.
| 2003 |
Jan
(31) |
Feb
(54) |
Mar
(37) |
Apr
(25) |
May
(77) |
Jun
(56) |
Jul
(38) |
Aug
(21) |
Sep
(49) |
Oct
(22) |
Nov
(45) |
Dec
(42) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(46) |
Feb
(56) |
Mar
(70) |
Apr
(22) |
May
(36) |
Jun
(33) |
Jul
(23) |
Aug
(22) |
Sep
(20) |
Oct
(85) |
Nov
(40) |
Dec
(23) |
| 2005 |
Jan
(17) |
Feb
(13) |
Mar
(17) |
Apr
(23) |
May
(72) |
Jun
(56) |
Jul
(41) |
Aug
(17) |
Sep
(29) |
Oct
(19) |
Nov
(62) |
Dec
(44) |
| 2006 |
Jan
(33) |
Feb
(9) |
Mar
(131) |
Apr
(32) |
May
(39) |
Jun
(26) |
Jul
(45) |
Aug
(124) |
Sep
(57) |
Oct
(80) |
Nov
(69) |
Dec
(26) |
| 2007 |
Jan
(50) |
Feb
(39) |
Mar
(53) |
Apr
(23) |
May
(148) |
Jun
(59) |
Jul
(71) |
Aug
(91) |
Sep
(99) |
Oct
(63) |
Nov
(113) |
Dec
(27) |
| 2008 |
Jan
(9) |
Feb
(12) |
Mar
(38) |
Apr
(65) |
May
(65) |
Jun
(16) |
Jul
(8) |
Aug
(55) |
Sep
(15) |
Oct
(29) |
Nov
(28) |
Dec
(7) |
| 2009 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(7) |
Jul
(28) |
Aug
(4) |
Sep
(17) |
Oct
(16) |
Nov
(18) |
Dec
(30) |
| 2010 |
Jan
(6) |
Feb
(15) |
Mar
(46) |
Apr
(48) |
May
(63) |
Jun
(13) |
Jul
(40) |
Aug
(11) |
Sep
(28) |
Oct
(35) |
Nov
(5) |
Dec
(8) |
| 2011 |
Jan
(14) |
Feb
(17) |
Mar
(15) |
Apr
(9) |
May
(2) |
Jun
|
Jul
(10) |
Aug
(6) |
Sep
(13) |
Oct
(2) |
Nov
(9) |
Dec
(1) |
| 2012 |
Jan
(19) |
Feb
(13) |
Mar
(1) |
Apr
|
May
(14) |
Jun
(21) |
Jul
(13) |
Aug
(3) |
Sep
(8) |
Oct
(28) |
Nov
|
Dec
(6) |
| 2013 |
Jan
(3) |
Feb
|
Mar
(8) |
Apr
|
May
(18) |
Jun
(16) |
Jul
|
Aug
(12) |
Sep
(5) |
Oct
(14) |
Nov
(9) |
Dec
(8) |
| 2014 |
Jan
(5) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
(13) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(8) |
Dec
(8) |
| 2015 |
Jan
(22) |
Feb
|
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jan K. <jan...@we...> - 2013-12-01 15:34:32
|
On 2013-11-26 15:25, Steven Kauffmann wrote: > Hi all, > > We are running an old version of xenomai 2.4 with a patched 2.6.26.8 > kernel ( 2.6.26.8-ipipe-2.0-18). In this pc we have a intel pro 1000 > card that we are using with rtnet (version 0.9.12). We would like to > upgrade rtnet to 0.9.13 because we need the rt_e1000e module. When > building the modules we get this error: > > CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.o > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c: In > function 'e1000_cfg_on_link_up_80003es2lan': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c:1191: > error: 'SPEED_1000' undeclared (first use in this function) > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c:1191: > error: (Each undeclared identifier is reported only once > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c:1191: > error: for each function it appears in.) > > Adding the following lines in drivers/e1000e/e1000.h > #define SPEED_10 10 > #define SPEED_100 100 > #define SPEED_1000 1000 > > Rerun make and now get the following error: > > CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.o > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c: In function > 'e1000_acquire_swflag_ich8lan': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c:869: error: > implicit declaration of function 'WARN' > > Changing WARN into e_dbg but now getting another error: > > CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.o > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c: In function > 'e1000_acquire_swflag_ich8lan': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c:869: error: > expected ')' before numeric constant > > Formatting this line so it works with e_dbg and rerun make again: > > CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.o > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:56:30: error: > linux/pm_runtime.h: No such file or directory > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function > 'e1000_open': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:2726: error: > implicit declaration of function 'pm_runtime_get_sync' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:2791: error: > implicit declaration of function 'pm_runtime_put' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:2809: error: > implicit declaration of function 'pm_runtime_put_sync' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function > 'e1000_power_off': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3678: error: > implicit declaration of function 'pci_prepare_to_sleep' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3682: error: > implicit declaration of function 'pci_wake_from_d3' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function > 'e1000_io_slot_reset': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3814: error: > 'struct pci_dev' has no member named 'state_saved' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function > 'e1000_map_rtskb': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3915: warning: > passing argument 1 of 'dma_mapping_error' makes integer from pointer > without a cast > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3915: error: > too many arguments to function 'dma_mapping_error' > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function > 'e1000_probe': > /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3998: error: > implicit declaration of function > 'pci_request_selected_regions_exclusive' > make[4]: *** [/home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.o] Error 1 > > > The linux/pm_runtime.h file is not available in my kernel source tree. > According the linux cross reference this header is included in the > kernel source starting from version 2.6.32. Does that mean that I have > to build a new patched kernel? Or is there another way to solve this > error? You can wrap the differences in the driver so that it builds against older versions as well. Other drivers like the e1000 may provide inspirations for this. But in general it is better to upgrade to a recent kernel, also to take advantage of bug fixes added since then. Jan |
|
From: Jan K. <jan...@we...> - 2013-12-01 15:25:54
|
On 2013-12-01 16:16, Jan Kiszka wrote: > I'm looking into the natsemi build issue. That was trivial, see git head. Jan |
|
From: Jan K. <jan...@we...> - 2013-12-01 15:16:40
|
On 2013-11-19 11:07, Leopold Palomo-Avellaneda wrote: > Hi, > > work done. Now it compiles. Still there's a driver that doesn't compile > (natsemi), but it's another problem: > > /home/users/leopold.palomo/robotica/projects/platform/rtnet- > code/drivers/rt_natsemi.c:2018:6: error: conflicting types for ‘set_bit_le’ > In file included from /usr/src/linux-headers-3.8.13- > xenomai-2.6.3/arch/x86/include/asm/bitops.h:516:0, > from include/linux/bitops.h:22, > from include/linux/kernel.h:10, > from include/linux/cache.h:4, > from include/linux/time.h:4, > from include/linux/stat.h:18, > from include/linux/module.h:10, > from > /home/users/leopold.palomo/robotica/projects/platform/rtnet- > code/drivers/rt_natsemi.c:150: > include/asm-generic/bitops/le.h:57:20: note: previous definition of > ‘set_bit_le’ was here > make[4]: *** [/home/users/leopold.palomo/robotica/projects/platform/rtnet- > code/drivers/rt_natsemi.o] Error 1 > > > Patch attached, please apply it. Thanks for the fixes, and sorry for my late reply. The patch looks good except for some small formal issues: - The patch should be accommodated with a proper commit message: <subject line> <brief description (you can follow my argumentation for Xenomai here)> Signed-off-by: ... The latter is a formal statement that you are the copyright holder and contribute it to this project under the corresponding license. - The .gitignore change is unrelated, requires a separate path I'm looking into the natsemi build issue. Jan |
|
From: Steven K. <ste...@gm...> - 2013-11-26 14:25:29
|
Hi all, We are running an old version of xenomai 2.4 with a patched 2.6.26.8 kernel ( 2.6.26.8-ipipe-2.0-18). In this pc we have a intel pro 1000 card that we are using with rtnet (version 0.9.12). We would like to upgrade rtnet to 0.9.13 because we need the rt_e1000e module. When building the modules we get this error: CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.o /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c: In function 'e1000_cfg_on_link_up_80003es2lan': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c:1191: error: 'SPEED_1000' undeclared (first use in this function) /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c:1191: error: (Each undeclared identifier is reported only once /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/80003es2lan.c:1191: error: for each function it appears in.) Adding the following lines in drivers/e1000e/e1000.h #define SPEED_10 10 #define SPEED_100 100 #define SPEED_1000 1000 Rerun make and now get the following error: CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.o /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c: In function 'e1000_acquire_swflag_ich8lan': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c:869: error: implicit declaration of function 'WARN' Changing WARN into e_dbg but now getting another error: CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.o /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c: In function 'e1000_acquire_swflag_ich8lan': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/ich8lan.c:869: error: expected ')' before numeric constant Formatting this line so it works with e_dbg and rerun make again: CC [M] /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.o /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:56:30: error: linux/pm_runtime.h: No such file or directory /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function 'e1000_open': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:2726: error: implicit declaration of function 'pm_runtime_get_sync' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:2791: error: implicit declaration of function 'pm_runtime_put' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:2809: error: implicit declaration of function 'pm_runtime_put_sync' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function 'e1000_power_off': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3678: error: implicit declaration of function 'pci_prepare_to_sleep' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3682: error: implicit declaration of function 'pci_wake_from_d3' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function 'e1000_io_slot_reset': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3814: error: 'struct pci_dev' has no member named 'state_saved' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function 'e1000_map_rtskb': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3915: warning: passing argument 1 of 'dma_mapping_error' makes integer from pointer without a cast /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3915: error: too many arguments to function 'dma_mapping_error' /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c: In function 'e1000_probe': /home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.c:3998: error: implicit declaration of function 'pci_request_selected_regions_exclusive' make[4]: *** [/home/mobile/skau/rtnet-0.9.13/drivers/e1000e/netdev.o] Error 1 The linux/pm_runtime.h file is not available in my kernel source tree. According the linux cross reference this header is included in the kernel source starting from version 2.6.32. Does that mean that I have to build a new patched kernel? Or is there another way to solve this error? Regards Steven |
|
From: Leopold Palomo-A. <le...@al...> - 2013-11-19 10:07:56
|
Hi,
work done. Now it compiles. Still there's a driver that doesn't compile
(natsemi), but it's another problem:
/home/users/leopold.palomo/robotica/projects/platform/rtnet-
code/drivers/rt_natsemi.c:2018:6: error: conflicting types for ‘set_bit_le’
In file included from /usr/src/linux-headers-3.8.13-
xenomai-2.6.3/arch/x86/include/asm/bitops.h:516:0,
from include/linux/bitops.h:22,
from include/linux/kernel.h:10,
from include/linux/cache.h:4,
from include/linux/time.h:4,
from include/linux/stat.h:18,
from include/linux/module.h:10,
from
/home/users/leopold.palomo/robotica/projects/platform/rtnet-
code/drivers/rt_natsemi.c:150:
include/asm-generic/bitops/le.h:57:20: note: previous definition of
‘set_bit_le’ was here
make[4]: *** [/home/users/leopold.palomo/robotica/projects/platform/rtnet-
code/drivers/rt_natsemi.o] Error 1
Patch attached, please apply it.
Leopold
A Dimecres, 13 de novembre de 2013, Jan Kiszka va escriure:
[...]
> > *adapter)
> > e1000e/netdev.c:static int __devinit e1000_probe(struct pci_dev *pdev,
> > e1000e/param.c: static int __devinitdata X[E1000_MAX_NIC+1] \
> > e1000e/param.c:static int __devinit e1000_validate_option(unsigned int
*value,
> > e1000e/param.c:void __devinit e1000e_check_options(struct e1000_adapter
> > *adapter)
> >
> >
> > which change should be done?
>
> See
>
http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=3ddc61cda095a9ae51277608d7fd4e9c2c481625
>
--
--
Linux User 152692
Catalonia
|
|
From: Jan K. <jan...@si...> - 2013-11-13 12:26:46
|
On 2013-11-12 09:12, Leopold Palomo-Avellaneda wrote: > A Dimarts, 12 de novembre de 2013, Jan Kiszka va escriure: >> On 2013-11-12 08:58, Leopold Palomo-Avellaneda wrote: >>> Hi, >>> >>> using the latest version of xenomai (2.6.3) and rtnet git master, the > driver >>> experimental/e1000 doesn't compile: >>> >>> >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:271:23: error: expected ‘=’, > ‘,’, >>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’ >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:403:2: error: implicit > declaration >>> of function ‘__devexit_p’ [-Werror=implicit-function-declaration] >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:403:26: error: ‘e1000_remove’ >>> undeclared here (not in a function) >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:1083:22: error: expected ‘=’, > ‘,’, >>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_probe’ >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:1499:23: error: expected ‘=’, > ‘,’, >>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’ >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:1549:22: error: expected ‘=’, > ‘,’, >>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_sw_init’ >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:1670:22: error: expected ‘=’, > ‘,’, >>> ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_alloc_queues’ >>> /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c: >>> In function ‘e1000_test_msi_interrupt’: >>> /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:1747:20: warning: passing > argument >>> 2 of ‘request_irq’ from incompatible pointer type [enabled by default] >>> In file included from /usr/src/linux-headers-3.8.13- >>> xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers_64.h:29:0, >>> from /usr/src/linux-headers-3.8.13- >>> xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers.h:4, >>> from /usr/src/linux-headers-3.8.13- >>> xenomai-2.6.3/arch/x86/include/asm/xenomai/hal_64.h:34, >>> from /usr/src/linux-headers-3.8.13- >>> xenomai-2.6.3/arch/x86/include/asm/xenomai/hal.h:81, >>> from include/asm-generic/xenomai/system.h:39, >>> from /usr/src/linux-headers-3.8.13- >>> xenomai-2.6.3/arch/x86/include/asm/xenomai/system.h:34, >>> from /lib/modules/3.8.13- >>> xenomai-2.6.3/build/include/xenomai/nucleus/types.h:36, >>> from /lib/modules/3.8.13- >>> xenomai-2.6.3/build/include/xenomai/nucleus/thread.h:25, >>> from /lib/modules/3.8.13- >>> xenomai-2.6.3/build/include/xenomai/nucleus/sched.h:31, >>> from /lib/modules/3.8.13- >>> xenomai-2.6.3/build/include/xenomai/nucleus/pod.h:34, >>> from /lib/modules/3.8.13- >>> xenomai-2.6.3/build/include/xenomai/nucleus/xenomai.h:23, >>> from /lib/modules/3.8.13- >>> xenomai-2.6.3/build/include/xenomai/rtdm/rtdm_driver.h:37, >>> from /home/leopold.palomo/rtnet-code- >>> git/stack/include/rtnet.h:99, >>> from /home/leopold.palomo/rtnet-code- >>> git/stack/include/rtskb.h:32, >>> from /home/leopold.palomo/rtnet-code- >>> git/stack/include/rtdev.h:37, >>> from /home/leopold.palomo/rtnet-code- >>> git/stack/include/rtnet_port.h:32, >>> from /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/kcompat.h:52, >>> from /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000.h:35, >>> from /home/leopold.palomo/rtnet-code- >>> git/drivers/experimental/e1000/e1000_main.c:110: >>> > > I cannot build almost any driver with 3.8.13 :-( > - e1000e > - e1000 > - experimental > .... > > >> I suppose we need to remove the obsolete devinit/devexit tags, just like >> in Xenomai. Patches welcome. > > Ok, I'm a bit afraid because I'm not a driver/kernel developer, but could you > explain a bit more what is needed? > > I have done a grep in the git sources and have found a lot of references of > devinit, for example: > > e1000e/netdev.c:static int __devinit e1000_alloc_queues(struct e1000_adapter > *adapter) > e1000e/netdev.c:static int __devinit e1000_sw_init(struct e1000_adapter > *adapter) > e1000e/netdev.c:static int __devinit e1000_probe(struct pci_dev *pdev, > e1000e/param.c: static int __devinitdata X[E1000_MAX_NIC+1] \ > e1000e/param.c:static int __devinit e1000_validate_option(unsigned int *value, > e1000e/param.c:void __devinit e1000e_check_options(struct e1000_adapter > *adapter) > > > which change should be done? See http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=3ddc61cda095a9ae51277608d7fd4e9c2c481625 Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux |
|
From: Leopold Palomo-A. <le...@al...> - 2013-11-12 09:47:46
|
A Dimarts, 12 de novembre de 2013, BOESEL Diego Fernandes va escriure: > Hello everybody, > > A point here a bit off-topic for RTNet itself, but relevant for most project using it. > > I wonder if anyone here uses a math library, such as Eigen, Armadillo, and so on, in their RT projects. > > Are these libraries qualified to be used in RT? My point is that I've heard they create objects to store intermediate results of their computation and I am not if this can violate the RT schedulling of my threads. > > Anyone with insides here? > I think that this topic it better to discuss it on the xenomai list instead the rtnet list. Regards, Leopold -- -- Linux User 152692 Catalonia |
|
From: BOESEL D. F. <Die...@cs...> - 2013-11-12 09:25:51
|
Hello everybody, A point here a bit off-topic for RTNet itself, but relevant for most project using it. I wonder if anyone here uses a math library, such as Eigen, Armadillo, and so on, in their RT projects. Are these libraries qualified to be used in RT? My point is that I've heard they create objects to store intermediate results of their computation and I am not if this can violate the RT schedulling of my threads. Anyone with insides here? Thanks, Diego |
|
From: Leopold Palomo-A. <le...@al...> - 2013-11-12 08:12:19
|
A Dimarts, 12 de novembre de 2013, Jan Kiszka va escriure: > On 2013-11-12 08:58, Leopold Palomo-Avellaneda wrote: > > Hi, > > > > using the latest version of xenomai (2.6.3) and rtnet git master, the driver > > experimental/e1000 doesn't compile: > > > > > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:271:23: error: expected ‘=’, ‘,’, > > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’ > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:403:2: error: implicit declaration > > of function ‘__devexit_p’ [-Werror=implicit-function-declaration] > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:403:26: error: ‘e1000_remove’ > > undeclared here (not in a function) > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:1083:22: error: expected ‘=’, ‘,’, > > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_probe’ > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:1499:23: error: expected ‘=’, ‘,’, > > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’ > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:1549:22: error: expected ‘=’, ‘,’, > > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_sw_init’ > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:1670:22: error: expected ‘=’, ‘,’, > > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_alloc_queues’ > > /home/leopold.palomo/rtnet-code- git/drivers/experimental/e1000/e1000_main.c: > > In function ‘e1000_test_msi_interrupt’: > > /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:1747:20: warning: passing argument > > 2 of ‘request_irq’ from incompatible pointer type [enabled by default] > > In file included from /usr/src/linux-headers-3.8.13- > > xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers_64.h:29:0, > > from /usr/src/linux-headers-3.8.13- > > xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers.h:4, > > from /usr/src/linux-headers-3.8.13- > > xenomai-2.6.3/arch/x86/include/asm/xenomai/hal_64.h:34, > > from /usr/src/linux-headers-3.8.13- > > xenomai-2.6.3/arch/x86/include/asm/xenomai/hal.h:81, > > from include/asm-generic/xenomai/system.h:39, > > from /usr/src/linux-headers-3.8.13- > > xenomai-2.6.3/arch/x86/include/asm/xenomai/system.h:34, > > from /lib/modules/3.8.13- > > xenomai-2.6.3/build/include/xenomai/nucleus/types.h:36, > > from /lib/modules/3.8.13- > > xenomai-2.6.3/build/include/xenomai/nucleus/thread.h:25, > > from /lib/modules/3.8.13- > > xenomai-2.6.3/build/include/xenomai/nucleus/sched.h:31, > > from /lib/modules/3.8.13- > > xenomai-2.6.3/build/include/xenomai/nucleus/pod.h:34, > > from /lib/modules/3.8.13- > > xenomai-2.6.3/build/include/xenomai/nucleus/xenomai.h:23, > > from /lib/modules/3.8.13- > > xenomai-2.6.3/build/include/xenomai/rtdm/rtdm_driver.h:37, > > from /home/leopold.palomo/rtnet-code- > > git/stack/include/rtnet.h:99, > > from /home/leopold.palomo/rtnet-code- > > git/stack/include/rtskb.h:32, > > from /home/leopold.palomo/rtnet-code- > > git/stack/include/rtdev.h:37, > > from /home/leopold.palomo/rtnet-code- > > git/stack/include/rtnet_port.h:32, > > from /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/kcompat.h:52, > > from /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000.h:35, > > from /home/leopold.palomo/rtnet-code- > > git/drivers/experimental/e1000/e1000_main.c:110: > > I cannot build almost any driver with 3.8.13 :-( - e1000e - e1000 - experimental .... > I suppose we need to remove the obsolete devinit/devexit tags, just like > in Xenomai. Patches welcome. Ok, I'm a bit afraid because I'm not a driver/kernel developer, but could you explain a bit more what is needed? I have done a grep in the git sources and have found a lot of references of devinit, for example: e1000e/netdev.c:static int __devinit e1000_alloc_queues(struct e1000_adapter *adapter) e1000e/netdev.c:static int __devinit e1000_sw_init(struct e1000_adapter *adapter) e1000e/netdev.c:static int __devinit e1000_probe(struct pci_dev *pdev, e1000e/param.c: static int __devinitdata X[E1000_MAX_NIC+1] \ e1000e/param.c:static int __devinit e1000_validate_option(unsigned int *value, e1000e/param.c:void __devinit e1000e_check_options(struct e1000_adapter *adapter) which change should be done? Regards, Leopold -- -- Linux User 152692 Catalonia |
|
From: Jan K. <jan...@si...> - 2013-11-12 08:04:33
|
On 2013-11-12 08:58, Leopold Palomo-Avellaneda wrote: > Hi, > > using the latest version of xenomai (2.6.3) and rtnet git master, the driver > experimental/e1000 doesn't compile: > > > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:271:23: error: expected ‘=’, ‘,’, > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’ > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:403:2: error: implicit declaration > of function ‘__devexit_p’ [-Werror=implicit-function-declaration] > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:403:26: error: ‘e1000_remove’ > undeclared here (not in a function) > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:1083:22: error: expected ‘=’, ‘,’, > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_probe’ > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:1499:23: error: expected ‘=’, ‘,’, > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’ > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:1549:22: error: expected ‘=’, ‘,’, > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_sw_init’ > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:1670:22: error: expected ‘=’, ‘,’, > ‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_alloc_queues’ > /home/leopold.palomo/rtnet-code-git/drivers/experimental/e1000/e1000_main.c: > In function ‘e1000_test_msi_interrupt’: > /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:1747:20: warning: passing argument > 2 of ‘request_irq’ from incompatible pointer type [enabled by default] > In file included from /usr/src/linux-headers-3.8.13- > xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers_64.h:29:0, > from /usr/src/linux-headers-3.8.13- > xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers.h:4, > from /usr/src/linux-headers-3.8.13- > xenomai-2.6.3/arch/x86/include/asm/xenomai/hal_64.h:34, > from /usr/src/linux-headers-3.8.13- > xenomai-2.6.3/arch/x86/include/asm/xenomai/hal.h:81, > from include/asm-generic/xenomai/system.h:39, > from /usr/src/linux-headers-3.8.13- > xenomai-2.6.3/arch/x86/include/asm/xenomai/system.h:34, > from /lib/modules/3.8.13- > xenomai-2.6.3/build/include/xenomai/nucleus/types.h:36, > from /lib/modules/3.8.13- > xenomai-2.6.3/build/include/xenomai/nucleus/thread.h:25, > from /lib/modules/3.8.13- > xenomai-2.6.3/build/include/xenomai/nucleus/sched.h:31, > from /lib/modules/3.8.13- > xenomai-2.6.3/build/include/xenomai/nucleus/pod.h:34, > from /lib/modules/3.8.13- > xenomai-2.6.3/build/include/xenomai/nucleus/xenomai.h:23, > from /lib/modules/3.8.13- > xenomai-2.6.3/build/include/xenomai/rtdm/rtdm_driver.h:37, > from /home/leopold.palomo/rtnet-code- > git/stack/include/rtnet.h:99, > from /home/leopold.palomo/rtnet-code- > git/stack/include/rtskb.h:32, > from /home/leopold.palomo/rtnet-code- > git/stack/include/rtdev.h:37, > from /home/leopold.palomo/rtnet-code- > git/stack/include/rtnet_port.h:32, > from /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/kcompat.h:52, > from /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000.h:35, > from /home/leopold.palomo/rtnet-code- > git/drivers/experimental/e1000/e1000_main.c:110: > I suppose we need to remove the obsolete devinit/devexit tags, just like in Xenomai. Patches welcome. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux |
|
From: Leopold Palomo-A. <le...@al...> - 2013-11-12 07:58:58
|
Hi,
using the latest version of xenomai (2.6.3) and rtnet git master, the driver
experimental/e1000 doesn't compile:
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:271:23: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:403:2: error: implicit declaration
of function ‘__devexit_p’ [-Werror=implicit-function-declaration]
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:403:26: error: ‘e1000_remove’
undeclared here (not in a function)
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:1083:22: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_probe’
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:1499:23: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_remove’
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:1549:22: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_sw_init’
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:1670:22: error: expected ‘=’, ‘,’,
‘;’, ‘asm’ or ‘__attribute__’ before ‘e1000_alloc_queues’
/home/leopold.palomo/rtnet-code-git/drivers/experimental/e1000/e1000_main.c:
In function ‘e1000_test_msi_interrupt’:
/home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:1747:20: warning: passing argument
2 of ‘request_irq’ from incompatible pointer type [enabled by default]
In file included from /usr/src/linux-headers-3.8.13-
xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers_64.h:29:0,
from /usr/src/linux-headers-3.8.13-
xenomai-2.6.3/arch/x86/include/asm/xenomai/wrappers.h:4,
from /usr/src/linux-headers-3.8.13-
xenomai-2.6.3/arch/x86/include/asm/xenomai/hal_64.h:34,
from /usr/src/linux-headers-3.8.13-
xenomai-2.6.3/arch/x86/include/asm/xenomai/hal.h:81,
from include/asm-generic/xenomai/system.h:39,
from /usr/src/linux-headers-3.8.13-
xenomai-2.6.3/arch/x86/include/asm/xenomai/system.h:34,
from /lib/modules/3.8.13-
xenomai-2.6.3/build/include/xenomai/nucleus/types.h:36,
from /lib/modules/3.8.13-
xenomai-2.6.3/build/include/xenomai/nucleus/thread.h:25,
from /lib/modules/3.8.13-
xenomai-2.6.3/build/include/xenomai/nucleus/sched.h:31,
from /lib/modules/3.8.13-
xenomai-2.6.3/build/include/xenomai/nucleus/pod.h:34,
from /lib/modules/3.8.13-
xenomai-2.6.3/build/include/xenomai/nucleus/xenomai.h:23,
from /lib/modules/3.8.13-
xenomai-2.6.3/build/include/xenomai/rtdm/rtdm_driver.h:37,
from /home/leopold.palomo/rtnet-code-
git/stack/include/rtnet.h:99,
from /home/leopold.palomo/rtnet-code-
git/stack/include/rtskb.h:32,
from /home/leopold.palomo/rtnet-code-
git/stack/include/rtdev.h:37,
from /home/leopold.palomo/rtnet-code-
git/stack/include/rtnet_port.h:32,
from /home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/kcompat.h:52,
from /home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000.h:35,
from /home/leopold.palomo/rtnet-code-
git/drivers/experimental/e1000/e1000_main.c:110:
Regards,
Leopold
--
--
Linux User 152692
Catalonia
|
|
From: Leopold Palomo-A. <le...@al...> - 2013-11-12 07:53:24
|
Hi, using the latest version of xenomai (2.6.3) and rtnet 0.9.13, the driver rt2500pci doesn't compile: /home/leopold.palomo/rtnet-0.9.13/drivers/experimental/rt2500/rt_rt2500pci.c:1236:5: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit- function-declaration] /home/leopold.palomo/rtnet-0.9.13/drivers/experimental/rt2500/rt_rt2500pci.c:1236:5: error: initializer element is not constant /home/leopold.palomo/rtnet-0.9.13/drivers/experimental/rt2500/rt_rt2500pci.c:1236:5: error: (near initialization for ‘rt2x00_pci_driver.remove’) cc1: some warnings being treated as errors are you aware of this? Regards, Leopold -- -- Linux User 152692 Catalonia |
|
From: Neil T. D. <nt...@ga...> - 2013-10-22 03:50:15
|
I am trying to run RTNet using an Intel 82574L with the rt_e1000e driver. When, I start RTNet, I get the following messages posted to syslog (and my console) several times a second: ... [11965.171075] rt_e1000e: Reset adapter [11965.302808] rt_e1000e: Reset adapter [11965.434541] rt_e1000e: Reset adapter [11965.566274] rt_e1000e: Reset adapter ... Stopping RTNet usually worked (and stopped the messages). However, I also got the following oops: [12786.769498] rt_e1000e: Reset adapter [12786.896987] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 [12786.920486] IP: [<ffffffffa04beba3>] e1000_alloc_rx_buffers+0x42/0x164 [rt_e1000e] [12786.943167] PGD 223419067 PUD 22550f067 PMD 0 [12786.956581] Oops: 0000 [#1] PREEMPT SMP [12786.968389] CPU 0 [12786.973891] Modules linked in: rtcfg(O-) rt_loopback(O) rtpacket(O) rttcp(O) rtudp(O) rt_e1000e(O) rtipv4(O) rtnet(O) cts binfmt_misc deflate zlib_deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_6] [12787.245318] [12787.249784] Pid: 5583, comm: kworker/0:1 Tainted: G W O 3.2.21-gt-xenomai+ #16 Supermicro X9SCI/X9SCA/X9SCI/X9SCA [12787.282634] RIP: 0010:[<ffffffffa04beba3>] [<ffffffffa04beba3>] e1000_alloc_rx_buffers+0x42/0x164 [rt_e1000e] [12787.312580] RSP: 0018:ffff880226263d60 EFLAGS: 00010206 [12787.328461] RAX: 00000000000005f2 RBX: ffff880225cf81e0 RCX: ffffffffa04beb61 [12787.349791] RDX: 00000000000000d0 RSI: 000000000000003f RDI: ffff880225cf81e0 [12787.371122] RBP: 0000000000000000 R08: ffff880226260000 R09: 0000000000000000 [12787.392451] R10: ffff88022fc0d380 R11: ffff88022fc23d80 R12: 000000000000003f [12787.413781] R13: ffff8802245463c0 R14: ffff880225cf8690 R15: 0000000000000000 [12787.435111] FS: 0000000000000000(0000) GS:ffff88022fc00000(0000) knlGS:0000000000000000 [12787.459269] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [12787.476422] CR2: 0000000000000008 CR3: 0000000225bd0000 CR4: 00000000001006f0 [12787.497727] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [12787.519057] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [12787.540389] Process kworker/0:1 (pid: 5583, threadinfo ffff880226260000, task ffff880225798040) [12787.566388] Stack: [12787.572382] ffff880225cf81e0 000005f200989680 0000000000000001 ffff880225cf81e0 [12787.594620] ffff880225cf8528 ffff880225512dc0 ffff88022fc27700 ffff880225cf81e0 [12787.616809] 0000000000000000 ffffffffa04c117f ffff880225cf81e0 ffffffffa04c18f6 [12787.639072] Call Trace: [12787.646368] [<ffffffffa04c117f>] ? e1000e_up+0x9/0x5e [rt_e1000e] [12787.664843] [<ffffffffa04c18f6>] ? e1000e_reinit_locked+0x3e/0x47 [rt_e1000e] [12787.686433] [<ffffffffa04c1fac>] ? e1000_reset_task+0x6ad/0x6d1 [rt_e1000e] [12787.707501] [<ffffffff81304ef6>] ? sub_preempt_count+0x72/0x98 [12787.725199] [<ffffffff8104cb77>] ? queue_work+0x31/0x50 [12787.741079] [<ffffffff8102eaa3>] ? get_parent_ip+0x9/0x1b [12787.757479] [<ffffffffa04c18ff>] ? e1000e_reinit_locked+0x47/0x47 [rt_e1000e] [12787.779070] [<ffffffff8104c440>] ? process_one_work+0x149/0x2a9 [12787.797026] [<ffffffff8104d231>] ? worker_thread+0xc4/0x164 [12787.813945] [<ffffffff8104d16d>] ? manage_workers.isra.22+0x160/0x160 [12787.833459] [<ffffffff8105050c>] ? kthread+0x76/0x7e [12787.848563] [<ffffffff8130a3a4>] ? kernel_thread_helper+0x4/0x10 [12787.866777] [<ffffffff81050496>] ? flush_kthread_worker+0x8b/0x8b [12787.885253] [<ffffffff8130a3a0>] ? gs_change+0xb/0xb [12787.900354] Code: 48 83 ec 18 4c 8b af 50 04 00 00 8b 87 3c 03 00 00 45 0f b7 7d 18 89 44 24 0c 41 0f b7 ef 4d 6b ff 28 4d 03 7d 20 e9 05 01 00 00 <49> 8b 47 08 48 85 c0 74 17 83 78 78 00 74 3c 48 8b 50 60 c7 [12787.959026] RIP [<ffffffffa04beba3>] e1000_alloc_rx_buffers+0x42/0x164 [rt_e1000e] [12787.981965] RSP <ffff880226263d60> [12787.992372] CR2: 0000000000000008 [12788.002723] ---[ end trace 0755e2b8c754bace ]--- [12788.016519] BUG: unable to handle kernel paging request at fffffffffffffff8 [12788.037394] IP: [<ffffffff81050696>] kthread_data+0x7/0xc [12788.053585] PGD 1609067 PUD 160a067 PMD 0 [12788.065988] Oops: 0000 [#2] PREEMPT SMP [12788.077796] CPU 0 [12788.083298] Modules linked in: rtcfg(O-) rt_loopback(O) rtpacket(O) rttcp(O) rtudp(O) rt_e1000e(O) rtipv4(O) rtnet(O) cts binfmt_misc deflate zlib_deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_6] [12788.355037] [12788.359500] Pid: 5583, comm: kworker/0:1 Tainted: G D W O 3.2.21-gt-xenomai+ #16 Supermicro X9SCI/X9SCA/X9SCI/X9SCA [12788.392378] RIP: 0010:[<ffffffff81050696>] [<ffffffff81050696>] kthread_data+0x7/0xc [12788.415837] RSP: 0000:ffff8802262639d0 EFLAGS: 00010002 [12788.431718] RAX: 0000000000000000 RBX: ffff88022fc23d80 RCX: 0000000000000000 [12788.453048] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880225798040 [12788.474377] RBP: 0000000000000000 R08: ffff88022ffac1e0 R09: 0000000000000400 [12788.495708] R10: ffff880225798040 R11: dead000000200200 R12: 0000000000000000 [12788.517040] R13: 0000000000000001 R14: ffff880225798338 R15: ffff880225798240 [12788.538367] FS: 0000000000000000(0000) GS:ffff88022fc00000(0000) knlGS:0000000000000000 [12788.562553] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [12788.579732] CR2: fffffffffffffff8 CR3: 0000000225bd0000 CR4: 00000000001006f0 [12788.601061] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [12788.622367] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [12788.643696] Process kworker/0:1 (pid: 5583, threadinfo ffff880226260000, task ffff880225798040) [12788.669696] Stack: [12788.675692] ffffffff8104d58e ffff88022fc23d80 ffff880225798554 0000000000000000 [12788.697982] ffffffff81300c90 ffff880225798040 ffff880225798040 0000000000023d80 [12788.720248] ffff880226263fd8 ffff880226263fd8 ffff880226263fd8 ffff880226263a28 [12788.742511] Call Trace: [12788.749830] [<ffffffff8104d58e>] ? wq_worker_sleeping+0xb/0x6a [12788.767528] [<ffffffff81300c90>] ? __schedule+0x17b/0x5a8 [12788.783928] [<ffffffff8103b11a>] ? do_exit+0x723/0x73f [12788.799548] [<ffffffff8130356c>] ? oops_end+0xab/0xb0 [12788.814910] [<ffffffff812fbf8a>] ? no_context+0x1eb/0x216 [12788.831310] [<ffffffff81304cb8>] ? do_page_fault+0x189/0x355 [12788.848489] [<ffffffff8102ff5d>] ? load_balance+0x8e/0x5ef [12788.865147] [<ffffffff81030660>] ? update_curr+0xb0/0xea [12788.881288] [<ffffffff81030660>] ? update_curr+0xb0/0xea [12788.897428] [<ffffffff81001654>] ? __switch_to+0x129/0x244 [12788.914090] [<ffffffff81028044>] ? mmdrop+0xd/0x1c [12788.928672] [<ffffffff81087ffd>] ? __ipipe_get_current_domain+0x5/0xd [12788.948185] [<ffffffff8102eaa3>] ? get_parent_ip+0x9/0x1b [12788.964586] [<ffffffff81016cfb>] ? __ipipe_handle_exception+0x14e/0x16c [12788.984618] [<ffffffff81304ef6>] ? sub_preempt_count+0x72/0x98 [12789.002316] [<ffffffff8130261a>] ? _raw_spin_unlock_irqrestore+0x2a/0x38 [12789.022608] [<ffffffff81302cf6>] ? page_fault+0x26/0x70 [12789.038492] [<ffffffffa04beb61>] ? dma_alloc_coherent.constprop.51+0x8e/0x8e [rt_e1000e] [12789.062935] [<ffffffffa04beba3>] ? e1000_alloc_rx_buffers+0x42/0x164 [rt_e1000e] [12789.085301] [<ffffffffa04c117f>] ? e1000e_up+0x9/0x5e [rt_e1000e] [12789.103778] [<ffffffffa04c18f6>] ? e1000e_reinit_locked+0x3e/0x47 [rt_e1000e] [12789.125367] [<ffffffffa04c1fac>] ? e1000_reset_task+0x6ad/0x6d1 [rt_e1000e] [12789.146437] [<ffffffff81304ef6>] ? sub_preempt_count+0x72/0x98 [12789.164135] [<ffffffff8104cb77>] ? queue_work+0x31/0x50 [12789.180014] [<ffffffff8102eaa3>] ? get_parent_ip+0x9/0x1b [12789.196416] [<ffffffffa04c18ff>] ? e1000e_reinit_locked+0x47/0x47 [rt_e1000e] [12789.218007] [<ffffffff8104c440>] ? process_one_work+0x149/0x2a9 [12789.235962] [<ffffffff8104d231>] ? worker_thread+0xc4/0x164 [12789.252881] [<ffffffff8104d16d>] ? manage_workers.isra.22+0x160/0x160 [12789.272396] [<ffffffff8105050c>] ? kthread+0x76/0x7e [12789.287498] [<ffffffff8130a3a4>] ? kernel_thread_helper+0x4/0x10 [12789.305714] [<ffffffff81050496>] ? flush_kthread_worker+0x8b/0x8b [12789.324190] [<ffffffff8130a3a0>] ? gs_change+0xb/0xb [12789.339291] Code: 65 48 8b 04 25 48 b6 00 00 ff 80 44 c0 ff ff 48 8b 1d 5f 36 62 00 48 85 db 75 a8 eb b8 41 5a 5b 89 e8 5d c3 48 8b 87 a0 02 00 00 <48> 8b 40 f8 c3 48 3b 3d 06 8a 72 00 75 08 0f bf 87 72 06 00 [12789.398041] RIP [<ffffffff81050696>] kthread_data+0x7/0xc [12789.414492] RSP <ffff8802262639d0> [12789.424925] CR2: fffffffffffffff8 [12789.434835] ---[ end trace 0755e2b8c754bacf ]--- [12789.448642] Fixing recursive fault but reboot is needed! This is with RTNet 0.9.13, Xenomai 2.6.2.1, Linux 3.2.21. Any suggestions to track down this issue? Cheers, -ntd |
|
From: Hidde V. (E2M) <hve...@e2...> - 2013-10-09 13:02:03
|
On Wed, Oct 9, 2013 at 12:15 PM, Jan Kiszka <jan...@we...> wrote: > On 2013-10-09 11:13, Hidde Verstoep (E2M) wrote: >> A lot of other rt drivers use busy waits for small timeouts. >> However, the timeout here is quite large and a busy wait does not seem >> like the right solution. I wanted to try to use the rtdm timer service >> (http://www.xenomai.org/documentation/trunk/html/api/group__rtdmtimer.html). >> However, these timers are not able to pass context to a handler. So, a >> handler wouldn't know which device to check in case of multiple >> devices. Could you give a suggestion as how to solve it Jan? > > container_of(timer...) - the timer object is usually embedded in a > struct that describes the required context. But you don't need > real-timer timers unless the timeout is on the critical path. That > wasn't the case with RTnet drivers so far. I fixed the issue using rtdm timers (using your suggestion of container_of). The patch is attached. Hidde |
|
From: Jan K. <jan...@we...> - 2013-10-09 10:16:00
|
On 2013-10-09 11:13, Hidde Verstoep (E2M) wrote: > Both our versions use the linux timers. While trying to find a > solution I found that the current rt_e1000 driver also uses linux > timers. The key is that the rt_e1000 doesn't call Linux timer services from real-time contexts or while holding real-time locks. > A lot of other rt drivers use busy waits for small timeouts. > However, the timeout here is quite large and a busy wait does not seem > like the right solution. I wanted to try to use the rtdm timer service > (http://www.xenomai.org/documentation/trunk/html/api/group__rtdmtimer.html). > However, these timers are not able to pass context to a handler. So, a > handler wouldn't know which device to check in case of multiple > devices. Could you give a suggestion as how to solve it Jan? container_of(timer...) - the timer object is usually embedded in a struct that describes the required context. But you don't need real-timer timers unless the timeout is on the critical path. That wasn't the case with RTnet drivers so far. Jan |
|
From: Hidde V. (E2M) <hve...@e2...> - 2013-10-09 09:13:19
|
On Mon, Oct 7, 2013 at 5:40 PM, Stéphane ANCELOT <san...@fr...> wrote: > It unlocks the 8168 internal chip delay to process interrupts (unwanted > behaviour in real-time process). My version does this too. > It is not dedicated to work with a shared interrupt. My version does work with shared interrupts (I tested this too). > I may have locked it to 100 Mbps - FDX. (to check). Yes you have. My version should use the highest speed the hardware supports. My version seems to support 9 more different cards. Both our versions use the linux timers. While trying to find a solution I found that the current rt_e1000 driver also uses linux timers. A lot of other rt drivers use busy waits for small timeouts. However, the timeout here is quite large and a busy wait does not seem like the right solution. I wanted to try to use the rtdm timer service (http://www.xenomai.org/documentation/trunk/html/api/group__rtdmtimer.html). However, these timers are not able to pass context to a handler. So, a handler wouldn't know which device to check in case of multiple devices. Could you give a suggestion as how to solve it Jan? Regards, Hidde |
|
From: Stéphane A. <san...@fr...> - 2013-10-07 15:40:59
|
This version is known to work with an RTL8168 (kernel 2.6.34) and solves some issues. It unlocks the 8168 internal chip delay to process interrupts (unwanted behaviour in real-time process). It is not dedicated to work with a shared interrupt. I may have locked it to 100 Mbps - FDX. (to check). I let Hidde compare this one to it's version. Regards, Steph On 07/10/2013 17:28, Jan Kiszka wrote: > On 2013-10-07 16:34, Stéphane ANCELOT wrote: >> Hi, >> >> Try this one. > Please no rtdm_irq_disable/enable for synchronization. This breaks > subtly once the affected line is shared with other (real-time) devices. > It's also often quite slow. > > Didn't check all details, so could you list what you did differently > (compared to Hidde's version)? > > Thanks, > Jan > |
|
From: Jan K. <jan...@we...> - 2013-10-07 15:28:30
|
On 2013-10-07 16:34, Stéphane ANCELOT wrote: > Hi, > > Try this one. Please no rtdm_irq_disable/enable for synchronization. This breaks subtly once the affected line is shared with other (real-time) devices. It's also often quite slow. Didn't check all details, so could you list what you did differently (compared to Hidde's version)? Thanks, Jan |
|
From: Stéphane A. <san...@fr...> - 2013-10-07 14:34:58
|
Hi, Try this one. Regards, Steph On 07/10/2013 11:10, Hidde Verstoep (E2M) wrote: > On Fri, Oct 4, 2013 at 8:34 AM, Jan Kiszka <jan...@we...> wrote: >> On 2013-10-03 11:16, Hidde Verstoep (E2M) wrote: >>> Hello Sam, >>> >>> I recently posted a version of the driver I ported from a more recent >>> Linux driver. You can just drop it over the old file and it should >>> work. http://sourceforge.net/mailarchive/message.php?msg_id=31389885. >> I just had a quick look at the code: Unfortunately, it still contains >> some bugs like calling Linux services while holding RTDM locks >> (__rtl8169_check_link_status and rtl8169_phy_timer, at least). Maybe you >> check again (take a look at existing drivers for solution patterns) and >> post it here as a patch. > The timer is only used when the interface is going up, going down, or > the speed is changed. All these things are not time critical (in my > opinion). So I believe the driver can be used as-is in a realtime > environment, or do these Linux functions prevent the driver from > running in primary mode? > > I agree it would be nice if it would be fixed properly. However, it > might be a while before I get around to it. > > Hidde > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > RTnet-users mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-users |
|
From: Jan K. <jan...@we...> - 2013-10-07 10:24:07
|
On 2013-10-07 11:10, Hidde Verstoep (E2M) wrote: > On Fri, Oct 4, 2013 at 8:34 AM, Jan Kiszka <jan...@we...> wrote: >> On 2013-10-03 11:16, Hidde Verstoep (E2M) wrote: >>> Hello Sam, >>> >>> I recently posted a version of the driver I ported from a more recent >>> Linux driver. You can just drop it over the old file and it should >>> work. http://sourceforge.net/mailarchive/message.php?msg_id=31389885. >> >> I just had a quick look at the code: Unfortunately, it still contains >> some bugs like calling Linux services while holding RTDM locks >> (__rtl8169_check_link_status and rtl8169_phy_timer, at least). Maybe you >> check again (take a look at existing drivers for solution patterns) and >> post it here as a patch. > > The timer is only used when the interface is going up, going down, or > the speed is changed. All these things are not time critical (in my > opinion). So I believe the driver can be used as-is in a realtime > environment, or do these Linux functions prevent the driver from > running in primary mode? These bugs can cause sporadic misbehavior or even crashes during startup/shutdown, network reconfiguration etc., so this is a matter of robustness. > > I agree it would be nice if it would be fixed properly. However, it > might be a while before I get around to it. OK. Who knows, maybe someone else interested in the driver as well will pick earlier. Jan |
|
From: Hidde V. (E2M) <hve...@e2...> - 2013-10-07 09:10:52
|
On Fri, Oct 4, 2013 at 8:34 AM, Jan Kiszka <jan...@we...> wrote: > On 2013-10-03 11:16, Hidde Verstoep (E2M) wrote: >> Hello Sam, >> >> I recently posted a version of the driver I ported from a more recent >> Linux driver. You can just drop it over the old file and it should >> work. http://sourceforge.net/mailarchive/message.php?msg_id=31389885. > > I just had a quick look at the code: Unfortunately, it still contains > some bugs like calling Linux services while holding RTDM locks > (__rtl8169_check_link_status and rtl8169_phy_timer, at least). Maybe you > check again (take a look at existing drivers for solution patterns) and > post it here as a patch. The timer is only used when the interface is going up, going down, or the speed is changed. All these things are not time critical (in my opinion). So I believe the driver can be used as-is in a realtime environment, or do these Linux functions prevent the driver from running in primary mode? I agree it would be nice if it would be fixed properly. However, it might be a while before I get around to it. Hidde |
|
From: Jan K. <jan...@we...> - 2013-10-04 06:34:52
|
On 2013-10-03 11:16, Hidde Verstoep (E2M) wrote: > Hello Sam, > > I recently posted a version of the driver I ported from a more recent > Linux driver. You can just drop it over the old file and it should > work. http://sourceforge.net/mailarchive/message.php?msg_id=31389885. I just had a quick look at the code: Unfortunately, it still contains some bugs like calling Linux services while holding RTDM locks (__rtl8169_check_link_status and rtl8169_phy_timer, at least). Maybe you check again (take a look at existing drivers for solution patterns) and post it here as a patch. Thanks for your contribution! Jan |
|
From: sam s. <sa...@em...> - 2013-10-03 13:21:41
|
I don't think our conversation made it to the list so I thought I would re-cap. I got Hidde's rt_r8169.c from the link he posted and I dropped the rt_r8169.c file into the /rtnet-0.9.13/drivers directory. I get an error when I do a make clean make /home/empire/rtnet-0.9.13/drivers/rt_r8169.c:32:24: fatal error: asm/system.h: No such file or directory compilation terminated. make[4]: *** [/home/empire/rtnet-0.9.13/drivers/rt_r8169.o] Error 1 make[3]: *** [_module_/home/empire/rtnet-0.9.13/drivers] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-3.5.7-xenomai-2.6.2.1' make[2]: *** [all-local.ko] Error 2 make[2]: Leaving directory `/home/empire/rtnet-0.9.13/drivers' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/empire/rtnet-0.9.13/drivers' make: *** [all-recursive] Error 1 I also sent this empire@empire-K55A:~/rtnet-0.9.13$ uname -a Linux empire-K55A 3.5.7-xenomai-2.6.2.1 #1 SMP Sat Feb 9 15:03:06 CST 2013 x86_64 x86_64 x86_64 GNU/Linux Hidde suggested Hello, I use kernel 3.2.21 with xenomai 2.6.2.1. The latest RTNet release only supports kernels up to 3.2 according to the news: http://sourceforge.net/p/rtnet/news/. well - I went into the rt_r8169.c file and just remarked out #include <asm/system.h> make clean and then a make seemed to work then. and it seemed to build - I was able to up the rteth0 and also solicit a route. The reason I am playing with RTnet is Linuxcnc (a machine control software) is starting to support realtime ethernet devices. I have a mesa 7i80 that I can not use with my laptop for testing. (interface device for machine control) I just tested it and it also seems to work so - SUCCESS!! http://www.electronicsam.com/images/KandT/testing/LaptopRTnet.jpg Thanks much!! sam On 10/3/2013 4:16 AM, Hidde Verstoep (E2M) wrote: > Hello Sam, > > I recently posted a version of the driver I ported from a more recent > Linux driver. You can just drop it over the old file and it should > work. http://sourceforge.net/mailarchive/message.php?msg_id=31389885. > > I see now that it was an HTML message, which is why you might not have > found it. This mail should be in plain text now. > > Kind regards, > > Hidde Verstoep > E2M Technologies B.V. > > On Wed, Oct 2, 2013 at 9:47 PM, sam sokolik <sa...@em...> wrote: >> I meant the subject to say >> >> RTL8168 using the rt_r8169.ko driver >> >> Also - I did try the rt_8139too.ko driver the same way.. Got this >> similar error >> >> [16716.482616] rt_8139too: 0000:03:00.2: region #1 not an MMIO resource, >> aborting >> [16716.482621] Trying to free nonexistent resource >> <000000000000e000-000000000000e0ff> >> [16716.482624] Trying to free nonexistent resource >> <00000000f0004000-00000000f0004fff> >> [16716.482626] Trying to free nonexistent resource >> <00000000f0000000-00000000f0003fff> >> >> thanks >> sam >> >> >> On 10/2/2013 11:59 AM, sam sokolik wrote: >>> I am getting this exact error (RTnet 0.9.13) >>> >>> http://www.mail-archive.com/rtn...@li.../msg03371.html >>> >>> This is what I did. >>> >>> lspci -nnk >>> >>> gets me >>> >>> 03:00.2 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. >>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] >>> (rev 0a) >>> Subsystem: ASUSTeK Computer Inc. Device [1043:1457] >>> Kernel modules: r8169 >>> >>> Next >>> >>> sudo echo "10ec 8168" > /sys/bus/pci/drivers/rt_r8169/new_id >>> >>> and get in dmesg >>> [ 951.112877] rt_r8169: region #1 not an MMIO resource, aborting >>> >>> Is there any work around? My google foo is failing me. >>> >>> sam >>> >>> >>> ------------------------------------------------------------------------------ >>> October Webinars: Code for Performance >>> Free Intel webinars can help you accelerate application performance. >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >>> the latest Intel processors and coprocessors. See abstracts and register > >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> RTnet-users mailing list >>> RTn...@li... >>> https://lists.sourceforge.net/lists/listinfo/rtnet-users >>> >>> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> RTnet-users mailing list >> RTn...@li... >> https://lists.sourceforge.net/lists/listinfo/rtnet-users > |
|
From: Hidde V. (E2M) <hve...@e2...> - 2013-10-03 09:16:22
|
Hello Sam, I recently posted a version of the driver I ported from a more recent Linux driver. You can just drop it over the old file and it should work. http://sourceforge.net/mailarchive/message.php?msg_id=31389885. I see now that it was an HTML message, which is why you might not have found it. This mail should be in plain text now. Kind regards, Hidde Verstoep E2M Technologies B.V. On Wed, Oct 2, 2013 at 9:47 PM, sam sokolik <sa...@em...> wrote: > I meant the subject to say > > RTL8168 using the rt_r8169.ko driver > > Also - I did try the rt_8139too.ko driver the same way.. Got this > similar error > > [16716.482616] rt_8139too: 0000:03:00.2: region #1 not an MMIO resource, > aborting > [16716.482621] Trying to free nonexistent resource > <000000000000e000-000000000000e0ff> > [16716.482624] Trying to free nonexistent resource > <00000000f0004000-00000000f0004fff> > [16716.482626] Trying to free nonexistent resource > <00000000f0000000-00000000f0003fff> > > thanks > sam > > > On 10/2/2013 11:59 AM, sam sokolik wrote: >> I am getting this exact error (RTnet 0.9.13) >> >> http://www.mail-archive.com/rtn...@li.../msg03371.html >> >> This is what I did. >> >> lspci -nnk >> >> gets me >> >> 03:00.2 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. >> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] >> (rev 0a) >> Subsystem: ASUSTeK Computer Inc. Device [1043:1457] >> Kernel modules: r8169 >> >> Next >> >> sudo echo "10ec 8168" > /sys/bus/pci/drivers/rt_r8169/new_id >> >> and get in dmesg >> [ 951.112877] rt_r8169: region #1 not an MMIO resource, aborting >> >> Is there any work around? My google foo is failing me. >> >> sam >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> RTnet-users mailing list >> RTn...@li... >> https://lists.sourceforge.net/lists/listinfo/rtnet-users >> >> > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > RTnet-users mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-users |
|
From: sam s. <sa...@em...> - 2013-10-02 19:47:59
|
I meant the subject to say RTL8168 using the rt_r8169.ko driver Also - I did try the rt_8139too.ko driver the same way.. Got this similar error [16716.482616] rt_8139too: 0000:03:00.2: region #1 not an MMIO resource, aborting [16716.482621] Trying to free nonexistent resource <000000000000e000-000000000000e0ff> [16716.482624] Trying to free nonexistent resource <00000000f0004000-00000000f0004fff> [16716.482626] Trying to free nonexistent resource <00000000f0000000-00000000f0003fff> thanks sam On 10/2/2013 11:59 AM, sam sokolik wrote: > I am getting this exact error (RTnet 0.9.13) > > http://www.mail-archive.com/rtn...@li.../msg03371.html > > This is what I did. > > lspci -nnk > > gets me > > 03:00.2 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] > (rev 0a) > Subsystem: ASUSTeK Computer Inc. Device [1043:1457] > Kernel modules: r8169 > > Next > > sudo echo "10ec 8168" > /sys/bus/pci/drivers/rt_r8169/new_id > > and get in dmesg > [ 951.112877] rt_r8169: region #1 not an MMIO resource, aborting > > Is there any work around? My google foo is failing me. > > sam > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > RTnet-users mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-users > > |
37 messages has been excluded from this view by a project administrator.
