From: Brian Norris <briannorris@chromium.org>
To: linux-mmc@vger.kernel.org, linux-rockchip@lists.infradead.org
Cc: Heiko Stuebner <heiko@sntech.de>,
amstan@chromium.org, Ziyuan Xu <xzy.xu@rock-chips.com>,
Shawn Lin <shawn.lin@rock-chips.com>,
Jaehoon Chung <jh80.chung@samsung.com>
Subject: [REGRESSION 4.10] dw_mmc: failures on Rockchip rk3288 veyron boards
Date: Wed, 29 Mar 2017 18:17:10 -0700 [thread overview]
Message-ID: <20170330011709.GA110687@google.com> (raw)
Hi all,
I haven't managed to get as far as a bugfix for this, but I've bisected
some issues seen on v4.10+ with a Chromebook of the Veyron family (Jaq,
in particular). v4.9 works fine.
Issue #1 - eMMC complains periodically:
[ 4.358135] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 4.461466] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 5.291450] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 5.381471] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 11.243337] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 17.371628] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
and if I stress it out at all (e.g., dd if=/dev/mmcblk2 bs=1M >
/dev/null), it will eventually croak:
[ 359.916315] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 360.071378] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 153
[ 360.211351] mmcblk2: error -110 transferring data, sector 8644608, nr 2048, cmd response 0x900, card status 0x0
[ 360.221936] mmcblk2: retrying using single block read
[ 363.491362] mmcblk2: error -110 transferring data, sector 8646656, nr 2048, cmd response 0x900, card status 0x0
[ 363.531569] mmc_host mmc2: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 363.596326] mmc_host mmc2: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 363.612712] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 152
[ 363.751351] mmcblk2: error -110 transferring data, sector 8646656, nr 2048, cmd response 0x900, card status 0x0
[ 363.761938] mmcblk2: retrying using single block read
[ 366.611356] INFO: task mmcqd/2boot1:92 blocked for more than 120 seconds.
[ 366.618134] Not tainted 4.10.0 #284
[ 366.622146] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 366.629960] mmcqd/2boot1 D 0 92 2 0x00000000
[ 366.635454] [<c07dc21c>] (__schedule) from [<c07dc4e0>] (schedule+0x90/0xa0)
[ 366.642497] [<c07dc4e0>] (schedule) from [<c066e8b4>] (__mmc_claim_host+0xd4/0x19c)
[ 366.650142] [<c066e8b4>] (__mmc_claim_host) from [<c066e9ac>] (mmc_get_card+0x30/0x34)
[ 366.658056] [<c066e9ac>] (mmc_get_card) from [<c067fc8c>] (mmc_blk_issue_rq+0x64/0x48c)
[ 366.666052] [<c067fc8c>] (mmc_blk_issue_rq) from [<c0680230>] (mmc_queue_thread+0x114/0x1b4)
[ 366.674484] [<c0680230>] (mmc_queue_thread) from [<c023d1b0>] (kthread+0x128/0x144)
[ 366.682134] [<c023d1b0>] (kthread) from [<c02076e8>] (ret_from_fork+0x14/0x2c)
...
Issue #2 - Wifi (via SDIO, mmc1) is completely dead:
[ 1.444125] mmc_host mmc1: card is non-removable.
[ 1.471368] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[ 1.619553] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 1.881699] mmc1: new ultra high speed SDR104 SDIO card at address 0001
[ 25.681172] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 25.691666] mwifiex: rx work enabled, cpus 4
[ 26.827000] mwifiex_sdio mmc1:0001:1: info: FW download over, size 800344 bytes
[ 27.561352] mwifiex_sdio mmc1:0001:1: WLAN FW is active
[ 33.585165] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 37.651344] mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0xa9, act = 0x0
[ 37.660122] mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0
[ 37.665951] mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0
[ 37.671688] mwifiex_sdio mmc1:0001:1: is_cmd_timedout = 1
[ 37.677076] mwifiex_sdio mmc1:0001:1: num_tx_timeout = 0
[ 37.682380] mwifiex_sdio mmc1:0001:1: last_cmd_index = 1
[ 37.687681] mwifiex_sdio mmc1:0001:1: last_cmd_id: 00 00 a9 00 00 00 00 00 00 00
[ 37.695066] mwifiex_sdio mmc1:0001:1: last_cmd_act: 00 00 00 00 00 00 00 00 00 00
[ 37.702536] mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 0
[ 37.708269] mwifiex_sdio mmc1:0001:1: last_cmd_resp_id: 00 00 00 00 00 00 00 00 00 00
[ 37.716087] mwifiex_sdio mmc1:0001:1: last_event_index = 0
[ 37.721564] mwifiex_sdio mmc1:0001:1: last_event: 00 00 00 00 00 00 00 00 00 00
[ 37.728857] mwifiex_sdio mmc1:0001:1: data_sent=1 cmd_sent=0
[ 37.734508] mwifiex_sdio mmc1:0001:1: ps_mode=0 ps_state=0
[ 37.740016] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
[ 37.750268] mwifiex_sdio mmc1:0001:1: info: mwifiex_fw_dpc: unregister device
For either of these issues, if I simply revert the dw_mmc driver back to
its v4.9 version (but keep everything else at v4.10), things seem to
work fine.
At this point, I'm pretty sure that it's the runtime PM support added to
dw_mmc that cause the regression.
Any thoughts? I don't exactly plan on trying to debug a solution myself here,
but I thought I'd report it in case somebody else has ideas.
Brian
next reply other threads:[~2017-03-30 1:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 1:17 Brian Norris [this message]
[not found] ` <20170330011709.GA110687-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2017-03-30 1:32 ` [REGRESSION 4.10] dw_mmc: failures on Rockchip rk3288 veyron boards Shawn Lin
2017-03-30 1:42 ` Brian Norris
2017-03-30 2:18 ` Eddie Cai
2017-03-30 2:53 ` Brian Norris
2017-03-30 5:11 ` Jaehoon Chung
2017-04-06 22:04 ` Brian Norris
2017-04-07 4:59 ` Jaehoon Chung
2017-04-07 6:50 ` Shawn Lin
2017-04-07 7:38 ` Jaehoon Chung
2017-04-10 23:35 ` Doug Anderson
2017-04-11 10:21 ` Ulf Hansson
2017-04-11 22:57 ` Doug Anderson
2017-04-12 0:54 ` Shawn Lin
2017-04-12 16:12 ` Doug Anderson
2017-04-13 7:17 ` Ulf Hansson
2017-04-13 15:45 ` Doug Anderson
2017-04-13 8:28 ` Shawn Lin
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=20170330011709.GA110687@google.com \
--to=briannorris@chromium.org \
--cc=amstan@chromium.org \
--cc=heiko@sntech.de \
--cc=jh80.chung@samsung.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=shawn.lin@rock-chips.com \
--cc=xzy.xu@rock-chips.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox