On 05/24/2012 11:21 PM, Seth Forshee wrote: > On Thu, May 24, 2012 at 11:36:16AM +0200, Arend van Spriel wrote: >> On 05/23/2012 03:55 PM, Seth Forshee wrote: >>> On Wed, May 23, 2012 at 11:30:38AM +0200, Arend van Spriel wrote: >>>> On 05/22/2012 06:52 PM, Seth Forshee wrote: >>>>> Hi Arend, >>>>> >>>>> I've inquired about this issue on the list once before, but I thought >>>>> I'd try once again to see if Broadcom can offer any suggestions. >>>>> >>>>> Recent MacBook Pros with BCM4331 wireless have a strange problem. Tx >>>>> doesn't work after S3, but only if no external power is applied during >>>>> the resume. mac80211 reports mostly timeouts for responses to probe >>>>> requests, but analysis with wireshark shows no frames from the BCM4331 >>>>> on the air. The only way I've found to recover is to reload both b43 and >>>>> bcma; reloading b43 alone is not enough. >>>> >>>> Yikes. I recently did suspend/resume and hibernate testing with BCM43224 >>>> (so brcmsmac and bcma), but my system was on AC. I will execute them >>>> again on battery. I want to make sure it is not a BCM4331 specific issue. >>> >>> I'm also testing a Macbook Air with BCM43224 using brcmsmac, and it does >>> not suffer from the same issue. >> >> Good to know. I will check whether there are any known issues with >> BCM4331 that could explain this. >> >>>>> I've checked the values of MACCTL and the DMA TXCTL registers, since >>>>> these are the ones used by brcmsmac to mute tx, but those look okay. Any >>>>> suggestions of other things to check? My next step would be to start >>>>> looking at the state of the phy and radio, but since we don't have much >>>>> information about what the registers there actually do some suggestions >>>>> would be helpful. >>>> >>>> When going to S3 the driver is told by mac80211 .stop callback to abort >>>> driver operation so I do not expect b43 has a problem. Instead we >>>> probably have to look at the host PCI code in bcma, but before going >>>> there let me execute my tests. >>>> >>>> Can you tell me on what kernel version you see this issue. I would also >>>> like to have a look at your kernel log. >>> >>> I'm still seeing it in both 3.4 and wireless-testing. Attached is dmesg >>> from wireless-testing. >> >> Nothing really looks wrong in there, but then again there are not much >> b43/bcma related messages. > > I don't know if this helps, but I can do a successful passive scan when > tx isn't working. So it seems rx still works, only tx is broken. I also > forgot to state explicitly that it only matters that AC power isn't > present during the resume; i.e. I can suspend with AC connected, remove > AC, then resume, and I will still get tx failures. > > I've been going through the suspend/resume paths for bcma and pci, and I > can't find anything that would account for differing behavior depending > on whether or not AC power is present. Even the ACPI _PS* methods for > the device appear to be (effectively) no-ops. > > The only other thing that comes to mind that might be disabling tx is > firmware, either system firmware or the BCM4331's firmware. Perhaps > there's something that bcma or b43 is not initializing that's usually in > the needed state? That's mostly just a guess, but I'm at a loss for > other explanations at this point. > > Cheers, > Seth > Hi Seth, rmmod and insmod of b43 does not help but doing this with b43 and bcma works is that correct? Have you tried to add this code from bcma_host_pci_probe() to resume: /* Disable the RETRY_TIMEOUT register (0x41) to keep * PCI Tx retries from interfering with C3 CPU state */ pci_read_config_dword(dev, 0x40, &val); if ((val & 0x0000ff00) != 0) pci_write_config_dword(dev, 0x40, val & 0xffff00ff); Could you also try to run bcma_sprom_get() after resume. And if that did not help run bcma_bus_scan() and remove the parts which are chaining anything to struct bcma_bus. If that all does not help or you already tried that, hopefully Arend has a solution. Hauke -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
