Hi all,
I write to start a discussion about the state of the mwifiex driver.
For over two years many other and me wait that the driver finally
becomes "stable". However, even with kernel 4.14.2 it still fails after
some minutes, or latest after some hours. With various stray errors in
the system log:
Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0: info:
MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p119)
Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0:
driver_version = mwifiex 1.0 (15.68.7.p119)
Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: trying
to associate to 'XXX' bssid xx:xx:xx:xx:xx:xx
Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info:
associated to bssid xx:xx:xx:xx:xx:xx successfully
...
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: Firmware
wakeup failed
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD: FW
in reset state
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD:
card is removed
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
crypto keys
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD:
card is removed
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
crypto keys
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD:
card is removed
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
crypto keys
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD:
card is removed
Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
crypto keys
Also, rmmod usually then hangs, and even if it eventually force unloads
and such re-loading the module does not even get it back into some
working state. Not even with echoing 1 into the pci reset file.
If this firmware and driver is already for years not working very
stable, can this not at least recover more gracefully?
Any suggestions how to finally address and solve these issues are welcome.
If someone needs more logs and debug fluff let me know to generate it as
necessary.
For what it is worth, at least the USB attached mwifi chip in the
Surface 2 appears to work more reliable with the Linux driver.
Best regards,
René Rebe
--
René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
http://exactcode.com | http://t2-project.org | http://rene.rebe.de
Hi Marek,
thank you for your blazingly fast reply.
On 12/05/2017 12:41 PM, Belisko Marek wrote:
> Hi Rene,
>
> On Tue, Dec 5, 2017 at 12:06 PM, René Rebe <[email protected]> wrote:
>> Hi all,
>>
>> I write to start a discussion about the state of the mwifiex driver.
>> For over two years many other and me wait that the driver finally becomes
>> "stable". However, even with kernel 4.14.2 it still fails after some
>> minutes, or latest after some hours. With various stray errors in the system
>> log:
>>
>> Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: MWIFIEX
>> VERSION: mwifiex 1.0 (15.68.7.p119)
>> Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0: driver_version =
>> mwifiex 1.0 (15.68.7.p119)
>>
>> Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: trying to
>> associate to 'XXX' bssid xx:xx:xx:xx:xx:xx
>> Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: associated
>> to bssid xx:xx:xx:xx:xx:xx successfully
>> ...
>> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: Firmware wakeup
>> failed
> As workaround you can disable powersave for wifi (using iw command)
> and test it should resolve an issue (at least it fixes for me).
13:28:18 up 1:52,
Thanks, so far so good. Are you on a Surface, too?
Does this also make mwifiex survive a suspend/resume cycle?
(will try later, when I got work done ;-)
Greetings,
Rene
--
René Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
https://exactcode.com | https://t2sde.org | https://rene.rebe.de
Hi Rene,
On Tue, Dec 5, 2017 at 1:31 PM, Ren=C3=A9 Rebe <[email protected]> wrote:
> Hi Marek,
>
> thank you for your blazingly fast reply.
np.
>
> On 12/05/2017 12:41 PM, Belisko Marek wrote:
>>
>> Hi Rene,
>>
>> On Tue, Dec 5, 2017 at 12:06 PM, Ren=C3=A9 Rebe <[email protected]> wro=
te:
>>>
>>> Hi all,
>>>
>>> I write to start a discussion about the state of the mwifiex driver.
>>> For over two years many other and me wait that the driver finally becom=
es
>>> "stable". However, even with kernel 4.14.2 it still fails after some
>>> minutes, or latest after some hours. With various stray errors in the
>>> system
>>> log:
>>>
>>> Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: MWIFI=
EX
>>> VERSION: mwifiex 1.0 (15.68.7.p119)
>>> Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0:
>>> driver_version =3D
>>> mwifiex 1.0 (15.68.7.p119)
>>>
>>> Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: tryin=
g
>>> to
>>> associate to 'XXX' bssid xx:xx:xx:xx:xx:xx
>>> Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info:
>>> associated
>>> to bssid xx:xx:xx:xx:xx:xx successfully
>>> ...
>>> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: Firmware
>>> wakeup
>>> failed
>>
>> As workaround you can disable powersave for wifi (using iw command)
>> and test it should resolve an issue (at least it fixes for me).
>
>
> 13:28:18 up 1:52,
>
> Thanks, so far so good. Are you on a Surface, too?
> Does this also make mwifiex survive a suspend/resume cycle?
> (will try later, when I got work done ;-)
We was struggling with this issue also and found out that disable
powersave resolve issue (as you have maybe a bit higher consumption).
Glad that it helps ;), enjoy. There are some small fixes to avoid this
issue but my theory is that issue is in marvell firmware and this one
needs to be addressed and fixed.
>
> Greetings,
> Rene
> --
> Ren=C3=A9 Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
> https://exactcode.com | https://t2sde.org | https://rene.rebe.de
BR,
marek
--=20
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
Hi Rene,
On Tue, Dec 5, 2017 at 12:06 PM, Ren=C3=A9 Rebe <[email protected]> wrote:
> Hi all,
>
> I write to start a discussion about the state of the mwifiex driver.
> For over two years many other and me wait that the driver finally becomes
> "stable". However, even with kernel 4.14.2 it still fails after some
> minutes, or latest after some hours. With various stray errors in the sys=
tem
> log:
>
> Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: MWIFIEX
> VERSION: mwifiex 1.0 (15.68.7.p119)
> Dec 5 09:50:50 surface3 kernel: mwifiex_pcie 0000:01:00.0: driver_versio=
n =3D
> mwifiex 1.0 (15.68.7.p119)
>
> Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: trying =
to
> associate to 'XXX' bssid xx:xx:xx:xx:xx:xx
> Dec 5 10:38:28 surface3 kernel: mwifiex_pcie 0000:01:00.0: info: associa=
ted
> to bssid xx:xx:xx:xx:xx:xx successfully
> ...
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: Firmware wake=
up
> failed
As workaround you can disable powersave for wifi (using iw command)
and test it should resolve an issue (at least it fixes for me).
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD: FW =
in
> reset state
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD: car=
d
> is removed
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
> crypto keys
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD: car=
d
> is removed
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
> crypto keys
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD: car=
d
> is removed
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
> crypto keys
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: PREP_CMD: car=
d
> is removed
> Dec 5 10:42:51 surface3 kernel: mwifiex_pcie 0000:01:00.0: deleting the
> crypto keys
>
> Also, rmmod usually then hangs, and even if it eventually force unloads a=
nd
> such re-loading the module does not even get it back into some working
> state. Not even with echoing 1 into the pci reset file.
>
> If this firmware and driver is already for years not working very stable,
> can this not at least recover more gracefully?
>
> Any suggestions how to finally address and solve these issues are welcome=
.
>
> If someone needs more logs and debug fluff let me know to generate it as
> necessary.
>
> For what it is worth, at least the USB attached mwifi chip in the Surface=
2
> appears to work more reliable with the Linux driver.
>
> Best regards,
> Ren=C3=A9 Rebe
>
> --
> Ren=C3=A9 Rebe, ExactCODE GmbH, Lietzenburger Str. 42, DE-10117 Berlin
> http://exactcode.com | http://t2-project.org | http://rene.rebe.de
BR,
marek
--=20
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com