* [Patch net-next]atl1c:remove compiling warning
From: jie.yang @ 2009-09-21 5:01 UTC (permalink / raw)
To: davem; +Cc: akpm, jirislaby, jcliburn, netdev, linux-kernel, Jie Yang
Set wol_ctrl_data to value 0, to remove compiling warning.
Signed-off-by: Jie Yang <jie.yang@atheros.com>
---
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index be2c6cf..1372e9a 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -2296,7 +2296,7 @@ static int atl1c_suspend(struct pci_dev *pdev, pm_message_t state)
u32 ctrl;
u32 mac_ctrl_data;
u32 master_ctrl_data;
- u32 wol_ctrl_data;
+ u32 wol_ctrl_data = 0;
u16 mii_bmsr_data;
u16 save_autoneg_advertised;
u16 mii_intr_status_data;
^ permalink raw reply related
* Re: [PANIC] pktgen panic on load
From: Stephen Hemminger @ 2009-09-21 4:35 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: netdev
In-Reply-To: <1253486747.17792.9.camel@jbrandeb-mobl2>
On Sun, 20 Sep 2009 15:45:47 -0700
Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> just got this today after cloning Linus' tree, please let me know if you
> want .config or full dmesg
config would help (hrt, nohz, preempt, ...), and was it just on module load?
or had you started it sending?
> [ 22.441999] modprobe used greatest stack depth: 3144 bytes left
> [ 503.775093] ------------[ cut here ]------------
> [ 503.780252] kernel BUG at net/core/pktgen.c:3503!
> [ 503.785505] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 503.791575] last sysfs file: /sys/devices/system/cpu/sched_smt_power_savings
> [ 503.799443] CPU 6
> [ 503.801698] Modules linked in: pktgen(+) ixgbe mdio [last unloaded: scsi_wait_scan]
> [ 503.810313] Pid: 6120, comm: kpktgend_13 Not tainted 2.6.31 #1 S5520HC
> [ 503.817600] RIP: 0010:[<ffffffffa0029cda>] [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
> [ 503.828402] RSP: 0018:ffff88036dca7d80 EFLAGS: 00010297
> [ 503.834332] RAX: 0000000000000006 RBX: ffff88036d6d0fe0 RCX: 0000000000000000
> [ 503.842299] RDX: 0000000000000006 RSI: ffff8800282d3740 RDI: ffff88036dca7e18
> [ 503.850264] RBP: ffff88036dca7ee0 R08: ffff88036dca6000 R09: ffff8801ed430700
> [ 503.858231] R10: 00000000afddf7db R11: ffff8801e0423e08 R12: ffff88036d9dd9e8
> [ 503.866195] R13: ffffffffa0029c64 R14: ffff88036d9dd9e8 R15: 0000000000000001
> [ 503.874161] FS: 0000000000000000(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
> [ 503.883196] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 503.889611] CR2: 00007f1bb5b3e00f CR3: 00000001d7c91000 CR4: 00000000000006e0
> [ 503.897578] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 503.905544] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 503.913513] Process kpktgend_13 (pid: 6120, threadinfo ffff88036dca6000, task ffff88036d6d0fe0)
> [ 503.923224] Stack:
> [ 503.925472] ffff88036dca7ea0 00000002afddf7db 000000000000028c 00000000d2c939bd
> [ 503.933573] <0> ffff88036dca7e00 ffffffff8100a7b4 ffff8801f5993740 00000000afddf7db
> [ 503.942191] <0> ffff8800282d3740 ffff8801ef1897d0 ffff88036dca7e10 ffffffff8104906c
> [ 503.951002] Call Trace:
> [ 503.953739] [<ffffffff8100a7b4>] ? __switch_to+0xfd/0x23b
> [ 503.959870] [<ffffffff8104906c>] ? finish_task_switch+0x4d/0x92
> [ 503.966582] [<ffffffff8106b57b>] ? autoremove_wake_function+0x0/0x5a
> [ 503.973778] [<ffffffff8147aaa5>] ? thread_return+0x71/0xd8
> [ 503.980003] [<ffffffffa0029c64>] ? pktgen_thread_worker+0x0/0x1497 [pktgen]
> [ 503.987874] [<ffffffff8106b12e>] kthread+0x89/0x91
> [ 503.993321] [<ffffffff8100ce5a>] child_rip+0xa/0x20
> [ 503.998865] [<ffffffff8106b0a5>] ? kthread+0x0/0x91
> [ 504.004409] [<ffffffff8100ce50>] ? child_rip+0x0/0x20
> [ 504.010146] Code: 48 89 85 28 ff ff ff 48 89 85 30 ff ff ff 48 c7 85 20 ff ff ff 7b b5 06 81 65 8b 04 25 30 cc 00 00 41 3b 84 24 34 02 00 00 74 04 <0f> 0b eb fe 49 8d 94 24 38 02 00 00 48 c7 c6 a8 ec 02 a0 48 89
> [ 504.032139] RIP [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
> [ 504.040316] RSP <ffff88036dca7d80>
> [ 504.044227] ---[ end trace ddca71c9720a201f ]---
>
--
^ permalink raw reply
* [PATCH kernel 2.6.31-git9] 3c574_cs: spin_lock the set_multicast_list function
From: Ken Kawasaki @ 2009-09-21 4:10 UTC (permalink / raw)
To: netdev
In-Reply-To: <20090913072203.d92f1734.ken_kawasaki@spring.nifty.jp>
3c574_cs:
spin_lock the set_multicast_list,
and clean up the set_rx_mode function.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
---
--- linux-2.6.31-git9.orig/drivers/net/pcmcia/3c574_cs.c 2009-09-20 06:53:31.000000000 +0900
+++ linux-2.6.31-git9/drivers/net/pcmcia/3c574_cs.c 2009-09-20 07:03:39.000000000 +0900
@@ -251,6 +251,7 @@ static void el3_tx_timeout(struct net_de
static int el3_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
static const struct ethtool_ops netdev_ethtool_ops;
static void set_rx_mode(struct net_device *dev);
+static void set_multicast_list(struct net_device *dev);
static void tc574_detach(struct pcmcia_device *p_dev);
@@ -266,7 +267,7 @@ static const struct net_device_ops el3_n
.ndo_tx_timeout = el3_tx_timeout,
.ndo_get_stats = el3_get_stats,
.ndo_do_ioctl = el3_ioctl,
- .ndo_set_multicast_list = set_rx_mode,
+ .ndo_set_multicast_list = set_multicast_list,
.ndo_change_mtu = eth_change_mtu,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
@@ -1153,12 +1154,23 @@ static void set_rx_mode(struct net_devic
unsigned int ioaddr = dev->base_addr;
if (dev->flags & IFF_PROMISC)
- outw(SetRxFilter | RxStation | RxMulticast | RxBroadcast | RxProm,
- ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast|RxProm,
+ ioaddr + EL3_CMD);
else if (dev->mc_count || (dev->flags & IFF_ALLMULTI))
- outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast, ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxMulticast|RxBroadcast,
+ ioaddr + EL3_CMD);
else
- outw(SetRxFilter | RxStation | RxBroadcast, ioaddr + EL3_CMD);
+ outw(SetRxFilter|RxStation|RxBroadcast, ioaddr + EL3_CMD);
+}
+
+static void set_multicast_list(struct net_device *dev)
+{
+ struct el3_private *lp = netdev_priv(dev);
+ unsigned long flags;
+
+ spin_lock_irqsave(&lp->window_lock, flags);
+ set_rx_mode(dev);
+ spin_unlock_irqrestore(&lp->window_lock, flags);
}
static int el3_close(struct net_device *dev)
^ permalink raw reply
* Re: sky2 rx length errors
From: Stephen Hemminger @ 2009-09-21 1:46 UTC (permalink / raw)
To: Mike McCormack
Cc: Andrew Morton, Grozdan, linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <392fb48f0909201511h34c71e0au838b52c413d517e0@mail.gmail.com>
On Mon, 21 Sep 2009 07:11:21 +0900
Mike McCormack <mikem@ring3k.org> wrote:
> 2009/9/21 Stephen Hemminger <shemminger@vyatta.com>
>
> > On Sat, 19 Sep 2009 23:35:36 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > > (added cc's from the MAINTAINERS file)
> > >
> > > On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
> >
>
> <snip>
>
> > > martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> > > > sky2 eth0: rx length error: status 0x4420100 length 598
> > > > sky2 eth0: rx length error: status 0x5ea0100 length 598
> >
> > This error status occurs if the length reported by the PHY does not
> > match the len reported by the DMA engine. The error status is:
> > 0x4420100 = length 1090 + broadcast packet...
> >
> > No idea what is on your network, but perhaps there is some MTU confusion?
> > Since martian destination seems related, knowing more about that packet
> > might help.
> >
> >
> This appears to be the same problem reported at:
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292445
>
> Mike
This really looks like multiple packets are getting smashed
together into one DMA, i.e a hardware timing related issue.
it might be possible to work around the problem
by separating them.
--
^ permalink raw reply
* r8169 64-bit DMA support
From: Robert Hancock @ 2009-09-20 23:38 UTC (permalink / raw)
To: netdev; +Cc: Francois Romieu
The r8169 driver currently disables 64-bit DMA support by default (needs
a module parameter to turn it on). This is a bit sub-optimal these days
with most new systems using more than 4GB of RAM. It was this patch back
in 2004 that disabled it:
http://git.kernel.org/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=c525e7cf69bfe18a1bf362558be5398e0b925d07
It's not clear (from the mails I've read) exactly what was going on in
the case that caused this to be added. Normally these days the PCI
subsystem is supposed to detect that DAC isn't usable on a machine and
refuse setting 64-bit DMA masks, it's not the driver's responsibility to
handle this. I'm guessing that when this change was made that detection
didn't exist though.
Thoughts on whether this default can be changed now? Or at least for the
PCI Express devices, which really should have nothing special about
64-bit addressing..
^ permalink raw reply
* [PANIC] pktgen panic on load
From: Jesse Brandeburg @ 2009-09-20 22:45 UTC (permalink / raw)
To: netdev
just got this today after cloning Linus' tree, please let me know if you
want .config or full dmesg
[ 22.441999] modprobe used greatest stack depth: 3144 bytes left
[ 503.775093] ------------[ cut here ]------------
[ 503.780252] kernel BUG at net/core/pktgen.c:3503!
[ 503.785505] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 503.791575] last sysfs file: /sys/devices/system/cpu/sched_smt_power_savings
[ 503.799443] CPU 6
[ 503.801698] Modules linked in: pktgen(+) ixgbe mdio [last unloaded: scsi_wait_scan]
[ 503.810313] Pid: 6120, comm: kpktgend_13 Not tainted 2.6.31 #1 S5520HC
[ 503.817600] RIP: 0010:[<ffffffffa0029cda>] [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
[ 503.828402] RSP: 0018:ffff88036dca7d80 EFLAGS: 00010297
[ 503.834332] RAX: 0000000000000006 RBX: ffff88036d6d0fe0 RCX: 0000000000000000
[ 503.842299] RDX: 0000000000000006 RSI: ffff8800282d3740 RDI: ffff88036dca7e18
[ 503.850264] RBP: ffff88036dca7ee0 R08: ffff88036dca6000 R09: ffff8801ed430700
[ 503.858231] R10: 00000000afddf7db R11: ffff8801e0423e08 R12: ffff88036d9dd9e8
[ 503.866195] R13: ffffffffa0029c64 R14: ffff88036d9dd9e8 R15: 0000000000000001
[ 503.874161] FS: 0000000000000000(0000) GS:ffff8800282c0000(0000) knlGS:0000000000000000
[ 503.883196] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 503.889611] CR2: 00007f1bb5b3e00f CR3: 00000001d7c91000 CR4: 00000000000006e0
[ 503.897578] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 503.905544] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 503.913513] Process kpktgend_13 (pid: 6120, threadinfo ffff88036dca6000, task ffff88036d6d0fe0)
[ 503.923224] Stack:
[ 503.925472] ffff88036dca7ea0 00000002afddf7db 000000000000028c 00000000d2c939bd
[ 503.933573] <0> ffff88036dca7e00 ffffffff8100a7b4 ffff8801f5993740 00000000afddf7db
[ 503.942191] <0> ffff8800282d3740 ffff8801ef1897d0 ffff88036dca7e10 ffffffff8104906c
[ 503.951002] Call Trace:
[ 503.953739] [<ffffffff8100a7b4>] ? __switch_to+0xfd/0x23b
[ 503.959870] [<ffffffff8104906c>] ? finish_task_switch+0x4d/0x92
[ 503.966582] [<ffffffff8106b57b>] ? autoremove_wake_function+0x0/0x5a
[ 503.973778] [<ffffffff8147aaa5>] ? thread_return+0x71/0xd8
[ 503.980003] [<ffffffffa0029c64>] ? pktgen_thread_worker+0x0/0x1497 [pktgen]
[ 503.987874] [<ffffffff8106b12e>] kthread+0x89/0x91
[ 503.993321] [<ffffffff8100ce5a>] child_rip+0xa/0x20
[ 503.998865] [<ffffffff8106b0a5>] ? kthread+0x0/0x91
[ 504.004409] [<ffffffff8100ce50>] ? child_rip+0x0/0x20
[ 504.010146] Code: 48 89 85 28 ff ff ff 48 89 85 30 ff ff ff 48 c7 85 20 ff ff ff 7b b5 06 81 65 8b 04 25 30 cc 00 00 41 3b 84 24 34 02 00 00 74 04 <0f> 0b eb fe 49 8d 94 24 38 02 00 00 48 c7 c6 a8 ec 02 a0 48 89
[ 504.032139] RIP [<ffffffffa0029cda>] pktgen_thread_worker+0x76/0x1497 [pktgen]
[ 504.040316] RSP <ffff88036dca7d80>
[ 504.044227] ---[ end trace ddca71c9720a201f ]---
--
Jesse Brandeburg
This email sent from Evolution, powered by Linux
^ permalink raw reply
* [RFC] skb align patch
From: Stephen Hemminger @ 2009-09-20 21:22 UTC (permalink / raw)
To: Jesse Brandeburg, Jesper Dangaard Brouer; +Cc: netdev
Based on the Intel suggestion that PCI-express overhead is
a significant cost.
Would people doing performance please measure the impact of
changing SKB alignment (64 bit only).
--- a/arch/x86/include/asm/system.h 2009-09-20 14:08:40.922346912 -0700
+++ b/arch/x86/include/asm/system.h 2009-09-20 14:14:37.012371200 -0700
@@ -455,4 +455,14 @@ static inline void rdtsc_barrier(void)
alternative(ASM_NOP3, "lfence", X86_FEATURE_LFENCE_RDTSC);
}
+#ifndef CONFIG_X86_32
+/*
+ * DMA to unaligned address is more expensive than the the
+ * overhead of unaligned CPU access.
+ */
+#define NET_IP_ALIGN 0
+#define NET_SKB_PAD L1_CACHE_BYTES
+#endif
+
+
#endif /* _ASM_X86_SYSTEM_H */
^ permalink raw reply
* [GIT *] Solos PCI ADSL driver update
From: David Woodhouse @ 2009-09-20 21:17 UTC (permalink / raw)
To: davem; +Cc: netdev
I'm sorry, I suck. I forgot I had anything outstanding to be pushed
upstream, and should have done this a while ago.
In later versions of the card's FPGA code, the RAM layout for
card<->host communication has changed -- and the new FPGA code is in the
devices which are being shipped now, so it would be really useful if we
could sneak this into 2.6.32. Sorry it's so late.
Please pull from git://git.infradead.org/users/dwmw2/solos-2.6.git
David Woodhouse (1):
solos: Add some margin-related parameters
Nathan Williams (2):
solos: support new FPGA RAM layout
solos: Check for rogue received packets
Simon Farnsworth (1):
solos: Show Interleaving details for ADSL2 and 2+
drivers/atm/solos-attrlist.c | 11 ++++++
drivers/atm/solos-pci.c | 75 +++++++++++++++++++++++++++++++++++++-----
2 files changed, 77 insertions(+), 9 deletions(-)
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [AX25] kernel panic
From: Jarek Poplawski @ 2009-09-20 21:02 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
In-Reply-To: <4AB5EAE5.6070605@upmc.fr>
On Sun, Sep 20, 2009 at 10:42:13AM +0200, Bernard Pidoux wrote:
> Hi,
>
> Here are the first events noticed since I turned on
> CONFIG_DEBUG_OBJECTS_TIMERS option.
>
> First a kernel BUG, second a kernel panic.
...
> ------------[ cut here ]------------
> kernel BUG at kernel/timer.c:913!
Alas this BUG doesn't show much (this new debugging didn't trigger
here). Maybe the patch below will be luckier.
Best regards,
Jarek P.
---
include/net/ax25.h | 36 ++++++++++++++++++++++++++++++++++++
net/ax25/af_ax25.c | 3 +++
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/include/net/ax25.h b/include/net/ax25.h
index 717e219..e8f6e33 100644
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -252,9 +252,45 @@ typedef struct ax25_cb {
#define ax25_cb_hold(__ax25) \
atomic_inc(&((__ax25)->refcount))
+static __inline__ int ax25_timers_warn(ax25_cb *ax25)
+{
+ int err = 0;
+
+ if (del_timer(&ax25->timer)) {
+ WARN_ON_ONCE(1);
+ err = 1;
+ }
+ if (del_timer(&ax25->t1timer)) {
+ WARN_ON_ONCE(1);
+ err += 2;
+ }
+ if (del_timer(&ax25->t2timer)) {
+ WARN_ON_ONCE(1);
+ err += 4;
+ }
+ if (del_timer(&ax25->t3timer)) {
+ WARN_ON_ONCE(1);
+ err += 8;
+ }
+ if (del_timer(&ax25->idletimer)) {
+ WARN_ON_ONCE(1);
+ err += 16;
+ }
+ if (del_timer(&ax25->dtimer)) {
+ WARN_ON_ONCE(1);
+ err += 32;
+ }
+ if (err)
+ printk(KERN_WARNING "AX25_DBG: %d %p %u\n", err, ax25,
+ ax25->state);
+
+ return err;
+}
+
static __inline__ void ax25_cb_put(ax25_cb *ax25)
{
if (atomic_dec_and_test(&ax25->refcount)) {
+ ax25_timers_warn(ax25);
kfree(ax25->digipeat);
kfree(ax25);
}
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..f443fe0 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -58,6 +58,9 @@ static const struct proto_ops ax25_proto_ops;
static void ax25_free_sock(struct sock *sk)
{
+ if (ax25_timers_warn(ax25_sk(sk)))
+ printk(KERN_WARNING "AX25_DBG: %p %u %u %u\n", sk,
+ sk->sk_family, sk->sk_type, sk->sk_protocol);
ax25_cb_put(ax25_sk(sk));
}
^ permalink raw reply related
* [PATCH] ipv4: fib table algorithm performance improvement
From: Stephen Hemminger @ 2009-09-20 20:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev
The FIB algorithim for IPV4 is set at compile time, but kernel goes through
the overhead of function call indirection at runtime. Save some
cycles by turning the indirect calls to direct calls to either
hash or trie code.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/include/net/ip_fib.h 2009-09-20 12:16:02.819467348 -0700
+++ b/include/net/ip_fib.h 2009-09-20 12:37:53.391940040 -0700
@@ -144,18 +144,21 @@ struct fib_table {
struct hlist_node tb_hlist;
u32 tb_id;
int tb_default;
- int (*tb_lookup)(struct fib_table *tb, const struct flowi *flp, struct fib_result *res);
- int (*tb_insert)(struct fib_table *, struct fib_config *);
- int (*tb_delete)(struct fib_table *, struct fib_config *);
- int (*tb_dump)(struct fib_table *table, struct sk_buff *skb,
- struct netlink_callback *cb);
- int (*tb_flush)(struct fib_table *table);
- void (*tb_select_default)(struct fib_table *table,
- const struct flowi *flp, struct fib_result *res);
-
unsigned char tb_data[0];
};
+extern int fib_table_lookup(struct fib_table *tb, const struct flowi *flp,
+ struct fib_result *res);
+extern int fib_table_insert(struct fib_table *, struct fib_config *);
+extern int fib_table_delete(struct fib_table *, struct fib_config *);
+extern int fib_table_dump(struct fib_table *table, struct sk_buff *skb,
+ struct netlink_callback *cb);
+extern int fib_table_flush(struct fib_table *table);
+extern void fib_table_select_default(struct fib_table *table,
+ const struct flowi *flp,
+ struct fib_result *res);
+
+
#ifndef CONFIG_IP_MULTIPLE_TABLES
#define TABLE_LOCAL_INDEX 0
@@ -182,11 +185,11 @@ static inline int fib_lookup(struct net
struct fib_table *table;
table = fib_get_table(net, RT_TABLE_LOCAL);
- if (!table->tb_lookup(table, flp, res))
+ if (!fib_table_lookup(table, flp, res))
return 0;
table = fib_get_table(net, RT_TABLE_MAIN);
- if (!table->tb_lookup(table, flp, res))
+ if (!fib_table_lookup(table, flp, res))
return 0;
return -ENETUNREACH;
}
--- a/net/ipv4/fib_frontend.c 2009-09-20 12:23:52.199466411 -0700
+++ b/net/ipv4/fib_frontend.c 2009-09-20 12:26:45.969439904 -0700
@@ -125,7 +125,7 @@ void fib_select_default(struct net *net,
#endif
tb = fib_get_table(net, table);
if (FIB_RES_GW(*res) && FIB_RES_NH(*res).nh_scope == RT_SCOPE_LINK)
- tb->tb_select_default(tb, flp, res);
+ fib_table_select_default(tb, flp, res);
}
static void fib_flush(struct net *net)
@@ -139,7 +139,7 @@ static void fib_flush(struct net *net)
for (h = 0; h < FIB_TABLE_HASHSZ; h++) {
head = &net->ipv4.fib_table_hash[h];
hlist_for_each_entry(tb, node, head, tb_hlist)
- flushed += tb->tb_flush(tb);
+ flushed += fib_table_flush(tb);
}
if (flushed)
@@ -162,7 +162,7 @@ struct net_device * ip_dev_find(struct n
#endif
local_table = fib_get_table(net, RT_TABLE_LOCAL);
- if (!local_table || local_table->tb_lookup(local_table, &fl, &res))
+ if (!local_table || fib_table_lookup(local_table, &fl, &res))
return NULL;
if (res.type != RTN_LOCAL)
goto out;
@@ -200,7 +200,7 @@ static inline unsigned __inet_dev_addr_t
local_table = fib_get_table(net, RT_TABLE_LOCAL);
if (local_table) {
ret = RTN_UNICAST;
- if (!local_table->tb_lookup(local_table, &fl, &res)) {
+ if (!fib_table_lookup(local_table, &fl, &res)) {
if (!dev || dev == res.fi->fib_dev)
ret = res.type;
fib_res_put(&res);
@@ -473,13 +473,13 @@ int ip_rt_ioctl(struct net *net, unsigne
if (cmd == SIOCDELRT) {
tb = fib_get_table(net, cfg.fc_table);
if (tb)
- err = tb->tb_delete(tb, &cfg);
+ err = fib_table_delete(tb, &cfg);
else
err = -ESRCH;
} else {
tb = fib_new_table(net, cfg.fc_table);
if (tb)
- err = tb->tb_insert(tb, &cfg);
+ err = fib_table_insert(tb, &cfg);
else
err = -ENOBUFS;
}
@@ -594,7 +594,7 @@ static int inet_rtm_delroute(struct sk_b
goto errout;
}
- err = tb->tb_delete(tb, &cfg);
+ err = fib_table_delete(tb, &cfg);
errout:
return err;
}
@@ -616,7 +616,7 @@ static int inet_rtm_newroute(struct sk_b
goto errout;
}
- err = tb->tb_insert(tb, &cfg);
+ err = fib_table_insert(tb, &cfg);
errout:
return err;
}
@@ -647,7 +647,7 @@ static int inet_dump_fib(struct sk_buff
if (dumped)
memset(&cb->args[2], 0, sizeof(cb->args) -
2 * sizeof(cb->args[0]));
- if (tb->tb_dump(tb, skb, cb) < 0)
+ if (fib_table_dump(tb, skb, cb) < 0)
goto out;
dumped = 1;
next:
@@ -701,9 +701,9 @@ static void fib_magic(int cmd, int type,
cfg.fc_scope = RT_SCOPE_HOST;
if (cmd == RTM_NEWROUTE)
- tb->tb_insert(tb, &cfg);
+ fib_table_insert(tb, &cfg);
else
- tb->tb_delete(tb, &cfg);
+ fib_table_delete(tb, &cfg);
}
void fib_add_ifaddr(struct in_ifaddr *ifa)
@@ -832,7 +832,7 @@ static void nl_fib_lookup(struct fib_res
local_bh_disable();
frn->tb_id = tb->tb_id;
- frn->err = tb->tb_lookup(tb, &fl, &res);
+ frn->err = fib_table_lookup(tb, &fl, &res);
if (!frn->err) {
frn->prefixlen = res.prefixlen;
@@ -1009,7 +1009,7 @@ static void __net_exit ip_fib_net_exit(s
head = &net->ipv4.fib_table_hash[i];
hlist_for_each_entry_safe(tb, node, tmp, head, tb_hlist) {
hlist_del(node);
- tb->tb_flush(tb);
+ fib_table_flush(tb);
kfree(tb);
}
}
--- a/net/ipv4/fib_rules.c 2009-09-20 12:30:43.159471244 -0700
+++ b/net/ipv4/fib_rules.c 2009-09-20 12:32:08.709470541 -0700
@@ -94,7 +94,7 @@ static int fib4_rule_action(struct fib_r
if ((tbl = fib_get_table(rule->fr_net, rule->table)) == NULL)
goto errout;
- err = tbl->tb_lookup(tbl, flp, (struct fib_result *) arg->result);
+ err = fib_table_lookup(tbl, flp, (struct fib_result *) arg->result);
if (err > 0)
err = -EAGAIN;
errout:
--- a/net/ipv4/fib_trie.c 2009-09-20 12:23:59.409447223 -0700
+++ b/net/ipv4/fib_trie.c 2009-09-20 12:29:45.041693219 -0700
@@ -1174,7 +1174,7 @@ done:
/*
* Caller must hold RTNL.
*/
-static int fn_trie_insert(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
{
struct trie *t = (struct trie *) tb->tb_data;
struct fib_alias *fa, *new_fa;
@@ -1373,8 +1373,8 @@ static int check_leaf(struct trie *t, st
return 1;
}
-static int fn_trie_lookup(struct fib_table *tb, const struct flowi *flp,
- struct fib_result *res)
+int fib_table_lookup(struct fib_table *tb, const struct flowi *flp,
+ struct fib_result *res)
{
struct trie *t = (struct trie *) tb->tb_data;
int ret;
@@ -1595,7 +1595,7 @@ static void trie_leaf_remove(struct trie
/*
* Caller must hold RTNL.
*/
-static int fn_trie_delete(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
{
struct trie *t = (struct trie *) tb->tb_data;
u32 key, mask;
@@ -1786,7 +1786,7 @@ static struct leaf *trie_leafindex(struc
/*
* Caller must hold RTNL.
*/
-static int fn_trie_flush(struct fib_table *tb)
+int fib_table_flush(struct fib_table *tb)
{
struct trie *t = (struct trie *) tb->tb_data;
struct leaf *l, *ll = NULL;
@@ -1807,9 +1807,9 @@ static int fn_trie_flush(struct fib_tabl
return found;
}
-static void fn_trie_select_default(struct fib_table *tb,
- const struct flowi *flp,
- struct fib_result *res)
+void fib_table_select_default(struct fib_table *tb,
+ const struct flowi *flp,
+ struct fib_result *res)
{
struct trie *t = (struct trie *) tb->tb_data;
int order, last_idx;
@@ -1952,8 +1952,8 @@ static int fn_trie_dump_leaf(struct leaf
return skb->len;
}
-static int fn_trie_dump(struct fib_table *tb, struct sk_buff *skb,
- struct netlink_callback *cb)
+int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
struct leaf *l;
struct trie *t = (struct trie *) tb->tb_data;
@@ -2020,12 +2020,6 @@ struct fib_table *fib_hash_table(u32 id)
tb->tb_id = id;
tb->tb_default = -1;
- tb->tb_lookup = fn_trie_lookup;
- tb->tb_insert = fn_trie_insert;
- tb->tb_delete = fn_trie_delete;
- tb->tb_flush = fn_trie_flush;
- tb->tb_select_default = fn_trie_select_default;
- tb->tb_dump = fn_trie_dump;
t = (struct trie *) tb->tb_data;
memset(t, 0, sizeof(*t));
--- a/net/ipv4/fib_hash.c 2009-09-20 12:23:55.799439103 -0700
+++ b/net/ipv4/fib_hash.c 2009-09-20 12:46:25.700353394 -0700
@@ -242,8 +242,8 @@ fn_new_zone(struct fn_hash *table, int z
return fz;
}
-static int
-fn_hash_lookup(struct fib_table *tb, const struct flowi *flp, struct fib_result *res)
+int fib_table_lookup(struct fib_table *tb,
+ const struct flowi *flp, struct fib_result *res)
{
int err;
struct fn_zone *fz;
@@ -274,8 +274,8 @@ out:
return err;
}
-static void
-fn_hash_select_default(struct fib_table *tb, const struct flowi *flp, struct fib_result *res)
+void fib_table_select_default(struct fib_table *tb,
+ const struct flowi *flp, struct fib_result *res)
{
int order, last_idx;
struct hlist_node *node;
@@ -366,7 +366,7 @@ static struct fib_node *fib_find_node(st
return NULL;
}
-static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_insert(struct fib_table *tb, struct fib_config *cfg)
{
struct fn_hash *table = (struct fn_hash *) tb->tb_data;
struct fib_node *new_f = NULL;
@@ -544,8 +544,7 @@ out:
return err;
}
-
-static int fn_hash_delete(struct fib_table *tb, struct fib_config *cfg)
+int fib_table_delete(struct fib_table *tb, struct fib_config *cfg)
{
struct fn_hash *table = (struct fn_hash *)tb->tb_data;
struct fib_node *f;
@@ -662,7 +661,7 @@ static int fn_flush_list(struct fn_zone
return found;
}
-static int fn_hash_flush(struct fib_table *tb)
+int fib_table_flush(struct fib_table *tb)
{
struct fn_hash *table = (struct fn_hash *) tb->tb_data;
struct fn_zone *fz;
@@ -743,7 +742,8 @@ fn_hash_dump_zone(struct sk_buff *skb, s
return skb->len;
}
-static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlink_callback *cb)
+int fib_table_dump(struct fib_table *tb, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
int m, s_m;
struct fn_zone *fz;
@@ -787,12 +787,7 @@ struct fib_table *fib_hash_table(u32 id)
tb->tb_id = id;
tb->tb_default = -1;
- tb->tb_lookup = fn_hash_lookup;
- tb->tb_insert = fn_hash_insert;
- tb->tb_delete = fn_hash_delete;
- tb->tb_flush = fn_hash_flush;
- tb->tb_select_default = fn_hash_select_default;
- tb->tb_dump = fn_hash_dump;
+
memset(tb->tb_data, 0, sizeof(struct fn_hash));
return tb;
}
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: Christopher Zimmermann @ 2009-09-20 18:50 UTC (permalink / raw)
To: netdev
In-Reply-To: <1253468893.2654.6.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
On Sun, 20 Sep 2009 10:48:13 -0700
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> On Sun, 2009-09-20 at 00:52 -0700, Christopher Zimmermann wrote:
> > On Sat, 19 Sep 2009 15:09:21 -0700
> > Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> >
> > > > hardware timestamps only work for the Intel igb driver. I have
> > > > access to two test machines with NICs supported by this driver.
> > >
> > > Intel's 82599, supported by ixgbe, also has the same IEEE 1588
> > > timestamping support in hardware. We haven't implemented the support
> > > yet in ixgbe, but the hardware is there and does work. If you were
> > > curious of the interface, the datasheet for the hardware is available on
> > > our SourceForge site (e1000.sf.net).
> >
> > hi! thanks for the reply.
> >
> > I already got the documentation for the 82576 cards I have access to. I
> > won't be able to afford another pair.
> >
> > What do you think about my idea to expose the relevant registers to
> > userspace? I believe it would not be too difficult for userspace to
> > configure the timestamps this way and would allow way more flexibility.
> > Of course I would #DEFINE the constants used to set the registers.
>
> The patch seems reasonable, but I haven't played with the igb
> timestamping very much. However, what impact will this have on the
> existing ptpd userspace daemon?
It will need to be modified. If you want to avoid this, one could keep
the HWTSTAMP_FILTER_PTP_.... defines and just redifine them to reflect
the new interface.
Where can I find this ptpd userspace daemon, which supports hardware
timestamps using the ioctl interface? ptpd.sourceforge.net doesn't.
Cheers,
Christopher Zimmermann
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH net-next-2.6] bonding: remove useless assignment
From: Nicolas de Pesloüan @ 2009-09-20 18:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Jay Vosburgh, bonding-devel
The variable old_active is first set to bond->curr_active_slave.
Then, it is unconditionally set to new_active, without being used in between.
The first assignment, having no side effect, is useless.
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a7e731f..fce7233 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1084,7 +1084,7 @@ static struct slave *bond_find_best_slave(struct bonding *bond)
int mintime = bond->params.updelay;
int i;
- new_active = old_active = bond->curr_active_slave;
+ new_active = bond->curr_active_slave;
if (!new_active) { /* there were no active slaves left */
if (bond->slave_cnt > 0) /* found one slave */
^ permalink raw reply related
* Re: sky2 rx length errors
From: Stephen Hemminger @ 2009-09-20 18:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: Grozdan, linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <20090919233536.f5fb700c.akpm@linux-foundation.org>
On Sat, 19 Sep 2009 23:35:36 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> (added cc's from the MAINTAINERS file)
>
> On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
>
> > Hi,
> >
> > I have a Marvell onboard NIC (88E8053) and I've been noticing for a
> > while now a bit weird behavior with the sky2 driver. This mostly
> > occurs with newer kernels (2.6.30, 2.6.31) and my older distro kernel
> > (2.6.27.21) does not seem to have the same problem. Basically, the
> > sky2 driver will randomly and unpredictably spew rx length error
> > messages and reboot itself. I also noticed in dmesg that this mostly
> > occurs after "martian destination" messages. After this message, sky2
> > starts spewing messages as shown below and then reboots itself. It is
> > not really a big problem for me, but since I'm virtually always logged
> > in in IRC, the client always loses connection, waits for a few minutes
> > to get a response from the server and then relogs me again. I do not
> > think it's a HW problem as the Marvell NIC otherwise works perfectly
> > and I've checked my cable modem too which operates without a problem.
> > Any ideas?
> >
> > PS: please cc me as I'm not subscribed to the mailing list
> >
> > sky2 driver version 1.23
> > sky2 0000:05:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
> > sky2 0000:05:00.0: setting latency timer to 64
> > sky2 0000:05:00.0: PCI: Disallowing DAC for device
> > sky2 0000:05:00.0: Yukon-2 EC chip revision 2
> > sky2 0000:05:00.0: irq 53 for MSI/MSI-X
> > sky2 0000:05:00.0: No interrupt generated using MSI, switching to INTx mode.
> > sky2 eth0: addr 00:11:d8:a1:5b:0e
> > sky2 eth0: enabling interface
> > sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx
> > .....
> > .....
> > martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> > sky2 eth0: rx length error: status 0x4420100 length 598
> > sky2 eth0: rx length error: status 0x5ea0100 length 598
This error status occurs if the length reported by the PHY does not
match the len reported by the DMA engine. The error status is:
0x4420100 = length 1090 + broadcast packet...
No idea what is on your network, but perhaps there is some MTU confusion?
Since martian destination seems related, knowing more about that packet
might help.
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: Peter P Waskiewicz Jr @ 2009-09-20 17:48 UTC (permalink / raw)
To: Christopher Zimmermann; +Cc: netdev@vger.kernel.org
In-Reply-To: <20090920095242.5cd42f1a@pundit>
On Sun, 2009-09-20 at 00:52 -0700, Christopher Zimmermann wrote:
> On Sat, 19 Sep 2009 15:09:21 -0700
> Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
>
> > > hardware timestamps only work for the Intel igb driver. I have
> > > access to two test machines with NICs supported by this driver.
> >
> > Intel's 82599, supported by ixgbe, also has the same IEEE 1588
> > timestamping support in hardware. We haven't implemented the support
> > yet in ixgbe, but the hardware is there and does work. If you were
> > curious of the interface, the datasheet for the hardware is available on
> > our SourceForge site (e1000.sf.net).
>
> hi! thanks for the reply.
>
> I already got the documentation for the 82576 cards I have access to. I
> won't be able to afford another pair.
>
> What do you think about my idea to expose the relevant registers to
> userspace? I believe it would not be too difficult for userspace to
> configure the timestamps this way and would allow way more flexibility.
> Of course I would #DEFINE the constants used to set the registers.
The patch seems reasonable, but I haven't played with the igb
timestamping very much. However, what impact will this have on the
existing ptpd userspace daemon?
-PJ
^ permalink raw reply
* Re: [PATCH] atm: dereference of he_dev->rbps_virt in he_init_group()
From: Roel Kluin @ 2009-09-20 17:11 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, chas, linux-atm-general, netdev, akpm
In-Reply-To: <1253384847.2638.4.camel@Joe-Laptop.home>
he_dev->rbps_virt or he_dev->rbpl_virt allocation may fail, s
them. Make sure that he_init_group() cleans up after errors.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
> It looks as if it'd be clearer to not use variable ret and
> simply return -ENOMEM after the out_destroy_rbps_pool label.
Ok, thanks.
Again build, sparse and checkpatch tested.
diff --git a/drivers/atm/he.c b/drivers/atm/he.c
index 2de6406..29e66d6 100644
--- a/drivers/atm/he.c
+++ b/drivers/atm/he.c
@@ -790,11 +790,15 @@ he_init_group(struct he_dev *he_dev, int group)
he_dev->rbps_base = pci_alloc_consistent(he_dev->pci_dev,
CONFIG_RBPS_SIZE * sizeof(struct he_rbp), &he_dev->rbps_phys);
if (he_dev->rbps_base == NULL) {
- hprintk("failed to alloc rbps\n");
- return -ENOMEM;
+ hprintk("failed to alloc rbps_base\n");
+ goto out_destroy_rbps_pool;
}
memset(he_dev->rbps_base, 0, CONFIG_RBPS_SIZE * sizeof(struct he_rbp));
he_dev->rbps_virt = kmalloc(CONFIG_RBPS_SIZE * sizeof(struct he_virt), GFP_KERNEL);
+ if (he_dev->rbps_virt == NULL) {
+ hprintk("failed to alloc rbps_virt\n");
+ goto out_free_rbps_base;
+ }
for (i = 0; i < CONFIG_RBPS_SIZE; ++i) {
dma_addr_t dma_handle;
@@ -802,7 +806,7 @@ he_init_group(struct he_dev *he_dev, int group)
cpuaddr = pci_pool_alloc(he_dev->rbps_pool, GFP_KERNEL|GFP_DMA, &dma_handle);
if (cpuaddr == NULL)
- return -ENOMEM;
+ goto out_free_rbps_virt;
he_dev->rbps_virt[i].virt = cpuaddr;
he_dev->rbps_base[i].status = RBP_LOANED | RBP_SMALLBUF | (i << RBP_INDEX_OFF);
@@ -827,17 +831,21 @@ he_init_group(struct he_dev *he_dev, int group)
CONFIG_RBPL_BUFSIZE, 8, 0);
if (he_dev->rbpl_pool == NULL) {
hprintk("unable to create rbpl pool\n");
- return -ENOMEM;
+ goto out_free_rbps_virt;
}
he_dev->rbpl_base = pci_alloc_consistent(he_dev->pci_dev,
CONFIG_RBPL_SIZE * sizeof(struct he_rbp), &he_dev->rbpl_phys);
if (he_dev->rbpl_base == NULL) {
- hprintk("failed to alloc rbpl\n");
- return -ENOMEM;
+ hprintk("failed to alloc rbpl_base\n");
+ goto out_destroy_rbpl_pool;
}
memset(he_dev->rbpl_base, 0, CONFIG_RBPL_SIZE * sizeof(struct he_rbp));
he_dev->rbpl_virt = kmalloc(CONFIG_RBPL_SIZE * sizeof(struct he_virt), GFP_KERNEL);
+ if (he_dev->rbpl_virt == NULL) {
+ hprintk("failed to alloc rbpl_virt\n");
+ goto out_free_rbpl_base;
+ }
for (i = 0; i < CONFIG_RBPL_SIZE; ++i) {
dma_addr_t dma_handle;
@@ -845,7 +853,7 @@ he_init_group(struct he_dev *he_dev, int group)
cpuaddr = pci_pool_alloc(he_dev->rbpl_pool, GFP_KERNEL|GFP_DMA, &dma_handle);
if (cpuaddr == NULL)
- return -ENOMEM;
+ goto out_free_rbpl_virt;
he_dev->rbpl_virt[i].virt = cpuaddr;
he_dev->rbpl_base[i].status = RBP_LOANED | (i << RBP_INDEX_OFF);
@@ -870,7 +878,7 @@ he_init_group(struct he_dev *he_dev, int group)
CONFIG_RBRQ_SIZE * sizeof(struct he_rbrq), &he_dev->rbrq_phys);
if (he_dev->rbrq_base == NULL) {
hprintk("failed to allocate rbrq\n");
- return -ENOMEM;
+ goto out_free_rbpl_virt;
}
memset(he_dev->rbrq_base, 0, CONFIG_RBRQ_SIZE * sizeof(struct he_rbrq));
@@ -894,7 +902,7 @@ he_init_group(struct he_dev *he_dev, int group)
CONFIG_TBRQ_SIZE * sizeof(struct he_tbrq), &he_dev->tbrq_phys);
if (he_dev->tbrq_base == NULL) {
hprintk("failed to allocate tbrq\n");
- return -ENOMEM;
+ goto out_free_rbpq_base;
}
memset(he_dev->tbrq_base, 0, CONFIG_TBRQ_SIZE * sizeof(struct he_tbrq));
@@ -906,6 +914,39 @@ he_init_group(struct he_dev *he_dev, int group)
he_writel(he_dev, CONFIG_TBRQ_THRESH, G0_TBRQ_THRESH + (group * 16));
return 0;
+
+out_free_rbpq_base:
+ pci_free_consistent(he_dev->pci_dev, CONFIG_RBRQ_SIZE *
+ sizeof(struct he_rbrq), he_dev->rbrq_base,
+ he_dev->rbrq_phys);
+ i = CONFIG_RBPL_SIZE;
+out_free_rbpl_virt:
+ while (--i)
+ pci_pool_free(he_dev->rbps_pool, he_dev->rbpl_virt[i].virt,
+ he_dev->rbps_base[i].phys);
+ kfree(he_dev->rbpl_virt);
+
+out_free_rbpl_base:
+ pci_free_consistent(he_dev->pci_dev, CONFIG_RBPL_SIZE *
+ sizeof(struct he_rbp), he_dev->rbpl_base,
+ he_dev->rbpl_phys);
+out_destroy_rbpl_pool:
+ pci_pool_destroy(he_dev->rbpl_pool);
+
+ i = CONFIG_RBPL_SIZE;
+out_free_rbps_virt:
+ while (--i)
+ pci_pool_free(he_dev->rbpl_pool, he_dev->rbps_virt[i].virt,
+ he_dev->rbpl_base[i].phys);
+ kfree(he_dev->rbps_virt);
+
+out_free_rbps_base:
+ pci_free_consistent(he_dev->pci_dev, CONFIG_RBPS_SIZE *
+ sizeof(struct he_rbp), he_dev->rbps_base,
+ he_dev->rbps_phys);
+out_destroy_rbps_pool:
+ pci_pool_destroy(he_dev->rbps_pool);
+ return -ENOMEM;
}
static int __devinit
^ permalink raw reply related
* [PATCH] ax25: Fix SIOCAX25GETINFO ioctl
From: Eric Dumazet @ 2009-09-20 16:32 UTC (permalink / raw)
To: Jan Rafaj, David S. Miller; +Cc: Linux Netdev List
In-Reply-To: <alpine.LNX.2.00.0909201226001.29572@cedric.unob.cz>
Jan Rafaj a écrit :
>
> Hello Eric,
>
> Your commit 31e6d363abcd0d05766c82f1a9c905a4c974a199 introduces (among
> other things):
>
> diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
> index 61b35b9..da0f64f 100644
> --- a/net/ax25/af_ax25.c
> +++ b/net/ax25/af_ax25.c
> @@ -1780,8 +1781,8 @@ static int ax25_ioctl(struct socket *sock,
> unsigned int cmd, unsigned long arg)
> ax25_info.idletimer =
> ax25_display_timer(&ax25->idletimer) / (60 * HZ);
> ax25_info.n2count = ax25->n2count;
> ax25_info.state = ax25->state;
> - ax25_info.rcv_q = atomic_read(&sk->sk_rmem_alloc);
> - ax25_info.snd_q = atomic_read(&sk->sk_wmem_alloc);
> + ax25_info.rcv_q = sk_wmem_alloc_get(sk);
> + ax25_info.snd_q = sk_rmem_alloc_get(sk);
> ax25_info.vs = ax25->vs;
> ax25_info.vr = ax25->vr;
> ax25_info.va = ax25->va;
>
> I believe there is a typo, correctly this should be:
>
> ax25_info.idletimer = ax25_display_timer(&ax25->idletimer)
> / (60 * HZ);
> ax25_info.n2count = ax25->n2count;
> ax25_info.state = ax25->state;
> - ax25_info.rcv_q = atomic_read(&sk->sk_rmem_alloc);
> - ax25_info.snd_q = atomic_read(&sk->sk_wmem_alloc);
> + ax25_info.rcv_q = sk_rmem_alloc_get(sk);
> + ax25_info.snd_q = sk_wmem_alloc_get(sk);
> ax25_info.vs = ax25->vs;
> ax25_info.vr = ax25->vr;
> ax25_info.va = ax25->va;
>
> If this is not fixed in the master, then fix, please.
>
> Being a total kernel newbie, I've checked it against Greg K-H's 2.6.31.y
> git tree (but I'm quite unsure whether this is the real HEAD of
> latest [most up to date] development master branch), so if you know where
> I should be looking instead, I'll be grateful for any kicking into the
> right direction... (I somehow feel this should probably be the main
> Linus's syndication tree linux/kernel/git/torvalds/linux-2.6.git - feel
> free to correct me on this one please).
>
> Thanks,
>
> Jan
>
> ---
> Jan Rafaj
> University of Defence in Brno
>
Oops, Jan you are absolutely right, this part of the patch was wrong.
Dont worry, David will push your patch to netdev tree, then to Linus.
Thanks
[PATCH] ax25: Fix SIOCAX25GETINFO ioctl
rcv_q & snd_q initializations were reversed in commit
31e6d363abcd0d05766c82f1a9c905a4c974a199
(net: correct off-by-one write allocations reports)
Signed-off-by: Jan Rafaj <jr+netfilter-devel@cedric.unob.cz>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..d6b1b05 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1781,8 +1781,8 @@ static int ax25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
ax25_info.idletimer = ax25_display_timer(&ax25->idletimer) / (60 * HZ);
ax25_info.n2count = ax25->n2count;
ax25_info.state = ax25->state;
- ax25_info.rcv_q = sk_wmem_alloc_get(sk);
- ax25_info.snd_q = sk_rmem_alloc_get(sk);
+ ax25_info.rcv_q = sk_rmem_alloc_get(sk);
+ ax25_info.snd_q = sk_wmem_alloc_get(sk);
ax25_info.vs = ax25->vs;
ax25_info.vr = ax25->vr;
ax25_info.va = ax25->va;
^ permalink raw reply related
* Re: [PATCH 1/2] pktgen: check for link down
From: Jesper Dangaard Brouer @ 2009-09-20 15:26 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Robert Olsson, Jesper Dangaard Brouer, netdev
In-Reply-To: <20090919221844.114e2e23@nehalam>
Thanks for fixing this.
Acked-by: Jesper Dangaard Brouer <hawk@comx.dk>
On Sat, 19 Sep 2009, Stephen Hemminger wrote:
> If cable is pulled, pktgen shouldn't continue slamming packets into the
> device.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/net/core/pktgen.c 2009-09-19 11:20:55.546463176 -0700
> +++ b/net/core/pktgen.c 2009-09-19 11:22:44.810509240 -0700
> @@ -1959,7 +1959,7 @@ static int pktgen_setup_dev(struct pktge
> if (odev->type != ARPHRD_ETHER) {
> printk(KERN_ERR "pktgen: not an ethernet device: \"%s\"\n", ifname);
> err = -EINVAL;
> - } else if (!netif_running(odev)) {
> + } else if (!netif_running(odev) || !netif_carrier_ok(odev)) {
> printk(KERN_ERR "pktgen: device is down: \"%s\"\n", ifname);
> err = -ENETDOWN;
> } else {
> @@ -3410,7 +3410,7 @@ static void pktgen_xmit(struct pktgen_de
> /* Did we saturate the queue already? */
> if (netif_tx_queue_stopped(txq) || netif_tx_queue_frozen(txq)) {
> /* If device is down, then all queues are permnantly frozen */
> - if (netif_running(odev))
> + if (netif_running(odev) && netif_carrier_ok(odev))
> idle(pkt_dev);
> else
> pktgen_stop_device(pkt_dev);
Hilsen
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: jamal @ 2009-09-20 13:33 UTC (permalink / raw)
To: Xiaofei Wu; +Cc: linux netdev
In-Reply-To: <908876.76571.qm@web111609.mail.gq1.yahoo.com>
On Sun, 2009-09-20 at 02:58 -0700, Xiaofei Wu wrote:
> When the link A-B is not available,
How do you detect this? Is it a path that is broken or a link?
> Could iproute2 'tc' do this?
you could use iproute2 'ip' which supports multi-nexthops, example
off top of my head (for exact syntax run "ip route help")
----
ip route add blah/24 nexthop via a.b.c.d dev wlan0 \
nexthop via e.f.g.h dev wlan1
----
You will probably need to help it by flushing route cache.
You may need to worry about loops on mirroring when the route flipping
happens and need to optimize for that. Please experiment.
cheers,
jamal
^ permalink raw reply
* Pozyskaj nowych klientów, zwieksz przychody, obniż koszty [Paweł Boratyński]
From: pb3 @ 2009-09-20 11:55 UTC (permalink / raw)
To: netdev
Witam,
reprezentuję firmę JSystems (www.jsystems.pl). Nasza firma stworzyła profesjonalny informatyczny system marketingowy, automatyzujący proces poszukiwania nowych klientów i jednocześnie znacznie obniżający koszty tego procesu. Czy mogę Państwu przesłać ofertę dotyczącą tego produktu?
Pozdrawiam
Sales Representative
Paweł Boratyński
22 405 38 45
^ permalink raw reply
* Re: [iproute2] tc action mirred question
From: Xiaofei Wu @ 2009-09-20 9:58 UTC (permalink / raw)
To: hadi; +Cc: linux netdev
In-Reply-To: <1253104099.4584.9.camel@dogo.mojatatu.com>
Hi,
I come across another problem.
network topology:
M
|
A
/ \
B D
\ /
C
node M < ---- > node C
common path: M-A-B-C
the other path: M-A-D-C
With your help I can mirror the outgoing packets(node A wlan0) to wlan1(node A), then transmit it to D. D will route them to C.
There will be another problem.
When the link A-B is not available, there is no packect going out to mirror, node M could not get to node C. (if B is broken, A use ARP to ask the MAC of B's IP addr, but no reply)
So I want to forward the incoming packets( node M -> A(eth0) ) to wlan0(node A) and wlan1(node A) at the same time, route them separately. In this case, if one path is unavailable, it will not influence the other path.
Could iproute2 'tc' do this?
regards,
wu
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [AX25] kernel panic
From: f8arr @ 2009-09-20 9:09 UTC (permalink / raw)
To: Bernard Pidoux
Cc: Jarek Poplawski, Ralf Baechle DL5RB, Linux Netdev List,
linux-hams
In-Reply-To: <4AB5EAE5.6070605@upmc.fr>
hi Bernard,
My problem wasn't exactly the same has your.
But !
Doing a boot with the kernel option "nosmp" wasn't suffisant... it
seemed to load the smp and then, while reading the boot option,
unsetting them... but it was too late. (I saw that looking the dmesg).
My solution has been to compile a kernel without smp to be sure that
nothing goes up... and it worked !
Regards
f8arr
Bernard Pidoux a écrit :
> Hi,
>
> Here are the first events noticed since I turned on
> CONFIG_DEBUG_OBJECTS_TIMERS option.
>
> First a kernel BUG, second a kernel panic.
>
> Best regards,
>
> Bernard Pidoux
>
>
>
>
>
^ permalink raw reply
* Re: [AX25] kernel panic
From: Bernard Pidoux @ 2009-09-20 8:42 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
In-Reply-To: <20090911120557.GA12175@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 174 bytes --]
Hi,
Here are the first events noticed since I turned on
CONFIG_DEBUG_OBJECTS_TIMERS option.
First a kernel BUG, second a kernel panic.
Best regards,
Bernard Pidoux
[-- Attachment #2: kernel_bug --]
[-- Type: text/plain, Size: 4116 bytes --]
------------[ cut here ]------------
kernel BUG at kernel/timer.c:913!
invalid opcode: 0000 [#1]
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
CPU 0
Modules linked in: netconsole netrom mkiss rose ax25 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc af_packet ipv6 binfmt_misc loop ext3 jbd cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart snd_rawmidi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore shpchp pci_hotplug i2c_viapro i2c_core via_agp floppy 8139cp 8139too mii sg sr_mod processor rtc_cmos button thermal evdev pata_via ata_generic ide_pci_generic pata_acpi sata_via libata sd_mod scsi_mod crc_t10dif
Pid: 24497, comm: astropulse_5.06 Not tainted 2.6.31-nosmp #3 MS-7258
RIP: 0010:[<ffffffff81061412>] [<ffffffff81061412>] cascade+0xb2/0xc0
RSP: 0000:ffffffff8155be00 EFLAGS: 00010082
RAX: 0000000000000000 RBX: ffff880050c4c218 RCX: 0000000104445204
RDX: ffffffff8132b3d0 RSI: ffff880050c4c218 RDI: ffffffff81673540
RBP: ffffffff8155be40 R08: 0000000000000004 R09: ffffffff81568bc0
R10: ffffffff8155be28 R11: 0000000000000001 R12: ffffffff81673540
R13: ffffffff8155be00 R14: 0000000000000012 R15: 0000000000000001
FS: 00000000016e2860(0063) GS:ffffffff81558000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3eb15029c CR3: 000000007ecff000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
Process astropulse_5.06 (pid: 24497, threadinfo ffff88005807a000, task ffff880049588000)
Stack:
ffff8800445748e0 ffff88007e86ab98 ffffffff8155be88 000000008c85481d
<0> 0000000000000000 ffffffff81673540 ffffffff8155be70 0000000000000081
<0> ffffffff8155bec0 ffffffff81061613 ffffffff81675150 ffffffff81674d50
Call Trace:
<IRQ>
[<ffffffff81061613>] run_timer_softirq+0xf3/0x250
[<ffffffff8102d0db>] ? lapic_next_event+0x2b/0x50
[<ffffffff8107fc42>] ? clockevents_program_event+0x62/0xc0
[<ffffffff8105b242>] __do_softirq+0xe2/0x1d0
[<ffffffff8101414a>] call_softirq+0x1a/0x30
[<ffffffff810162c5>] do_softirq+0x75/0xc0
[<ffffffff8105ac45>] irq_exit+0x65/0x80
[<ffffffff8102ddb5>] smp_apic_timer_interrupt+0x65/0xb0
[<ffffffff81013c73>] apic_timer_interrupt+0x13/0x20
<EOI>
Code: 45 fe ff ff 4c 39 eb 48 8b 13 75 dd 48 8b 55 d8 65 48 33 14 25 28 00 00 00 44 89 f0 75 11 48 83 c4 20 5b 41 5c 41 5d 41 5e c9 c3 <0f> 0b eb fe e8 c5 29 ff ff 0f 1f 44 00 00 55 48 89 e5 48 83 ec
RIP [<ffffffff81061412>] cascade+0xb2/0xc0
RSP <ffffffff8155be00>
---[ end trace 2efb8d4aaedbf503 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Pid: 24497, comm: astropulse_5.06 Tainted: G D 2.6.31-nosmp #3
Call Trace:
<IRQ> [<ffffffff813d5e52>] panic+0xb2/0x180
[<ffffffff8132f8ff>] ? __kfree_skb+0x6f/0xe0
[<ffffffff810549bd>] ? console_unblank+0x8d/0xd0
[<ffffffff812bdcee>] ? unblank_screen+0x1e/0x40
[<ffffffff81053a36>] ? oops_exit+0x36/0x60
[<ffffffff81017947>] oops_end+0xe7/0x100
[<ffffffff810179bd>] ? oops_begin+0x5d/0x80
[<ffffffff81017b52>] die+0x62/0xa0
[<ffffffff81014e86>] do_trap+0x166/0x190
[<ffffffff8107715d>] ? notify_die+0x3d/0x60
[<ffffffff810153a5>] do_invalid_op+0xa5/0xd0
[<ffffffff81061412>] ? cascade+0xb2/0xc0
[<ffffffff8104dcde>] ? wake_up_state+0x1e/0x40
[<ffffffff81013ddb>] invalid_op+0x1b/0x20
[<ffffffff8132b3d0>] ? sock_def_write_space+0x0/0xb0
[<ffffffff81061412>] ? cascade+0xb2/0xc0
[<ffffffff81061613>] run_timer_softirq+0xf3/0x250
[<ffffffff8102d0db>] ? lapic_next_event+0x2b/0x50
[<ffffffff8107fc42>] ? clockevents_program_event+0x62/0xc0
[<ffffffff8105b242>] __do_softirq+0xe2/0x1d0
[<ffffffff8101414a>] call_softirq+0x1a/0x30
[<ffffffff810162c5>] do_softirq+0x75/0xc0
[<ffffffff8105ac45>] irq_exit+0x65/0x80
[<ffffffff8102ddb5>] smp_apic_timer_interrupt+0x65/0xb0
[<ffffffff81013c73>] apic_timer_interrupt+0x13/0x20
<EOI>
Rebooting in 60 seconds..[root@f6bvp-9 bernard]#
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: Christopher Zimmermann @ 2009-09-20 7:52 UTC (permalink / raw)
To: Peter P Waskiewicz Jr, netdev@vger.kernel.org
In-Reply-To: <1253398161.14869.2.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
On Sat, 19 Sep 2009 15:09:21 -0700
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> wrote:
> > hardware timestamps only work for the Intel igb driver. I have
> > access to two test machines with NICs supported by this driver.
>
> Intel's 82599, supported by ixgbe, also has the same IEEE 1588
> timestamping support in hardware. We haven't implemented the support
> yet in ixgbe, but the hardware is there and does work. If you were
> curious of the interface, the datasheet for the hardware is available on
> our SourceForge site (e1000.sf.net).
hi! thanks for the reply.
I already got the documentation for the 82576 cards I have access to. I
won't be able to afford another pair.
What do you think about my idea to expose the relevant registers to
userspace? I believe it would not be too difficult for userspace to
configure the timestamps this way and would allow way more flexibility.
Of course I would #DEFINE the constants used to set the registers.
Christopher Zimmermann
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] netdev: stats on multiqueue possible bug
From: Eric Dumazet @ 2009-09-20 7:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20090919222608.5fdf80b8@nehalam>
Stephen Hemminger a écrit :
> Dave, I think you were trying to optimize something here that
> doesn't need optimization.
>
> If transmit stats (all) wrap to zero, then the stats would not
> be set correctly. Move local variable into loop as well.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/net/core/dev.c 2009-09-19 15:19:13.902495560 -0700
> +++ b/net/core/dev.c 2009-09-19 15:48:21.126458728 -0700
> @@ -5079,19 +5079,19 @@ const struct net_device_stats *dev_get_s
> unsigned long tx_bytes = 0, tx_packets = 0, tx_dropped = 0;
> struct net_device_stats *stats = &dev->stats;
> unsigned int i;
> - struct netdev_queue *txq;
>
> for (i = 0; i < dev->num_tx_queues; i++) {
> - txq = netdev_get_tx_queue(dev, i);
> + const struct netdev_queue *txq
> + = netdev_get_tx_queue(dev, i);
> tx_bytes += txq->tx_bytes;
> tx_packets += txq->tx_packets;
> tx_dropped += txq->tx_dropped;
> }
> - if (tx_bytes || tx_packets || tx_dropped) {
> - stats->tx_bytes = tx_bytes;
> - stats->tx_packets = tx_packets;
> - stats->tx_dropped = tx_dropped;
> - }
> +
> + stats->tx_bytes = tx_bytes;
> + stats->tx_packets = tx_packets;
> + stats->tx_dropped = tx_dropped;
> +
> return stats;
> }
> }
Most devices dont update txq->tx_bytes/tx_packets/tx_dropped yet, but
still update their device->stats
Your patch makes these devices clearing their stats.
In the case all stats wrap to zero, we'll give old values. If you think this is
a bug, you should find another way to fix it :)
^ permalink raw reply
* Re: sky2 rx length errors
From: Andrew Morton @ 2009-09-20 6:35 UTC (permalink / raw)
To: Grozdan; +Cc: linux-kernel, Stephen Hemminger, netdev
In-Reply-To: <c5bd819b0909180641n7c353b80tc15b9c9fe02d5c95@mail.gmail.com>
(added cc's from the MAINTAINERS file)
On Fri, 18 Sep 2009 15:41:45 +0200 Grozdan <neutrino8@gmail.com> wrote:
> Hi,
>
> I have a Marvell onboard NIC (88E8053) and I've been noticing for a
> while now a bit weird behavior with the sky2 driver. This mostly
> occurs with newer kernels (2.6.30, 2.6.31) and my older distro kernel
> (2.6.27.21) does not seem to have the same problem. Basically, the
> sky2 driver will randomly and unpredictably spew rx length error
> messages and reboot itself. I also noticed in dmesg that this mostly
> occurs after "martian destination" messages. After this message, sky2
> starts spewing messages as shown below and then reboots itself. It is
> not really a big problem for me, but since I'm virtually always logged
> in in IRC, the client always loses connection, waits for a few minutes
> to get a response from the server and then relogs me again. I do not
> think it's a HW problem as the Marvell NIC otherwise works perfectly
> and I've checked my cable modem too which operates without a problem.
> Any ideas?
>
> PS: please cc me as I'm not subscribed to the mailing list
>
> sky2 driver version 1.23
> sky2 0000:05:00.0: PCI INT A -> GSI 36 (level, low) -> IRQ 36
> sky2 0000:05:00.0: setting latency timer to 64
> sky2 0000:05:00.0: PCI: Disallowing DAC for device
> sky2 0000:05:00.0: Yukon-2 EC chip revision 2
> sky2 0000:05:00.0: irq 53 for MSI/MSI-X
> sky2 0000:05:00.0: No interrupt generated using MSI, switching to INTx mode.
> sky2 eth0: addr 00:11:d8:a1:5b:0e
> sky2 eth0: enabling interface
> sky2 eth0: Link is up at 100 Mbps, full duplex, flow control rx
> .....
> .....
> martian destination 0.0.0.0 from 172.23.204.1, dev eth0
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x5ea0100 length 598
> sky2 eth0: rx length error: status 0x5ea0100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x5ea0100 length 598
> sky2 eth0: rx length error: status 0x5ea0100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
> sky2 eth0: rx length error: status 0x4420100 length 598
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox