From: Roland Dreier <[EMAIL PROTECTED]>
Date: Mon, 20 Aug 2007 18:16:54 -0700
> And direct data placement really does give you a factor of two at
> least, because otherwise you're stuck receiving the data in one
> buffer, looking at some of the data at least, and then figuring out
> where to copy
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
> Ie a "barrier()" is likely _cheaper_ than the code generation downside
> from using "volatile".
Assuming GCC were ever better about the code generation badness
with volatile that has been discussed here, I muc
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 21 Aug 2007 14:22:55 +0800
> Hi:
>
> Here's the back-port for 2.6.22.
>
> [NET]: Share correct feature code between bridging and bonding
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the
> bonding driver may produce bogus combinat
From: Wei Yongjun <[EMAIL PROTECTED]>
Date: Mon, 20 Aug 2007 10:27:36 +0800
> Hi Arnaldo Carvalho de Melo:
> > Em Mon, Aug 20, 2007 at 09:28:27AM +0800, Wei Yongjun escreveu:
> >
> >> If ICMP6 message with "Packet Too Big" is received after send SCTP DATA,
> >> kernel panic will occur when SCTP
From: Konstantin Sharlaimov <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 20:45:51 +1100
> This patch addresses the issue with "osize too small" errors in mppe
> encryption.
> The patch fixes the issue with wrong output buffer size being passed to ppp
> decompression routine.
>
> Signed-off-by: Kon
From: Krishna Kumar2 <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 11:36:03 +0530
> > I ran 3 iterations of 45 sec tests (total 1 hour 16 min, but I will
> > run a longer one tonight). The results are (results in KB/s, and %):
>
> I ran a 8.5 hours run with no batching + another 8.5 hours run with
>
From: Milan Kocian <[EMAIL PROTECTED]>
Date: Wed, 15 Aug 2007 16:33:22 +0200
> ipv6 sends a RTM_DELLINK netlink message on both events: NETDEV_DOWN,
> NETDEV_UNREGISTER. Corrected by sending RTM_NEWLINK on NETDEV_DOWN event
> and RTM_DELLINK on NETDEV_UNREGISTER event.
Why would we indicate that
From: Joy Latten <[EMAIL PROTECTED]>
Date: Wed, 15 Aug 2007 11:16:29 -0500
> On Tue, 2007-08-07 at 18:32 -0700, David Miller wrote:
> >From: Joy Latten <[EMAIL PROTECTED]>
> >Date: Thu, 2 Aug 2007 15:56:47 -0500
> >
> >> @@ -426,10 +426,15 @@ struct xfrm_audit
> >> };
> >>
> >> #ifdef CONFIG_A
ERROR: "slhc_init" [drivers/net/ppp_generic.ko] undefined!
ERROR: "slhc_free" [drivers/net/ppp_generic.ko] undefined!
ERROR: "slhc_uncompress" [drivers/net/ppp_generic.ko] undefined!
ERROR: "slhc_compress" [drivers/net/ppp_generic.ko] undefined!
ERROR: "slhc_toss" [drivers/net/ppp_generic.ko] undef
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
> The existing OF glue code was crufty and broken. Rather than fix it,
> it will be removed, and the ethernet driver now talks to the device
> tree directly.
>
A bit short description, I'd rather expect some specific improvements list,
that ar
On Tue, Aug 21, 2007 at 01:02:01AM +0200, Segher Boessenkool wrote:
> >>And no, RMW on MMIO isn't "problematic" at all, either.
> >>
> >>An RMW op is a read op, a modify op, and a write op, all rolled
> >>into one opcode. But three actual operations.
> >
> >Maybe for some CPUs, but not all. ARM f
Hi Francois,
i just tested the new kernel 2.6.23rc3 with and without your patches, i cannot
find a difference to the behaviour of the previous state ... (22 + your patches)
I still have a very unreliable receiving of multicast packets, only for about
1/3 of my join mc attempts or so i receive
On Mon, Aug 20, 2007 at 05:05:18PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 21, 2007 at 01:02:01AM +0200, Segher Boessenkool wrote:
> > >>And no, RMW on MMIO isn't "problematic" at all, either.
> > >>
> > >>An RMW op is a read op, a modify op, and a write op, all rolled
> > >>into one opcode.
Russell King writes:
> Let me say it more clearly: On ARM, it is impossible to perform atomic
> operations on MMIO space.
Actually, no one is suggesting that we try to do that at all.
The discussion about RMW ops on MMIO space started with a comment
attributed to the gcc developers that one reas
Hi!
> > But I'm able to compile kernel (-j 10) on 128MB machine, and I tried
> > cat /dev/zero | grep foo to exhaust memory... and could not reproduce
> > the deadlock. Should I pingflood? Tweak down ammount of atomic memory
> > avaialable to make deadlocks easier to reproduce?
>
> I usually test
What if the name of the function was more descriptive of what the
function actually does? Maybe timeval_ceil_sec()?
-
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
On Tue, Aug 21, 2007 at 07:33:49PM +1000, Paul Mackerras wrote:
> So the whole discussion is irrelevant to ARM, PowerPC and any other
> architecture except x86[-64].
It's even irrelevant on x86 because all modifying operations on atomic_t
are coded in inline assembler and will always be RMW no ma
* Varun Chandramohan <[EMAIL PROTECTED]> 2007-08-20 13:46
> The age field is filled with the current time at the time of creation of the
> route. When the routes are dumped
> then the age value stored in the route structure is subtracted from the
> current time value and the difference is the age
fyi:
I do not know whether it is related to the problem, but since using
the version you told me there are these entries is my log:
frege Hangcheck: hangcheck value past margin!
frege Hangcheck: hangcheck value past margin!
frege Hangcheck: hangcheck value past margin!
2007/8/16, Francois Romie
Yesterdays git snapsot on a normal home PC spams dmesg with the
following line:
ipv4_get_l4proto: Frag of proto 17
--
Meelis Roos ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://v
Bob Beers wrote:
> What if the name of the function was more descriptive of what the
> function actually does? Maybe timeval_ceil_sec()?
>
Looks ok, it can be done if everyone is ok with it.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [
Thomas Graf wrote:
> * Varun Chandramohan <[EMAIL PROTECTED]> 2007-08-20 13:46
>
>> The age field is filled with the current time at the time of creation of the
>> route. When the routes are dumped
>> then the age value stored in the route structure is subtracted from the
>> current time value
* Varun Chandramohan <[EMAIL PROTECTED]> 2007-08-21 16:52
> I know its a bit confusing but let me explain the reason. In my first
> version patch i used fn_hash_insert() (place where alias is created)as
> place to insert my current time in the age field.
> This will eventually call fib_dump_info()
Thomas Graf wrote:
> * Varun Chandramohan <[EMAIL PROTECTED]> 2007-08-21 16:52
>
>> I know its a bit confusing but let me explain the reason. In my first
>> version patch i used fn_hash_insert() (place where alias is created)as
>> place to insert my current time in the age field.
>> This will ev
On Tue, 2007-21-08 at 00:18 -0700, David Miller wrote:
> Using 16K buffer size really isn't going to keep the pipe full enough
> for TSO.
Why the comparison with TSO (or GSO for that matter)?
Seems to me that is only valid/fair if you have a single flow.
Batching is multi-flow focused (or i sho
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
index 69da95b..c3fe1c7 100755
--- a/drivers/net/qla3xxx.c
+++ b/drivers/net/qla3xxx.c
@@ -2248,6 +2248,7 @
Fix 4032 chip undocumented "feature" where bit-8 is set
if the inbound completion is for a VLAN.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
inde
David Miller wrote:
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
Ie a "barrier()" is likely _cheaper_ than the code generation downside
from using "volatile".
Assuming GCC were ever better about the code generation badness
with volatile that has been di
Hi all,
Sadly I have to use the Apani/Nortel cvc contivity linux client. The
latest version (3.5) stopped being compatible with the latest stable
2.6.22 kernel.
Since there will most probably not be a new release from apani until
year 2013 we have hack the linux_wrapper.c file to try to keep th
And no, RMW on MMIO isn't "problematic" at all, either.
An RMW op is a read op, a modify op, and a write op, all rolled
into one opcode. But three actual operations.
Maybe for some CPUs, but not all. ARM for instance can't use the
load exclusive and store exclusive instructions to MMIO space.
Let me say it more clearly: On ARM, it is impossible to perform atomic
operations on MMIO space.
Actually, no one is suggesting that we try to do that at all.
The discussion about RMW ops on MMIO space started with a comment
attributed to the gcc developers that one reason why gcc on x86
doesn'
At some point in the future, barrier() will be universally regarded as
a hammer too big for most purposes. Whether or not removing it now
You can't just remove it, it is needed in some places; you want to
replace it in most places with a more fine-grained "compiler barrier",
I presume?
constit
On Tue, 21 Aug 2007, Chris Snook wrote:
> David Miller wrote:
> > From: Linus Torvalds <[EMAIL PROTECTED]>
> > Date: Mon, 20 Aug 2007 22:46:47 -0700 (PDT)
> >
> > > Ie a "barrier()" is likely _cheaper_ than the code generation downside
> > > from using "volatile".
> >
> > Assuming GCC were eve
On Tue, Aug 21, 2007 at 04:48:51PM +0200, Segher Boessenkool wrote:
> >>Let me say it more clearly: On ARM, it is impossible to perform atomic
> >>operations on MMIO space.
> >
> >Actually, no one is suggesting that we try to do that at all.
> >
> >The discussion about RMW ops on MMIO space started
Hi,
My kernel crashed while testing macvlan interfaces on 2.6.23-rc2.
(See kernel panic below)
The culprit is dev_mc_sync(). In this routine, we delete
elements from 'from->mc_list' unsafely.
While going through the list, we may delete one of the element
(__dev_addr_delete(from->mc_list,...)),
This patch fixes a crash that may occur when the routine dev_mc_sync()
deletes an address from the list it is currently going through. It
saves the pointer to the next element before deleting the current one.
The problem may also exist in dev_mc_unsync().
Signed-off-by: Benjamin Thery <[EMAIL PRO
Vitaly Bordug wrote:
On Fri, 17 Aug 2007 13:17:18 -0500
Scott Wood wrote:
The existing OF glue code was crufty and broken. Rather than fix it,
it will be removed, and the ethernet driver now talks to the device
tree directly.
A bit short description, I'd rather expect some specific improve
On Tue, 21 Aug 2007, Chris Snook wrote:
>
> Moore's law is definitely working against us here. Register counts, pipeline
> depths, core counts, and clock multipliers are all increasing in the long run.
> At some point in the future, barrier() will be universally regarded as a
> hammer too big f
The sky2 driver clears some bits in the PHY control register, that cause
the PHY interface to get changed. Some of these deal with voltage and power
savings as well. This may explain some of the failures on Gigabyte DS-3
motherboard.
The clue to possible problem was looking at why loading/unload
There are special PHY settings available on Yukon EC-U chip that
should not get cleared. The reset bits are in the least significant
bits, so that is all that needs to be set.
This should solve mysterious errors on some motherboards (like Gigabyte DS-3).
Signed-off-by: Stephen Hemminger <[EMAIL P
There are special PHY settings available on Yukon EC-U chip that
should not get cleared. This should solve mysterious errors on some
motherboards (like Gigabyte DS-3).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-21 11:08:27.0 -0700
+++ b/d
On Tue, 21 Aug 2007, Stephen Hemminger wrote:
>
> There are special PHY settings available on Yukon EC-U chip that
> should not get cleared. This should solve mysterious errors on some
> motherboards (like Gigabyte DS-3).
Ok, applied.
However:
- now all accesses to GPHY_CTRL are 8-bit (it use
On Tue, 21 Aug 2007 05:32:57 -0700 (PDT) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8914
>
>Summary: filter attached to prio qdisc breaks priomap handling of
> packets it does _not_ match
>Product: Networking
>Vers
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 21 Aug 2007 08:30:22 -0400
> On Tue, 2007-21-08 at 00:18 -0700, David Miller wrote:
>
> > Using 16K buffer size really isn't going to keep the pipe full enough
> > for TSO.
>
> Why the comparison with TSO (or GSO for that matter)?
Because TSO does bat
On Tue, 21 Aug 2007 11:26:23 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 21 Aug 2007, Stephen Hemminger wrote:
> >
> > There are special PHY settings available on Yukon EC-U chip that
> > should not get cleared. This should solve mysterious errors on some
> > motherboards
On 8/20/07, Dirk wrote:
>> So it seems that when the driver tries to queue a packet while the
>> controller is busy processing the queue, the newly queued packet does
>> not get noticed by the controller (until further packet activity
occurs).
>> Perhaps there is a problem with the memory barrie
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=253290
18:57:54 osama kernel: BUG: unable to handle kernel NULL pointer dereference at
virtual address 0004
18:57:54 osama kernel: printing eip:
18:57:54 osama kernel: c05c4026
18:57:54 osama kernel: *pde = 1d860067
18:57:54 osama kernel:
On Mon, 2007-08-20 at 18:23 +0200, Erik Slagter wrote:
> > /*
> > if ((eeprom >> 8) != 1) {
> > asix_write_gpio(dev, 0x003c, 30);
> > asix_write_gpio(dev, 0x001c, 300);
> > asix_write_gpio(dev, 0x003c, 30);
> > } else {
> > */
> >
On Tue, 2007-21-08 at 11:51 -0700, David Miller wrote:
> Because TSO does batching already, so it's a very good
> "tit for tat" comparison of the new batching scheme
> vs. an existing one.
Fair enough - I may have read too much into your email then;->
For bulk type of apps (where TSO will make a
Mark new version to track if current driver is in use.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-21 10:36:58.0 -0700
+++ b/drivers/net/sky2.c2007-08-21 10:44:22.0 -0700
@@ -51,7 +51,7 @@
#include "sky2.h"
#define DRV_N
Make sure PCI register for PHY power gets cleared on boot, and make
sure to avoid any PCI posting problems.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-21 10:17:59.0 -0700
+++ b/drivers/net/sky2.c2007-08-21 10:18:02.0 -0700
These patches address some issues that got listed as regressions
in 2.6.23.
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
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.htm
This fixes the extra timer overhead that people were whining about
as a 2.6.23 regression.
Running the watchdog timer all the time is unneeded. Change it
to run only if link is up, and reduce frequency to save power.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c
From: jamal <[EMAIL PROTECTED]>
Date: Tue, 21 Aug 2007 17:09:12 -0400
> Examples, a busy ssh or irc server and you could go as far as
> looking at the most pre-dominant app on the wild west, http (average
> page size from a few years back was in the range of 10-20K and can
> be simulated with good
On Tue, 21 Aug 2007 09:16:43 PDT, "Paul E. McKenney" said:
> I agree that instant gratification is hard to come by when synching
> up compiler and kernel versions. Nonetheless, it should be possible
> to create APIs that are are conditioned on the compiler version.
We've tried that, sort of. Se
The per cpu backlog napi struct can't do netpoll and has the
dev member set to NULL. Fixes an oops on boot when netpoll is
enabled.
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6.24/include/linux/netpoll.h
===
--- net-
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Wed, 22 Aug 2007 01:08:51 +0200
> The per cpu backlog napi struct can't do netpoll and has the
> dev member set to NULL. Fixes an oops on boot when netpoll is
> enabled.
>
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Applied, thanks a lot Thomas.
-
Linas Vepstas wrote:
> On Mon, Aug 20, 2007 at 10:13:27PM +0900, Ishizaki Kou wrote:
> > Please apply this to 2.6.23.
>
> I'll review and forward shortly. Kick me if you don't see a formal
> reply in a few days.
>
> > And also, please apply the following Arnd-san's patch to fix a problem
> > tha
We must not call netif_poll_enable after enabling interrupts,
because an interrupt might come in and set the __LINK_STATE_RX_SCHED
bit before we get to clear that bit again. If that happens,
the next call to the ->poll() function will oops.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
Signed-o
On Tue, Aug 21, 2007 at 06:51:16PM -0400, [EMAIL PROTECTED] wrote:
> On Tue, 21 Aug 2007 09:16:43 PDT, "Paul E. McKenney" said:
>
> > I agree that instant gratification is hard to come by when synching
> > up compiler and kernel versions. Nonetheless, it should be possible
> > to create APIs that
Jeff,
I'm resubmitting the last cxgb3 patch series against netdev-2.6#upstream,
minus the first patch that you already applied and the last patch.
Here is a brief description:
- Modify max HW Rx coalescing size
- Log SGE doorbell Fifo overflow
- Use Tx immediate data for offloa
From: Divy Le Ray <[EMAIL PROTECTED]>
Reduce Rx coalescing length to 12288
Large bursts from the adapter to the host create back pressure
on the chip. Reducing the burst size avoids the issue.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |2 +-
1 files chang
From: Divy Le Ray <[EMAIL PROTECTED]>
Log doorbell Fifo overflow
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/regs.h |8
drivers/net/cxgb3/sge.c |4
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/regs.h b/drivers/
From: Divy Le Ray <[EMAIL PROTECTED]>
Send small TX_DATA work requests as immediate data even when
there are fragments. this avoids doing multiple DMAs for
small fragmented packets.
The driver already implements this optimization for small
contiguous packets.
Signed-off-by: Divy Le Ray <[EMAIL
From: Divy Le Ray <[EMAIL PROTECTED]>
A HW issue requires limiting the receive window size
to 23 pages of internal memory.
These pages can be configured to different sizes,
thus the RDMA driver needs to know the
page size to enforce the upper limit.
Also assign explicit enum values.
Signed-off-b
From: Divy Le Ray <[EMAIL PROTECTED]>
Enforce validity checks on connection ids
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_defs.h| 20 ++--
drivers/net/cxgb3/cxgb3_offload.c | 28 +++-
2 files changed, 41 insertions
From: Divy Le Ray <[EMAIL PROTECTED]>
Stop the MAC when a fatal error is detected.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxg
From: Divy Le Ray <[EMAIL PROTECTED]>
Log HW serial number when cxgb3 module is loaded.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |2 ++
drivers/net/cxgb3/cxgb3_main.c |6 --
drivers/net/cxgb3/t3_hw.c |3 ++-
3 files changed, 8 insert
From: Divy Le Ray <[EMAIL PROTECTED]>
Set PM1 internal memory to round robin mode
It balances access to this internal memory for multiport adapters.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/regs.h |2 ++
drivers/net/cxgb3/t3_hw.c |2 ++
2 files changed, 4 in
From: Divy Le Ray <[EMAIL PROTECTED]>
Load microcode engine when the interface
is configured up.
Bump up version to 1.1.0.
Allow the driver to be and running with
older microcode images.
Allow ethtool to log the microcode version.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/c
From: Divy Le Ray <[EMAIL PROTECTED]>
Update firmware version
Allow the driver to be up and running with older FW image
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |2 +-
drivers/net/cxgb3/cxgb3_main.c |9 +
drivers/net/cxgb3/t3_hw.c |
From: Divy Le Ray <[EMAIL PROTECTED]>
Clear pciE PEX errors late at module load time.
Log details when PEX errors occur.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/t3_hw.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/cxgb3/t
David Miller <[EMAIL PROTECTED]> wrote on 08/22/2007 12:21:43 AM:
> From: jamal <[EMAIL PROTECTED]>
> Date: Tue, 21 Aug 2007 08:30:22 -0400
>
> > On Tue, 2007-21-08 at 00:18 -0700, David Miller wrote:
> >
> > > Using 16K buffer size really isn't going to keep the pipe full enough
> > > for TSO.
>
From: Krishna Kumar2 <[EMAIL PROTECTED]>
Date: Wed, 22 Aug 2007 09:41:52 +0530
> David Miller <[EMAIL PROTECTED]> wrote on 08/22/2007 12:21:43 AM:
>
> > From: jamal <[EMAIL PROTECTED]>
> > Date: Tue, 21 Aug 2007 08:30:22 -0400
> >
> > > On Tue, 2007-21-08 at 00:18 -0700, David Miller wrote:
> > >
So I did some experimenting with locking, but eventually found that this
chunk:
@@ -2677,10 +2681,18 @@ static void rtl8169_tx_interrupt(struct
net_device *dev,
if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
- -smp_wmb();
- -if (netif_queue_stopped(dev) &
- Support to add/delete/store/restore 64 and 128 Ethernet addresses for
Xframe I and Xframe II respectively.
Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -urpN patch1/drivers/net/s2io.c patch2/drivers/net/s2io.c
--- patch1/drivers
76 matches
Mail list logo