Re: Failed to suspend mac
On Wed, 2006-02-08 at 18:35 +0100, Michael Buesch wrote: > Johannes, what is your opinion on that. Does the original driver also > implement a mutex here? Not as far as I can see. johannes signature.asc Description: This is a digitally signed message part
Re: Failed to suspend mac
Joseph Jezak wrote: Michael Buesch wrote: The original driver looped 3500 times here, is that enough Larry? I've changed the specs to reflect this. On my system, when 1000 fails, 1 still doesn't work as the IRQ_READY will never appear. With my modification, it hasn't failed in nearly 24 hours. The best I ever did before was 5 or 6 hours, but sometimes failed in minutes. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Failed to suspend mac
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 1 where the code spins waiting > >>for IRQ_READY to be set, I > > > > > > I just increased the timeout to 10 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
Re: Failed to suspend mac
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 1 where the code spins waiting for IRQ_READY to be set, I I just increased the timeout to 10 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
Re: Failed to suspend mac
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 1 where the code spins waiting for > IRQ_READY to be set, I I just increased the timeout to 10 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
Re: Failed to suspend mac
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 1 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 Bcm43xx-dev@lists.berlios.de http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
