Hi Arend, Thanks for your answers. On Wed, Mar 05, 2014 at 10:04:13AM +0100, Arend van Spriel wrote: > > So I finally found this NVRAM file, hidden somewhere in an EFI variable > > (Thanks for the hint). > > That is actually the first occurrence of EFI I have come across in the > wild, but I mentioned it as I caught up that this was considered for > Win8(.1). Yes, this device came with Win8 installed. > > I have 2 questions for you: > > > > - How can I tell if the target properly loaded this NVRAM file ? Is > > checking for wlan0's MAC to match the NVRAM MAC a good way to verify > > that ? > > Actually, the MAC address in NVRAM should be a backup value. The device > should have a MAC address programmed in OTP on the device itself. The > driver itself reads back the NVRAM to assure it is properly loaded. I'm asking this because when fetching the NVRAM file from UEFI, I eventually noticed the 4 first bytes were garbage. I'm not sure how the target will react to that, so I was looking for a way to verify that the NVRAM was parsed and processed properly on the target side. > > - I'm running this on an Asus T100 (x86 tablet). This is a BCM94324A1 > > over SDIO and I run wireless-next there (With your very latest > > brcmfmac changes). I see the driver is quite unreliable, for example > > scan times out most of the time as the driver puts the target to sleep > > while it's in the middle of receiving partial scan results. I had to > > increase BRCMF_WD_POLL_MS to 100ms to actually get scan results. Then > > the driver seems to be having a hard time joining the couple of WPA > > APs that I tested it against. > > Am I missing something or are those instabilities to be expected with > > the latest brcmfmac code ? Please let me know if you need debug logs, > > I'll happily provide them. > > Great. Please send me a log with module parameter 'debug=0x31416' of the > driver probe sequence. I'm attaching the log corresponding to a modprobe brcmfmac debug=0x31416 && ifconfig wlan0 up sequence. I have modified this in the driver, to make it less aggressive about SDIO sleeps: sdio_host.h: #define BRCMF_WD_POLL_MS 200 dhd_sdio.c: #define BRCMF_IDLE_INTERVAL 20 > I also have 2 question for you ;-) Sorry if I sounded a bit rude, I didn't mean it :-/ > - what mmc host controller is used? So this is sdhci-acpi. > - do you have CONFIG_RUNTIME_PM enabled? CONFIG_PM_RUNTIME is enabled, yes. Do you want me to test with it disabled ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/
Attachment:
brcmfmac-0x31416.gz
Description: Binary data
