* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Thomas Graf @ 2005-07-05 13:48 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <42CA8555.9050607@cosmosbay.com>
* Eric Dumazet <42CA8555.9050607@cosmosbay.com> 2005-07-05 15:04
> Thomas Graf a écrit :
> >* Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
> >
> >>[NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
> >>better code.
> >> (Using skb_queue_empty() to test the queue is faster than trying to
> >> __skb_dequeue())
> >> oprofile says this function uses now 0.29% instead of 1.22 %, on a
> >> x86_64 target.
> >
> >
> >I think this patch is pretty much pointless. __skb_dequeue() and
> >!skb_queue_empty() should produce almost the same code and as soon
> >as you disable profiling and debugging you'll see that the compiler
> >unrolls the loop itself if possible.
> >
> >
>
> OK. At least my compiler (gcc-3.3.1) does NOT unroll the loop :
Because you don't specify -funroll-loop
[...]
> Please give us the code your compiler produces,
Unrolled version:
pfifo_fast_dequeue:
pushl %esi
xorl %edx, %edx
pushl %ebx
movl 12(%esp), %esi
movl 128(%esi), %eax
leal 128(%esi), %ecx
cmpl %ecx, %eax
je .L132
movl %eax, %edx
movl (%eax), %eax
decl 8(%ecx)
movl $0, 8(%edx)
movl %ecx, 4(%eax)
movl %eax, 128(%esi)
movl $0, 4(%edx)
movl $0, (%edx)
.L132:
testl %edx, %edx
je .L131
movl 96(%edx), %ebx
movl 80(%esi), %eax
decl 40(%esi)
subl %ebx, %eax
movl %eax, 80(%esi)
movl %edx, %eax
.L117:
popl %ebx
popl %esi
ret
.L131:
movl 20(%ecx), %eax
leal 20(%ecx), %edx
xorl %ebx, %ebx
cmpl %edx, %eax
je .L137
movl %eax, %ebx
movl (%eax), %eax
decl 8(%edx)
movl $0, 8(%ebx)
movl %edx, 4(%eax)
movl %eax, 20(%ecx)
movl $0, 4(%ebx)
movl $0, (%ebx)
.L137:
testl %ebx, %ebx
je .L147
.L146:
movl 96(%ebx), %ecx
movl 80(%esi), %eax
decl 40(%esi)
subl %ecx, %eax
movl %eax, 80(%esi)
movl %ebx, %eax
jmp .L117
.L147:
movl 40(%ecx), %eax
leal 40(%ecx), %edx
xorl %ebx, %ebx
cmpl %edx, %eax
je .L142
movl %eax, %ebx
movl (%eax), %eax
decl 8(%edx)
movl $0, 8(%ebx)
movl %edx, 4(%eax)
movl %eax, 40(%ecx)
movl $0, 4(%ebx)
movl $0, (%ebx)
.L142:
xorl %eax, %eax
testl %ebx, %ebx
jne .L146
jmp .L117
> and explain me how
> disabling oprofile can change the generated assembly. :)
> Debugging has no impact on this code either.
I just noticed that this is a local modification of my own, so in
the vanilla tree it indeed doesn't have any impact on the code
generated.
Still, your patch does not make sense to me. The latest tree
also includes my pfifo_fast changes wich modified the code to
maintain a backlog and made it easy to add more fifos at compile
time. If you want the loop unrolled then let the compiler do it
via -funroll-loop. These kind of optimization seem as uncessary
to me as all the loopback optimizations.
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Eric Dumazet @ 2005-07-05 13:04 UTC (permalink / raw)
To: Thomas Graf; +Cc: David S. Miller, netdev
In-Reply-To: <20050705115108.GE16076@postel.suug.ch>
Thomas Graf a écrit :
> * Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
>
>>[NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
>>better code.
>> (Using skb_queue_empty() to test the queue is faster than trying to
>> __skb_dequeue())
>> oprofile says this function uses now 0.29% instead of 1.22 %, on a
>> x86_64 target.
>
>
> I think this patch is pretty much pointless. __skb_dequeue() and
> !skb_queue_empty() should produce almost the same code and as soon
> as you disable profiling and debugging you'll see that the compiler
> unrolls the loop itself if possible.
>
>
OK. At least my compiler (gcc-3.3.1) does NOT unroll the loop :
Original 2.6.12 gives :
ffffffff802a9790 <pfifo_fast_dequeue>: /* pfifo_fast_dequeue total: 2904054 1.9531 */
258371 0.1738 :ffffffff802a9790: lea 0xc0(%rdi),%rcx
273669 0.1841 :ffffffff802a9797: xor %esi,%esi
12533 0.0084 :ffffffff802a9799: mov (%rcx),%rdx
292315 0.1966 :ffffffff802a979c: cmp %rcx,%rdx
11717 0.0079 :ffffffff802a979f: je ffffffff802a97d1 <pfifo_fast_dequeue+0x41>
4474 0.0030 :ffffffff802a97a1: mov %rdx,%rax
6238 0.0042 :ffffffff802a97a4: mov (%rdx),%rdx
41 2.8e-05 :ffffffff802a97a7: decl 0x10(%rcx)
6089 0.0041 :ffffffff802a97aa: test %rax,%rax
126 8.5e-05 :ffffffff802a97ad: movq $0x0,0x10(%rax)
39 2.6e-05 :ffffffff802a97b5: mov %rcx,0x8(%rdx)
6974 0.0047 :ffffffff802a97b9: mov %rdx,(%rcx)
2841 0.0019 :ffffffff802a97bc: movq $0x0,0x8(%rax)
366 2.5e-04 :ffffffff802a97c4: movq $0x0,(%rax)
14757 0.0099 :ffffffff802a97cb: je ffffffff802a97d1 <pfifo_fast_dequeue+0x41>
288 1.9e-04 :ffffffff802a97cd: decl 0x40(%rdi)
94 6.3e-05 :ffffffff802a97d0: retq
970400 0.6526 :ffffffff802a97d1: inc %esi
982402 0.6607 :ffffffff802a97d3: add $0x18,%rcx
4 2.7e-06 :ffffffff802a97d7: cmp $0x2,%esi
1 6.7e-07 :ffffffff802a97da: jle ffffffff802a9799 <pfifo_fast_dequeue+0x9>
59754 0.0402 :ffffffff802a97dc: xor %eax,%eax
561 3.8e-04 :ffffffff802a97de: data16
:ffffffff802a97df: nop
:ffffffff802a97e0: retq
And new code (2.6.12-ed):
ffffffff802b1020 <pfifo_fast_dequeue>: /* pfifo_fast_dequeue total: 153139 0.2934 */
27388 0.0525 :ffffffff802b1020: lea 0xc0(%rdi),%rdx
42091 0.0806 :ffffffff802b1027: cmp %rdx,0xc0(%rdi)
:ffffffff802b102e: jne ffffffff802b1052 <pfifo_fast_dequeue+0x32>
474 9.1e-04 :ffffffff802b1030: lea 0xd8(%rdi),%rdx
5571 0.0107 :ffffffff802b1037: cmp %rdx,0xd8(%rdi)
2 3.8e-06 :ffffffff802b103e: jne ffffffff802b1052 <pfifo_fast_dequeue+0x32>
1 1.9e-06 :ffffffff802b1040: lea 0xf0(%rdi),%rdx
20030 0.0384 :ffffffff802b1047: xor %eax,%eax
6 1.1e-05 :ffffffff802b1049: cmp %rdx,0xf0(%rdi)
6 1.1e-05 :ffffffff802b1050: je ffffffff802b1086 <pfifo_fast_dequeue+0x66>
:ffffffff802b1052: mov (%rdx),%rcx
11796 0.0226 :ffffffff802b1055: xor %eax,%eax
:ffffffff802b1057: cmp %rdx,%rcx
8 1.5e-05 :ffffffff802b105a: je ffffffff802b1083 <pfifo_fast_dequeue+0x63>
3146 0.0060 :ffffffff802b105c: mov %rcx,%rax
12 2.3e-05 :ffffffff802b105f: mov (%rcx),%rcx
118 2.3e-04 :ffffffff802b1062: decl 0x10(%rdx)
4924 0.0094 :ffffffff802b1065: movq $0x0,0x10(%rax)
65 1.2e-04 :ffffffff802b106d: mov %rdx,0x8(%rcx)
725 0.0014 :ffffffff802b1071: mov %rcx,(%rdx)
11493 0.0220 :ffffffff802b1074: movq $0x0,0x8(%rax)
194 3.7e-04 :ffffffff802b107c: movq $0x0,(%rax)
2995 0.0057 :ffffffff802b1083: decl 0x40(%rdi)
19607 0.0376 :ffffffff802b1086: nop
2487 0.0048 :ffffffff802b1087: retq
Please give us the code your compiler produces, and explain me how disabling oprofile can change the generated assembly. :)
Debugging has no impact on this code either.
Thank you
Eric
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Thomas Graf @ 2005-07-05 12:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <20050705115108.GE16076@postel.suug.ch>
* Thomas Graf <20050705115108.GE16076@postel.suug.ch> 2005-07-05 13:51
> * Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
> > [NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
> > better code.
> > (Using skb_queue_empty() to test the queue is faster than trying to
> > __skb_dequeue())
> > oprofile says this function uses now 0.29% instead of 1.22 %, on a
> > x86_64 target.
>
> I think this patch is pretty much pointless. __skb_dequeue() and
> !skb_queue_empty() should produce almost the same code and as soon
> as you disable profiling and debugging you'll see that the compiler
> unrolls the loop itself if possible.
... given one enables it of course.
^ permalink raw reply
* Re: [PATCH] loop unrolling in net/sched/sch_generic.c
From: Thomas Graf @ 2005-07-05 11:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <42CA390C.9000801@cosmosbay.com>
* Eric Dumazet <42CA390C.9000801@cosmosbay.com> 2005-07-05 09:38
> [NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates
> better code.
> (Using skb_queue_empty() to test the queue is faster than trying to
> __skb_dequeue())
> oprofile says this function uses now 0.29% instead of 1.22 %, on a
> x86_64 target.
I think this patch is pretty much pointless. __skb_dequeue() and
!skb_queue_empty() should produce almost the same code and as soon
as you disable profiling and debugging you'll see that the compiler
unrolls the loop itself if possible.
^ permalink raw reply
* [PATCH] loop unrolling in net/sched/sch_generic.c
From: Eric Dumazet @ 2005-07-05 7:38 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <20050704.160140.21591849.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
[NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates better code.
(Using skb_queue_empty() to test the queue is faster than trying to __skb_dequeue())
oprofile says this function uses now 0.29% instead of 1.22 %, on a x86_64 target.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: patch.sch_generic --]
[-- Type: text/plain, Size: 1022 bytes --]
--- linux-2.6.12/net/sched/sch_generic.c 2005-06-17 21:48:29.000000000 +0200
+++ linux-2.6.12-ed/net/sched/sch_generic.c 2005-07-05 09:11:30.000000000 +0200
@@ -333,18 +333,23 @@
static struct sk_buff *
pfifo_fast_dequeue(struct Qdisc* qdisc)
{
- int prio;
struct sk_buff_head *list = qdisc_priv(qdisc);
struct sk_buff *skb;
- for (prio = 0; prio < 3; prio++, list++) {
- skb = __skb_dequeue(list);
- if (skb) {
- qdisc->q.qlen--;
- return skb;
- }
+ for (;;) {
+ if (!skb_queue_empty(list))
+ break;
+ list++;
+ if (!skb_queue_empty(list))
+ break;
+ list++;
+ if (!skb_queue_empty(list))
+ break;
+ return NULL;
}
- return NULL;
+ skb = __skb_dequeue(list);
+ qdisc->q.qlen--;
+ return skb;
}
static int
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 23:01 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9BEF6.4080402@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 05 Jul 2005 00:57:58 +0200
> Eric Dumazet a écrit :
>
> > Very easy way to lock it :
> >
> > ping -f some_destination.
>
>
> Arg. False alarm. Sorry.
>
> Time for me to sleep.
Oh well...
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 23:00 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9BE69.2070008@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 05 Jul 2005 00:55:37 +0200
> David S. Miller a écrit :
>
> > Please don't ever do stuff like that :-( That makes the driver
> > version, and any other information you report completely meaningless
> > and useless. You've just wasted a lot of our time.
> >
>
> Yes. But if you dont want us to test your patches, dont send them to
> the list.
The case here is that you didn't even mention that you had
the patch applied. If you don't say what changes you've applied
to the stock driver we can't properly debug anything.
> For your information, 2.6.13-rc1 locks too.
>
> Very easy way to lock it :
>
> ping -f some_destination.
SMP system? What platform and 570x chip revision?
Does the stock driver in 2.6.12 hang as well?
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, mchan, netdev
In-Reply-To: <42C9BE69.2070008@cosmosbay.com>
Eric Dumazet a écrit :
>
> For your information, 2.6.13-rc1 locks too.
>
> Very easy way to lock it :
>
> ping -f some_destination.
Arg. False alarm. Sorry.
Time for me to sleep.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:55 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, netdev
In-Reply-To: <20050704.154712.63128211.davem@davemloft.net>
David S. Miller a écrit :
> Please don't ever do stuff like that :-( That makes the driver
> version, and any other information you report completely meaningless
> and useless. You've just wasted a lot of our time.
>
Yes. But if you dont want us to test your patches, dont send them to the list.
For your information, 2.6.13-rc1 locks too.
Very easy way to lock it :
ping -f some_destination.
> I have no idea to even know _WHICH_ IRQ spinlock patch you applied.
>
> The one that ended up in Linus's tree has many bug fixes and
> refinements. The ones which were posted on netdev had many bugs and
> deadlocks which needed to be cured before pushing the change upstream.
>
>
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, mchan, netdev
In-Reply-To: <42C9B8DB.7020403@cosmosbay.com>
Eric Dumazet a écrit :
>
>
> Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all
> hw IRQ handler spinlocks.
> (Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT))
>
> Maybe I should revert to stock 2.6.12 tg3 driver ?
>
> Eric
>
>
Oh well, I checked 2.6.13-rc1 and it contains this line in tg3_netif_stop() :
+ tp->dev->trans_start = jiffies; /* prevent tx timeout */
So I am trying driver 3.32 June 24, 2005, included in 2.6.13-rc1
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 22:47 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9B8DB.7020403@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 05 Jul 2005 00:31:55 +0200
> Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all hw IRQ handler spinlocks.
> (Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT))
>
> Maybe I should revert to stock 2.6.12 tg3 driver ?
Please don't ever do stuff like that :-( That makes the driver
version, and any other information you report completely meaningless
and useless. You've just wasted a lot of our time.
I have no idea to even know _WHICH_ IRQ spinlock patch you applied.
The one that ended up in Linus's tree has many bug fixes and
refinements. The ones which were posted on netdev had many bugs and
deadlocks which needed to be cured before pushing the change upstream.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 22:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, mchan, netdev
In-Reply-To: <42C9AC97.1020902@cosmosbay.com>
Eric Dumazet a écrit :
> David S. Miller a écrit :
>
>> From: Eric Dumazet <dada1@cosmosbay.com>
>> Date: Mon, 04 Jul 2005 23:22:12 +0200
>>
>>
>>> But it seems something is wrong because when network load becomes
>>> high I get :
>>>
>>> Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>> Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>> Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>> Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>> Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>
>>
>>
>> Does this happen without changing the coalescing settings
>> at all?
>>
>>
> Not easy to answer because I have to rebuild a kernel and reboot. Will
> do that shortly.
>
>
>
Oops, I forgot to tell you I applied the patch : [TG3]: Eliminate all hw IRQ handler spinlocks.
(Date: Fri, 03 Jun 2005 12:25:58 -0700 (PDT))
Maybe I should revert to stock 2.6.12 tg3 driver ?
Eric
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 21:49 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9AC97.1020902@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 04 Jul 2005 23:39:35 +0200
> Not easy to answer because I have to rebuild a kernel and
> reboot. Will do that shortly.
Thanks.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 21:39 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, netdev
In-Reply-To: <20050704.142604.18592223.davem@davemloft.net>
David S. Miller a écrit :
> From: Eric Dumazet <dada1@cosmosbay.com>
> Date: Mon, 04 Jul 2005 23:22:12 +0200
>
>
>>But it seems something is wrong because when network load becomes high I get :
>>
>>Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>>Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
>>Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
>
>
> Does this happen without changing the coalescing settings
> at all?
>
>
Not easy to answer because I have to rebuild a kernel and reboot. Will do that shortly.
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: David S. Miller @ 2005-07-04 21:26 UTC (permalink / raw)
To: dada1; +Cc: mchan, netdev
In-Reply-To: <42C9A884.1030906@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 04 Jul 2005 23:22:12 +0200
> But it seems something is wrong because when network load becomes high I get :
>
> Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
> Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
> Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
> Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Does this happen without changing the coalescing settings
at all?
^ permalink raw reply
* Re: [TG3]: About hw coalescing infrastructure.
From: Eric Dumazet @ 2005-07-04 21:22 UTC (permalink / raw)
To: Michael Chan; +Cc: David S. Miller, netdev
In-Reply-To: <1119467012.5325.15.camel@rh4>
Michael Chan a écrit :
> On Wed, 2005-06-22 at 17:25 +0200, Eric Dumazet wrote:
>
>
>>Is there anything I can try to tune the coalescing ?
>>Being able to handle 100 packets each interrupt instead of one or two would certainly help.
>>I dont mind about latency. But of course I would like not to drop packets :)
>>But maybe the BCM5702 is not able to delay an interrupt ?
>>
>
>
> On the 5702 that supports CLRTCKS mode, you need to play around with the
> following parameters in tg3.h. To reduce interrupts, you generally have
> to increase the values.
>
> #define LOW_RXCOL_TICKS_CLRTCKS 0x00000014
> #define LOW_TXCOL_TICKS_CLRTCKS 0x00000048
> #define LOW_RXMAX_FRAMES 0x00000005
> #define LOW_TXMAX_FRAMES 0x00000035
> #define DEFAULT_RXCOAL_TICK_INT_CLRTCKS 0x00000014
> #define DEFAULT_TXCOAL_TICK_INT_CLRTCKS 0x00000014
> #define DEFAULT_RXCOAL_MAXF_INT 0x00000005
> #define DEFAULT_TXCOAL_MAXF_INT 0x00000005
>
>
>
Thanks Michael
I tried various settings.
# ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: off TX: off
stats-block-usecs: 1000000
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0
rx-usecs: 500
rx-frames: 20
rx-usecs-irq: 500
rx-frames-irq: 20
tx-usecs: 600
tx-frames: 53
tx-usecs-irq: 600
tx-frames-irq: 20
rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0
rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0
But it seems something is wrong because when network load becomes high I get :
Jul 4 23:01:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:29 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:34 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:34 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:39 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:39 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:44 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:44 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:49 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:49 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:54 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:54 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:01:59 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:01:59 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:04 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:04 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:09 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:09 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:14 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:14 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:19 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:19 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:24 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:24 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:29 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:29 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:34 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:34 dada1 kernel: tg3: eth0: transmit timed out, resetting
Jul 4 23:02:39 dada1 kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jul 4 23:02:39 dada1 kernel: tg3: eth0: transmit timed out, resetting
Then the machine crashes at this point.
tg3.c :
#define DRV_MODULE_VERSION "3.31"
#define DRV_MODULE_RELDATE "June 8, 2005"
# ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 511
RX Mini: 0
RX Jumbo: 255
TX: 0
Current hardware settings:
RX: 400
RX Mini: 0
RX Jumbo: 40
TX: 511
Thank you
Eric Dumazet
^ permalink raw reply
* Re: [2.6 patch] fix IP_FIB_HASH kconfig warning
From: Roman Zippel @ 2005-07-04 18:27 UTC (permalink / raw)
To: Adrian Bunk; +Cc: netdev, linux-kernel
In-Reply-To: <20050703222002.GQ5346@stusta.de>
Hi,
On Mon, 4 Jul 2005, Adrian Bunk wrote:
> --- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old 2005-07-02 20:07:25.000000000 +0200
> +++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig 2005-07-02 20:13:05.000000000 +0200
> @@ -58,8 +58,9 @@
> depends on IP_ADVANCED_ROUTER
> default IP_FIB_HASH
>
> -config IP_FIB_HASH
> +config ASK_IP_FIB_HASH
> bool "FIB_HASH"
> + select IP_FIB_HASH
> ---help---
> Current FIB is very proven and good enough for most users.
>
> @@ -84,12 +85,9 @@
>
> endchoice
>
> -# If the user does not enable advanced routing, he gets the safe
> -# default of the fib-hash algorithm.
> config IP_FIB_HASH
> bool
> - depends on !IP_ADVANCED_ROUTER
> - default y
> + default y if !IP_ADVANCED_ROUTER
>
> config IP_MULTIPLE_TABLES
> bool "IP: policy routing"
I'd prefer to do it without select.
config IP_FIB_HASH
def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER
bye, Roman
^ permalink raw reply
* Re: ipw2100: more cleanups
From: Pavel Machek @ 2005-07-04 7:05 UTC (permalink / raw)
To: Zhu Yi; +Cc: jketreno, netdev, jbohac, jbenc
In-Reply-To: <1120456146.27821.85.camel@debian.sh.intel.com>
Hi!
> > More cleanups (relative to ipw2100-1.1.0 version). Highlights include
> > removing of two printk wrappers.
>
> [snip]
>
> > -static DEVICE_ATTR(bssinfo, S_IRUGO, show_bssinfo, NULL);
>
> Any special reason to remove these driver sysfs entries?
Umm, yes, they should not be needed and we do not want to maintain
them in /sys forever. /sys should be "one value per file", and
definitely not for debugging stuff like this. (See debugfs)
Anyway I think I did drop that patch from newer cleanup attempts.
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
^ permalink raw reply
* Re: ipw2100: more cleanups
From: Zhu Yi @ 2005-07-04 5:49 UTC (permalink / raw)
To: Pavel Machek; +Cc: jketreno, netdev, jbohac, jbenc
In-Reply-To: <20050513214025.GA1863@elf.ucw.cz>
On Fri, 2005-05-13 at 23:40 +0200, Pavel Machek wrote:
> More cleanups (relative to ipw2100-1.1.0 version). Highlights include
> removing of two printk wrappers.
[snip]
> -static DEVICE_ATTR(bssinfo, S_IRUGO, show_bssinfo, NULL);
Any special reason to remove these driver sysfs entries?
Thanks,
-yi
^ permalink raw reply
* [2.6 patch] fix IP_FIB_HASH kconfig warning
From: Adrian Bunk @ 2005-07-03 22:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, zippel
[ This time with a subject... ]
This patch fixes the following kconfig warning:
net/ipv4/Kconfig:92:warning: defaults for choice values not supported
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
I've Cc'ed Roman because I might have missed a more elegant solution.
--- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old 2005-07-02 20:07:25.000000000 +0200
+++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig 2005-07-02 20:13:05.000000000 +0200
@@ -58,8 +58,9 @@
depends on IP_ADVANCED_ROUTER
default IP_FIB_HASH
-config IP_FIB_HASH
+config ASK_IP_FIB_HASH
bool "FIB_HASH"
+ select IP_FIB_HASH
---help---
Current FIB is very proven and good enough for most users.
@@ -84,12 +85,9 @@
endchoice
-# If the user does not enable advanced routing, he gets the safe
-# default of the fib-hash algorithm.
config IP_FIB_HASH
bool
- depends on !IP_ADVANCED_ROUTER
- default y
+ default y if !IP_ADVANCED_ROUTER
config IP_MULTIPLE_TABLES
bool "IP: policy routing"
^ permalink raw reply
* Реклама для Вас
From: Лариса @ 2005-07-03 17:52 UTC (permalink / raw)
To: netdev
Оперативная доставка рекламы
на электронные ящики потенциальных клиентов.
Мы поможем и вам стать известными!
icq - 2 9 2 5 9 3 9 7 3
site - 9911.ws
tel +7 (905) 203~90~72
Operativnaja dostavka reklamy
na elektronnye jashiki potencial'nyh klientov.
My pomoj`em i vam stat' izvestnymi!
^ permalink raw reply
* [-mm patch] net/ieee80211/: remove pci.h #include's
From: Adrian Bunk @ 2005-07-02 23:51 UTC (permalink / raw)
To: jgarzik; +Cc: jkmaline, hostap, netdev, linux-kernel
I was wondering why editing pci.h triggered the rebuild of three files
under net/, and as far as I can see, there's no reason for these three
files to #include pci.h .
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 30 May 2005
- 1 May 2005
net/ieee80211/ieee80211_module.c | 1 -
net/ieee80211/ieee80211_rx.c | 1 -
net/ieee80211/ieee80211_tx.c | 1 -
3 files changed, 3 deletions(-)
--- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c.old 2005-04-30 23:23:14.000000000 +0200
+++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_module.c 2005-04-30 23:23:18.000000000 +0200
@@ -40,7 +40,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/pci.h>
#include <linux/proc_fs.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
--- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c.old 2005-04-30 23:23:25.000000000 +0200
+++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_tx.c 2005-04-30 23:23:32.000000000 +0200
@@ -33,7 +33,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/pci.h>
#include <linux/proc_fs.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
--- linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c.old 2005-04-30 23:23:42.000000000 +0200
+++ linux-2.6.12-rc3-mm1-full/net/ieee80211/ieee80211_rx.c 2005-04-30 23:23:46.000000000 +0200
@@ -23,7 +23,6 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/netdevice.h>
-#include <linux/pci.h>
#include <linux/proc_fs.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
^ permalink raw reply
* [RFC: -mm patch] remove unused IPW2100_PROMISC option
From: Adrian Bunk @ 2005-07-02 21:52 UTC (permalink / raw)
To: ipw2100-admin, jgarzik; +Cc: linux-kernel, netdev
This patch removes a completely unsed option.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc1-mm1-full/drivers/net/wireless/Kconfig.old 2005-07-02 22:41:09.000000000 +0200
+++ linux-2.6.13-rc1-mm1-full/drivers/net/wireless/Kconfig 2005-07-02 22:41:17.000000000 +0200
@@ -164,15 +164,6 @@
say M here and read <file:Documentation/modules.txt>. The module
will be called ipw2100.ko.
-config IPW2100_PROMISC
- bool "Enable promiscuous mode"
- depends on IPW2100
- ---help---
- Enables promiscuous/monitor mode support for the ipw2100 driver.
- With this feature compiled into the driver, you can switch to
- promiscuous mode via the Wireless Tool's Monitor mode. While in this
- mode, no packets can be sent.
-
config IPW_DEBUG
bool "Enable full debugging output in IPW2100 module."
depends on IPW2100
^ permalink raw reply
* [-mm patch] drivers/net/wireless/ipw2200.c: remove division by zero
From: Adrian Bunk @ 2005-07-02 21:51 UTC (permalink / raw)
To: ipw2100-admin, jgarzik; +Cc: linux-kernel, netdev
gcc correctly complained about a division by zero for HZ < 1000.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.13-rc1-mm1-full/drivers/net/wireless/ipw2200.c.old 2005-07-02 23:14:39.000000000 +0200
+++ linux-2.6.13-rc1-mm1-full/drivers/net/wireless/ipw2200.c 2005-07-02 23:15:39.000000000 +0200
@@ -1170,7 +1170,7 @@
HOST_COMPLETE_TIMEOUT);
if (rc == 0) {
IPW_DEBUG_INFO("Command completion failed out after %dms.\n",
- HOST_COMPLETE_TIMEOUT / (HZ / 1000));
+ (1000 * HOST_COMPLETE_TIMEOUT) / HZ);
priv->status &= ~STATUS_HCMD_ACTIVE;
return -EIO;
}
^ permalink raw reply
* [2.6 patch]
From: Adrian Bunk @ 2005-07-02 21:48 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, zippel
This patch fixes the following kconfig warning:
net/ipv4/Kconfig:92:warning: defaults for choice values not supported
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
I've Cc'ed Roman because I might have missed a more elegant solution.
--- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old 2005-07-02 20:07:25.000000000 +0200
+++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig 2005-07-02 20:13:05.000000000 +0200
@@ -58,8 +58,9 @@
depends on IP_ADVANCED_ROUTER
default IP_FIB_HASH
-config IP_FIB_HASH
+config ASK_IP_FIB_HASH
bool "FIB_HASH"
+ select IP_FIB_HASH
---help---
Current FIB is very proven and good enough for most users.
@@ -84,12 +85,9 @@
endchoice
-# If the user does not enable advanced routing, he gets the safe
-# default of the fib-hash algorithm.
config IP_FIB_HASH
bool
- depends on !IP_ADVANCED_ROUTER
- default y
+ default y if !IP_ADVANCED_ROUTER
config IP_MULTIPLE_TABLES
bool "IP: policy routing"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox