* Jeff Garzik ([EMAIL PROTECTED]) wrote:
> Jay Vosburgh wrote:
> > The following patch (based on a patch from Stephen Hemminger
> ><[EMAIL PROTECTED]>) removes use after free conditions in
> >the unregister path for the bonding master. Without this patch, an
> >operation of the form "echo -bon
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/bonding/bond_3ad.c |9 +--
drivers/net/bonding/bond_main.c |2 +-
drivers/net/bonding/bond_sysfs.c |2 +-
d
[EMAIL PROTECTED] wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
eth_type_trans() now sets skb->dev.
References to skb->dev should happen after it is called.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/sge.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Tim Mann wrote:
I happened to notice that a system with an NVidia NIC using the
forcedeth driver won't wake-on-LAN if the interface was in promiscuous
mode when you power off. By experiment, it looks like
the hardware needs to have NvRegPacketFilterFlags set to
NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR
Jay Vosburgh wrote:
The following patch (based on a patch from Stephen Hemminger
<[EMAIL PROTECTED]>) removes use after free conditions in
the unregister path for the bonding master. Without this patch, an
operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
would trigger
Frank Pavlic wrote:
From: Ursula Braun <[EMAIL PROTECTED]>
For real HiperSockets the EBCDIC-ASCII conversion is not necessary.
This is only needed for z/VM GuestLAN devices.
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/qet
Jay Vosburgh wrote:
Modify carrier state determination for 802.3ad mode to comply
with section 43.3.9 of IEEE 802.3, which requires that "Links that are
not successful candidates for aggregation (e.g., links that are attached
to other devices that cannot perform aggregation or links that
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Wed, 20 Jun 2007 16:58:43 +0200
> to me it seems that this patch set only include multiple transmit
> queue support (for qdisc). Am I right with this observation? If so,
> are there also plans to support multiple receive queues to allow the
> queue
David Gundersen <[EMAIL PROTECTED]> :
[...]
> - Why are you checking dirty_tx against cur_rx (shouldn't it be cur_tx?)?
Usual "try something, send something else" bug.
> - Is there a possibility that the driver could be triggering the card to
> send invalid packets with that code?
[snip]
I do n
On 6/19/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
David Miller wrote:
> This is actually a real issue for virtualization, and many
> if not all current generation ethernet chips support
> programming several unicast ethernet addresses in the MAC.
>
> Networking switches in domain0 on virtualizat
On 06/20/2007 02:27 PM, Sushant wrote:
Sushant, you should be sending this kind of message to netdev.
[cc'd]
> Hi all,
> I am currently doing some analysis on the TCP newReno implementation
> in the Linux kernel and it looks like the sender behavior is not
> expected. Here is what I am observing.
[E1000]: Secondary unicast address support
Add support for configuring secondary unicast addresses. Unicast
addresses take precendece over multicast addresses when filling
the exact address filters to avoid going to promiscous mode.
When more unicast addresses are present than filter slots,
unicas
These two patches contain a first short at secondary unicast address support.
I'm still working on converting macvlan as an example, but since I'm about to
leave for tonight I thougth I'd get them out for some comments now.
The patch adds two new functions dev_unicast_add and dev_unicast_delete to
[NETDEV]: Secondary unicast address support
Add support for configuring secondary unicast addresses on network devices.
Devices supporting this feature need to change their set_multicast_list
function to configure unicast filters as well and assign it to
dev->set_address_list instead of dev->set_m
> to me it seems that this patch set only include multiple
> transmit queue support (for qdisc). Am I right with this
> observation? If so, are there also plans to support multiple
> receive queues to allow the queues to be processed in
> parallel on different CPUs via a standard interface?
>
> On Wed, 20 Jun 2007 03:56:28 -0700 (PDT) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8654
>
>Summary: possible connect() bug
>Product: Networking
>Version: 2.5
> KernelVersion: Linux version 2.6.21.1 ([EMAIL PROTECTED]) (gcc
>
Stephens, Allan <[EMAIL PROTECTED]> wrote:
[removed tipc-discussion list from CC]
> Patrick McHardy wrote:
> > Florian Westphal wrote:
> > > - genlmsg_unicast(rep_buf, req_nlh->nlmsg_pid);
> > > + genlmsg_unicast(rep_buf, NETLINK_CB(skb).pid);
> >
> >
> > This is the second time w
Hi,
to me it seems that this patch set only include multiple transmit queue support
(for qdisc). Am I right with this observation? If so, are there also plans to
support multiple receive queues to allow the queues to be processed in parallel
on different CPUs via a standard interface? Currently,
Patrick McHardy wrote:
> Florian Westphal wrote:
> > From: Florian Westphal <[EMAIL PROTECTED]>
> >
> > The tipc netlink config handler uses the nlmsg_pid from the request
> > header as destination for its reply. If the application initialized
> > nlmsg_pid to 0, the reply is looped back to th
On 18/06/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
On Sun, 17 Jun 2007 16:24:00 +0200
Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc5
> with patches available.
>
> Feel free to add new regressions/remove fixed etc.
> http:/
Hi,
I have kind of a difficult problem with my USB network adapter. It used
to work using kernel 2.6.20.3, more or less, I needed to insert and
remove the network cable from the device frequently to get it working,
but then, at least, it worked.
Now, using 2.6.22-rc2 it's not working anymore, at
The mppe_decompress() function required a buffer that is 1 byte too small when
receiving a message of mru size. This fixes buffer allocation to prevent this
from occurring.
Signed-off-by: Konstantin Sharlaimov <[EMAIL PROTECTED]>
---
As Sergey Vlasov pointed out,
ppp_mppe-account-for-osize-too-sm
[took off acpi list]
On Tue, 2007-06-19 at 12:20 -0400, jamal wrote:
> There is one default mcast group per entity. Most users only need that
> one.
Ok. That's definitely a bug in nl80211 as we have it in development
right now. Btw, what happens if the group id gets larger than 31?
> If you nee
Hi,
Is there a chance that this, or a patch with similar spirit (e.g. a way
to send packets from non-local IP addresses) could be merged?
On Fri, 2007-06-01 at 02:18 +0300, Julian Anastasov wrote:
> Hello,
>
> On Thu, 31 May 2007, KOVACS Krisztian wrote:
>
> > So what about this one?
>
From: Martin Schwidefsky <[EMAIL PROTECTED]>
The recent iucv rework patches re-introduced some unnecessary inlines.
Remove them again.
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---
drivers/s390/net/netiucv.c | 18 +++---
1
From: Thomas Gleixner <[EMAIL PROTECTED]>
spinlock initializer cleanup in netiucv.c
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/netiucv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/
From: Ursula Braun <[EMAIL PROTECTED]>
ipv6_regen_rndid in net/ipv6/addrconf.c makes use of "write_lock_bh"
for its inet6_dev->lock. It may run in softirq-context.
qeth makes use of "read_lock" for the same inet6_dev->lock.
To avoid a potential deadlock situation, qeth should make use of
"read_loc
From: Ursula Braun <[EMAIL PROTECTED]>
net/iucv/iucv.c creates the requirement for
iucv_path_connect not to be called from tasklet context anymore.
An extra checking is added in case of a failing netiucv_tx
to fulfil this requirement for netiucv.
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
Si
From: Cornelia Huck <[EMAIL PROTECTED]>
Use ccw_device_get_id() to get a device number
instead of parsing the ccw device's bus id.
Signed-off-by: Cornelia Huck <[EMAIL PROTECTED]>
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/claw.c | 13 -
drivers/s390
From: Frank Pavlic <[EMAIL PROTECTED]>
Packets Length in qdio header is broken when using
EDDP on Layer2 devices. This leads to skb_under_panic on receiver
system when running on z/VM GuestLAN devices.
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth_eddp.c |3 +--
1
From: Ursula Braun <[EMAIL PROTECTED]>
For real HiperSockets the EBCDIC-ASCII conversion is not necessary.
This is only needed for z/VM GuestLAN devices.
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth_main.c | 20 ++
From: Ursula Braun <[EMAIL PROTECTED]>
While first recovery continues, the card issues
a STARTLAN command itself. In this case qeth
schedules another recovery. This second
recovery is cancelled because of an already running first recovery.
Stop first recovery in case of 0xe080.
Signed-off-by: U
Hi Jeff,
following eight patches are all fixes for s390 network
device driver qeth, claw and netiucv.
I would be glad to see them going into 2.6.22 although
I know it is quite late .
Thank you.
Frank
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 8f3e0da..8c0851f 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2682,6 +2688,8 @@ static void rtl8169_tx_interrupt(struct net_device *dev,
(TX_BUFFS_AVAIL(tp) >= MAX_SKB_FRAGS)) {
On Tue, 2007-06-19 at 20:38 -0700, Vernon Mauery wrote:
> On Monday 18 June 2007 10:12:21 pm Vernon Mauery wrote:
> > In looking at the performance characteristics of my network I found that
> > 2.6.21.5-rt15 suffers from degraded thoughput with multiple threads. The
> > test that I did this with
35 matches
Mail list logo
