Dear Jeff:
We found current sundance.c in kernel 2.6.22 is working fine for IP100A.
We need not to modify following codes:
> - for (phy = 1; phy <= 32 && phy_idx < MII_CNT; phy++) {
> + if (sundance_pci_tbl[np->chip_id].device == 0x0200)
> + phy = 0;
> + else
> +
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones <[EMAIL PROTECTED]> wrote:
> Build upon David Miller's initial patches to set the per-route rto_min
> so users can specify the rto_min in the same units (milliseconds) in
> which they are displayed. This is desirable because asking users to
> con
This trivial patch removes the unneeded pointer newdp, which is never used.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
---
--- a/net/dccp/ipv4.c 2007-09-04 23:18:42.0 +0800
+++ b/net/dccp/ipv4.c 2007-09-05 00:49:54.0 +0800
@@ -381,7 +381,6 @@
{
struct inet_reques
This trivial patch removes the unneeded pointer iph, which is never used.
Signed-off-by: Micah Gruber < [EMAIL PROTECTED]>
---
--- a/net/ipv6/ipcomp6.c2007-09-04 23:18:43.0 +0800
+++ b/net/ipv6/ipcomp6.c2007-09-05 00:48:05.0 +0800
@@ -65,7 +65,6 @@
static int ipco
On Fri, Aug 31, 2007 at 06:46:17AM -0400, Jeff Garzik wrote:
> Ishizaki Kou wrote:
> >This patch solves a problem that the spidernet driver sometimes fails
> >to handle IRQ.
> >
> >The problem happens because,
> >- In Cell architecture, interrupts may arrive at an interrupt
> > controller, even if
According to the comment in the net/core/sock.c code (in 2.6.20), I should be
able to pass a zero
optlen to the setsockopt method for SO_BINDTODEVICE:
case SO_BINDTODEVICE:
{
char devname[IFNAMSIZ];
/* Sorry... */
Francois Romieu wrote:
Does "acceptable" mean that there is a noticeable difference when compared
to the patch based on a busy-waiting loop ?
Would you like me to *just* try patches 1 & 2, to help narrow down anything?
I expect patch #2 alone to be enough to enhance the performance. I
On Tue, 4 Sep 2007 10:54:32 -0700
Zach Carter <[EMAIL PROTECTED]> wrote:
>
> > +ioc3-program-uart-predividers.patch
> > +sky2-fe-chip-support.patch
> > +sky2-use-debugfs-rename.patch
> > +sky2-document-gphy_ctrl-bits.patch
> > +sky2-dont-restrict-config-space-access.patch
> > +sky2-advanced-error
On Tue, 4 Sep 2007, Francois Romieu wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
20070903-2.6.23-rc5-r8169-test.patch applied against 2.6.23-rc5 works fine.
Performance is acceptable.
Does "acceptable" mean that there is a noticeable difference when compared
to the patch based on a b
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
> 20070903-2.6.23-rc5-r8169-test.patch applied against 2.6.23-rc5 works fine.
> Performance is acceptable.
Does "acceptable" mean that there is a noticeable difference when compared
to the patch based on a busy-waiting loop ?
> Would you like me to *j
John Sigler wrote:
> Jesse Brandeburg wrote:
>
>> Auke Kok wrote:
>>
>>> Marc Sigler wrote:
>>>
I have several systems with three integrated Intel 82559 (I
*think*).
Does someone know if these boards support hardware interrupt
mitigation? I.e. is it possible to configu
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This is desirable because asking users to
convert to and from jiffies themselves, when there can be different
values of HZ from syst
On Mon, 3 Sep 2007, Francois Romieu wrote:
[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
[...]
I have had abysmal performance trying to remotely run X apps via ssh on a
computer with a RTL8111 NIC. Saw this message and decided to give this
patch a try --- success! Much, much better.
Can you give
> +ioc3-program-uart-predividers.patch
> +sky2-fe-chip-support.patch
> +sky2-use-debugfs-rename.patch
> +sky2-document-gphy_ctrl-bits.patch
> +sky2-dont-restrict-config-space-access.patch
> +sky2-advanced-error-reporting.patch
> +sky2-use-pci_config-access-functions.patch
> +sky2-use-net_device-in
Adrian Bunk napsal(a):
> defconfig fails with the following error on parisc:
>
> <-- snip -->
>
> ...
> CC net/core/gen_estimator.o
> In file included from include2/asm/bitops.h:111,
> from
> /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/net/core/gen_estimator.c:18:
On Tue, 04 Sep 2007, Patrick McHardy wrote:
> Bill Fink wrote:
> > On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:
> >
> >>On Sat, 1 Sep 2007, Patrick McHardy wrote:
> >>>
> >>>It still won't work properly with TSO (TBF for example already drops
> >>>oversized packets during ->enqueue), but its
Cool. I'll try to see if I can clock my pc lower and run the
experiments again. I'll measure cpu utilization also this time around.
That should be useful for extrapolating.
Regards,
Mandeep
On 9/4/07, Daniele Venzano <[EMAIL PROTECTED]> wrote:
> - Message d'origine -
> De: Mandeep Singh B
On 9/4/07, jamal <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-03-09 at 20:20 -0700, Mandeep Singh Baines wrote:
>
> > I didn't see much saving in interrupts on my machine (too fast, I guess).
>
> You could try the idea suggested by Dave earlier and just turn interupts
> for every nth packet. That shou
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next li
- Message d'origine -
De: Mandeep Singh Baines <[EMAIL PROTECTED]>
Date: Mon, 3 Sep 2007 20:20:36 -0700
Sujet: [PATCH] [sis900] convert to NAPI, WAS Re: pktgen terminating condition
>Hi Daniele,
>
>Attached is a patch for converting the sis900 driver to NAPI. Please take a
>look at let me
Jesse Brandeburg wrote:
Auke Kok wrote:
Marc Sigler wrote:
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt
mitigation? I.e. is it possible to configure them to raise an IRQ
only if their hardware buffer is fu
Jesper Dangaard Brouer wrote:
> On Sun, 2007-09-02 at 23:16 +0200, Patrick McHardy wrote:
>
>>Jesper Dangaard Brouer wrote:
>>
>>>On Sun, 2 Sep 2007, Patrick McHardy wrote:
>>>
>>>Lets focus on the general case, where the functionality actually is
>>>needed right away.
>>>
>>>In the general case:
Bill Fink wrote:
> On Sat, 1 Sep 2007, Jesper Dangaard Brouer wrote:
>
>>On Sat, 1 Sep 2007, Patrick McHardy wrote:
>>
>>>
>>>It still won't work properly with TSO (TBF for example already drops
>>>oversized packets during ->enqueue), but its a good cleanup anyway.
>>
>>Then lets call it a cleanup
Kok, Auke wrote:
> Marc Sigler wrote:
>> Hello everyone,
>>
>> I have several systems with three integrated Intel 82559 (I *think*).
>>
>> Does someone know if these boards support hardware interrupt
>> mitigation? I.e. is it possible to configure them to raise an IRQ
>> only if their hardware bu
Marc Sigler wrote:
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if their
hardware buffer is full OR if some given time (
Roland Dreier wrote:
> The sysadmin creates "for iwarp use only" alias interfaces of the form
> "devname:iw*" where devname is the native interface name (eg eth0) for the
> iwarp netdev device. The alias label can be anything starting with "iw".
> The "iw" immediately after the ':' is the
Jeff Garzik wrote:
> drivers/net/xen-netfront.c | 26 +++
>
Hey, look, its identical to the patch I have here.
Acked-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
J
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mo
> -Original Message-
> From: Denys [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 02, 2007 6:12 AM
> To: Rune Torgersen; [EMAIL PROTECTED];
> netdev@vger.kernel.org
> Subject: Re: Ethernet weirdness on 82xx
>
> Thats normal.
> Check arp_filter sysctl :
> arp_filter - BOOLEAN
Thank
The sgiseeq driver is one of the few remaining users of the ancient
cache banging DMA API. Replaced with the modern days DMA API.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
diff --git a/drivers/net/sgiseeq.c b/drivers/net/sgiseeq.c
index 0fb74cb..eb67b02 100644
--- a/drivers/net/sgiseeq.c
+
On Mon, 2007-03-09 at 20:20 -0700, Mandeep Singh Baines wrote:
> I didn't see much saving in interrupts on my machine (too fast, I guess).
You could try the idea suggested by Dave earlier and just turn interupts
for every nth packet. That should cut down the numbers.
> I did see a significant b
* Herbert Xu <[EMAIL PROTECTED]> 2007-09-04 07:05
> Thomas Graf <[EMAIL PROTECTED]> wrote:
> >
> > I've been trying to reproduce this, what happens on my system
> > is that when the ISAKMP SA lifetime is exceeded the rekeying
> > fails and my connection dies. I can reproduce this back to
> > 2.6.2
On Tue, Sep 04, 2007 at 10:35:10AM +0100, Mark Hindley wrote:
> On Tue, Sep 04, 2007 at 11:17:57AM +0200, Steffen Klassert wrote:
>
> > The only warning that I was able to trigger with gcc 4.2 is in the case of
> > a .config
> > without PCI support. In this case I get
> >
> > drivers/net/3c59x.
On Tue, Sep 04, 2007 at 11:17:57AM +0200, Steffen Klassert wrote:
> The only warning that I was able to trigger with gcc 4.2 is in the case of a
> .config
> without PCI support. In this case I get
>
> drivers/net/3c59x.c: In function 'vortex_up':
> drivers/net/3c59x.c:1672: warning: 'err' is us
On Tue, Sep 04, 2007 at 09:53:31AM +0100, Mark Hindley wrote:
> On Tue, Sep 04, 2007 at 02:09:47PM +0530, Satyam Sharma wrote:
> > Hi Steffen,
> >
> >
> > On Tue, 4 Sep 2007, Steffen Klassert wrote:
> >
> > > On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
> > > >
> > > > drivers
On Tue, Sep 04, 2007 at 02:09:47PM +0530, Satyam Sharma wrote:
> Hi Steffen,
>
>
> On Tue, 4 Sep 2007, Steffen Klassert wrote:
>
> > On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
> > >
> > > drivers/net/3c59x.c: In function 'vortex_up':
> > > drivers/net/3c59x.c:1495: warning:
On Tue, 4 Sep 2007, Satyam Sharma wrote:
> Hi Micah,
>
>
> On Tue, 4 Sep 2007, Micah Gruber wrote:
>
> > This patch fixes a potential null dereference bug where we dereference
> > dev before a null check. This patch simply moves the dereferencing after
> > the null check.
> >
> > Signed-off-
Hi Steffen,
On Tue, 4 Sep 2007, Steffen Klassert wrote:
> On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
> >
> > drivers/net/3c59x.c: In function 'vortex_up':
> > drivers/net/3c59x.c:1495: warning: 'err' may be used uninitialized in this
> > function
>
> This came in with the
Hi Micah,
On Tue, 4 Sep 2007, Micah Gruber wrote:
> This patch fixes a potential null dereference bug where we dereference
> dev before a null check. This patch simply moves the dereferencing after
> the null check.
>
> Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
> ---
>
> --- a/drivers/ne
On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
>
> drivers/net/3c59x.c: In function 'vortex_up':
> drivers/net/3c59x.c:1495: warning: 'err' may be used uninitialized in this
> function
This came in with the recently applied 3c59x-check-return-of-pci_enable_device
patch
from Mark
This patch fixes a potential null dereference bug where we dereference dev
before a null check. This patch simply moves the dereferencing after the null
check.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
---
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -663,7 +663,
This patch fixes a potential null dereference bug where we dereference dev
before a null check. This patch simply moves the dereferencing after the null
check.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
---
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -663,7 +663,
On Tue, 4 Sep 2007 06:35:25 +0100
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Andi mentioned he did something like this already, but never
> submitted it.
>
> The dhcp client application uses AF_PACKET with a packet filter to
> receive data. The application doesn't even use timestamps, but bec
On Tue, Sep 04, 2007 at 03:52:50AM +0530, Satyam Sharma wrote:
> Remove duplicate entry for the same driver.
This is -mm specific. Andrew did not remove the add-3c59x-maintainer
patch after pushing it to mainline. This can be fixed just by removing
the add-3c59x-maintainer patch from -mm.
-
To u
43 matches
Mail list logo
