Re: Failed to suspend mac

2006-02-10 Thread Johannes Berg
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

2006-02-08 Thread Michael Buesch
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

2006-02-08 Thread Larry Finger

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