Re: [PATCH] [0/4] pasemi_mac: fixes and enhancements

On Mon, Apr 16, 2007 at 01:16:54AM -0500, Olof Johansson wrote: > Hi, > > The four following patches contain a number of fixes and improvements > of the pasemi_mac driver: I just realized that these have been based on top of some OF API changes that are in paulus' for-2.6.22 tree, and won't build

Re: PROBLEM: tg3 spitting out uninitialized memory

Andi Kleen wrote: > tg3s never use the IOMMU on AMD systems with production kernels > because they have a suitably large DMA mask. IOMMU is only used > there to remap memory that doesn't fit a device's DMA mask. > There is a debugging mode to force iommu always, but it is not used > unless you co

[PATCH] [3/4] pasemi_mac: cleanups and rx performance improvements

NAPI fixes and cleanups for pasemi_mac: * Timer changes/fixes * Abstract out the rx intr restart to a separate function * Similar function for tx intr to reset to a known clear state even if firmware used the same interface * Add a copy-break and recycle the SKB in the driver for small packets

[PATCH] [4/4] pasemi_mac: phy support

PHY support for pasemi_mac. Also add msg_enable flags for future disablement of the link messages. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac

[PATCH] [2/4] pasemi_mac: irq mapping changes

Fixes for ethernet IRQ mapping, to move it to the driver instead of in the platform setup code. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: powerpc/arch/powerpc/platforms/pasemi/pci.c === --- powerpc.orig/arch/powerpc/p

Re: [PATCH] [2/4] pasemi_mac: irq mapping changes

On Mon, 2007-04-16 at 01:18 -0500, Olof Johansson wrote: > Fixes for ethernet IRQ mapping, to move it to the driver instead of in > the platform setup code. > > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > Index: powerpc/arch/powerpc/platforms/pasemi/pci.c > ==

Re: PROBLEM: tg3 spitting out uninitialized memory

> That's right. See the discussion on a similar problem here: > > 59644&admit=-682735245+1158251313899+28353475> That's an AMD machine. > > In this other case, the symptoms were very similar to yours. > I suspected it w

Re: PROBLEM: tg3 spitting out uninitialized memory

Jamie webb wrote: > > Well, so far so good. I'll let you know if it happens again, but it > looks like that's fixed it. > > Further testing showed that I also had to disable rx checksumming, > otherwise I was getting random kernel crashes. Presumably it was not > only reading data from random

[PATCH] [0/4] pasemi_mac: fixes and enhancements

Hi, The four following patches contain a number of fixes and improvements of the pasemi_mac driver: 1/4: A couple of minor bugfixes. 2/4: Move the IRQ mapping from the PCI layer under our platform, to the driver. 3/4: A rather large patch with various NAPI/performance-related fixes and

[PATCH] [1/4] pasemi_mac: minor bugfixes

Ethernet bugfixes: * Move the was_full/wake_queue logic from tx_intr to clean_tx * Fix polarity in checks in pasemi_mac_close Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: linux-2.6/drivers/net/pasemi_mac.c === --- linu

[KJ][PATCH]sb1250-mac.c-kzalloc

Replacing kmalloc/memset combination with kzalloc. Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/drivers/net/sb1250-mac.c b/drivers/net/sb1250-mac.c index 103c317..af7649f 100644 --- a/drivers/net/sb1250-mac.c +++ b/drivers/net/sb1250-mac.c @@ -735,8 +735,8 @@ static void sbdma

Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen

Denys wrote: > On Mon, 16 Apr 2007 07:30:33 +0200, Patrick McHardy wrote > >>That makes sense with using multiple IPs (and we support doing that), >>but whats the point of load-balancing to differenet *ports*? > > > Easy - for example i have my own TCP acceleration solution, which is using > RE

Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen

On Mon, 16 Apr 2007 07:30:33 +0200, Patrick McHardy wrote > Denys wrote: > > Sorry, i will put my IMHO, since i am using it too. > > > > I guess it can be useful for load-balancing scenario. > > That makes sense with using multiple IPs (and we support doing that), > but whats the point of load

Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen

Denys wrote: > Sorry, i will put my IMHO, since i am using it too. > > I guess it can be useful for load-balancing scenario. That makes sense with using multiple IPs (and we support doing that), but whats the point of load-balancing to differenet *ports*? > Is there way to provide both ways? >

Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen

