use cond_resched() to replace udelay() when dump eeprom
Subsystems (3)
PATCH 1/1 use cond_resched() to replace udelay() when dump eeprom
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
--- drivers/net/ethernet/broadcom/tg3.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/tg3.c +3 -1
@@ -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 ;
Signature · 1 line
1.8.4.5
Quoted 30 lines · Yu-Chen
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>]0x7f6b6cbf4386Signed-off-by Cho, Yu-Chen <[email protected]>--- drivers/net/ethernet/broadcom/tg3.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)drivers/net/ethernet/broadcom/tg3.c +0
-0
drivers/net/ethernet/broadcom/tg3.c static int tg3_nvram_exec_cmd(struct tg3 *tp, u32 nvram_cmd) · line 3237
Quoted 7 lines
drivers/net/ethernet/broadcom/tg3.c +3
-1@@ -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).
Quoted 3 lines
drivers/net/ethernet/broadcom/tg3.c +0
-0if (tr32 (NVRAM_CMD ) &NVRAM_CMD_DONE ) {udelay (10 );break ;
David Miller
maintainerFrom: Michael Chan <[email protected]>
Date: Mon, 12 May 2014 10:48:30 -0700
Quoted 3 lines
We still need to time these commands. Using
cond_resched(), the timing becomes unpredictable. Perhaps we can reduce theNVRAM_CMD_TIMEOUTcounter by a factor of 100 and use msleep(1) instead of udelay(10).
That should work.
Quoted 8 lines · David Miller
From: Michael Chan <[email protected]>
Date: Mon, 12 May 2014 10:48:30 -0700Quoted 3 lines
We still need to time these commands. Using
cond_resched(), the timing becomes unpredictable. Perhaps we can reduce theNVRAM_CMD_TIMEOUTcounter 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.