Cédrick ROCHET wrote: > Hi, > well it helps ( the patch directly didn't work but I > had the idea) > but i got stuck on open socket: > > #RTnet, simpleserver for LXRT > #Error opening socket: -12
That's now likely due to the fact that a syscall via RTDM into RTnet
*after* rt_task_init is performed in real-time context. By default,
RTnet is lacking any resources to accept socket creation requests in RT.
This can be tuned of course, but it is generally not what you want.
Setup/cleanup should take place in non-RT in most cases.
I think this is why the original example had the rt_dev_socket call
*before* rt_task_init, the only non-RT context in the sense of RTAI
LXRT. And this must have worked with older versions.
So (@Paolo): Is there a design change in 3.3 preventing LXRT syscalls,
e.g. to RTDM, before we have the context a LXRT userspace task? How
should a user invoke a RTDM function so that the driver will run in non-RT?
RTDM is is built on this dual-invokation concept, i.e. the chance to
invoke driver functions either from RT or from non-RT and handle the
request each time in an optimised way.
>
> Eventhough I am able to rtping an other computer...
> I am searching but an idea is welcome.
>
> Thanks.
>
> PS: be careful of having two network cards with the
> same bios irq!
You mean one IRQ for a RT the other for a non-RT device? Yea, well known
generic and not easily solvable issue to all real-time extensions.
Jan
>
> --- Jan Kiszka <[EMAIL PROTECTED]> a écrit :
>
>
>>Cédrick ROCHET wrote:
>>
>>>hi,
>>>
>>>I have the latest rtai-rtnet versions and a
>>
>>2.6.14.3
>>
>>>kernel version
>>>
>>>when I launch the rtai-rtnet example I have a
>>>segmentation fault.
>>>Also rtnet doesn't want to unload => reboot
>>
>>machine to
>>
>>>get it off.
>>>
>>>here is my manual launching script
>>>
>>>ifconfig eth1 down
>>>rmmod e100
>>>mknod /dev/rtnet c 10 240
>>>insmod /usr/realtime/modules/rtai_hal.ko
>>>insmod /usr/realtime/modules/rtai_lxrt.ko
>>>insmod /usr/realtime/modules/rtai_sem.ko
>>>insmod /usr/realtime/modules/rtai_rtdm.ko
>>>insmod /usr/local/rtnet/modules/rtnet.ko
>>>insmod /usr/local/rtnet/modules/rt_eepro100.ko
>>>insmod /usr/local/rtnet/modules/rtipv4
>>>/usr/local/rtnet/sbin/rtifconfig rteth0 up
>>
>>10.0.0.1
>>
>>>netmask 255.255.255.0
>>>/usr/local/rtnet/sbin/rtroute solicit 10.0.0.2 dev
>>>rteth0
>>>
>>>and here is the stack of dmesg for simpleserver (
>>
>>the
>>
>>>2 others have the same problem):
>>>
>>>
>>> <1>Unable to handle kernel NULL pointer
>>
>>dereference
>>
>>>at virtual address 000003f0 printing eip:
>>>f8ca0b7b
>>>*pde = 24fc1001
>>>Oops: 0000 [#2]
>>>SMP
>>>Modules linked in: rtipv4 rt_eepro100 rtnet
>>
>>rtai_rtdm
>>
>>>rtai_sem rtai_lxrt rtai_hal lp ipv6 autofs4 rfcomm
>>>l2cap bluetooth sunrpc dm_mod video button battery
>>
>>ac
>>
>>>uhci_hcd parport_pc parport i2c_viapro i2c_core
>>>snd_via82xx gameport snd_ac97_codec snd_ac97_bus
>>>snd_seq_dummy snd_seq_oss snd_seq_midi_event
>>
>>snd_seq
>>
>>>snd_pcm_oss snd_mixer_oss snd_pcm snd_timer
>>>snd_page_alloc snd_mpu401_uart snd_rawmidi
>>>snd_seq_device snd soundcore 8139too mii floppy
>>>CPU: 0
>>>EIP: 0060:[<f8ca0b7b>] Not tainted VLI
>>>EFLAGS: 00010202 (2.6.14.3)
>>>EIP is at rtai_lxrt_invoke+0x9b/0x1210 [rtai_lxrt]
>>>eax: 0000000f ebx: f8c33a10 ecx: 00000002
>>
>>edx:
>>
>>>00000000
>>>esi: 00000001 edi: 0f00280c ebp: bffa2650
>>
>>esp:
>>
>>>e4546f1c
>>>ds: 007b es: 007b ss: 0068
>>>Process simpleserver (pid: 3623,
>>
>>threadinfo=e4546000
>>
>>>task=e7058aa0)
>>>Stack: bffa5000 00000000 00000001 00000000
>>
>>00000000
>>
>>>00000000 ec76817c ffffffea
>>> f549cf20 00000000 bff8f000 bffa5000
>>
>>bff8f000
>>
>>>bffa5000 00102173 eddc5a40
>>> 00000000 000bff8f 00000000 00000001
>>
>>e4546f90
>>
>>>e4546000 00000003 c0166ea3
>>>Call Trace:
>>> [<c0166ea3>] do_mlockall+0x83/0xa0
>>> [<f8c1af54>] rtai_syscall_dispatcher+0xc4/0x138
>>>[rtai_hal]
>>> [<f8c1afe2>] rtai_uvec_handler+0x1a/0x38
>>
>>[rtai_hal]
>>
>>>Code: 05 00 00 89 f8 c1 e8 18 83 e0 0f 8b 14 85 20
>>
>>26
>>
>>>cb f8 85 d2 0f 84 ca 0a 00 00 8d 1c ca 8b 33 85 f6
>>
>>0f
>>
>>>84 01 0b 00 00 8b 54 24 6c <8b> 82 f0 03 00 00 85
>>
>>c0
>>
>>>0f 88 66 0b 00 00 81 e7 ff 07 00 00 f7
>>>
>>>
>>>When I lunch a lxrt program under rtai without
>>
>>rtnet
>>
>>>no problem to report.
>>>So any idea: wrong compilation, wrong files, .....
>>>
>>
>>I don't have any RTAI system to test my theory
>>around anymore, but I
>>think I know some possible reason. Please try the
>>attached patch.
>>
>>What I guess is that RTAI does not gracefully catch
>>the case the someone
>>like our evil examples issue the first LXRT syscall
>>before creating any
>>RTAI task context.
>>
>>Please report back if it helps.
>>
>>Jan
>>
>>>Index: examples/rtai/simpleserver.c
>>
> ===================================================================
>
>>--- examples/rtai/simpleserver.c (Revision 940)
>>+++ examples/rtai/simpleserver.c (Arbeitskopie)
>>@@ -64,22 +64,21 @@
>> /* Lock allocated memory into RAM. */
>> mlockall(MCL_CURRENT|MCL_FUTURE);
>>
>>- /* Create new socket. */
>>- sockfd = rt_dev_socket(AF_INET, SOCK_DGRAM, 0);
>>- if (sockfd < 0) {
>>-
>>- printf("Error opening socket: %d\n",
>>sockfd);
>>- exit(1);
>>- }
>>-
>> /* Initialize a real time buddy. */
>> lxrtnettsk = rt_task_init(4900, 1, 0, 0);
>> if (NULL == lxrtnettsk) {
>>- rt_dev_close(sockfd);
>> printf("CANNOT INIT MASTER TASK\n");
>> exit(1);
>> }
>>
>>+ /* Create new socket. */
>>+ sockfd = rt_dev_socket(AF_INET, SOCK_DGRAM, 0);
>>+ if (sockfd < 0) {
>>+ rt_task_delete(lxrtnettsk);
>>+ printf("Error opening socket: %d\n",
>>sockfd);
>>+ exit(1);
>>+ }
>>+
>> /* Switch over to hard realtime mode. */
>> rt_make_hard_real_time();
>>
>>
signature.asc
Description: OpenPGP digital signature
