Michael Buesch wrote:
Ok, I think your fix is more or less correct.
The original driver does not have any timeout in mac suspend. It just spins
until the device responds with IRQ_READY. At least, that's what I can see from
the specs.
Im my opinion it is very rude to work without a timeout, here.
I think we should raise it to some very big value. Maybe half a second, or even
a whole second.
I will apply a mac_suspend fix to my tree.
I think I have figured out what happens in my "Failed to suspend mac/XMIT
ERROR" sequence. When I
increased the loop count from 1000 to 10000 where the code spins waiting for
IRQ_READY to be set, I
still got "failure to suspend mac" messages, but the XMIT ERROR message was no
longer printed. This
made me suspect that the periodic_work1 operation was triggered at a point between
dmacontroller_poke_tx and the end of the operation in bcm43xx_dma_handle_xmitstatus, while the
firmware was doing the transmission.
To test this, I added a flag that is set in bcm43xx_dma_tx and cleared in
bcm43xx_dma_handle_xmitstatus when 'is_last_fragment' is true. In all of the
periodic work handlers,
the new flag is tested. If set, the work of the handler is skipped and the
periodic work is
rescheduled. In periodic_work1_handler where my problem occurred, a message is temporarily logged
when this happens. In roughly 10 hours of testing, I have received a number of these messages.
If this change seems to help after more testing, I will submit a patch.
Larry
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
