* [PATCH net-next 1/5] qlcnic: detect fan failure
From: Sony Chacko @ 2011-08-29 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sony Chacko
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 1 -
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h | 4 ++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 29 ++++++++++++++++---
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 7c64f2f..59d73f2 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -832,7 +832,6 @@ qlcnic_diag_test(struct net_device *dev, struct ethtool_test *eth_test,
data[3] = qlcnic_loopback_test(dev, QLCNIC_ILB_MODE);
if (data[3])
eth_test->flags |= ETH_TEST_FL_FAILED;
-
if (eth_test->flags & ETH_TEST_FL_EXTERNAL_LB) {
data[4] = qlcnic_loopback_test(dev, QLCNIC_ELB_MODE);
if (data[4])
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
index d14506f..92bc8ce 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hdr.h
@@ -609,6 +609,7 @@ enum {
QLCNIC_TEMP_PANIC /* Fatal error, hardware has shut down. */
};
+
/* Lock IDs for PHY lock */
#define PHY_LOCK_DRIVER 0x44524956
@@ -723,7 +724,8 @@ enum {
#define QLCNIC_RCODE_DRIVER_CAN_RELOAD BIT_30
#define QLCNIC_RCODE_FATAL_ERROR BIT_31
#define QLCNIC_FWERROR_PEGNUM(code) ((code) & 0xff)
-#define QLCNIC_FWERROR_CODE(code) ((code >> 8) & 0xfffff)
+#define QLCNIC_FWERROR_CODE(code) ((code >> 8) & 0x1fffff)
+#define QLCNIC_FWERROR_FAN_FAILURE 0x16
#define FW_POLL_DELAY (1 * HZ)
#define FW_FAIL_THRESH 2
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index b447cc5..998bb1d 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -2928,15 +2928,36 @@ qlcnic_detach_work(struct work_struct *work)
status = QLCRD32(adapter, QLCNIC_PEG_HALT_STATUS1);
- if (status & QLCNIC_RCODE_FATAL_ERROR)
+ if (status & QLCNIC_RCODE_FATAL_ERROR) {
+ dev_err(&adapter->pdev->dev,
+ "Detaching the device: peg halt status1=0x%x\n",
+ status);
+
+ if (QLCNIC_FWERROR_CODE(status) == QLCNIC_FWERROR_FAN_FAILURE) {
+ dev_err(&adapter->pdev->dev,
+ "On board active cooling fan failed. "
+ "Device has been halted.\n");
+ dev_err(&adapter->pdev->dev,
+ "Replace the adapter.\n");
+ }
+
goto err_ret;
+ }
- if (adapter->temp == QLCNIC_TEMP_PANIC)
+ if (adapter->temp == QLCNIC_TEMP_PANIC) {
+ dev_err(&adapter->pdev->dev, "Detaching the device: temp=%d\n",
+ adapter->temp);
goto err_ret;
+ }
+
/* Dont ack if this instance is the reset owner */
if (!(adapter->flags & QLCNIC_FW_RESET_OWNER)) {
- if (qlcnic_set_drv_state(adapter, adapter->dev_state))
+ if (qlcnic_set_drv_state(adapter, adapter->dev_state)) {
+ dev_err(&adapter->pdev->dev,
+ "Failed to set driver state,"
+ "detaching the device.\n");
goto err_ret;
+ }
}
adapter->fw_wait_cnt = 0;
@@ -2946,8 +2967,6 @@ qlcnic_detach_work(struct work_struct *work)
return;
err_ret:
- dev_err(&adapter->pdev->dev, "detach failed; status=%d temp=%d\n",
- status, adapter->temp);
netif_device_attach(netdev);
qlcnic_clr_all_drv_state(adapter, 1);
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH net-next 4/5] qlcnic: fix cdrp race condition
From: Sony Chacko @ 2011-08-29 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sritej Velaga
In-Reply-To: <1314658231-30735-1-git-send-email-sony.chacko@qlogic.com>
From: Sritej Velaga <sritej.velaga@qlogic.com>
Reading CRB registers(if reqd) before releasing the api lock.
Signed-off-by: Sritej Velaga <sritej.velaga@qlogic.com>
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 3 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 116 +++++++++++++++-----
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 4 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 4 +-
4 files changed, 95 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 4118502..2a3e552 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -1465,7 +1465,8 @@ int qlcnic_check_loopback_buff(unsigned char *data, u8 mac[]);
/* Functions from qlcnic_main.c */
int qlcnic_reset_context(struct qlcnic_adapter *);
u32 qlcnic_issue_cmd(struct qlcnic_adapter *adapter,
- u32 pci_fn, u32 version, u32 arg1, u32 arg2, u32 arg3, u32 cmd);
+ u32 pci_fn, u32 version, u32 arg1, u32 arg2, u32 arg3, u32 cmd,
+ u32 *rd_args[3]);
void qlcnic_diag_free_res(struct net_device *netdev, int max_sds_rings);
int qlcnic_diag_alloc_res(struct net_device *netdev, int test);
netdev_tx_t qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index b0d32dd..e0c85a5 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -28,7 +28,8 @@ qlcnic_poll_rsp(struct qlcnic_adapter *adapter)
u32
qlcnic_issue_cmd(struct qlcnic_adapter *adapter,
- u32 pci_fn, u32 version, u32 arg1, u32 arg2, u32 arg3, u32 cmd)
+ u32 pci_fn, u32 version, u32 arg1, u32 arg2, u32 arg3, u32 cmd,
+ u32 *rd_args[3])
{
u32 rsp;
u32 signature;
@@ -56,7 +57,14 @@ qlcnic_issue_cmd(struct qlcnic_adapter *adapter,
rcode = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
dev_err(&pdev->dev, "failed card response code:0x%x\n",
rcode);
+ } else if (rsp == QLCNIC_CDRP_RSP_OK) {
+ if (rd_args[1])
+ *rd_args[1] = QLCRD32(adapter, QLCNIC_ARG2_CRB_OFFSET);
+ if (rd_args[2])
+ *rd_args[2] = QLCRD32(adapter, QLCNIC_ARG3_CRB_OFFSET);
}
+ if (rd_args[0])
+ *rd_args[0] = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
/* Release semaphore */
qlcnic_api_unlock(adapter);
@@ -80,28 +88,30 @@ int qlcnic_fw_cmd_get_minidump_temp(struct qlcnic_adapter *adapter)
int err, i;
u16 temp_size;
void *tmp_addr;
- u32 version, csum, *template, *tmp_buf;
+ u32 version, csum, *template, *tmp_buf, rsp;
+ u32 *rd_args[3];
struct qlcnic_hardware_context *ahw;
struct qlcnic_dump_template_hdr *tmpl_hdr, *tmp_tmpl;
dma_addr_t tmp_addr_t = 0;
ahw = adapter->ahw;
+ rd_args[0] = &rsp;
+ rd_args[1] = (u32 *) &temp_size;
+ rd_args[2] = &version;
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
0,
0,
0,
- QLCNIC_CDRP_CMD_TEMP_SIZE);
+ QLCNIC_CDRP_CMD_TEMP_SIZE,
+ rd_args);
if (err != QLCNIC_RCODE_SUCCESS) {
- err = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
dev_info(&adapter->pdev->dev,
- "Can't get template size %d\n", err);
+ "Can't get template size %d\n", rsp);
err = -EIO;
return err;
}
- version = QLCRD32(adapter, QLCNIC_ARG3_CRB_OFFSET);
- temp_size = QLCRD32(adapter, QLCNIC_ARG2_CRB_OFFSET);
if (!temp_size)
return -EIO;
@@ -112,13 +122,15 @@ int qlcnic_fw_cmd_get_minidump_temp(struct qlcnic_adapter *adapter)
"Can't get memory for FW dump template\n");
return -ENOMEM;
}
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
LSD(tmp_addr_t),
MSD(tmp_addr_t),
temp_size,
- QLCNIC_CDRP_CMD_GET_TEMP_HDR);
+ QLCNIC_CDRP_CMD_GET_TEMP_HDR,
+ rd_args);
if (err != QLCNIC_RCODE_SUCCESS) {
dev_err(&adapter->pdev->dev,
@@ -155,8 +167,10 @@ error:
int
qlcnic_fw_cmd_set_mtu(struct qlcnic_adapter *adapter, int mtu)
{
+ u32 *rd_args[3];
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
+ memset(rd_args, 0, sizeof(rd_args));
if (recv_ctx->state == QLCNIC_HOST_CTX_STATE_ACTIVE) {
if (qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
@@ -164,7 +178,8 @@ qlcnic_fw_cmd_set_mtu(struct qlcnic_adapter *adapter, int mtu)
recv_ctx->context_id,
mtu,
0,
- QLCNIC_CDRP_CMD_SET_MTU)) {
+ QLCNIC_CDRP_CMD_SET_MTU,
+ rd_args)) {
dev_err(&adapter->pdev->dev, "Failed to set mtu\n");
return -EIO;
@@ -193,6 +208,7 @@ qlcnic_fw_cmd_create_rx_ctx(struct qlcnic_adapter *adapter)
u8 i, nrds_rings, nsds_rings;
size_t rq_size, rsp_size;
u32 cap, reg, val, reg2;
+ u32 *rd_args[3];
int err;
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
@@ -274,13 +290,15 @@ qlcnic_fw_cmd_create_rx_ctx(struct qlcnic_adapter *adapter)
}
phys_addr = hostrq_phys_addr;
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
(u32)(phys_addr >> 32),
(u32)(phys_addr & 0xffffffff),
rq_size,
- QLCNIC_CDRP_CMD_CREATE_RX_CTX);
+ QLCNIC_CDRP_CMD_CREATE_RX_CTX,
+ rd_args);
if (err) {
dev_err(&adapter->pdev->dev,
"Failed to create rx ctx in firmware%d\n", err);
@@ -326,15 +344,18 @@ out_free_rq:
static void
qlcnic_fw_cmd_destroy_rx_ctx(struct qlcnic_adapter *adapter)
{
+ u32 *rd_args[3];
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
+ memset(rd_args, 0, sizeof(rd_args));
if (qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
recv_ctx->context_id,
QLCNIC_DESTROY_CTX_RESET,
0,
- QLCNIC_CDRP_CMD_DESTROY_RX_CTX)) {
+ QLCNIC_CDRP_CMD_DESTROY_RX_CTX,
+ rd_args)) {
dev_err(&adapter->pdev->dev,
"Failed to destroy rx ctx in firmware\n");
@@ -352,6 +373,7 @@ qlcnic_fw_cmd_create_tx_ctx(struct qlcnic_adapter *adapter)
void *rq_addr, *rsp_addr;
size_t rq_size, rsp_size;
u32 temp;
+ u32 *rd_args[3];
int err;
u64 phys_addr;
dma_addr_t rq_phys_addr, rsp_phys_addr;
@@ -401,13 +423,15 @@ qlcnic_fw_cmd_create_tx_ctx(struct qlcnic_adapter *adapter)
prq_cds->ring_size = cpu_to_le32(tx_ring->num_desc);
phys_addr = rq_phys_addr;
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
(u32)(phys_addr >> 32),
((u32)phys_addr & 0xffffffff),
rq_size,
- QLCNIC_CDRP_CMD_CREATE_TX_CTX);
+ QLCNIC_CDRP_CMD_CREATE_TX_CTX,
+ rd_args);
if (err == QLCNIC_RCODE_SUCCESS) {
temp = le32_to_cpu(prsp->cds_ring.host_producer_crb);
@@ -433,13 +457,17 @@ out_free_rq:
static void
qlcnic_fw_cmd_destroy_tx_ctx(struct qlcnic_adapter *adapter)
{
+ u32 *rd_args[3];
+
+ memset(rd_args, 0, sizeof(rd_args));
if (qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
adapter->tx_context_id,
QLCNIC_DESTROY_CTX_RESET,
0,
- QLCNIC_CDRP_CMD_DESTROY_TX_CTX)) {
+ QLCNIC_CDRP_CMD_DESTROY_TX_CTX,
+ rd_args)) {
dev_err(&adapter->pdev->dev,
"Failed to destroy tx ctx in firmware\n");
@@ -449,13 +477,17 @@ qlcnic_fw_cmd_destroy_tx_ctx(struct qlcnic_adapter *adapter)
int
qlcnic_fw_cmd_set_port(struct qlcnic_adapter *adapter, u32 config)
{
+ u32 *rd_args[3];
+
+ memset(rd_args, 0, sizeof(rd_args));
return qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
config,
0,
0,
- QLCNIC_CDRP_CMD_CONFIG_PORT);
+ QLCNIC_CDRP_CMD_CONFIG_PORT,
+ rd_args);
}
int qlcnic_alloc_hw_resources(struct qlcnic_adapter *adapter)
@@ -620,20 +652,24 @@ void qlcnic_free_hw_resources(struct qlcnic_adapter *adapter)
int qlcnic_get_mac_address(struct qlcnic_adapter *adapter, u8 *mac)
{
int err;
- u32 arg1;
+ u32 arg1, rd_arg1, rd_arg2;
+ u32 *rd_args[3];
arg1 = adapter->ahw->pci_func | BIT_8;
+ rd_args[0] = &rd_arg1;
+ rd_args[1] = &rd_arg2;
+ rd_args[2] = 0;
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
arg1,
0,
0,
- QLCNIC_CDRP_CMD_MAC_ADDRESS);
+ QLCNIC_CDRP_CMD_MAC_ADDRESS,
+ rd_args);
if (err == QLCNIC_RCODE_SUCCESS)
- qlcnic_fetch_mac(adapter, QLCNIC_ARG1_CRB_OFFSET,
- QLCNIC_ARG2_CRB_OFFSET, 0, mac);
+ qlcnic_fetch_mac(adapter, rd_arg1, rd_arg2, 0, mac);
else {
dev_err(&adapter->pdev->dev,
"Failed to get mac address%d\n", err);
@@ -651,6 +687,7 @@ int qlcnic_get_nic_info(struct qlcnic_adapter *adapter,
dma_addr_t nic_dma_t;
struct qlcnic_info *nic_info;
void *nic_info_addr;
+ u32 *rd_args[3];
size_t nic_size = sizeof(struct qlcnic_info);
nic_info_addr = dma_alloc_coherent(&adapter->pdev->dev, nic_size,
@@ -660,13 +697,15 @@ int qlcnic_get_nic_info(struct qlcnic_adapter *adapter,
memset(nic_info_addr, 0, nic_size);
nic_info = nic_info_addr;
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
MSD(nic_dma_t),
LSD(nic_dma_t),
(func_id << 16 | nic_size),
- QLCNIC_CDRP_CMD_GET_NIC_INFO);
+ QLCNIC_CDRP_CMD_GET_NIC_INFO,
+ rd_args);
if (err == QLCNIC_RCODE_SUCCESS) {
npar_info->pci_func = le16_to_cpu(nic_info->pci_func);
@@ -705,6 +744,7 @@ int qlcnic_set_nic_info(struct qlcnic_adapter *adapter, struct qlcnic_info *nic)
int err = -EIO;
dma_addr_t nic_dma_t;
void *nic_info_addr;
+ u32 *rd_args[3];
struct qlcnic_info *nic_info;
size_t nic_size = sizeof(struct qlcnic_info);
@@ -730,13 +770,15 @@ int qlcnic_set_nic_info(struct qlcnic_adapter *adapter, struct qlcnic_info *nic)
nic_info->min_tx_bw = cpu_to_le16(nic->min_tx_bw);
nic_info->max_tx_bw = cpu_to_le16(nic->max_tx_bw);
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
MSD(nic_dma_t),
LSD(nic_dma_t),
((nic->pci_func << 16) | nic_size),
- QLCNIC_CDRP_CMD_SET_NIC_INFO);
+ QLCNIC_CDRP_CMD_SET_NIC_INFO,
+ rd_args);
if (err != QLCNIC_RCODE_SUCCESS) {
dev_err(&adapter->pdev->dev,
@@ -754,6 +796,7 @@ int qlcnic_get_pci_info(struct qlcnic_adapter *adapter,
struct qlcnic_pci_info *pci_info)
{
int err = 0, i;
+ u32 *rd_args[3];
dma_addr_t pci_info_dma_t;
struct qlcnic_pci_info *npar;
void *pci_info_addr;
@@ -767,13 +810,15 @@ int qlcnic_get_pci_info(struct qlcnic_adapter *adapter,
memset(pci_info_addr, 0, pci_size);
npar = pci_info_addr;
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
MSD(pci_info_dma_t),
LSD(pci_info_dma_t),
pci_size,
- QLCNIC_CDRP_CMD_GET_PCI_INFO);
+ QLCNIC_CDRP_CMD_GET_PCI_INFO,
+ rd_args);
if (err == QLCNIC_RCODE_SUCCESS) {
for (i = 0; i < QLCNIC_MAX_PCI_FUNC; i++, npar++, pci_info++) {
@@ -805,6 +850,7 @@ int qlcnic_config_port_mirroring(struct qlcnic_adapter *adapter, u8 id,
{
int err = -EIO;
u32 arg1;
+ u32 *rd_args[3];
if (adapter->op_mode != QLCNIC_MGMT_FUNC ||
!(adapter->eswitch[id].flags & QLCNIC_SWITCH_ENABLE))
@@ -813,13 +859,15 @@ int qlcnic_config_port_mirroring(struct qlcnic_adapter *adapter, u8 id,
arg1 = id | (enable_mirroring ? BIT_4 : 0);
arg1 |= pci_func << 8;
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
arg1,
0,
0,
- QLCNIC_CDRP_CMD_SET_PORTMIRRORING);
+ QLCNIC_CDRP_CMD_SET_PORTMIRRORING,
+ rd_args);
if (err != QLCNIC_RCODE_SUCCESS) {
dev_err(&adapter->pdev->dev,
@@ -842,6 +890,7 @@ int qlcnic_get_port_stats(struct qlcnic_adapter *adapter, const u8 func,
dma_addr_t stats_dma_t;
void *stats_addr;
u32 arg1;
+ u32 *rd_args[3];
int err;
if (esw_stats == NULL)
@@ -865,13 +914,15 @@ int qlcnic_get_port_stats(struct qlcnic_adapter *adapter, const u8 func,
arg1 = func | QLCNIC_STATS_VERSION << 8 | QLCNIC_STATS_PORT << 12;
arg1 |= rx_tx << 15 | stats_size << 16;
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
arg1,
MSD(stats_dma_t),
LSD(stats_dma_t),
- QLCNIC_CDRP_CMD_GET_ESWITCH_STATS);
+ QLCNIC_CDRP_CMD_GET_ESWITCH_STATS,
+ rd_args);
if (!err) {
stats = stats_addr;
@@ -952,6 +1003,7 @@ int qlcnic_clear_esw_stats(struct qlcnic_adapter *adapter, const u8 func_esw,
{
u32 arg1;
+ u32 *rd_args[3];
if (adapter->op_mode != QLCNIC_MGMT_FUNC)
return -EIO;
@@ -972,13 +1024,15 @@ int qlcnic_clear_esw_stats(struct qlcnic_adapter *adapter, const u8 func_esw,
arg1 = port | QLCNIC_STATS_VERSION << 8 | func_esw << 12;
arg1 |= BIT_14 | rx_tx << 15;
+ memset(rd_args, 0, sizeof(rd_args));
return qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
arg1,
0,
0,
- QLCNIC_CDRP_CMD_GET_ESWITCH_STATS);
+ QLCNIC_CDRP_CMD_GET_ESWITCH_STATS,
+ rd_args);
err_ret:
dev_err(&adapter->pdev->dev, "Invalid argument func_esw=%d port=%d"
@@ -991,19 +1045,22 @@ __qlcnic_get_eswitch_port_config(struct qlcnic_adapter *adapter,
u32 *arg1, u32 *arg2)
{
int err = -EIO;
+ u32 *rd_args[3];
u8 pci_func;
pci_func = (*arg1 >> 8);
+ rd_args[0] = arg1;
+ rd_args[1] = arg2;
+ rd_args[2] = 0;
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
*arg1,
0,
0,
- QLCNIC_CDRP_CMD_GET_ESWITCH_PORT_CONFIG);
+ QLCNIC_CDRP_CMD_GET_ESWITCH_PORT_CONFIG,
+ rd_args);
if (err == QLCNIC_RCODE_SUCCESS) {
- *arg1 = QLCRD32(adapter, QLCNIC_ARG1_CRB_OFFSET);
- *arg2 = QLCRD32(adapter, QLCNIC_ARG2_CRB_OFFSET);
dev_info(&adapter->pdev->dev,
"eSwitch port config for pci func %d\n", pci_func);
} else {
@@ -1025,6 +1082,7 @@ int qlcnic_config_switch_port(struct qlcnic_adapter *adapter,
{
int err = -EIO;
u32 arg1, arg2 = 0;
+ u32 *rd_args[3];
u8 pci_func;
if (adapter->op_mode != QLCNIC_MGMT_FUNC)
@@ -1071,13 +1129,15 @@ int qlcnic_config_switch_port(struct qlcnic_adapter *adapter,
return err;
}
+ memset(rd_args, 0, sizeof(rd_args));
err = qlcnic_issue_cmd(adapter,
adapter->ahw->pci_func,
adapter->fw_hal_version,
arg1,
arg2,
0,
- QLCNIC_CDRP_CMD_CONFIGURE_ESWITCH);
+ QLCNIC_CDRP_CMD_CONFIGURE_ESWITCH,
+ rd_args);
if (err != QLCNIC_RCODE_SUCCESS) {
dev_err(&adapter->pdev->dev,
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 720b333..2230a62 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -659,6 +659,7 @@ static int qlcnic_irq_test(struct net_device *netdev)
struct qlcnic_adapter *adapter = netdev_priv(netdev);
int max_sds_rings = adapter->max_sds_rings;
int ret;
+ u32 *rd_args[3];
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -668,9 +669,10 @@ static int qlcnic_irq_test(struct net_device *netdev)
goto clear_it;
adapter->diag_cnt = 0;
+ memset(rd_args, 0, sizeof(rd_args));
ret = qlcnic_issue_cmd(adapter, adapter->ahw->pci_func,
adapter->fw_hal_version, adapter->ahw->pci_func,
- 0, 0, 0x00000011);
+ 0, 0, 0x00000011, rd_args);
if (ret)
goto done;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index 7f4b8e6..312c1c3 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1889,8 +1889,8 @@ qlcnic_fetch_mac(struct qlcnic_adapter *adapter, u32 off1, u32 off2,
u32 mac_low, mac_high;
int i;
- mac_low = QLCRD32(adapter, off1);
- mac_high = QLCRD32(adapter, off2);
+ mac_low = off1;
+ mac_high = off2;
if (alt_mac) {
mac_low |= (mac_low >> 16) | (mac_high << 16);
--
1.6.0.2
^ permalink raw reply related
* [PATCH net-next 5/5] qlcnic: add beacon test support.
From: Sony Chacko @ 2011-08-29 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sucheta Chakraborty
In-Reply-To: <1314658231-30735-1-git-send-email-sony.chacko@qlogic.com>
From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Beacon test flashes both port LEDs instead of just 1 LED of a port.
Updated driver version to 5.0.23.
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 10 ++-
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 5 +
drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 95 ++++++++++++++++++++
3 files changed, 108 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 2a3e552..04c7015 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -36,8 +36,8 @@
#define _QLCNIC_LINUX_MAJOR 5
#define _QLCNIC_LINUX_MINOR 0
-#define _QLCNIC_LINUX_SUBVERSION 22
-#define QLCNIC_LINUX_VERSIONID "5.0.22"
+#define _QLCNIC_LINUX_SUBVERSION 23
+#define QLCNIC_LINUX_VERSIONID "5.0.23"
#define QLCNIC_DRV_IDC_VER 0x01
#define QLCNIC_DRIVER_VERSION ((_QLCNIC_LINUX_MAJOR << 16) |\
(_QLCNIC_LINUX_MINOR << 8) | (_QLCNIC_LINUX_SUBVERSION))
@@ -457,6 +457,8 @@ struct qlcnic_hardware_context {
u16 port_type;
u16 board_type;
+ u8 beacon_state;
+
struct qlcnic_nic_intr_coalesce coal;
struct qlcnic_fw_dump fw_dump;
};
@@ -931,6 +933,7 @@ struct qlcnic_ipaddr {
#define __QLCNIC_START_FW 4
#define __QLCNIC_AER 5
#define __QLCNIC_DIAG_RES_ALLOC 6
+#define __QLCNIC_LED_ENABLE 7
#define QLCNIC_INTERRUPT_TEST 1
#define QLCNIC_LOOPBACK_TEST 2
@@ -1397,6 +1400,9 @@ void qlcnic_pcie_sem_unlock(struct qlcnic_adapter *, int);
#define crb_win_unlock(a) \
qlcnic_pcie_sem_unlock((a), 7)
+#define __QLCNIC_MAX_LED_RATE 0xf
+#define __QLCNIC_MAX_LED_STATE 0x2
+
int qlcnic_get_board_info(struct qlcnic_adapter *adapter);
int qlcnic_wol_supported(struct qlcnic_adapter *adapter);
int qlcnic_config_led(struct qlcnic_adapter *adapter, u32 state, u32 rate);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 2230a62..b127f80 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -939,6 +939,9 @@ static int qlcnic_set_led(struct net_device *dev,
switch (state) {
case ETHTOOL_ID_ACTIVE:
+ if (test_and_set_bit(__QLCNIC_LED_ENABLE, &adapter->state))
+ return -EBUSY;
+
if (!test_bit(__QLCNIC_DEV_UP, &adapter->state)) {
if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
return -EIO;
@@ -973,6 +976,8 @@ static int qlcnic_set_led(struct net_device *dev,
clear_bit(__QLCNIC_RESETTING, &adapter->state);
}
+ clear_bit(__QLCNIC_LED_ENABLE, &adapter->state);
+
return -EIO;
}
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
index 998bb1d..690c93f 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
@@ -3466,6 +3466,98 @@ int qlcnic_set_max_rss(struct qlcnic_adapter *adapter, u8 data)
}
static int
+qlcnic_validate_beacon(struct qlcnic_adapter *adapter, u16 beacon, u8 *state,
+ u8 *rate)
+{
+ *rate = LSB(beacon);
+ *state = MSB(beacon);
+
+ QLCDB(adapter, DRV, "rate %x state %x\n", *rate, *state);
+
+ if (!*state) {
+ *rate = __QLCNIC_MAX_LED_RATE;
+ return 0;
+ } else if (*state > __QLCNIC_MAX_LED_STATE)
+ return -EINVAL;
+
+ if ((!*rate) || (*rate > __QLCNIC_MAX_LED_RATE))
+ return -EINVAL;
+
+ return 0;
+}
+
+static ssize_t
+qlcnic_store_beacon(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct qlcnic_adapter *adapter = dev_get_drvdata(dev);
+ int max_sds_rings = adapter->max_sds_rings;
+ int dev_down = 0;
+ u16 beacon;
+ u8 b_state, b_rate;
+ int err;
+
+ if (len != sizeof(u16))
+ return QL_STATUS_INVALID_PARAM;
+
+ memcpy(&beacon, buf, sizeof(u16));
+ err = qlcnic_validate_beacon(adapter, beacon, &b_state, &b_rate);
+ if (err)
+ return err;
+
+ if (adapter->ahw->beacon_state == b_state)
+ return len;
+
+ if (!adapter->ahw->beacon_state)
+ if (test_and_set_bit(__QLCNIC_LED_ENABLE, &adapter->state))
+ return -EBUSY;
+
+ if (!test_bit(__QLCNIC_DEV_UP, &adapter->state)) {
+ if (test_and_set_bit(__QLCNIC_RESETTING, &adapter->state))
+ return -EIO;
+ err = qlcnic_diag_alloc_res(adapter->netdev, QLCNIC_LED_TEST);
+ if (err) {
+ clear_bit(__QLCNIC_RESETTING, &adapter->state);
+ clear_bit(__QLCNIC_LED_ENABLE, &adapter->state);
+ return err;
+ }
+ dev_down = 1;
+ }
+
+ err = qlcnic_config_led(adapter, b_state, b_rate);
+
+ if (!err) {
+ adapter->ahw->beacon_state = b_state;
+ err = len;
+ }
+
+ if (dev_down) {
+ qlcnic_diag_free_res(adapter->netdev, max_sds_rings);
+ clear_bit(__QLCNIC_RESETTING, &adapter->state);
+ }
+
+ if (!b_state)
+ clear_bit(__QLCNIC_LED_ENABLE, &adapter->state);
+
+ return err;
+}
+
+static ssize_t
+qlcnic_show_beacon(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct qlcnic_adapter *adapter = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%d\n", adapter->ahw->beacon_state);
+}
+
+static struct device_attribute dev_attr_beacon = {
+ .attr = {.name = "beacon", .mode = (S_IRUGO | S_IWUSR)},
+ .show = qlcnic_show_beacon,
+ .store = qlcnic_store_beacon,
+};
+
+static int
qlcnic_sysfs_validate_crb(struct qlcnic_adapter *adapter,
loff_t offset, size_t size)
{
@@ -4162,6 +4254,8 @@ qlcnic_create_diag_entries(struct qlcnic_adapter *adapter)
return;
if (device_create_file(dev, &dev_attr_diag_mode))
dev_info(dev, "failed to create diag_mode sysfs entry\n");
+ if (device_create_file(dev, &dev_attr_beacon))
+ dev_info(dev, "failed to create beacon sysfs entry");
if (device_create_bin_file(dev, &bin_attr_crb))
dev_info(dev, "failed to create crb sysfs entry\n");
if (device_create_bin_file(dev, &bin_attr_mem))
@@ -4192,6 +4286,7 @@ qlcnic_remove_diag_entries(struct qlcnic_adapter *adapter)
if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC)
return;
device_remove_file(dev, &dev_attr_diag_mode);
+ device_remove_file(dev, &dev_attr_beacon);
device_remove_bin_file(dev, &bin_attr_crb);
device_remove_bin_file(dev, &bin_attr_mem);
device_remove_bin_file(dev, &bin_attr_pci_config);
--
1.6.0.2
^ permalink raw reply related
* [PATCH net-next 2/5] qlcnic: Change debug messages in loopback path
From: Sony Chacko @ 2011-08-29 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Manish chopra
In-Reply-To: <1314658231-30735-1-git-send-email-sony.chacko@qlogic.com>
From: Manish chopra <Manish.Chopra@qlogic.com>
Added more debug messages while loopback test in progress
Signed-off-by: Manish chopra <Manish.Chopra@qlogic.com>
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
.../net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 15 ++++++++++-----
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 6 +++---
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 59d73f2..720b333 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -710,7 +710,7 @@ int qlcnic_check_loopback_buff(unsigned char *data, u8 mac[])
return memcmp(data, buff, QLCNIC_ILB_PKT_SIZE);
}
-static int qlcnic_do_lb_test(struct qlcnic_adapter *adapter)
+static int qlcnic_do_lb_test(struct qlcnic_adapter *adapter, u8 mode)
{
struct qlcnic_recv_context *recv_ctx = adapter->recv_ctx;
struct qlcnic_host_sds_ring *sds_ring = &recv_ctx->sds_rings[0];
@@ -736,13 +736,18 @@ static int qlcnic_do_lb_test(struct qlcnic_adapter *adapter)
dev_kfree_skb_any(skb);
if (!adapter->diag_cnt)
- dev_warn(&adapter->pdev->dev, "LB Test: %dth packet"
- " not recevied\n", i + 1);
+ QLCDB(adapter, DRV,
+ "LB Test: packet #%d was not received\n", i + 1);
else
cnt++;
}
if (cnt != i) {
dev_warn(&adapter->pdev->dev, "LB Test failed\n");
+ if (mode != QLCNIC_ILB_MODE) {
+ dev_warn(&adapter->pdev->dev,
+ "WARNING: Please make sure external"
+ "loopback connector is plugged in\n");
+ }
return -1;
}
return 0;
@@ -761,7 +766,7 @@ static int qlcnic_loopback_test(struct net_device *netdev, u8 mode)
return -EOPNOTSUPP;
}
- netdev_info(netdev, "%s loopback test in progress\n",
+ QLCDB(adapter, DRV, "%s loopback test in progress\n",
mode == QLCNIC_ILB_MODE ? "internal" : "external");
if (adapter->op_mode == QLCNIC_NON_PRIV_FUNC) {
netdev_warn(netdev, "Loopback test not supported for non "
@@ -797,7 +802,7 @@ static int qlcnic_loopback_test(struct net_device *netdev, u8 mode)
}
} while (!QLCNIC_IS_LB_CONFIGURED(adapter->ahw->loopback_state));
- ret = qlcnic_do_lb_test(adapter);
+ ret = qlcnic_do_lb_test(adapter, mode);
qlcnic_clear_lb_mode(adapter);
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index 3b6741e..b02859c 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -1779,14 +1779,14 @@ qlcnic_post_rx_buffers_nodb(struct qlcnic_adapter *adapter,
spin_unlock(&rds_ring->lock);
}
-static void dump_skb(struct sk_buff *skb)
+static void dump_skb(struct sk_buff *skb, struct qlcnic_adapter *adapter)
{
int i;
unsigned char *data = skb->data;
printk(KERN_INFO "\n");
for (i = 0; i < skb->len; i++) {
- printk(KERN_INFO "%02x ", data[i]);
+ QLCDB(adapter, DRV, "%02x ", data[i]);
if ((i & 0x0f) == 8)
printk(KERN_INFO "\n");
}
@@ -1829,7 +1829,7 @@ void qlcnic_process_rcv_diag(struct qlcnic_adapter *adapter,
if (!qlcnic_check_loopback_buff(skb->data, adapter->mac_addr))
adapter->diag_cnt++;
else
- dump_skb(skb);
+ dump_skb(skb, adapter);
dev_kfree_skb_any(skb);
adapter->stats.rx_pkts++;
--
1.6.0.2
^ permalink raw reply related
* [PATCH net-next 0/5] qlcnic: Bug fixes
From: Sony Chacko @ 2011-08-29 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sony Chacko
In-Reply-To: <1314658231-30735-1-git-send-email-sony.chacko@qlogic.com>
Please apply to net-next.
Thank you,
Sony Chacko
^ permalink raw reply
* [PATCH net-next 3/5] qlcnic: Add FLT entry for CO cards FW image region
From: Sony Chacko @ 2011-08-29 22:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept_NX_Linux_NIC_Driver, Sritej Velaga
In-Reply-To: <1314658231-30735-1-git-send-email-sony.chacko@qlogic.com>
From: Sritej Velaga <sritej.velaga@qlogic.com>
The FLT entry for FW image region has changed for C0 cards.
Updated the driver to look at the right region in the FLT.
Signed-off-by: Sritej Velaga <sritej.velaga@qlogic.com>
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic.h | 4 +++-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c | 8 +++++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
index 53c6e5d..4118502 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic.h
@@ -73,6 +73,7 @@
(sizeof(struct cmd_desc_type0) * tx_ring->num_desc)
#define QLCNIC_P3P_A0 0x50
+#define QLCNIC_P3P_C0 0x58
#define QLCNIC_IS_REVISION_P3P(REVISION) (REVISION >= QLCNIC_P3P_A0)
@@ -291,7 +292,8 @@ struct uni_data_desc{
/* Flash Defines and Structures */
#define QLCNIC_FLT_LOCATION 0x3F1000
-#define QLCNIC_FW_IMAGE_REGION 0x74
+#define QLCNIC_B0_FW_IMAGE_REGION 0x74
+#define QLCNIC_C0_FW_IMAGE_REGION 0x97
#define QLCNIC_BOOTLD_REGION 0X72
struct qlcnic_flt_header {
u16 version;
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
index b02859c..7f4b8e6 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_init.c
@@ -686,7 +686,13 @@ qlcnic_check_flash_fw_ver(struct qlcnic_adapter *adapter)
u32 ver = -1, min_ver;
int ret;
- ret = qlcnic_get_flt_entry(adapter, QLCNIC_FW_IMAGE_REGION, &fw_entry);
+ if (adapter->ahw->revision_id == QLCNIC_P3P_C0)
+ ret = qlcnic_get_flt_entry(adapter, QLCNIC_C0_FW_IMAGE_REGION,
+ &fw_entry);
+ else
+ ret = qlcnic_get_flt_entry(adapter, QLCNIC_B0_FW_IMAGE_REGION,
+ &fw_entry);
+
if (!ret)
/* 0-4:-signature, 4-8:-fw version */
qlcnic_rom_fast_read(adapter, fw_entry.start_addr + 4,
--
1.6.0.2
^ permalink raw reply related
* Re: BQL crap and wireless
From: Dave Taht @ 2011-08-29 23:10 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tom Herbert, linux-wireless, Andrew McGregor, Matt Smith,
Kevin Hayes, Derek Smithies, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAB=NE6V7jFgtK4HmkUnfY5MuWCJoTyo83p9KMVTvmXTsrGoTew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
My goal in collecting these recordings is to get TRANSCRIPTS of what
is important and what is not, so that ultimately better documentation
can be written from those than exist today.
Since the byte queuing issue is hot this week, I decided to make more
people aware that these recordings existed in the hope that more
available background information on how wireless works could be
internalized by more people.
I did note that the talk with felix was an attempt at capturing and
summarizing some bufferbloat history and only towards the end did we
start moving forward to things we planned to try, while the talk with
andrew was an attempt at doing a more technical overview of quite a
few issues.
Multiple people have found these conversations useful. Certainly I
find them useful, often reviewing them a few weeks after the fact to
find subtleties that I missed originally, or needed further reading to
really understand or write code for. The earliest conversation I had
with felix (march?) still has some useful nuggets in it about how
aggregation actually works that I hope to mine one day for better
documentation. It also had some glaring errors in it...
(mostly MINE!)
http://mirrors.bufferbloat.net/podcasts/
I would certainly like to have a (recorded!) conversation with you to
have a constructive
discussion of the issues you find important, correct, and essential,
towards making wireless networking better.
Many people are capable of doing otherwise useful work while having a
podcast running in the background that might have a few percentage
points of useful information.
By all means, don't listen if you can't split the brain cells, as I
wrote I will have transcript of that latest available and will try to
summarize and extract the best of what was discussed, after we get
some code written and some tests performed.
There are many other folk I would like to interview in this way, as well.
On Mon, Aug 29, 2011 at 3:54 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Aug 29, 2011 at 3:45 PM, Dave Taht <dave.taht-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> http://huchra.bufferbloat.net/~d/talks/felix/
>> http://huchra.bufferbloat.net/~d/talks/andrew/
>
> I had already listened to Andrew's audio, and got up to 1 hour with
> your session with Felix but seriously considered that entire 1 hour a
> waste of my life. I think you digressed completely and rambled on
> about random crap instead of focusing on the core of the matter, I
> gave up after 1 hour.
>
> Luis
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BQL crap and wireless
From: Luis R. Rodriguez @ 2011-08-29 23:15 UTC (permalink / raw)
To: Dave Taht
Cc: Tom Herbert, linux-wireless, Andrew McGregor, Matt Smith,
Kevin Hayes, Derek Smithies, netdev
In-Reply-To: <CAA93jw6Ude=x=5v2cq86UjnORXDhAQASp51zLvDDBYHB28T_Jw@mail.gmail.com>
On Mon, Aug 29, 2011 at 4:10 PM, Dave Taht <dave.taht@gmail.com> wrote:
> My goal in collecting these recordings is to get TRANSCRIPTS of what
> is important and what is not, so that ultimately better documentation
> can be written from those than exist today.
>
> Since the byte queuing issue is hot this week, I decided to make more
> people aware that these recordings existed in the hope that more
> available background information on how wireless works could be
> internalized by more people.
>
> I did note that the talk with felix was an attempt at capturing and
> summarizing some bufferbloat history and only towards the end did we
> start moving forward to things we planned to try, while the talk with
> andrew was an attempt at doing a more technical overview of quite a
> few issues.
>
> Multiple people have found these conversations useful. Certainly I
> find them useful, often reviewing them a few weeks after the fact to
> find subtleties that I missed originally, or needed further reading to
> really understand or write code for. The earliest conversation I had
> with felix (march?) still has some useful nuggets in it about how
> aggregation actually works that I hope to mine one day for better
> documentation. It also had some glaring errors in it...
> (mostly MINE!)
>
> http://mirrors.bufferbloat.net/podcasts/
>
> I would certainly like to have a (recorded!) conversation with you to
> have a constructive
> discussion of the issues you find important, correct, and essential,
> towards making wireless networking better.
>
> Many people are capable of doing otherwise useful work while having a
> podcast running in the background that might have a few percentage
> points of useful information.
>
> By all means, don't listen if you can't split the brain cells, as I
> wrote I will have transcript of that latest available and will try to
> summarize and extract the best of what was discussed, after we get
> some code written and some tests performed.
>
> There are many other folk I would like to interview in this way, as well.
Honestly I do not have > 1 hour to review random audio on some topic
when the only meat of what I want is in 5 minutes of the > 1 hour
talk; the reason I stuck to hearing most of the talk though is I am
quite tired of the FUD around bufferbloat and also tired of the random
adhoc patches, e-mails and rants about it. My recommendation is edit
crap out and make a more condensed clip with the stuff technical folks
really care about. I'm not saying no one will find it useful, I'm
saying technical folks will puke all over it and likely not want to
even review more bufferbloat crap later. That's where I'm at least.
Luis
^ permalink raw reply
* Re: BQL crap and wireless
From: Andrew McGregor @ 2011-08-29 23:18 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tom Herbert, linux-wireless, Matt Smith, Kevin Hayes, Dave Taht,
Derek Smithies, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAB=NE6VwWu5+Hk7=3ghkgiXss9kCqGyS-RWPYtyHRhDsx5r2rA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 30/08/2011, at 9:02 AM, Luis R. Rodriguez wrote:
> On Fri, Aug 26, 2011 at 4:27 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> I've just read this thread:
>>
>> http://marc.info/?t=131277868500001&r=1&w=2
>>
>> Since its not linux-wireless I'll chime in here. It seems that you are
>> trying to write an algorithm that will work for all networking and
>> 802.11 devices. For networking is seems tough given driver
>> architecture and structure and the hope that all drivers will report
>> things in a fairly similar way. For 802.11 it was pointed out how we
>> have varying bandwidths and depending on the technology used for
>> connection (AP, 802.11s, IBSS) a different number of possible peers
>> need to be considered. 802.11 faced similar algorithmic complexities
>> with rate control and the way Andrew and Derek resolved this was to
>> not assume you could solve this problem and simply test out the water
>> by trial and error, that gave birth to the minstrel rate control
>> algorithm which Felix later rewrote for mac80211 with 802.11n support
>> [1]. Can the BQL algorithm make use of the same trial and error
>> mechanism and simply try different values and and use EWMA [2] to pick
>> the best size for the queue ?
>>
>> [1] http://wireless.kernel.org/en/developers/Documentation/mac80211/RateControl/minstrel
>> [2] http://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average
>
> Let me elaborate on 802.11 and bufferbloat as so far I see only crap
> documentation on this and also random crap adhoc patches. Given that I
> see effort on netdev to try to help with latency issues its important
> for netdev developers to be aware of what issues we do face today and
> what stuff is being mucked with.
>
> As far as I see it I break down the issues into two categories:
>
> * 1. High latencies on ping
> * 2. Constant small drops in throughput
>
> 1. High latencies on ping
> ===================
>
> It seems the bufferbloat folks are blaming the high latencies on our
> obsession on modern hardware to create huge queues and also with
> software retries. They assert that reducing the queue length
> (ATH_MAX_QDEPTH on ath9k) and software retries (ATH_MAX_SW_RETRIES on
> ath9k) helps with latencies. They have at least empirically tested
> this with ath9k with
> a simple patch:
>
> https://www.bufferbloat.net/attachments/43/580-ath9k_lowlatency.patch
>
> The obvious issue with this approach is it assumes STA mode of
> operation, with an AP you do not want to reduce the queue size like
> that. In fact because of the dynamic nature of 802.11 and the
> different modes of operation it is a hard question to solve on what
> queue size you should have. The BQL effort seems to try to unify a
> solution but obviously did not consider 802.11's complexities. 802.11
> makes this very complicated given the PtP and PtMP support we have and
> random number of possible peers.
>
> Then -- we have Aggregation. At least AMPDU Aggregation seems to
> empirically deteriorate latency and bufferbloat guys seem to hate it.
> Of course their statements are baseless and they are ignoring a lot of
> effort that went into this. Their current efforts have been to reduce
> segment size of a aggregates and this seems to help but the same
> problem looms over this resolution -- the optimal aggregation segment
> size should be dynamic and my instincts tell me we likely need to also
> rely on a minstrel-like based algorithm for finding the optimal length.
Luis, as the author of that patch... I agree entirely that we want something dynamic. I was actually writing that assuming AP operation... and it works pretty well, but I wouldn't expect it to be anything like optimal in all situations.
It looks like the time limits (called segment_size in the code) in Minstrel-HT were just copied from Minstrel-classic, which was tuned for 11g timings. The patch reduces the time limits and retry counts (the SW retry limit number goes up because of another patch that changes the accounting for SW retries from passes through the queue to transmitter shots, but 50 shots is way less than 20 passes through the queue). Now, this is just a matter of having sensible defaults that are not crazily trying to use hundreds of transmit opportunities on one packet.
That patch also reduces the aggregation opportunities a bit; the driver has something approximating a target queue depth, ATH_MAX_QDEPTH, that by default was 123 packets, and I reduced it to 34. Now, why 34? Because at any smaller number, it's going to impact aggregation and therefore performance really badly, while at a much larger number it's going to affect latency. I do understand why aggregation is important; the MAC has a lot of dead air in it, the scarce resource is transmit opportunities rather than bandwidth per se, and we need to get as much as reasonably possible done with each transmit opportunity.
What this patch does assume is that most of the clients have fairly decent coverage; it's going to be really unfair to .11b clients and those right out on the fringes of the APs coverage. But, with a fairly busy AP and decent coverage, it does actually work well in practice on the AP (I run it at home, and there's a fair bit of stuff on my network...). The demonstration is, I can have a few TCP streams running flat out from my laptop to something on the wired LAN, and still make a voip call from any device on the wireless... including the laptop (which runs OS X Lion and has a Broadcom radio, by the way, so Linux is not the only stack that does pretty well for latency). The TCP throughput is barely affected by that patch, but the latency is dramatically improved; what was over 100 ms an
d wildly varying (under load from TCP traffic) is now very stable and a little under 20 ms on the wireless hop.
So, yes, I do think some kind of dynamic queue sizing is called for. Also, I think we need a queue bundle per active peer (just to cover all the operation modes... that would be just the AP in STA mode), that is dynamically sized per traffic class per peer. Also, a decent qdisc that will do a reasonable job of getting latency-sensitive stuff into queues that are trying for latency rather than throughput.
And to the buffer bloat guys: yes, I do see how many buffers I'm proposing using here... it might be a couple or four thousand on a really busy AP. But the point is not to eliminate buffering, it is to use it sensibly to help performance rather than hurt as it so often does at present. The number of buffers in total doesn't matter, it's the depth of the queues seen by any particular packet passing through the network that is really critical... and too few is just as bad as too many, especially when it leads to wasting a scarce link resource, as too few buffers will do on an 802.11n AP.
>
> 2. Constant small drops in throughput
> =============================
>
> How to explain this? I have no clue. Two current theories:
>
> a. Dynamic Power save
> b. Offchannel operations on bgscans
> c. Bufferbloat: large hw queue size and sw retries
d. Someone has a broken rate control algorithm, and that is causing slowdowns and packet loss.
The study that Dave was referring to earlier was done on Windows XP clients, using APs running who knows what (we know the best of them was ath9k and Minstrel-classic, because it was running code based on OpenWRT 8.something, but the others I have no idea). There's all kinds of variables there, and I wouldn't rule out any kind of weirdness.
I think Linux in general is in pretty good shape with respect to most of these issues, what with your work on power save and scanning, and with minstrel for rate control. Part of the bufferbloat effort is to get the awareness of queue size issues... and what we're doing here is, basically, documenting the tradeoffs and considerations in 802.11 land.
I think a distilled version of these conversations needs to be written up as an informational RFC so the IETC has something to refer to.
>
> One can rule out (a) and (b) by disabling Dynamic Power Save (iw dev
> wlan0 power_save off) and also bg scans. If its (c) then we can work
> our way up to proving a solution with the same fixes for the first
> latency issue. But there are more subtle issues here. Bufferbloat
> folks talk about "ants" and "elephants". They call "Elephants" as
> frames that are just data, but "ants" are small frames that build make
> the networks work -- so consider 802.11 management frames, and TCP
> ACKs, and so forth. They argue we should prioritize these more and
> ensure we use whatever techniques we can to ensure we reduce latency
> for them. At least on ath9k we only aggregate data frames, but that
> doesn't mean we are not aggregating other "ant" frames. We at least
> now have in place code to not aggregate Voice Traffic -- that's good
> but we can do more. For example we can use AMSDU TX support for small
> frame. This means we'd need to prioritize AMSDU TX support, which we
> do not have support for in mac80211. I think this will help here, but
> consider queue size too -- we can likely get even better results here
> by ensuring we reduce latency further for them.
>
> Hope this helps sum up the issue for 802.11 and what we are faced with.
>
> Luis
It sure does help, thanks Luis.
Andrew--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 19/24] sunrpc: Remove unnecessary OOM logging messages
From: Myklebust, Trond @ 2011-08-29 23:25 UTC (permalink / raw)
To: David Miller, bharrosh
Cc: joe, bfields, neilb, linux-nfs, netdev, linux-kernel
In-Reply-To: <20110829.180348.1774953636752413432.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Monday, August 29, 2011 6:04 PM
> To: bharrosh@panasas.com
> Cc: Myklebust, Trond; joe@perches.com; bfields@fieldses.org;
> neilb@suse.de; linux-nfs@vger.kernel.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 19/24] sunrpc: Remove unnecessary OOM logging
> messages
>
> From: Boaz Harrosh <bharrosh@panasas.com>
> Date: Mon, 29 Aug 2011 14:54:59 -0700
>
> > I have a question about that. Are the dprints going to show the
stack
> backtrace?
>
> Yes, OOMs give full stack backtraces.
>
> > If yes above? then I'm not sure I like it either, because am I'll be
> getting a full
> > stack backtrace for every failed allocation?
>
> They've been doing this for years, so obviously they haven't bothered
> you
> enough to care up to this point.
>
> All of this pushback is pure uneducated noise, please stop blocking
> progress
> with poorly informed objections.
I can see that slub.c has the slab_out_of_memory() function that
(although ratelimited) warns you if the allocation failed. However I
can't find any equivalent for slab.c or slob.c.
Trond
^ permalink raw reply
* Re: [PATCH 19/24] sunrpc: Remove unnecessary OOM logging messages
From: Boaz Harrosh @ 2011-08-29 23:33 UTC (permalink / raw)
To: Myklebust, Trond
Cc: David Miller, joe-6d6DIl74uiNBDgjK7y7TUQ,
bfields-uC3wQj2KruNg9hUCZPvPmw, neilb-l3A5Bk7waGM,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2E1EB2CF9ED1CB4AA966F0EB76EAB4430AEB4FAF-hX7t0kiaRRrlMGe9HJ1VYQK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
On 08/29/2011 04:25 PM, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: David Miller [mailto:davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org]
<>
>> They've been doing this for years, so obviously they haven't bothered
>> you enough to care up to this point.
>>
>> All of this pushback is pure uneducated noise, please stop blocking
>> progress with poorly informed objections.
>
> I can see that slub.c has the slab_out_of_memory() function that
> (although ratelimited) warns you if the allocation failed. However I
> can't find any equivalent for slab.c or slob.c.
>
OK That would explain why I never saw it in my debugging. For some reason
I'm always using slab.
Which one is the best for development and memory problems debugging?
> Trond
Thanks
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BQL crap and wireless
From: Dave Taht @ 2011-08-30 0:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tom Herbert, linux-wireless, Andrew McGregor, Matt Smith,
Kevin Hayes, Derek Smithies, netdev
In-Reply-To: <CAB=NE6VwWu5+Hk7=3ghkgiXss9kCqGyS-RWPYtyHRhDsx5r2rA@mail.gmail.com>
On Mon, Aug 29, 2011 at 2:02 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Aug 26, 2011 at 4:27 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> Let me elaborate on 802.11 and bufferbloat as so far I see only crap
> documentation on this and also random crap adhoc patches.
I agree that the research into bufferbloat has been an evolving topic, and
the existing documentation and solutions throughout the web is inaccurate
or just plan wrong in many respects. While I've been accumulating better
and more interesting results as research continues, we're not there yet...
> Given that I
> see effort on netdev to try to help with latency issues its important
> for netdev developers to be aware of what issues we do face today and
> what stuff is being mucked with.
Hear, Hear!
> As far as I see it I break down the issues into two categories:
>
> * 1. High latencies on ping
> * 2. Constant small drops in throughput
I'll take on 2, in a separate email.
>
> 1. High latencies on ping
> ===================
For starters, no, "high - and wildly varying - latencies on all sorts
of packets".
Ping is merely a diagnostic tool in this case.
If you would like several gb of packet captures of all sorts of streams
from various places and circumstances, ask. JG published a long
series about 7 months back, more are coming.
Regrettably most of the most recent traces come from irreproducible
circumstances, a flaw we are trying to fix after 'CeroWrt' is finished.
> It seems the bufferbloat folks are blaming the high latencies on our
> obsession on modern hardware to create huge queues and also with
> software retries. They assert that reducing the queue length
> (ATH_MAX_QDEPTH on ath9k) and software retries (ATH_MAX_SW_RETRIES on
> ath9k) helps with latencies. They have at least empirically tested
> this with ath9k with
> a simple patch:
>
> https://www.bufferbloat.net/attachments/43/580-ath9k_lowlatency.patch
>
> The obvious issue with this approach is it assumes STA mode of
> operation, with an AP you do not want to reduce the queue size like
> that. In fact because of the dynamic nature of 802.11 and the
If there is any one assumption about the bufferbloat issue that people
keep assuming we have, it's this one.
In article after article, in blog post after blog post, people keep
'fixing' bufferbloat by setting their queues to very low values,
and almost miraculously start seeing their QoS start working
(which it does), and then they gleefully publish their results
as recommendations, and then someone from the bufferbloat
effort has to go and comment on that piece, whenever we
notice, to straighten them out.
In no presentation, no documentation, anywhere I know of,
have we expressed that queuing as it works today
is the right thing.
More recently, JG got fed up and wrote these...
http://gettys.wordpress.com/2011/07/06/rant-warning-there-is-no-single-right-answer-for-buffering-ever/
http://gettys.wordpress.com/2011/07/09/rant-warning-there-is-no-single-right-answer-for-buffering-ever-part-2/
There has been no time, since the inception of the bufferbloat
concept, have we had a fixed buffer size in any layer of the
stack as even a potential solution.
And you just did applied that preconception to us again.
My take on matters is that *unmanaged* buffer sizes > 1 is a
problem. Others set the number higher.
Of late, given what tools we have, we HAVE been trying to establish
what *good baseline* queue sizes (txqueues, driver queues, etc)
actually are for wireless under ANY circumstance that was
duplicate-able.
For the drivers JG was using last year, that answer was: 0.
Actually, less than 0 would have been good, but that
would have involved having tachyon emitters in the
architecture.
For the work that felix and andrew recently performed on the ath9k,
it looks to be about 37 for STA mode, but further testing is required
and is taking place... as well as instrumentation of the tcp stack, changes
to the system clock interrupt, and a horde of other things.
As for AP performance... don't know. Am testing, capturing streams,
testing contention, building up labs, and creating a distro to deploy
to the field to test everything with.
> different modes of operation it is a hard question to solve on what
> queue size you should have. The BQL effort seems to try to unify a
> solution but obviously did not consider 802.11's complexities.
I only noticed the presentation and thread a few days ago. I do happen
to like byte, rather than packet limits, as a start towards sanity, but
framing overhead is still a problem, and an effective API and
set of servos more so.
> 802.11
> makes this very complicated given the PtP and PtMP support we have and
> random number of possible peers.
>
> Then -- we have Aggregation. At least AMPDU Aggregation seems to
> empirically deteriorate latency and bufferbloat guys seem to hate it.
I think aggregation is awesome, actually. I've said so on multiple occasions.
After reading the early work done on it, back in the early 2000s, I thought it
could not be made to work, at all. I was wrong.
The problems I have with aggregation as seemingly commenly
implemented today are:
0) Attempts to make the media look 100% perfect
1) Head of line blocking
2) Assumption that all packets are equal.
3) Co-existence with previous forms of 802.11 is difficult
4) Horrible behavior with every AQM algorithm, particularly with fair queuing
> Of course their statements are baseless and they are ignoring a lot of
> effort that went into this. Their current efforts have been to reduce
> segment size of a aggregates and this seems to help but the same
I note that some of the ongoing suggestions actually will make it statistically
more likely that stuff emerging from higher levels of the stack will be even
more aggregate-able than it is currently.
Also, it would be good to have some statistics as to how good aggregation
is currently, actually working under normal multiuser workloads.
A suggestion of felix's was to make that available via netlink broadcast.
> problem looms over this resolution -- the optimal aggregation segment
> size should be dynamic and my instincts tell me we likely need to also
> rely on a minstrel-like based algorithm for finding the optimal length.
We agree very much it should be dynamic.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
^ permalink raw reply
* Re: Unicast hash for IXGBEVF driver
From: J.Hwan Kim @ 2011-08-30 1:05 UTC (permalink / raw)
To: netdev
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019454265E@orsmsx508.amr.corp.intel.com>
On 2011년 08월 30일 03:24, Rose, Gregory V wrote:
> The ROPE bits should not be set for any of the VFs and only on the PF when it is in promiscuous mode.
>
> The PFUTA bits are imperfect MAC address hash filters. By setting them all to ones and then turning on the ROPE bit for each of the VFs you're essentially putting the VF into a sort of fake promiscuous mode.
>
> This is not recommended. Older drivers that did this had a bug in them.
>
> - Greg
Hi, Greg,
Thank you for reply.
When I have two streams of which destination mac address, for example
34:22:11:13:23:55 and 14:12:34:23:12:33,
and I have 2VFs, how can I set the PFUTA register for distributting the
streams into 2VFs according to the MAC address?
I want to first MAC address stream to first VF and second MAC address
stream to second VF.
>> -----Original Message-----
>> From: tarbal@gmail.com [mailto:tarbal@gmail.com] On Behalf Of Jeff Kirsher
>> Sent: Saturday, August 27, 2011 12:35 AM
>> To: J.Hwan Kim; Rose, Gregory V
>> Cc: netdev; e1000-devel@lists.sourceforge.net
>> Subject: Re: Unicast hash for IXGBEVF driver
>>
>> On Sat, Aug 27, 2011 at 00:23, J.Hwan Kim<frog1120@gmail.com> wrote:
>>> Hi, everyone
>>>
>>> How can I distribute the packets according to destination MAC address
>>> into multi-virtual fucntion queue?
>>> Now, my setting is that all bit of PFUTA are '1' and ROPE bit is 1,
>>> so all mac packet is duplicated to all VF queue.
>>> I cannot understand the meaning of bits of PFUTA and the relation
>>> with mac address.
>>> I want to distribute the received packets to RX queues respectively,
>>> not duplicated.
>>>
>>>
>>> Thanks in advance.
>>>
>>> Best Regards,
>>> J.Hwan Kim
>>>
>> Adding Greg Rose, since he is the ixgbevf driver maintainer. He
>> should be able to answer your questions early next week, unless he is
>> checking his email over the weekend.
>>
>> --
>> Cheers,
>> Jeff
^ permalink raw reply
* Re: BQL crap and wireless
From: Dave Taht @ 2011-08-30 1:08 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tom Herbert, linux-wireless, Andrew McGregor, Matt Smith,
Kevin Hayes, Derek Smithies, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAB=NE6VwWu5+Hk7=3ghkgiXss9kCqGyS-RWPYtyHRhDsx5r2rA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> 2. Constant small drops in throughput
> =============================
Huge drops in throughput, actually.
> How to explain this? I have no clue. Two current theories:
>
> a. Dynamic Power save
> b. Offchannel operations on bgscans
> c. Bufferbloat: large hw queue size and sw retries
>
> One can rule out (a) and (b) by disabling Dynamic Power Save (iw dev
> wlan0 power_save off) and also bg scans. If its (c) then we can work
> our way up to proving a solution with the same fixes for the first
> latency issue. But there are more subtle issues here.
(in part, your) recent analysis of the periodicity of bandwidth drops
does point
strongly to points a and b being mis-implemented by many vendors and OS-makers,
and shows a clear path toward further testing by several labs.
> Bufferbloat
> folks talk about "ants" and "elephants". They call "Elephants" as
> frames that are just data, but "ants" are small frames that build make
> the networks work --
This is an over-simplification of a complex issue, and wrong.
Elephants are very large *streams* of tcp data, the kind you get after
a few seconds of operation, and mice are short ones, the kind you
commonly get with non-pipelined http protocols and normal websites.
As noted elsewhere, with tons of reference material on google and citeseer,
"tcp mice and elephants" are a well researched and understood topic -
or at least were, back when network research still happened, which
was prior to the explosion and predominance of wireless.
The need for AQMs such as RED, Blue, etc, to manage elephants was
well demonstrated back in the early 90s. Being able to shoot/slow down
the elephants on a sane basis is also required to have sane shared
network behavior.
There has been a huge shift in TCP flows with first the advent of the
web for all things, and more recently, back again, with the rise of video.
> so consider 802.11 management frames, and TCP
> ACKs, and so forth.
Um, actually, if TCP acks are 'ANT's, it's news to me, and I co-coined the term.
There is one special case, commonly implemented in cable modems, of
Syn and Syn/Ack optimization, that might pay off to some extent in wireless.
Upstream ACK prioritization does seem to help when it comes to
managing interactive
flows on asymmetric (e.g. home) networks as (for example) demonstrated by
wondershaper and other QoS mechanism.
But anything involving TCP fits into the well defined mice and
elephant categories
already, not ANTs.
I'm told that most management frames are in a separately managed queue already.
> They argue we should prioritize these more and
> ensure we use whatever techniques we can to ensure we reduce latency
> for them.
ARP, DHCP, ND, RA, and various forms of ipv6's ping based protocols,
most routing protocols
in many aspects, numerous other non-tcp protocols, all count as ANTs.
> At least on ath9k we only aggregate data frames, but that
> doesn't mean we are not aggregating other "ant" frames.
The approach that we are experimenting with now, is putting
ANT-like packets into the VO and VI queues as appropriate and out
of the BE or BK queues.
Too early to publish preliminary results, but I am encouraged by what
I've seen so far.
It's interesting to note that a lot of web traffic is actually marked
as bulk traffic (tos of bulk)
which ends up in the wireless BK queue, rather than BE.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 18/24] sctp: Remove unnecessary OOM logging messages
From: Joe Perches @ 2011-08-30 1:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Vlad Yasevich, Sridhar Samudrala, David S. Miller, linux-sctp,
netdev, linux-kernel
In-Reply-To: <1314654209.2563.7.camel@edumazet-laptop>
On Mon, 2011-08-29 at 23:43 +0200, Eric Dumazet wrote:
> Le lundi 29 août 2011 à 14:17 -0700, Joe Perches a écrit :
> > Removing unnecessary messages saves code and text.
> > Site specific OOM messages are duplications of a generic MM
> > out of memory message and aren't really useful, so just
> > delete them.
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > net/sctp/protocol.c | 3 ---
> > 1 files changed, 0 insertions(+), 3 deletions(-)
> > diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
[]
> > @@ -1326,7 +1326,6 @@ SCTP_STATIC __init int sctp_init(void)
> > __get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order);
> > } while (!sctp_assoc_hashtable && --order > 0);
> > if (!sctp_assoc_hashtable) {
> > - pr_err("Failed association hash alloc\n");
> > status = -ENOMEM;
> > goto err_ahash_alloc;
> > }
[]
> > @@ -1359,7 +1357,6 @@ SCTP_STATIC __init int sctp_init(void)
> > __get_free_pages(GFP_ATOMIC|__GFP_NOWARN, order);
> > } while (!sctp_port_hashtable && --order > 0);
> > if (!sctp_port_hashtable) {
> > - pr_err("Failed bind hash alloc\n");
> > status = -ENOMEM;
> > goto err_bhash_alloc;
> > }
> It would be nice if you could avoid all these patches, that you dont
> even read.
Didn't read is not the same thing as didn't notice.
> As I already told you in the past, __GFP_NOWARN dont print generic OOM
> messages.
I didn't notice those had GFP_NOWARN.
> Its not because I told Wang Shaoyan not adding a useless "pr_err("Out of
> memory\n");" in last gianfar patch, that you have to remove all
> messages, with one hundred or more patches.
> If I remember well, you even disagreed at that time.
No, what I said was that it'd be better to get agreement
to delete them before deleting them.
https://lkml.org/lkml/2011/8/9/379
So I submitted an RFC and cc'd you.
You did not reply.
https://lkml.org/lkml/2011/8/25/580
> Furthermore, a failed vmalloc() is not guaranteed to emit an OOM
> message, is it ?
Doesn't seem to be, perhaps it should be
when __GFP_NOWARN is not set...
^ permalink raw reply
* Re: BQL crap and wireless
From: Jim Gettys @ 2011-08-30 1:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dave Taht, Tom Herbert, linux-wireless, Andrew McGregor,
Matt Smith, Kevin Hayes, Derek Smithies,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAA93jw7c+Nxc6ZbWZWsQ+F78AoPWU=quSRaOUpT0yRcwJOXsGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 08/29/2011 08:24 PM, Dave Taht wrote:
> On Mon, Aug 29, 2011 at 2:02 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Aug 26, 2011 at 4:27 PM, Luis R. Rodriguez <mcgrof-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> Let me elaborate on 802.11 and bufferbloat as so far I see only crap
>> documentation on this and also random crap adhoc patches.
> I agree that the research into bufferbloat has been an evolving topic, and
> the existing documentation and solutions throughout the web is inaccurate
> or just plan wrong in many respects. While I've been accumulating better
> and more interesting results as research continues, we're not there yet...
>
>> Given that I
>> see effort on netdev to try to help with latency issues its important
>> for netdev developers to be aware of what issues we do face today and
>> what stuff is being mucked with.
> Hear, Hear!
>
>> As far as I see it I break down the issues into two categories:
>>
>> * 1. High latencies on ping
>> * 2. Constant small drops in throughput
> I'll take on 2, in a separate email.
>
>> 1. High latencies on ping
>> ===================
> For starters, no, "high - and wildly varying - latencies on all sorts
> of packets".
>
> Ping is merely a diagnostic tool in this case.
>
> If you would like several gb of packet captures of all sorts of streams
> from various places and circumstances, ask. JG published a long
> series about 7 months back, more are coming.
>
> Regrettably most of the most recent traces come from irreproducible
> circumstances, a flaw we are trying to fix after 'CeroWrt' is finished.
>
>> It seems the bufferbloat folks are blaming the high latencies on our
>> obsession on modern hardware to create huge queues and also with
>> software retries. They assert that reducing the queue length
>> (ATH_MAX_QDEPTH on ath9k) and software retries (ATH_MAX_SW_RETRIES on
>> ath9k) helps with latencies. They have at least empirically tested
>> this with ath9k with
>> a simple patch:
The retries in wireless interact here only because they have encouraged
buffering for the retries. This is not unique to 802.11, but also
present in 3g networks (there, they fragment packets and put in lots of
buffering hoping to get the packet fragment transmitted at some future
time; they really hate dropping a packet if only a piece got damaged.
>> https://www.bufferbloat.net/attachments/43/580-ath9k_lowlatency.patch
>>
>> The obvious issue with this approach is it assumes STA mode of
>> operation, with an AP you do not want to reduce the queue size like
>> that. In fact because of the dynamic nature of 802.11 and the
> If there is any one assumption about the bufferbloat issue that people
> keep assuming we have, it's this one.
>
> In article after article, in blog post after blog post, people keep
> 'fixing' bufferbloat by setting their queues to very low values,
> and almost miraculously start seeing their QoS start working
> (which it does), and then they gleefully publish their results
> as recommendations, and then someone from the bufferbloat
> effort has to go and comment on that piece, whenever we
> notice, to straighten them out.
>
> In no presentation, no documentation, anywhere I know of,
> have we expressed that queuing as it works today
> is the right thing.
>
> More recently, JG got fed up and wrote these...
>
> http://gettys.wordpress.com/2011/07/06/rant-warning-there-is-no-single-right-answer-for-buffering-ever/
>
> http://gettys.wordpress.com/2011/07/09/rant-warning-there-is-no-single-right-answer-for-buffering-ever-part-2/
Yes, I got really frustrated....
>
> There has been no time, since the inception of the bufferbloat
> concept, have we had a fixed buffer size in any layer of the
> stack as even a potential solution.
Right now, we have typically 2 (large) buffers: the transmit queue and
the driver rings. Some hardware/software hides buffers in additional
places (e.g. on the OLPC X0-1, there are 4 packets in the wireless
module and 1 hidden in the driver itself. YMWV.
>
> And you just did applied that preconception to us again.
>
> My take on matters is that *unmanaged* buffer sizes > 1 is a
> problem. Others set the number higher.
>
> Of late, given what tools we have, we HAVE been trying to establish
> what *good baseline* queue sizes (txqueues, driver queues, etc)
> actually are for wireless under ANY circumstance that was
> duplicate-able.
>
> For the drivers JG was using last year, that answer was: 0.
>
> Actually, less than 0 would have been good, but that
> would have involved having tachyon emitters in the
> architecture.
Zero is what I set the transmit queue in my *experiments* ***only***
because I knew by that point the drivers underneath the transmit queue
had another 250 or so packets of buffering on the hardware I (and most
of you) have; I went and looked at quite a few Linux drivers, and
confirmed similar ring buffer sizes on Mac and Windows both empirically
and when possible from driver control panel information. At the
bandwidth delay product of my experiments, 250 packets is way more than
TCP will ever need. See:
http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-with-your-switch/
Most current ethernet and wireless drivers have that much in the
transmit rings today, on all operating systems that I've played with.
The hardware will typically support up to 4096 packet rings, but the
defaults in the drivers seem to be typically in the 200-300 packet range
(sometimes per queue).
Remember that any long lived TCP session (an "elephant" flow), will fill
any size buffer just before the bottleneck link in a path, given time.
It will fill the buffer at the rate at one packet/ack; in the traces I
took over cable modems you can watch the delay go up and up cleanly,
and up (in my case, to 1.2 seconds when they filled after of order 10
seconds. The same thing happens on 802.11 wireless, but its noisier in
my traces as I don't have a handy faraday cage ;-). An additional
problem, which was a huge surprise to everyone who studied the traces is
that congestion avoidance is getting terminally confused. And by
delaying packet drop (or ECN marking), TCP never slows down; it actually
continues to speed up (since current TCP algorithms typically do not
take notice of the RTT). The delay is so long that TCP's servo system is
no longer stable and it oscillates with a constant period. I have no
clue if this is at all related to the other periodic behaviour people
have noticed. If you think about it, the fact that the delay is several
orders of magnitude larger than the actual delay of the path makes it
less surprising than it might be.
Indeed there is no simple single right answer for buffering; it needs to
be dynamic, and ultimately we need to have AQM
even in hosts to control buffering (think about the case of two
different long lived TCP sessions over vastly different bandwidth/delay
paths). The gotcha is we don't have a AQM algorithm known to work in
the face of the highly dynamic bandwidth variation that is wireless;
classic RED does not
have the output bandwidth as a parameter in its algorithm. This was/is
the great surprise to me as I had always thought of AQM as a property of
internet routers, not hosts.
That buffering between the transmit queue is completely divorced from
driver buffering, when it needs to be treated together in some fashion.
What the "right" way to do that is, I don't know, though Andrew's
interview gave me some hope. And it needs to be dynamic, over (in the
802.11 case) at least 3 orders of magnitude.
This is a non-trivial, hard problem we have on our hands.
Computing the buffering in bytes is better than in packets; but since on
wireless multicast/broadcast is transmitted at a radically different
rate than other packets, I expect something based on time is really the
long term solution; and only the driver has any idea how long a packet
of a given flavour will likely take to transmit.
- Jim
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BQL crap and wireless
From: Adrian Chadd @ 2011-08-30 1:44 UTC (permalink / raw)
To: Jim Gettys
Cc: Luis R. Rodriguez, Dave Taht, Tom Herbert, linux-wireless,
Andrew McGregor, Matt Smith, Kevin Hayes, Derek Smithies, netdev
In-Reply-To: <4E5C3B47.1050809@freedesktop.org>
On 30 August 2011 09:22, Jim Gettys <jg@freedesktop.org> wrote:
Note: I'm knee deep in the aggregation TX/RX path at the present time
- I'm porting the atheros 802.11n TX aggregation code to FreeBSD.
> Computing the buffering in bytes is better than in packets; but since on
> wireless multicast/broadcast is transmitted at a radically different
> rate than other packets, I expect something based on time is really the
> long term solution; and only the driver has any idea how long a packet
> of a given flavour will likely take to transmit.
And the driver (hopefully!) can find out how long the packet -did-
take to transmit.
There are a bunch of different reasons for why the packet isn't
transmitting or why it can take so long. If (say) an aggregate has 10
hardware (long, short) retries at a high MCS rate, and then 10
software retries, that's up to 100 attempts at transmitting the
sub-frames in some way. It may also involve 10 attempts at an RTS
exchange. But it may also be 10 attempts at transmitting the -whole-
frame. In the case of a long aggregate (say the upper bounds of 4ms,
easily achievable when lower MCS rates are selected), this can take a
long time.
I'm occasionally seeing this in my testing, where the block-ack isn't
seen by the sender. The whole aggregate frame is thus retransmitted in
its entirety. This causes occasional bumps in the testing latency. The
obvious solution is to not form such large aggregates at lower MCS
rates but even single events have an impact on latency.
I'm not at the point yet where I can start tinkering with rate control
and queue management in this way but the idea of asking the rate
control code to manage per-node and overall airtime has crossed my
mind. Ie, the rate control code can see how successful transmissions
are to a given node (at given streams, rates, antenna configurations,
etc) and then enforce aggregate size and retransmission limits there.
Since a decision for any given node will affect the latency on all
subsequent nodes, it makes sense for the rate control code to keep a
global idea of the airtime involved as well as the (current) per-node
logic.
2c, which'll be more when I work the 11n TX A-MPDU kinks out in the
FreeBSD driver,
Adrian
^ permalink raw reply
* Re: BQL crap and wireless
From: Adrian Chadd @ 2011-08-30 1:48 UTC (permalink / raw)
To: Jim Gettys
Cc: Luis R. Rodriguez, Dave Taht, Tom Herbert, linux-wireless,
Andrew McGregor, Matt Smith, Kevin Hayes, Derek Smithies, netdev
In-Reply-To: <CAJ-Vmom_EwR31Z6r4VpSiKTwE+YXwmRwtwurzr5VUX6nnC67fg@mail.gmail.com>
.. Whilst knee-deep in it all, I should also mention things like
"transmission opportunity/beacon transmit time being enforced by
hardware" - ie, where the hardware stops a packet TX from occuring
because it would exceed the programmed TXOP window, or because it
would interfere with an upcoming beacon TX from the hostap.
Another 2c,
Adrian
^ permalink raw reply
* Re: BQL crap and wireless
From: Andrew McGregor @ 2011-08-30 1:59 UTC (permalink / raw)
To: Jim Gettys
Cc: Luis R. Rodriguez, Dave Taht, Tom Herbert, linux-wireless,
Matt Smith, Kevin Hayes, Derek Smithies,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4E5C3B47.1050809-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org>
On 30/08/2011, at 1:22 PM, Jim Gettys wrote:
> The gotcha is we don't have a AQM algorithm known to work in
> the face of the highly dynamic bandwidth variation that is wireless
It's worse than highly dynamic... the bandwidth may be completely undefined moment to moment, as it is dependent on both the wireless environment, which varies on timescales that can be about equal to a packet transmit time, and on the traffic mix. There's about 30 ms of correlation time at best.
> This was/is
> the great surprise to me as I had always thought of AQM as a property of
> internet routers, not hosts.
There's no distinction in the forwarding plane, every router is a host, every host is a router.
Andrew--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH -next] net: fix Makefile typos & build errors
From: Stephen Rothwell @ 2011-08-30 1:59 UTC (permalink / raw)
To: Randy Dunlap; +Cc: netdev, linux-next, LKML, davem
In-Reply-To: <20110829114940.4d29febc.rdunlap@xenotime.net>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
Hi all,
On Mon, 29 Aug 2011 11:49:40 -0700 Randy Dunlap <rdunlap@xenotime.net> wrote:
>
> @@ -44,10 +44,10 @@ obj-$(CONFIG_PPP_SYNC_TTY) += ppp/
> obj-$(CONFIG_PPPOE) += ppp/
> obj-$(CONFIG_PPPOL2TP) += ppp/
> obj-$(CONFIG_PPTP) += ppp/
> -onj-$(CONFIG_SLIP) += slip/
> +obj-$(CONFIG_SLIP) += slip/
> obj-$(CONFIG_SLHC) += slip/
> obj-$(CONFIG_NET_SB1000) += sb1000.o
> -onj-$(CONFIG_SLIP) += slip/
> +obj-$(CONFIG_SLIP) += slip/
It may be my old(er) eyes, but isn't that CONFIG_SLIP line repeated?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: BQL crap and wireless
From: Jim Gettys @ 2011-08-30 2:12 UTC (permalink / raw)
To: Andrew McGregor
Cc: Luis R. Rodriguez, Dave Taht, Tom Herbert, linux-wireless,
Matt Smith, Kevin Hayes, Derek Smithies, netdev
In-Reply-To: <903AA8A8-9ACD-44FB-9BA8-50137359EC2B@gmail.com>
On 08/29/2011 09:59 PM, Andrew McGregor wrote:
> On 30/08/2011, at 1:22 PM, Jim Gettys wrote:
>
>> The gotcha is we don't have a AQM algorithm known to work in
>> the face of the highly dynamic bandwidth variation that is wireless
> It's worse than highly dynamic... the bandwidth may be completely undefined moment to moment, as it is dependent on both the wireless environment, which varies on timescales that can be about equal to a packet transmit time, and on the traffic mix. There's about 30 ms of correlation time at best.
Yup. It makes ethernet look trivial. If we can handle buffers there,
everywhere else is easy by comparison.
>> This was/is
>> the great surprise to me as I had always thought of AQM as a property of
>> internet routers, not hosts.
> There's no distinction in the forwarding plane, every router is a host, every host is a router.
Exactly; but I hadn't thought this through to hosts, nor, I think had
many other people. Naive me, having been scarred by '90's congestion,
was aware of RED, and roughly how it worked, but always thought of AQM
as something you did in routers. Realising that in principle I needed
it turned on in my laptop was not something I expected.
- Jim
^ permalink raw reply
* Re: [PATCH 19/24] sunrpc: Remove unnecessary OOM logging messages
From: David Miller @ 2011-08-30 2:35 UTC (permalink / raw)
To: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA
Cc: bharrosh-C4P08NqkoRlBDgjK7y7TUQ, joe-6d6DIl74uiNBDgjK7y7TUQ,
bfields-uC3wQj2KruNg9hUCZPvPmw, neilb-l3A5Bk7waGM,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2E1EB2CF9ED1CB4AA966F0EB76EAB4430AEB4FAF-hX7t0kiaRRrlMGe9HJ1VYQK/GNPrWCqfQQ4Iyu8u01E@public.gmane.org>
From: "Myklebust, Trond" <Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>
Date: Mon, 29 Aug 2011 16:25:08 -0700
> I can see that slub.c has the slab_out_of_memory() function that
> (although ratelimited) warns you if the allocation failed. However I
> can't find any equivalent for slab.c or slob.c.
See the page allocator.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/5] qlcnic: Bug fixes
From: David Miller @ 2011-08-30 2:53 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1314658231-30735-6-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Mon, 29 Aug 2011 15:50:31 -0700
> Please apply to net-next.
Applied, thanks.
I would like to suggest that you move away from driver internal
debug logging macros and either use existing generic kernel
facilities that exist or extend what exists so that it fits
your needs and others can enjoy the improvements too.
Thanks.
^ permalink raw reply
* Re: [PATCH -next] net: fix Makefile typos & build errors
From: David Miller @ 2011-08-30 2:55 UTC (permalink / raw)
To: sfr; +Cc: rdunlap, netdev, linux-next, linux-kernel
In-Reply-To: <20110830115925.45984bb8eeb73401dd5d289f@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 30 Aug 2011 11:59:25 +1000
> It may be my old(er) eyes, but isn't that CONFIG_SLIP line repeated?
My old eyes can confirm this, so I'll fix it up, thanks! :-)
^ permalink raw reply
* Re: linux-next: Tree for Aug 29 (bnx2x)
From: David Miller @ 2011-08-30 2:57 UTC (permalink / raw)
To: rdunlap; +Cc: dmitry, sfr, netdev, linux-next, linux-kernel, eilong
In-Reply-To: <20110829155618.01a73cce.rdunlap@xenotime.net>
From: Randy Dunlap <rdunlap@xenotime.net>
Date: Mon, 29 Aug 2011 15:56:18 -0700
> On Tue, 30 Aug 2011 00:35:44 +0300 Dmitry Kravkov wrote:
>
>> On Mon, 2011-08-29 at 13:28 -0700, Randy Dunlap wrote:
>> > On Mon, 29 Aug 2011 16:19:07 +1000 Stephen Rothwell wrote:
>> >
>> > > Hi all,
>> >
>> > (on i386 or x86_64)
>> >
>> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:10148: error: 'bnx2x_fcoe_get_wwn' undeclared here (not in a function)
>> >
>> >
>> > Full randconfig file is attached.
>> >
>> > ---
>> > ~Randy
>> > *** Remember to use Documentation/SubmitChecklist when testing your code ***
>> This should sync #define structures between definition and declaration
>> ---
>>
>> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
>> Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
>
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Applied, thanks everyone.
^ 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