On 05/24/2012 11:34 PM, Hauke Mehrtens wrote: > 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 > No solution yet, but maybe another thing to try is b43/bcma with bcm43224 and see if that works. Gr. AvS -- 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