Sorry, i will put my IMHO, since i am using it too. I guess it can be useful for load-balancing scenario. Is there way to provide both ways? Thinking... 60% done, But maybe this can be done over -m statistic already On Mon, 16 Apr 2007 07:12:33 +0200, Patrick McHardy wrote > Andrew Morton wrote:

Re: [Bugme-new] [Bug 8325] New: -j REDIRECT --to-ports 1000-1009, always first choosen

Andrew Morton wrote: > On Fri, 13 Apr 2007 13:53:12 -0700 > [EMAIL PROTECTED] wrote: > > >>http://bugzilla.kernel.org/show_bug.cgi?id=8325 >> >> Summary: -j REDIRECT --to-ports 1000-1009, always first choosen >>Kernel Version: 2.6.19-1.2911.fc6PAE 2.6.19-gentoo-r4 >>Stat

Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work

Rusty Russell wrote: > On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote: > >> I hadn't considered an always-blocking (or unbuffered) networking API. >> It's very counter to current APIs, but does make sense with things like >> syslets. Without syslets, I don't think it's very useful as you

Re: [Bugme-new] [Bug 8320] New: replacing route in kernel doesn't send netlink message

Milan Kocián wrote: > On Wed, 2007-04-11 at 20:19 +0200, Patrick McHardy wrote: > > >>I think having notifications for this case makes sense (IIRC I used >>to use a similar patch some time ago, but can't find it right now). >>But we need to indicate somehow that it is a replacement and not a >>co

2.6.21rc7 e1000 media-detect oddness.

I booted up 2.6.21rc7 without an ethernet cable plugged in, and noticed this.. e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 I plugged a cable in, did rmmod e1000;modprobe e1000, and got this.. e1000: :02:00.0: e1000_prob

[1/2] 2.6.21-rc7: known regressions

This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involv

Re: [kvm-devel] QEMU PIC indirection patch for in-kernel APIC work

On Thu, 2007-04-12 at 06:32 +0300, Avi Kivity wrote: > I hadn't considered an always-blocking (or unbuffered) networking API. > It's very counter to current APIs, but does make sense with things like > syslets. Without syslets, I don't think it's very useful as you need > some artificial threads

Re: TCP connection stops after high load.

Hi John, On 4/15/07, John Heffner <[EMAIL PROTECTED]> wrote: Robert Iakobashvili wrote: > Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and > 2.6.20.6 do not. > > Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 > tcp_rmem and tcp_wmem are the same, whereas tcp_mem are

Re: TCP connection stops after high load.

Robert Iakobashvili wrote: Vanilla 2.6.18.3 works for me perfectly, whereas 2.6.19.5 and 2.6.20.6 do not. Looking into the tcp /proc entries of 2.6.18.3 versus 2.6.19.5 tcp_rmem and tcp_wmem are the same, whereas tcp_mem are much different: kernel tcp_mem --

Re: TCP connection stops after high load.

On 4/13/07, David Miller <[EMAIL PROTECTED]> wrote: From: "Robert Iakobashvili" <[EMAIL PROTECTED]> Date: Thu, 12 Apr 2007 23:11:14 +0200 > It works good with 2.6.11.8 and debian 2.6.18.3-i686 image. > > At the same Intel Pentium-4 PC with the same about kernel configuration > (make oldconfig u

{Spam?} Re: {Spam?} Re: {Spam?} [PATCH] NET: Remove obsolete traffic shaper code.

On Sun, 15 Apr 2007, Ian McDonald wrote: > On 4/15/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote: > > in fact, according to this: > > > > http://lkml.org/lkml/2006/1/13/139 > > > > that notice was put in the feature removal file well over a year ago, > > during 2.6.15. so that would seem to be m

Re: TCP connection stops after high load.

On 4/13/07, David Miller <[EMAIL PROTECTED]> wrote: From: "Robert Iakobashvili" <[EMAIL PROTECTED]> Date: Thu, 12 Apr 2007 23:11:14 +0200 > It works good with 2.6.11.8 and debian 2.6.18.3-i686 image. > > At the same Intel Pentium-4 PC with the same about kernel configuration > (make oldconfig u