* [PATCH] use cond_resched() to replace udelay() when dump eeprom
@ 2014-05-12 7:06 Cho, Yu-Chen
2014-05-12 17:48 ` Michael Chan
0 siblings, 1 reply; 4+ messages in thread
From: Cho, Yu-Chen @ 2014-05-12 7:06 UTC (permalink / raw)
To: netdev; +Cc: bpoirier
The loop in tg3_nvram_exec_cmd() will give up after about 100 msec per command,
it can loop for a long time.
For some test case , if we try to dump eeprom from tg3 interface,
what is UP but not running , NO-CARRIER (no cable), then the lock up occurs:
[<ffffffffa01def4a>] tg3_nvram_exec_cmd+0x3a/0x60 [tg3]
[<ffffffffa01e2982>] tg3_nvram_read+0x62/0x130 [tg3]
[<ffffffffa01e2a62>] tg3_nvram_read_be32+0x12/0x30 [tg3]
[<ffffffffa01e2b1d>] tg3_get_eeprom+0x9d/0x190 [tg3]
[<ffffffff81494cc2>] ethtool_get_any_eeprom+0xe2/0x170
[<ffffffff81496108>] dev_ethtool+0xd58/0x1a60
[<ffffffff814a43fb>] dev_ioctl+0x1ab/0x560
[<ffffffff8147782d>] sock_do_ioctl+0x3d/0x50
[<ffffffff81477c78>] sock_ioctl+0x1e8/0x2c0
[<ffffffff81197cc4>] do_vfs_ioctl+0x2d4/0x4b0
[<ffffffff81197f20>] SyS_ioctl+0x80/0xa0
[<ffffffff81581a7d>] system_call_fastpath+0x1a/0x1f
[<00007f6b6cbf4387>] 0x7f6b6cbf4386
Signed-off-by: Cho, Yu-Chen <acho@suse.com>
---
drivers/net/ethernet/broadcom/tg3.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index e5d95c5..7dc8bb5 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -3232,7 +3232,9 @@ static int tg3_nvram_exec_cmd(struct tg3 *tp, u32 nvram_cmd)
tw32(NVRAM_CMD, nvram_cmd);
for (i = 0; i < NVRAM_CMD_TIMEOUT; i++) {
- udelay(10);
+
+ cond_resched();
+
if (tr32(NVRAM_CMD) & NVRAM_CMD_DONE) {
udelay(10);
break;
--
1.8.4.5
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] use cond_resched() to replace udelay() when dump eeprom
2014-05-12 7:06 [PATCH] use cond_resched() to replace udelay() when dump eeprom Cho, Yu-Chen
@ 2014-05-12 17:48 ` Michael Chan
2014-05-14 4:53 ` David Miller
0 siblings, 1 reply; 4+ messages in thread
From: Michael Chan @ 2014-05-12 17:48 UTC (permalink / raw)
To: Cho, Yu-Chen; +Cc: netdev, bpoirier
On Mon, 2014-05-12 at 15:06 +0800, Cho, Yu-Chen wrote:
> The loop in tg3_nvram_exec_cmd() will give up after about 100 msec per command,
> it can loop for a long time.
>
> For some test case , if we try to dump eeprom from tg3 interface,
> what is UP but not running , NO-CARRIER (no cable), then the lock up occurs:
>
> [<ffffffffa01def4a>] tg3_nvram_exec_cmd+0x3a/0x60 [tg3]
> [<ffffffffa01e2982>] tg3_nvram_read+0x62/0x130 [tg3]
> [<ffffffffa01e2a62>] tg3_nvram_read_be32+0x12/0x30 [tg3]
> [<ffffffffa01e2b1d>] tg3_get_eeprom+0x9d/0x190 [tg3]
> [<ffffffff81494cc2>] ethtool_get_any_eeprom+0xe2/0x170
> [<ffffffff81496108>] dev_ethtool+0xd58/0x1a60
> [<ffffffff814a43fb>] dev_ioctl+0x1ab/0x560
> [<ffffffff8147782d>] sock_do_ioctl+0x3d/0x50
> [<ffffffff81477c78>] sock_ioctl+0x1e8/0x2c0
> [<ffffffff81197cc4>] do_vfs_ioctl+0x2d4/0x4b0
> [<ffffffff81197f20>] SyS_ioctl+0x80/0xa0
> [<ffffffff81581a7d>] system_call_fastpath+0x1a/0x1f
> [<00007f6b6cbf4387>] 0x7f6b6cbf4386
>
> Signed-off-by: Cho, Yu-Chen <acho@suse.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index e5d95c5..7dc8bb5 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -3232,7 +3232,9 @@ static int tg3_nvram_exec_cmd(struct tg3 *tp, u32 nvram_cmd)
>
> tw32(NVRAM_CMD, nvram_cmd);
> for (i = 0; i < NVRAM_CMD_TIMEOUT; i++) {
> - udelay(10);
> +
> + cond_resched();
> +
We still need to time these commands. Using cond_resched(), the timing
becomes unpredictable. Perhaps we can reduce the NVRAM_CMD_TIMEOUT
counter by a factor of 100 and use msleep(1) instead of udelay(10).
> if (tr32(NVRAM_CMD) & NVRAM_CMD_DONE) {
> udelay(10);
> break;
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] use cond_resched() to replace udelay() when dump eeprom
2014-05-12 17:48 ` Michael Chan
@ 2014-05-14 4:53 ` David Miller
2014-05-14 5:41 ` Michael Chan
0 siblings, 1 reply; 4+ messages in thread
From: David Miller @ 2014-05-14 4:53 UTC (permalink / raw)
To: mchan; +Cc: acho, netdev, bpoirier
From: Michael Chan <mchan@broadcom.com>
Date: Mon, 12 May 2014 10:48:30 -0700
> We still need to time these commands. Using cond_resched(), the timing
> becomes unpredictable. Perhaps we can reduce the NVRAM_CMD_TIMEOUT
> counter by a factor of 100 and use msleep(1) instead of udelay(10).
That should work.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] use cond_resched() to replace udelay() when dump eeprom
2014-05-14 4:53 ` David Miller
@ 2014-05-14 5:41 ` Michael Chan
0 siblings, 0 replies; 4+ messages in thread
From: Michael Chan @ 2014-05-14 5:41 UTC (permalink / raw)
To: David Miller; +Cc: acho, netdev, bpoirier
On Wed, 2014-05-14 at 00:53 -0400, David Miller wrote:
> From: Michael Chan <mchan@broadcom.com>
> Date: Mon, 12 May 2014 10:48:30 -0700
>
> > We still need to time these commands. Using cond_resched(), the timing
> > becomes unpredictable. Perhaps we can reduce the NVRAM_CMD_TIMEOUT
> > counter by a factor of 100 and use msleep(1) instead of udelay(10).
>
> That should work.
It actually won't work very well. It typically takes 10 to 20 us to
read one 32-bit value. Using msleep(1), it will take 100 times longer
than it should. When dumping the entire NVRAM, it will visibly take a
very long time.
We are working on a patch to make sure that the clock is not running
slow when reading the NVRAM. I think we can also reduce
NVRAM_CMD_TIMEOUT to something more reasonable.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-05-14 6:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-12 7:06 [PATCH] use cond_resched() to replace udelay() when dump eeprom Cho, Yu-Chen
2014-05-12 17:48 ` Michael Chan
2014-05-14 4:53 ` David Miller
2014-05-14 5:41 ` Michael Chan
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).