* Re: [PATCH] e100: timer power saving
From: Arjan van de Ven @ 2007-09-09 22:37 UTC (permalink / raw)
To: Auke Kok; +Cc: jeff, netdev, shemminger
In-Reply-To: <20070906185137.30733.99594.stgit@localhost.localdomain>
Auke Kok wrote:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
>
> Since E100 timer is 2HZ, use rounding to make timer occur on the
> correct boundary.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
given that I was about to send out exactly this same patch...
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
^ permalink raw reply
* Re: 2.6.23-rc4-mm1: e1000e napi lockup
From: Kok, Auke @ 2007-09-09 22:50 UTC (permalink / raw)
To: Jiri Slaby
Cc: no To-header on input, Andrew Morton, netdev, e1000-devel,
Auke Kok, David S. Miller
In-Reply-To: <46E3C3B9.4010500@gmail.com>
Jiri Slaby wrote:
> On 09/07/2007 09:19 AM, Jiri Slaby wrote:
>> Hi,
>>
>> I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
>> napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
>
> Ok, after these changes:
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index c1c64e2..f8ec537 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -1693,10 +1693,7 @@ quit_polling:
> if (adapter->itr_setting & 3)
> e1000_set_itr(adapter);
> netif_rx_complete(poll_dev, napi);
> - if (test_bit(__E1000_DOWN, &adapter->state))
> - atomic_dec(&adapter->irq_sem);
> - else
> - e1000_irq_enable(adapter);
> + e1000_irq_enable(adapter);
> return 0;
> }
>
> @@ -4257,7 +4254,6 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
> /* tell the stack to leave us alone until e1000_open() is called */
> netif_carrier_off(netdev);
> netif_stop_queue(netdev);
> - napi_disable(&adapter->napi);
>
> strcpy(netdev->name, "eth%d");
> err = register_netdev(netdev);
>
>
> I still have problems with the driver. When I do `ip link set eth0 up', ksoftirq
> runs with 100 % cpu time, so I think you endlessly re-schedule some timer (or
> the new napi layer?)
something changed in the logic and e1000e apparently does something wrong. I'll
look into it on monday and resubmit a fixup patch (see robert olsson's mail as
well discussing this issue)
Auke
^ permalink raw reply
* Re: [IPv6] BUG: NULL pointer dereference in(?) ip6_flush_pending_frames
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-09-09 23:38 UTC (permalink / raw)
To: berni; +Cc: netdev, yoshfuji, miyazawa
In-Reply-To: <20070909222400.GC7591@obelix.birkenwald.de>
In article <20070909222400.GC7591@obelix.birkenwald.de> (at Mon, 10 Sep 2007 00:24:00 +0200), Bernhard Schmidt <berni@birkenwald.de> says:
> I'm running a public Teredo relay (IPv4-to-IPv6 migration protocol)
> using Miredo. Every once in a while (a few minutes to days after
> daemon restart) it becomes unusable and I see the following kernel
> message:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0000008c
:
> EIP is at ip6_flush_pending_frames+0x97/0x121
I think I've found a bug.
Some of skbs in sk->write_queue do not have skb->dst because
we do not fill skb->dst when we allocate new skb in append_data().
Miyazawa-san, am I right?
BTW, I think we may not need to (or we should not) increment some stats
when using corking; if 100 sendmsg() (with MSG_MORE) result in 2 packets,
how many should we increment?
If 100, we should set skb->dst for every queued skbs.
If 1 (or 2 (*)), we increment the stats for the first queued skb and
we should just skip incrementing OutDiscards for the rest of queued skbs,
adn we should also impelement this semantics in other places;
e.g., we should increment other stats just once, not 100 times.
*: depends on the place we are discarding the datagram.
I guess should just increment by 1 (or 2).
Anyway, please try this.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 4704b5f..e489499 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1423,8 +1423,9 @@ void ip6_flush_pending_frames(struct sock *sk)
struct sk_buff *skb;
while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL) {
- IP6_INC_STATS(ip6_dst_idev(skb->dst),
- IPSTATS_MIB_OUTDISCARDS);
+ if (skb->dst)
+ IP6_INC_STATS(ip6_dst_idev(skb->dst),
+ IPSTATS_MIB_OUTDISCARDS);
kfree_skb(skb);
}
--yoshfuji
^ permalink raw reply related
* Re: [RFC 0/3] rfkill
From: Dmitry Torokhov @ 2007-09-10 4:04 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: netdev, linux-wireless, Inaky Perez-Gonzalez
In-Reply-To: <200709081710.56744.IvDoorn@gmail.com>
Hi Ivo,
On Saturday 08 September 2007 11:10, Ivo van Doorn wrote:
> Hi Dmitry,
>
> I have a few rfkill related patches for which I would prefer if you to could
> take a look at before I send them for inclusion.
>
Looks good, feel free to add
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Thanks!
--
Dmitry
^ permalink raw reply
* Re: [PATCH 03/16] net: Basic network namespace infrastructure.
From: Krishna Kumar2 @ 2007-09-10 5:46 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Linux Containers, David Miller, netdev
In-Reply-To: <m1ejh8x3ih.fsf_-_@ebiederm.dsl.xmission.com>
Eric W. Biederman wrote on 09/09/2007 02:45:34 AM:
Hi Eric,
> +static int register_pernet_operations(struct list_head *list,
> + struct pernet_operations *ops)
> +{
> <snip>
> +out:
> + return error;
> +
> +out_undo:
> + /* If I have an error cleanup all namespaces I initialized */
> + list_del(&ops->list);
> + for_each_net(undo_net) {
> + if (undo_net == net)
> + goto undone;
> + if (ops->exit)
> + ops->exit(undo_net);
> + }
> +undone:
> + goto out;
> +}
You could remove "undone" label (and associated) goto with a "break".
> +static void unregister_pernet_operations(struct pernet_operations *ops)
> +{
> + struct net *net;
> +
> + list_del(&ops->list);
> + for_each_net(net)
> + if (ops->exit)
> + ops->exit(net);
> +}
> +
> +/**
> + * register_pernet_subsys - register a network namespace subsystem
> + * @ops: pernet operations structure for the subsystem
> + *
> + * Register a subsystem which has init and exit functions
> + * that are called when network namespaces are created and
> + * destroyed respectively.
> + *
> + * When registered all network namespace init functions are
> + * called for every existing network namespace. Allowing kernel
> + * modules to have a race free view of the set of network namespaces.
> + *
> + * When a new network namespace is created all of the init
> + * methods are called in the order in which they were registered.
> + *
> + * When a network namespace is destroyed all of the exit methods
> + * are called in the reverse of the order with which they were
> + * registered.
> + */
<snip>
> +/**
> + * unregister_pernet_subsys - unregister a network namespace
subsystem
> + * @ops: pernet operations structure to manipulate
> + *
> + * Remove the pernet operations structure from the list to be
> + * used when network namespaces are created or destoryed. In
> + * addition run the exit method for all existing network
> + * namespaces.
> + */
> +void unregister_pernet_subsys(struct pernet_operations *module)
> +{
> + mutex_lock(&net_mutex);
> + unregister_pernet_operations(module);
> + mutex_unlock(&net_mutex);
> +}
Don't you require something like for_each_net_backwards to 'exit' in
reverse order? Same comment for unregister_subnet_subsys(). Should this
be done for failure in register_pernet_operations too?
thanks,
- KK
^ permalink raw reply
* Re: 2.6.23-rc4-mm1: e1000e napi lockup
From: Jiri Slaby @ 2007-09-10 6:24 UTC (permalink / raw)
To: Kok, Auke; +Cc: Andrew Morton, netdev, e1000-devel, David S. Miller
In-Reply-To: <46E478BE.2030202@intel.com>
Kok, Auke napsal(a):
> Jiri Slaby wrote:
>> I still have problems with the driver. When I do `ip link set eth0
>> up', ksoftirq
>> runs with 100 % cpu time, so I think you endlessly re-schedule some
>> timer (or
>> the new napi layer?)
>
> something changed in the logic and e1000e apparently does something
> wrong. I'll look into it on monday and resubmit a fixup patch (see
> robert olsson's mail as well discussing this issue)
he's posted me a patch, but no change on my side :(.
Anyway, I'm going away of the box on monday (today). will be back on fri to
test patches :).
thanks,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
^ permalink raw reply
* Re: 2.6.23-rc4-mm1: e1000e napi lockup
From: Kok, Auke @ 2007-09-10 6:31 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Andrew Morton, netdev, e1000-devel, David S. Miller
In-Reply-To: <46E4E305.6010406@gmail.com>
Jiri Slaby wrote:
> Kok, Auke napsal(a):
>> Jiri Slaby wrote:
>>> I still have problems with the driver. When I do `ip link set eth0
>>> up', ksoftirq
>>> runs with 100 % cpu time, so I think you endlessly re-schedule some
>>> timer (or
>>> the new napi layer?)
>> something changed in the logic and e1000e apparently does something
>> wrong. I'll look into it on monday and resubmit a fixup patch (see
>> robert olsson's mail as well discussing this issue)
>
> he's posted me a patch, but no change on my side :(.
that's what I feared/thought as well when I saw his patch - e1000e and e1000 are
slightly different so the exit condition will be as well.
> Anyway, I'm going away of the box on monday (today). will be back on fri to
> test patches :).
I'll be on top of it. Since e1000e will be merged I need to get this workign
properly before the merge window opens - no pressure :)
Auke
^ permalink raw reply
* Re: [PATCH 03/16] net: Basic network namespace infrastructure.
From: Eric W. Biederman @ 2007-09-10 6:32 UTC (permalink / raw)
To: paulmck; +Cc: David Miller, netdev, Linux Containers
In-Reply-To: <20070909164547.GD10417@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> writes:
>> I know I cannot use get_net for the reference in in /proc because
>> otherwise I could not release the network namespace unless I was to
>> unmount the filesystem, which is not a desirable property.
>>
>> I think I can change the idiom to:
>>
>> struct net *maybe_get_net(struct net *net)
>> {
>> if (!atomic_inc_not_zero(&net->count))
>> net = NULL;
>> return net;
>> }
>>
>> Which would make dev_seq_open be:
>>
>> static int dev_seq_open(struct inode *inode, struct file *file)
>> {
>> struct seq_file *seq;
>> int res;
>> res = seq_open(file, &dev_seq_ops);
>> if (!res) {
>> seq = file->private_data;
>> seq->private = maybe_get_net(PROC_NET(inode));
>> if (!seq->private) {
>> res = -ENOENT;
>> seq_release(inode, file);
>> }
>> }
>> return res;
>> }
>>
>> I'm still asking myself if I need any kind of locking to ensure
>> struct net does not go away in the mean time, if so rcu_read_lock()
>> should be sufficient.
>
> Agreed -- and it might be possible to leverage the existing locking
> in the /proc code.
Yes. The generic /proc code takes care of this. It appears
to ensure that any ongoing operations will be waited for and
no more operations will be started once remove_proc_entry
is called. So I just need the maybe_get_net thing to have
safe ref counting.
That is what I thought but I figured I would review that part while
I was looking at everything.
Eric
^ permalink raw reply
* sh: add support for ax88796 and 93cx6 to highlander boards
From: Magnus Damm @ 2007-09-10 6:36 UTC (permalink / raw)
To: netdev; +Cc: Magnus Damm, lethal, jgarzik, ben-linux
sh: add support for ax88796 and 93cx6 to highlander boards
This patch adds eeprom support to the ax88796 driver together with a platform
device for highlander boards. The 93cx6 driver is hooked up to the ax88796
driver and is used to read out the mac address from the on board eeprom. The
pin configuration used to connect the eeprom to the ax88796 is the same one
as pointed out by the ax88796 datasheet. So it's likely that we can reuse
this code for other boards as well.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
---
arch/sh/boards/renesas/r7780rp/setup.c | 40 ++++++++++++++++++++++++++
drivers/net/Kconfig | 9 +++++
drivers/net/ax88796.c | 49 ++++++++++++++++++++++++++++++++
include/linux/eeprom_93cx6.h | 3 +
include/net/ax88796.h | 1
5 files changed, 100 insertions(+), 2 deletions(-)
--- 0004/arch/sh/boards/renesas/r7780rp/setup.c
+++ work/arch/sh/boards/renesas/r7780rp/setup.c 2007-09-06 15:35:49.000000000 +0900
@@ -21,6 +21,7 @@
#include <asm/clock.h>
#include <asm/heartbeat.h>
#include <asm/io.h>
+#include <net/ax88796.h>
static struct resource r8a66597_usb_host_resources[] = {
[0] = {
@@ -136,11 +137,50 @@ static struct platform_device heartbeat_
.resource = heartbeat_resources,
};
+static struct ax_plat_data ax88796_platdata = {
+ .flags = AXFLG_HAS_93CX6,
+ .wordlength = 2,
+ .dcr_val = 0x1,
+ .rcr_val = 0x40,
+};
+
+static struct resource ax88796_resources[] = {
+ {
+#ifdef CONFIG_SH_R7780RP
+ .start = 0xa5800400,
+ .end = 0xa5800400 + (0x20 * 0x2) - 1,
+#else
+ .start = 0xa4100400,
+ .end = 0xa4100400 + (0x20 * 0x2) - 1,
+#endif
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_AX88796,
+ .end = IRQ_AX88796,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device ax88796_device = {
+ .name = "ax88796",
+ .id = 0,
+
+ .dev = {
+ .platform_data = &ax88796_platdata,
+ },
+
+ .num_resources = ARRAY_SIZE(ax88796_resources),
+ .resource = ax88796_resources,
+};
+
+
static struct platform_device *r7780rp_devices[] __initdata = {
&r8a66597_usb_host_device,
&m66592_usb_peripheral_device,
&cf_ide_device,
&heartbeat_device,
+ &ax88796_device,
};
static int __init r7780rp_devices_setup(void)
--- 0001/drivers/net/Kconfig
+++ work/drivers/net/Kconfig 2007-09-06 15:35:41.000000000 +0900
@@ -218,13 +218,20 @@ source "drivers/net/arm/Kconfig"
config AX88796
tristate "ASIX AX88796 NE2000 clone support"
- depends on ARM || MIPS
+ depends on ARM || MIPS || SUPERH
select CRC32
select MII
help
AX88796 driver, using platform bus to provide
chip detection and resources
+config AX88796_93CX6
+ bool "ASIX AX88796 external 93CX6 eeprom support"
+ depends on AX88796
+ select EEPROM_93CX6
+ help
+ Select this if your platform comes with an external 93CX6 eeprom.
+
config MACE
tristate "MACE (Power Mac ethernet) support"
depends on PPC_PMAC && PPC32
--- 0001/drivers/net/ax88796.c
+++ work/drivers/net/ax88796.c 2007-09-06 15:35:41.000000000 +0900
@@ -24,6 +24,7 @@
#include <linux/etherdevice.h>
#include <linux/ethtool.h>
#include <linux/mii.h>
+#include <linux/eeprom_93cx6.h>
#include <net/ax88796.h>
@@ -582,6 +583,37 @@ static const struct ethtool_ops ax_ethto
.get_link = ax_get_link,
};
+#ifdef CONFIG_AX88796_93CX6
+static void ax_eeprom_register_read(struct eeprom_93cx6 *eeprom)
+{
+ struct ei_device *ei_local = eeprom->data;
+ u8 reg = ei_inb(ei_local->mem + AX_MEMR);
+
+ eeprom->reg_data_in = reg & AX_MEMR_EEI;
+ eeprom->reg_data_out = reg & AX_MEMR_EEO; /* Input pin */
+ eeprom->reg_data_clock = reg & AX_MEMR_EECLK;
+ eeprom->reg_chip_select = reg & AX_MEMR_EECS;
+}
+
+static void ax_eeprom_register_write(struct eeprom_93cx6 *eeprom)
+{
+ struct ei_device *ei_local = eeprom->data;
+ u8 reg = ei_inb(ei_local->mem + AX_MEMR);
+
+ reg &= ~(AX_MEMR_EEI | AX_MEMR_EECLK | AX_MEMR_EECS);
+
+ if (eeprom->reg_data_in)
+ reg |= AX_MEMR_EEI;
+ if (eeprom->reg_data_clock)
+ reg |= AX_MEMR_EECLK;
+ if (eeprom->reg_chip_select)
+ reg |= AX_MEMR_EECS;
+
+ ei_outb(reg, ei_local->mem + AX_MEMR);
+ udelay(10);
+}
+#endif
+
/* setup code */
static void ax_initial_setup(struct net_device *dev, struct ei_device *ei_local)
@@ -640,6 +672,23 @@ static int ax_init_dev(struct net_device
memcpy(dev->dev_addr, SA_prom, 6);
}
+#ifdef CONFIG_AX88796_93CX6
+ if (first_init && ax->plat->flags & AXFLG_HAS_93CX6) {
+ unsigned char mac_addr[6];
+ struct eeprom_93cx6 eeprom;
+
+ eeprom.data = ei_local;
+ eeprom.register_read = ax_eeprom_register_read;
+ eeprom.register_write = ax_eeprom_register_write;
+ eeprom.width = PCI_EEPROM_WIDTH_93C56;
+
+ eeprom_93cx6_multiread(&eeprom, 0,
+ (__le16 __force *)mac_addr,
+ sizeof(mac_addr) >> 1);
+
+ memcpy(dev->dev_addr, mac_addr, 6);
+ }
+#endif
if (ax->plat->wordlength == 2) {
/* We must set the 8390 for word mode. */
ei_outb(ax->plat->dcr_val, ei_local->mem + EN0_DCFG);
--- 0001/include/linux/eeprom_93cx6.h
+++ work/include/linux/eeprom_93cx6.h 2007-09-06 15:35:41.000000000 +0900
@@ -21,13 +21,14 @@
/*
Module: eeprom_93cx6
Abstract: EEPROM reader datastructures for 93cx6 chipsets.
- Supported chipsets: 93c46 & 93c66.
+ Supported chipsets: 93c46, 93c56 and 93c66.
*/
/*
* EEPROM operation defines.
*/
#define PCI_EEPROM_WIDTH_93C46 6
+#define PCI_EEPROM_WIDTH_93C56 8
#define PCI_EEPROM_WIDTH_93C66 8
#define PCI_EEPROM_WIDTH_OPCODE 3
#define PCI_EEPROM_WRITE_OPCODE 0x05
--- 0001/include/net/ax88796.h
+++ work/include/net/ax88796.h 2007-09-06 15:35:41.000000000 +0900
@@ -14,6 +14,7 @@
#define AXFLG_HAS_EEPROM (1<<0)
#define AXFLG_MAC_FROMDEV (1<<1) /* device already has MAC */
+#define AXFLG_HAS_93CX6 (1<<2) /* use eeprom_93cx6 driver */
struct ax_plat_data {
unsigned int flags;
^ permalink raw reply
* Re: [PATCH 03/16] net: Basic network namespace infrastructure.
From: Eric W. Biederman @ 2007-09-10 6:40 UTC (permalink / raw)
To: Krishna Kumar2
Cc: Linux Containers, netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <OF55551EA4.A3E6920C-ON65257352.001D6A3E-65257352.001FBEA7-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org>
Krishna Kumar2 <krkumar2-xthvdsQ13ZrQT0dZR+AlfA@public.gmane.org> writes:
> Eric W. Biederman wrote on 09/09/2007 02:45:34 AM:
>
> Hi Eric,
>
>> +static int register_pernet_operations(struct list_head *list,
>> + struct pernet_operations *ops)
>> +{
>> <snip>
>> +out:
>> + return error;
>> +
>> +out_undo:
>> + /* If I have an error cleanup all namespaces I initialized */
>> + list_del(&ops->list);
>> + for_each_net(undo_net) {
>> + if (undo_net == net)
>> + goto undone;
>> + if (ops->exit)
>> + ops->exit(undo_net);
>> + }
>> +undone:
>> + goto out;
>> +}
>
> You could remove "undone" label (and associated) goto with a "break".
I could but there is there is no guarantee that the for_each_net macro is
implemented with standard C looping construct such that break will work,
and in one of the earlier versions that wasn't the case. So my paranoia
says an explicit label safer and just as clear.
>> +static void unregister_pernet_operations(struct pernet_operations *ops)
>> +{
>> + struct net *net;
>> +
>> + list_del(&ops->list);
>> + for_each_net(net)
>> + if (ops->exit)
>> + ops->exit(net);
>> +}
>
> Don't you require something like for_each_net_backwards to 'exit' in
> reverse order? Same comment for unregister_subnet_subsys(). Should this
> be done for failure in register_pernet_operations too?
There are no ordering guarantees between the initialization and
cleanup of different network namespaces. The only real guarantee
is that the initial network namespace is always present. Which
means any order will work so always doing it in a forwards order
in the list should be fine.
Eric
^ permalink raw reply
* Re: sh: add support for ax88796 and 93cx6 to highlander boards
From: Paul Mundt @ 2007-09-10 7:15 UTC (permalink / raw)
To: Magnus Damm; +Cc: netdev, jgarzik, ben-linux
In-Reply-To: <20070910063626.2300.75144.sendpatchset@clockwork.opensource.se>
On Mon, Sep 10, 2007 at 03:36:26PM +0900, Magnus Damm wrote:
> --- 0004/arch/sh/boards/renesas/r7780rp/setup.c
> +++ work/arch/sh/boards/renesas/r7780rp/setup.c 2007-09-06 15:35:49.000000000 +0900
> @@ -21,6 +21,7 @@
> #include <asm/clock.h>
> #include <asm/heartbeat.h>
> #include <asm/io.h>
> +#include <net/ax88796.h>
>
> static struct resource r8a66597_usb_host_resources[] = {
> [0] = {
> @@ -136,11 +137,50 @@ static struct platform_device heartbeat_
> .resource = heartbeat_resources,
> };
>
> +static struct ax_plat_data ax88796_platdata = {
> + .flags = AXFLG_HAS_93CX6,
> + .wordlength = 2,
> + .dcr_val = 0x1,
> + .rcr_val = 0x40,
> +};
> +
> +static struct resource ax88796_resources[] = {
> + {
> +#ifdef CONFIG_SH_R7780RP
> + .start = 0xa5800400,
> + .end = 0xa5800400 + (0x20 * 0x2) - 1,
> +#else
> + .start = 0xa4100400,
> + .end = 0xa4100400 + (0x20 * 0x2) - 1,
> +#endif
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = IRQ_AX88796,
> + .end = IRQ_AX88796,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device ax88796_device = {
> + .name = "ax88796",
> + .id = 0,
> +
> + .dev = {
> + .platform_data = &ax88796_platdata,
> + },
> +
> + .num_resources = ARRAY_SIZE(ax88796_resources),
> + .resource = ax88796_resources,
> +};
> +
> +
> static struct platform_device *r7780rp_devices[] __initdata = {
> &r8a66597_usb_host_device,
> &m66592_usb_peripheral_device,
> &cf_ide_device,
> &heartbeat_device,
> + &ax88796_device,
> };
>
> static int __init r7780rp_devices_setup(void)
These bits I'll merge separately once the other patches have been
applied.
> --- 0001/drivers/net/Kconfig
> +++ work/drivers/net/Kconfig 2007-09-06 15:35:41.000000000 +0900
> @@ -218,13 +218,20 @@ source "drivers/net/arm/Kconfig"
>
> config AX88796
> tristate "ASIX AX88796 NE2000 clone support"
> - depends on ARM || MIPS
> + depends on ARM || MIPS || SUPERH
> select CRC32
> select MII
> help
> AX88796 driver, using platform bus to provide
> chip detection and resources
>
> +config AX88796_93CX6
> + bool "ASIX AX88796 external 93CX6 eeprom support"
> + depends on AX88796
> + select EEPROM_93CX6
> + help
> + Select this if your platform comes with an external 93CX6 eeprom.
> +
> config MACE
> tristate "MACE (Power Mac ethernet) support"
> depends on PPC_PMAC && PPC32
There are two different changes here, these should probably be split up
and applied independently of each other, given that there's no real
dependency between them.
^ permalink raw reply
* [INET_DIAG]: Fix oops in netlink_rcv_skb
From: Patrick McHardy @ 2007-09-10 7:50 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, stable, Athanasius
[-- Attachment #1: Type: text/plain, Size: 240 bytes --]
Fix the oidentd oops reported by Athanasius <link@miggy.org> in
http://bugzilla.kernel.org/show_bug.cgi?id=8961
The oops is a 2.6.22 regression and triggerable by normal users.
The patch applies cleanly to current -git and stable-2.6.22.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 3154 bytes --]
[INET_DIAG]: Fix oops in netlink_rcv_skb
netlink_run_queue() doesn't handle multiple processes processing the
queue concurrently. Serialize queue processing in inet_diag to fix
a oops in netlink_rcv_skb caused by netlink_run_queue passing a
NULL for the skb.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000054
[349587.500454] printing eip:
[349587.500457] c03318ae
[349587.500459] *pde = 00000000
[349587.500464] Oops: 0000 [#1]
[349587.500466] PREEMPT SMP
[349587.500474] Modules linked in: w83627hf hwmon_vid i2c_isa
[349587.500483] CPU: 0
[349587.500485] EIP: 0060:[<c03318ae>] Not tainted VLI
[349587.500487] EFLAGS: 00010246 (2.6.22.3 #1)
[349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e
[349587.500506] eax: 00000000 ebx: 00000000 ecx: c148d2a0 edx: c0398819
[349587.500510] esi: 00000000 edi: c0398819 ebp: c7a21c8c esp: c7a21c80
[349587.500517] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[349587.500521] Process oidentd (pid: 17943, ti=c7a20000 task=cee231c0 task.ti=c7a20000)
[349587.500527] Stack: 00000000 c7a21cac f7c8ba78 c7a21ca4 c0331962 c0398819 f7c8ba00 0000004c
[349587.500542] f736f000 c7a21cb4 c03988e3 00000001 f7c8ba00 c7a21cc4 c03312a5 0000004c
[349587.500558] f7c8ba00 c7a21cd4 c0330681 f7c8ba00 e4695280 c7a21d00 c03307c6 7fffffff
[349587.500578] Call Trace:
[349587.500581] [<c010361a>] show_trace_log_lvl+0x1c/0x33
[349587.500591] [<c01036d4>] show_stack_log_lvl+0x8d/0xaa
[349587.500595] [<c010390e>] show_registers+0x1cb/0x321
[349587.500604] [<c0103bff>] die+0x112/0x1e1
[349587.500607] [<c01132d2>] do_page_fault+0x229/0x565
[349587.500618] [<c03c8d3a>] error_code+0x72/0x78
[349587.500625] [<c0331962>] netlink_run_queue+0x40/0x76
[349587.500632] [<c03988e3>] inet_diag_rcv+0x1f/0x2c
[349587.500639] [<c03312a5>] netlink_data_ready+0x57/0x59
[349587.500643] [<c0330681>] netlink_sendskb+0x24/0x45
[349587.500651] [<c03307c6>] netlink_unicast+0x100/0x116
[349587.500656] [<c0330f83>] netlink_sendmsg+0x1c2/0x280
[349587.500664] [<c02fcce9>] sock_sendmsg+0xba/0xd5
[349587.500671] [<c02fe4d1>] sys_sendmsg+0x17b/0x1e8
[349587.500676] [<c02fe92d>] sys_socketcall+0x230/0x24d
[349587.500684] [<c01028d2>] syscall_call+0x7/0xb
[349587.500691] =======================
[349587.500693] Code: f0 ff 4e 18 0f 94 c0 84 c0 0f 84 66 ff ff ff 89 f0 e8 86 e2 fc ff e9 5a ff ff ff f0 ff 40 10 eb be 55 89 e5 57 89 d7 56 89 c6 53 <8b> 50 54 83 fa 10 72 55 8b 9e 9c 00 00 00 31 c9 8b 03 83 f8 0f
Reported by Athanasius <link@miggy.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index dbeacd8..def007e 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -836,12 +836,16 @@ static int inet_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
return inet_diag_get_exact(skb, nlh);
}
+static DEFINE_MUTEX(inet_diag_mutex);
+
static void inet_diag_rcv(struct sock *sk, int len)
{
unsigned int qlen = 0;
do {
+ mutex_lock(&inet_diag_mutex);
netlink_run_queue(sk, &qlen, &inet_diag_rcv_msg);
+ mutex_unlock(&inet_diag_mutex);
} while (qlen);
}
^ permalink raw reply related
* Re: [IPv6] BUG: NULL pointer dereference in(?) ip6_flush_pending_frames
From: Bernhard Schmidt @ 2007-09-10 8:18 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev, miyazawa
In-Reply-To: <20070910.083847.40751994.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明:
Hi,
>> BUG: unable to handle kernel NULL pointer dereference at virtual address
>> 0000008c
> :
>> EIP is at ip6_flush_pending_frames+0x97/0x121
>
> I think I've found a bug.
[...]
> Anyway, please try this.
FTR, I tried 2.6.22.6 without the patch and it failed as well. The
patched kernel is running since yesterday evening (about 8h now) and
seems to be stable so far. Too early to tell for sure, but I guess we
have a fix.
Thanks Yoshifuji!
Regards,
Bernhard
^ permalink raw reply
* Re: [PATCH resend] Fix a lock problem in generic phy code
From: Herbert Xu @ 2007-09-10 8:58 UTC (permalink / raw)
To: Hans-J??rgen Koch; +Cc: linux-kernel, netdev, jeff, afleming
In-Reply-To: <200709092336.25634.hjk@linutronix.de>
Hans-J??rgen Koch <hjk@linutronix.de> wrote:
>
> The following patch fixes it. Tested on an AT91SAM9263-EK board, kernel 2.6.23-rc4 and -rc3-mm1.
Could you please audit all instances of physdev->lock and add
_bh where necessary? I can see that at least phys_stop also
needs the _bh.
We should also consider whether it makes sense to move the
timer into a work queue.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates
From: James Chapman @ 2007-09-10 9:20 UTC (permalink / raw)
To: hadi; +Cc: netdev, davem, jeff, mandeep.baines, ossthema, Stephen Hemminger
In-Reply-To: <1189171370.4234.38.camel@localhost>
jamal wrote:
> If the problem i am trying to solve is "reduce cpu use at lower rate",
> then this is not the right answer because your cpu use has gone up.
The problem I'm trying to solve is "reduce the max interrupt rate from
NAPI drivers while minimizing latency". In modern systems, the interrupt
rate can be so high that the CPU spends too much time processing
interrupts, resulting in the system's behavior seen by the user being
degraded.
Having the poll() called when idle will always increase CPU usage. But
the feedback you and others are giving encourages me to find a better
compromise. At the end of the day, it's going to be a trade-off of cpu
and latency. The trade-off will be different for each hardware system
and application environment so parameters need to be tunable.
I'll go away and do some tests. I'll post results here for discussion later.
Thanks for your feedback.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates
From: James Chapman @ 2007-09-10 9:25 UTC (permalink / raw)
To: Jason Lunz
Cc: netdev, davem, jeff, mandeep.baines, ossthema, hadi,
Stephen Hemminger
In-Reply-To: <20070907212044.GA9786@falooley.org>
Jason Lunz wrote:
> I'd be particularly interested to see what happens to your latency when
> other apps are hogging the cpu. I assume from your description that your
> cpu is mostly free to schedule the niced softirqd for the device polling
> duration, but this won't always be the case. If other tasks are running
> at high priority, it could be nearly a full jiffy before softirqd gets
> to check the poll list again and the latency introduced could be much
> higher than you've yet measured.
Indeed. The effect of cpu load on all of this is important to consider.
The challenge will be how to test it fairly on different test runs.
One thing to bear in mind is that interrupts are processed at highest
priority, above any scheduled work. Reducing interrupt rate gives the
scheduler more chance to run what it thinks is the next highest priority
work. This might be at the expense of network processing. Is it better
to give other runnable tasks a fair chunk of the cpu pie? I think so.
I'll try to incorporate application cpu load into my tests. Thanks for
your feedback.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates
From: James Chapman @ 2007-09-10 9:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, hadi, davem, jeff, mandeep.baines, ossthema
In-Reply-To: <p737in19kxw.fsf@bingen.suse.de>
Andi Kleen wrote:
> James Chapman <jchapman@katalix.com> writes:
> On some platforms the precise timers (like ktime_get()) can be slow,
> but often they are fast. It might make sense to use a shorter
> constant time wait on those with fast timers at least. Right now this
> cannot be known by portable code, but there was a proposal some time
> ago to export some global estimate to tell how fast
> ktime_get().et.al. are. That could be reviewed.
Interesting. Is ktime_get() fast enough on P4 systems? I'll be using
those to test with.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: RFC: possible NAPI improvements to reduce interrupt rates for low traffic rates
From: James Chapman @ 2007-09-10 9:33 UTC (permalink / raw)
To: Mandeep Singh Baines
Cc: netdev, hadi, davem, jeff, ossthema, Stephen Hemminger
In-Reply-To: <20070908164222.GB3765@ludhiana>
Mandeep Singh Baines wrote:
>> Why would using a timer to hold off the napi_complete() rather than
>> jiffy count limit the polls per packet to 2?
>>
> I was thinking a timer could be used in the way suggested in Jamal's
> paper. The driver would do nothing (park) until the timer expires. So
> there would be no calls to poll for the duration of the timer. Hence,
> this approach would add extra latency not present in a jiffy polling
> approach.
Ah, ok. I wasn't planning to test timer-driven polling. :)
>> Why wouldn't it be efficient? It would usually be done by reading an
>> "interrupt pending" register.
>>
> Reading the "interrupt pending" register would require an MMIO read.
> MMIO reads are very expensive. In some systems the latency of an MMIO
> read can be 1000x that of an L1 cache access.
Agreed. Testing for any work being available should be as efficient as
possible and would be driver specific.
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* un
From: Robert Jordens @ 2007-09-10 9:45 UTC (permalink / raw)
To: netdev
unsubscribe netdev
^ permalink raw reply
* Re: auto recycling of TIME_WAIT connections
From: Pádraig Brady @ 2007-09-10 10:26 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <46E18489.6060100@hp.com>
Rick Jones wrote:
>> The first issue, requires a large timeout, and
>> the TIME_WAIT timeout is currently 60 seconds on linux.
>> That timeout effectively limits the connection rate between
>> local TCP clients and a server to 32k/60s or around 500
>> connections/second.
>
> Actually, it would be more like 60k/60s if the application were making
> explicit calls to bind() as arguably it should if it is going to be
> churning through so many connections.
> This was an issue over a decade ago with SPECweb96 benchmarking. The
> initial solution was to make the explicit bind() calls and not rely on
> the anonymous/ephemeral port space. After that, one starts adding
> additional IP's into the mix (at least where possible). And if that
> fails, one has to go back to the beginning and ask oneself exactly why a
> client is trying to churn through so many connections per second in the
> first place.
right. This is for benchmarking mainly.
Sane applications would use persistent connections,
or a different form of IPC.
>
> If we were slavishly conformant to the RFC's :) that 60 seconds would be
> 240 seconds...
>
>> But that issue can't really happen when the client
>> and server are on the same machine can it, and
>> even if it could, the timeouts involved would be shorter.
>>
>> Now linux does have an (undocumented)
>> /proc/sys/net/ipv4/tcp_tw_recycle flag
>> to enable recycling of TIME_WAIT connections. This is global however
>> and could cause
>> problems in general for external connections.
>
> Rampant speculation begins...
>
> If the client can be convinced to just call shutdown(SHUT_RDWR) rather
> than close(), and be the first to do so, ahead of the server, I think it
> will retain a link to the TCP endpoint in TIME_WAIT. It could then, in
> TCP theory, call connect() again, and go through a path that allows
> transition from TIME_WAIT to ESTABLISHED if all the right things wrt
> Initial Sequence Number selection happen. Whether randomization of the
> ISN allows that today is questionable.
Sounds good, unfortunately connect() returns EISCONN
unless you do a close().
>
>> So how about auto enabling recycling for local connections?
>
> I think the standard response is that one can never _really_ know what
> is local and what not, particularly in the presence of netfilter and the
> rewriting of headers behind one's back.
Hmm, I was afraid someone would say that :)
thanks for the feedback,
Pádraig.
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Denys Vlasenko @ 2007-09-10 10:56 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linus Torvalds, Nick Piggin, Satyam Sharma, Herbert Xu,
Paul Mackerras, Christoph Lameter, Chris Snook, Ilpo Jarvinen,
Paul E. McKenney, Stefan Richter, Linux Kernel Mailing List,
linux-arch, Netdev, Andrew Morton, ak, heiko.carstens,
David Miller, schwidefsky, wensong, horms, wjiang, cfriesen,
zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <20070909191839.1fa10e88@laptopd505.fenrus.org>
On Sunday 09 September 2007 19:18, Arjan van de Ven wrote:
> On Sun, 9 Sep 2007 19:02:54 +0100
> Denys Vlasenko <vda.linux@googlemail.com> wrote:
>
> > Why is all this fixation on "volatile"? I don't think
> > people want "volatile" keyword per se, they want atomic_read(&x) to
> > _always_ compile into an memory-accessing instruction, not register
> > access.
>
> and ... why is that?
> is there any valid, non-buggy code sequence that makes that a
> reasonable requirement?
Well, if you insist on having it again:
Waiting for atomic value to be zero:
while (atomic_read(&x))
continue;
gcc may happily convert it into:
reg = atomic_read(&x);
while (reg)
continue;
Expecting every driver writer to remember that atomic_read is not in fact
a "read from memory" is naive. That won't happen. Face it, majority of
driver authors are a bit less talented than Ingo Molnar or Arjan van de Ven ;)
The name of the macro is saying that it's a read.
We are confusing users here.
It's doubly confusing that cpy_relax(), which says _nothing_ about barriers
in its name, is actually a barrier you need to insert here.
--
vda
^ permalink raw reply
* Re: [2/2] 2.6.23-rc5: known regressions with patches v2
From: Johannes Berg @ 2007-09-10 11:09 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Linus Torvalds, Andrew Morton, LKML, Pierre Ossman,
Christian Casteyde, Alan Stern, netdev, Florian Lohoff,
linux-wireless, Martin Langer, Stefano Brivio, Michael Buesch,
Danny van Dyk, Andreas Jaggi
In-Reply-To: <46E2836B.60406@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Sat, 2007-09-08 at 13:11 +0200, Michal Piotrowski wrote:
> Subject : Unable to access memory card reader anymore
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8885
> Last known good : ?
> Submitter : Christian Casteyde <casteyde.christian@free.fr>
> Caused-By : ?
> Handled-By : Alan Stern <stern@rowland.harvard.edu>
> Patch : http://bugzilla.kernel.org/attachment.cgi?id=12438
> Status : patch available
Last known good/caused-by doesn't apply, the bug has been in there ever
since the mac80211 code was merged into the tree.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [2/2] 2.6.23-rc5: known regressions with patches v2
From: Johannes Berg @ 2007-09-10 11:12 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Linus Torvalds, Andrew Morton, LKML, Pierre Ossman,
Christian Casteyde, Alan Stern, netdev, Florian Lohoff,
linux-wireless, Martin Langer, Stefano Brivio, Michael Buesch,
Danny van Dyk, Andreas Jaggi
In-Reply-To: <1189422562.4506.56.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Mon, 2007-09-10 at 13:09 +0200, Johannes Berg wrote:
> On Sat, 2007-09-08 at 13:11 +0200, Michal Piotrowski wrote:
>
> > Subject : Unable to access memory card reader anymore
> Last known good/caused-by doesn't apply, the bug has been in there ever
> since the mac80211 code was merged into the tree.
Eh, no, I quoted the wrong one by accident,
Subject : ifconfig eth1 - scheduling while atomic: ifconfig/0x00000002/4170
is the one I was thinking of.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures
From: Herbert Xu @ 2007-09-10 11:15 UTC (permalink / raw)
To: Denys Vlasenko
Cc: Arjan van de Ven, Linus Torvalds, Nick Piggin, Satyam Sharma,
Paul Mackerras, Christoph Lameter, Chris Snook, Ilpo Jarvinen,
Paul E. McKenney, Stefan Richter, Linux Kernel Mailing List,
linux-arch, Netdev, Andrew Morton, ak, heiko.carstens,
David Miller, schwidefsky, wensong, horms, wjiang, cfriesen,
zlynx, rpjday, jesper.juhl, segher
In-Reply-To: <200709101156.30010.vda.linux@googlemail.com>
On Mon, Sep 10, 2007 at 11:56:29AM +0100, Denys Vlasenko wrote:
>
> Expecting every driver writer to remember that atomic_read is not in fact
> a "read from memory" is naive. That won't happen. Face it, majority of
> driver authors are a bit less talented than Ingo Molnar or Arjan van de Ven ;)
> The name of the macro is saying that it's a read.
> We are confusing users here.
For driver authors who're too busy to learn the intricacies
of atomic operations, we have the plain old spin lock which
then lets you use normal data structures such as u32 safely.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] cfg80211: fix initialisation if built-in
From: Johannes Berg @ 2007-09-10 11:44 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev, Rob Hussey, stable
When cfg80211 is built into the kernel it needs to init earlier
so that device registrations are run after it has initialised.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-dev.orig/net/wireless/core.c 2007-09-10 13:00:18.567257487 +0200
+++ wireless-dev/net/wireless/core.c 2007-09-10 13:00:59.837219347 +0200
@@ -363,7 +363,7 @@ out_fail_notifier:
out_fail_sysfs:
return err;
}
-module_init(cfg80211_init);
+subsys_initcall(cfg80211_init);
static void cfg80211_exit(void)
{
^ 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