Hi For the past week I have been trying to find the cause of RTnet freezing up the Linux process, but without any success. In the frag_ip.c I even tried to give a parameter for start_rt_timer under oneshot mode (which if use zero ... could crash my computer - proved with the testsuite /latency example, maybe my 350Mhz is not sufficient to run so fast?). I seems that the message was unable to sent in periodical fashion and continuous printed rt_printk( ) that I could not catch what it is on the terminal. So I disabled the
rt_socket_callback(sock,recv_msg, NULL); function in frag_ip.c and finally I manage to read the bellow msg/error Sending message of 65505+2 bytes RTnet: Host 127.0.0.1 unreachable (from 0.0.0.0) rt_socket_sendmsg() = -113! Sending message of 65.... continues... the same .. I am not sure whether commenting out the above function caused that or? but.. rt_task_wait_period(); does not to be doing anything..i.e. as if not there and a instant return. I am sure I have installed RTAI properly and working normally with all testsuites running fine. So this now leaves to why the wait_period is not doing its job? Can you please tell me what loopback-rt.o and rtnet.o each should be doing? and would they have called any function that may result a infinite loop of real-time task ( as currently it seems its doing that). Or maybe one line has been commented out by accident that the task forgot to give back the handling to Linux process? I know this would sound rather rediculous but would it be possible for you to reinstall your rtnet with the one posted online again, Just to see if there is any accidental difference between your working version and the on for download please ? My last hope would be to go down to the very inside of rtnet and see what is really feezing the Linux process. so before do that..can you please try the online version out so i can be guaranteed that there is a problem with my system and not yours which means crossing the last option from my list. and just to make sure that i have installed and configured properly. This is how i installed rtnet: PC: 350Mhz 1) ./configure --with-rtai=/usr/realtime/ --enable-allpci --enable-eepro100 --enable-rtcap 2) make 3) make install 4) mknod /dev/rtnet c 10 240 Thanks Bret On Wed, 19 May 2004, Jan Kiszka wrote: > > > > 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: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ RTnet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-users
