All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
To: linux-wireless@vger.kernel.org,
	"Amitkumar Karwar" <amitkarwar@gmail.com>,
	"Jonas Dreßler" <verdre@v0yd.nl>
Cc: Takashi Iwai <tiwai@suse.de>, Tsuchiya Yuto <kitakar@gmail.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Arnd Bergmann <arnd@arndb.de>, Lee Jones <lee.jones@linaro.org>,
	Kalle Valo <kvalo@codeaurora.org>,
	Xinming Hu <huxinming820@gmail.com>,
	Sharvari Harisangam <sharvari.harisangam@nxp.com>,
	Ganapathi Bhat <ganapathi017@gmail.com>
Subject: Re: mwifiex cmd timeout on one pci variant
Date: Wed, 8 Sep 2021 14:36:14 +0900	[thread overview]
Message-ID: <YThLznrMQ4EYUDEl@atmark-techno.com> (raw)
In-Reply-To: <YTg/f5mHQ6jjHDt6@atmark-techno.com>

(+cc Jonas Dreßler, sorry for two mails in a row for others)

Dominique MARTINET wrote on Wed, Sep 08, 2021 at 01:43:43PM +0900:
> I've got a board with an i.MX8MP chip, and three different marvell W8997
> M.2 modules

(I just noticed Jonas' patches "mwifiex: Work around firmware bugs on
88W8897 chip" on linux-wireless, but it doesn't seem to change anything
for me, so my problem isn't related to pci post or interrupt wake
apparently. Was worth a try...)

I'm surprised though he says the latest firmware is 15.68.19.p21, but I
can't find it anywhere -- linux-firmware only has up to 16.68.1.p179 and
I got 16.68.10.p16 from NXP dependencies, and now I'm searching a bit
harder i also found 16.92.10.p124 !? (note 16.92 instead of 16.68, also
NXP) but I have no idea where to find anything 'official' from marvell
as git.marvell.com/mwifiex-firmware.git disappeared.

Where could I find this version you speak of?


Thanks,

