* [net-next 04/13] i40e: rework debug messages for NVM update
From: Jeff Kirsher @ 2014-12-09 11:22 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1418124170-7495-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
Rework the debug messages in the NVM update state machine so that we can
turn them on and off dynamically rather than forcing a recompile/reload.
These can now be turned on with something like:
ethtool -s eth1 msglvl 0xf000008f
and off with:
ethtool -s eth1 msglvl 0xf000000f
The high 0xf0000000 gets the driver's attention that we want to change the
internal debug flags, and the 0x80 bit is the NVM debug.
Change-ID: I5efb9039400304b29a0fd6ddea3f47bb362e6661
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 107 +++++++++++++++++++++--------
1 file changed, 80 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_nvm.c b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
index 25c4f9a..df429bb 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -61,7 +61,7 @@ i40e_status i40e_init_nvm(struct i40e_hw *hw)
} else { /* Blank programming mode */
nvm->blank_nvm_mode = true;
ret_code = I40E_ERR_NVM_BLANK_MODE;
- hw_dbg(hw, "NVM init error: unsupported blank mode.\n");
+ i40e_debug(hw, I40E_DEBUG_NVM, "NVM init error: unsupported blank mode.\n");
}
return ret_code;
@@ -118,8 +118,9 @@ i40e_status i40e_acquire_nvm(struct i40e_hw *hw,
hw->nvm.hw_semaphore_timeout = 0;
hw->nvm.hw_semaphore_wait =
I40E_MS_TO_GTIME(time) + gtime;
- hw_dbg(hw, "NVM acquire timed out, wait %llu ms before trying again.\n",
- time);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVM acquire timed out, wait %llu ms before trying again.\n",
+ time);
}
}
@@ -160,7 +161,7 @@ static i40e_status i40e_poll_sr_srctl_done_bit(struct i40e_hw *hw)
udelay(5);
}
if (ret_code == I40E_ERR_TIMEOUT)
- hw_dbg(hw, "Done bit in GLNVM_SRCTL not set\n");
+ i40e_debug(hw, I40E_DEBUG_NVM, "Done bit in GLNVM_SRCTL not set");
return ret_code;
}
@@ -179,7 +180,9 @@ i40e_status i40e_read_nvm_word(struct i40e_hw *hw, u16 offset,
u32 sr_reg;
if (offset >= hw->nvm.sr_size) {
- hw_dbg(hw, "NVM read error: Offset beyond Shadow RAM limit.\n");
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVM read error: offset %d beyond Shadow RAM limit %d\n",
+ offset, hw->nvm.sr_size);
ret_code = I40E_ERR_PARAM;
goto read_nvm_exit;
}
@@ -202,8 +205,9 @@ i40e_status i40e_read_nvm_word(struct i40e_hw *hw, u16 offset,
}
}
if (ret_code)
- hw_dbg(hw, "NVM read error: Couldn't access Shadow RAM address: 0x%x\n",
- offset);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVM read error: Couldn't access Shadow RAM address: 0x%x\n",
+ offset);
read_nvm_exit:
return ret_code;
@@ -263,14 +267,20 @@ static i40e_status i40e_write_nvm_aq(struct i40e_hw *hw, u8 module_pointer,
* Firmware will check the module-based model.
*/
if ((offset + words) > hw->nvm.sr_size)
- hw_dbg(hw, "NVM write error: offset beyond Shadow RAM limit.\n");
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVM write error: offset %d beyond Shadow RAM limit %d\n",
+ (offset + words), hw->nvm.sr_size);
else if (words > I40E_SR_SECTOR_SIZE_IN_WORDS)
/* We can write only up to 4KB (one sector), in one AQ write */
- hw_dbg(hw, "NVM write fail error: cannot write more than 4KB in a single write.\n");
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVM write fail error: tried to write %d words, limit is %d.\n",
+ words, I40E_SR_SECTOR_SIZE_IN_WORDS);
else if (((offset + (words - 1)) / I40E_SR_SECTOR_SIZE_IN_WORDS)
!= (offset / I40E_SR_SECTOR_SIZE_IN_WORDS))
/* A single write cannot spread over two sectors */
- hw_dbg(hw, "NVM write error: cannot spread over two sectors in a single write.\n");
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVM write error: cannot spread over two sectors in a single write offset=%d words=%d\n",
+ offset, words);
else
ret_code = i40e_aq_update_nvm(hw, module_pointer,
2 * offset, /*bytes*/
@@ -438,6 +448,22 @@ static inline u8 i40e_nvmupd_get_transaction(u32 val)
return (u8)((val & I40E_NVM_TRANS_MASK) >> I40E_NVM_TRANS_SHIFT);
}
+static char *i40e_nvm_update_state_str[] = {
+ "I40E_NVMUPD_INVALID",
+ "I40E_NVMUPD_READ_CON",
+ "I40E_NVMUPD_READ_SNT",
+ "I40E_NVMUPD_READ_LCB",
+ "I40E_NVMUPD_READ_SA",
+ "I40E_NVMUPD_WRITE_ERA",
+ "I40E_NVMUPD_WRITE_CON",
+ "I40E_NVMUPD_WRITE_SNT",
+ "I40E_NVMUPD_WRITE_LCB",
+ "I40E_NVMUPD_WRITE_SA",
+ "I40E_NVMUPD_CSUM_CON",
+ "I40E_NVMUPD_CSUM_SA",
+ "I40E_NVMUPD_CSUM_LCB",
+};
+
/**
* i40e_nvmupd_command - Process an NVM update command
* @hw: pointer to hardware structure
@@ -471,6 +497,8 @@ i40e_status i40e_nvmupd_command(struct i40e_hw *hw,
default:
/* invalid state, should never happen */
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVMUPD: no such state %d\n", hw->nvmupd_state);
status = I40E_NOT_SUPPORTED;
*errno = -ESRCH;
break;
@@ -572,6 +600,9 @@ static i40e_status i40e_nvmupd_state_init(struct i40e_hw *hw,
break;
default:
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVMUPD: bad cmd %s in init state\n",
+ i40e_nvm_update_state_str[upd_cmd]);
status = I40E_ERR_NVM;
*errno = -ESRCH;
break;
@@ -611,6 +642,9 @@ static i40e_status i40e_nvmupd_state_reading(struct i40e_hw *hw,
break;
default:
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVMUPD: bad cmd %s in reading state.\n",
+ i40e_nvm_update_state_str[upd_cmd]);
status = I40E_NOT_SUPPORTED;
*errno = -ESRCH;
break;
@@ -671,6 +705,9 @@ static i40e_status i40e_nvmupd_state_writing(struct i40e_hw *hw,
break;
default:
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "NVMUPD: bad cmd %s in writing state.\n",
+ i40e_nvm_update_state_str[upd_cmd]);
status = I40E_NOT_SUPPORTED;
*errno = -ESRCH;
break;
@@ -702,8 +739,9 @@ static enum i40e_nvmupd_cmd i40e_nvmupd_validate_command(struct i40e_hw *hw,
/* limits on data size */
if ((cmd->data_size < 1) ||
(cmd->data_size > I40E_NVMUPD_MAX_DATA)) {
- hw_dbg(hw, "i40e_nvmupd_validate_command data_size %d\n",
- cmd->data_size);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_validate_command data_size %d\n",
+ cmd->data_size);
*errno = -EFAULT;
return I40E_NVMUPD_INVALID;
}
@@ -755,12 +793,14 @@ static enum i40e_nvmupd_cmd i40e_nvmupd_validate_command(struct i40e_hw *hw,
}
break;
}
+ i40e_debug(hw, I40E_DEBUG_NVM, "%s\n",
+ i40e_nvm_update_state_str[upd_cmd]);
if (upd_cmd == I40E_NVMUPD_INVALID) {
*errno = -EFAULT;
- hw_dbg(hw,
- "i40e_nvmupd_validate_command returns %d errno: %d\n",
- upd_cmd, *errno);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_validate_command returns %d errno %d\n",
+ upd_cmd, *errno);
}
return upd_cmd;
}
@@ -785,14 +825,18 @@ static i40e_status i40e_nvmupd_nvm_read(struct i40e_hw *hw,
transaction = i40e_nvmupd_get_transaction(cmd->config);
module = i40e_nvmupd_get_module(cmd->config);
last = (transaction == I40E_NVM_LCB) || (transaction == I40E_NVM_SA);
- hw_dbg(hw, "i40e_nvmupd_nvm_read mod 0x%x off 0x%x len 0x%x\n",
- module, cmd->offset, cmd->data_size);
status = i40e_aq_read_nvm(hw, module, cmd->offset, (u16)cmd->data_size,
bytes, last, NULL);
- hw_dbg(hw, "i40e_nvmupd_nvm_read status %d\n", status);
- if (status)
+ if (status) {
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_nvm_read mod 0x%x off 0x%x len 0x%x\n",
+ module, cmd->offset, cmd->data_size);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_nvm_read status %d aq %d\n",
+ status, hw->aq.asq_last_status);
*errno = i40e_aq_rc_to_posix(hw->aq.asq_last_status);
+ }
return status;
}
@@ -816,13 +860,17 @@ static i40e_status i40e_nvmupd_nvm_erase(struct i40e_hw *hw,
transaction = i40e_nvmupd_get_transaction(cmd->config);
module = i40e_nvmupd_get_module(cmd->config);
last = (transaction & I40E_NVM_LCB);
- hw_dbg(hw, "i40e_nvmupd_nvm_erase mod 0x%x off 0x%x len 0x%x\n",
- module, cmd->offset, cmd->data_size);
status = i40e_aq_erase_nvm(hw, module, cmd->offset, (u16)cmd->data_size,
last, NULL);
- hw_dbg(hw, "i40e_nvmupd_nvm_erase status %d\n", status);
- if (status)
+ if (status) {
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_nvm_erase mod 0x%x off 0x%x len 0x%x\n",
+ module, cmd->offset, cmd->data_size);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_nvm_erase status %d aq %d\n",
+ status, hw->aq.asq_last_status);
*errno = i40e_aq_rc_to_posix(hw->aq.asq_last_status);
+ }
return status;
}
@@ -847,13 +895,18 @@ static i40e_status i40e_nvmupd_nvm_write(struct i40e_hw *hw,
transaction = i40e_nvmupd_get_transaction(cmd->config);
module = i40e_nvmupd_get_module(cmd->config);
last = (transaction & I40E_NVM_LCB);
- hw_dbg(hw, "i40e_nvmupd_nvm_write mod 0x%x off 0x%x len 0x%x\n",
- module, cmd->offset, cmd->data_size);
+
status = i40e_aq_update_nvm(hw, module, cmd->offset,
(u16)cmd->data_size, bytes, last, NULL);
- hw_dbg(hw, "i40e_nvmupd_nvm_write status %d\n", status);
- if (status)
+ if (status) {
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_nvm_write mod 0x%x off 0x%x len 0x%x\n",
+ module, cmd->offset, cmd->data_size);
+ i40e_debug(hw, I40E_DEBUG_NVM,
+ "i40e_nvmupd_nvm_write status %d aq %d\n",
+ status, hw->aq.asq_last_status);
*errno = i40e_aq_rc_to_posix(hw->aq.asq_last_status);
+ }
return status;
}
--
1.9.3
^ permalink raw reply related
* [net-next 05/13] i40e: add range check to i40e_aq_rc_to_posix
From: Jeff Kirsher @ 2014-12-09 11:22 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1418124170-7495-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
Just to be sure, add a range check to avoid any possible
array index-out-of-bound issues.
Change-ID: I9323bee6732c2a47599816e1d6c6b3a1f8dcbf54
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Acked-by: Michal Kosiarz <michal.kosiarz@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq.h | 2 ++
drivers/net/ethernet/intel/i40evf/i40e_adminq.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
index 618fe96..4064b1e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
@@ -136,6 +136,8 @@ static inline int i40e_aq_rc_to_posix(u16 aq_rc)
-EFBIG, /* I40E_AQ_RC_EFBIG */
};
+ if (aq_rc >= (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0])))
+ return -ERANGE;
return aq_to_posix[aq_rc];
}
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq.h b/drivers/net/ethernet/intel/i40evf/i40e_adminq.h
index d5d3c93..4d63514 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq.h
@@ -136,6 +136,8 @@ static inline int i40e_aq_rc_to_posix(u16 aq_rc)
-EFBIG, /* I40E_AQ_RC_EFBIG */
};
+ if (aq_rc >= (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0])))
+ return -ERANGE;
return aq_to_posix[aq_rc];
}
--
1.9.3
^ permalink raw reply related
* [net-next 02/13] i40e: better error messages for NVM update issues
From: Jeff Kirsher @ 2014-12-09 11:22 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1418124170-7495-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
Add more detail to the NVM update error messages so folks
have a better chance at diagnosing issues without having to
resort to heroic measures to reproduce an issue.
Change-ID: I270d1a9c903baceaef0bebcc55d29108ac08b0bd
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 52 ++++++++++++++++----------
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 25242f5..951e876 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -822,7 +822,7 @@ static int i40e_get_eeprom(struct net_device *netdev,
struct i40e_netdev_priv *np = netdev_priv(netdev);
struct i40e_hw *hw = &np->vsi->back->hw;
struct i40e_pf *pf = np->vsi->back;
- int ret_val = 0, len;
+ int ret_val = 0, len, offset;
u8 *eeprom_buff;
u16 i, sectors;
bool last;
@@ -835,19 +835,21 @@ static int i40e_get_eeprom(struct net_device *netdev,
/* check for NVMUpdate access method */
magic = hw->vendor_id | (hw->device_id << 16);
if (eeprom->magic && eeprom->magic != magic) {
+ struct i40e_nvm_access *cmd;
int errno;
/* make sure it is the right magic for NVMUpdate */
if ((eeprom->magic >> 16) != hw->device_id)
return -EINVAL;
- ret_val = i40e_nvmupd_command(hw,
- (struct i40e_nvm_access *)eeprom,
- bytes, &errno);
+ cmd = (struct i40e_nvm_access *)eeprom;
+ ret_val = i40e_nvmupd_command(hw, cmd, bytes, &errno);
if (ret_val)
dev_info(&pf->pdev->dev,
- "NVMUpdate read failed err=%d status=0x%x\n",
- ret_val, hw->aq.asq_last_status);
+ "NVMUpdate read failed err=%d status=0x%x errno=%d module=%d offset=0x%x size=%d\n",
+ ret_val, hw->aq.asq_last_status, errno,
+ (u8)(cmd->config & I40E_NVM_MOD_PNT_MASK),
+ cmd->offset, cmd->data_size);
return errno;
}
@@ -876,20 +878,29 @@ static int i40e_get_eeprom(struct net_device *netdev,
len = eeprom->len - (I40E_NVM_SECTOR_SIZE * i);
last = true;
}
- ret_val = i40e_aq_read_nvm(hw, 0x0,
- eeprom->offset + (I40E_NVM_SECTOR_SIZE * i),
- len,
+ offset = eeprom->offset + (I40E_NVM_SECTOR_SIZE * i),
+ ret_val = i40e_aq_read_nvm(hw, 0x0, offset, len,
(u8 *)eeprom_buff + (I40E_NVM_SECTOR_SIZE * i),
last, NULL);
- if (ret_val) {
+ if (ret_val && hw->aq.asq_last_status == I40E_AQ_RC_EPERM) {
dev_info(&pf->pdev->dev,
- "read NVM failed err=%d status=0x%x\n",
- ret_val, hw->aq.asq_last_status);
- goto release_nvm;
+ "read NVM failed, invalid offset 0x%x\n",
+ offset);
+ break;
+ } else if (ret_val &&
+ hw->aq.asq_last_status == I40E_AQ_RC_EACCES) {
+ dev_info(&pf->pdev->dev,
+ "read NVM failed, access, offset 0x%x\n",
+ offset);
+ break;
+ } else if (ret_val) {
+ dev_info(&pf->pdev->dev,
+ "read NVM failed offset %d err=%d status=0x%x\n",
+ offset, ret_val, hw->aq.asq_last_status);
+ break;
}
}
-release_nvm:
i40e_release_nvm(hw);
memcpy(bytes, (u8 *)eeprom_buff, eeprom->len);
free_buff:
@@ -917,6 +928,7 @@ static int i40e_set_eeprom(struct net_device *netdev,
struct i40e_netdev_priv *np = netdev_priv(netdev);
struct i40e_hw *hw = &np->vsi->back->hw;
struct i40e_pf *pf = np->vsi->back;
+ struct i40e_nvm_access *cmd;
int ret_val = 0;
int errno;
u32 magic;
@@ -934,12 +946,14 @@ static int i40e_set_eeprom(struct net_device *netdev,
test_bit(__I40E_RESET_INTR_RECEIVED, &pf->state))
return -EBUSY;
- ret_val = i40e_nvmupd_command(hw, (struct i40e_nvm_access *)eeprom,
- bytes, &errno);
- if (ret_val)
+ cmd = (struct i40e_nvm_access *)eeprom;
+ ret_val = i40e_nvmupd_command(hw, cmd, bytes, &errno);
+ if (ret_val && hw->aq.asq_last_status != I40E_AQ_RC_EBUSY)
dev_info(&pf->pdev->dev,
- "NVMUpdate write failed err=%d status=0x%x\n",
- ret_val, hw->aq.asq_last_status);
+ "NVMUpdate write failed err=%d status=0x%x errno=%d module=%d offset=0x%x size=%d\n",
+ ret_val, hw->aq.asq_last_status, errno,
+ (u8)(cmd->config & I40E_NVM_MOD_PNT_MASK),
+ cmd->offset, cmd->data_size);
return errno;
}
--
1.9.3
^ permalink raw reply related
* [net-next 03/13] i40e: let firmware catch the NVM busy error
From: Jeff Kirsher @ 2014-12-09 11:22 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1418124170-7495-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
The NVM update operations take time finish asynchronously, and follow-on
update requests need to wait for the current one to finish. Early
firmware didn't handle this well, so the code had to track the busy state.
The released firmware handles the busy state correctly, returning
I40E_AQ_RC_EBUSY if an update is still in progress, so the code no longer
needs to track this.
Change-ID: I6e6b4adc26d6dcc5fd7adfee5763423858a7d921
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Acked-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 11 -----------
drivers/net/ethernet/intel/i40e/i40e_adminq.h | 1 -
drivers/net/ethernet/intel/i40evf/i40e_adminq.c | 6 ------
drivers/net/ethernet/intel/i40evf/i40e_adminq.h | 1 -
4 files changed, 19 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.c b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
index 35fa09a..ebff11b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.c
@@ -617,7 +617,6 @@ i40e_status i40e_init_adminq(struct i40e_hw *hw)
/* pre-emptive resource lock release */
i40e_aq_release_resource(hw, I40E_NVM_RESOURCE_ID, 0, NULL);
- hw->aq.nvm_busy = false;
ret_code = i40e_aq_set_hmc_resource_profile(hw,
I40E_HMC_PROFILE_DEFAULT,
@@ -754,12 +753,6 @@ i40e_status i40e_asq_send_command(struct i40e_hw *hw,
goto asq_send_command_exit;
}
- if (i40e_is_nvm_update_op(desc) && hw->aq.nvm_busy) {
- i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE, "AQTX: NVM busy.\n");
- status = I40E_ERR_NVM;
- goto asq_send_command_exit;
- }
-
details = I40E_ADMINQ_DETAILS(hw->aq.asq, hw->aq.asq.next_to_use);
if (cmd_details) {
*details = *cmd_details;
@@ -901,9 +894,6 @@ i40e_status i40e_asq_send_command(struct i40e_hw *hw,
status = I40E_ERR_ADMIN_QUEUE_TIMEOUT;
}
- if (!status && i40e_is_nvm_update_op(desc))
- hw->aq.nvm_busy = true;
-
asq_send_command_error:
mutex_unlock(&hw->aq.asq_mutex);
asq_send_command_exit:
@@ -1016,7 +1006,6 @@ clean_arq_element_out:
mutex_unlock(&hw->aq.arq_mutex);
if (i40e_is_nvm_update_op(&e->desc)) {
- hw->aq.nvm_busy = false;
if (hw->aq.nvm_release_on_done) {
i40e_release_nvm(hw);
hw->aq.nvm_release_on_done = false;
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
index 003a227..618fe96 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
@@ -94,7 +94,6 @@ struct i40e_adminq_info {
u16 fw_min_ver; /* firmware minor version */
u16 api_maj_ver; /* api major version */
u16 api_min_ver; /* api minor version */
- bool nvm_busy;
bool nvm_release_on_done;
struct mutex asq_mutex; /* Send queue lock */
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq.c b/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
index 1698994..c1d25f8 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq.c
@@ -836,9 +836,6 @@ i40e_status i40evf_asq_send_command(struct i40e_hw *hw,
hw->aq.asq_last_status = (enum i40e_admin_queue_err)retval;
}
- if (i40e_is_nvm_update_op(desc))
- hw->aq.nvm_busy = true;
-
i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE,
"AQTX: desc and buffer writeback:\n");
i40evf_debug_aq(hw, I40E_DEBUG_AQ_COMMAND, (void *)desc, buff,
@@ -931,9 +928,6 @@ i40e_status i40evf_clean_arq_element(struct i40e_hw *hw,
memcpy(e->msg_buf, hw->aq.arq.r.arq_bi[desc_idx].va,
e->msg_len);
- if (i40e_is_nvm_update_op(&e->desc))
- hw->aq.nvm_busy = false;
-
i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE, "AQRX: desc and buffer:\n");
i40evf_debug_aq(hw, I40E_DEBUG_AQ_COMMAND, (void *)desc, e->msg_buf,
hw->aq.arq_buf_size);
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_adminq.h b/drivers/net/ethernet/intel/i40evf/i40e_adminq.h
index 0d58378..d5d3c93 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_adminq.h
+++ b/drivers/net/ethernet/intel/i40evf/i40e_adminq.h
@@ -94,7 +94,6 @@ struct i40e_adminq_info {
u16 fw_min_ver; /* firmware minor version */
u16 api_maj_ver; /* api major version */
u16 api_min_ver; /* api minor version */
- bool nvm_busy;
bool nvm_release_on_done;
struct mutex asq_mutex; /* Send queue lock */
--
1.9.3
^ permalink raw reply related
* [net-next 00/13][pull request] Intel Wired LAN Driver Updates 2014-12-09
From: Jeff Kirsher @ 2014-12-09 11:22 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to i40e and i40evf.
Jeff (me) provides a single patch to convert a macro to a static inline
function based on feedback from Joe Perches on a previous patch.
Shannon provides the remaining twelve patches against i40e. Almost all
of Shannon's patches cleanup/fix NVM issues varying in range from
adding more detail to debug messages, to removing dead code, to fixing
NVM state transitions after an error. Change the handy decoder interface
for admin queue return code to help catch and properly report the condition
as a useful errno rather than returning a misleading '0'. Added a range
check to avoid any possible array index-out-of-bound issues.
The following are changes since commit 9cdfe2c709c4f6076249ced6844b2bea420739c4:
sunvnet: fix incorrect rcu_read_unlock() in vnet_start_xmit()
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Jeff Kirsher (1):
i40e/i40evf: Convert macro to static inline
Shannon Nelson (12):
i40e: clear NVM update state on ethtool test
i40e: better error messages for NVM update issues
i40e: let firmware catch the NVM busy error
i40e: rework debug messages for NVM update
i40e: add range check to i40e_aq_rc_to_posix
i40e: init NVM update state on adminq init
i40e: remove unused nvm_semaphore_wait
i40e: set max limit for access polling
i40e: fix up NVM update sm error handling
i40e: poll on NVM semaphore only if not other error
i40e: check for AQ timeout in aq_rc decode
i40e: add to NVM update debug message
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 13 +-
drivers/net/ethernet/intel/i40e/i40e_adminq.h | 10 +-
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 55 ++++---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 198 ++++++++++++++++--------
drivers/net/ethernet/intel/i40e/i40e_type.h | 8 +-
drivers/net/ethernet/intel/i40evf/i40e_adminq.c | 6 -
drivers/net/ethernet/intel/i40evf/i40e_adminq.h | 10 +-
drivers/net/ethernet/intel/i40evf/i40e_type.h | 8 +-
8 files changed, 197 insertions(+), 111 deletions(-)
--
1.9.3
^ permalink raw reply
* [net-next 01/13] i40e: clear NVM update state on ethtool test
From: Jeff Kirsher @ 2014-12-09 11:22 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1418124170-7495-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
Once in a great while the NVMUpdate tools and the driver get out
of phase with each other. This gives us a way to reset things
without having to unload the driver.
Change-ID: I353f688236249a666a90ba3e7233e0ed8c1a04e9
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Jim Young <jamesx.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index fcd815d..25242f5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1393,6 +1393,9 @@ static int i40e_eeprom_test(struct net_device *netdev, u64 *data)
netif_info(pf, hw, netdev, "eeprom test\n");
*data = i40e_diag_eeprom_test(&pf->hw);
+ /* forcebly clear the NVM Update state machine */
+ pf->hw.nvmupd_state = I40E_NVMUPD_STATE_INIT;
+
return *data;
}
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 1/1] net: fec: avoid kernal crash by NULL pointer when no phy connection
From: Fugang Duan @ 2014-12-09 10:46 UTC (permalink / raw)
To: davem; +Cc: netdev, s.hauer, bhutchings, b38611, stephen
On i.MX6SX sabreauto board, when there have no phy daughter board connection,
there have kernel crash by NULL pointer:
fec 2188000.ethernet eth0: could not attach to PHY
Unable to handle kernel NULL pointer dereference at virtual address 00000220
pgd = 80004000
[00000220] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.24-01042-g27eaeea-dirty #405
task: d8078000 ti: d8076000 task.ti: d8076000
PC is at mutex_lock+0x10/0x54
LR is at phy_start+0x14/0x68
pc : [<806ad4e4>] lr : [<803b0f90>] psr: 60000113
sp : d8077d80 ip : 00000000 fp : d83cc000
r10: 0000100c r9 : d83cc800 r8 : 00000000
r7 : d83bcd0c r6 : 00000200 r5 : 00000220 r4 : 00000220
r3 : 00000000 r2 : 00000000 r1 : d83bcd90 r0 : 00000220
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 8000404a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xd8076240)
Stack: (0xd8077d80 to 0xd8078000)
7d80: 00000000 803b0f90 00000001 00000000 d83bc800 803be034 00000007 805c3fb4
7da0: 00000003 80d4e0bc 805efcb8 fffffff1 fffffff0 00000000 00000000 d8077dfc
7dc0: 0000000d 80d6ce80 80d126b0 800499c8 d83bc800 d83bc800 806f0f40 d83bc82c
7de0: 00000000 00000000 80d6ce80 80d126b0 0000016b 80540250 d8076008 d83bc800
7e00: 0000016b d83bc800 00001003 00000001 00001002 805404d4 d83bc800 00000120
7e20: 00001002 00001002 00000000 805405d4 d83bc800 00000001 80d126c0 00001002
7e40: 80dbc5dc 80d02024 00000000 806ae360 00000002 d6128420 d6127198 12400000
7e60: 00000000 00000000 00000002 d61271e8 00000000 12400000 d801674c 800e49f0
7e80: d6127198 d6124e58 00000000 80238848 d61271c4 00000000 00000001 d8016700
7ea0: 80dd2e00 80d752c0 80d752c0 80cfdaec 0000010c 80239430 806c2e90 d800f080
7ec0: d800f380 804e46b4 ffffffbc 80d15cb0 00000007 80d752c0 80d752c0 80d01e94
7ee0: 0000010c d8076030 00000000 800088cc 80dbaba4 80bd411c d80a6f00 806b1e04
7f00: 00000000 00000000 00000000 80125b84 00000000 80d2c56c 60000113 00000001
7f20: ef7ff9df 806c80cc 0000010c 80043f5c 80c95eb8 00000007 ef7ffa1d 00000007
7f40: 80d2c55c 80d15cb0 00000007 80d752c0 80d752c0 80ccc50c 0000010c 80d0a114
7f60: 80d0a10c 80cccc04 00000007 00000007 80ccc50c 806ae410 00000000 8004cb84
7f80: 80d17bc0 00000000 806a4bd4 00000000 00000000 00000000 00000000 00000000
7fa0: 00000000 806a4bdc 00000000 8000e5f8 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 1e79a7bb e5337f77
[<806ad4e4>] (mutex_lock) from [<803b0f90>] (phy_start+0x14/0x68)
[<803b0f90>] (phy_start) from [<803be034>] (fec_enet_open+0x448/0x5dc)
[<803be034>] (fec_enet_open) from [<80540250>] (__dev_open+0xa8/0x110)
[<80540250>] (__dev_open) from [<805404d4>] (__dev_change_flags+0x88/0x170)
[<805404d4>] (__dev_change_flags) from [<805405d4>] (dev_change_flags+0x18/0x48)
[<805405d4>] (dev_change_flags) from [<80d02024>] (ip_auto_config+0x190/0xf94)
[<80d02024>] (ip_auto_config) from [<800088cc>] (do_one_initcall+0xe8/0x144)
[<800088cc>] (do_one_initcall) from [<80cccc04>] (kernel_init_freeable+0x104/0x1c8)
[<80cccc04>] (kernel_init_freeable) from [<806a4bdc>] (kernel_init+0x8/0xec)
[<806a4bdc>] (kernel_init) from [<8000e5f8>] (ret_from_fork+0x14/0x3c)
Code: e92d4010 e3a03000 e1a04000 ee073fba (e1903f9f)
Add phydev check to fix the issue.
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
drivers/net/ethernet/freescale/fec_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d2955ce..fee2afe 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1872,6 +1872,8 @@ static int fec_enet_mii_probe(struct net_device *ndev)
phy_dev = of_phy_connect(ndev, fep->phy_node,
&fec_enet_adjust_link, 0,
fep->phy_interface);
+ if (!phy_dev)
+ return -ENODEV;
} else {
/* check for attached phy */
for (phy_id = 0; (phy_id < PHY_MAX_ADDR); phy_id++) {
--
1.7.8
^ permalink raw reply related
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Smart Weblications GmbH - Florian Wiessner @ 2014-12-09 10:23 UTC (permalink / raw)
To: Julian Anastasov
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <alpine.LFD.2.11.1412082234350.2401@ja.home.ssi.bg>
Hi Julian,
Am 08.12.2014 21:40, schrieb Julian Anastasov:
>
> Hello,
>
> On Mon, 8 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
>
>> Am 07.12.2014 19:27, schrieb Julian Anastasov:>
>>>
>>> I'm attaching a patch that avoids rerouting in
>>> IPVS for LOCAL_IN. Please test it in your setup. My tests
>>> were with NAT on today's net tree. I checked that it
>>> compiles for 3.12.33. You can use the default snat_reroute=1.
>>>
>>
>> I'm sorry to tell you that your patch does not fix the problem. The BUG happens
>> as soon as the client sends PASV, the ftp server does not return "Entering
>> Passive Mode":
>
> Patch is to avoid the xfrm_selector_match crash,
> may be caused when using local client (mail?).
> For nf_ct_seqadj_set you have to use commit b25adce16064
> ("ipvs: correct usage/allocation of seqadj ext in ipvs").
> I'll send it to you privately...
>
I rebuild everything with the two provided patches and still get:
[ 512.475449] BUG: unable to handle kernel NULL pointer dereference at
0000000000000014
[ 512.481277] IP: [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[ 512.481442] PGD 0
[ 512.481572] Oops: 0000 [#1] SMP
[ 512.481750] Modules linked in: ip_vs_rr netconsole xt_nat xt_multiport veth
iptable_mangle xt_mark nf_conntrack_netlink nfnetlink ipt_MASQUERADE iptable_nat
nf_nat_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter
ip_tables cpufreq_ondemand cpufreq_powersave cpufreq_conservative
cpufreq_userspace ocfs2_stack_o2cb ocfs2_dlm bridge stp llc bonding fuse
nf_conntrack_ftp 8021q openvswitch gre vxlan xt_conntrack x_tables ocfs2_dlmfs
dlm sctp ocfs2 ocfs2_nodemanager ocfs2_stackglue configfs rbd kvm_intel kvm
coretemp ip_vs_ftp ip_vs nf_nat nf_conntrack psmouse serio_raw i2c_i801 lpc_ich
mfd_core evdev btrfs lzo_decompress lzo_compress
[ 512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
[ 512.485405] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
09/28/2011
[ 512.485497] task: ffff880703f1c500 ti: ffff8805cab2e000 task.ti: ffff8805cab2e000
[ 512.485594] RIP: 0010:[<ffffffffa013d470>] [<ffffffffa013d470>]
nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[ 512.485751] RSP: 0018:ffff88083fd03988 EFLAGS: 00010206
[ 512.485829] RAX: 000000000000000c RBX: ffff8805cb314b1c RCX: 0000000000000003
[ 512.485916] RDX: 0000000000000026 RSI: 0000000000000003 RDI: ffff8805cb314b1c
[ 512.486007] RBP: 00000000030a6079 R08: ffff88079d058c80 R09: ffff88083fd03998
[ 512.486084] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
[ 512.486162] R13: 0000000000000000 R14: 0000000000000003 R15: ffff8808170150bc
[ 512.486240] FS: 00007f0497645700(0000) GS:ffff88083fd00000(0000)
knlGS:0000000000000000
[ 512.486351] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 512.486431] CR2: 0000000000000014 CR3: 00000007457f4000 CR4: 00000000000407e0
[ 512.486512] Stack:
[ 512.486583] ffff88077b389460 0000000000000012 0000000000000014 ffff8805cb314b18
[ 512.486886] ffff880817015001 ffffffffa0152681 0000000000000000 ffffffff00000045
[ 512.487195] ffff880800000048 0000001b00000003 ffff88083fd03a60 ffff88077b389460
[ 512.487501] Call Trace:
[ 512.487574] <IRQ>
[ 512.487634] [<ffffffffa0152681>] ? __nf_nat_mangle_tcp_packet+0x109/0x120
[nf_nat]
[ 512.487859] [<ffffffffa017a49e>] ? ip_vs_ftp_out.part.8+0x2b2/0x338 [ip_vs_ftp]
[ 512.487957] [<ffffffffa0162884>] ? ip_vs_app_pkt_out+0x105/0x18b [ip_vs]
[ 512.488038] [<ffffffffa0166028>] ? tcp_snat_handler+0x6b/0x320 [ip_vs]
[ 512.488123] [<ffffffffa0158d3d>] ? ip_vs_conn_out_get_proto+0x1c/0x25 [ip_vs]
[ 512.488222] [<ffffffffa015b93c>] ? ip_vs_out+0x2a5/0x5f6 [ip_vs]
[ 512.488325] [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[ 512.488405] [<ffffffff81508e1f>] ? nf_iterate+0x42/0x80
[ 512.488486] [<ffffffff81508ec6>] ? nf_hook_slow+0x69/0xff
[ 512.488565] [<ffffffff8150f544>] ? ip_frag_mem+0x2a/0x2a
[ 512.488645] [<ffffffff8150f8ae>] ? ip_forward+0x22d/0x2cf
[ 512.488729] [<ffffffff814e57ce>] ? __netif_receive_skb_core+0x5f0/0x66c
[ 512.488810] [<ffffffff814e59df>] ? process_backlog+0x13e/0x13e
[ 512.488893] [<ffffffffa0458e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
[ 512.488987] [<ffffffff814e5a2b>] ? netif_receive_skb+0x4c/0x7d
[ 512.489068] [<ffffffffa0458d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
[ 512.489166] [<ffffffffa0458fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
[ 512.489247] [<ffffffff814e567d>] ? __netif_receive_skb_core+0x49f/0x66c
[ 512.489338] [<ffffffff814e592b>] ? process_backlog+0x8a/0x13e
[ 512.489415] [<ffffffff814e5c31>] ? net_rx_action+0xa2/0x1c0
[ 512.489493] [<ffffffff81047e2e>] ? __do_softirq+0xf6/0x24f
[ 512.489578] [<ffffffff815ad7dc>] ? call_softirq+0x1c/0x30
[ 512.489655] <EOI>
[ 512.489721] [<ffffffff8100464d>] ? do_softirq+0x2c/0x5f
[ 512.489920] [<ffffffff81047ca1>] ? local_bh_enable+0x67/0x85
[ 512.489996] [<ffffffff81511689>] ? ip_finish_output+0x2c9/0x322
[ 512.490076] [<ffffffff8151240a>] ? ip_queue_xmit+0x2b7/0x2f0
[ 512.490156] [<ffffffff81524772>] ? tcp_transmit_skb+0x6ef/0x755
[ 512.490235] [<ffffffff815250e8>] ? tcp_write_xmit+0x886/0x9cb
[ 512.490311] [<ffffffff8152527a>] ? __tcp_push_pending_frames+0x24/0x7e
[ 512.490392] [<ffffffff8151a33c>] ? tcp_sendmsg+0xa4c/0xbfc
[ 512.490466] [<ffffffff814d3477>] ? sock_aio_write+0xe3/0xfd
[ 512.490545] [<ffffffff81122f4d>] ? do_sync_write+0x59/0x79
[ 512.490623] [<ffffffff811239e3>] ? vfs_write+0xc4/0x182
[ 512.490703] [<ffffffff81123daf>] ? SyS_write+0x45/0x7c
[ 512.490781] [<ffffffff815ac35b>] ? tracesys+0xdd/0xe2
[ 512.490859] Code: 68 14 4d 01 c5 45 85 e4 74 46 f0 80 4f 78 40 48 8d 5f 04 48
89 df e8 00 e2 46 e1 31 c0 41 83 fe 02 0f 97 c0 48 6b c0 0c 4c 01 e8 <8b> 70 08
39 70 04 74 08 89 ea 0f ca 39 10 79 0d 89 70 04 44 01
[ 512.494558] RIP [<ffffffffa013d470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack]
[ 512.494714] RSP <ffff88083fd03988>
[ 512.494785] CR2: 0000000000000014
[ 512.494871] ---[ end trace 8a6e753cba1ccec2 ]---
--
Mit freundlichen Grüßen,
Florian Wiessner
Smart Weblications GmbH
Martinsberger Str. 1
D-95119 Naila
fon.: +49 9282 9638 200
fax.: +49 9282 9638 205
24/7: +49 900 144 000 00 - 0,99 EUR/Min*
http://www.smart-weblications.de
--
Sitz der Gesellschaft: Naila
Geschäftsführer: Florian Wiessner
HRB-Nr.: HRB 3840 Amtsgericht Hof
*aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz
^ permalink raw reply
* [PATCH] stmmac: platform: adjust messages and move to dev level
From: Andy Shevchenko @ 2014-12-09 9:59 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S . Miller, netdev; +Cc: Andy Shevchenko
This patch amendes error and warning messages across the platform driver. It
includes the following changes:
- remove unneccessary message when no memory is available
- change info level to warn in the validation functions
- append \n to the end of messages
- change pr_* macros to dev_*
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 37 ++++++++++++----------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 4032b17..e809b30 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -53,6 +53,7 @@ MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
/**
* dwmac1000_validate_mcast_bins - validates the number of Multicast filter bins
+ * @dev: struct device of the platform device
* @mcast_bins: Multicast filtering bins
* Description:
* this function validates the number of Multicast filtering bins specified
@@ -63,7 +64,7 @@ MODULE_DEVICE_TABLE(of, stmmac_dt_ids);
* invalid and will cause the filtering algorithm to use Multicast
* promiscuous mode.
*/
-static int dwmac1000_validate_mcast_bins(int mcast_bins)
+static int dwmac1000_validate_mcast_bins(struct device *dev, int mcast_bins)
{
int x = mcast_bins;
@@ -74,8 +75,8 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
break;
default:
x = 0;
- pr_info("Hash table entries set to unexpected value %d",
- mcast_bins);
+ dev_warn(dev, "Hash table entries set to unexpected value %d\n",
+ mcast_bins);
break;
}
return x;
@@ -83,6 +84,7 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
/**
* dwmac1000_validate_ucast_entries - validate the Unicast address entries
+ * @dev: struct device of the platform device
* @ucast_entries: number of Unicast address entries
* Description:
* This function validates the number of Unicast address entries supported
@@ -92,7 +94,8 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
* selected, and defaults to 1 Unicast address if an unsupported
* configuration is selected.
*/
-static int dwmac1000_validate_ucast_entries(int ucast_entries)
+static int dwmac1000_validate_ucast_entries(struct device *dev,
+ int ucast_entries)
{
int x = ucast_entries;
@@ -104,8 +107,9 @@ static int dwmac1000_validate_ucast_entries(int ucast_entries)
break;
default:
x = 1;
- pr_info("Unicast table entries set to unexpected value %d\n",
- ucast_entries);
+ dev_warn(dev,
+ "Unicast table entries set to unexpected value %d\n",
+ ucast_entries);
break;
}
return x;
@@ -209,9 +213,9 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
of_property_read_u32(np, "snps,perfect-filter-entries",
&plat->unicast_filter_entries);
plat->unicast_filter_entries = dwmac1000_validate_ucast_entries(
- plat->unicast_filter_entries);
+ &pdev->dev, plat->unicast_filter_entries);
plat->multicast_filter_bins = dwmac1000_validate_mcast_bins(
- plat->multicast_filter_bins);
+ &pdev->dev, plat->multicast_filter_bins);
plat->has_gmac = 1;
plat->pmt = 1;
}
@@ -238,7 +242,8 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
if (plat->force_thresh_dma_mode) {
plat->force_sf_dma_mode = 0;
- pr_warn("force_sf_dma_mode is ignored if force_thresh_dma_mode is set.");
+ dev_warn(&pdev->dev,
+ "force_sf_dma_mode is ignored if force_thresh_dma_mode is set.\n");
}
return 0;
@@ -280,10 +285,8 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
plat_dat = devm_kzalloc(&pdev->dev,
sizeof(struct plat_stmmacenet_data),
GFP_KERNEL);
- if (!plat_dat) {
- pr_err("%s: ERROR: no memory", __func__);
+ if (!plat_dat)
return -ENOMEM;
- }
/* Set default value for multicast hash bins */
plat_dat->multicast_filter_bins = HASH_TABLE_SIZE;
@@ -294,7 +297,8 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
if (pdev->dev.of_node) {
ret = stmmac_probe_config_dt(pdev, plat_dat, &mac);
if (ret) {
- pr_err("%s: main dt probe failed", __func__);
+ dev_err(&pdev->dev, "%s: main dt probe failed\n",
+ __func__);
return ret;
}
}
@@ -313,9 +317,10 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
return ret;
}
- priv = stmmac_dvr_probe(&(pdev->dev), plat_dat, addr);
+ priv = stmmac_dvr_probe(&pdev->dev, plat_dat, addr);
if (IS_ERR(priv)) {
- pr_err("%s: main driver probe failed", __func__);
+ dev_err(&pdev->dev, "%s: main driver probe failed\n",
+ __func__);
return PTR_ERR(priv);
}
@@ -354,7 +359,7 @@ static int stmmac_pltfr_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv->dev);
- pr_debug("STMMAC platform driver registration completed");
+ dev_dbg(&pdev->dev, "STMMAC platform driver registration completed\n");
return 0;
}
--
2.1.3
^ permalink raw reply related
* Re: [Xen-devel] [PATCH] xen-netfront: Fix handling packets on compound pages with skb_linearize
From: Luis Henriques @ 2014-12-09 9:54 UTC (permalink / raw)
To: David Vrabel
Cc: Stefan Bader, Wei Liu, Ian Campbell, netdev, Kamal Mostafa,
linux-kernel, Paul Durrant, Zoltan Kiss, xen-devel,
Boris Ostrovsky
In-Reply-To: <54858753.1070801@citrix.com>
On Mon, Dec 08, 2014 at 11:11:15AM +0000, David Vrabel wrote:
> On 08/12/14 10:19, Luis Henriques wrote:
> > On Mon, Dec 01, 2014 at 09:55:24AM +0100, Stefan Bader wrote:
> >> On 11.08.2014 19:32, Zoltan Kiss wrote:
> >>> There is a long known problem with the netfront/netback interface: if the guest
> >>> tries to send a packet which constitues more than MAX_SKB_FRAGS + 1 ring slots,
> >>> it gets dropped. The reason is that netback maps these slots to a frag in the
> >>> frags array, which is limited by size. Having so many slots can occur since
> >>> compound pages were introduced, as the ring protocol slice them up into
> >>> individual (non-compound) page aligned slots. The theoretical worst case
> >>> scenario looks like this (note, skbs are limited to 64 Kb here):
> >>> linear buffer: at most PAGE_SIZE - 17 * 2 bytes, overlapping page boundary,
> >>> using 2 slots
> >>> first 15 frags: 1 + PAGE_SIZE + 1 bytes long, first and last bytes are at the
> >>> end and the beginning of a page, therefore they use 3 * 15 = 45 slots
> >>> last 2 frags: 1 + 1 bytes, overlapping page boundary, 2 * 2 = 4 slots
> >>> Although I don't think this 51 slots skb can really happen, we need a solution
> >>> which can deal with every scenario. In real life there is only a few slots
> >>> overdue, but usually it causes the TCP stream to be blocked, as the retry will
> >>> most likely have the same buffer layout.
> >>> This patch solves this problem by linearizing the packet. This is not the
> >>> fastest way, and it can fail much easier as it tries to allocate a big linear
> >>> area for the whole packet, but probably easier by an order of magnitude than
> >>> anything else. Probably this code path is not touched very frequently anyway.
> >>>
> >>> Signed-off-by: Zoltan Kiss <zoltan.kiss@citrix.com>
> >>> Cc: Wei Liu <wei.liu2@citrix.com>
> >>> Cc: Ian Campbell <Ian.Campbell@citrix.com>
> >>> Cc: Paul Durrant <paul.durrant@citrix.com>
> >>> Cc: netdev@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> Cc: xen-devel@lists.xenproject.org
> >>
> >> This does not seem to be marked explicitly as stable. Has someone already asked
> >> David Miller to put it on his stable queue? IMO it qualifies quite well and the
> >> actual change should be simple to pick/backport.
> >>
> >
> > Thank you Stefan, I'm queuing this for the next 3.16 kernel release.
>
> Don't backport this yes. It's broken. It produces malformed requests
> and netback will report a fatal error and stop all traffic on the VIF.
>
> David
Ok, thank you. I've dropped it already.
Cheers,
--
Luís
^ permalink raw reply
* Re: is the commit 571dcfde2371 (net-next) a proper fix?
From: Andy Shevchenko @ 2014-12-09 9:25 UTC (permalink / raw)
To: David Miller; +Cc: chenhc, peppe.cavallaro, netdev
In-Reply-To: <20141208.193532.411317230886917624.davem@davemloft.net>
On Mon, 2014-12-08 at 19:35 -0500, David Miller wrote:
> > It seems for me that commit 571dcfde2371 (stmmac: platform: fix default
> > values of the filter bins setting) is redundant (moreover, it could be a
> > cause of crash in some cases when there is no platform data defined in
> > case of CONFIG_OF).
> >
> > In case of no OF the platform data should be provided by platform code
> > where the defaults are set. What did I miss?
>
> You missed follow-up fix:
>
> commit 28603d13997e2ef47f18589cc9a44553aad49c86
> Author: Huacai Chen <chenhc@lemote.com>
> Date: Thu Nov 27 21:05:34 2014 +0800
>
> stmmac: platform: Move plat_dat checking earlier
Thanks, now it makes sense, indeed.
--
Andy Shevchenko <andriy.shevchenko@intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.12+
From: Thomas Jarosch @ 2014-12-09 8:54 UTC (permalink / raw)
To: Wolfgang Walter
Cc: Eric Dumazet, netdev, Eric Dumazet, Herbert Xu, Steffen Klassert
In-Reply-To: <5642727.qTG53DqrAk@h2o.as.studentenwerk.mhn.de>
On Monday, 8. December 2014 23:20:42 Wolfgang Walter wrote:
> Am Freitag, 5. Dezember 2014, 05:26:25 schrieb Eric Dumazet:
> > On Fri, 2014-12-05 at 13:09 +0100, Wolfgang Walter wrote:
> > > Hello,
> > >
> > > as reverting this patch fixes this rather annoying problem: is it
> > > dangerous to revert it as a workaround until the root cause is found?
> >
> > Unfortunately no, this patch fixes a serious issue.
> >
> > We need to find the root cause of your problem instead of trying to work
> > around it.
>
> I only wanted to use it as local workaround here.
>
>
> I looked a bit at at code. I'm not familiar with the network code, though
> :-).
If it helps, I'm running the reverted patch on five production boxes hitherto
without a hiccup. As far as I understood the original commit message,
some packet counters might me wrong without it.
@Eric: What could possibly go wrong(tm)? :)
Of course a real fix is preferred over this band-aid.
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH net-next v5 3/3] bridge: remove mode BRIDGE_MODE_SWDEV
From: Jiri Pirko @ 2014-12-09 7:56 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1418076261-24593-4-git-send-email-roopa@cumulusnetworks.com>
Mon, Dec 08, 2014 at 11:04:21PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This patch removes bridge mode swdev.
>Users can use BRIDGE_FLAGS_SELF to indicate swdev offload
>if needed.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Thanks Roopa for taking care of this!
>---
> include/uapi/linux/if_bridge.h | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
>index 05f0869..b03ee8f 100644
>--- a/include/uapi/linux/if_bridge.h
>+++ b/include/uapi/linux/if_bridge.h
>@@ -105,7 +105,6 @@ struct __fdb_entry {
>
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
>-#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
> #define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
>
> /* Bridge management nested attributes
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 2/3] rocker: remove swdev mode
From: Jiri Pirko @ 2014-12-09 7:55 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1418076261-24593-3-git-send-email-roopa@cumulusnetworks.com>
Mon, Dec 08, 2014 at 11:04:20PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>Remove use of 'swdev' mode in rocker. rocker dev offloads
>can use the BRIDGE_FLAGS_SELF to indicate offload to hardware.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>---
> drivers/net/ethernet/rocker/rocker.c | 18 +-----------------
> net/core/rtnetlink.c | 10 ++++++++--
> 2 files changed, 9 insertions(+), 19 deletions(-)
>
>diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>index fded127..a841f7a 100644
>--- a/drivers/net/ethernet/rocker/rocker.c
>+++ b/drivers/net/ethernet/rocker/rocker.c
>@@ -3700,27 +3700,11 @@ static int rocker_port_bridge_setlink(struct net_device *dev,
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
> struct nlattr *protinfo;
>- struct nlattr *afspec;
> struct nlattr *attr;
>- u16 mode;
> int err;
>
> protinfo = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg),
> IFLA_PROTINFO);
>- afspec = nlmsg_find_attr(nlh, sizeof(struct ifinfomsg), IFLA_AF_SPEC);
>-
>- if (afspec) {
>- attr = nla_find_nested(afspec, IFLA_BRIDGE_MODE);
>- if (attr) {
>- if (nla_len(attr) < sizeof(mode))
>- return -EINVAL;
>-
>- mode = nla_get_u16(attr);
>- if (mode != BRIDGE_MODE_SWDEV)
>- return -EINVAL;
>- }
>- }
>-
> if (protinfo) {
> attr = nla_find_nested(protinfo, IFLA_BRPORT_LEARNING);
> if (attr) {
>@@ -3755,7 +3739,7 @@ static int rocker_port_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> u32 filter_mask)
> {
> struct rocker_port *rocker_port = netdev_priv(dev);
>- u16 mode = BRIDGE_MODE_SWDEV;
>+ u16 mode = BRIDGE_MODE_UNDEF;
> u32 mask = BR_LEARNING | BR_LEARNING_SYNC;
>
> return ndo_dflt_bridge_getlink(skb, pid, seq, dev, mode,
>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>index 61cb7e7..3863e3b 100644
>--- a/net/core/rtnetlink.c
>+++ b/net/core/rtnetlink.c
>@@ -2734,11 +2734,17 @@ int ndo_dflt_bridge_getlink(struct sk_buff *skb, u32 pid, u32 seq,
> if (!br_afspec)
> goto nla_put_failure;
>
>- if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF) ||
>- nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
>+ if (nla_put_u16(skb, IFLA_BRIDGE_FLAGS, BRIDGE_FLAGS_SELF)) {
> nla_nest_cancel(skb, br_afspec);
> goto nla_put_failure;
> }
>+
>+ if (mode != BRIDGE_MODE_UNDEF) {
>+ if (nla_put_u16(skb, IFLA_BRIDGE_MODE, mode)) {
>+ nla_nest_cancel(skb, br_afspec);
>+ goto nla_put_failure;
>+ }
>+ }
> nla_nest_end(skb, br_afspec);
>
> protinfo = nla_nest_start(skb, IFLA_PROTINFO | NLA_F_NESTED);
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH net-next v5 1/3] bridge: new mode flag to indicate mode 'undefined'
From: Jiri Pirko @ 2014-12-09 7:54 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
vyasevic, netdev, davem, shm, gospo
In-Reply-To: <1418076261-24593-2-git-send-email-roopa@cumulusnetworks.com>
Mon, Dec 08, 2014 at 11:04:19PM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This patch adds mode BRIDGE_MODE_UNDEF for cases where mode is not needed.
>
>Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>
>---
> include/uapi/linux/if_bridge.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
>index 296a556..05f0869 100644
>--- a/include/uapi/linux/if_bridge.h
>+++ b/include/uapi/linux/if_bridge.h
>@@ -106,6 +106,7 @@ struct __fdb_entry {
> #define BRIDGE_MODE_VEB 0 /* Default loopback mode */
> #define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
> #define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
>+#define BRIDGE_MODE_UNDEF 0xFFFF /* mode undefined */
>
> /* Bridge management nested attributes
> * [IFLA_AF_SPEC] = {
>--
>1.7.10.4
>
^ permalink raw reply
* [PATCH net-next] tipc: avoid double lock 'spin_lock:&seq->lock'
From: Ying Xue @ 2014-12-09 7:17 UTC (permalink / raw)
To: davem; +Cc: jon.maloy, dan.carpenter, erik.hugne, netdev, tipc-discussion
The commit fb9962f3cefe ("tipc: ensure all name sequences are properly
protected with its lock") involves below errors:
net/tipc/name_table.c:980 tipc_purge_publications() error: double lock 'spin_lock:&seq->lock'
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/name_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index aafa684c..c8df022 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -979,7 +979,7 @@ static void tipc_purge_publications(struct name_seq *seq)
}
hlist_del_init_rcu(&seq->ns_list);
kfree(seq->sseqs);
- spin_lock_bh(&seq->lock);
+ spin_unlock_bh(&seq->lock);
kfree_rcu(seq, rcu);
}
--
1.7.9.5
^ permalink raw reply related
* RE: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
From: Yuval Mintz @ 2014-12-09 7:07 UTC (permalink / raw)
To: Eli Cohen
Cc: bhelgaas@google.com, David Miller, linux-pci, netdev,
ogerlitz@mellanox.com, yevgenyp@mellanox.com, Donald Dutile
In-Reply-To: <20141209064339.GA1806@mtldesk30>
[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]
> > >Currently the kerenl will call probe for any device for which there
> > >is a supporting driver and I did not want to change that.
> >
> > But what's next? How will this feature be activated?
> >
> > Adding a parameter to pci_enable_sriov() might give developers the
> > false impression they can change behavior by passing `0' to this
> > function; But that shouldn't be the method to control this - we should
> > have uniform control of the feature across different drivers, e.g., by an
> additional sysfs node.
>
> I was planning on using this on mlx5 SRIOV support which is not available
> upstream yet. So this could be a driver developer's decision how to use this.
I think it shouldn't - from user perspective, you can't have such fundamental
difference between different drivers - that enabling sriov on one device would
create VFs in the hypervisors and another one won't.
> I think adding another sysfs entry to control this behavior is unnecessary since the
> administrator has the freedom to later do any bidnings he wishes to do.
>
> Keeping things as they are today is not so "nice". I mean, I could fail probe for
> VFs to avoid them from being initialized at the hypervisor but there are other
> questions: which error should I return and how can I be sure how the bus driver
> will refer to such failures.
Again - you could say that this is solely in your drivers decision-making-area,
but failing the VF probe would lead to the same difference between drivers I've
stated before.
> So, maybe the solution I suggested is not the best one but do we agree that this
> needs to be addressed this way or another?
All-in-all, I agree. But I think the solution should be user-controlled and not driver-based.
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 5068 bytes --]
^ permalink raw reply
* Antw: Re: Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-09 7:01 UTC (permalink / raw)
To: phil; +Cc: netdev
In-Reply-To: <1418056540.384.5.camel@niobium.home.fifi.org>
>>> Philippe Troin <phil@fifi.org> schrieb am 08.12.2014 um 17:35 in Nachricht
<1418056540.384.5.camel@niobium.home.fifi.org>:
> On Mon, 2014-12-08 at 13:51 +0100, Ulrich Windl wrote:
>> (not subscribed to the list, plese keep me on CC:)
>>
>> I have a problem I could not find the answer. I suspect the problem
>> arises from Linux derivating from standard functionality...
>>
>> I have written a server that should accept n TCP connections at most.
>> I was expecting that the backlog parameter of listen will cause extra
>> connection requests either
>> 1) to be refused
>> or
>> 2) to time out eventually
>>
>> (The standard seems to say that extra connections are refused)
>
> The argument to listen() specifies how many connections the system is
> allow to keep waiting to be accept()ed.
> As soon as you accept() the connection, the count is decremented.
> So that won't help for your use case.
>
>> However none of the above see ms true. Even if my server delays
>> accept()ing new connections, no client ever sees a "connection
>> refused" or "connection timed out". Is there any chance to signal the
>> client that no more connections are accepted at the moment?
>
> Close the listening socket. No new connections will be accepted.
> When you reopen the socket for accepting new connections, you may have
> to use SO_REUSEADDR before bind()ing to the port.
This is what I had done, but those connections who are waiting to be accepted: If I close the listening socket, will the clients see a connection abort, or will they see a connection refused?
Connection aborts could confuse clients.
Ulrich
^ permalink raw reply
* Re: [patch v2] ipvs: uninitialized data with IP_VS_IPV6
From: Dan Carpenter @ 2014-12-09 6:49 UTC (permalink / raw)
To: Simon Horman
Cc: Julian Anastasov, Wensong Zhang, Pablo Neira Ayuso,
Patrick McHardy, Jozsef Kadlecsik, David S. Miller, netdev,
lvs-devel, netfilter-devel, coreteam, kernel-janitors
In-Reply-To: <20141209005215.GH8897@verge.net.au>
On Tue, Dec 09, 2014 at 09:52:15AM +0900, Simon Horman wrote:
> On Sun, Dec 07, 2014 at 08:39:35PM +0200, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Sat, 6 Dec 2014, Dan Carpenter wrote:
> >
> > > The app_tcp_pkt_out() function expects "*diff" to be set and ends up
> > > using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.
> > >
> > > The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
> > > for noticing that.
> > >
> > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > ---
> > > v2: fix app_tcp_pkt_in() as well. This is an old bug.
> >
> > Thanks! It will not break seqs for IPv6 control
> > connection, only that we do not support FTP yet :( I have
> > the doubt whether this should be classified as bugfix :)
> > I guess, it is a net-next material, right?
>
> Agreed, I have queued it up in ipvs-next.
> I'll send a pull request to Pablo if Dan doesn't object
> to it going there.
No objections from me.
regards,
dan carpenter
^ permalink raw reply
* Re: Possible regression: "gre: Use inner mac length when computing tunnel length"
From: Timo Teras @ 2014-12-09 6:44 UTC (permalink / raw)
To: Tom Herbert; +Cc: Alexander Duyck, Linux Netdev List
In-Reply-To: <20141209082645.5cf70f55@vostro>
On Tue, 9 Dec 2014 08:26:45 +0200
Timo Teras <timo.teras@iki.fi> wrote:
> On Thu, 4 Dec 2014 08:00:19 -0800
> Tom Herbert <therbert@google.com> wrote:
>
> > A fix is pending for net. Please try if you can.
>
> Finally got to testing this. Unfortunately, this does not seem to fix
> the issue I am experiencing.
>
> Any suggestions?
I think this fix is required, but does not fix the issue.
I suspect my problem is with the fact that I have NBMA GRE tunnel.
In ipgre_xmit() it is gre_handle_offloads() that is called first.
However, in my case, the GRE header was already pushed earlier via
header_ops. That's why the packet is skb_pull()'ed in the
"if (dev->header_ops)" path, so that __gre_xmit can push back the
header again on it.
I wonder if it is correct to just move the gre_handle_offloads() call
after the if() block, or if additional fixing is needed to make
offloads work with nbma tunnels.
/Timo
^ permalink raw reply
* Re: [PATCH RFC] pci: Control whether VFs are probed on pci_enable_sriov
From: Eli Cohen @ 2014-12-09 6:43 UTC (permalink / raw)
To: Yuval Mintz
Cc: Eli Cohen, bhelgaas@google.com, David Miller, linux-pci, netdev,
ogerlitz@mellanox.com, yevgenyp@mellanox.com, Donald Dutile
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63BA7746@avmb3.qlogic.org>
On Mon, Dec 08, 2014 at 07:25:24PM +0000, Yuval Mintz wrote:
>
> >Currently the kerenl will call probe for any device for which there is
> >a supporting driver and I did not want to change that.
>
> But what's next? How will this feature be activated?
>
> Adding a parameter to pci_enable_sriov() might give developers the false
> impression they can change behavior by passing `0' to this function;
> But that shouldn't be the method to control this - we should have uniform
> control of the feature across different drivers, e.g., by an additional sysfs node.
I was planning on using this on mlx5 SRIOV support which is not
available upstream yet. So this could be a driver developer's decision
how to use this. I think adding another sysfs entry to control this
behavior is unnecessary since the administrator has the freedom to
later do any bidnings he wishes to do.
Keeping things as they are today is not so "nice". I mean, I could
fail probe for VFs to avoid them from being initialized at the
hypervisor but there are other questions: which error should I return
and how can I be sure how the bus driver will refer to such failures.
So, maybe the solution I suggested is not the best one but do we agree
that this needs to be addressed this way or another?
^ permalink raw reply
* Re: Possible regression: "gre: Use inner mac length when computing tunnel length"
From: Timo Teras @ 2014-12-09 6:26 UTC (permalink / raw)
To: Tom Herbert; +Cc: Alexander Duyck, Linux Netdev List
In-Reply-To: <CA+mtBx-se+u4j8WHzZ+AXeiFN2uevrvcTb6xFpeNrhjOv=EVng@mail.gmail.com>
On Thu, 4 Dec 2014 08:00:19 -0800
Tom Herbert <therbert@google.com> wrote:
> A fix is pending for net. Please try if you can.
Finally got to testing this. Unfortunately, this does not seem to fix
the issue I am experiencing.
Any suggestions?
>
> Tom
>
> diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
> index bb5947b..51973dd 100644
> --- a/net/ipv4/gre_offload.c
> +++ b/net/ipv4/gre_offload.c
> @@ -247,6 +247,9 @@ static int gre_gro_complete(struct sk_buff *skb,
> int nhoff) err = ptype->callbacks.gro_complete(skb, nhoff + grehlen);
>
> rcu_read_unlock();
> +
> + skb_set_inner_mac_header(skb, nhoff + grehlen);
> +
> return err;
> }
>
> On Thu, Dec 4, 2014 at 4:16 AM, Timo Teras <timo.teras@iki.fi> wrote:
> > Hi,
> >
> > After upgrading to latest 3.14.24 or newer, I noticed a weird TSO
> > bug in the "dmvpn" setup I use. And seems 3.14.23 works just fine.
> > So the commit 14051f0452a2c26a "gre: Use inner mac length when
> > computing tunnel length" would appear to be the related commit (but
> > have not yet tested this).
> >
> > In practice what happens is that forwarding path between ethX (or
> > vlanX) and gre1 gets broken.
> >
> > There's probably two differences to the "regular" gre tunnel case:
> > - it's nbma mode, meaning the gre header is inserted via slightly
> > different code path
> > - the gre1 packets are IPsec encrypted in transport mode
> >
> > As additional detail, doing "ethtool -K gre1 tso off" will
> > workaround the issue, so it is clearly tso issue pointing even
> > further to the commit in question.
> >
> > Is this something the suspected patch could cause? Any suggestions
> > what to test more?
> >
> > Thanks,
> > Timo
> >
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Marcel Holtmann @ 2014-12-09 5:25 UTC (permalink / raw)
To: Pali Rohár
Cc: Greg Kroah-Hartman, Ming Lei, Pavel Machek, John W. Linville,
Grazvydas Ignotas, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List, Ivaylo Dimitrov,
Aaro Koskinen, Kalle Valo, Sebastian Reichel, David Gnedt
In-Reply-To: <201412090027.46485@pali>
Hi Pali,
>> Use your own custom usermode helper for stuff like this, not
>> the firmware interface. But use a binary sysfs file if you
>> want, that seems to make sense for it...
>>
>> greg k-h
>
> Patch for telling permanent mac address from userspace via sysfs
> file was rejected for inclusion into mainline kernel.
>
> So I do not think that now maintainers of network subsystem allow
> it for nvs data...
>
> https://lkml.org/lkml/2013/12/8/35
this magic sysfs that has to be written to at the right time of the boot process to make this all work is something that will not work. I does not work for WiFi and it does not work for Bluetooth. Seems the discussion come full circle now and we are back to square one.
The problem is that either the driver does not register the device with mac80211 until it gets the MAC address provided by userspace or mac80211 should get an unconfigured state. The unconfigured state is something telling userspace that the device is present, but needs a few extra configuration information before it can become useful.
For Bluetooth, I went the later route. Mainly because the missing address is such a generic problem that solving it in the core makes a lot more sense. The driver just tells the core that it has no address for this device and provides a custom callback to configure the address when provided. After that everything resumes as normal.
However userspace gets informed when an unconfigured device gets added and at boot it can just query the list of unconfigured devices, or at runtime wait to be told there is a new unconfigured device that needs its attention. And then just provide the information. Once all information are present, the devices disappears as unconfigured and shows up as configured device ready for normal operation.
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/mgmt-api.txt#n2006
http://permalink.gmane.org/gmane.linux.bluez.kernel/50716
Can something similar be added to cfg80211 + nl80211. It bet it can, but that is up to Johannes to decide and someone to actually do the work and implement it.
Regards
Marcel
^ permalink raw reply
* Re: wl1251: NVS firmware data
From: Marcel Holtmann @ 2014-12-09 5:10 UTC (permalink / raw)
To: Dan Williams
Cc: Ivaylo Dimitrov, Pali Rohár, Greg Kroah-Hartman, Ming Lei,
Pavel Machek, John W. Linville, Grazvydas Ignotas,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List, Aaro Koskinen, Kalle Valo,
Sebastian Reichel, David Gnedt
In-Reply-To: <1418078493.31640.4.camel@dcbw.local>
Hi Dan,
>>> a) change driver to prefer a new "wl1251-nvs-n900.bin" file, but fall
>>> back to "wl1251-nvs.bin" if the first one isn't present
>>> b) have a "wl1251-cal-nvs-update" service that, if wl1521-nvs-n900.bin
>>> is *not* present mounts the CAL MTD, reads the data, writes it out into
>>> wl1521-nvs-n900.bin, and the rmmod/modprobes the driver
>>>
>>> and done? Stuff that's not N900 just wouldn't ship the update service
>>> and would proceed like none of this happened.
>>>
>>> Dan
>>>
>>>
>>
>> That would mean that the driver should not be built-in, as afaik we
>> cannot rmmod built-in drivers. Sure, it will work after a reboot, but
>> this is a bit hacky, agree?
>>
>> Also, new NVS file needs to be loaded when fcc regulation changes(flying
>> abroad), so that would mean that the device would be outside of those
>> until reboot (in case of built-in driver)
>
> Regulatory stuff needs to be hooked into CRDA or the existing regulatory
> codepaths, not some other path. So when cfg80211 sets the regulatory
> domain on the driver the driver needs to get the necessary NVS data.
> Either the NVS for every domain (which cannot be a lot of them) gets
> hardcoded into the driver, and then selected based on what cfg80211
> says, or the driver needs to ask userspace for the NVS data based on
> what cfg80211 says. In all cases, cfg80211 drives the regulatory domain
> [1].
>
> a) How many regulatory domains does the driver support, how much data is
> there for each domain, and can that be put into the driver instead of
> getting it from the CAL partition?
>
> b) what do *other* (non-N900) wl1251 devices do for regulatory data?
>
> Dan
>
> [1] unless there's some *restriction* hardcoded into the EEPROM of the
> device, which in the case of the N900 there isn't, since the regulatory
> data changes based on the MCC/MNC of the cellular side.
and even these ones would all work just fine. The regulatory handling of cfg80211 is already multi-layer anyway. I will intersect from the driver provided information and userspace provided information.
I mean if userspace can just make up some NVS data to change the regulatory enforcement or let cfg80211 do it for you, there is no difference. So the real question is why bother with this at all in the first place. We already have a solution that does exactly what you want. Use CRDA and be done with it.
And calibration data should be rather static for each device. It might differ from device a to device b, but on device a it would stay the same. These calibration data are normally programmed at the factory line and then never changed again.
For me this sounds all a bit like that everybody is buying into this NVS file solution for everything and now trying to hack that into something workable. But nobody actually looks at the existing solutions out there and really tries to fix the mess that Nokia and TI left behind for this chipset.
Regards
Marcel
^ permalink raw reply
* RE: TO WHOM IT MAY CONCERN!!!
From: Mr. Stephen Odufore @ 2014-12-09 11:44 UTC (permalink / raw)
Hello
My Name is Mr. Stephen Odufore, A staff of Sunrise Bank Team, and an account officer to Engineer Shang Lee Sukchai(Late) It might interest you to know that engineer Shang Lee Sukchai is a Gold Merchant here in Ghana and he deposited a large sum of money with Sunrise Bank Team (Ghana).
On one faithful Wednesday, 7 November 2012, We received a shocking news that Melcom building at Achimota-Accra COLLAPSED and that 78 persons were rescued from the rubble. Out of this figure ten persons are reported DEAD, 14 on admission at 37 Military Hospital as well as Achimota, and the Korle-Bu Teaching Hospitals. for more information visit the TWO links below:
http://edition.myjoyonline.com/pages/news/201211/96847.php
http://edition.myjoyonline.com/pages/news/201211/96960.php
Based on the information reaching us, Engineer Shang Lee Sukchai with his house hold (Wife, son and 2 daughters) died in the accident and left this large sum of money behind. Apparently, the management are seriously searching for any of his relative to claim this money so I want you to stand as a relative to the decease and once the funds are paid to you, I will visit you in your country so we can share the money.
I can assure you that this deal is 100% risk-free, and if you follow my advice we will succeed within the shortest possible time. All I need is your assurance that you are solvent and capable of handling a transaction of this magnitude, and that our share of the money will be safe with you.
The money is going to be shared among THREE parties and it's going to be in this way, 10% of the money will go to the orphanage in your country, another 10% to the widow and widowers association, 30% for your good work and cooperation whilst the remaining 50% goes to me and my colleague who is in support of this transaction.
If you are interested in this business, then send your Full name, House address, direct contact number for easy communication. Remember, this transaction most be kept strictly Confidential hence my job will e astake
Yours Faithfully
Mr. Stephen Odufore
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox