On Sunday 01 February 2009 02:01:24 Francesco Gringoli wrote: > Ok, this could be a problem. Will check next days how to solve. I > suppose now that the length of that report_tx_status queue is very > device dependent as mine can grow it more than one hundred elements > and status continues to be correctly reported.
I think you still probably didn't get it. The TX status queue has _nothing_ to do with the DMA queues/rings/slots or the PIO queues. These are _completely_ independent queues. Just _completely_ forget about DMA and PIO when dealing with TX status. The TX status queue is only about 16 elements (give or take a couple) on all devices. I'm not sure if it's possible to read the queue size from somewhere. It probably isn't. I think the overflow protection works through external conditions in the firmware. So there is some external condition that flags "tx status queue is full" and the firmware will neither try to queue the status report, nor try to transmit yet another frame. It will simply wait for the driver to fetch at least one entry from the queue. The external condition will flip and the firmware goes on. (However, I think the firmware probably can receive new frames while waiting for the tx status queue to get one free entry.) -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
