On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/s390/lib/Makefile b/arch/s390/lib/Makefile
> index 7a44fed..59aea65 100644
> --- a/arch/s390/lib/Makefile
> +++ b/arch/s390/lib/Makefile
> @@ -5,6 +5,6 @@
> EXTRA_AFLAGS := -traditional
>
> lib
Waskiewicz Jr, Peter P wrote:
>>This leaks the device. You treat every single-queue device as
>>having a single subqueue. If it doesn't get too ugly it would
>>be nice to avoid this and only allocate the subqueue states
>>for real multiqueue devices.
>
>
> We went back and forth on this. The
Stephen Hemminger wrote:
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index a260679..8a55276 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> if (unlikely(is_link_local(dest))) {
> skb->pkt_type = PACKET_HOST;
> - return NF_HOOK(
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:47:38 -0700
> attribute(weak) would give a nicer result?
>
> We'd also need to remove s390's EXPORT_SYMBOL(__div64_32), so s390 ends up
> using lib/div64.c's EXPORT_SYMBOL().
Ok, here is the version of the fix I'll use for now:
c
On Tue, Apr 10, 2007 at 11:25:59PM +0200, Jan Engelhardt wrote:
>
> Use menuconfigs instead of menus, so the whole menu can be disabled at
> once instead of going through all options.
>
> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
This seems to work fine to me.
Signed-off-by: Sim
Hi,
For some per-flow queue management work I need to access TCP port
numbers of an skb inside a qdisc (i.e. in qdisc enqueue and dequeue
functions). Can I assume that skb->data always points to the head of
the IP header of the packet? If that is the case will the following
statements do the tr
Rusty Russell wrote:
> On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote:
>
>> Moreover, some things just don't lend themselves to a userspace
>> abstraction. If we want to expose tso (tcp segmentation offload), we
>> can easily do so with a kernel driver since the kernel interfaces are
>>
On Mon, 2007-04-09 at 16:38 +0300, Avi Kivity wrote:
> Moreover, some things just don't lend themselves to a userspace
> abstraction. If we want to expose tso (tcp segmentation offload), we
> can easily do so with a kernel driver since the kernel interfaces are
> all tso aware. Tacking on tso
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:47:38 -0700
> On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Andrew Morton <[EMAIL PROTECTED]>
> > Date: Tue, 10 Apr 2007 18:29:37 -0700
> >
> > > git-net.patch implements generic li
On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 10 Apr 2007 18:29:37 -0700
>
> > git-net.patch implements generic lib/div64.c, but s390 also has a
> > private one. Presumably the appropriate fix is to remove
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:29:37 -0700
> git-net.patch implements generic lib/div64.c, but s390 also has a
> private one. Presumably the appropriate fix is to remove s390's
> private implementation within davem's tree.
The s390 version seems to be optimized
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 11 Apr 2007 02:42:59 +0200
> Hi Dave,
>
> Patrick McHardy wrote:
> > [SK_BUFF]: Fix missing offset adjustment in skb_copy_expand
> >
> > skb_copy_expand changes the headroom, so it needs to adjust the header
> > offsets by the difference betwe
On Tue, 10 Apr 2007 20:56:16 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> The last for today : link error of 2.6.21-rc6-mm1 for s390 :
>
>
>
> /opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld
> -m elf_s390 -e start -o .tmp_vmlinux1 -T arch/s39
On Tue, Apr 10, 2007 at 05:20:52PM -0500, Kim Phillips wrote:
> (note I'm coming from an embedded world here.)
Please read this:
http://marc.info/?l=linux-netdev&m=116527863300952&w=2
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL P
On Tue, Apr 10, 2007 at 04:57:23PM -0500, Kim Phillips wrote:
> also adds RX & TX delay bits to help boards with clock skew problems.
This doesn't make sense at all.
RGMII specifies that clock and data are generated simultaneously. The
necessary 1.5-2ns of clock delay is either achieved by rout
Hi Dave,
Patrick McHardy wrote:
> [SK_BUFF]: Fix missing offset adjustment in skb_copy_expand
>
> skb_copy_expand changes the headroom, so it needs to adjust the header
> offsets by the difference between the old and the new value.
it seems like you missed this one. Attached again for your conv
On Tue 10 Apr 2007 08:55, David Howells pondered:
> Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the
> latter case. I don't know that this is a problem; it depends on how things
> work, and that I don't know offhand. If someone can give me a simple test
> program, I would be
On Tue, 10 Apr 2007 14:41:01 -0400
David Hollis <[EMAIL PROTECTED]> wrote:
> I've been keeping an eye on PHYLIB since it's addition to the kernel
> some time ago and I'm a bit curious as to why it doesn't seem to have
> much up-take among other drivers. A quick check of the kernel source
> shows
Hi all; any love here? Maybe a pointer or two (e.g., what's the
equivalent, in the new emac driver, of these lines in the old driver:
emac_rxeob_dev((void *)ndev, 0);
emac_txeob_dev((void *)ndev, 0);
?)
---
I was having so many problems with the 2.6.14 (old) emac dr
Thomas Langås <[EMAIL PROTECTED]> :
[...]
> I found a driver [1] that I managed to patch into the linux 2.6.9-kernel,
> but upon booting the dreambox it doesn't detect the networkcard. I suspect
> it because of this (found inside the ne.c-file used by the dreambox):
>From a (very) quick sight at
From: Michael Barkowski <[EMAIL PROTECTED]>
The ICPlus IP175C sports a 100Mbit/s 5-port switch in addition
to a dedicated 100Mbit/s WAN port.
Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]>
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
please consider for 2.6.22
drivers/net/phy/Kconf
Distinguish between the Davicom DM9161A PHY and the DM9161E.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
please consider for 2.6.22
drivers/net/phy/davicom.c | 34 ++
1 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/davicom
also adds RX & TX delay bits to help boards with clock skew problems.
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
please consider for 2.6.22
drivers/net/phy/marvell.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drive
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
please consider for 2.6.22
drivers/net/ucc_geth.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 1b943e6..c9b1b28 100644
--- a/drivers/net/ucc_geth.c
+++ b/driver
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/drivers/net/Kconfig
===
--- linux-2.
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/drivers/net/tokenring/Kconfig
===
--
(No MAINTAINERS entry. MODULE_AUTHOR lines exist, but without addresses.)
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/drivers/net/phy/Kconfig
=
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/drivers/net/arcnet/Kconfig
==
Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.
Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/net/ipv4/ipvs/Kconfig
===
--- linux-
Sorry, now with the patches that follow...
-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Paolo Galtieri <[EMAIL PROTECTED]>
During the sctp_bindx() call to add additional addresses to the
endpoint, any v4mapped addresses are converted and stored as regular
v4 addresses. However, when trying to remove these addresses, the
v4mapped addresses are not converted and the operation fa
From: Tsutomu Fujii <[EMAIL PROTECTED]>
In current implementation, LKSCTP does receive buffer accounting for
data in sctp_receive_queue and pd_lobby. However, LKSCTP don't do
accounting for data in frag_list when data is fragmented. In addition,
LKSCTP doesn't do accounting for data in reasm and l
Hi Dave
Please consider applying the following two patches. They resolve some
interesting bugs.
Thanks
-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
As the merge window approaches I've made a decision about how to
handle the TCP RB-Tree work since it's getting really close.
First, I'm going to rebase the net-2.6.22 tree after making a quick
run through my patch backlog looking for low hanging fruit. I will
include the TCP write queue abstrac
I've been keeping an eye on PHYLIB since it's addition to the kernel
some time ago and I'm a bit curious as to why it doesn't seem to have
much up-take among other drivers. A quick check of the kernel source
shows only two users (AU1000 and gianfar) and both look to be embedded
type devices. Are
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 19:29:12 +0200
> Hi David
>
> Please find this patch against net-2.6.22
>
> Thank you
>
> [PATCH] NET : loopback driver can use loopback_dev integrated net_device_stats
>
> Rusty added a new 'stats' field to struct net_device.
>
>
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Mon, 9 Apr 2007 13:55:52 -0700
> Here is an update to bridging code for net-2.6.22
>
> The following changes since commit 532122caf3f7573760c5ec523bc3be14606bb8f2:
> Ilpo Järvinen (1):
> [TCP]: Simplify LOST marker code
>
> are found in
Add the Intel 5000 southbridge (aka Intel 6310/6311/6321ESB) PCIe ports
and the Intel E30x0 chipsets to the whitelist of aligned PCIe completion.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.c | 17 +
1 file changed, 17 insertions(+)
Index:
Update the myri10ge driver version number to 1.3.0-1.233.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-rc/drivers/net/myri10ge/myri10ge.c
=
Simpler way of dealing with the firmware 4KB boundary crossing
restriction for rx buffers. This fixes a variety of memory
corruption issues when using an "uncommon" MTU with a 16KB
page size.
Signed-off-by: Brice Goglin <[EMAIL PROTECTED]>
---
drivers/net/myri10ge/myri10ge.c | 19 -
Hi Jeff,
In case it is not too late for 2.6.21, here are 3 minor fixes for myri10ge:
1. fix management of the firmware 4KB boundary crossing restriction
2. more Intel chipsets providing aligned PCIe completions
3. update driver version to 1.3.0-1.233
Thanks,
Brice
-
To unsubscribe from this list
Hi Guennadi,
On Sat, Apr 07, 2007 at 03:59:26AM +0300, Samuel Ortiz wrote:
> IMHO, irnet_flow_indication() should be called asynchronously by
> irttp_run_tx_queue(), through some bottom-half mechanism. That would fix your
> locking issues, and that would reduce the time we spend in the IrDA code w
I've got an DVB-C-box called Dreambox DM500-C and it uses the
AX88796-chip for networking. They (Dream Multimedia, makers of the
Dreambox) has patched the NE2000-drivers in the kernel (ne.c), but only to
get it working. As a result it doesn't seem to be performing more than
20-30 Mbps.
I found a
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : loopback driver can use loopback_dev integrated net_device_stats
Rusty added a new 'stats' field to struct net_device.
loopback driver can use it instead of declaring another struct net_device_stats
This saves some memo
On Thu, Apr 05, Valerie Henson wrote:
> On Tue, Apr 03, 2007 at 11:19:16PM +0200, Olaf Hering wrote:
> > From: [EMAIL PROTECTED]
> >
> > https://bugzilla.novell.com/show_bug.cgi?id=SUSE39204
>
> Wow, registering for Novell's bugzilla is painful. And in the end I
> get "Access denied" on that b
> Peter P Waskiewicz Jr wrote:
> > + /* To retrieve statistics per subqueue - FOR FUTURE USE */
> > + struct net_device_stats* (*get_subqueue_stats)(struct
> net_device *dev,
> > + int
> queue_index);
>
>
> Please no future use stuff, just a
On Tue, Apr 10, 2007 at 08:41:49AM -0700, Waskiewicz Jr, Peter P ([EMAIL
PROTECTED]) wrote:
> > On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz
> > Jr ([EMAIL PROTECTED]) wrote:
> > > + alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
> > > +
> > > +
> On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz
> Jr ([EMAIL PROTECTED]) wrote:
> > + alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
> > +
> > + p = kzalloc(alloc_size, GFP_KERNEL);
> > + if (!p) {
> > + printk(KERN_ERR "alloc_netdev: Unable to
>
W Agtail wrote:
On Mon, 2007-04-09 at 11:11 -0700, Ben Greear wrote:
W Agtail wrote:
Nice one, but unfortunately still doesn't work.
I'm now not seeing any marked messages in /var/log/messages and traffic
still going via gw2 for port 8088.
Maybe you could use something like my m
On Tue, Apr 10, 2007 at 02:05:46PM +0200, Patrick McHardy wrote:
> So simply put: if I can implement support for
> "ip wireless add dev wlan0 mode managed essid ... key ..."
> in less than 100 lines and get a working connection afterwards, it
> seems worth it.
ACK
--
John W. Linville
[EMAIL PRO
On Tue, 2007-04-10 at 14:05 +0200, Patrick McHardy wrote:
>
> I know too little about wireless to judge really this. My opinion is
> that if it is possible to add and configure an interface (even if
> only for simple cases) without knowledge about driver internals by
> setting a few parameters, it
On Mon, 2007-04-09 at 11:11 -0700, Ben Greear wrote:
> W Agtail wrote:
> > Nice one, but unfortunately still doesn't work.
> > I'm now not seeing any marked messages in /var/log/messages and traffic
> > still going via gw2 for port 8088.
>
> Maybe you could use something like my mac-vlan virtual d
Robin Getz <[EMAIL PROTECTED]> wrote:
> David - I know you have been reworking the noMMU vma handling - is there a
> solution to vm_insert_page?
The reason vm_insert_page() is being called, I imagine, is because
packet_mmap() has to insert mappings to an already existing buffer. All it
does is
Evgeniy Polyakov wrote:
On Tue, Apr 10, 2007 at 03:17:45PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
Check a link please in case we are talking about different ideas:
http://marc.info/?l=linux-netdev&m=112262743505711&w=2
I don't really understand what you're testing there. in p
On Tue, Apr 10, 2007 at 03:17:45PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
> >Check a link please in case we are talking about different ideas:
> >http://marc.info/?l=linux-netdev&m=112262743505711&w=2
> >
> >
>
> I don't really understand what you're testing there. in particular, how
> c
Evgeniy Polyakov wrote:
This is what Xen does. It is actually less performant than copying, IIRC.
The problem with flipping pages around is that physical addresses are
cached both in the kvm mmu and in the on-chip tlbs, necessitating
expensive page table walks and tlb invalidation IPIs.
Johannes Berg wrote:
> Fair enough. Then the question however remains whether wireless should
> try to do all things it needs in one or try leveraging multiple things
> from other places. Thoughts?
I know too little about wireless to judge really this. My opinion is
that if it is possible to add
On Tue, Apr 10, 2007 at 02:21:24PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
> >You want to implement zero-copy network device between host and guest, if
> >I understood this thread correctly?
> >So, for sending part, device allocates pages from receiver's memory (or
> >from shared memory), rece
On Tue, 2007-04-10 at 13:09 +0200, Patrick McHardy wrote:
> I know :) It was a few month ago when I noticed the new bonding
> sysfs interface when I first thought that we really need this.
:)
> > I don't think wireless can get away without a new tool. So much stuff
> > there. Look at
> > http://
Evgeniy Polyakov wrote:
But it looks from this discussion, that it will not prevent from
changing in-kernel driver - place a hook into skb allocation path and
allocate data from opposing memory - get pages from another side and put
them into fragments, then copy headers into skb->data.
Patrick McHardy wrote:
Maybe not wireless, but bonding, briding, vlan, etun, possibly more.
[if I understand you correctly] I agree. With ethtool, the idea is to
have a single tool that supports multiple hardware platforms -- even to
the point of introducing hardware-specific code into ethto
Johannes Berg wrote:
> On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
>
>
>>The main advantage that we don't get more weird sysfs/proc/ioctl based
>>interfaces
>
>
> Please don't put me into a corner I don't want to be in ;) The new
> wireless stuff was completely designed using netl
Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> wrote:
>
>> >@@ -3356,6 +3370,7 @@ void free_netdev(struct net_device *dev)
>> > /* will free via device release */
>> > put_device(&dev->dev);
>> > #else
>> >+kfree((char *)dev->egress_subqueue);
>> > kfree((char *)dev - dev->padded);
>> >
On Tue, 2007-04-10 at 12:46 +0200, Patrick McHardy wrote:
> Not totally different, so far I think we should use the same attributes
> as for RTM_SETLINK messages and include the device-specific stuff in
> IFLA_PROTINFO, which is symetric to what the kernel sends in RTM_NETLINK
> messages (see br_n
Johannes Berg wrote:
> On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
>
>
>>Without having thought much about it yet, roughly like this:
>>
>>- driver receives RTM_NEWLINK message (under rtnl)
>>- driver allocates new device
>>- driver initializes device based on content of RTM_NEWLINK
On Tue, 2007-04-10 at 11:52 +0200, Patrick McHardy wrote:
> Without having thought much about it yet, roughly like this:
>
> - driver receives RTM_NEWLINK message (under rtnl)
> - driver allocates new device
> - driver initializes device based on content of RTM_NEWLINK message
> - driver returns
Johannes Berg wrote:
> On Tue, 2007-04-10 at 09:52 +0200, Patrick McHardy wrote:
>
>
>>Shouldn't be a problem either. Creating the device atomically also
>>prevents that anything else is setting them UP before they're fully
>>configured.
>
>
> How would you do it generically then? I'm absolutel
Peter P Waskiewicz Jr wrote:
> + /* To retrieve statistics per subqueue - FOR FUTURE USE */
> + struct net_device_stats* (*get_subqueue_stats)(struct net_device *dev,
> + int queue_index);
Please no future use stuff, just add it when you
On Tue, 2007-04-10 at 09:52 +0200, Patrick McHardy wrote:
> Shouldn't be a problem either. Creating the device atomically also
> prevents that anything else is setting them UP before they're fully
> configured.
How would you do it generically then? I'm absolutely not opposed to the
idea but for n
Waskiewicz Jr, Peter P wrote:
> Thanks Pat for the initial feedback. I can post a set of patches to
> e1000 using the new API; I'll try to get them out asap (need to apply to
> this kernel tree).
Thanks.
> However, the PRIO qdisc still uses the priority in
> the bands for dequeueing priority, a
On Tue, Apr 10, 2007 at 11:19:52AM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
> I meant, network aio in the mainline kernel. I am aware of the various
> out-of-tree implementations.
If potential users do not pay attention to initial implementaion, it is
quite hard to them to get into. But actua
Evgeniy Polyakov wrote:
> On Mon, Apr 09, 2007 at 04:38:18PM +0300, Avi Kivity ([EMAIL PROTECTED])
> wrote:
>
>>> But I don't get this "we can enhance the kernel but not userspace" vibe
>>> 8(
>>>
>>>
>> I've been waiting for network aio since ~2003. If it arrives in the
>> next few
On Mon, Apr 09, 2007 at 02:28:41PM -0700, Peter P Waskiewicz Jr ([EMAIL
PROTECTED]) wrote:
> + alloc_size = (sizeof(struct net_device_subqueue) * queue_count);
> +
> + p = kzalloc(alloc_size, GFP_KERNEL);
> + if (!p) {
> + printk(KERN_ERR "alloc_netdev: Unable to allocate
On Mon, Apr 09, 2007 at 04:38:18PM +0300, Avi Kivity ([EMAIL PROTECTED]) wrote:
> >But I don't get this "we can enhance the kernel but not userspace" vibe
> >8(
> >
>
> I've been waiting for network aio since ~2003. If it arrives in the
> next few days, I'm all for it; much more than kvm can u
Johannes Berg wrote:
> Our virtual devices are always associated with a piece of hardware, and
> we really want them to be associated with that at all times, even when
> not UP. Everything else seems like a huge complication if only because
> then we can't have whoever will be responsible for the d
75 matches
Mail list logo
