From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: linux-i2c@vger.kernel.org, linux-mips@linux-mips.org,
David Daney <david.daney@cavium.com>,
Peter Swain <pswain@cavium.com>, Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
Date: Wed, 9 Nov 2016 14:41:03 +0100 [thread overview]
Message-ID: <20161109134103.GC2960@hardcore> (raw)
In-Reply-To: <20161107200921.30284-2-paul.burton@imgtec.com>
Hi Paul,
I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
register access retries". With debugging enabled I'm getting:
[ 78.871568] ipmi_ssif: Trying hotmod-specified SSIF interface at i2c address 0x12, adapter Cavium ThunderX i2c adapter at 0000:01:09.4, slave address 0x0
[ 78.886107] do not call blocking ops when !TASK_RUNNING; state=2 set at [<fffffc00080e0088>] prepare_to_wait_event+0x58/0x10c
[ 78.897436] ------------[ cut here ]------------
[ 78.902050] WARNING: CPU: 6 PID: 2235 at kernel/sched/core.c:7718 __might_sleep+0x80/0x88
[ 78.910218] Modules linked in: ipmi_ssif i2c_thunderx i2c_smbus nicvf nicpf thunder_bgx thunder_xcv mdio_thunder
[ 78.921916] CPU: 6 PID: 2235 Comm: bash Tainted: G W 4.9.0-rc3-jang+ #17
[ 78.929737] Hardware name: www.cavium.com ThunderX CRB-1S/ThunderX CRB-1S, BIOS 0.3 Aug 24 2016
[ 78.938426] task: fffffe1fdd554500 task.stack: fffffe1fe384c000
[ 78.944338] PC is at __might_sleep+0x80/0x88
[ 78.948601] LR is at __might_sleep+0x80/0x88
[ 78.952863] pc : [<fffffc00080c3aac>] lr : [<fffffc00080c3aac>] pstate: 80000145
[ 78.960250] sp : fffffe1fe384f600
[ 78.963557] x29: fffffe1fe384f600 x28: fffffe1fe384f860
[ 78.968875] x27: fffffe1fd07fa018 x26: fffffe1fe384f968
[ 78.974193] x25: fffffc0009a2b000 x24: 00000000ffff26d6
[ 78.979510] x23: fffffe1fe384f860 x22: fffffe1fe384f860
[ 78.984827] x21: 0000000000000000 x20: 00000000000000b1
[ 78.990144] x19: fffffc0000e330b8 x18: 0000000000005bb0
[ 78.995461] x17: fffffc0009669ca8 x16: 0000000000000000
[ 79.000779] x15: 0000000000000539 x14: 66663c5b20746120
[ 79.006097] x13: 74657320323d6574 x12: 617473203b474e49
[ 79.011415] x11: 4e4e55525f4b5341 x10: 5421206e65687720
[ 79.016732] x9 : 73706f20676e696b x8 : 0000000000000000
[ 79.022049] x7 : fffffc00080f5740 x6 : fffffc00080f5740
[ 79.027367] x5 : ffffffffffffff80 x4 : 0000000000000060
[ 79.032684] x3 : 0000000000000000 x2 : 0000000000000001
[ 79.038001] x1 : 0000000000000000 x0 : 0000000000000071
[ 79.044803] ---[ end trace d8af6005f683d444 ]---
[ 79.049413] Call trace:
[ 79.051853] Exception stack(0xfffffe1fe384f420 to 0xfffffe1fe384f550)
[ 79.058287] f420: fffffc0000e330b8 0000040000000000 fffffe1fe384f600 fffffc00080c3aac
[ 79.066109] f440: 0000000080000145 000000000000003d 0000000000000000 fffffc0008853920
[ 79.073931] f460: 0000040000000000 0000000100000001 fffffe1fe384f520 fffffc00080f60d8
[ 79.081752] f480: fffffc0000e330b8 00000000000000b1 0000000000000000 fffffe1fe384f860
[ 79.089574] f4a0: fffffe1fe384f860 00000000ffff26d6 fffffc0009a2b000 fffffe1fe384f968
[ 79.097396] f4c0: fffffe1fd07fa018 fffffe1fe384f860 0000000000000071 0000000000000000
[ 79.105218] f4e0: 0000000000000001 0000000000000000 0000000000000060 ffffffffffffff80
[ 79.113040] f500: fffffc00080f5740 fffffc00080f5740 0000000000000000 73706f20676e696b
[ 79.120861] f520: 5421206e65687720 4e4e55525f4b5341 617473203b474e49 74657320323d6574
[ 79.128683] f540: 66663c5b20746120 0000000000000539
[ 79.133553] [<fffffc00080c3aac>] __might_sleep+0x80/0x88
[ 79.138862] [<fffffc0000e30138>] octeon_i2c_test_iflg+0x4c/0xbc [i2c_thunderx]
[ 79.146077] [<fffffc0000e30958>] octeon_i2c_test_ready+0x18/0x70 [i2c_thunderx]
[ 79.153379] [<fffffc0000e30b04>] octeon_i2c_wait+0x154/0x1a4 [i2c_thunderx]
[ 79.160334] [<fffffc0000e310bc>] octeon_i2c_xfer+0xf4/0xf60 [i2c_thunderx]
This is not caused by the usleep inside the wait_event but by readq_poll_timeout().
Could you try if it works for you if you only revert this patch?
Thanks,
Jan
next prev parent reply other threads:[~2016-11-09 13:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 20:09 [PATCH 1/2] i2c: octeon: Fix register access Paul Burton
2016-11-07 20:09 ` [PATCH 2/2] i2c: octeon: Fix waiting for operation completion Paul Burton
2016-11-08 9:20 ` Jan Glauber
2016-11-09 13:41 ` Jan Glauber [this message]
2016-11-09 14:07 ` Paul Burton
2016-11-09 14:38 ` Jan Glauber
2016-11-11 8:57 ` Jan Glauber
2016-11-11 20:51 ` Steven J. Hill
2016-11-11 22:11 ` David Daney
2016-11-08 7:13 ` [PATCH 1/2] i2c: octeon: Fix register access Jan Glauber
2016-11-09 14:09 ` Paul Burton
2016-11-09 14:43 ` Jan Glauber
2016-11-10 20:17 ` Wolfram Sang
2016-11-11 7:00 ` Jan Glauber
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=20161109134103.GC2960@hardcore \
--to=jan.glauber@caviumnetworks.com \
--cc=david.daney@cavium.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.burton@imgtec.com \
--cc=pswain@cavium.com \
--cc=wsa@the-dreams.de \
/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;
as well as URLs for NNTP newsgroup(s).