James Kilts wrote: >> I suspect the driver has some bug in its RX path, and the RTmac layer is >> the first consumer suffering from it, generating an exception. > > I've traced back through the RX path, but I don't see anything out of the > ordinary compared to the other RTnet drivers. Really, I'm a little bit > confused as to how rtcfg_rx_task can work. In rtcfg_rx_task() the last > parameter to rtcfg_do_main_event() is rtskb*, which it gets from > rtskb_dequeue(). This parameter is implicitly cast to void*. > rtcfg_do_main_event() in turn calls the function pointer from array state[], > which in the initial part of slave mode will call rtcfg_main_state_off(). > Here the rtskb* is cast from void* to rt_proc_call*. All of this wouldn't > be so bad if rt_proc_call and rtskb were compatible structures, but the two > are quite different from the very beginning.
rtcfg_main_state_off should not be called, even if the frame is totally corrupted (yeah, we are lacking basic range checks here): RTCFG_FRM_STAGE_1_CFG is added to the header ID, so you normally end up in the frame event handlers. What is the header ID when things go wrong? > > Does rtskb_dequeue() actually return a rt_proc_call*, just improperly cast > as a rtskb*? > > > >> Resolve the address given along with the suspension error, check the >> disassembly or instrument the RTmac code to find out what it tries to >> access (I bet some rtskb field that is corrupted). > > Even after the exception in RTcfg, the driver itself continues to produce > (as far as I can tell) valid rtskb instances with incoming traffic. > Although the exception is in RTcfg, is there a part of the code in RTmac > that I should investigate for corruption? Not RTmac, start with the frame as the stack finds it in memory after the driver handed it over. If that one is correct, we have a bug in the higher layers. But I strongly suspect the frame is corrupted. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
