On Wed, Oct 17, 2007 at 08:28:36PM -0400, Jeff Garzik wrote:
Badari Pulavarty wrote:
Simple compile warning fix. (against 2.6.23-git12)
Thanks,
Badari
vortex_up() should initialize 'err' for a successful return.
drivers/net/3c59x.c: In function `vortex_up':
drivers/net/3c59x.c:1494:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 17 Oct 2007 13:21:31 -0700
I propose that we take out all the whole netpoll rx path. If/when
kgdb gets submitted a better and alternative receive path can be
added.
I would like to kill the RX side handling of netpoll too,
but I don't think
From: Jeff Garzik [EMAIL PROTECTED]
Date: Tue, 16 Oct 2007 17:55:55 -0400
While looking at a net driver with the following construct,
if (!netif_carrier_ok(dev))
netif_carrier_on(dev);
it stuck me that the netif_carrier_ok() check was redundant, since
On Wed, Oct 17, 2007 at 10:58:09AM +0200, Jarek Poplawski wrote:
...
8) phy_stop_interrupts(): I'm not sure this additional call from
DEBUG_SHIRQ should be so dangerous, eg.:
/*
* status == PHY_HALTED
* interrupts are stopped after phy_stop()
*/
if
On Wed, 17 Oct 2007 23:28:38 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 17 Oct 2007 13:21:31 -0700
I propose that we take out all the whole netpoll rx path. If/when
kgdb gets submitted a better and alternative receive path can be
After reading this and earlier threads about phylib's way of using
workqueue I think such a lighter and safer wrt. locking alternative
for flush_scheduled_work should be useful, but maybe it's only my
imagination.
So, let's ask Oleg Nesterov, whose solutions are here only
copy-cut-pasted
On Thu, 18 Oct 2007 08:05:06 +0200 Steffen Klassert [EMAIL PROTECTED] wrote:
On Wed, Oct 17, 2007 at 08:28:36PM -0400, Jeff Garzik wrote:
Badari Pulavarty wrote:
Simple compile warning fix. (against 2.6.23-git12)
Thanks,
Badari
vortex_up() should initialize 'err' for a successful
On Wed, Oct 17, 2007 at 11:02:57AM -0700, Stephen Hemminger wrote:
The tagging naming convention is messed up, but they are there:
$ git tag -l
I don't want to be a pain in the ass, but
this is the list from my clone of
Seems we are getting some kind of bug out of our s390x partition (lnxabat1)
when booting latest mainline releases, specifically since 2.6.23-git3.
Kernel BUG at 0002 Ýverbose debug info unavailable¨
illegal operation: 0001 Ý#1¨
Modules linked in: dm_mod sit tunnel4 ipv6 qeth ccwgroup
On Thu, 18 Oct 2007, TAKANO Ryousei wrote:
From: David Miller [EMAIL PROTECTED]
Subject: Re: [PATCH 7/7] [TCP]: Limit processing lost_retrans loop to
work-to-do cases
Date: Thu, 11 Oct 2007 17:36:22 -0700 (PDT)
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 11 Oct 2007 14:41:07 +0300
The check then is to see if a non {}'d block has no statements in it if the
ifdef is null. Hmmm. May be possible. Will think on it.
if (err)
+#ifdef CONFIG_GFAR_NAPI
napi_disable(priv-napi);
+#endif
-apw
-
To unsubscribe from this list: send the line unsubscribe netdev
the packet trace was a bit too cooked perhaps, but there were indications
that at times the TCP window was going to zero - perhaps something with
window updates or persist timers?
Does TCP use different window sizes on loopback? Why is this not
happening on ethernet?
How could I test this
Hi,
these patches convert more cases of array size calculations to use the
ARRAY_SIZE() macro.
First patch converts those of the form 'sizeof(arr) / ETH_GSTRING_LEN',
second one some other mostly obvious cases, and the third applies to the
almost dead sk98lin driver (which also removes a useless
Andy Whitcroft wrote:
Seems we are getting some kind of bug out of our s390x partition (lnxabat1)
when booting latest mainline releases, specifically since 2.6.23-git3.
Kernel BUG at 0002 Ýverbose debug info unavailable?
illegal operation: 0001 Ý#1?
Modules linked in: dm_mod sit
From: Alejandro Martinez Ruiz [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 10:00:15 +0200
Subject: [PATCH] netdev: use ARRAY_SIZE() instead of sizeof(array) /
ETH_GSTRING_LEN
Using ARRAY_SIZE() on arrays of the form array[][K] makes it unnecessary
to know the value of K when checking its size.
From: Alejandro Martinez Ruiz [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 10:16:33 +0200
Subject: [PATCH] netdev: ARRAY_SIZE() cleanups
Convert array size calculations to use ARRAY_SIZE().
Signed-off-by: Alejandro Martinez Ruiz [EMAIL PROTECTED]
---
drivers/net/e1000e/ethtool.c |3 +--
From: Alejandro Martinez Ruiz [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 10:22:02 +0200
Subject: [PATCH] sk98lin: kill bogus check and convert to use ARRAY_SIZE()
This converts uses of ARRAY_SIZE(), and while at it also kills
unreachable code as far as I can say. I can't tell what was the author
Andrew Morton wrote:
On Wed, 17 Oct 2007 07:36:16 -0700 (PDT)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9174
Summary: linux-2.6.23-git11 kernel panic
EIP is at packet_rcv_0x1a2/0x360
Please find out on which device the packet socket is opened by
Interface groups let handle different interfaces together
especially in netfilter modules.
Modified net device structure and netlink interface.
Signed-off-by: Laszlo Attila Toth [EMAIL PROTECTED]
---
include/linux/if_link.h |2 ++
include/linux/netdevice.h |2 ++
net/core/rtnetlink.c
Interfaces can be grouped and each group has an unique positive integer ID.
It can be set via ip link. Symbolic names can be specified in
/etc/iproute2/rt_ifgroup.
Signed-off-by: Laszlo Attila Toth [EMAIL PROTECTED]
---
include/linux/if_link.h |2 +
include/rt_names.h |2 +
Matching ifgroup value of incoming and/or outgoing interface.
Signed-off-by: Laszlo Attila Toth [EMAIL PROTECTED]
---
extensions/Makefile |2 +-
extensions/libip6t_ifgroup.man | 36 +++
extensions/libipt_ifgroup.man| 36 +++
Hello,
Here is the new version of ifgroup patches.
The interface group value is u_int32_t in net_device which should be enough.
Previously it was an int.
Usage:
ip link set eth0 group 4
but currently it cannot be unset, only changed to another value.
In /etc/iproute2/rt_ifgroup each value
Interface group values can be checked on both input and output interfaces.
Signed-off-by: Laszlo Attila Toth [EMAIL PROTECTED]
---
include/linux/netfilter/xt_ifgroup.h | 18 ++
net/netfilter/Kconfig| 16 +
net/netfilter/Makefile |1 +
On Thu, 18 Oct 2007, Ilpo Järvinen wrote:
On Thu, 18 Oct 2007, TAKANO Ryousei wrote:
From: David Miller [EMAIL PROTECTED]
Subject: Re: [PATCH 7/7] [TCP]: Limit processing lost_retrans loop to
work-to-do cases
Date: Thu, 11 Oct 2007 17:36:22 -0700 (PDT)
From: Ilpo_Järvinen [EMAIL
Laszlo Attila Toth wrote:
Hello,
Here is the new version of ifgroup patches.
The interface group value is u_int32_t in net_device which should be enough.
Previously it was an int.
Usage:
ip link set eth0 group 4
but currently it cannot be unset, only changed to another value.
The only
Laszlo Attila Toth wrote:
@@ -846,6 +850,12 @@ static int do_setlink(struct net_device *dev, struct
ifinfomsg *ifm,
write_unlock_bh(dev_base_lock);
}
+ if (tb[IFLA_IFGROUP]) {
+ write_lock_bh(dev_base_lock);
+ dev-ifgroup =
Laszlo Attila Toth wrote:
Interface group values can be checked on both input and output interfaces.
Signed-off-by: Laszlo Attila Toth [EMAIL PROTECTED]
---
include/linux/netfilter/xt_ifgroup.h | 18 ++
net/netfilter/Kconfig| 16 +
net/netfilter/Makefile
On Wed, 17 Oct 2007, Stephen Hemminger wrote:
On Thu, 18 Oct 2007 00:31:13 +0200 (CEST)
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
On Wed, 17 Oct 2007, Stephen Hemminger wrote:
On Wed, 17 Oct 2007 23:15:48 +0200 (CEST)
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Hello,
Is it normal
On Thu, 2007-10-18 at 11:43 +0200, Patrick McHardy wrote:
Andy Whitcroft wrote:
Seems we are getting some kind of bug out of our s390x partition (lnxabat1)
when booting latest mainline releases, specifically since 2.6.23-git3.
Kernel BUG at 0002 Ýverbose debug info
Since commit 1706d58763c36133d7fce6cc78b1444fd40db28c ip_frag_reasm()
can return the value of an uninitialized variable:
-- snip --
...
static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
struct net_device *dev)
{
struct iphdr *iph;
struct
From: Ilpo Järvinen [EMAIL PROTECTED]
Subject: [PATCH] [TCP]: Remove lost_retrans zero special cases
Date: Thu, 18 Oct 2007 13:17:24 +0300 (EEST)
[PATCH] [TCP]: Remove lost_retrans zero seqno special cases
Both high-sack detection and new lowest seq variables have
unnecessary zero special
Patrick McHardy wrote:
Andrew Morton wrote:
On Wed, 17 Oct 2007 07:36:16 -0700 (PDT)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9174
Summary: linux-2.6.23-git11 kernel panic
EIP is at packet_rcv_0x1a2/0x360
Please find out on which device the
On Thu, 18 Oct 2007, TAKANO Ryousei wrote:
From: Ilpo Järvinen [EMAIL PROTECTED]
Subject: [PATCH] [TCP]: Remove lost_retrans zero special cases
Date: Thu, 18 Oct 2007 13:17:24 +0300 (EEST)
[PATCH] [TCP]: Remove lost_retrans zero seqno special cases
Both high-sack detection and new
On Wed, 17 Oct 2007, Eric Dumazet wrote:
Krzysztof Oledzki a écrit :
On Wed, 17 Oct 2007, Eric Dumazet wrote:
Krzysztof Oledzki a écrit :
On Wed, 17 Oct 2007, Eric Dumazet wrote:
Krzysztof Oledzki a écrit :
Hello,
Today I found in my logs:
BUG: unable to handle kernel NULL
Patrick McHardy írta:
Laszlo Attila Toth wrote:
Hello,
Here is the new version of ifgroup patches.
The interface group value is u_int32_t in net_device which should be
enough.
Previously it was an int.
Usage:
ip link set eth0 group 4
but currently it cannot be unset, only changed to
On Thu, 18 Oct 2007, Jarek Poplawski wrote:
After rethinking, it looks like this last cancel should be useless.
So, if phy_interrupt() schedules only if !PHY_HALTED and phy_change()
does enable_irq() with no exeptions, it seems phy_interrupt() even
without lock must see PHY_HALTED state
Laszlo Attila Toth wrote:
Patrick McHardy írta:
Laszlo Attila Toth wrote:
The only reason why it can't be set to zero again seems to
be this part from the iproute patch:
+if (rtnl_ifgroup_a2n(group, *argv) || group == 0)
Why don't you allow a value of zero?
It has historical
Krzysztof Oledzki wrote:
Hum, you are using IPT_TPROXY thing, which is not in linux-2.6.22.9
It is only compiled in, not used at the moment.
But at least the previous version (before those patches posted a week
ago) touches the routing code in exactly that function.
-
To unsubscribe from
From: Adrian Bunk [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 12:52:03 +0200
Since commit 1706d58763c36133d7fce6cc78b1444fd40db28c ip_frag_reasm()
can return the value of an uninitialized variable:
I have a fix for this in my net-2.6 tree, thanks Adrian.
-
To unsubscribe from this list: send the
On Wed, 17 Oct 2007, Jarek Poplawski wrote:
I'm not sure free_irq() should maintain the depth count - rather warn
on not zero. But, IMHO, any activity on freed irq seems suspicious to
me (and doesn't look like very common), even if it's safe with current
implementation.
No way to avoid it
This routine scans the ipv6_fl_list whose update is
protected with the socket lock and the ip6_sk_fl_lock.
Since the socket lock is not taken in the lookup, use
the other one.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
In the IPV6_FL_A_GET case the hash is checked for flowlabels
with the given label. If it is not found, the lock, protecting
the hash, is dropped to be re-get for writing. After this a
newly allocated entry is inserted, but no checks are performed
to catch a classical SMP race, when the
In article [EMAIL PROTECTED] (at Thu, 18 Oct 2007 15:53:52 +0400), Pavel
Emelyanov [EMAIL PROTECTED] says:
This routine scans the ipv6_fl_list whose update is
protected with the socket lock and the ip6_sk_fl_lock.
struct ip6_flowlabel *fl = sfl-fl;
if (fl-label
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 14:07:42 +0300 (EEST)
Dave, please put this one to net-2.6 and forget the other patch with
title [TCP]: Add highest_sack_end_seq check back..., it would just
add another (wrong) zero special case back (they won't conflict with
each
From: Patrick McHardy [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 12:58:42 +0200
Patrick McHardy wrote:
Andrew Morton wrote:
On Wed, 17 Oct 2007 07:36:16 -0700 (PDT)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9174
Summary: linux-2.6.23-git11 kernel
YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Thu, 18 Oct 2007 15:53:52 +0400), Pavel
Emelyanov [EMAIL PROTECTED] says:
This routine scans the ipv6_fl_list whose update is
protected with the socket lock and the ip6_sk_fl_lock.
struct ip6_flowlabel *fl = sfl-fl;
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 16:11:58 +0400
YOSHIFUJI Hideaki wrote:
In article [EMAIL PROTECTED] (at Thu, 18 Oct 2007 15:53:52 +0400), Pavel
Emelyanov [EMAIL PROTECTED] says:
This routine scans the ipv6_fl_list whose update is
protected with the
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 15:51:41 +0400
The new flowlabels should be inserted into the sock list
under the ip6_sk_fl_lock. This was lost in one place.
This list is naturally protected with the socket lock, but
the fl6_sock_lookup() is called without it,
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 15:53:52 +0400
This routine scans the ipv6_fl_list whose update is
protected with the socket lock and the ip6_sk_fl_lock.
Since the socket lock is not taken in the lookup, use
the other one.
Signed-off-by: Pavel Emelyanov
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 15:59:14 +0400
In the IPV6_FL_A_GET case the hash is checked for flowlabels
with the given label. If it is not found, the lock, protecting
the hash, is dropped to be re-get for writing. After this a
newly allocated entry is
The new flowlabels should be inserted into the sock list
under the ip6_sk_fl_lock. This was lost in one place.
This list is naturally protected with the socket lock, but
the fl6_sock_lookup() is called without it, so another
protection is required.
Signed-off-by: Pavel Emelyanov [EMAIL
David Miller wrote:
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 15:53:52 +0400
This routine scans the ipv6_fl_list whose update is
protected with the socket lock and the ip6_sk_fl_lock.
Since the socket lock is not taken in the lookup, use
the other one.
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 16:22:49 +0400
Oops. You're right here :( I looked at the ip6_fl_lock
and messed it with the ip6_sk_fl_lock.
Should I resend the whole patch, or just make an
incremental one?
Please make an incremental one.
And hurry, I'm
YOSHIFUJI fairly pointed out, that the users increment should
be done under the ip6_sk_fl_lock not to give IPV6_FL_A_PUT a
chance to put this count to zero and release the flowlabel.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Cc: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
diff --git
From: Pavel Emelyanov [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 16:36:58 +0400
YOSHIFUJI fairly pointed out, that the users increment should
be done under the ip6_sk_fl_lock not to give IPV6_FL_A_PUT a
chance to put this count to zero and release the flowlabel.
Signed-off-by: Pavel Emelyanov
Hi all,
Sorry, I don't know if this is the right mail list. I got the
following question:
I have a e100 card and a e1000 card. Whenever I boot the system, I
found the eth0 matches the e1000 card, and the eth2 matches the other.
How can I force the eth0 to match the e100 card and the eth2 to
On Thu, 18 Oct 2007, Patrick McHardy wrote:
Krzysztof Oledzki wrote:
Hum, you are using IPT_TPROXY thing, which is not in linux-2.6.22.9
It is only compiled in, not used at the moment.
But at least the previous version (before those patches posted a week
ago) touches the routing code in
On Thu, Oct 18, 2007 at 09:06:40PM +0800, wit ([EMAIL PROTECTED]) wrote:
Hi all,
Sorry, I don't know if this is the right mail list. I got the
following question:
I have a e100 card and a e1000 card. Whenever I boot the system, I
found the eth0 matches the e1000 card, and the eth2
On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Domen Puncer wrote:
Hello!
If there are no objections, I would like to get this merged
when bestcomm goes in (any time now?).
It's split into four parts:
1 - device tree
2 - small bestcomm change
3 - the actual driver
4 - phy
-Original Message-
From: Joakim Tjernlund [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 5:06 PM
To: Netdev; Li Yang-r58472
Subject: [PATCH] Fix ethernet multicast for ucc_geth.
From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17
00:00:00 2001
From: Joakim
Hi!
There is a justifying patch for Stephen's patches. Stephen's patches
disallows using a port range of one single port and brakes the meaning
of the 'remaining' variable, in some places it has different meaning.
My patch gives back the sense of 'remaining' variable. It should mean how
many
On Thu, 18 Oct 2007, Jarek Poplawski wrote:
Technically until free_irq returns a handler should respond to calls
and with proper hardware it should have no problem with checking if
it's its interrupt, even after disabling this hardware, because of
possible races.
Well, the hardirq handler
On Thu, 18 Oct 2007 16:27:37 +0200
Anton Arapov [EMAIL PROTECTED] wrote:
Hi!
There is a justifying patch for Stephen's patches. Stephen's patches
disallows using a port range of one single port and brakes the meaning
of the 'remaining' variable, in some places it has different meaning.
On 10/18, Jarek Poplawski wrote:
+/**
+ * flush_work_sync - block until a work_struct's callback has terminated
^^^
Hmm...
+ * Similar to cancel_work_sync() but will only busy wait (without cancel)
+ * if the work is
On Thu, 18 Oct 2007, Oleg Nesterov wrote:
If we can't just cancel the work, can't we do something like
if (cancel_work_sync(w))
w-func(w);
instead?
We do an equivalent of this -- all that we care about that w-func(w)
would do is enable_irq() and the rest we want to
[PACKET]: Kill unused pg_vec_endpage() function
The conversion to vm_insert_page() left this unused function behind,
remove it.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e11000a..d093650 100644
---
Vlad Yasevich wrote:
We've been trying to field some questions regarding multicast
behavior and one such behavior has stumped us.
I've reproduced the following behavior on 2.6.23.
The application opens 2 sockets. One socket is the receiver
and it simply binds to 0.0.0.0:2000 and joins a
Matthew Faulkner wrote:
Hey all
I'm using netperf to perform TCP throughput tests via the localhost
interface. This is being done on a SMP machine. I'm forcing the
netperf server and client to run on the same core. However, for any
packet sizes below 523 the throughput is much lower compared to
Felix von Leitner wrote:
the packet trace was a bit too cooked perhaps, but there were indications
that at times the TCP window was going to zero - perhaps something with
window updates or persist timers?
Does TCP use different window sizes on loopback? Why is this not
happening on
It appears that the needed e100 fix made it into the Fedora
2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
Dave
-Original Message-
From: Kok, Auke [mailto:[EMAIL PROTECTED]
Sent: Friday, October 12, 2007 10:05 AM
To: Herbert Xu
Cc: David Mack; Dave
David Mack wrote:
It appears that the needed e100 fix made it into the Fedora
2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now works?
Auke
Dave
-Original Message-
From: Kok, Auke
On 10/18/2007 01:59 PM, Kok, Auke wrote:
David Mack wrote:
It appears that the needed e100 fix made it into the Fedora
2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now works?
We didn't put
Prefix dprintk with KERN_DEBUG
Fix a bug with existing use of dprintk (PFX KERN_INFO PFX)
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 419c00c..9c11087 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -44,7 +44,8 @@
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 419c00c..9c11087 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2310,7 +2311,7 @@ static void rtl8169_reinit_task(struct work_struct *work)
ret = rtl8169_open(dev);
Joe Perches [EMAIL PROTECTED] :
Prefix dprintk with KERN_DEBUG
Fix a bug with existing use of dprintk (PFX KERN_INFO PFX)
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Ok, I will add #1 and #2 to the next submission to Jeff.
--
Ueimor
-
To unsubscribe from this list: send the line
Grant Likely wrote:
On 10/15/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Domen Puncer wrote:
Hello!
If there are no objections, I would like to get this merged
when bestcomm goes in (any time now?).
It's split into four parts:
1 - device tree
2 - small bestcomm change
3 - the actual driver
4 -
Hi.
I'm pleased to announce sixth release of the distributed storage
subsystem, which allows to form a storage on top of remote and local
nodes, which in turn can be exported to another storage as a node to
form tree-like storages.
This release includes mirroring algorithm extension, which
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index dd88e33..fcf042d 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_VIODASD) += viodasd.o
obj-$(CONFIG_BLK_DEV_SX8) +=
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/drivers/block/dst/kst.c b/drivers/block/dst/kst.c
new file mode 100644
index 000..b0608c9
--- /dev/null
+++ b/drivers/block/dst/kst.c
@@ -0,0 +1,1606 @@
+/*
+ * 2007+ Copyright (c) Evgeniy Polyakov [EMAIL PROTECTED]
+ * All rights
Signed-off-by: Evgeniy Polyakov [EMAIL PROTECTED]
diff --git a/Documentation/dst/algorithms.txt b/Documentation/dst/algorithms.txt
new file mode 100644
index 000..1437a6a
--- /dev/null
+++ b/Documentation/dst/algorithms.txt
@@ -0,0 +1,115 @@
+Each storage by itself is just a set of contiguous
From: Randy Dunlap [EMAIL PROTECTED]
Missing MODULE_LICENSE(), loading this module taints the kernel.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/net/phy/mdio-bitbang.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.23-git7.orig/drivers/net/phy/mdio-bitbang.c
+++
On Wed, Oct 17, 2007 at 05:04:01PM -0700, Don Fry wrote:
I have no objections myself. It has been slowly moving that direction.
First with the napi implementation, default off, labeled experimental.
Then removing experimental and then making the default on.
If any other user of the pcnet32
remove buggy and unused vdbg macro
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
index df884f0..a4b481c 100644
--- a/drivers/net/ucc_geth_mii.c
+++ b/drivers/net/ucc_geth_mii.c
@@ -46,13 +46,6 @@
#include ucc_geth_mii.h
Please pull from branch 'upstream-jeff' in repository
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git
upstream-jeff
to get the changes below.
Following mails on netdev describe each patch.
Distance from 'master' (d85714d81cc0408daddb68c10f7fd69eafe7c213)
I'm using Linus's git tree as of commit
d85714d81cc0408daddb68c10f7fd69eafe7c213. I built that kernel under vmware
workstation 6.0.1 which emulates a pcnet32 nic. When I only turn on
CONFIG_PCNET32, my network interface doesn't seem to come up fully: my dhcp
server sees a request, offers an IP
Erez Zadok wrote:
I'm using Linus's git tree as of commit
d85714d81cc0408daddb68c10f7fd69eafe7c213. I built that kernel under vmware
workstation 6.0.1 which emulates a pcnet32 nic. When I only turn on
CONFIG_PCNET32, my network interface doesn't seem to come up fully: my dhcp
server sees a
- prefix dprintk with KERN_DEBUG
- fix a bug with existing use of dprintk (PFX KERN_INFO PFX)
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |5 +++--
1 files changed, 3 insertions(+), 2
The identifiers have been extracted from Realtek's drivers:
- version 8.002.00 of the r8168 driver
- version 6.002.00 of the r8169 driver
- version 1.002.00 of the r8101 driver
1. RTL_GIGA_MAC_VER_17 (8168Bf) is isolated from RTL_GIGA_MAC_VER_12 (8168Be)
Both are still handled the same in
The values have been extracted from Realtek's r8168 driver
version 8.002.00.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 52 +++
1 files changed, 52 insertions(+), 0 deletions(-)
Consistent use of hexadecimal. No change of behavior otherwise.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/net/r8169.c
Use net_device_stats in the net_device structure.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 34 +-
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/r8169.c
Realtek's r8168 driver version 8.003.00 adds new init sequences
(they do not appear in version 8.002.00).
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 34 ++
1 files changed, 34 insertions(+), 0
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 66 +-
1 files changed, 2 insertions(+), 64 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9deda50..3a3ba79
The code is reworked to easily add phy-dependant init changes.
No change of behavior should be noticed.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 56 --
1 files changed, 31
The values have been updated between version 8.002.00 and version
8.003.00 of Realtek's r8168 driver. This modification syncs the
8168C with version 8.003.00.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |2 ++
1 files changed, 2
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 9c11087..16ecba1 100644
--- a/drivers/net/r8169.c
+++
It is currently limited to the tested 0x8136 and 0x8168. 8169sb/8110sb ought
to handle it as well where they support MSI.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
Tester-Cc: Rolf Eike Beer [EMAIL PROTECTED]
---
drivers/net/r8169.c | 50
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 951c56e..c290aa5 100644
--- a/drivers/net/r8169.c
+++
From: Randy Dunlap [EMAIL PROTECTED]
Date: Thu, 18 Oct 2007 21:53:50 -0700
[EMAIL PROTECTED] wrote:]
From: Randy Dunlap [EMAIL PROTECTED]
Drivers that use lro functions should depend on INET, otherwise they
may not link correctly. Let's not select INET. Select should be used
only
Applied, thanks!
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
1 - 100 of 131 matches
Mail list logo
