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. > 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? -- Greetings Michael.
pgpNQ4hrDtuKV.pgp
Description: PGP signature
