Michael Buesch wrote:
It appears to be an older card. There are quite some special codepaths for this, I think.
Yes, I bought this card before the G specifications were finalized.
Well, we did not want to have the card, because at this point it did not make sense. We all have 4306 cards. But now it appears that this card seems to have some special things (because it is older than ours). Well, how to debug. We are waiting for the IRQ Reason register there. Actually, we are waiting for the "no IRQ pending, but READY signal" state. Your card does not completely (?) clear the bits after MAC shutdown. So very helpful would be to print out in the loop the value. We know, that the card generates silly IRQs, that we did not ask for. That may happen here, too. So it _may_ help to mask out unwanted IRQs before the if-check. But I would first like to see a log of the reason-value on each iteration until it succeeds.
First of all, I have a udelay(1) in the wait loop. I have also moved the udelay to the top of the loop. For the past 12 hours, I have been printing the delay time for the cases where it took more than 2 passes through the loop. There have been single instances of 3 and 4 usec; otherwise the delay is much longer, with the largest delay at 750 usec. The long delays are always found during scanning, associating, and authenticating. I use WPA with wpa_supplicant.
Since adding the dump of IRQ reason, every case that took more than 1 pass through the loop has had an IRQ reason of 0x0580 for every pass in the loop. Your idea about the silly IRQ's seems to be right. I'll let you know if I get any results that are different.
One other little problem. If I do an ifdown/ifup sequence without unloading the bcm43xx module, I get a failure of the assert(bcm->mac_suspended >= 0) at the beginning of bcm43xx_mac_suspend.
Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
