On Wednesday 08 February 2006 21:05, Joseph Jezak wrote: > 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.
Well, I think it is unlikely that this is the source of the problem, anyway. I think that something in the bcm43xx_calc_nrssi_slope is still broken. There are other problems with this function. It is called from the interference mitigation code and it also breaks for me, when called from there. -- Greetings Michael.
pgpIMa4Na2x4z.pgp
Description: PGP signature
