Ah, you sent this separately in private mail and to the list. Here's my reply also for the list:
Alexander Smirnov wrote: > Currently I don't clearly imagine a situation, when in BUSY_RX condition > we will request for RX_ON. Sorry, my description may have been a bit fuzzy. This happens after at86rf230_state writes STATE_RX_ON to SR_TRX_CMD. It then tries to verify that SR_TRX_STATUS has really changed to STATE_RX_ON. However, if the host is slow enough and someone is sending at just the right moment, we may transition -> STATE_TRANSITION_IN_PROGRESS -> STATE_RX_ON -> STATE_BUSY_RX before reading SR_TRX_STATUS. And then at86rf230_state complains. Nothing bad happens besides the complaint, because the error code trickles up to mac802154_xmit_worker and is simply ignored there. You can see this happen quite often if your hardware is just slow enough :-) (We're working on the USB-to-SPI infrastructure for atusb and it's still quite sluggish at the moment. Which is of course great for spotting races.) - Werner ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
