[PATCH 0/5] NetXen: Driver bug fixes
Hi All, I will be sending updates to NetXen: 1G/10G Ethernet driver in subsequent mails. The patches will be with respect to netdev#upstream. Regards, Mithlesh Thukral - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] NetXen: Fix softlock seen on some machines during hardware writes
NetXen: This will fix a softlock seen on some machines.
The reason was too much time was spent waiting for writes to go through.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |1 +
drivers/net/netxen/netxen_nic_ethtool.c |1 +
drivers/net/netxen/netxen_nic_init.c| 11 +--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 38d7409..c85c2cb 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -236,6 +236,7 @@ #define MPORT_MULTI_FUNCTION_MODE 0x
#include "netxen_nic_phan_reg.h"
extern unsigned long long netxen_dma_mask;
+extern unsigned long last_schedule_time;
/*
* NetXen host-peg signal message structure
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 3752d2a..d49a7d8 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -455,6 +455,7 @@ netxen_nic_set_eeprom(struct net_device
}
printk(KERN_INFO "%s: flash unlocked. \n",
netxen_nic_driver_name);
+ last_schedule_time = jiffies;
ret = netxen_flash_erase_secondary(adapter);
if (ret != FLASH_SUCCESS) {
printk(KERN_ERR "%s: Flash erase failed.\n",
diff --git a/drivers/net/netxen/netxen_nic_init.c
b/drivers/net/netxen/netxen_nic_init.c
index b2e776f..53ca21e 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -42,6 +42,8 @@ struct crb_addr_pair {
u32 data;
};
+unsigned long last_schedule_time;
+
#define NETXEN_MAX_CRB_XFORM 60
static unsigned int crb_addr_xform[NETXEN_MAX_CRB_XFORM];
#define NETXEN_ADDR_ERROR (0x)
@@ -404,9 +406,14 @@ static inline int do_rom_fast_write(stru
static inline int
do_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp)
{
+ if (jiffies > (last_schedule_time + (8 * HZ))) {
+ last_schedule_time = jiffies;
+ schedule();
+ }
+
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ADDRESS, addr);
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 3);
- udelay(70); /* prevent bursting on CRB */
+ udelay(100);/* prevent bursting on CRB */
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_DUMMY_BYTE_CNT, 0);
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_INSTR_OPCODE, 0xb);
if (netxen_wait_rom_done(adapter)) {
@@ -415,7 +422,7 @@ do_rom_fast_read(struct netxen_adapter *
}
/* reset abyte_cnt and dummy_byte_cnt */
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 0);
- udelay(70); /* prevent bursting on CRB */
+ udelay(100);/* prevent bursting on CRB */
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_DUMMY_BYTE_CNT, 0);
*valp = netxen_nic_reg_read(adapter, NETXEN_ROMUSB_ROM_RDATA);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] NetXen: Update the statistics counter for interrupts
NetXen: Update the statistics counter for interrupts which have occured.
Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic_main.c |1 +
1 files changed, 1 insertion(+)
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index bfeca9a..5fbf6b0 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -1023,6 +1023,7 @@ netxen_handle_int(struct netxen_adapter
u32 ret = 0;
DPRINTK(INFO, "Entered handle ISR\n");
+ adapter->stats.ints++;
if (!(adapter->flags & NETXEN_NIC_MSI_ENABLED)) {
int count = 0;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] NetXen: Fix the driver for reduced PCIE footprint cards
NetXen: Fix the driver for reduced PCIE footprint cards.
Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |8 +-
drivers/net/netxen/netxen_nic_hdr.h |2 +
drivers/net/netxen/netxen_nic_main.c | 30 -
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index c85c2cb..d5e9d46 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -770,6 +770,8 @@ struct netxen_hardware_context {
void __iomem *pci_base2;
void __iomem *db_base;
unsigned long db_len;
+ unsigned long first_page_group_start;
+ unsigned long first_page_group_end;
u8 revision_id;
u16 board_type;
@@ -946,7 +948,8 @@ #define PCI_OFFSET_THIRD_RANGE(adapter,
static inline void __iomem *pci_base_offset(struct netxen_adapter *adapter,
unsigned long off)
{
- if ((off < FIRST_PAGE_GROUP_END) && (off >= FIRST_PAGE_GROUP_START)) {
+ if ((off < adapter->ahw.first_page_group_end) &&
+ (off >= adapter->ahw.first_page_group_start)) {
return (adapter->ahw.pci_base0 + off);
} else if ((off < SECOND_PAGE_GROUP_END) &&
(off >= SECOND_PAGE_GROUP_START)) {
@@ -961,7 +964,8 @@ static inline void __iomem *pci_base_off
static inline void __iomem *pci_base(struct netxen_adapter *adapter,
unsigned long off)
{
- if ((off < FIRST_PAGE_GROUP_END) && (off >= FIRST_PAGE_GROUP_START)) {
+ if ((off < adapter->ahw.first_page_group_end) &&
+ (off >= adapter->ahw.first_page_group_start)) {
return adapter->ahw.pci_base0;
} else if ((off < SECOND_PAGE_GROUP_END) &&
(off >= SECOND_PAGE_GROUP_START)) {
diff --git a/drivers/net/netxen/netxen_nic_hdr.h
b/drivers/net/netxen/netxen_nic_hdr.h
index b826bca..20dbebc 100644
--- a/drivers/net/netxen/netxen_nic_hdr.h
+++ b/drivers/net/netxen/netxen_nic_hdr.h
@@ -467,6 +467,8 @@ #define NETXEN_PCI_OCM0_MAX (0x050fU
#define NETXEN_PCI_OCM1(0x0510UL)
#define NETXEN_PCI_OCM1_MAX(0x051fUL)
#define NETXEN_PCI_CRBSPACE(0x0600UL)
+#define NETXEN_PCI_128MB_SIZE (0x0800UL)
+#define NETXEN_PCI_32MB_SIZE (0x0200UL)
#define NETXEN_CRB_CAM NETXEN_PCI_CRB_WINDOW(NETXEN_HW_PX_MAP_CRB_CAM)
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index 5fbf6b0..121a5f9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -174,6 +174,7 @@ netxen_nic_probe(struct pci_dev *pdev, c
u8 __iomem *db_ptr = NULL;
unsigned long mem_base, mem_len, db_base, db_len;
+ unsigned long first_page_group_start, first_page_group_end;
int pci_using_dac, i = 0, err;
int ring;
struct netxen_recv_context *recv_ctx = NULL;
@@ -237,13 +238,28 @@ netxen_nic_probe(struct pci_dev *pdev, c
mem_len = pci_resource_len(pdev, 0);
/* 128 Meg of memory */
- mem_ptr0 = ioremap(mem_base, FIRST_PAGE_GROUP_SIZE);
- mem_ptr1 =
- ioremap(mem_base + SECOND_PAGE_GROUP_START, SECOND_PAGE_GROUP_SIZE);
- mem_ptr2 =
- ioremap(mem_base + THIRD_PAGE_GROUP_START, THIRD_PAGE_GROUP_SIZE);
+ if (mem_len == NETXEN_PCI_128MB_SIZE) {
+ mem_ptr0 = ioremap(mem_base, FIRST_PAGE_GROUP_SIZE);
+ mem_ptr1 = ioremap(mem_base + SECOND_PAGE_GROUP_START,
+ SECOND_PAGE_GROUP_SIZE);
+ mem_ptr2 = ioremap(mem_base + THIRD_PAGE_GROUP_START,
+ THIRD_PAGE_GROUP_SIZE);
+ first_page_group_start = FIRST_PAGE_GROUP_START;
+ first_page_group_end = FIRST_PAGE_GROUP_END;
+ } else if (mem_len == NETXEN_PCI_32MB_SIZE) {
+ mem_ptr1 = ioremap(mem_base, SECOND_PAGE_GROUP_SIZE);
+ mem_ptr2 = ioremap(mem_base + THIRD_PAGE_GROUP_START -
+ SECOND_PAGE_GROUP_START, THIRD_PAGE_GROUP_SIZE);
+ first_page_group_start = 0;
+ first_page_group_end = 0;
+ } else {
+ DPRINTK(1, ERR, "Invalid PCI memory mapped length\n");
+ err = -EIO;
+ goto err_out_free_res;
+ }
- if ((mem_ptr0 == 0UL) || (mem_ptr1 == 0UL) || (mem_ptr2 == 0UL)) {
+ if (((mem_ptr0 == 0UL) && (mem_len == NETXEN_PCI_128MB_SIZE))
+ || (mem_ptr1 == 0UL) || (mem_ptr2 == 0UL)) {
DPRINTK(ERR,
"Cannot remap adapter memory aborting.:"
"0 -> %p, 1 -> %p, 2 -> %p\n",
@@ -379,6 +395,8 @@ #endif
adapter->cmd_buf_arr = cmd_buf_arr;
adapter->ahw.pci_base0 = mem_ptr0;
+ adapter->ahw.first_page_group_start = first_page_group_start;
+
[PATCH 4/5] NetXen: Fix the reading of MAC adddress during probe
NetXen: Fix the reading of MAC adddress during probe
Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic_main.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c
b/drivers/net/netxen/netxen_nic_main.c
index 121a5f9..7c27f15 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -451,7 +451,7 @@ #endif
valid_mac = 0;
if (valid_mac) {
- unsigned char *p = (unsigned char *)&mac_addr[i];
+ unsigned char *p = (unsigned char *)&mac_addr[adapter->portnum];
netdev->dev_addr[0] = *(p + 5);
netdev->dev_addr[1] = *(p + 4);
netdev->dev_addr[2] = *(p + 3);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] NetXen: Fix the setup of resources for hardware on multi port cards
NetXen: Fix the setup of resources for hardware on multi port cards. Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]> --- drivers/net/netxen/netxen_nic_hw.c |8 +--- drivers/net/netxen/netxen_nic_phan_reg.h |6 +++--- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/net/netxen/netxen_nic_hw.c b/drivers/net/netxen/netxen_nic_hw.c index 81ebc81..4ce33d8 100644 --- a/drivers/net/netxen/netxen_nic_hw.c +++ b/drivers/net/netxen/netxen_nic_hw.c @@ -294,6 +294,7 @@ int netxen_nic_hw_resources(struct netxe u32 card_cmdring = 0; struct netxen_recv_context *recv_ctx; struct netxen_rcv_desc_ctx *rcv_desc; + int func_id = adapter->portnum; DPRINTK(INFO, "crb_base: %lx %x", NETXEN_PCI_CRBSPACE, PCI_OFFSET_SECOND_RANGE(adapter, NETXEN_PCI_CRBSPACE)); @@ -349,6 +350,7 @@ int netxen_nic_hw_resources(struct netxe } memset(addr, 0, sizeof(struct netxen_ring_ctx)); adapter->ctx_desc = (struct netxen_ring_ctx *)addr; + adapter->ctx_desc->ctx_id = adapter->portnum; adapter->ctx_desc->cmd_consumer_offset = cpu_to_le64(adapter->ctx_desc_phys_addr + sizeof(struct netxen_ring_ctx)); @@ -418,11 +420,11 @@ int netxen_nic_hw_resources(struct netxe /* Window = 1 */ writel(lower32(adapter->ctx_desc_phys_addr), - NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_ADDR_REG_LO)); + NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_ADDR_REG_LO(func_id))); writel(upper32(adapter->ctx_desc_phys_addr), - NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_ADDR_REG_HI)); + NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_ADDR_REG_HI(func_id))); writel(NETXEN_CTX_SIGNATURE, - NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_SIGNATURE_REG)); + NETXEN_CRB_NORMALIZE(adapter, CRB_CTX_SIGNATURE_REG(func_id))); return err; } diff --git a/drivers/net/netxen/netxen_nic_phan_reg.h b/drivers/net/netxen/netxen_nic_phan_reg.h index f7eb627..97e34e6 100644 --- a/drivers/net/netxen/netxen_nic_phan_reg.h +++ b/drivers/net/netxen/netxen_nic_phan_reg.h @@ -151,9 +151,9 @@ #else extern struct netxen_recv_crb recv_crb_registers[]; extern u64 ctx_addr_sig_regs[][3]; #endif /* DEFINE_GLOBAL_RECEIVE_CRB */ -#define CRB_CTX_ADDR_REG_LO(ctx_addr_sig_regs[0][0]) -#define CRB_CTX_ADDR_REG_HI(ctx_addr_sig_regs[0][2]) -#define CRB_CTX_SIGNATURE_REG (ctx_addr_sig_regs[0][1]) +#define CRB_CTX_ADDR_REG_LO(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][0]) +#define CRB_CTX_ADDR_REG_HI(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][2]) +#define CRB_CTX_SIGNATURE_REG(FUNC_ID) (ctx_addr_sig_regs[FUNC_ID][1]) /* * Temperature control. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8132] New: pptp server lockup in ppp_asynctty_receive()
Could this be done with: CONFIG_PROVE_LOCKING = y CONFIG_4KSTACKS = n and, if possible, to send the first full lockdep error message with some lines before it? It would be nice to try to be more exact when hand writing, too. Regards, Jarek P. I already have CONFIG_PROVE_LOCKING=y # CONFIG_4KSTACKS is not set .config is at http://bugzilla.kernel.org/attachment.cgi?id=10660&action=view Also all information i've provied was recieved by serial console and it's not hand writing. I've checked logs and right before lockup there is oops in syslog Mar 5 21:50:44 vpn2 skb_under_panic: text:c02248a2 len:207 put:1 head:db96e22c data:db96e22b tail:db96e2fa end:db96e82c dev: Mar 5 21:50:44 vpn2 [ cut here ] Mar 5 21:50:44 vpn2 kernel BUG at net/core/skbuff.c:112! Mar 5 21:50:44 vpn2 invalid opcode: [#1] Mar 5 21:50:44 vpn2 SMP Mar 5 21:50:44 vpn2 Modules linked in: 8021q ipt_TCPMSS xt_tcpudp xt_pkttype iptable_filter ip_tables x_tables i2c_i801 i2c_core Mar 5 21:50:44 vpn2 CPU:1 Mar 5 21:50:44 vpn2 EIP:0060:[]Not tainted VLI Mar 5 21:50:44 vpn2 EFLAGS: 00010092 (2.6.20-gentoo #10) Mar 5 21:50:44 vpn2 EIP is at skb_under_panic+0x59/0x5d Mar 5 21:50:44 vpn2 eax: 0072 ebx: db96e22c ecx: 0001 edx: de20d4d0 Mar 5 21:50:44 vpn2 esi: edi: db96e2fc ebp: dc5ab2e8 esp: dcaf5e84 Mar 5 21:50:44 vpn2 ds: 007b es: 007b ss: 0068 Mar 5 21:50:44 vpn2 Process pptpctrl (pid: 5203, ti=dcaf4000 task=de20d4d0 task.ti=dcaf4000) Mar 5 21:50:44 vpn2 Stack: c0315e34 c02248a2 00cf 0001 db96e22c db96e22b db96e2fa db96e82c Mar 5 21:50:44 vpn2 c0301eef 0004 c02248b0 de20d4d0 de20da04 de20d4d0 Mar 5 21:50:44 vpn2 db96e22b 00cf de3e28f0 de3e2884 ddae82ac de3e2854 0296 Mar 5 21:50:44 vpn2 Call Trace: Mar 5 21:50:44 vpn2 [] ppp_asynctty_receive+0x6d2/0x710 Mar 5 21:50:44 vpn2 [] ppp_asynctty_receive+0x6e0/0x710 Mar 5 21:50:44 vpn2 [] pty_write+0x39/0x41 Mar 5 21:50:44 vpn2 [] write_chan+0x212/0x320 Mar 5 21:50:44 vpn2 [] default_wake_function+0x0/0xc Mar 5 21:50:44 vpn2 [] tty_write+0x11c/0x1d0 Mar 5 21:50:44 vpn2 [] write_chan+0x0/0x320 Mar 5 21:50:44 vpn2 [] vfs_write+0x87/0xf0 Mar 5 21:50:44 vpn2 [] tty_write+0x0/0x1d0 Mar 5 21:50:44 vpn2 [] sys_write+0x41/0x6a Mar 5 21:50:44 vpn2 [] sysenter_past_esp+0x5f/0x99 Mar 5 21:50:44 vpn2 === Mar 5 21:50:44 vpn2 Code: 00 00 89 5c 24 14 8b 98 8c 00 00 00 89 5c 24 10 89 54 24 0c 8b 40 60 89 44 24 08 89 4c 24 04 c7 04 24 34 5e 31 c0 e8 8e e4 ec ff <0 f> 0b eb fe 56 53 83 ec 24 8b 70 14 bb ef 1e 30 c0 85 f6 0f 45 Mar 5 21:50:44 vpn2 EIP: [] skb_under_panic+0x59/0x5d SS:ESP 0068:dcaf5e84 Another thing - when i`ve changed HZ from 100 too 300 there is no such lockups for few days. Jura - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8132] New: pptp server lockup in ppp_asynctty_receive()
On Fri, Mar 09, 2007 at 11:40:04AM +0300, Yuriy N. Shkandybin wrote: ... > I already have > CONFIG_PROVE_LOCKING=y > # CONFIG_4KSTACKS is not set > .config is at > http://bugzilla.kernel.org/attachment.cgi?id=10660&action=view > Also all information i've provied was recieved by serial console and it's > not hand writing. Maybe you cut too much (lines before a bug could be meaningful - if there are some secret data - try to mask only them). And there is no real lockdep diagnose, so I wasn't sure. Dump registers at the end looks incomplete (no ESP info), too. So, this all made me think - it's cut because it's from the screen. Very sorry!!! > I've checked logs and right before lockup there is oops in syslog > Mar 5 21:50:44 vpn2 skb_under_panic: text:c02248a2 len:207 put:1 As a matter of fact the first bug is the most interesting and everything after could be only some aftereffect. This skb_under_panic message could change all diagnose: it's not necessarily a locking problem. On the other hand this could be even harder to diagnose than locking... > head:db96e22c data:db96e22b tail:db96e2fa end:db96e82c dev: > Mar 5 21:50:44 vpn2 [ cut here ] Why?! We don't even know if there was some config pending here. > Mar 5 21:50:44 vpn2 kernel BUG at net/core/skbuff.c:112! ... > Another thing - when i`ve changed HZ from 100 too 300 there is no such > lockups for few days. You wrote it had been since several kernel releases, so it shouldn't be the case, but anyway - it would be interesting to check HZ 100 but with clean and more current kernel version e.g. 2.6.21-rc3. Thanks & regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.19/2.6.20 BUG in inet_rtm_newaddr()/__inet_insert_ifa()
Try this: ip addr add 172.18.12.99/21 dev dummy0 ip addr add broadcast 172.18.15.255 dev dummy0 kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 kernel: printing eip: kernel: c04bc331 kernel: *pde = kernel: Oops: [#1] kernel: SMP kernel: Modules linked in: kernel: CPU:0 kernel: EIP:0060:[]Not tainted VLI kernel: EFLAGS: 00010292 (2.6.20.1-y150 #1) kernel: EIP is at __inet_insert_ifa+0x11/0x150 kernel: eax: ebx: ecx: 3984 edx: f709f6a0 kernel: esi: d6f5429c edi: c04bc8a0 ebp: d3f41c2c esp: d3f41c04 kernel: ds: 007b es: 007b ss: 0068 kernel: Process ip (pid: 14724, ti=d3f4 task=f647a030 task.ti=d3f4) kernel: Stack: f709f6b8 3984 f709f6a0 f709f6a0 kernel:d6f5429c c04bc8a0 d3f41c48 c04bc8da 0046 c045e360 f709f6a0 kernel:0004 d3f41c7c c046c19e 0001 0046 0044 0001 kernel: Call Trace: kernel: [] show_trace_log_lvl+0x19/0x30 kernel: [] show_stack_log_lvl+0x8b/0xb0 kernel: [] show_registers+0x1b5/0x2d0 kernel: [] die+0x10f/0x240 kernel: [] do_page_fault+0x342/0x610 kernel: [] error_code+0x7c/0x90 kernel: [] inet_rtm_newaddr+0x3a/0x70 kernel: [] rtnetlink_rcv_msg+0x17e/0x240 kernel: [] netlink_rcv_skb+0x2d/0x70 kernel: [] netlink_run_queue+0x35/0x80 kernel: [] rtnetlink_rcv+0x29/0x50 kernel: [] netlink_data_ready+0x58/0x60 kernel: [] netlink_sendskb+0x1f/0x40 kernel: [] netlink_unicast+0x131/0x140 kernel: [] netlink_sendmsg+0x1fa/0x270 kernel: [] sock_sendmsg+0xba/0xf0 kernel: [] sys_sendmsg+0x13f/0x250 kernel: [] sys_socketcall+0x225/0x230 kernel: [] syscall_call+0x7/0xb kernel: === kernel: Code: c7 44 24 04 00 00 00 00 c7 04 24 00 00 00 00 e8 c6 fd ff ff c9 c3 8d 74 26 00 55 89 e5 57 56 53 83 ec 1c 89 55 f0 89 4d ec 89 c3 <8b> 78 04 e8 77 ea fa ff 85 c0 0f 85 ff 00 00 00 8b 43 10 89 45 kernel: EIP: [] __inet_insert_ifa+0x11/0x150 SS:ESP 0068:d3f41c04 -- Frank - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19/2.6.20 BUG in inet_rtm_newaddr()/__inet_insert_ifa()
On Fri, Mar 09, 2007 at 11:33:33AM +0100, Frank van Maarseveen ([EMAIL
PROTECTED]) wrote:
> Try this:
>
> ip addr add 172.18.12.99/21 dev dummy0
> ip addr add broadcast 172.18.15.255 dev dummy0
Attached patch fixes the problem.
nlmsg_parse() in rtm_to_ifaddr() sucessfully returns zero, but
subsequent check for prefix len and LOCAL ifa fails, so NULL is returned
instead of negative error value embedded in the pointer which is
expected by error logic in inet_rtm_newaddr().
---
Return negative error value (embedded in the pointer) instead of returning NULL.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index e10794d..98a00d0 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -502,8 +502,10 @@ static struct in_ifaddr *rtm_to_ifaddr(struct nlmsghdr
*nlh)
goto errout;
ifm = nlmsg_data(nlh);
- if (ifm->ifa_prefixlen > 32 || tb[IFA_LOCAL] == NULL)
+ if (ifm->ifa_prefixlen > 32 || tb[IFA_LOCAL] == NULL) {
+ err = -EINVAL;
goto errout;
+ }
dev = __dev_get_by_index(ifm->ifa_index);
if (dev == NULL) {
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8132] New: pptp server lockup in ppp_asynctty_receive()
On Fri, Mar 09, 2007 at 11:40:04AM +0300, Yuriy N. Shkandybin wrote: ... > .config is at > http://bugzilla.kernel.org/attachment.cgi?id=10660&action=view > Also all information i've provied was recieved by serial console and it's > not hand writing. > > I've checked logs and right before lockup there is oops in syslog > Mar 5 21:50:44 vpn2 skb_under_panic: text:c02248a2 len:207 put:1 > head:db96e22c data:db96e22b tail:db96e2fa end:db96e82c dev: This looks like a real problem with skb and maybe with dev->hard_header_len. I see you are using vlan module, so maybe there is some interaction? I don't know ppp enough, so I CC this message to the ppp list. I'm not sure HZ change will cure this forever (maybe some packets are going to the wrong dev?). If you're willing to experiment, you can try to edit "include/linux/ppp_defs.h" and change it like this: #define PPP_HDRLEN 8 #define PPP_MRU 1496 and "include/linux/if_ppp.h": #define PPP_MTU 1496 plus mru/mtu in your pppd config (and recompile). But I hope ppp people will propose something better. Cheers, Jarek P. > Mar 5 21:50:44 vpn2 [ cut here ] > Mar 5 21:50:44 vpn2 kernel BUG at net/core/skbuff.c:112! > Mar 5 21:50:44 vpn2 invalid opcode: [#1] > Mar 5 21:50:44 vpn2 SMP > Mar 5 21:50:44 vpn2 Modules linked in: 8021q ipt_TCPMSS xt_tcpudp > xt_pkttype iptable_filter ip_tables x_tables i2c_i801 i2c_core > Mar 5 21:50:44 vpn2 CPU:1 > Mar 5 21:50:44 vpn2 EIP:0060:[]Not tainted VLI > Mar 5 21:50:44 vpn2 EFLAGS: 00010092 (2.6.20-gentoo #10) > Mar 5 21:50:44 vpn2 EIP is at skb_under_panic+0x59/0x5d > Mar 5 21:50:44 vpn2 eax: 0072 ebx: db96e22c ecx: 0001 edx: > de20d4d0 > Mar 5 21:50:44 vpn2 esi: edi: db96e2fc ebp: dc5ab2e8 esp: > dcaf5e84 > Mar 5 21:50:44 vpn2 ds: 007b es: 007b ss: 0068 > Mar 5 21:50:44 vpn2 Process pptpctrl (pid: 5203, ti=dcaf4000 task=de20d4d0 > task.ti=dcaf4000) > Mar 5 21:50:44 vpn2 Stack: c0315e34 c02248a2 00cf 0001 db96e22c > db96e22b db96e2fa db96e82c > Mar 5 21:50:44 vpn2 c0301eef 0004 c02248b0 de20d4d0 de20da04 > de20d4d0 > Mar 5 21:50:44 vpn2 db96e22b 00cf de3e28f0 de3e2884 ddae82ac > de3e2854 0296 > Mar 5 21:50:44 vpn2 Call Trace: > Mar 5 21:50:44 vpn2 [] ppp_asynctty_receive+0x6d2/0x710 > Mar 5 21:50:44 vpn2 [] ppp_asynctty_receive+0x6e0/0x710 > Mar 5 21:50:44 vpn2 [] pty_write+0x39/0x41 > Mar 5 21:50:44 vpn2 [] write_chan+0x212/0x320 > Mar 5 21:50:44 vpn2 [] default_wake_function+0x0/0xc > Mar 5 21:50:44 vpn2 [] tty_write+0x11c/0x1d0 > Mar 5 21:50:44 vpn2 [] write_chan+0x0/0x320 > Mar 5 21:50:44 vpn2 [] vfs_write+0x87/0xf0 > Mar 5 21:50:44 vpn2 [] tty_write+0x0/0x1d0 > Mar 5 21:50:44 vpn2 [] sys_write+0x41/0x6a > Mar 5 21:50:44 vpn2 [] sysenter_past_esp+0x5f/0x99 > Mar 5 21:50:44 vpn2 === > Mar 5 21:50:44 vpn2 Code: 00 00 89 5c 24 14 8b 98 8c 00 00 00 89 5c 24 10 > 89 54 24 0c 8b 40 60 89 44 24 08 89 4c 24 04 c7 04 24 34 5e 31 c0 e8 8e e4 > ec ff <0 > f> 0b eb fe 56 53 83 ec 24 8b 70 14 bb ef 1e 30 c0 85 f6 0f 45 > Mar 5 21:50:44 vpn2 EIP: [] skb_under_panic+0x59/0x5d SS:ESP > 0068:dcaf5e84 > > Another thing - when i`ve changed HZ from 100 too 300 there is no such > lockups for few days. > > Jura > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1][UDP]: Use __skb_pull since we have checked it won't fail with pskb_may_pull
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> --- net/ipv4/udp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index ca35380..1bbf551 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -1002,7 +1002,7 @@ static int udp_encap_rcv(struct sock * sk, struct sk_buff *skb) * transport header to point to ESP. Keep UDP on the stack * for later. */ - skb->h.raw = skb_pull(skb, len); + skb->h.raw = __skb_pull(skb, len); /* modify the protocol (it's ESP!) */ iph->protocol = IPPROTO_ESP;
Fix for ipv6_setsockopt NULL dereference
I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155
Here's a potential fix.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
--
Fix NULL pointer derefence in ipv6_setsockopt, as described in bug #8155.
Signed-off-by: [EMAIL PROTECTED]
---
net/ipv6/ipv6_sockglue.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: build-2.6/net/ipv6/ipv6_sockglue.c
===
--- build-2.6.orig/net/ipv6/ipv6_sockglue.c
+++ build-2.6/net/ipv6/ipv6_sockglue.c
@@ -413,7 +413,7 @@ static int do_ipv6_setsockopt(struct soc
}
/* routing header option needs extra check */
- if (optname == IPV6_RTHDR && opt->srcrt) {
+ if (optname == IPV6_RTHDR && opt && opt->srcrt) {
struct ipv6_rt_hdr *rthdr = opt->srcrt;
switch (rthdr->type) {
case IPV6_SRCRT_TYPE_0:
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for ipv6_setsockopt NULL dereference
In article <[EMAIL PROTECTED]> (at Fri, 9 Mar 2007 15:15:54 +0100), Olaf Kirch <[EMAIL PROTECTED]> says: > I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155 : > Fix NULL pointer derefence in ipv6_setsockopt, as described in bug #8155. > > Signed-off-by: [EMAIL PROTECTED] Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> I also ack to push this to -stable. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about : [NET]: Replace CONFIG_NET_DEBUG with sysctl.
Eric Dumazet wrote: David Miller a écrit : From: Eric Dumazet <[EMAIL PROTECTED]> Date: Fri, 09 Mar 2007 07:34:15 +0100 I gently ask that any new sysctl is '__read_mostly' tagged. People are lazy because you are so gifted at finding this stuff :-) I seee ;) BTW I missed the patch on netdev, is it just me or netdev have problems ? My bad, forgot the CC in the patch cleanout yesterday - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TSO performance wrt 2.614
anandvelu thulasiram wrote: Hi all, I'm working on TCP segmentation Offload and I'm using Linux -2.6.14 kernel for this. I'm getting about a 6x increase in sending by turning off TCP segmentation offload. But When I turn on the TSO my performance is getting degraded. But when I switched back to Linux 2.6.9 kernel I'm getting 16Mbps more when TSO is enabled. Is there any TSO patch for linux-2.6.14. Which hardware and what is the network connection? It turns out that older versions of TSO were violating internet congestion control and not counting packets properly. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about : [NET]: Replace CONFIG_NET_DEBUG with sysctl.
Eric Dumazet wrote:
Hello David and Stephen
I see git commit 8e2101a9faab43dcf307d46784a1ede7997fe729
and its potential problems :
Here on my x86_64 machine :
806e7520 d rtnl_mutex
806e7538 D net_msg_cost
806e753c D net_msg_burst
806e7540 D net_msg_warn
806e7560 d lweventlist_lock
It probably is worth making a hot/cold map somehow. Ideally some
automated version
of something like oprofile uses (memprofile?)
So net_msg_{cost|burst|warn} are on two 'heavy' cachelines.
I gently ask that any new sysctl is '__read_mostly' tagged.
Why not all the old one's as well?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] NetXen: Update the statistics counter for interrupts
Linsys Contractor Mithlesh Thukral wrote: NetXen: Update the statistics counter for interrupts which have occured. Signed-off-by: Mithlesh Thukral <[EMAIL PROTECTED]> --- drivers/net/netxen/netxen_nic_main.c |1 + 1 files changed, 1 insertion(+) diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c index bfeca9a..5fbf6b0 100644 --- a/drivers/net/netxen/netxen_nic_main.c +++ b/drivers/net/netxen/netxen_nic_main.c @@ -1023,6 +1023,7 @@ netxen_handle_int(struct netxen_adapter u32 ret = 0; DPRINTK(INFO, "Entered handle ISR\n"); + adapter->stats.ints++; You may want to consider the cost of the additional cache miss. Either don't bother with this stat, or go to per-cpu stats. Plus isn't this already in the statistics kept for /proc/interrupts? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] NetXen: Fix softlock seen on some machines during hardware writes
Linsys Contractor Mithlesh Thukral wrote:
NetXen: This will fix a softlock seen on some machines.
The reason was too much time was spent waiting for writes to go through.
Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
---
drivers/net/netxen/netxen_nic.h |1 +
drivers/net/netxen/netxen_nic_ethtool.c |1 +
drivers/net/netxen/netxen_nic_init.c| 11 +--
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic.h b/drivers/net/netxen/netxen_nic.h
index 38d7409..c85c2cb 100644
--- a/drivers/net/netxen/netxen_nic.h
+++ b/drivers/net/netxen/netxen_nic.h
@@ -236,6 +236,7 @@ #define MPORT_MULTI_FUNCTION_MODE 0x
#include "netxen_nic_phan_reg.h"
extern unsigned long long netxen_dma_mask;
+extern unsigned long last_schedule_time;
/*
* NetXen host-peg signal message structure
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
b/drivers/net/netxen/netxen_nic_ethtool.c
index 3752d2a..d49a7d8 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -455,6 +455,7 @@ netxen_nic_set_eeprom(struct net_device
}
printk(KERN_INFO "%s: flash unlocked. \n",
netxen_nic_driver_name);
+ last_schedule_time = jiffies;
ret = netxen_flash_erase_secondary(adapter);
if (ret != FLASH_SUCCESS) {
printk(KERN_ERR "%s: Flash erase failed.\n",
diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
index b2e776f..53ca21e 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -42,6 +42,8 @@ struct crb_addr_pair {
u32 data;
};
+unsigned long last_schedule_time;
+
#define NETXEN_MAX_CRB_XFORM 60
static unsigned int crb_addr_xform[NETXEN_MAX_CRB_XFORM];
#define NETXEN_ADDR_ERROR (0x)
@@ -404,9 +406,14 @@ static inline int do_rom_fast_write(stru
static inline int
do_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp)
{
+ if (jiffies > (last_schedule_time + (8 * HZ))) {
+ last_schedule_time = jiffies;
+ schedule();
+ }
+
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ADDRESS, addr);
netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 3);
- udelay(70); /* prevent bursting on CRB */
+ udelay(100);/* prevent bursting on CRB */
To prevent PCI write posting issues, you should always do a dummy read
before
any delay.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] netxen: fix warnings
Ralf Baechle wrote: CC [M] drivers/net/netxen/netxen_nic_hw.o drivers/net/netxen/netxen_nic_hw.c: In function 'netxen_nic_hw_resources': drivers/net/netxen/netxen_nic_hw.c:231: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'dma_addr_t' drivers/net/netxen/netxen_nic_hw.c:250: warning: format '%llx' expects type 'long long unsigned int', but argument 2 has type 'dma_addr_t' u64 is unsigned long so the cast to u64 will result in a warning on the printf arguments for 64-bit builds. So cast to unsigned long long instead. Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] myri10ge: fix error checking and return value in myri10ge_allocate_rings
Brice Goglin wrote: Fix a missing error check in myri10ge_allocate_rings() and set status to -ENOMEM before all actual allocations so that the error path returns what it should. Signed-off-by: Brice Goglin <[EMAIL PROTECTED]> --- drivers/net/myri10ge/myri10ge.c |4 1 file changed, 4 insertions(+) applied 1-4 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mv643xx: Clear pending interrupts before calling request_irq
Dale Farnsworth wrote: From: Dale Farnsworth <[EMAIL PROTECTED]> Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]> Acked-by: Giridhar Pemmasani <[EMAIL PROTECTED]> --- Giri, thank you very much for reporting the problem and confirming the fix. Jeff, please apply. Andrew, this patch supersedes the -mm patch: mv643xx-ethernet-driver-irq-registration-fix.patch drivers/net/mv643xx_eth.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sky2: turn off Rx checksum on bad hardware
Stephen Hemminger wrote: On Yukon FE, occasional hardware receive checksum errors are seen. An early indication of the problem is single bit differences in the two checksum engines. Use this as a detection mechanism to turn off Rx checksumming. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- drivers/net/sky2.c | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] r8169: revert bogus BMCR reset
Francois Romieu wrote: Added during bf793295e1090af84972750898bf8470df5e5419 The current code requests a reset but prohibits autoneg, 1000 Mb/s, 100 Mb/s and full duplex. The 8168 does not like it at all. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> --- drivers/net/r8169.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied 1-2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spidernet: Fix problem sending IP fragments
Linas Vepstas wrote: Jeff, Please apply. The rather long patch description is from the submitter, Norbert Eicker, I don't know if that's alright, or if I should ask to have it trimmed. Thanks, --linas From: Norbert Eicker <[EMAIL PROTECTED]> I found out that the spidernet-driver is unable to send fragmented IP frames. Let me just recall the basic structure of "normal" UDP/IP/Ethernet frames (that actually work): - It starts with the Ethernet header (dest MAC, src MAC, etc.) - The next part is occupied by the IP header (version info, length of packet, id=0, fragment offset=0, checksum, from / to address, etc.) - Then comes the UDP header (src / dest port, length, checksum) - Actual payload - Ethernet checksum Now what's different for IP fragment: - The IP header has id set to some value (same for all fragments), offset is set appropriately (i.e. 0 for first fragment, following according to size of other fragments), size is the length of the frame. - UDP header is unchanged. I.e. length is according to full UDP datagram, not just the part within the actual frame! But this is only true within the first frame: all following frames don't have a valid UDP-header at all. The spidernet silicon seems to be quite intelligent: It's able to compute (IP / UDP / Ethernet) checksums on the fly and tests if frames are conforming to RFC -- at least conforming to RFC on complete frames. But IP fragments are different as explained above: I.e. for IP fragments containing part of a UDP datagram it sees incompatible length in the headers for IP and UDP in the first frame and, thus, skips this frame. But the content *is* correct for IP fragments. For all following frames it finds (most probably) no valid UDP header at all. But this *is* also correct for IP fragments. The Linux IP-stack seems to be clever in this point. It expects the spidernet to calculate the checksum (since the module claims to be able to do so) and marks the skb's for "normal" frames accordingly (ip_summed set to CHECKSUM_HW). But for the IP fragments it does not expect the driver to be capable to handle the frames appropriately. Thus all checksums are allready computed. This is also flaged within the skb (ip_summed set to CHECKSUM_NONE). Unfortunately the spidernet driver ignores that hints. It tries to send the IP fragments of UDP datagrams as normal UDP/IP frames. Since they have different structure the silicon detects them the be not "well-formed" and skips them. The following one-liner against 2.6.21-rc2 changes this behavior. If the IP-stack claims to have done the checksumming, the driver should not try to checksum (and analyze) the frame but send it as is. Signed-off-by: Norbert Eicker <[EMAIL PROTECTED]> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> are you sure it can't send out fragmented IP frames? what's really going on here? patch was corrupted anyway, and could not be applied... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bonding-devel] [PATCH 3/3] bonding: Improve IGMP join processing
On Tue, Mar 06, 2007 at 07:21:30PM -0800, David Stevens wrote:
> > >Marking the master down would, I believe, issue notifiers that
> > > the device has gone down. Various things, network manager sort of
> > > applications in particular, listen to those, so I'm not sure it's a
> good
> > > idea. I think there are other side effects as well, I'm thinking it
> > > would flush routes associated with the interface as well.
>
> [BTW, you can call ip_mc_down()/ip_mc_up() directly w/o getting there
> from the notifiers -- then no side-effects.]
>
While this might seem like a nice solution if we think only about what
would cause the smallest change to igmp.c (since you just need to add a
small patch to export additional symbols), I shudder to think about the
disruption that this could cause in the network in some cases.
> Andy Gospodarek wrote:
> >
> > I agree with Jay here. I hate that bonding has to have so much
> > knowledge about upper layer protocols, but for the ones that are
> > stateful like IGMP we will need fixes like the one proposed.
>
> I have no problem with bonding having knowledge of ULP's (I
> don't like it, but I don't have to look at it :-) ), but the
> patch is doing it the other way around. What I don't like about the
> proposed patch is that it's adding knowledge of bonding to IGMP.
I disagree with this statement. Why does adding an extra function to
aide in the transmission of additional igmp joins cause igmp to have
knowledge of bonding?
> And IGMP does work fine in this case, w/o flooding or the
> proposed patch. It just has the risk of losing multicast packets
> during one query interval, and that only happens if you're
> using a switch that does IGMP snooping.
I feel like igmp snooping is a pretty widely used feature and I would
guess that it is used by anyone doing a/b bonding that has concerns
about igmp failover.
> I'd like the patch a lot better if it were basicly this:
>
> mc_bond_fudge(void)
> {
> ip_mc_down(masterdev);
> /*do whatever you need to do to switch the slave */
> ip_mc_up(masterdev);
> }
>
> That doesn't go through the notifier chain, uses existing
> functions, doesn't have any refcnt issues, and most importantly
> could/should reside in a bonding source file and not in igmp.c. :-)
> But RTNL is required whether you use up/down or roll your
> own variant, so it sounds like you have other issues to resolve too.
The RTNL stuff would be all done work if Jay would just accept my
workqueue patch. ;-)
>
> +-DLS
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] NetXen: Driver bug fixes
Linsys Contractor Mithlesh Thukral wrote: Hi All, I will be sending updates to NetXen: 1G/10G Ethernet driver in subsequent mails. The patches will be with respect to netdev#upstream. Are you sure you don't want some of these in #upstream-fixes, queued for 2.6.21-rc? Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] 3c59x: Fix several modpost warnings
Ralf Baechle wrote: WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from .text between 'vortex_eisa_probe' (at offset 0x4580) and 'vortex_eisa_remove' WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from .text between 'vortex_eisa_probe' (at offset 0x4584) and 'vortex_eisa_remove' WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from .text between 'vortex_eisa_probe' (at offset 0x4588) and 'vortex_eisa_remove' WARNING: drivers/net/3c59x.o - Section mismatch: reference to .init.text: from .text between 'vortex_eisa_probe' (at offset 0x458c) and 'vortex_eisa_remove' Fixed by: o move definition of vortex_eisa_driver below the functions it references. o remove now unnecessary prototypes for vortex_eisa_probe and vortex_eisa_remove. o Make vortex_eisa_probe an __init function. o Make vortex_eisa_remove a __devexit function. o Wrap vortex_eisa_driver reference to vortex_eisa_remove with __devexit_p(). Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> drivers/net/3c59x.c | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) applied this and ibmtr patch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e1000: Use ARRAY_SIZE macro when appropriate
Auke Kok wrote: From: Ahmed S. Darwish <[EMAIL PROTECTED]> A patch to use ARRAY_SIZE macro already defined in kernel.h. Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000_ethtool.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied 1-3 to #upstream - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ixgb: Use ARRAY_SIZE macro when appropriate.
Auke Kok wrote: From: Ahmed S. Darwish <[EMAIL PROTECTED]> Signed-off-by: Ahmed S. Darwish <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/ixgb/ixgb_param.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] S2IO: Remove unused variables
Ramkrishna Vepa wrote: - Remove unused variables from s2io_nic structure - Changed the memory failure printk messages to print only in debug mode - Updated the copyright messages (Resending; forgot to cc netdev) Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]> patch #1 was corrupted, but technical content looks sane patch #2 was applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] pcnet32: only allocate init_block dma consistent
Don Fry wrote: The patch below moves the init_block out of the private struct and only allocates init block with pci_alloc_consistent. This has two effects: 1. Performance increase for non cache coherent machines, because the CPU only data in the private struct are now cached 2. locks are working now for platforms, which need to have locks in cached memory Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]> Acked-by: Don Fry <[EMAIL PROTECTED]> --- drivers/net/pcnet32.c | 77 ++--- 1 files changed, 34 insertions(+), 43 deletions(-) applied 1-2, with included trailing whitespace noise - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
rstp for 2.4 kernel: port state keeps changing
Hi, I am using RSTP for 2.4 kernel. I have created a loop between two bridges: P1 --- P1 BR1 BR2 P2 -- P2 BR2 is rinning linux bridge RSTP. BR1 is a Root running STP ( Netgear switch). The port P2 on BR2 go to Blocking state for a while, then got to Listening state, learning State, Forwarding state and then back to Blocking State. The same thing happen over and over. Any help is appreciated. Regrads, -Marc. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about : [NET]: Replace CONFIG_NET_DEBUG with sysctl.
This was what the patch was (complete with spulling error)...
Covert network warning messages from a compile time to runtime choice.
Removes kernel config option and replaces it with new
/proc/sys/net/core/warnings.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
Documentation/filesystems/proc.txt |9 +
include/linux/sysctl.h |1 +
include/net/sock.h | 12 +---
net/Kconfig|7 ---
net/core/sysctl_net_core.c |8
net/core/utils.c |2 ++
6 files changed, 25 insertions(+), 14 deletions(-)
--- net-2.6.22.orig/Documentation/filesystems/proc.txt 2007-03-08
11:23:38.0 -0800
+++ net-2.6.22/Documentation/filesystems/proc.txt 2007-03-08
11:26:10.0 -0800
@@ -1421,6 +1421,15 @@
be dropped. The default settings limit warning messages to one every five
seconds.
+warnings
+
+
+This controls console messages from the networking stack that can occur because
+of problems on the network like duplicate address or bad checksums. Normally,
+this should be enabled, but if the problem persists the messages can be
+disabled.
+
+
netdev_max_backlog
--
--- net-2.6.22.orig/include/linux/sysctl.h 2007-03-08 11:11:46.0
-0800
+++ net-2.6.22/include/linux/sysctl.h 2007-03-08 11:17:39.0 -0800
@@ -290,6 +290,7 @@
NET_CORE_BUDGET=19,
NET_CORE_AEVENT_ETIME=20,
NET_CORE_AEVENT_RSEQTH=21,
+ NET_CORE_WARNINGS=22,
};
/* /proc/sys/net/ethernet */
--- net-2.6.22.orig/include/net/sock.h 2007-03-08 11:06:36.0 -0800
+++ net-2.6.22/include/net/sock.h 2007-03-08 11:26:17.0 -0800
@@ -1333,14 +1333,12 @@
/*
* Enable debug/info messages
*/
+extern int net_msg_warn;
+#define NETDEBUG(fmt, args...) \
+ do { if (net_msg_warn) printk(fmt,##args); } while (0)
-#ifdef CONFIG_NETDEBUG
-#define NETDEBUG(fmt, args...) printk(fmt,##args)
-#define LIMIT_NETDEBUG(fmt, args...) do { if (net_ratelimit())
printk(fmt,##args); } while(0)
-#else
-#define NETDEBUG(fmt, args...) do { } while (0)
-#define LIMIT_NETDEBUG(fmt, args...) do { } while(0)
-#endif
+#define LIMIT_NETDEBUG(fmt, args...) \
+ do { if (net_msg_warn && net_ratelimit()) printk(fmt,##args); } while(0)
/*
* Macros for sleeping on a socket. Use them like this:
--- net-2.6.22.orig/net/Kconfig 2007-03-08 11:21:05.0 -0800
+++ net-2.6.22/net/Kconfig 2007-03-08 11:21:16.0 -0800
@@ -27,13 +27,6 @@
menu "Networking options"
-config NETDEBUG
- bool "Network packet debugging"
- help
- You can say Y here if you want to get additional messages useful in
- debugging bad packets, but can overwhelm logs under denial of service
- attacks.
-
source "net/packet/Kconfig"
source "net/unix/Kconfig"
source "net/xfrm/Kconfig"
--- net-2.6.22.orig/net/core/sysctl_net_core.c 2007-03-08 11:10:40.0
-0800
+++ net-2.6.22/net/core/sysctl_net_core.c 2007-03-08 11:37:18.0
-0800
@@ -136,6 +136,14 @@
.mode = 0644,
.proc_handler = &proc_dointvec
},
+ {
+ .ctl_name = NET_CORE_WARNINGS,
+ .procname = "warnings",
+ .data = &net_msg_warn,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec
+ },
{ .ctl_name = 0 }
};
--- net-2.6.22.orig/net/core/utils.c2007-03-08 11:18:09.0 -0800
+++ net-2.6.22/net/core/utils.c 2007-03-08 11:39:08.0 -0800
@@ -32,6 +32,8 @@
int net_msg_cost = 5*HZ;
int net_msg_burst = 10;
+int net_msg_warn = 1;
+EXPORT_SYMBOL(net_msg_warn);
/*
* All net warning printk()s should be guarded by this function.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19/2.6.20 BUG in inet_rtm_newaddr()/__inet_insert_ifa()
On Fri, Mar 09, 2007 at 03:30:17PM +0300, Evgeniy Polyakov wrote:
> On Fri, Mar 09, 2007 at 11:33:33AM +0100, Frank van Maarseveen ([EMAIL
> PROTECTED]) wrote:
> > Try this:
> >
> > ip addr add 172.18.12.99/21 dev dummy0
> > ip addr add broadcast 172.18.15.255 dev dummy0
>
> Attached patch fixes the problem.
>
> nlmsg_parse() in rtm_to_ifaddr() sucessfully returns zero, but
> subsequent check for prefix len and LOCAL ifa fails, so NULL is returned
> instead of negative error value embedded in the pointer which is
> expected by error logic in inet_rtm_newaddr().
>
> ---
>
> Return negative error value (embedded in the pointer) instead of returning
> NULL.
>
> Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index e10794d..98a00d0 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -502,8 +502,10 @@ static struct in_ifaddr *rtm_to_ifaddr(struct nlmsghdr
> *nlh)
> goto errout;
>
> ifm = nlmsg_data(nlh);
> - if (ifm->ifa_prefixlen > 32 || tb[IFA_LOCAL] == NULL)
> + if (ifm->ifa_prefixlen > 32 || tb[IFA_LOCAL] == NULL) {
> + err = -EINVAL;
> goto errout;
> + }
>
> dev = __dev_get_by_index(ifm->ifa_index);
> if (dev == NULL) {
>
> --
> Evgeniy Polyakov
Ok that worked.. not as I expected. I don't understand the EINVAL and
"ip addr" shows no broadcast address for eth0 when a classless address is
added as the primary (and only) address like in the above example. That's
why I tried to set it manually in the second "ip" command.
--
Frank
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rstp for 2.4 kernel: port state keeps changing
On Fri, 9 Mar 2007 12:24:40 -0500 [EMAIL PROTECTED] wrote: > > Hi, > > I am using RSTP for 2.4 kernel. RSTP is not in the mainline kernel tree. Please post the patch or a where the source can be downloaded. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: Please revert disallowing zero listen queues
David Miller wrote: > From: Rick Jones <[EMAIL PROTECTED]> > Date: Tue, 06 Mar 2007 10:54:00 -0800 > >>> So we're not "disallowing" a backlog argument of zero to >>> listen(). We'll accept that just fine, the only thing that >>> happens is that you'll get what you ask for, that being >>> no connections :-) >> I'm not sure where HP-UX inherited the 0 = 1 bit - perhaps from BSD, nor >> am I sure there is official chapter and verse, but: >> >> >> backlog is limited to the range of 0 to SOMAXCONN, which is defined in >> . SOMAXCONN is currently set to 4096. If any other >> value is specified, the system automatically assigns the closest value >> within the range. A backlog of 0 specifies only 1 pending >> connection is allowed at any given time. >> >> >> I don't have a Solaris, BSD or AIX manpage for listen handy to check >> them but would not be surprised to see they are similar. > > Ok, that seals the deal for me, I'll revert the change :) Ahh, crap. Even Posix wiesel-words around this issue: > A backlog argument of 0 may allow the socket to accept connections, in which > case > the length of the listen queue may be set to an implementation-defined > minimum value. (from http://www.opengroup.org/onlinepubs/009695399/functions/listen.html) No, to go and fix the SCTP spec -vlad - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NET : Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support
Hi David
This patch is against net-2.6.22 git tree.
Thank you
[PATCH] NET : Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support
Now that network timestamps use ktime_t infrastructure, we can add a new
SOL_SOCKET sockopt SO_TIMESTAMPNS.
This command is similar to SO_TIMESTAMP, but permits transmission of
a 'timespec struct' instead of a 'timeval struct' control message.
(nanosecond resolution instead of microsecond)
Control message is labelled SCM_TIMESTAMPNS instead of SCM_TIMESTAMP
A socket cannot mix SO_TIMESTAMP and SO_TIMESTAMPNS : the two modes are
mutually exclusive.
sock_recv_timestamp() became too big to be fully inlined so I added a
__sock_recv_timestamp() helper function.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
CC: linux-arch@vger.kernel.org
diff --git a/include/net/sock.h b/include/net/sock.h
index 5124657..390c047 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -390,6 +390,7 @@ enum sock_flags {
SOCK_USE_WRITE_QUEUE, /* whether to call sk->sk_write_space in
sock_wfree */
SOCK_DBG, /* %SO_DEBUG setting */
SOCK_RCVTSTAMP, /* %SO_TIMESTAMP setting */
+ SOCK_RCVTSTAMPNS, /* %SO_TIMESTAMPNS setting */
SOCK_LOCALROUTE, /* route locally only, %SO_DONTROUTE setting */
SOCK_QUEUE_SHRUNK, /* write queue has been shrunk recently */
};
@@ -1283,21 +1284,17 @@ static inline int sock_intr_errno(long t
return timeo == MAX_SCHEDULE_TIMEOUT ? -ERESTARTSYS : -EINTR;
}
+extern void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
+ struct sk_buff *skb);
+
static __inline__ void
sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
{
ktime_t kt = skb->tstamp;
- if (sock_flag(sk, SOCK_RCVTSTAMP)) {
- struct timeval tv;
- /* Race occurred between timestamp enabling and packet
- receiving. Fill in the current time for now. */
- if (kt.tv64 == 0)
- kt = ktime_get_real();
- skb->tstamp = kt;
- tv = ktime_to_timeval(kt);
- put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP, sizeof(tv), &tv);
- } else
+ if (sock_flag(sk, SOCK_RCVTSTAMP))
+ __sock_recv_timestamp(msg, sk, skb);
+ else
sk->sk_stamp = kt;
}
diff --git a/net/compat.c b/net/compat.c
index 0e40756..9a0f5f2 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -215,6 +215,7 @@ Efault:
int put_cmsg_compat(struct msghdr *kmsg, int level, int type, int len, void
*data)
{
struct compat_timeval ctv;
+ struct compat_timespec cts;
struct compat_cmsghdr __user *cm = (struct compat_cmsghdr __user *)
kmsg->msg_control;
struct compat_cmsghdr cmhdr;
int cmlen;
@@ -229,7 +230,14 @@ int put_cmsg_compat(struct msghdr *kmsg,
ctv.tv_sec = tv->tv_sec;
ctv.tv_usec = tv->tv_usec;
data = &ctv;
- len = sizeof(struct compat_timeval);
+ len = sizeof(ctv);
+ }
+ if (level == SOL_SOCKET && type == SO_TIMESTAMPNS) {
+ struct timespec *ts = (struct timespec *)data;
+ cts.tv_sec = ts->tv_sec;
+ cts.tv_nsec = ts->tv_nsec;
+ data = &cts;
+ len = sizeof(cts);
}
cmlen = CMSG_COMPAT_LEN(len);
diff --git a/net/core/sock.c b/net/core/sock.c
index a016661..d4c89f8 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -521,11 +521,18 @@ #endif
break;
case SO_TIMESTAMP:
+ case SO_TIMESTAMPNS:
if (valbool) {
+ if (optname == SO_TIMESTAMP)
+ sock_reset_flag(sk, SOCK_RCVTSTAMPNS);
+ else
+ sock_set_flag(sk, SOCK_RCVTSTAMPNS);
sock_set_flag(sk, SOCK_RCVTSTAMP);
sock_enable_timestamp(sk);
- } else
+ } else {
sock_reset_flag(sk, SOCK_RCVTSTAMP);
+ sock_reset_flag(sk, SOCK_RCVTSTAMPNS);
+ }
break;
case SO_RCVLOWAT:
@@ -715,7 +722,12 @@ int sock_getsockopt(struct socket *sock,
break;
case SO_TIMESTAMP:
- v.val = sock_flag(sk, SOCK_RCVTSTAMP);
+ v.val = sock_flag(sk, SOCK_RCVTSTAMP) &&
+ !sock_flag(sk, SOCK_RCVTSTAMPNS);
+ break;
+
+ case SO_TIMESTAMPNS:
+ v.val = sock_flag(sk, SOCK_RCVTSTAMPNS);
break;
case SO_RCVTIMEO:
diff --git a/net/socket.c b/net/socket.c
index 724b9cd..15e4327 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -585,6 +585,35 @@ int kernel_sendmsg(struct socket *sock,
return result;
}
+/*
+ * called from sock_recv_timestamp() if sock_flag(sk, SOCK_RCVTSTAMP)
+ */
+void __sock_recv_timestamp(struct msghdr *msg, st
Re: [Bridge] rstp for 2.4 kernel: port state keeps changing
I have downloaded RSTP from this site: http://developer.osdl.org/shemminger/prototypes/rstp-2.4.zip -Marc Stephen Hemminger <[EMAIL PROTECTED]> Sent by: To [EMAIL PROTECTED] Marc Obbad/[EMAIL PROTECTED] cc netdev@vger.kernel.org, [EMAIL PROTECTED] 03/09/2007 01:55 PM Subject Re: [Bridge] rstp for 2.4 kernel: port state keeps changing On Fri, 9 Mar 2007 12:24:40 -0500 [EMAIL PROTECTED] wrote: > > Hi, > > I am using RSTP for 2.4 kernel. RSTP is not in the mainline kernel tree. Please post the patch or a where the source can be downloaded. -- Stephen Hemminger <[EMAIL PROTECTED]> ___ Bridge mailing list Bridge@lists.osdl.org https://lists.osdl.org/mailman/listinfo/bridge - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bridge] rstp for 2.4 kernel: port state keeps changing
On Fri, 9 Mar 2007 15:20:02 -0500 [EMAIL PROTECTED] wrote: > I have downloaded RSTP from this site: > > > http://developer.osdl.org/shemminger/prototypes/rstp-2.4.zip > > That's cool, I didn't know anyone got the old code to work! -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless extensions vs. 64-bit architectures
On Thu, Mar 08, 2007 at 11:35:26PM +0100, Johannes Berg wrote: > On Thu, 2007-03-08 at 14:11 -0800, Jean Tourrilhes wrote: > > > First possiblity, we could stick with this band-aid > > permanently. > > It sucks for various reasons, one for example being that I don't even > understand your recognition code but all userspace programs that use > wext will have to include such code! It's not as bad as it look like. All userspace programs nowadays use either the iwlib or wpa_supplicant. For example, NetworkManager gets its stuff through wpa_supplicant, and kdenetwork uses iwlib. So, in essence, there is only two places to fix. Which is why I would like to hear from Jouni. By the way, I've just released version 29.pre16 which has a better band aid. It fixes bugs of the previous version and is more forward compatible (i.e. it's compatible with option 2). Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.19/2.6.20 BUG in inet_rtm_newaddr()/__inet_insert_ifa()
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Fri, 9 Mar 2007 15:30:17 +0300 > On Fri, Mar 09, 2007 at 11:33:33AM +0100, Frank van Maarseveen ([EMAIL > PROTECTED]) wrote: > > Try this: > > > > ip addr add 172.18.12.99/21 dev dummy0 > > ip addr add broadcast 172.18.15.255 dev dummy0 > > Attached patch fixes the problem. > > nlmsg_parse() in rtm_to_ifaddr() sucessfully returns zero, but > subsequent check for prefix len and LOCAL ifa fails, so NULL is returned > instead of negative error value embedded in the pointer which is > expected by error logic in inet_rtm_newaddr(). Patch applied, thanks Evgeniy. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1][UDP]: Use __skb_pull since we have checked it won't fail with pskb_may_pull
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]> Date: Fri, 9 Mar 2007 11:07:50 -0300 > Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> Applied to net-2.6.22, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for ipv6_setsockopt NULL dereference
From: Olaf Kirch <[EMAIL PROTECTED]> Date: Fri, 9 Mar 2007 15:15:54 +0100 > I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155 > > Here's a potential fix. > > Olaf > -- > Olaf Kirch | --- o --- Nous sommes du soleil we love when we play > [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax > -- > Fix NULL pointer derefence in ipv6_setsockopt, as described in bug #8155. > > Signed-off-by: [EMAIL PROTECTED] Applied, thanks a lot Olaf. I'll push this to -stable too. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix for ipv6_setsockopt NULL dereference
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> Date: Fri, 09 Mar 2007 23:40:25 +0900 (JST) > In article <[EMAIL PROTECTED]> (at Fri, 9 Mar 2007 15:15:54 +0100), Olaf > Kirch <[EMAIL PROTECTED]> says: > > > I came across this bug in http://bugzilla.kernel.org/show_bug.cgi?id=8155 > : > > Fix NULL pointer derefence in ipv6_setsockopt, as described in bug #8155. > > > > Signed-off-by: [EMAIL PROTECTED] > > Acked-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> > > I also ack to push this to -stable. Thank you for reviewing. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] spidernet: Fix problem sending IP fragments
On Friday, 9. March 2007 17:53, Jeff Garzik wrote:
> Linas Vepstas wrote:
> > Jeff,
> >
> > Please apply. The rather long patch description is from the submitter,
> > Norbert Eicker, I don't know if that's alright, or if I should ask to
> > have it trimmed.
> >
> > Thanks,
> > --linas
> >
> > From: Norbert Eicker <[EMAIL PROTECTED]>
> >
> >
> > Signed-off-by: Norbert Eicker <[EMAIL PROTECTED]>
> > Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
>
> are you sure it can't send out fragmented IP frames? what's really
> going on here?
Pretty sure that fragmented IP frames are not send out. Here's a small test
using ttcp and tcpdump reproducing the problem (I assume a MTU of 1500):
You need two node, lets call them src and dest.
On dest run 'tcpdump -nvvv host src'.
Furthermore start on dest: 'ttcp -u -r -s'
and on src: 'ttcp -u -t -s -l 1472 -n 4 dest
tcpdump will show 10 frames received from src, one of size 32 (UDP length 4),
four of size 1500 (UDP length 1472) (the payload), five more of size 32 (UDP
length 4). The size 32 frames are some startup/closing frames of ttcp.
Start on dest again: 'ttcp -u -r -s'
and on src: 'ttcp -u -t -s -l 1473 -n 4 dest
Now tcpdump only sees the six startup/closing frames. The payload frames
(which are fragmented by the IP-stack) disappear somehow.
With the patch applied you see in the second case the startup/closing frames
plus 4 pairs of frames in between. Each pair consists of one frame of size
1500 followed by one of size 21 (with an offset of 1480), i.e. the two
fragments of the too large UDP-datagram.
On src tcpdump will show the fragmented IP-frames in both cases (with and
without patch applied).
> patch was corrupted anyway, and could not be applied...
Whitespace problem? Let's try again...
Signed-off-by: Norbert Eicker <[EMAIL PROTECTED]>
diff --git a/drivers/net/spider_net.c b/drivers/net/spider_net.c
index 3b91af8..e3019d5 100644
--- a/drivers/net/spider_net.c
+++ b/drivers/net/spider_net.c
@@ -719,7 +719,7 @@ spider_net_prepare_tx_descr(struct spide
SPIDER_NET_DESCR_CARDOWNED | SPIDER_NET_DMAC_NOCS;
spin_unlock_irqrestore(&chain->lock, flags);
- if (skb->protocol == htons(ETH_P_IP))
+ if (skb->protocol == htons(ETH_P_IP) && skb->ip_summed ==
CHECKSUM_PARTIAL)
switch (skb->nh.iph->protocol) {
case IPPROTO_TCP:
hwdescr->dmac_cmd_status |= SPIDER_NET_DMAC_TCP;
--
Fon ++49-(0)2461/61-1492
http://www.fz-juelich.de
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: double SAs are created when using AH and ESP together
On Tue, 2007-03-06 at 14:40 -0500, James Morris wrote:
On Tue, 6 Mar 2007, Joy Latten wrote:
>
> > > I saw something similar to this some time ago when testing various
> > > failure modes, and discused it with Herbert.
> > >
> > > IIRC, there's a larval SA which is not torn down properly by Racoon once
> > > the full SA is established, and the larval SA keeps resending until it
> > > times out.
> > >
> > Ok, good to know.
> > I thought a bit more about this last night but am not
> > sure best way to fix it. Perhaps a way to keep larval
> > SA around until all SAs resulting from xfrm_vec[xfrm_nr]
> > are established... oh well, just thinking out loud... :-)
>
> I think the solution, if this actually the problem, is for the userland
> code to maintain the SAs.
Gotta agree. :-)
I noticed that in xfrm_state_add we look for the larval SA in a few
places without checking for protocol match. So when using both
AH and ESP, whichever one gets added first, deletes the larval SA.
It seems AH always gets added first and ESP is always the larval
SA's protocol since the xfrm->tmpl has it first. Thus causing the
additional km_query()
Adding the check eliminates the double SA creation.
I know this may not seem like a complete solution and I will
continue to test and be on the lookout, but isn't having the
check a good thing? So far I have tested SAs with just ESP, just AH
and with both and all seems ok.
Please let me know if this patch is ok.
My kernel was 2.6.20-rc3-git3.
Joy
Signed-off-by: Joy Latten <[EMAIL PROTECTED]>
diff -urpN linux-2.6.20.orig/net/xfrm/xfrm_state.c
linux-2.6.20.patch/net/xfrm/xfrm_state.c
--- linux-2.6.20.orig/net/xfrm/xfrm_state.c 2007-03-08 17:39:14.0
-0600
+++ linux-2.6.20.patch/net/xfrm/xfrm_state.c2007-03-09 11:03:25.0
-0600
@@ -704,7 +704,8 @@ static struct xfrm_state *__find_acq_cor
x->props.mode != mode ||
x->props.family != family ||
x->km.state != XFRM_STATE_ACQ ||
- x->id.spi != 0)
+ x->id.spi != 0 ||
+ x->id.proto != proto)
continue;
switch (family) {
@@ -801,7 +802,8 @@ int xfrm_state_add(struct xfrm_state *x)
if (use_spi && x->km.seq) {
x1 = __xfrm_find_acq_byseq(x->km.seq);
- if (x1 && xfrm_addr_cmp(&x1->id.daddr, &x->id.daddr, family)) {
+ if (x1 && ((x1->id.proto != x->id.proto) ||
+ xfrm_addr_cmp(&x1->id.daddr, &x->id.daddr, family))) {
xfrm_state_put(x1);
x1 = NULL;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless extensions vs. 64-bit architectures
On Fri, Mar 09, 2007 at 01:35:31PM -0800, Jean Tourrilhes wrote: > It's not as bad as it look like. All userspace programs > nowadays use either the iwlib or wpa_supplicant. For example, > NetworkManager gets its stuff through wpa_supplicant, and kdenetwork > uses iwlib. So, in essence, there is only two places to fix. > Which is why I would like to hear from Jouni. How confident are you of this being the full set? I did not use iwlib for two reasons: its license and it not being available (at least at that point in time) by default in many Linux distros. I would expect someone else having the same reasons, but I have to admit that I have not looked into this at all, so this is only a guess. > By the way, I've just released version 29.pre16 which has a > better band aid. It fixes bugs of the previous version and is more > forward compatible (i.e. it's compatible with option 2). Hmm.. What should I look as the description of the latest proposed workaround? I was kind of hoping to see a nice description of the problem and proposed change in couple of paragraphs of text.. ;-) Anyway, I can see two changes when I diff wireless tools 29.pre14 and pre15 that are clearly related to this. Diff of pre14 vs. pre16 or pre15 vs. pre16 includes more changes and some of them do not seem to be related to issue. Unfortunately I do not have access to any system to test this workaround, so I cannot easily test this myself. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6]: Ensure to truncate result and return full length for sticky options.
* David Miller ([EMAIL PROTECTED]) wrote: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 09 Mar 2007 10:13:28 +0900 (JST) > > > Bug noticed by Chris Wright <[EMAIL PROTECTED]>. > > > > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> > > Applied, thanks a lot. Crud, I should have noticed this earlier. This has a problem, min_t(int) means user supplied < 0 is a large copy_to_user (back to leaking memory on arch's that don't protect < 0 copy_to_user like i386 does). Here's a simple fix ontop of yoshifuji's two changes. Hope that's it ;-) thanks, -chris -- From: Chris Wright <[EMAIL PROTECTED]> Subject: [IPV6] fix ipv6_getsockopt_sticky copy_to_user leak User supplied len < 0 can cause leak of kernel memory. Use unsigned compare instead. Signed-off-by: Chris Wright <[EMAIL PROTECTED]> --- net/ipv6/ipv6_sockglue.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c index a4f06ce..321287b 100644 --- a/net/ipv6/ipv6_sockglue.c +++ b/net/ipv6/ipv6_sockglue.c @@ -824,7 +824,7 @@ static int ipv6_getsockopt_sticky(struct sock *sk, struct ipv6_txoptions *opt, if (!hdr) return 0; - len = min_t(int, len, ipv6_optlen(hdr)); + len = min_t(unsigned, len, ipv6_optlen(hdr)); if (copy_to_user(optval, hdr, len)); return -EFAULT; return ipv6_optlen(hdr); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6]: Ensure to truncate result and return full length for sticky options.
Ugh, Chris, why is this patch against a copy of ipv6_sockglue.c that doesn't have the NULL pointer fix applied? Nevermind, it's obvious, so I fixed it up by hand, but please patch against current sources expecially when we're all aware of other fixes that have been made to this exact function over the past few days. Otherwise it makes a lot more work for me. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: double SAs are created when using AH and ESP together
From: Joy Latten <[EMAIL PROTECTED]> Date: Fri, 9 Mar 2007 17:14:54 -0600 > I noticed that in xfrm_state_add we look for the larval SA in a few > places without checking for protocol match. So when using both > AH and ESP, whichever one gets added first, deletes the larval SA. > It seems AH always gets added first and ESP is always the larval > SA's protocol since the xfrm->tmpl has it first. Thus causing the > additional km_query() > > Adding the check eliminates the double SA creation. > I know this may not seem like a complete solution and I will > continue to test and be on the lookout, but isn't having the > check a good thing? So far I have tested SAs with just ESP, just AH > and with both and all seems ok. > > Please let me know if this patch is ok. > My kernel was 2.6.20-rc3-git3. > > Signed-off-by: Joy Latten <[EMAIL PROTECTED]> Generally it looks OK, but I'm going to let this one sit for a while before I apply it so that other folks can review it too and spot any unintended consequences. In particular, I find it strance that we didn't check the protocol field all this time and I wonder whether that might be on purpose for some reason. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6]: Ensure to truncate result and return full length for sticky options.
* David Miller ([EMAIL PROTECTED]) wrote: > copy_to_user() will check it, actually, it will make sure that > optval + len doesn't wrap or overlap into kernel space. > > Actually, like sparc64 it BUG's on negative length so we have > to fix this :-) Yeah, I think it's arch dependent (x86_64 for example will give me 2GB back happily, useful if I forgot my password ;-) thanks, -chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix net-2.6.22 on sparc
Eric, please look at whole files you are editing :) I'm sure there is probably another case like this or two in the other platform socket ioctl allocations you made. Thanks. commit 9415518744729743b017da2e08a71c5bb0d94108 Author: David S. Miller <[EMAIL PROTECTED]> Date: Fri Mar 9 16:22:52 2007 -0800 [NET]: Fix SO_TIMESTAMPNS values allocated to sparc. They confliced with SO_BROADCAST which already uses the value 0x0020. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> diff --git a/include/asm-sparc/socket.h b/include/asm-sparc/socket.h index d77768e..7c14239 100644 --- a/include/asm-sparc/socket.h +++ b/include/asm-sparc/socket.h @@ -49,7 +49,7 @@ #define SO_PEERSEC 0x001e #define SO_PASSSEC 0x001f -#define SO_TIMESTAMPNS 0x0020 +#define SO_TIMESTAMPNS 0x0021 #define SCM_TIMESTAMPNSSO_TIMESTAMPNS /* Security levels - as per NRL IPv6 - don't actually do anything */ diff --git a/include/asm-sparc64/socket.h b/include/asm-sparc64/socket.h index 1bd9f52..986441d 100644 --- a/include/asm-sparc64/socket.h +++ b/include/asm-sparc64/socket.h @@ -49,7 +49,7 @@ #define SO_PEERSEC 0x001e #define SO_PASSSEC 0x001f -#define SO_TIMESTAMPNS 0x0020 +#define SO_TIMESTAMPNS 0x0021 #define SCM_TIMESTAMPNSSO_TIMESTAMPNS /* Security levels - as per NRL IPv6 - don't actually do anything */ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6]: Ensure to truncate result and return full length for sticky options.
* David Miller ([EMAIL PROTECTED]) wrote: > > Ugh, Chris, why is this patch against a copy of ipv6_sockglue.c > that doesn't have the NULL pointer fix applied? > > Nevermind, it's obvious, so I fixed it up by hand, but please > patch against current sources expecially when we're all aware > of other fixes that have been made to this exact function over > the past few days. Otherwise it makes a lot more work for me. Shoot, I'm sorry. I pulled from Linus' tree, then your tree to have most uptodate specifically to make sure I had the lastest changes. Not sure how that went wrong. thanks, -chris - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: double SAs are created when using AH and ESP together
On Fri, 2007-03-09 at 16:20 -0800, David Miller wrote: > From: Joy Latten <[EMAIL PROTECTED]> > Date: Fri, 9 Mar 2007 17:14:54 -0600 > > > I noticed that in xfrm_state_add we look for the larval SA in a few > > places without checking for protocol match. So when using both > > AH and ESP, whichever one gets added first, deletes the larval SA. > > It seems AH always gets added first and ESP is always the larval > > SA's protocol since the xfrm->tmpl has it first. Thus causing the > > additional km_query() > > > > Adding the check eliminates the double SA creation. > > I know this may not seem like a complete solution and I will > > continue to test and be on the lookout, but isn't having the > > check a good thing? So far I have tested SAs with just ESP, just AH > > and with both and all seems ok. > > > > Please let me know if this patch is ok. > > My kernel was 2.6.20-rc3-git3. > > > > Signed-off-by: Joy Latten <[EMAIL PROTECTED]> > > Generally it looks OK, but I'm going to let this one sit for > a while before I apply it so that other folks can review it > too and spot any unintended consequences. > > In particular, I find it strance that we didn't check the > protocol field all this time and I wonder whether that might > be on purpose for some reason. At least the first hunk of this patch used to be checked back in net/ipv4/xfrm4_state.c in __xfrm4_find_acq and looks like it just was accidentally forgotten when there was a transition to using __find_acq_core http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2770834c9f44afd1bfa13914c7285470775af657 Since Joy found this problem on a 2.6.18 kernel originally which was before this diff and had the proto check I'm guessing it is actually the second hunk which is more relevant to the problem. -Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix net-2.6.22 on sparc
David Miller a écrit :
Eric, please look at whole files you are editing :) I'm sure
there is probably another case like this or two in the
other platform socket ioctl allocations you made.
Thanks.
commit 9415518744729743b017da2e08a71c5bb0d94108
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Fri Mar 9 16:22:52 2007 -0800
[NET]: Fix SO_TIMESTAMPNS values allocated to sparc.
They confliced with SO_BROADCAST which already uses the
value 0x0020.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Oh I see :( this one was really not easy to spot without close inspection :)
I just checked all arches and only sparc{64} have this strange SO_ values
not linear. I wonder why this layout was chosen ?
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix net-2.6.22 on sparc
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 01:56:16 +0100
> I just checked all arches and only sparc{64} have this strange
> SO_ values not linear. I wonder why this layout was chosen ?
A lot of the API bogosity in the sparc userspace APIs comes from the
fact that we mirrored the SunOS values at the beginning of the port
and we're kind of stuck with that bad decision. :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless extensions vs. 64-bit architectures
On Fri, Mar 09, 2007 at 03:19:22PM -0800, Jouni Malinen wrote: > On Fri, Mar 09, 2007 at 01:35:31PM -0800, Jean Tourrilhes wrote: > > > It's not as bad as it look like. All userspace programs > > nowadays use either the iwlib or wpa_supplicant. For example, > > NetworkManager gets its stuff through wpa_supplicant, and kdenetwork > > uses iwlib. So, in essence, there is only two places to fix. > > Which is why I would like to hear from Jouni. > > How confident are you of this being the full set? I spent some time tracking that when we did the ESSID change. I also try to keep the list on my web site up to date. The reason the set is small is that most programs are simplistic, only reporting signal strength, and only a few go beyond that. > > By the way, I've just released version 29.pre16 which has a > > better band aid. It fixes bugs of the previous version and is more > > forward compatible (i.e. it's compatible with option 2). > > Hmm.. What should I look as the description of the latest proposed > workaround? I was kind of hoping to see a nice description of the > problem and proposed change in couple of paragraphs of text.. ;-) Alignement issue in structures. On 64 bit, you get an extra 4 bytes of stuff between the header and the payload. So, you need to detect this condition and remove the extra 4 bytes. > Anyway, I can see two changes when I diff wireless tools 29.pre14 and > pre15 that are clearly related to this. Diff of pre14 vs. pre16 or pre15 > vs. pre16 includes more changes and some of them do not seem to be > related to issue. Actually, apart from ifrename, all the pre15 to pre16 changes are related to this. > Unfortunately I do not have access to any system to test this > workaround, so I cannot easily test this myself. Same here. > Jouni Malinen Jean - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: double SAs are created when using AH and ESP together
On Fri, 2007-03-09 at 16:20 -0800, David Miller wrote: > From: Joy Latten <[EMAIL PROTECTED]> > Date: Fri, 9 Mar 2007 17:14:54 -0600 > > > I noticed that in xfrm_state_add we look for the larval SA in a few > > places without checking for protocol match. So when using both > > AH and ESP, whichever one gets added first, deletes the larval SA. > > It seems AH always gets added first and ESP is always the larval > > SA's protocol since the xfrm->tmpl has it first. Thus causing the > > additional km_query() > > > > Adding the check eliminates the double SA creation. > > I know this may not seem like a complete solution and I will > > continue to test and be on the lookout, but isn't having the > > check a good thing? So far I have tested SAs with just ESP, just AH > > and with both and all seems ok. > > > > Please let me know if this patch is ok. > > My kernel was 2.6.20-rc3-git3. > > > > Signed-off-by: Joy Latten <[EMAIL PROTECTED]> > > Generally it looks OK, but I'm going to let this one sit for > a while before I apply it so that other folks can review it > too and spot any unintended consequences. > > In particular, I find it strance that we didn't check the > protocol field all this time and I wonder whether that might > be on purpose for some reason. Ok. And I'll continue to test, though most of my testing is done on lspp kernel. lspp kernel is an earlier version of upstream kernel and I noticed the old __xfrm4_find_acq() did include a check for the protocol, new __find_acq_core() doesn't. But neither checked for protocol after call to __xfrm_find_acq_byseq(). Joy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6]: Ensure to truncate result and return full length for sticky options.
In article <[EMAIL PROTECTED]> (at Fri, 09 Mar 2007 16:15:06 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > > on arch's that don't protect < 0 copy_to_user like i386 does). Here's > > a simple fix ontop of yoshifuji's two changes. Hope that's it ;-) > > copy_to_user() will check it, actually, it will make sure that > optval + len doesn't wrap or overlap into kernel space. > > Actually, like sparc64 it BUG's on negative length so we have > to fix this :-) Oh I did not know this BUG. Anyway, thanks for taking care of this. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET : Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Fri, 9 Mar 2007 19:39:42 +0100 > [PATCH] NET : Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support > > Now that network timestamps use ktime_t infrastructure, we can add a new > SOL_SOCKET sockopt SO_TIMESTAMPNS. > > This command is similar to SO_TIMESTAMP, but permits transmission of > a 'timespec struct' instead of a 'timeval struct' control message. > (nanosecond resolution instead of microsecond) > > Control message is labelled SCM_TIMESTAMPNS instead of SCM_TIMESTAMP > > A socket cannot mix SO_TIMESTAMP and SO_TIMESTAMPNS : the two modes are > mutually exclusive. > > sock_recv_timestamp() became too big to be fully inlined so I added a > __sock_recv_timestamp() helper function. > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> > CC: linux-arch@vger.kernel.org > Applied, thanks for following up on all of this nanosecond timestamp work. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: double SAs are created when using AH and ESP together
On Fri, 2007-03-09 at 19:54 -0500, Eric Paris wrote: > On Fri, 2007-03-09 at 16:20 -0800, David Miller wrote: > > From: Joy Latten <[EMAIL PROTECTED]> > > Date: Fri, 9 Mar 2007 17:14:54 -0600 > > > > > I noticed that in xfrm_state_add we look for the larval SA in a few > > > places without checking for protocol match. So when using both > > > AH and ESP, whichever one gets added first, deletes the larval SA. > > > It seems AH always gets added first and ESP is always the larval > > > SA's protocol since the xfrm->tmpl has it first. Thus causing the > > > additional km_query() > > > > > > Adding the check eliminates the double SA creation. > > > I know this may not seem like a complete solution and I will > > > continue to test and be on the lookout, but isn't having the > > > check a good thing? So far I have tested SAs with just ESP, just AH > > > and with both and all seems ok. > > > > > > Please let me know if this patch is ok. > > > My kernel was 2.6.20-rc3-git3. > > > > > > Signed-off-by: Joy Latten <[EMAIL PROTECTED]> > > > > Generally it looks OK, but I'm going to let this one sit for > > a while before I apply it so that other folks can review it > > too and spot any unintended consequences. > > > > In particular, I find it strance that we didn't check the > > protocol field all this time and I wonder whether that might > > be on purpose for some reason. > > At least the first hunk of this patch used to be checked back in > net/ipv4/xfrm4_state.c in __xfrm4_find_acq and looks like it just was > accidentally forgotten when there was a transition to using > __find_acq_core > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2770834c9f44afd1bfa13914c7285470775af657 > > Since Joy found this problem on a 2.6.18 kernel originally which was > before this diff and had the proto check I'm guessing it is actually the > second hunk which is more relevant to the problem. > > -Eric Don't mean to be a killjoy on a friday evening, but I just saw something else that I recall seeing a while back but forgot and so want to report now. While initiator is establishing SAs, the responder sends an ACQUIRE. I once got 3 sets of SAs. Now I only got 2 this time with above patch. This occurs when I start netperf to send streams of tcp and udp packets to test. This doesn't always happen. Just once in a while it seems... like a packet escaped and reached remote... (this is from lspp kernel) Initiator's log file: Mar 9 19:43:51 racoon: INFO: ISAKMP-SA established 9.3.192.210[500]-9.3.189.55[500] spi:dcdf529f9e7e1c7b:87400b8505e2f2aa Mar 9 19:43:52 racoon: INFO: initiate new phase 2 negotiation: 9.3.192.210[500]<=>9.3.189.55[500] Mar 9 19:43:53 racoon: INFO: IPsec-SA established: AH/Transport 9.3.189.55[0]->9.3.192.210[0] spi=193987518(0xb9003be) Mar 9 19:43:53 racoon: INFO: IPsec-SA established: ESP/Transport 9.3.189.55[0]->9.3.192.210[0] spi=137973961(0x83950c9) Mar 9 19:43:53 racoon: INFO: IPsec-SA established: AH/Transport 9.3.192.210[0]->9.3.189.55[0] spi=248476422(0xecf7306) Mar 9 19:43:53 racoon: INFO: IPsec-SA established: ESP/Transport 9.3.192.210[0]->9.3.189.55[0] spi=263395735(0xfb31997) Mar 9 19:43:53 racoon: INFO: respond new phase 2 negotiation: 9.3.192.210[500]<=>9.3.189.55[500] Mar 9 19:43:55 racoon: INFO: IPsec-SA established: AH/Transport 9.3.189.55[0]->9.3.192.210[0] spi=37664464(0x23eb6d0) Mar 9 19:43:55 racoon: INFO: IPsec-SA established: ESP/Transport 9.3.189.55[0]->9.3.192.210[0] spi=246992333(0xeb8cdcd) Mar 9 19:43:55 racoon: INFO: IPsec-SA established: AH/Transport 9.3.192.210[0]->9.3.189.55[0] spi=203651374(0xc23792e) Mar 9 19:43:55 racoon: INFO: IPsec-SA established: ESP/Transport 9.3.192.210[0]->9.3.189.55[0] spi=48093292(0x2ddd86c) -- Responder's log file: Mar 9 19:43:10 racoon: INFO: respond new phase 2 negotiation: 9.3.189.55[500]<=>9.3.192.210[500] Mar 9 19:43:11 racoon: INFO: IPsec-SA established: AH/Transport 9.3.192.210[0]->9.3.189.55[0] spi=248476422(0xecf7306) Mar 9 19:43:11 racoon: INFO: IPsec-SA established: ESP/Transport 9.3.192.210[0]->9.3.189.55[0] spi=263395735(0xfb31997) Mar 9 19:43:11 racoon: INFO: IPsec-SA established: AH/Transport 9.3.189.55[0]->9.3.192.210[0] spi=193987518(0xb9003be) Mar 9 19:43:11 racoon: INFO: security context doi: 1 Mar 9 19:43:11 racoon: INFO: security context algorithm: 1 Mar 9 19:43:11 racoon: INFO: security context length: 39 Mar 9 19:43:11 racoon: INFO: security context: root:sysadm_r:sysadm_t:s0-s15:c0.c1023 Mar 9 19:43:11 racoon: INFO: initiate new phase 2 negotiation: 9.3.189.55[500]<=>9.3.192.210[500] Mar 9 19:43:11 racoon: INFO: IPsec-SA established: ESP/Transport 9.3.189.55[0]->9.3.192.210[0] spi=137973961(0x83950c9) Mar 9 19:43:12 racoon: INFO: IPsec-SA established: AH/Transport 9.3.192.210[0]->9.3.189.55[0] spi=203651374(0xc23792e) Mar 9 19:43:12 racoon: INFO: IPsec-SA established: ESP/Trans
[PATCH 1/2] S2io: Remove unused variables
- Remove unused variables from s2io_nic structure
- Changed the memory failure printk messages to print only in debug mode
- Updated the copyright messages
(Resending; due to patch being corrupted)
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
---
diff -Nurp patch/drivers/net/s2io.c patch1/drivers/net/s2io.c
--- patch/drivers/net/s2io.c2007-03-06 03:28:39.0 -0800
+++ patch1/drivers/net/s2io.c 2007-03-06 03:29:18.0 -0800
@@ -1,6 +1,6 @@
/
* s2io.c: A Linux PCI-X Ethernet driver for Neterion 10GbE Server NIC
- * Copyright(c) 2002-2005 Neterion Inc.
+ * Copyright(c) 2002-2007 Neterion Inc.
* This software may be used and distributed according to the terms of
* the GNU General Public License (GPL), incorporated herein by reference.
@@ -516,7 +516,7 @@ static int init_shared_mem(struct s2io_n
mac_control->fifos[i].list_info = kmalloc(list_holder_size,
GFP_KERNEL);
if (!mac_control->fifos[i].list_info) {
- DBG_PRINT(ERR_DBG,
+ DBG_PRINT(INFO_DBG,
"Malloc failed for list_info\n");
return -ENOMEM;
}
@@ -542,9 +542,9 @@ static int init_shared_mem(struct s2io_n
tmp_v = pci_alloc_consistent(nic->pdev,
PAGE_SIZE, &tmp_p);
if (!tmp_v) {
- DBG_PRINT(ERR_DBG,
+ DBG_PRINT(INFO_DBG,
"pci_alloc_consistent ");
- DBG_PRINT(ERR_DBG, "failed for TxDL\n");
+ DBG_PRINT(INFO_DBG, "failed for TxDL\n");
return -ENOMEM;
}
/* If we got a zero DMA address(can happen on
@@ -561,9 +561,9 @@ static int init_shared_mem(struct s2io_n
tmp_v = pci_alloc_consistent(nic->pdev,
PAGE_SIZE, &tmp_p);
if (!tmp_v) {
- DBG_PRINT(ERR_DBG,
+ DBG_PRINT(INFO_DBG,
"pci_alloc_consistent ");
- DBG_PRINT(ERR_DBG, "failed for TxDL\n");
+ DBG_PRINT(INFO_DBG, "failed for
TxDL\n");
return -ENOMEM;
}
}
@@ -2187,7 +2187,7 @@ static int fill_rxd_3buf(struct s2io_nic
/* skb_shinfo(skb)->frag_list will have L4 data payload */
skb_shinfo(skb)->frag_list = dev_alloc_skb(dev->mtu + ALIGN_SIZE);
if (skb_shinfo(skb)->frag_list == NULL) {
- DBG_PRINT(ERR_DBG, "%s: dev_alloc_skb failed\n ", dev->name);
+ DBG_PRINT(INFO_DBG, "%s: dev_alloc_skb failed\n ", dev->name);
return -ENOMEM ;
}
frag_list = skb_shinfo(skb)->frag_list;
@@ -2313,8 +2313,8 @@ static int fill_rx_buffers(struct s2io_n
/* allocate skb */
skb = dev_alloc_skb(size);
if(!skb) {
- DBG_PRINT(ERR_DBG, "%s: Out of ", dev->name);
- DBG_PRINT(ERR_DBG, "memory to allocate SKBs\n");
+ DBG_PRINT(INFO_DBG, "%s: Out of ", dev->name);
+ DBG_PRINT(INFO_DBG, "memory to allocate SKBs\n");
if (first_rxdp) {
wmb();
first_rxdp->Control_1 |= RXD_OWN_XENA;
@@ -2573,8 +2573,8 @@ static int s2io_poll(struct net_device *
for (i = 0; i < config->rx_ring_num; i++) {
if (fill_rx_buffers(nic, i) == -ENOMEM) {
- DBG_PRINT(ERR_DBG, "%s:Out of memory", dev->name);
- DBG_PRINT(ERR_DBG, " in Rx Poll!!\n");
+ DBG_PRINT(INFO_DBG, "%s:Out of memory", dev->name);
+ DBG_PRINT(INFO_DBG, " in Rx Poll!!\n");
break;
}
}
@@ -2590,8 +2590,8 @@ no_rx:
for (i = 0; i < config->rx_ring_num; i++) {
if (fill_rx_buffers(nic, i) == -ENOMEM) {
- DBG_PRINT(ERR_DBG, "%s:Out of memory", dev->name);
- DBG_PRINT(ERR_DBG, " in Rx Poll!!\n");
+ DBG_PRINT(INFO_DBG, "%s:Out of memory", dev->name);
+ DBG_PRINT(INFO_DBG, " in Rx Poll!!\n");
break;
}
}
@@ -2640,8 +2640,8 @@ static void s2io_netpoll(struct net_devi
for (i = 0; i < config->rx_ring_num; i++) {
if (fill_rx_buffers
SSB/b44 build failure
Hi, In 2.6.21-rc3-mm2, with CONFIG_SSB=y but all other SSB kconfig symbols disabled, I get this (on x86_64): drivers/built-in.o: In function `b44_init': b44.c:(.init.text+0x6e04): undefined reference to `ssb_pcihost_register' b44.c:(.init.text+0x6e2c): undefined reference to `ssb_pcihost_unregister' drivers/built-in.o: In function `b44_cleanup': b44.c:(.exit.text+0x63b): undefined reference to `ssb_pcihost_unregister' make: *** [.tmp_vmlinux1] Error 1 --- ~Randy I don't have time to look into a fix for it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
PROBLEM: What happend when exceeding allocatable memory for TCP socket buffers?
Hi, I tried to find out how many TCP connections a server can establish with a simple test program. But when trying 120K connections for receiving 512 bytes message for each connection sequentially, of which sending rate was 15,000 requests/second, the system stops. I suspect the system was required more amount of memory than auto-tuned allocatable memory for TCP socket buffers, since I monitored at /proc/net/sockstat. The system did not hang, since it can respond to ping. When trying to connect via ssh, ssh can establish a new TCP connection, but it cannot exchange auth. info. So, we cannot connect the machine via ssh. Even at a console machine, the system does not accept any input over 24 hours later. I expected TCP timeout released socket buffers and the system recovered. But it didn't happen. Could you analyze this problem? I attached the system information. If more information is needed to analyze this problem, let me know. Thanks a lot, Kumiko - Kernel version: Linux 2.6.20 #12 SMP Tue Mar 6 16:55:47 EST 2007 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz unknown GNU/Linux Config: CONFIG_EDD=y CONFIG_HIGHMEM4G=y CONFIG_VMSPLIT_2G=y CONFIG_PAGE_OFFSET=0x7800 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_HIGHPTE=y Software env: Gnu C 3.4.3 Gnu make 3.80 binutils 2.15.92.0.2 util-linux 2.12a mount 2.12a module-init-tools 3.0 e2fsprogs 1.36 nfs-utils 1.0.7 Linux C Library2.3.4 Dynamic linker (ldd) 2.3.4 Procps 3.2.5 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 udev 054 Modules Loaded nfsd exportfs lockd sunrpc ipv6 af_packet floppy ide_cd cdrom loop 8250_pci 8250 serial_core ohci_hcd usbcore Boot log: kernel: 1887MB HIGHMEM available. kernel: 2048MB LOWMEM available. kernel: found SMP MP-table at 000f4fd0 kernel: Zone PFN ranges: kernel: DMA 0 -> 4096 kernel: Normal 4096 -> 524288 kernel: HighMem524288 -> 1007610 kernel: early_node_map[1] active PFN ranges kernel: 0:0 -> 1007610 kernel: Dentry cache hash table entries: 262144 (order: 8, 1048576 bytes) kernel: Inode-cache hash table entries: 131072 (order: 7, 524288 bytes) kernel: Memory: 3993004k/4030440k available (1922k kernel code, 36308k reserved, 717k data, 216k init, 1933288k highmem) kernel: TCP established hash table entries: 262144 (order: 9, 2097152 bytes) kernel: TCP bind hash table entries: 65536 (order: 7, 524288 bytes) kernel: TCP: Hash tables configured (established 262144 bind 65536) sysctl: sunrpc.tcp_slot_table_entries = 16 net.ipv4.tcp_allowed_congestion_control = cubic reno net.ipv4.tcp_available_congestion_control = cubic reno net.ipv4.tcp_slow_start_after_idle = 1 net.ipv4.tcp_workaround_signed_windows = 0 net.ipv4.tcp_base_mss = 512 net.ipv4.tcp_mtu_probing = 0 net.ipv4.tcp_abc = 0 net.ipv4.tcp_congestion_control = cubic net.ipv4.tcp_tso_win_divisor = 3 net.ipv4.tcp_moderate_rcvbuf = 1 net.ipv4.tcp_no_metrics_save = 0 net.ipv4.tcp_low_latency = 0 net.ipv4.tcp_frto = 0 net.ipv4.tcp_tw_reuse = 0 net.ipv4.tcp_adv_win_scale = 2 net.ipv4.tcp_app_win = 31 net.ipv4.tcp_rmem = 409687380 1048576 net.ipv4.tcp_wmem = 409616384 1048576 net.ipv4.tcp_mem = 2457632768 49152 net.ipv4.tcp_dsack = 1 net.ipv4.tcp_ecn = 0 net.ipv4.tcp_reordering = 3 net.ipv4.tcp_fack = 1 net.ipv4.tcp_orphan_retries = 0 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.tcp_rfc1337 = 0 net.ipv4.tcp_stdurg = 0 net.ipv4.tcp_abort_on_overflow = 0 net.ipv4.tcp_tw_recycle = 0 net.ipv4.tcp_syncookies = 0 net.ipv4.tcp_fin_timeout = 60 net.ipv4.tcp_retries2 = 15 net.ipv4.tcp_retries1 = 3 net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_max_tw_buckets = 18 net.ipv4.tcp_max_orphans = 32768 net.ipv4.tcp_synack_retries = 5 net.ipv4.tcp_syn_retries = 5 net.ipv4.tcp_retrans_collapse = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 fs.nfs.nlm_tcpport = 0 Slabtop: (not at load time) Active / Total Objects (% used): 38515 / 42977 (89.6%) Active / Total Slabs (% used) : 2410 / 2416 (99.8%) Active / Total Caches (% used) : 75 / 120 (62.5%) Active / Total Size (% used) : 9099.07K / 9653.93K (94.3%) Minimum / Average / Maximum Object : 0.01K / 0.22K / 128.00K - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHES 0/4] simple fixes and cleanups
Hi David, Please consider pulling from: master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22.git. - Arnaldo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] [SOCKET]: Export __sock_recv_timestamp
Kernel: arch/x86_64/boot/bzImage is ready (#2)
MODPOST 1816 modules
WARNING: "__sock_recv_timestamp" [net/sctp/sctp.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/packet/af_packet.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/key/af_key.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/ipv6/ipv6.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/atm/atm.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [_all] Error 2
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/socket.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
From 2a7f320e8e64e56f5cb7fd076d943d785f52229c Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 00:39:35 -0300
Subject: [PATCH 1/4] [SOCKET]: Export __sock_recv_timestamp
Kernel: arch/x86_64/boot/bzImage is ready (#2)
MODPOST 1816 modules
WARNING: "__sock_recv_timestamp" [net/sctp/sctp.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/packet/af_packet.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/key/af_key.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/ipv6/ipv6.ko] undefined!
WARNING: "__sock_recv_timestamp" [net/atm/atm.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [_all] Error 2
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
net/socket.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 9994332..eeeb772 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -614,6 +614,8 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
}
}
+EXPORT_SYMBOL_GPL(__sock_recv_timestamp);
+
static inline int __sock_recvmsg(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, size_t size, int flags)
{
--
1.5.0.2
[PATCH 2/4] [TR]: Use tr_hdr() were appropriate
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/tokenring/lanstreamer.c |6 +++---
drivers/net/tokenring/olympic.c |9 +
drivers/s390/net/qeth_main.c|2 +-
net/802/tr.c|3 ++-
4 files changed, 11 insertions(+), 9 deletions(-)
From 73bcc05360ee860addaa48f51c31efa5f46d7dc2 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 00:43:41 -0300
Subject: [PATCH 2/4] [TR]: Use tr_hdr() were appropriate
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/tokenring/lanstreamer.c |6 +++---
drivers/net/tokenring/olympic.c |9 +
drivers/s390/net/qeth_main.c|2 +-
net/802/tr.c|3 ++-
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/tokenring/lanstreamer.c b/drivers/net/tokenring/lanstreamer.c
index e999feb..5e1b884 100644
--- a/drivers/net/tokenring/lanstreamer.c
+++ b/drivers/net/tokenring/lanstreamer.c
@@ -1607,10 +1607,12 @@ static void streamer_arb_cmd(struct net_device *dev)
frame_data, buffer_len);
} while (next_ptr && (buff_off = next_ptr));
+ mac_frame->dev = dev;
+ mac_frame->protocol = tr_type_trans(mac_frame, dev);
#if STREAMER_NETWORK_MONITOR
printk(KERN_WARNING "%s: Received MAC Frame, details: \n",
dev->name);
- mac_hdr = (struct trh_hdr *) mac_frame->data;
+ mac_hdr = tr_hdr(mac_frame);
printk(KERN_WARNING
"%s: MAC Frame Dest. Addr: %02x:%02x:%02x:%02x:%02x:%02x \n",
dev->name, mac_hdr->daddr[0], mac_hdr->daddr[1],
@@ -1622,8 +1624,6 @@ static void streamer_arb_cmd(struct net_device *dev)
mac_hdr->saddr[2], mac_hdr->saddr[3],
mac_hdr->saddr[4], mac_hdr->saddr[5]);
#endif
- mac_frame->dev = dev;
- mac_frame->protocol = tr_type_trans(mac_frame, dev);
netif_rx(mac_frame);
/* Now tell the card we have dealt with the received frame */
diff --git a/drivers/net/tokenring/olympic.c b/drivers/net/tokenring/olympic.c
index 8f4ecc1..7f3226e 100644
--- a/drivers/net/tokenring/olympic.c
+++ b/drivers/net/tokenring/olympic.c
@@ -1440,16 +1440,17 @@ static void olympic_arb_cmd(struct net_device *dev)
next_ptr=readw(buf_ptr+offsetof(struct mac_receive_buffer,next));
} while (next_ptr && (buf_ptr=olympic_priv->olympic_lap + ntohs(next_ptr)));
+ mac_frame->dev = dev;
+ mac_frame->protocol = tr_type_trans(mac_frame, dev);
+
if (olympic_priv->olympic_network_monitor) {
struct trh_hdr *mac_hdr ;
printk(KERN_WARNING "%s: Received MAC Frame, details: \n",dev->name) ;
- mac_hdr = (struct trh_hdr *)mac_frame->data ;
+ mac_hdr = tr_hdr(mac_frame);
printk(KERN_WARNING "%s: MAC Frame Dest. Addr: %02x:%02x:%02x:%02x:%02x:%02x \n", dev->name , mac_hdr->daddr[0], mac_hdr->daddr[1], mac_hdr->daddr[2], mac_hdr->daddr[3], mac_hdr->daddr[4], mac_hdr->daddr[5]) ;
printk(KERN_WARNING "%s: MAC Frame Srce. Addr: %02x:%02x:%02x:%02x:%02x:%02x \n", dev->name , mac_hdr->saddr[0], mac_hdr->saddr[1], mac_hdr->saddr[2], mac_hdr->saddr[3], mac_hdr->saddr[4], mac_hdr->saddr[5]) ;
}
- mac_frame->dev = dev ;
- mac_frame->protocol = tr_type_trans(mac_frame,dev);
- netif_rx(mac_frame) ;
+ netif_rx(mac_frame);
dev->last_rx = jiffies;
drop_frame:
diff --git a/drivers/s390/net/qeth_main.c b/drivers/s390/net/qeth_main.c
index d8a86f5..f2b9b1b 100644
--- a/drivers/s390/net/qeth_main.c
+++ b/drivers/s390/net/qeth_main.c
@@ -2308,7 +2308,7 @@ qeth_rebuild_skb_fake_ll_tr(struct qeth_card *card, struct sk_buff *skb,
QETH_DBF_TEXT(trace,5,"skbfktr");
skb->mac.raw = skb->data - QETH_FAKE_LL_LEN_TR;
/* this is a fake ethernet header */
- fake_hdr = (struct trh_hdr *) skb->mac.raw;
+ fake_hdr = tr_hdr(skb);
/* the destination MAC address */
switch (skb->pkt_type){
diff --git a/net/802/tr.c b/net/802/tr.c
index 96bd144..a6a6d46 100644
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -189,11 +189,12 @@ static int tr_rebuild_header(struct sk_buff *skb)
__be16 tr_type_trans(struct sk_buff *skb, struct net_device *dev)
{
- struct trh_hdr *trh=(struct trh_hdr *)skb->data;
+ struct trh_hdr *trh;
struct trllc *trllc;
unsigned riflen=0;
skb->mac.raw = skb->data;
+ trh = tr_hdr(skb);
if(trh->saddr[0] & TR_RII)
riflen = (ntohs(trh->rcf) & TR_RCF_LEN_MASK) >> 8;
--
1.5.0.2
[PATCH 3/4] [TR]: Make tr_type_trans set skb->dev
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/tokenring/3c359.c |4
drivers/net/tokenring/ibmtr.c |1 -
drivers/net/tokenring/lanstreamer.c |3 ---
drivers/net/tokenring/olympic.c |3 ---
drivers/net/tokenring/smctr.c |2 --
drivers/net/tokenring/tms380tr.c|1 -
net/802/tr.c|1 +
net/atm/lec.c |4 +++-
8 files changed, 4 insertions(+), 15 deletions(-)
From 2f15aa46c1cc68cb41ad17a6259d97a227527be9 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Sat, 10 Mar 2007 00:47:21 -0300
Subject: [PATCH 3/4] [TR]: Make tr_type_trans set skb->dev
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/net/tokenring/3c359.c |4
drivers/net/tokenring/ibmtr.c |1 -
drivers/net/tokenring/lanstreamer.c |3 ---
drivers/net/tokenring/olympic.c |3 ---
drivers/net/tokenring/smctr.c |2 --
drivers/net/tokenring/tms380tr.c|1 -
net/802/tr.c|1 +
net/atm/lec.c |4 +++-
8 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/net/tokenring/3c359.c b/drivers/net/tokenring/3c359.c
index 7580bde..d293423 100644
--- a/drivers/net/tokenring/3c359.c
+++ b/drivers/net/tokenring/3c359.c
@@ -933,8 +933,6 @@ static void xl_rx(struct net_device *dev)
return ;
}
- skb->dev = dev ;
-
while (xl_priv->rx_ring_tail != temp_ring_loc) {
copy_len = xl_priv->xl_rx_ring[xl_priv->rx_ring_tail].upfraglen & 0x7FFF ;
frame_length -= copy_len ;
@@ -967,8 +965,6 @@ static void xl_rx(struct net_device *dev)
return ;
}
- skb->dev = dev ;
-
skb2 = xl_priv->rx_ring_skb[xl_priv->rx_ring_tail] ;
pci_unmap_single(xl_priv->pdev, xl_priv->xl_rx_ring[xl_priv->rx_ring_tail].upfragaddr, xl_priv->pkt_buf_sz,PCI_DMA_FROMDEVICE) ;
skb_put(skb2, frame_length) ;
diff --git a/drivers/net/tokenring/ibmtr.c b/drivers/net/tokenring/ibmtr.c
index 0d97e10..41588ef 100644
--- a/drivers/net/tokenring/ibmtr.c
+++ b/drivers/net/tokenring/ibmtr.c
@@ -1772,7 +1772,6 @@ static void tr_rx(struct net_device *dev)
/*BMS again, if she comes in with few but leaves with many */
skb_reserve(skb, sizeof(struct trh_hdr) - lan_hdr_len);
skb_put(skb, length);
- skb->dev = dev;
data = skb->data;
rbuffer_len = ntohs(readw(rbuf + offsetof(struct rec_buf, buf_len)));
rbufdata = rbuf + offsetof(struct rec_buf, data);
diff --git a/drivers/net/tokenring/lanstreamer.c b/drivers/net/tokenring/lanstreamer.c
index 5e1b884..5d849c0 100644
--- a/drivers/net/tokenring/lanstreamer.c
+++ b/drivers/net/tokenring/lanstreamer.c
@@ -944,8 +944,6 @@ static void streamer_rx(struct net_device *dev)
printk(KERN_WARNING "%s: Not enough memory to copy packet to upper layers. \n", dev->name);
streamer_priv->streamer_stats.rx_dropped++;
} else { /* we allocated an skb OK */
-skb->dev = dev;
-
if (buffer_cnt == 1) {
/* release the DMA mapping */
pci_unmap_single(streamer_priv->pci_dev,
@@ -1607,7 +1605,6 @@ static void streamer_arb_cmd(struct net_device *dev)
frame_data, buffer_len);
} while (next_ptr && (buff_off = next_ptr));
- mac_frame->dev = dev;
mac_frame->protocol = tr_type_trans(mac_frame, dev);
#if STREAMER_NETWORK_MONITOR
printk(KERN_WARNING "%s: Received MAC Frame, details: \n",
diff --git a/drivers/net/tokenring/olympic.c b/drivers/net/tokenring/olympic.c
index 7f3226e..068f976 100644
--- a/drivers/net/tokenring/olympic.c
+++ b/drivers/net/tokenring/olympic.c
@@ -814,8 +814,6 @@ static void olympic_rx(struct net_device *dev)
olympic_priv->rx_ring_last_received += i ;
olympic_priv->rx_ring_last_received &= (OLYMPIC_RX_RING_SIZE -1) ;
} else {
- skb->dev = dev ;
-
/* Optimise based upon number of buffers used.
If only one buffer is used we can simply swap the buffers around.
If more than one then we must use the new buffer and copy the information
@@ -1440,7 +1438,6 @@ static void olympic_arb_cmd(struct net_device *dev)
next_ptr=readw(buf_ptr+offsetof(struct mac_receive_buffer,next));
} while (next_ptr && (buf_ptr=olympic_priv->olympic_lap + ntohs(next_ptr)));
- mac_frame->dev = dev;
mac_frame->protocol = tr_type_trans(mac_frame, dev);
if (olympic_priv->olympic_network_monitor) {
diff --git a/drivers/net/tokenring/smctr.c b/drivers/net/tokenring/smctr.c
index cec282a..b0296d8 100644
--- a/drivers/net/tokenring/smctr.c
+++ b/drivers/net/tokenring/smctr.c
@@ -3896,7 +3896,6 @@ static int smctr_process_rx_packet(MAC_HEADER *rmf, __u16 size,
tp->MacStat.rx_bytes += skb->len;
/* Kick the packet on up. */
-skb->dev = dev;
skb->protocol = tr_type_trans(skb, dev);
netif_rx(skb);
dev->last_rx = jiffies;
@@ -4483,7 +4
Re: [PATCHES 0/4] simple fixes and cleanups
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]> Date: Sat, 10 Mar 2007 00:59:36 -0300 > Please consider pulling from: > > master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22.git. Pulled, thanks a lot. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] NetXen: Driver bug fixes
On Friday 09 March 2007 22:26, Jeff Garzik wrote: > Linsys Contractor Mithlesh Thukral wrote: > > Hi All, > > > > I will be sending updates to NetXen: 1G/10G Ethernet driver in subsequent > > mails. The patches will be with respect to netdev#upstream. > > Are you sure you don't want some of these in #upstream-fixes, queued for > 2.6.21-rc? We really want them in both places. If we send them to #upstream-fixes, they'll break #upstream. Should we send them against both of these branches? Pardon for this newbie question :-). Thanks. -Amit - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] NetXen: Fix softlock seen on some machines during hardware writes
On Friday 09 March 2007 21:56, Stephen Hemminger wrote:
> Linsys Contractor Mithlesh Thukral wrote:
> > NetXen: This will fix a softlock seen on some machines.
> > The reason was too much time was spent waiting for writes to go through.
> >
> > Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]>
> > ---
> > drivers/net/netxen/netxen_nic.h |1 +
> > drivers/net/netxen/netxen_nic_ethtool.c |1 +
> > drivers/net/netxen/netxen_nic_init.c| 11 +--
> > 3 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/netxen/netxen_nic.h
> > b/drivers/net/netxen/netxen_nic.h index 38d7409..c85c2cb 100644
> > --- a/drivers/net/netxen/netxen_nic.h
> > +++ b/drivers/net/netxen/netxen_nic.h
> > @@ -236,6 +236,7 @@ #define MPORT_MULTI_FUNCTION_MODE 0x
> >
> > #include "netxen_nic_phan_reg.h"
> > extern unsigned long long netxen_dma_mask;
> > +extern unsigned long last_schedule_time;
> >
> > /*
> > * NetXen host-peg signal message structure
> > diff --git a/drivers/net/netxen/netxen_nic_ethtool.c
> > b/drivers/net/netxen/netxen_nic_ethtool.c index 3752d2a..d49a7d8 100644
> > --- a/drivers/net/netxen/netxen_nic_ethtool.c
> > +++ b/drivers/net/netxen/netxen_nic_ethtool.c
> > @@ -455,6 +455,7 @@ netxen_nic_set_eeprom(struct net_device
> > }
> > printk(KERN_INFO "%s: flash unlocked. \n",
> > netxen_nic_driver_name);
> > + last_schedule_time = jiffies;
> > ret = netxen_flash_erase_secondary(adapter);
> > if (ret != FLASH_SUCCESS) {
> > printk(KERN_ERR "%s: Flash erase failed.\n",
> > diff --git a/drivers/net/netxen/netxen_nic_init.c
> > b/drivers/net/netxen/netxen_nic_init.c index b2e776f..53ca21e 100644
> > --- a/drivers/net/netxen/netxen_nic_init.c
> > +++ b/drivers/net/netxen/netxen_nic_init.c
> > @@ -42,6 +42,8 @@ struct crb_addr_pair {
> > u32 data;
> > };
> >
> > +unsigned long last_schedule_time;
> > +
> > #define NETXEN_MAX_CRB_XFORM 60
> > static unsigned int crb_addr_xform[NETXEN_MAX_CRB_XFORM];
> > #define NETXEN_ADDR_ERROR (0x)
> > @@ -404,9 +406,14 @@ static inline int do_rom_fast_write(stru
> > static inline int
> > do_rom_fast_read(struct netxen_adapter *adapter, int addr, int *valp)
> > {
> > + if (jiffies > (last_schedule_time + (8 * HZ))) {
> > + last_schedule_time = jiffies;
> > + schedule();
> > + }
> > +
> > netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ADDRESS, addr);
> > netxen_nic_reg_write(adapter, NETXEN_ROMUSB_ROM_ABYTE_CNT, 3);
> > - udelay(70); /* prevent bursting on CRB */
> > + udelay(100);/* prevent bursting on CRB */
>
> To prevent PCI write posting issues, you should always do a dummy read
> before
> any delay.
Good point. Thanks.
-Amit
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20-rc4-mm1: PCI=n: drivers/net/3c59x.c compile error
Hello, Randy Dunlap wrote: >> Erm, before I do that, could somebody explain what >> >> #define HAVE_PCI_REQ_REGIONS 2 >> >> accompanying their declaration is for? I have't found any references to it >> in >> the source. Should I duplicate it for CONFIG_PCI=n case (I guess not)? > > I wouldn't since it's not used anywhere, but maybe Tejun could comment > on it... This is the first time I see that macro. There is no user in the whole source. I think the best way is to just kill it. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] NET: Multiple queue network device support
* Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 455d589..42b635c 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1477,6 +1477,49 @@ gso:
> skb->tc_verd = SET_TC_AT(skb->tc_verd,AT_EGRESS);
> #endif
> if (q->enqueue) {
> +#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
> + int queue_index;
> + /* If we're a multi-queue device, get a queue index to lock */
> + if (netif_is_multiqueue(dev))
> + {
> + /* Get the queue index and lock it. */
> + if (likely(q->ops->map_queue)) {
> + queue_index = q->ops->map_queue(skb, q);
> +
> spin_lock(&dev->egress_subqueue[queue_index].queue_lock);
> + rc = q->enqueue(skb, q);
> + /*
> + * Unlock because the underlying qdisc
> + * may queue and send a packet from a
> + * different queue.
> + */
> +
> spin_unlock(&dev->egress_subqueue[queue_index].queue_lock);
> + qdisc_run(dev);
I really dislike this asymmetric locking logic, while enqueue() is called
with queue_lock held dequeue() is repsonsible to acquire the lock for
qdisc_restart().
> + rc = rc == NET_XMIT_BYPASS
> +? NET_XMIT_SUCCESS : rc;
> + goto out;
> + } else {
> + printk(KERN_CRIT "Device %s is "
> + "multiqueue, but map_queue is "
> + "undefined in the qdisc!!\n",
> + dev->name);
> + kfree_skb(skb);
Move this check to tc_modify_qdisc(), it's useless to check this for
every packet being delivered.
> + }
> + } else {
> + /* We're not a multi-queue device. */
> + spin_lock(&dev->queue_lock);
> + q = dev->qdisc;
> + if (q->enqueue) {
> + rc = q->enqueue(skb, q);
> + qdisc_run(dev);
> + spin_unlock(&dev->queue_lock);
> + rc = rc == NET_XMIT_BYPASS
> +? NET_XMIT_SUCCESS : rc;
> + goto out;
> + }
> + spin_unlock(&dev->queue_lock);
Please don't duplicate already existing code.
> @@ -130,6 +140,72 @@ static inline int qdisc_restart(struct net_device *dev)
> }
>
> {
> +#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
> + if (netif_is_multiqueue(dev)) {
> + if (likely(q->ops->map_queue)) {
> + queue_index = q->ops->map_queue(skb, q);
> + } else {
> + printk(KERN_CRIT "Device %s is "
> + "multiqueue, but map_queue is "
> + "undefined in the qdisc!!\n",
> + dev->name);
> + goto requeue;
> + }
Yet another condition completely useless for every transmission.
> +
> spin_unlock(&dev->egress_subqueue[queue_index].queue_lock);
> + /* Check top level device, and any sub-device */
> + if ((!netif_queue_stopped(dev)) &&
> + (!netif_subqueue_stopped(dev, queue_index))) {
> + int ret;
> + ret =
> dev->hard_start_subqueue_xmit(skb, dev, queue_index);
> + if (ret == NETDEV_TX_OK) {
> + if (!nolock) {
> + netif_tx_unlock(dev);
> + }
> + return -1;
> + }
> + if (ret == NETDEV_TX_LOCKED && nolock) {
> +
> spin_lock(&dev->egress_subqueue[queue_index].queue_lock);
> + goto collision;
> + }
> + }
> + /* NETDEV_TX_BUSY - we need to requeue */
> + /* Release the driver */
> + if (!nolock) {
> + neti
Re: [PATCH 2/2] e1000: Implement the new kernel API for multiqueue TX support.
* Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09 > > From: Peter Waskiewicz Jr. <[EMAIL PROTECTED]> > > Several newer e1000 chipsets support multiple RX and TX queues. Most > commonly, 82571's and ESB2LAN support 2 rx and 2 rx queues. > > Signed-off-by: Peter Waskiewicz Jr. <[EMAIL PROTECTED]> > Signed-off-by: Auke Kok <[EMAIL PROTECTED]> > --- > > drivers/net/Kconfig | 13 ++ > drivers/net/e1000/e1000.h | 23 +++ > drivers/net/e1000/e1000_ethtool.c | 43 ++ > drivers/net/e1000/e1000_main.c| 269 > +++-- > 4 files changed, 304 insertions(+), 44 deletions(-) > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index ad92b6a..2d758ab 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/net/Kconfig > @@ -1988,6 +1988,19 @@ config E1000_DISABLE_PACKET_SPLIT > > If in doubt, say N. > > +config E1000_MQ > + bool "Enable Tx/Rx Multiqueue Support (EXPERIMENTAL)" > + depends on E1000 && NET_MULTI_QUEUE_DEVICE && EXPERIMENTAL Would be better to just select NET_MULTI_QUEUE_DEVICE instead of depending on it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity
Probably should copy me and [EMAIL PROTECTED] Other than
that, this looks fine to me. I'll queue it up shortly.
John
On Fri, Mar 09, 2007 at 01:11:46PM +1100, Tony Breeds wrote:
> On Wed, Mar 07, 2007 at 03:00:57PM -0800, Andrew Morton wrote:
> > On Wed, 7 Mar 2007 23:41:16 +0100
> > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, Mar 06, 2007 at 12:44:08AM -0800, Andrew Morton wrote:
> > > >...
> > > > Changes since 2.6.20-rc2-mm1:
> > > >...
> > > > git-netdev-all.patch
> > > >...
> > > > git trees
> > > >...
> > >
> > > drivers/net/wireless/libertas/debugfs.c contains:
> > > #define item_addr(n) ((u32) &((wlan_adapter *)0)->n)
> > >
> > > This is wrong on 64bit architectures.
> >
> > Is OK - it is simply yet another reimplementation of offsetof(). Hint.
>
> Perhaps something like?
>
> Against 2.6.21-rc3-mm2
>
> From: Tony Breeds <[EMAIL PROTECTED]>
>
> Cleanup drivers/net/wireless/libertas/debugfs.c to use standard kernel macros
> and functions.
>
> Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
>
> ---
> only compile tested on x86
>
> debugfs.c | 41 -
> 1 file changed, 4 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/debugfs.c
> b/drivers/net/wireless/libertas/debugfs.c
> index 3ad1e03..51dfd20 100644
> --- a/drivers/net/wireless/libertas/debugfs.c
> +++ b/drivers/net/wireless/libertas/debugfs.c
> @@ -1772,8 +1772,8 @@ void libertas_debugfs_remove_one(wlan_private *priv)
>
> /* debug entry */
>
> -#define item_size(n) (sizeof ((wlan_adapter *)0)->n)
> -#define item_addr(n) ((u32) &((wlan_adapter *)0)->n)
> +#define item_size(n) (FIELD_SIZEOF(wlan_adapter, n))
> +#define item_addr(n) (offsetof(wlan_adapter, n))
>
> struct debug_data {
> char name[32];
> @@ -1789,40 +1789,7 @@ static struct debug_data items[] = {
> {"psstate", item_size(psstate), item_addr(psstate)},
> };
>
> -static int num_of_items = sizeof(items) / sizeof(items[0]);
> -
> -/**
> - * @brief convert string to number
> - *
> - * @param spointer to numbered string
> - * @return converted number from string s
> - */
> -static int string_to_number(char *s)
> -{
> - int r = 0;
> - int base = 0;
> -
> - if ((strncmp(s, "0x", 2) == 0) || (strncmp(s, "0X", 2) == 0))
> - base = 16;
> - else
> - base = 10;
> -
> - if (base == 16)
> - s += 2;
> -
> - for (s = s; *s != 0; s++) {
> - if ((*s >= 48) && (*s <= 57))
> - r = (r * base) + (*s - 48);
> - else if ((*s >= 65) && (*s <= 70))
> - r = (r * base) + (*s - 55);
> - else if ((*s >= 97) && (*s <= 102))
> - r = (r * base) + (*s - 87);
> - else
> - break;
> - }
> -
> - return r;
> -}
> +static int num_of_items = ARRAY_SIZE(items);
>
> /**
> * @brief proc read function
> @@ -1912,7 +1879,7 @@ static int wlan_debugfs_write(struct file *f, const
> char __user *buf,
> if (!p2)
> break;
> p2++;
> - r = string_to_number(p2);
> + r = simple_strtoul(p2, NULL, 0);
> if (d[i].size == 1)
> *((u8 *) d[i].addr) = (u8) r;
> else if (d[i].size == 2)
> Yours Tony
>
> linux.conf.auhttp://linux.conf.au/ || http://lca2008.linux.org.au/
> Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq
Auke Kok wrote: From: Auke Kok <[EMAIL PROTECTED]> DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts after having called pci_request_irq. This obviously requires us to finish our software setup which assigns the irq handler before we request the irq. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000_main.c | 66 +++- 1 files changed, 45 insertions(+), 21 deletions(-) All these do indeed look like fixes to me. But they look like low priority fixes that would need some public testing behind them, and it's pretty late in the 2.6.21-rc game. I'll merge them into an e1000-fixes branch for now (and propagates through #ALL to akpm's -mm). If replies to this email indicate we really should push these upstream for 2.6.21-rc, it will be easy enough to do so via #e1000-fixes. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow pktgen to work with loopback devices.
Josh Triplett wrote:
pktgen currently only works on network devices with type ARPHRD_ETHER. Add
support for the loopback device, type ARPHRD_LOOPBACK.
I've tested this on my system, using a modified pktgen.conf-1-1 with
s/eth1/lo/g, and it works fine; the network device statistics confirm packet
transmission and receipt.
Thanks to Sarah Bailey for discovering and tracking down the problem.
Signed-off-by: Josh Triplett <[EMAIL PROTECTED]>
---
I intentionally didn't change the error message "not an ethernet device". For
the purposes of pktgen, loopback devices act like ethernet devices.
net/core/pktgen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 74a9a32..6fc6f9d 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -1930,7 +1930,7 @@ static struct net_device *pktgen_setup_dev(struct
pktgen_dev *pkt_dev)
printk("pktgen: no such netdevice: \"%s\"\n", pkt_dev->ifname);
goto out;
}
- if (odev->type != ARPHRD_ETHER) {
+ if (odev->type != ARPHRD_LOOPBACK && odev->type != ARPHRD_ETHER) {
printk("pktgen: not an ethernet device: \"%s\"\n",
pkt_dev->ifname);
I'll let DaveM queue this (or not)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq
Jeff Garzik wrote: Auke Kok wrote: From: Auke Kok <[EMAIL PROTECTED]> DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts after having called pci_request_irq. This obviously requires us to finish our software setup which assigns the irq handler before we request the irq. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000_main.c | 66 +++- 1 files changed, 45 insertions(+), 21 deletions(-) All these do indeed look like fixes to me. But they look like low priority fixes that would need some public testing behind them, and it's pretty late in the 2.6.21-rc game. I'll merge them into an e1000-fixes branch for now (and propagates through #ALL to akpm's -mm). If replies to this email indicate we really should push these upstream for 2.6.21-rc, it will be easy enough to do so via #e1000-fixes. Personally, I think this is really really needed. I'm surprised that you already didn't push this considering Andrew pulled this into -mm immediately. We've also been crunching this patch in our labs for a whole week now doing all sorts of load/unload up/down torture and it's a real improvement. Especially ESB2 systems were hit with this bug irregardless of the DEBUG_SHIRQ code active or not, so it's a real bug with real fix. but hey, it doesn't fix a new problem :) Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21-rc2-mm2: drivers/net/wireless/libertas/debugfs.c addr bogosity
On Fri, 9 Mar 2007 09:19:07 -0500 John W. Linville wrote:
> Probably should copy me and [EMAIL PROTECTED] Other than
> that, this looks fine to me. I'll queue it up shortly.
>
> John
>
> On Fri, Mar 09, 2007 at 01:11:46PM +1100, Tony Breeds wrote:
> > On Wed, Mar 07, 2007 at 03:00:57PM -0800, Andrew Morton wrote:
> > > On Wed, 7 Mar 2007 23:41:16 +0100
> > > Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Tue, Mar 06, 2007 at 12:44:08AM -0800, Andrew Morton wrote:
> > > > >...
> > > > > Changes since 2.6.20-rc2-mm1:
> > > > >...
> > > > > git-netdev-all.patch
> > > > >...
> > > > > git trees
> > > > >...
> > > >
> > > > drivers/net/wireless/libertas/debugfs.c contains:
> > > > #define item_addr(n) ((u32) &((wlan_adapter *)0)->n)
> > > >
> > > > This is wrong on 64bit architectures.
> > >
> > > Is OK - it is simply yet another reimplementation of offsetof(). Hint.
> >
> > Perhaps something like?
> >
> > Against 2.6.21-rc3-mm2
> >
> > From: Tony Breeds <[EMAIL PROTECTED]>
> >
> > Cleanup drivers/net/wireless/libertas/debugfs.c to use standard kernel
> > macros and functions.
> >
> > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
> >
> > ---
> > only compile tested on x86
> >
> > debugfs.c | 41 -
> > 1 file changed, 4 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/net/wireless/libertas/debugfs.c
> > b/drivers/net/wireless/libertas/debugfs.c
> > index 3ad1e03..51dfd20 100644
> > --- a/drivers/net/wireless/libertas/debugfs.c
> > +++ b/drivers/net/wireless/libertas/debugfs.c
> > @@ -1772,8 +1772,8 @@ void libertas_debugfs_remove_one(wlan_private *priv)
> >
> > /* debug entry */
> >
> > -#define item_size(n) (sizeof ((wlan_adapter *)0)->n)
> > -#define item_addr(n) ((u32) &((wlan_adapter *)0)->n)
> > +#define item_size(n) (FIELD_SIZEOF(wlan_adapter, n))
Good to use FIELD_SIZEOF(), but in general, we prefer to use it
directly, not in yet another wrapper.
> > +#define item_addr(n) (offsetof(wlan_adapter, n))
> >
> > struct debug_data {
> > char name[32];
> > @@ -1789,40 +1789,7 @@ static struct debug_data items[] = {
> > {"psstate", item_size(psstate), item_addr(psstate)},
> > };
> >
> > -static int num_of_items = sizeof(items) / sizeof(items[0]);
> > -
> > -/**
> > - * @brief convert string to number
> > - *
> > - * @param s pointer to numbered string
> > - * @return converted number from string s
> > - */
> > -static int string_to_number(char *s)
> > -{
> > - int r = 0;
> > - int base = 0;
> > -
> > - if ((strncmp(s, "0x", 2) == 0) || (strncmp(s, "0X", 2) == 0))
> > - base = 16;
> > - else
> > - base = 10;
> > -
> > - if (base == 16)
> > - s += 2;
> > -
> > - for (s = s; *s != 0; s++) {
> > - if ((*s >= 48) && (*s <= 57))
> > - r = (r * base) + (*s - 48);
> > - else if ((*s >= 65) && (*s <= 70))
> > - r = (r * base) + (*s - 55);
> > - else if ((*s >= 97) && (*s <= 102))
> > - r = (r * base) + (*s - 87);
> > - else
> > - break;
> > - }
> > -
> > - return r;
> > -}
> > +static int num_of_items = ARRAY_SIZE(items);
> >
> > /**
> > * @brief proc read function
> > @@ -1912,7 +1879,7 @@ static int wlan_debugfs_write(struct file *f, const
> > char __user *buf,
> > if (!p2)
> > break;
> > p2++;
> > - r = string_to_number(p2);
> > + r = simple_strtoul(p2, NULL, 0);
> > if (d[i].size == 1)
> > *((u8 *) d[i].addr) = (u8) r;
> > else if (d[i].size == 2)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/3c59x.c | 28 -
drivers/net/mv643xx_eth.c | 10 --
drivers/net/myri10ge/myri10ge.c | 42 +--
drivers/net/netxen/netxen_nic_hw.c |5 ++-
drivers/net/r8169.c | 14
drivers/net/sky2.c | 24 +--
drivers/net/tokenring/ibmtr.c | 25 +++
drivers/net/via-rhine.c | 32 +++-
drivers/net/wan/z85230.c|2 +-
drivers/net/wireless/bcm43xx/bcm43xx_main.c |6 ++--
drivers/net/wireless/bcm43xx/bcm43xx_phy.c | 10 +-
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 10 +-
12 files changed, 145 insertions(+), 63 deletions(-)
Alan Cox (1):
z85230: Fix FIFO handling
Brice Goglin (4):
myri10ge: fix error checking and return value in myri10ge_allocate_rings
myri10ge: use pci_map_page to prepare the dmatest buffer
myri10ge: prevent 4k rdma on SGI TIOCE chipset
myri10ge: add a wc_enabled flag to myri10ge_priv
Dale Farnsworth (1):
mv643xx: Clear pending interrupts before calling request_irq
Francois Romieu (2):
r8169: revert bogus BMCR reset
r8169: fix a race between PCI probe and dev_open
Joerg Sommer (1):
bcm43xx: Fix bug in frequency to channel conversion
Larry Finger (1):
bcm43xx: Fix errors in specs to code translation in B6PHY init
Pavel Roskin (1):
bcm43xx: Fix assertion failures in interrupt handler
Ralf Baechle (3):
netxen: fix warnings
3c59x: Fix several modpost warnings
ibmtr: Drain rich supply of modpost warnings.
Roger Luethi (1):
via-rhine: set avoid_D3 for broken BIOSes
Stephen Hemminger (1):
sky2: turn off Rx checksum on bad hardware
diff --git a/drivers/net/3c59x.c b/drivers/net/3c59x.c
index 7299577..b406ecf 100644
--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -858,19 +858,7 @@ static struct eisa_device_id vortex_eisa_ids[] = {
};
MODULE_DEVICE_TABLE(eisa, vortex_eisa_ids);
-static int vortex_eisa_probe(struct device *device);
-static int vortex_eisa_remove(struct device *device);
-
-static struct eisa_driver vortex_eisa_driver = {
- .id_table = vortex_eisa_ids,
- .driver = {
- .name= "3c59x",
- .probe = vortex_eisa_probe,
- .remove = vortex_eisa_remove
- }
-};
-
-static int vortex_eisa_probe(struct device *device)
+static int __init vortex_eisa_probe(struct device *device)
{
void __iomem *ioaddr;
struct eisa_device *edev;
@@ -893,7 +881,7 @@ static int vortex_eisa_probe(struct device *device)
return 0;
}
-static int vortex_eisa_remove(struct device *device)
+static int __devexit vortex_eisa_remove(struct device *device)
{
struct eisa_device *edev;
struct net_device *dev;
@@ -918,7 +906,17 @@ static int vortex_eisa_remove(struct device *device)
free_netdev(dev);
return 0;
}
-#endif
+
+static struct eisa_driver vortex_eisa_driver = {
+ .id_table = vortex_eisa_ids,
+ .driver = {
+ .name= "3c59x",
+ .probe = vortex_eisa_probe,
+ .remove = __devexit_p(vortex_eisa_remove)
+ }
+};
+
+#endif /* CONFIG_EISA */
/* returns count found (>= 0), or negative on error */
static int __init vortex_eisa_init(void)
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 9ba21e0..1ee27c3 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -787,6 +787,12 @@ static int mv643xx_eth_open(struct net_device *dev)
unsigned int size;
int err;
+ /* Clear any pending ethernet port interrupts */
+ mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0);
+ mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0);
+ /* wait for previous write to complete */
+ mv_read (MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num));
+
err = request_irq(dev->irq, mv643xx_eth_int_handler,
IRQF_SHARED | IRQF_SAMPLE_RANDOM, dev->name, dev);
if (err) {
@@ -875,10 +881,6 @@ static int mv643xx_eth_open(struct net_device *dev)
mv643xx_eth_rx_refill_descs(dev); /* Fill RX ring with skb's */
- /* Clear any pending ethernet port interrupts */
- mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0);
- mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0);
-
eth_port_start(dev);
/* Interrupt Coalescing */
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index b05dc6e..ac02b3b 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -181,6 +181,7
Re: [PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq
Kok, Auke wrote: Personally, I think this is really really needed. I'm surprised that you already didn't push this considering Andrew pulled this into -mm immediately. Since it affects a fragile area of e1000 for all [e1000] users, I much prefer to err on the side of caution. I have a history of pulling wide-impact fixes like this, late in -rc cycle, and having yet more breakage appear. But if Andrew or Linus disagree, feel free to override me. This is just area where I am intentionally over-cautious. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] NET: Multiple queue network device support
> -Original Message-
> From: Thomas Graf [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 09, 2007 5:41 AM
> To: Kok, Auke-jan H
> Cc: David Miller; Garzik, Jeff; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org; Waskiewicz Jr, Peter P;
> Brandeburg, Jesse; Kok, Auke; Ronciak, John
> Subject: Re: [PATCH 1/2] NET: Multiple queue network device support
>
> * Kok, Auke <[EMAIL PROTECTED]> 2007-02-08 16:09
> > diff --git a/net/core/dev.c b/net/core/dev.c index 455d589..42b635c
> > 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1477,6 +1477,49 @@ gso:
> > skb->tc_verd = SET_TC_AT(skb->tc_verd,AT_EGRESS);
> > #endif
> > if (q->enqueue) {
> > +#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
> > + int queue_index;
> > + /* If we're a multi-queue device, get a queue
> index to lock */
> > + if (netif_is_multiqueue(dev))
> > + {
> > + /* Get the queue index and lock it. */
> > + if (likely(q->ops->map_queue)) {
> > + queue_index = q->ops->map_queue(skb, q);
> > +
> spin_lock(&dev->egress_subqueue[queue_index].queue_lock);
> > + rc = q->enqueue(skb, q);
> > + /*
> > +* Unlock because the underlying qdisc
> > +* may queue and send a packet from a
> > +* different queue.
> > +*/
> > +
> spin_unlock(&dev->egress_subqueue[queue_index].queue_lock);
> > + qdisc_run(dev);
>
> I really dislike this asymmetric locking logic, while
> enqueue() is called with queue_lock held dequeue() is
> repsonsible to acquire the lock for qdisc_restart().
I don't see how I can make this symmetrical when dealing with more than
one queue. If an skb is classified to band 2 which maps to queue 1, we
lock queue 1, and enqueue the packet. That queue will not be the first
queue checked in dequeue for an skb, so I cannot rely on that lock
protecting queue 0 in dequeue. Therefore I need to map the skb, lock,
enqueue, unlock, then go into dequeue and lock the correct queue there.
If I were to make this symmetrical, then the process of enqueuing and
dequeuing would be serialized completely, and we'd be back to where we
started without multiqueue.
Also, in the multiqueue code path, dev->queue_lock isn't held anywhere,
it's the subqueue lock.
>
> > + rc = rc == NET_XMIT_BYPASS
> > + ? NET_XMIT_SUCCESS : rc;
> > + goto out;
> > + } else {
> > + printk(KERN_CRIT "Device %s is "
> > + "multiqueue, but map_queue is "
> > + "undefined in the qdisc!!\n",
> > + dev->name);
> > + kfree_skb(skb);
>
> Move this check to tc_modify_qdisc(), it's useless to check
> this for every packet being delivered.
The patches I sent yesterday modified the non-multiqueue qdiscs to not
load if the device is multiqueue, so this check can be removed
altogether.
>
> > + }
> > + } else {
> > + /* We're not a multi-queue device. */
> > + spin_lock(&dev->queue_lock);
> > + q = dev->qdisc;
> > + if (q->enqueue) {
> > + rc = q->enqueue(skb, q);
> > + qdisc_run(dev);
> > + spin_unlock(&dev->queue_lock);
> > + rc = rc == NET_XMIT_BYPASS
> > + ? NET_XMIT_SUCCESS : rc;
> > + goto out;
> > + }
> > + spin_unlock(&dev->queue_lock);
>
> Please don't duplicate already existing code.
I don't want to mix multiqueue and non-multiqueue code in the transmit
path. This was an attempt to allow MQ and non-MQ devices to coexist in
a machine having separate code paths. Are you suggesting to combine
them? That would get very messy trying to determine what type of lock
to grab (subqueue lock or dev->queue_lock), not to mention grabbing the
dev->queue_lock would block multiqueue devices in that same codepath.
>
> > @@ -130,6 +140,72 @@ static inline int qdisc_restart(struct
> net_device *dev)
> > }
> >
> > {
> > +#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
> > + if (netif_is_multiqueue(dev)) {
> > + if (likely(q->ops->map_queue)) {
> > + queue_index =
> q->ops->map_queue(skb, q);
> > + } else {
> > + printk(KERN_CRIT "Device %s is "
> > + "multiqueue,
netconsole system freeze when cable unplugged
When I unplug the cable the system just stops responding to anything, at all. No message is printed to the console when the cable is plugged back in. [0.00] Linux version 2.6.21-rc3 ([EMAIL PROTECTED]) (gcc version 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)) #3 SMP Fri Mar 9 18:42:22 GMT 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize bail 0 [0.00] BIOS-e801: - 0009f000 (usable) [0.00] BIOS-e801: 0010 - 0c00 (usable) [0.00] 192MB LOWMEM available. [0.00] found SMP MP-table at 000fea90 [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 ->49152 [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 ->49152 [0.00] DMI not present or invalid. [0.00] Intel MultiProcessor Specification v1.4 [0.00] Virtual Wire compatibility mode. [0.00] OEM ID: COMPAQ Product ID: Workstation APIC at: 0xFEE0 [0.00] Processor #1 6:1 APIC version 16 [0.00] Processor #0 6:1 APIC version 16 [0.00] I/O APIC #8 Version 17 at 0xFEC0. [0.00] Enabling APIC mode: Flat. Using 1 I/O APICs [0.00] Processors: 2 [0.00] Allocating PCI resources starting at 1000 (gap: 0c00:f400) [0.00] Built 1 zonelists. Total pages: 48768 [0.00] Kernel command line: [EMAIL PROTECTED]/eth0,[EMAIL PROTECTED]/ console=ttyS0,115200 ip=dhcp root=/dev/nfs init=/bin/bash panic=10 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 1024 (order: 10, 4096 bytes) [0.00] Detected 199.444 MHz processor. [ 485.111206] Console: colour dummy device 80x25 [ 486.218671] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 486.227388] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 486.234789] Pentium Pro with Errata#50 detected. Taking evasive action. [ 486.346878] Memory: 189764k/196608k available (1268k kernel code, 6452k reserved, 492k data, 184k init, 0k highmem) [ 486.357430] virtual kernel memory layout: [ 486.357444] fixmap : 0xfffbc000 - 0xf000 ( 268 kB) [ 486.357461] vmalloc : 0xcc80 - 0xfffba000 ( 823 MB) [ 486.357478] lowmem : 0xc000 - 0xcc00 ( 192 MB) [ 486.357494] .init : 0xc02bf000 - 0xc02ed000 ( 184 kB) [ 486.357510] .data : 0xc023d32b - 0xc02b85d0 ( 492 kB) [ 486.357527] .text : 0xc010 - 0xc023d32b (1268 kB) [ 486.396031] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 486.562667] Calibrating delay using timer specific routine.. 400.92 BogoMIPS (lpj=2004624) [ 486.575064] Mount-cache hash table entries: 512 [ 486.587330] CPU: L1 I cache: 8K, L1 D cache: 8K [ 486.591916] CPU: L2 cache: 256K [ 486.595475] Checking 'hlt' instruction... OK. [ 486.633415] Freeing SMP alternatives: 9k freed [ 486.638843] CPU0: Intel Pentium Pro stepping 07 [ 486.644597] lockdep: not fixing up alternatives. [ 486.649256] Booting processor 1/0 eip 2000 [ 486.664153] Initializing CPU#1 [ 486.812607] Calibrating delay using timer specific routine.. 398.91 BogoMIPS (lpj=1994559) [ 486.812755] CPU: L1 I cache: 8K, L1 D cache: 8K [ 486.812781] CPU: L2 cache: 256K [ 486.813992] CPU1: Intel Pentium Pro stepping 07 [ 486.837731] Total of 2 processors activated (799.83 BogoMIPS). [ 486.844201] ExtINT not setup in hardware but reported by MP table [ 486.851035] ENABLING IO-APIC IRQs [ 486.855772] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 [ 487.204372] checking TSC synchronization [CPU#0 -> CPU#1]: passed. [ 487.230906] Brought up 2 CPUs [ 487.888084] migration_cost=6769 [ 487.904092] NET: Registered protocol family 16 [ 487.927495] PCI: PCI BIOS revision 2.10 entry at 0xe07c4, last bus=1 [ 487.933936] PCI: Using configuration type 1 [ 487.938152] Setting up standard PCI resources [ 487.951810] PCI: Probing PCI hardware [ 487.959923] :00:14.1: trying to change BAR0 from to 01F0 [ 487.966107] :00:14.1: trying to change BAR1 from to 03F4 [ 487.972246] :00:14.1: trying to change BAR2 from to 0170 [ 487.978418] :00:14.1: trying to change BAR3 from to 0374 [ 487.993123] PCI->APIC IRQ transform: :00:08.0[A] -> IRQ 19 [ 487.999018] PCI->APIC IRQ transform: :00:0b.0[A] -> IRQ 16 [ 488.004987] PCI->APIC IRQ transform: :01:0b.0[A] -> IRQ 20 [ 488.010870] PCI->APIC IRQ transform: :01:0c.0[A] -> IRQ 21 [ 488.058792] PCI: Bridge: :00:06.0 [ 488.062512] IO window: 1000-1fff [ 488.065964] Time: tsc clocksource has been installed. [ 488.071119] MEM window: 5000-501f [ 488.075398] PREFETCH window: 1000-100f [ 488.081935] NET: Registered protocol family 2 [ 488.173953] IP route cache hash table entries: 2048 (order: 1, 8192 bytes) [ 488.184036]
Re: netconsole system freeze when cable unplugged
Simon Arlott <[EMAIL PROTECTED]> :
> When I unplug the cable the system just stops responding to anything,
> at all. No message is printed to the console when the cable is plugged
> back in.
rtl8139_interrupt (spin_lock(&tp->lock))
-> rtl8139_weird_interrupt
-> rtl_check_media
-> mii_check_media (printk(KERN_INFO "%s: link down\n", ...))
[netpoll stuff here]
-> rtl8139_poll_controller
-> rtl8139_interrupt
*deadlock*
See below for my random stuff of the day. Feel free to open a PR at
bugzilla.kernel.org if the issue does not go away.
8<-
8139too: netconsole breakage when link changes
rtl8139_interrupt is not supposed to be reentrant but its link
management part can emit printk.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 99304b2..64467ad 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -2215,9 +2215,16 @@ static irqreturn_t rtl8139_interrupt (int irq, void
*dev_instance)
*/
static void rtl8139_poll_controller(struct net_device *dev)
{
- disable_irq(dev->irq);
+ struct rtl8139_private *tp = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ rc = spin_trylock_irqsave(&tp->lock, flags);
+ if (!rc)
+ return;
+ spin_unlock(&tp->lock);
rtl8139_interrupt(dev->irq, dev);
- enable_irq(dev->irq);
+ local_irq_restore(flags);
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] NET: Multiple queue network device support
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 11:25
> > > + }
> > > + } else {
> > > + /* We're not a multi-queue device. */
> > > + spin_lock(&dev->queue_lock);
> > > + q = dev->qdisc;
> > > + if (q->enqueue) {
> > > + rc = q->enqueue(skb, q);
> > > + qdisc_run(dev);
> > > + spin_unlock(&dev->queue_lock);
> > > + rc = rc == NET_XMIT_BYPASS
> > > +? NET_XMIT_SUCCESS : rc;
> > > + goto out;
> > > + }
> > > + spin_unlock(&dev->queue_lock);
> >
> > Please don't duplicate already existing code.
>
> I don't want to mix multiqueue and non-multiqueue code in the transmit
> path. This was an attempt to allow MQ and non-MQ devices to coexist in
> a machine having separate code paths. Are you suggesting to combine
> them? That would get very messy trying to determine what type of lock
> to grab (subqueue lock or dev->queue_lock), not to mention grabbing the
> dev->queue_lock would block multiqueue devices in that same codepath.
The piece of code I quoted above is the branch executed if multi queue
is not enabled. The code you added is 100% identical to the already
existing enqueue logic. Just execute the existing branch if multi queue
is not enabled.
> This is another attempt to keep the two codepaths separate. The only
> way I see of combining them is to check netif_is_multiqueue() everytime
> I need to grab a lock, which I think would be excessive.
The code added is 100% identical to the existing code, just be a little
smarter on how you do the ifdefs.
> > > }
> > >
> > > return NULL;
> > > @@ -141,18 +174,53 @@ prio_dequeue(struct Qdisc* sch)
> > > struct sk_buff *skb;
> > > struct prio_sched_data *q = qdisc_priv(sch);
> > > int prio;
> > > +#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
> > > + int queue;
> > > +#endif
> > > struct Qdisc *qdisc;
> > >
> > > + /*
> > > + * If we're multiqueue, the basic approach is try the
> > lock on each
> > > + * queue. If it's locked, either we're already
> > dequeuing, or enqueue
> > > + * is doing something. Go to the next band if we're
> > locked. Once we
> > > + * have a packet, unlock the queue. NOTE: the
> > underlying qdisc CANNOT
> > > + * be a PRIO qdisc, otherwise we will deadlock. FIXME
> > > + */
> > > for (prio = 0; prio < q->bands; prio++) {
> > > +#ifdef CONFIG_NET_MULTI_QUEUE_DEVICE
> > > + if (netif_is_multiqueue(sch->dev)) {
> > > + queue = q->band2queue[prio];
> > > + if
> > (spin_trylock(&sch->dev->egress_subqueue[queue].queue_lock)) {
> > > + qdisc = q->queues[prio];
> > > + skb = qdisc->dequeue(qdisc);
> > > + if (skb) {
> > > + sch->q.qlen--;
> > > + skb->priority = prio;
> > > +
> > spin_unlock(&sch->dev->egress_subqueue[queue].queue_lock);
> > > + return skb;
> > > + }
> > > +
> > spin_unlock(&sch->dev->egress_subqueue[queue].queue_lock);
> > > + }
> >
> > Your modified qdisc_restart() expects the queue_lock to be
> > locked, how can this work?
>
> No, it doesn't expect the lock to be held. Because of the multiple
> queues, enqueueing and dequeueing are now asynchronous, since I can
> enqueue to queue 0 while dequeuing from queue 1. dev->queue_lock isn't
> held, so this can happen. Therefore the spin_trylock() is used in this
> dequeue because I don't want to wait for someone to finish with that
> queue in question (e.g. enqueue working), since that will block all
> other bands/queues after the band in question. So if the lock isn't
> available to grab, we move to the next band. If I were to wait for the
> lock, I'd serialize the enqueue/dequeue completely, and block other
> traffic flows in other queues waiting for the lock.
The first thing you do in qdisc_restart() after dequeue()ing is unlock
the sub queue lock. You explicitely unlock it before calling qdisc_run()
so I assume dequeue() is expected to keep it locked. Something doesn't
add up.
BTW, which lock serializes your write access to qdisc->q.qlen? It used
to be dev->queue_lock but that is apparently not true for multi queue.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] NET: Multiple queue network device support
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-03-09 11:25
> > > > + }
> > > > + } else {
> > > > + /* We're not a multi-queue device. */
> > > > + spin_lock(&dev->queue_lock);
> > > > + q = dev->qdisc;
> > > > + if (q->enqueue) {
> > > > + rc = q->enqueue(skb, q);
> > > > + qdisc_run(dev);
> > > > + spin_unlock(&dev->queue_lock);
> > > > + rc = rc == NET_XMIT_BYPASS
> > > > + ?
> NET_XMIT_SUCCESS : rc;
> > > > + goto out;
> > > > + }
> > > > + spin_unlock(&dev->queue_lock);
> > >
> > > Please don't duplicate already existing code.
> >
> > I don't want to mix multiqueue and non-multiqueue code in
> the transmit
> > path. This was an attempt to allow MQ and non-MQ devices
> to coexist
> > in a machine having separate code paths. Are you suggesting to
> > combine them? That would get very messy trying to
> determine what type
> > of lock to grab (subqueue lock or dev->queue_lock), not to mention
> > grabbing the
> > dev->queue_lock would block multiqueue devices in that same
> codepath.
>
> The piece of code I quoted above is the branch executed if
> multi queue is not enabled. The code you added is 100%
> identical to the already existing enqueue logic. Just execute
> the existing branch if multi queue is not enabled.
>
I totally agree this is identical code if multiqueue isn't enabled.
However, when multiqueue is enabled, I don't want to make all network
drivers implement the subqueue API just to be able to lock the queues.
So the first thing I check is netif_is_multiqueue(dev), and if it
*isn't* multiqueue, it will run the existing code. This way both
non-multiqueue devices don't have to have any knowledge of the MQ API.
> > This is another attempt to keep the two codepaths separate.
> The only
> > way I see of combining them is to check netif_is_multiqueue()
> > everytime I need to grab a lock, which I think would be excessive.
>
> The code added is 100% identical to the existing code, just
> be a little smarter on how you do the ifdefs.
An example could be an on-board adapter isn't multiqueue, and an
expansion card you have in your system is. If I handle multiqueue being
on with just ifdef's, then I could use the expansion card, but not the
on-board adapter as-is. The on-board driver would need to be updated to
have 1 queue in the multiqueue context, which is what I tried to avoid.
> > > Your modified qdisc_restart() expects the queue_lock to
> be locked,
> > > how can this work?
> >
> > No, it doesn't expect the lock to be held. Because of the multiple
> > queues, enqueueing and dequeueing are now asynchronous, since I can
> > enqueue to queue 0 while dequeuing from queue 1. dev->queue_lock
> > isn't held, so this can happen. Therefore the
> spin_trylock() is used
> > in this dequeue because I don't want to wait for someone to finish
> > with that queue in question (e.g. enqueue working), since that will
> > block all other bands/queues after the band in question. So if the
> > lock isn't available to grab, we move to the next band. If
> I were to
> > wait for the lock, I'd serialize the enqueue/dequeue
> completely, and
> > block other traffic flows in other queues waiting for the lock.
>
> The first thing you do in qdisc_restart() after dequeue()ing
> is unlock the sub queue lock. You explicitely unlock it
> before calling qdisc_run() so I assume dequeue() is expected
> to keep it locked. Something doesn't add up.
That's the entire point of this extra locking. enqueue() is going to
put an skb into a band somewhere that maps to some queue, and there is
no way to guarantee the skb I retrieve from dequeue() is headed for the
same queue. Therefore, I need to unlock the queue after I finish
enqueuing, since having that lock makes little sense to dequeue().
dequeue() will then grab *a* lock on a queue; it may be the same one we
had during enqueue(), but it may not be. And the placement of the
unlock of that queue is exactly where it happens in non-multiqueue,
which is right before the hard_start_xmit().
I concede that the locking model is complex and seems really nasty, but
to truly separate queue functionality from one another, I see no other
feasible option than to run locking like this. I am very open to
suggestions.
>
> BTW, which lock serializes your write access to
> qdisc->q.qlen? It used to be dev->queue_lock but that is
> apparently not true for multi queue.
>
This is a very good catch, because it isn't being protected on the
entire qdisc right now for PRIO. However, Chris Leech pointed out the
LINK_STATE_QDISC_RUNNING bit is serializing things at the qdisc_run()
level
Re: netconsole system freeze when cable unplugged
On 09/03/07 20:42, Francois Romieu wrote:
Simon Arlott <[EMAIL PROTECTED]> :
When I unplug the cable the system just stops responding to anything,
at all. No message is printed to the console when the cable is plugged
back in.
rtl8139_interrupt (spin_lock(&tp->lock))
-> rtl8139_weird_interrupt
-> rtl_check_media
-> mii_check_media (printk(KERN_INFO "%s: link down\n", ...))
[netpoll stuff here]
-> rtl8139_poll_controller
-> rtl8139_interrupt
*deadlock*
See below for my random stuff of the day. Feel free to open a PR at
bugzilla.kernel.org if the issue does not go away.
The patch doesn't fix it, nothing changes. I'm not sure how this can
be debugged if printk won't work...
8<-
8139too: netconsole breakage when link changes
rtl8139_interrupt is not supposed to be reentrant but its link
management part can emit printk.
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 99304b2..64467ad 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -2215,9 +2215,16 @@ static irqreturn_t rtl8139_interrupt (int irq, void
*dev_instance)
*/
static void rtl8139_poll_controller(struct net_device *dev)
{
- disable_irq(dev->irq);
+ struct rtl8139_private *tp = netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ rc = spin_trylock_irqsave(&tp->lock, flags);
+ if (!rc)
+ return;
+ spin_unlock(&tp->lock);
rtl8139_interrupt(dev->irq, dev);
- enable_irq(dev->irq);
+ local_irq_restore(flags);
}
#endif
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Simon Arlott
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] NET: Multiple queue network device support
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 15:27
> That's the entire point of this extra locking. enqueue() is going to
> put an skb into a band somewhere that maps to some queue, and there is
> no way to guarantee the skb I retrieve from dequeue() is headed for the
> same queue. Therefore, I need to unlock the queue after I finish
> enqueuing, since having that lock makes little sense to dequeue().
> dequeue() will then grab *a* lock on a queue; it may be the same one we
> had during enqueue(), but it may not be. And the placement of the
> unlock of that queue is exactly where it happens in non-multiqueue,
> which is right before the hard_start_xmit().
The lock is already unlocked after dequeue, from your prio_dequeue():
if (netif_is_multiqueue(sch->dev)) {
queue = q->band2queue[prio];
if (spin_trylock(&sch->dev->egress_subqueue[queue].queue_lock)) {
qdisc = q->queues[prio];
skb = qdisc->dequeue(qdisc);
if (skb) {
sch->q.qlen--;
skb->priority = prio;
spin_unlock(&sch->dev->egress_subqueue[queue].queue_lock);
return skb;
}
spin_unlock(&sch->dev->egress_subqueue[queue].queue_lock);
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
