|
From: James K. <jam...@gm...> - 2009-12-09 09:42:24
|
> 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. 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? Thanks, - James |