> -- one from laird which works fine, and two from azurewave
> which are labeled exactly the same AW-CM276MA 2276MA PCIE-UART except
> one works and not the other.
> The inscription on the chip itself are slightly different, one saying
> it's a W8997-M1216 from marvell (works) and the other having AW-CM276NF
> azurewave mark. The electronics around are also different.
> 
> I could say it's just a bad chip, but I've actually got two of each
> (samples) which act the same... And I've tried it in another device
> where it works with the same kernel/firmware, so there must be something
> wrong on the board as well as the wifi card works elsewhere.
> 
> 
> Anyway, if someone knows how to get around to debugging this, I'd
> appreciate a pointer! I can't see anything wrong with the tools I have
> here.
> If nothing else, I can't read /sys/class/devcoredump/devcd*/data that I
> saw Amitkumar Karwar request somewhere else, so just deciphering this
> would be great help.
> 
> 
> dmesg looks like this on failure:
> [  108.513028] mwifiex_pcie 0000:01:00.0: mwifiex_cmd_timeout_func: Timeout cmd id = 0x10, act = 0x1
> [  108.522388] mwifiex_pcie 0000:01:00.0: num_data_h2c_failure = 0
> [  108.528310] mwifiex_pcie 0000:01:00.0: num_cmd_h2c_failure = 0
> [  108.534143] mwifiex_pcie 0000:01:00.0: is_cmd_timedout = 1
> [  108.539631] mwifiex_pcie 0000:01:00.0: num_tx_timeout = 0
> [  108.545029] mwifiex_pcie 0000:01:00.0: last_cmd_index = 0
> [  108.550431] mwifiex_pcie 0000:01:00.0: last_cmd_id: 10 00 28 00 16 00 cd 00 1e 00
> [  108.557913] mwifiex_pcie 0000:01:00.0: last_cmd_act: 01 00 13 00 01 00 01 00 00 00
> [  108.565484] mwifiex_pcie 0000:01:00.0: last_cmd_resp_index = 4
> [  108.571318] mwifiex_pcie 0000:01:00.0: last_cmd_resp_id: df 80 28 80 16 80 cd 80 1e 80
> [  108.579237] mwifiex_pcie 0000:01:00.0: last_event_index = 2
> [  108.584810] mwifiex_pcie 0000:01:00.0: last_event: 00 00 0b 00 0a 00 00 00 00 00
> [  108.592206] mwifiex_pcie 0000:01:00.0: data_sent=0 cmd_sent=1
> [  108.597954] mwifiex_pcie 0000:01:00.0: ps_mode=1 ps_state=0
> [  108.604085] mwifiex_pcie 0000:01:00.0: ===mwifiex driverinfo dump start===
> [  108.613552] mwifiex_pcie 0000:01:00.0: info: MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p179) 
> [  108.621748] mwifiex_pcie 0000:01:00.0: PCIE register dump start
> [  108.627676] mwifiex_pcie 0000:01:00.0: pcie scratch register:
> [  108.633441] mwifiex_pcie 0000:01:00.0: reg:0xcf0, value=0xfedcba00
>                reg:0xcf8, value=0x8260049
>                reg:0xcfc, value=0x1282820
> 
> [  108.648584] mwifiex_pcie 0000:01:00.0: PCIE register dump end
> [  108.654411] mwifiex_pcie 0000:01:00.0: ===mwifiex driverinfo dump end===
> [  108.661119] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump start ==
> [  110.560689] mwifiex_pcie 0000:01:00.0: cmd_wait_q terminated: -110
> [  148.127107] mwifiex_pcie 0000:01:00.0: == mwifiex firmware dump end ==
> [  148.134552] mwifiex_pcie 0000:01:00.0: == mwifiex dump information to /sys/class/devcoredump start
> [  148.143669] mwifiex_pcie 0000:01:00.0: == mwifiex dump information to /sys/class/devcoredump end
> [  148.152485] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW is in bad state
> [  148.158915] mwifiex_pcie 0000:01:00.0: info: shutdown mwifiex...
> [  148.165829] mwifiex_pcie 0000:01:00.0: PREP_CMD: card is removed
> [  148.443761] mwifiex_pcie 0000:01:00.0: info: dnld wifi firmware from 169340 bytes
> [  149.511193] mwifiex_pcie 0000:01:00.0: info: FW download over, size 632240 bytes
> [  150.163677] mwifiex_pcie 0000:01:00.0: WLAN FW is active
> [  150.231583] mwifiex_pcie 0000:01:00.0: info: MWIFIEX VERSION: mwifiex 1.0 (16.68.1.p179) 
> [  150.239814] mwifiex_pcie 0000:01:00.0: driver_version = mwifiex 1.0 (16.68.1.p179) 
> 
> I tried with two different firmwares, full dmesg and data.txt are here:
> hang on `ip link set mlan0 up`:
> https://codewreck.org/tmp/16.68.1.p179-data.txt
> https://codewreck.org/tmp/16.68.1.p179-dmesg
> 
> hang on `iw mlan0 scan` after successful link up:
> https://codewreck.org/tmp/16.68.1.p179-2-data.txt
> https://codewreck.org/tmp/16.68.1.p179-2-dmesg
> 
> other firmware (dmesg truncated to just timeout message):
> https://codewreck.org/tmp/16.68.10.p16-data.txt
> https://codewreck.org/tmp/16.68.10.p16-dmesg
> 
> 
> 
> Extra info:
>  - it doesn't always fail at the same place, so this looks like a
> tolerance problem? e.g. sometimes transmission works and sometimes
> a message is garbled?
> 
> - on the working azurewave module I can keep the card maxed at ~300mbps
> in or ~100mbps out without problem for a while with iperf so signals
> can't be that bad...? Or that could just be wishful thinking!
-- 
Dominique Martinet

  reply	other threads:[~2021-09-08  5:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08  4:43 mwifiex cmd timeout on one pci variant Dominique MARTINET
2021-09-08  5:36 ` Dominique MARTINET [this message]
2021-09-08  5:45   ` [EXT] " Sharvari Harisangam
2021-09-08  5:56     ` Dominique MARTINET
2021-09-14 10:11       ` Jonas Dreßler
2021-09-15  1:43         ` Dominique MARTINET
2021-09-15 10:06           ` Jonas Dreßler
2021-09-08 16:56 ` Brian Norris
2021-09-08 23:48   ` Dominique MARTINET

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YThLznrMQ4EYUDEl@atmark-techno.com \
    --to=dominique.martinet@atmark-techno.com \
    --cc=amitkarwar@gmail.com \
    --cc=arnd@arndb.de \
    --cc=ganapathi017@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=huxinming820@gmail.com \
    --cc=kitakar@gmail.com \
    --cc=kvalo@codeaurora.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sharvari.harisangam@nxp.com \
    --cc=tiwai@suse.de \
    --cc=verdre@v0yd.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.