On 22-08-2007 19:03, Paul E. McKenney wrote:
> On Wed, Aug 22, 2007 at 05:41:11PM +0200, Adrian Bunk wrote:
>> On Wed, Aug 22, 2007 at 05:30:13PM +0200, Gabriel C wrote:
>>> Got it with a randconfig (
>>> http://194.231.229.228/kernel/mm/2.6.23-rc3-mm1/r/randconfig-8 )
>>>
>>> ...
>>>
>>> net/ipv4
On Sat, Aug 25, 2007 at 11:43:08AM +0200, Mariusz Kozlowski wrote:
> > > =
> > > [ INFO: inconsistent lock state ]
> > > 2.6.23-rc2-mm1 #7
> > > -
> > > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> > > ifconfig/5492 [HC0[0]:S
Sorry for late reply. I was on holiday last week.
On Thu, 23 Aug 2007 02:12:47 +0100
"Michael Lothian" <[EMAIL PROTECTED]> wrote:
> I can confirm this behaviour
>
> It could also be worth mentioning I'm using gcc 4.2.1
>
> Cheers
I also reproduced the symptom now. I'll investigate.
Thanks,
Add suspend and resume capability to the driver.
Tested both to ram and to disk on x86_64 platform.
Signed-off-by: Don Fry <[EMAIL PROTECTED]>
---
--- linux-2.6.23-rc3/drivers/net/pcnet32.c.orig 2007-08-14 13:52:24.0
-0700
+++ linux-2.6.23-rc3/drivers/net/pcnet32.c 2007-08-14 14:16:
From: John Heffner <[EMAIL PROTECTED]>
Date: Sun, 26 Aug 2007 21:32:26 -0400
> There are a few interesting things here. For one, the bursts caused by
> TSO seem to be causing the receiver to do stretch acks. This may have a
> negative impact on flow performance, but it's hard to say for sure h
From: James Chapman <[EMAIL PROTECTED]>
Date: Sun, 26 Aug 2007 20:36:20 +0100
> David Miller wrote:
> > From: James Chapman <[EMAIL PROTECTED]>
> > Date: Fri, 24 Aug 2007 18:16:45 +0100
> >
> >> Does hardware interrupt mitigation really interact well with NAPI?
> >
> > It interacts quite excelle
Bill Fink wrote:
Here's the beforeafter delta of the receiver's "netstat -s"
statistics for the TSO enabled case:
Ip:
3659898 total packets received
3659898 incoming packets delivered
80050 requests sent out
Tcp:
2 passive connection openings
3659897 segments received
800
A ootb chunk such as data in close state or init-ack in estab state will
cause SCTP to enter dead loop. Look like this:
(1)
Endpoint A Endpoint B
(Closed)(Closed)
DATA -> Kernel dead loop
(With Length set to zero)
(2)
End
Hi Dave,
Here go 3 IrDA patches for net-2.6.24 inclusion.
Cheers,
Samuel.
-
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
This dongle does not follow the usb-irda specification, so it needs its own
special driver. First, it uses control URBs for data transfer, instead of
bulk or interrupt transfers; the only interrupt endpoint exposed seems to
be a dummy to prevent the interface from being rejected. Second, it uses
ob
This dongle does not follow the usb-irda specification, so it needs its own
special driver. Just like the Kingsun/Donshine dongle, it exposes two
interrupt endpoints. Reception is performed through direct reads from the
input endpoint. Transmission requires splitting the IrDA frames into 8-byte
seg
Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
---
net/irda/af_irda.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
Index: net-2.6.24-quilt/net/irda/af_irda.c
===
--- net-2.6.24-quilt.orig/net/irda/a
David Miller wrote:
From: James Chapman <[EMAIL PROTECTED]>
Date: Fri, 24 Aug 2007 18:16:45 +0100
Does hardware interrupt mitigation really interact well with NAPI?
It interacts quite excellently.
If NAPI disables interrupts and keeps them disabled while there are more
packets arriving or
On Sun, 2007-08-26 at 10:30 +0200, Geert Uytterhoeven wrote:
> On Fri, 24 Aug 2007, Joe Perches wrote:
> > Corrected printk calls with multiple output lines which
> > did not correctly preface each line with KERN_
> > Fixed uses of some single lines with too many KERN_
> > --- a/arch/arm/kernel/ec
On Sun, 26 Aug 2007, Mike Frysinger wrote:
> On 8/26/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> > On Fri, 24 Aug 2007, Joe Perches wrote:
> > > Corrected printk calls with multiple output lines which
> > > did not correctly preface each line with KERN_
> > >
> > > Fixed uses of some single
On 8/26/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Fri, 24 Aug 2007, Joe Perches wrote:
> > Corrected printk calls with multiple output lines which
> > did not correctly preface each line with KERN_
> >
> > Fixed uses of some single lines with too many KERN_
>
> > --- a/arch/arm/kernel/
On Fri, 24 Aug 2007, John Heffner wrote:
> Bill Fink wrote:
> > Here you can see there is a major difference in the TX CPU utilization
> > (99 % with TSO disabled versus only 39 % with TSO enabled), although
> > the TSO disabled case was able to squeeze out a little extra performance
> > from its
On Fri, 24 Aug 2007, Joe Perches wrote:
> Corrected printk calls with multiple output lines which
> did not correctly preface each line with KERN_
>
> Fixed uses of some single lines with too many KERN_
> --- a/arch/arm/kernel/ecard.c
> +++ b/arch/arm/kernel/ecard.c
> @@ -547,7 +547,8 @@ static v
18 matches
Mail list logo