I unplugged the cable to the network and ran "rtnet start" the computer stil froze. I don't think the computer crashed since beefore when it was connected to the network... it was still outputing printk to the screen..
When you are no longer able to use a console of your computer, then something serious must have happened. A frozen system may have silentely crashed.
You previously suggested me in manually insmod rtnet.o and loopback-rt.o to test whether the core is doing fine.
I configured as such like you advised.
rtifconfig rtlo up 127.0.0.1 insmod examples/frag-ip/frag-ip.o start_timer=1
the screen continuously output something i could hardly catch up .. but presumabily they are what is written for transmit packet and receive packets... One odd thing i have manage to find out is that my key-board "Num Lock" light kept on blinking and not responding my control. Also i coudln't not ALT+F* to any other consoles. From this response I guess the hard real-time task is taking most of the CPU which is probably the reason why the Linux process is at halt or seem crashed...
I went and open what the frag-ip.c file is doing... One thing i wondered is in the if(timer_start) that start_rt_timer has an argument of "0" in the module initialising function... I am not sure what start_rt_timer(0) actually will do.. but a tick of 0 i guess mean absolutely fast ? I noticed that rt_task_make_periodic_relative_ns() is called .. which has the CYCLE set to 1s ... so wondered how the loop went so fast?
Well, this indicates that some part of your setup is broken. Actually, this is the most simple scenario which should only lead to a periodic output of frag_ip.o on the kernel console - 1 per second. And this is also absolutely hardware-independent if RTAI works correctly.
Latency tests or any example from the showroom (RTAI 3.x, earlier version already come with that examples). See RTAI docs.
Yes I have tried those tests provide by RTAI3.x and all worked.. In fact I have also written a little something as real-time tasks and also worked. As I guess RTAI3.x is not the cause of the problem
Did your task use the timer functionality of RTAI (was it periodic or did it wait for a certain time)? I think that the problem is related to this part of RTAI, it is VERY unlikely that something is wrong with RTnet (as long as you compile it against the correct RTAI source/installation tree).
Jan
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ RTnet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-users
