I have two systems with this device:
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
Flags: bus master, fast devsel, latency 0, IRQ 92
Memory at 90700000 (64-bit, prefetchable) [size=1M]
Memory at 90600000 (64-bit, prefetchable) [size=1M]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [150] Power Budgeting <?>
Capabilities: [160] Latency Tolerance Reporting
Capabilities: [168] L1 PM Substates
Kernel driver in use: mwifiex_pcie
Originally mwifiex_pcie driver from linux-4.7-rc3 fails to initialize
the device with messages:
[ 18.057875] mwifiex_pcie: try set_consistent_dma_mask(32)
[ 18.068694] mwifiex_pcie: PCI memory map Virt0: ffffc90000c00000 PCI memory map Virt2: ffffc90001c00000
[ 18.089754] mwifiex: rx work enabled, cpus 2
[ 18.317941] mwifiex_pcie 0000:02:00.0: PCI-E is not the winner <0x0,0>, exit dnld
[ 18.325531] mwifiex_pcie 0000:02:00.0: WLAN is not the winner! Skip FW dnld
[ 33.460842] mwifiex_pcie 0000:02:00.0: FW failed to be active in time
[ 33.467424] mwifiex_pcie 0000:02:00.0: info: mwifiex_fw_dpc: unregister device
On one system, I modify driver to skip check_winner_status() in
mwifiex_dnld_fw() i.e. force firmware upload to device. On first boot
of that modified kernel, system soft hang - there was very long
or infinite loop on some mwifiex procedure (I fail to get exact
logs from this problem). On second boot, soft hang was gone and
device still fail (with different messages):
[ 8.167830] mwifiex_pcie: try set_consistent_dma_mask(32)
[ 8.174098] mwifiex_pcie: PCI memory map Virt0: ffffc90001c00000 PCI memory map Virt2: ffffc90001e00000
[ 8.195099] mwifiex: rx work enabled, cpus 2
[ 9.595060] mwifiex_pcie 0000:03:00.0: info: FW download over, size 820212 bytes
[ 9.714066] mwifiex_pcie 0000:03:00.0: FW failed to be active in time
[ 9.720598] mwifiex_pcie 0000:03:00.0: info: mwifiex_fw_dpc: unregister device
However now on unmodified kernel on the same system, driver is capable
to initialize the device:
[ 8.751231] mwifiex_pcie: try set_consistent_dma_mask(32)
[ 8.792175] mwifiex_pcie: PCI memory map Virt0: ffffc90001c00000 PCI memory map Virt2: ffffc90001e00000
[ 8.814868] mwifiex: rx work enabled, cpus 2
[ 10.218692] mwifiex_pcie 0000:03:00.0: info: FW download over, size 820212 bytes
[ 10.937332] mwifiex_pcie 0000:03:00.0: WLAN FW is active
[ 11.052624] mwifiex_pcie 0000:03:00.0: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77)
[ 11.060810] mwifiex_pcie 0000:03:00.0: driver_version = mwifiex 1.0 (15.68.7.p77)
[ 11.218702] mwifiex_pcie 0000:03:00.0 wlp3s0: renamed from mlan0
Hence looks like forcing firmware upload somehow changed device, now it
is capable to initialize. On my second system device is on pristine state
and original problem is still reproducible. Do you have good solution
for this problem ?
Thanks
Stanislaw
On Tue, Jun 14, 2016 at 05:12:50PM +0300, Kalle Valo wrote:
> Stanislaw Gruszka <[email protected]> writes:
>
> > Hence looks like forcing firmware upload somehow changed device, now it
> > is capable to initialize. On my second system device is on pristine state
> > and original problem is still reproducible. Do you have good solution
> > for this problem ?
>
> Did you see this:
>
> mwifiex: fix racing condition when downloading firmware
>
> https://patchwork.kernel.org/patch/9123771/
>
> Though I have no idea if it helps in your case, just saw it on my queue
> of patches to apply.
Patch did not help. No wonder since it fixes SDIO and I have problem
with PCIE device :-)
Stanislaw
Stanislaw Gruszka <[email protected]> writes:
> Hence looks like forcing firmware upload somehow changed device, now it
> is capable to initialize. On my second system device is on pristine state
> and original problem is still reproducible. Do you have good solution
> for this problem ?
Did you see this:
mwifiex: fix racing condition when downloading firmware
https://patchwork.kernel.org/patch/9123771/
Though I have no idea if it helps in your case, just saw it on my queue
of patches to apply.
--
Kalle Valo
On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > Could you please share complete dmesg log for failure and successful cases?
>
> Dmesg from failure case is in attachment. I loose access to system
> where device initalize, I'll provide missed dmesg when I get back
> the access.
Have the access now, dmesg is in attachment.
Stanislaw
Hi
On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> Could you please share complete dmesg log for failure and successful cases?
Dmesg from failure case is in attachment. I loose access to system
where device initalize, I'll provide missed dmesg when I get back
the access.
> Probably mwifiex is trying to download the firmware through USB. We had fixed this problem with below patch. Check if it's part of your codebase.
> https://patchwork.kernel.org/patch/7154601/
This patch is applied already on 4.7-rc3 as:
commit 60a188a2715f5cf9f495bd125600453b9e9b1a55
Author: Amitkumar Karwar <[email protected]>
Date: Thu Sep 10 07:27:33 2015 -0700
mwifiex: remove USB8897 chipset support
Thanks
Stanislaw
Hi Stanislaw,
> From: Stanislaw Gruszka [mailto:[email protected]]
> Sent: Tuesday, June 14, 2016 7:20 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; [email protected]
> Subject: Problems with mwifiex_pcie firmware activation
>
> I have two systems with this device:
>
> 03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
> 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
> Flags: bus master, fast devsel, latency 0, IRQ 92
> Memory at 90700000 (64-bit, prefetchable) [size=1M]
> Memory at 90600000 (64-bit, prefetchable) [size=1M]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 00-00-00-00-00-00-00-00
> Capabilities: [150] Power Budgeting <?>
> Capabilities: [160] Latency Tolerance Reporting
> Capabilities: [168] L1 PM Substates
> Kernel driver in use: mwifiex_pcie
>
> Originally mwifiex_pcie driver from linux-4.7-rc3 fails to initialize
> the device with messages:
>
> [ 18.057875] mwifiex_pcie: try set_consistent_dma_mask(32)
> [ 18.068694] mwifiex_pcie: PCI memory map Virt0: ffffc90000c00000 PCI
> memory map Virt2: ffffc90001c00000
> [ 18.089754] mwifiex: rx work enabled, cpus 2
> [ 18.317941] mwifiex_pcie 0000:02:00.0: PCI-E is not the winner
> <0x0,0>, exit dnld
> [ 18.325531] mwifiex_pcie 0000:02:00.0: WLAN is not the winner! Skip
> FW dnld
> [ 33.460842] mwifiex_pcie 0000:02:00.0: FW failed to be active in time
> [ 33.467424] mwifiex_pcie 0000:02:00.0: info: mwifiex_fw_dpc:
> unregister device
>
> On one system, I modify driver to skip check_winner_status() in
> mwifiex_dnld_fw() i.e. force firmware upload to device. On first boot of
> that modified kernel, system soft hang - there was very long or infinite
> loop on some mwifiex procedure (I fail to get exact logs from this
> problem). On second boot, soft hang was gone and device still fail (with
> different messages):
>
> [ 8.167830] mwifiex_pcie: try set_consistent_dma_mask(32)
> [ 8.174098] mwifiex_pcie: PCI memory map Virt0: ffffc90001c00000 PCI
> memory map Virt2: ffffc90001e00000
> [ 8.195099] mwifiex: rx work enabled, cpus 2
> [ 9.595060] mwifiex_pcie 0000:03:00.0: info: FW download over, size
> 820212 bytes
> [ 9.714066] mwifiex_pcie 0000:03:00.0: FW failed to be active in time
> [ 9.720598] mwifiex_pcie 0000:03:00.0: info: mwifiex_fw_dpc:
> unregister device
>
> However now on unmodified kernel on the same system, driver is capable
> to initialize the device:
>
> [ 8.751231] mwifiex_pcie: try set_consistent_dma_mask(32)
> [ 8.792175] mwifiex_pcie: PCI memory map Virt0: ffffc90001c00000 PCI
> memory map Virt2: ffffc90001e00000
> [ 8.814868] mwifiex: rx work enabled, cpus 2
> [ 10.218692] mwifiex_pcie 0000:03:00.0: info: FW download over, size
> 820212 bytes
> [ 10.937332] mwifiex_pcie 0000:03:00.0: WLAN FW is active
> [ 11.052624] mwifiex_pcie 0000:03:00.0: info: MWIFIEX VERSION: mwifiex
> 1.0 (15.68.7.p77)
> [ 11.060810] mwifiex_pcie 0000:03:00.0: driver_version = mwifiex 1.0
> (15.68.7.p77)
> [ 11.218702] mwifiex_pcie 0000:03:00.0 wlp3s0: renamed from mlan0
>
> Hence looks like forcing firmware upload somehow changed device, now it
> is capable to initialize. On my second system device is on pristine
> state and original problem is still reproducible. Do you have good
> solution for this problem ?
>
Could you please share complete dmesg log for failure and successful cases?
Probably mwifiex is trying to download the firmware through USB. We had fixed this problem with below patch. Check if it's part of your codebase.
https://patchwork.kernel.org/patch/7154601/
Regards,
Amitkumar
Hi Stanislaw,
> From: Stanislaw Gruszka [mailto:[email protected]]
> Sent: Thursday, August 11, 2016 5:59 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; [email protected]
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> Hi
>
> On Thu, Aug 11, 2016 at 10:21:58AM +0000, Amitkumar Karwar wrote:
> > > -----Original Message-----
> > > From: Stanislaw Gruszka [mailto:[email protected]]
> > > Sent: Thursday, August 11, 2016 2:31 PM
> > > To: Amitkumar Karwar
> > > Cc: Nishant Sarmukadam; [email protected]
> > > Subject: Re: Problems with mwifiex_pcie firmware activation
> > >
> > > On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> > > > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > > > > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar
> wrote:
> > > > > > Could you please share complete dmesg log for failure and
> > > successful cases?
> > > > >
> > > > > Dmesg from failure case is in attachment. I loose access to
> > > > > system where device initalize, I'll provide missed dmesg when I
> > > > > get back the access.
> > > >
> > > > Have the access now, dmesg is in attachment.
> > >
> > > Any news here ?
> >
> > Do you have below patch included? It increases poll count which may
> help in your case.
> > https://patchwork.kernel.org/patch/7973951/
>
> Yes, I have that patch.
>
> To clarify the issue: reverting above patch seems to helps with the
> problem. That what I basically did on first of my systems with mwifiex,
> that did not work similarly like second one. However I did not revert
> the patch but just comment out check_winner_status:
>
> @@ -755,7 +755,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
> }
>
> /* check if we are the winner for downloading FW */
> - if (adapter->if_ops.check_winner_status) {
> + if (false) {
> adapter->winner = 0;
> ret = adapter->if_ops.check_winner_status(adapter);
>
> After running modified kernel once, the problem was gone on unmodified
> kernel! I suppose that once new firmware was uploaded to the device it
> somehow modify it (change it's internal firmware?) and make
> check_winner_status() works correctly. This is strange, but I can not
> find any other explanation and don't see any other changes in the first
> system that makes mwifiex suddenly work.
>
> I could be wrong, but I suppose somebody who use pre 4.6 kernel (without
> the above patch committed as: 2fd5c6ed0b4fbf3c2d9314a24c82862ce5254d42
> "mwifiex: firmware download enhancements") with new enough mwifiex
> firmware, will not see the problem even after kernel update. But if
> somebody install 4.6 or newer kernel on pristine hardware, the device
> will not work.
>
The problem looks strange. The patch just splits mwifiex_check_fw_status() and increases poll count. It should not have any side-effects.
Our code used to check winner status before this patch also.
Regards,
Amitkumar Karwar
On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > > Could you please share complete dmesg log for failure and successful cases?
> >
> > Dmesg from failure case is in attachment. I loose access to system
> > where device initalize, I'll provide missed dmesg when I get back
> > the access.
>
> Have the access now, dmesg is in attachment.
Any news here ?
Stanislaw
Hi Stanislaw,
> -----Original Message-----
> From: Stanislaw Gruszka [mailto:[email protected]]
> Sent: Thursday, August 11, 2016 2:31 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; [email protected]
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > > > Could you please share complete dmesg log for failure and
> successful cases?
> > >
> > > Dmesg from failure case is in attachment. I loose access to system
> > > where device initalize, I'll provide missed dmesg when I get back
> > > the access.
> >
> > Have the access now, dmesg is in attachment.
>
> Any news here ?
Do you have below patch included? It increases poll count which may help in your case.
https://patchwork.kernel.org/patch/7973951/
Regards,
Amitkumar
On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > The problem looks strange. The patch just splits mwifiex_check_fw_status() and increases poll count. It should not have any side-effects.
> > Our code used to check winner status before this patch also.
>
> Ok, I misread the patch. Anyway checking "winner status" seems
> does not work well on some condition and prevent loading firmware
> into device.
I debug this a bit more on latest wireless-testing-next tree + 3 patches
I just posted and debug_mask=0x700000ff.
On broken system, we do not download FW to device when system is
rebooted, due to PCI-E is not the winner. However if system is
powered OFF and then powered ON, we do FW downloading. Hence
download the new FW into device does not make it work as was
my theory.
In attachments are full dmesgs of good/bad and reboot/power-off-on
cases.
The difference is that on broken system FW (or HW) do not create
new USB Bluetooth device (1286:2046) and do not report
FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
from USB xhci.
GOOD system after reboot:
[ 11.899924] mwifiex_pcie: try set_consistent_dma_mask(32)
[ 11.937024] mwifiex_pcie: PCI memory map Virt0: ffffc90001000000 PCI memory map Virt2: ffffc90001400000
[ 11.948256] mwifiex: rx work enabled, cpus 2
[ 11.954821] snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 11.977205] mwifiex_pcie 0000:03:00.0: msi_enable = 1
[ 12.001881] mwifiex_pcie 0000:03:00.0: Setting driver ready signature
[ 12.008456] mwifiex_pcie 0000:03:00.0: Try 0 if FW is ready <0,0x0>
[ 12.051216] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input7
[ 12.069136] Adding 6254588k swap on /dev/mapper/rhel_iot--r5s3--01-swap. Priority:-1 extents:1 across:6254588k SSFS
[ 12.081133] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8
[ 12.111533] mwifiex_pcie 0000:03:00.0: PCI-E is the winner
[ 12.111537] mwifiex_pcie 0000:03:00.0: info: Downloading FW image (803884 bytes)
[ 13.347194] mwifiex_pcie 0000:03:00.0: info: FW download over, size 803884 bytes
[ 13.347200] mwifiex_pcie 0000:03:00.0: Setting driver ready signature
[ 13.347205] mwifiex_pcie 0000:03:00.0: Try 0 if FW is ready <0,0x6>
[ 13.397597] intel_rapl: Found RAPL domain package
[ 13.397600] intel_rapl: Found RAPL domain core
[ 13.456221] mwifiex_pcie 0000:03:00.0: Try 1 if FW is ready <0,0x6>
[ 13.560263] mwifiex_pcie 0000:03:00.0: Try 2 if FW is ready <0,0x6>
[ 13.607377] usb 1-4.2: USB disconnect, device number 3
[ 13.664199] mwifiex_pcie 0000:03:00.0: Try 3 if FW is ready <0,0x6>
[ 13.768563] mwifiex_pcie 0000:03:00.0: Try 4 if FW is ready <0,0x6>
[ 13.795585] usb 1-4.2: new high-speed USB device number 4 using xhci_hcd
[ 13.872962] mwifiex_pcie 0000:03:00.0: Try 5 if FW is ready <0,0x6>
[ 13.892350] usb 1-4.2: New USB device found, idVendor=1286, idProduct=2046
[ 13.900302] usb 1-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 13.900304] usb 1-4.2: Product: Bluetooth and Wireless LAN Composite Device
[ 13.900307] usb 1-4.2: Manufacturer: Marvell
[ 13.900309] usb 1-4.2: SerialNumber: 0000000000000000
[ 13.908594] XFS (dm-2): Mounting V5 Filesystem
[ 13.944449] XFS (dm-2): Ending clean mount
[ 13.984292] mwifiex_pcie 0000:03:00.0: Try 6 if FW is ready <0,0x6>
[ 14.121836] mwifiex_pcie 0000:03:00.0: Try 7 if FW is ready <0,0xfedcba00>
[ 14.128771] mwifiex_pcie 0000:03:00.0: WLAN FW is active
BAD system after reboot:
[ 14.588111] mwifiex_pcie: try set_consistent_dma_mask(32)
[ 14.588155] mwifiex_pcie: PCI memory map Virt0: ffffc90000800000 PCI memory map Virt2: ffffc90000a00000
[ 14.588227] mwifiex: rx work enabled, cpus 2
[ 14.591260] mwifiex_pcie 0000:02:00.0: msi_enable = 1
[ 14.602408] mwifiex_pcie 0000:02:00.0: Setting driver ready signature
[ 14.602416] mwifiex_pcie 0000:02:00.0: Try 0 if FW is ready <0,0x6>
[ 14.707156] mwifiex_pcie 0000:02:00.0: PCI-E is not the winner <0x6>
[ 14.707164] mwifiex_pcie 0000:02:00.0: WLAN is not the winner! Skip FW dnld
[ 14.707171] mwifiex_pcie 0000:02:00.0: Setting driver ready signature
[ 14.707186] mwifiex_pcie 0000:02:00.0: Try 0 if FW is ready <0,0x6>
[ 14.810726] mwifiex_pcie 0000:02:00.0: Try 1 if FW is ready <0,0x6>
<snip>
[ 25.550002] mwifiex_pcie 0000:02:00.0: Try 97 if FW is ready <0,0x6>
[ 25.662032] mwifiex_pcie 0000:02:00.0: Try 98 if FW is ready <0,0x6>
[ 25.667083] usb 1-4.2: device descriptor read/64, error -110
[ 25.782069] mwifiex_pcie 0000:02:00.0: Try 99 if FW is ready <0,0x6>
[ 25.850076] usb 1-4.2: new high-speed USB device number 4 using xhci_hcd
[ 25.894091] mwifiex_pcie 0000:02:00.0: Try 100 if FW is ready <0,0x6>
[ 26.006123] mwifiex_pcie 0000:02:00.0: Try 101 if FW is ready <0,0x6>
<snip>
[ 31.167060] mwifiex_pcie 0000:02:00.0: Try 147 if FW is ready <0,0x6>
[ 31.279149] mwifiex_pcie 0000:02:00.0: Try 148 if FW is ready <0,0x6>
[ 31.299139] usb 1-4.2: device descriptor read/64, error -110
[ 31.391128] mwifiex_pcie 0000:02:00.0: Try 149 if FW is ready <0,0x6>
[ 31.503180] mwifiex_pcie 0000:02:00.0: FW failed to be active in time
[ 31.509766] mwifiex_pcie 0000:02:00.0: info: mwifiex_fw_dpc: unregister device
[ 31.517118] mwifiex_pcie 0000:02:00.0: mwifiex_unregister_dev(): calling free_irq()
[ 34.555397] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 34.721265] Ebtables v2.0 registered
[ 35.180409] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[ 35.258839] tun: Universal TUN/TAP device driver, 1.6
[ 35.263968] tun: (C) 1999-2004 Max Krasnyansky <[email protected]>
[ 35.317893] virbr0: port 1(virbr0-nic) entered blocking state
[ 35.323733] virbr0: port 1(virbr0-nic) entered disabled state
[ 35.330484] device virbr0-nic entered promiscuous mode
[ 35.731136] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 36.274961] virbr0: port 1(virbr0-nic) entered blocking state
[ 36.280795] virbr0: port 1(virbr0-nic) entered listening state
[ 36.425084] virbr0: port 1(virbr0-nic) entered disabled state
[ 36.467694] device virbr0-nic left promiscuous mode
[ 36.472708] virbr0: port 1(virbr0-nic) entered disabled state
[ 47.550858] usb 1-4.2: device descriptor read/64, error -110
[ 47.734888] usb 1-4.2: new high-speed USB device number 5 using xhci_hcd
[ 53.108292] xhci_hcd 0000:00:14.0: Command completion event does not match command
[ 53.116708] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 58.741871] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 58.957883] usb 1-4.2: device not accepting address 5, error -62
[ 59.039904] usb 1-4.2: new high-speed USB device number 6 using xhci_hcd
[ 64.375277] xhci_hcd 0000:00:14.0: Command completion event does not match command
[ 64.383018] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 70.008837] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 70.224865] usb 1-4.2: device not accepting address 6, error -62
[ 70.231111] usb 1-4-port2: unable to enumerate USB device
On both systems mwifiex seems to be the same device, but the systems
itself are not identical. This could be a BIOS or motherboard issue.
However mwifiex didn't work on good system as well before and start
to work somehow, I'm not sure how this happened.
Thanks
Stanislaw
Hi
On Thu, Aug 11, 2016 at 10:21:58AM +0000, Amitkumar Karwar wrote:
> > -----Original Message-----
> > From: Stanislaw Gruszka [mailto:[email protected]]
> > Sent: Thursday, August 11, 2016 2:31 PM
> > To: Amitkumar Karwar
> > Cc: Nishant Sarmukadam; [email protected]
> > Subject: Re: Problems with mwifiex_pcie firmware activation
> >
> > On Thu, Jun 23, 2016 at 02:09:52PM +0200, Stanislaw Gruszka wrote:
> > > On Thu, Jun 16, 2016 at 01:53:15PM +0200, Stanislaw Gruszka wrote:
> > > > On Wed, Jun 15, 2016 at 01:47:53PM +0000, Amitkumar Karwar wrote:
> > > > > Could you please share complete dmesg log for failure and
> > successful cases?
> > > >
> > > > Dmesg from failure case is in attachment. I loose access to system
> > > > where device initalize, I'll provide missed dmesg when I get back
> > > > the access.
> > >
> > > Have the access now, dmesg is in attachment.
> >
> > Any news here ?
>
> Do you have below patch included? It increases poll count which may help in your case.
> https://patchwork.kernel.org/patch/7973951/
Yes, I have that patch.
To clarify the issue: reverting above patch seems to helps with the
problem. That what I basically did on first of my systems with mwifiex,
that did not work similarly like second one. However I did not revert
the patch but just comment out check_winner_status:
@@ -755,7 +755,7 @@ int mwifiex_dnld_fw(struct mwifiex_adapter *adapter,
}
/* check if we are the winner for downloading FW */
- if (adapter->if_ops.check_winner_status) {
+ if (false) {
adapter->winner = 0;
ret = adapter->if_ops.check_winner_status(adapter);
After running modified kernel once, the problem was gone on
unmodified kernel! I suppose that once new firmware was uploaded to
the device it somehow modify it (change it's internal firmware?) and make
check_winner_status() works correctly. This is strange, but I can not
find any other explanation and don't see any other changes in the
first system that makes mwifiex suddenly work.
I could be wrong, but I suppose somebody who use pre 4.6 kernel (without
the above patch committed as: 2fd5c6ed0b4fbf3c2d9314a24c82862ce5254d42
"mwifiex: firmware download enhancements") with new enough mwifiex
firmware, will not see the problem even after kernel update. But if
somebody install 4.6 or newer kernel on pristine hardware, the device
will not work.
Thanks
Stanislaw
On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> The problem looks strange. The patch just splits mwifiex_check_fw_status() and increases poll count. It should not have any side-effects.
> Our code used to check winner status before this patch also.
Ok, I misread the patch. Anyway checking "winner status" seems
does not work well on some condition and prevent loading firmware
into device.
Stanislaw
Hi
On Wed, Nov 16, 2016 at 06:03:49AM +0000, Amitkumar Karwar wrote:
> > From: Stanislaw Gruszka [mailto:[email protected]]
> > Sent: Monday, November 14, 2016 3:46 PM
> > To: Amitkumar Karwar
> > Cc: Nishant Sarmukadam; [email protected]
> > Subject: Re: Problems with mwifiex_pcie firmware activation
> >
> > On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> > > On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > > > On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > > > > The problem looks strange. The patch just splits
> > mwifiex_check_fw_status() and increases poll count. It should not have
> > any side-effects.
> > > > > Our code used to check winner status before this patch also.
> > > >
> > > > Ok, I misread the patch. Anyway checking "winner status" seems does
> > > > not work well on some condition and prevent loading firmware into
> > > > device.
> > >
> > > I debug this a bit more on latest wireless-testing-next tree + 3
> > > patches I just posted and debug_mask=0x700000ff.
> > >
> > > On broken system, we do not download FW to device when system is
> > > rebooted, due to PCI-E is not the winner. However if system is
> > powered
> > > OFF and then powered ON, we do FW downloading. Hence download the new
> > > FW into device does not make it work as was my theory.
> > >
> > > In attachments are full dmesgs of good/bad and reboot/power-off-on
> > > cases.
> > >
> > > The difference is that on broken system FW (or HW) do not create new
> > > USB Bluetooth device (1286:2046) and do not report
> > > FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> > from
> > > USB xhci.
> >
> > It was discovered that not working device require pcie8897_uapsta.bin
> > firmware from ubuntu package to work:
>
> What's the difference between working and non-working device?
I can not find anything reasonable. Lspci gives almost the same print.
There is some difference, but I think it comes from from fact that
working device is enabled and non-working is disabled.
Working:
03:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 266
Region 0: Memory at 90700000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at 90600000 (64-bit, prefetchable) [size=1M]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/32 Maskable+ 64bit+
Address: 00000000fee0200c Data: 4172
Masking: fffffffe Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Latency Tolerance Reporting
Max snoop latency: 71680ns
Max no snoop latency: 71680ns
Capabilities: [168 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=70us PortTPowerOnTime=10us
Kernel driver in use: mwifiex_pcie
Kernel modules: mwifiex_pcie
Non-working:
02:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd. 88W8897 [AVASTAR] 802.11ac Wireless [11ab:2b38]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 18
Region 0: Memory at 90700000 (64-bit, prefetchable) [size=1M]
Region 2: Memory at 90600000 (64-bit, prefetchable) [size=1M]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <1us, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [150 v1] Power Budgeting <?>
Capabilities: [160 v1] Latency Tolerance Reporting
Max snoop latency: 71680ns
Max no snoop latency: 71680ns
Capabilities: [168 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=70us PortTPowerOnTime=10us
Kernel driver in use: mwifiex_pcie
Kernel modules: mwifiex_pcie
I also added some extra code to print registers that are used to identify
other PCIE_DEVICE_ID_MARVELL_88W8997 device:
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 3c3c4f1..84434ab 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2921,6 +2921,9 @@ static void mwifiex_pcie_get_fw_name(struct
mwifiex_adapter *adapter)
case PCIE_DEVICE_ID_MARVELL_88W8897:
mwifiex_write_reg(adapter, 0x0c58, 0x80c00000);
mwifiex_read_reg(adapter, 0x0c58, &revision_id);
+ mwifiex_read_reg(adapter, 0x0cd0, &version);
+ mwifiex_read_reg(adapter, 0x0cd4, &magic);
+ printk("%s revision_id 0x%08x version 0x%08x magic 0x%08x\n", __func__, revision_id, version, magic);
revision_id &= 0xff00;
switch (revision_id) {
case PCIE8897_A0:
but prints are the same for non-working and working system:
mwifiex_pcie_get_fw_name revision_id 0x00001430 version 0x00000000 magic 0x00000000
So I'm not sure if device in working and non-working system is different.
Maybe difference is in how device is connected with the rest of the system
or in other hardware parts. Cc Charles, perhaps he can elaborate more about
that.
> > https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-
> > devices/+sourcepub/5936055/+listing-archive-extra
> >
> > Device initialize like this then:
> >
> > [ 15.374630] mwifiex_pcie 0000:02:00.0: info: FW download over, size
> > 689624 bytes
> > [ 16.101214] mwifiex_pcie 0000:02:00.0: WLAN FW is active
> > [ 16.242825] mwifiex_pcie 0000:02:00.0: info: MWIFIEX VERSION:
> > mwifiex 1.0 (15.150.13.p21)
> > [ 16.251231] mwifiex_pcie 0000:02:00.0: driver_version = mwifiex 1.0
> > (15.150.13.p21)
> >
> > I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
> > it seems it's not present nor in upstream linux-firmware repo not in
> > http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
> >
> > Anyway could you modify firmware to support this device or modify
> > driver to load 15.150.13.p21 if required and push this F/W image
> > upstream ?
> >
>
> Last released firmware is 15.68.7.p77
> http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=05e2f3a4acf4174ec507a3464a374ecb1b4ec011
> Could you try with it?
I does not make device on non-workig system work.
> If it doesn't work, we need to investigate what is missing in this compared to 15.150.13.p21 and create new 15.68.7.pXX.
Thanks
Stanislaw
On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > > The problem looks strange. The patch just splits mwifiex_check_fw_status() and increases poll count. It should not have any side-effects.
> > > Our code used to check winner status before this patch also.
> >
> > Ok, I misread the patch. Anyway checking "winner status" seems
> > does not work well on some condition and prevent loading firmware
> > into device.
>
> I debug this a bit more on latest wireless-testing-next tree + 3 patches
> I just posted and debug_mask=0x700000ff.
>
> On broken system, we do not download FW to device when system is
> rebooted, due to PCI-E is not the winner. However if system is
> powered OFF and then powered ON, we do FW downloading. Hence
> download the new FW into device does not make it work as was
> my theory.
>
> In attachments are full dmesgs of good/bad and reboot/power-off-on
> cases.
>
> The difference is that on broken system FW (or HW) do not create
> new USB Bluetooth device (1286:2046) and do not report
> FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> from USB xhci.
It was discovered that not working device require pcie8897_uapsta.bin
firmware from ubuntu package to work:
https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-devices/+sourcepub/5936055/+listing-archive-extra
Device initialize like this then:
[ 15.374630] mwifiex_pcie 0000:02:00.0: info: FW download over, size 689624 bytes
[ 16.101214] mwifiex_pcie 0000:02:00.0: WLAN FW is active
[ 16.242825] mwifiex_pcie 0000:02:00.0: info: MWIFIEX VERSION: mwifiex 1.0 (15.150.13.p21)
[ 16.251231] mwifiex_pcie 0000:02:00.0: driver_version = mwifiex 1.0 (15.150.13.p21)
I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
it seems it's not present nor in upstream linux-firmware repo not in
http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
Anyway could you modify firmware to support this device or modify
driver to load 15.150.13.p21 if required and push this F/W image
upstream ?
Thanks
Stanislaw
Hi Stanislaw,
> From: Stanislaw Gruszka [mailto:[email protected]]
> Sent: Monday, November 14, 2016 3:46 PM
> To: Amitkumar Karwar
> Cc: Nishant Sarmukadam; [email protected]
> Subject: Re: Problems with mwifiex_pcie firmware activation
>
> On Thu, Aug 25, 2016 at 05:06:26PM +0200, Stanislaw Gruszka wrote:
> > On Fri, Aug 12, 2016 at 10:13:43AM +0200, Stanislaw Gruszka wrote:
> > > On Fri, Aug 12, 2016 at 07:17:38AM +0000, Amitkumar Karwar wrote:
> > > > The problem looks strange. The patch just splits
> mwifiex_check_fw_status() and increases poll count. It should not have
> any side-effects.
> > > > Our code used to check winner status before this patch also.
> > >
> > > Ok, I misread the patch. Anyway checking "winner status" seems does
> > > not work well on some condition and prevent loading firmware into
> > > device.
> >
> > I debug this a bit more on latest wireless-testing-next tree + 3
> > patches I just posted and debug_mask=0x700000ff.
> >
> > On broken system, we do not download FW to device when system is
> > rebooted, due to PCI-E is not the winner. However if system is
> powered
> > OFF and then powered ON, we do FW downloading. Hence download the new
> > FW into device does not make it work as was my theory.
> >
> > In attachments are full dmesgs of good/bad and reboot/power-off-on
> > cases.
> >
> > The difference is that on broken system FW (or HW) do not create new
> > USB Bluetooth device (1286:2046) and do not report
> > FIRMWARE_READY_PCIE. Additionally on reboot case there are errors
> from
> > USB xhci.
>
> It was discovered that not working device require pcie8897_uapsta.bin
> firmware from ubuntu package to work:
What's the difference between working and non-working device?
> https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-
> devices/+sourcepub/5936055/+listing-archive-extra
>
> Device initialize like this then:
>
> [ 15.374630] mwifiex_pcie 0000:02:00.0: info: FW download over, size
> 689624 bytes
> [ 16.101214] mwifiex_pcie 0000:02:00.0: WLAN FW is active
> [ 16.242825] mwifiex_pcie 0000:02:00.0: info: MWIFIEX VERSION:
> mwifiex 1.0 (15.150.13.p21)
> [ 16.251231] mwifiex_pcie 0000:02:00.0: driver_version = mwifiex 1.0
> (15.150.13.p21)
>
> I'm not sure where ubuntu get this 15.150.13.p21 version of firmware as
> it seems it's not present nor in upstream linux-firmware repo not in
> http://git.marvell.com/?p=mwifiex-firmware.git;a=summary
>
> Anyway could you modify firmware to support this device or modify
> driver to load 15.150.13.p21 if required and push this F/W image
> upstream ?
>
Last released firmware is 15.68.7.p77
http://git.marvell.com/?p=mwifiex-firmware.git;a=commit;h=05e2f3a4acf4174ec507a3464a374ecb1b4ec011
Could you try with it?
If it doesn't work, we need to investigate what is missing in this compared to 15.150.13.p21 and create new 15.68.7.pXX.
Regards,
Amitkumar