Le 15/12/2015 14:56, Dan Carpenter a écrit :
The problem here is that at the end of the loop we test for if
idc->vnic_wait_limit is zero, but since idc->vnic_wait_limit-- is a
post-op, it actually ends up set to (u8)-1. I have fixed this by
moving the decrement inside the loop.
Fixes: 486a5bc77a4a ('qlcnic: Add support for 83xx suspend and resume.')
Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
---
v2: different color on the bikeshed
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
index be7d7a6..b1a452f 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_vnic.c
@@ -246,7 +246,8 @@ int qlcnic_83xx_check_vnic_state(struct qlcnic_adapter
*adapter)
u32 state;
state = QLCRDX(ahw, QLC_83XX_VNIC_STATE);
- while (state != QLCNIC_DEV_NPAR_OPER && idc->vnic_wait_limit--) {
+ while (state != QLCNIC_DEV_NPAR_OPER && idc->vnic_wait_limit) {
+ idc->vnic_wait_limit--;
msleep(1000);
state = QLCRDX(ahw, QLC_83XX_VNIC_STATE);
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi everybody, & Happy new year.
We're seeing very sporadic & rare kernel oops due to qlcnic, even with
latests kernels.
I only have 1 trace, which can be seen here https://paste2.org/4m8EGEG1
Others kernel oops (not recorded) showed different stack trace, but in
the end, problem was always in qlcnic_xmit_frame
Any chance this bug is corrected by this very patch or is this a totally
different problem ?
Cheers,
Yann.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
