Michael Buesch wrote:
On Wednesday 08 February 2006 18:20, you wrote:
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
I just increased the timeout to 100000 loops in my tree. That should be enough.
The original driver looped 3500 times here, is that enough Larry? I've
changed the specs to reflect this.
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.
Very interresting.
Johannes, what is your opinion on that. Does the original driver also
implement a mutex here?
As far as I know, no, but I'll take a look at the newer driver, perhaps
one was added later.
-Joe
_______________________________________________
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
