Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*tx_timeout\s+and\s+timer\s+serialisation\s*$/: 102 ]

Total 102 documents matching your query.

1. tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 02 May 2000 01:19:41 +1000
In 3c59x we have a timer routine for media selection. It is set up with add_timer(). It is called from a BH (or whatever we call BH's in 2.3) We also have the tx_timeout routine which is called from
/archives/netdev/2000-05/msg00001.html (8,109 bytes)

2. Re: tx_timeout and timer serialisation (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: Mon, 1 May 2000 11:46:08 -0400 (EDT)
Hacking away those last minutes? ;-> Not Alexey, but i can give you some answers. you mean the dev->hard_start_xmit() ? This is called only from the non interupt context; the only exception i can th
/archives/netdev/2000-05/msg00002.html (9,908 bytes)

3. Re: tx_timeout and timer serialisation (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Mon, 1 May 2000 21:14:13 +0400 (MSK DST)
tx_timeout and hard_start_xmit are serialized by core and never overlap. The way, how driver protects itself of its own internal events, (media selection timer in this case) is its own internal prob
/archives/netdev/2000-05/msg00004.html (9,435 bytes)

4. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 02 May 2000 11:37:07 +1000
Had a little problem with the corporate Amex. 24 hrs delay.. You're less entertaining :) [ stuff ] OK, thanks, guys. 1: hard_start_xmit and tx_timeout are serialised wrt each other. 2: timer function
/archives/netdev/2000-05/msg00012.html (9,975 bytes)

5. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Tue, 02 May 2000 04:29:00 +0000
That email sounded whiny. I'm not whining - I will sit down and work through these drivers starting in 1-2 weeks time, if we agree it would be useful. But I'd be interested in hearing from more exper
/archives/netdev/2000-05/msg00013.html (8,835 bytes)

6. Re: tx_timeout and timer serialisation (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Tue, 2 May 2000 17:34:33 +0400 (MSK DST)
Add set_multicast_list() to this list. Media timer is separate item, it is inivisible from outside at all. ioctl() is allowed to sleep, hence top level cannot do anything to serialize it wrt class 1
/archives/netdev/2000-05/msg00014.html (10,938 bytes)

7. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Wed, 03 May 2000 00:27:07 +1000
I believe you are correct. This is a good approach, because the mdio functions, although rarely called, are slow. 3Com's GPL'ed driver for the 3c90x series is interesting. They use four spinlocks. -
/archives/netdev/2000-05/msg00015.html (12,312 bytes)

8. Re: tx_timeout and timer serialisation (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Tue, 2 May 2000 16:47:36 +0200
+ Inherent deadlock with disable_irq() [the driver likes to lock up under high load on SMP] The Intel e100 driver does that too. It is probably wrong (interrupt can race with TX) -Andi
/archives/netdev/2000-05/msg00017.html (9,756 bytes)

9. Re: tx_timeout and timer serialisation (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Tue, 2 May 2000 19:49:00 +0400 (MSK DST)
Indeed 8) Where can I find it? Do not forget, it is under dev->xmit_lock! If media timer will grab it too -> deadlock. Yes. Well, if this function were _correct_... 8) Essentially, it is replacement
/archives/netdev/2000-05/msg00018.html (11,818 bytes)

10. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Wed, 3 May 2000 10:39:22 +0800
Calling del_timer_sync() may look dangerous, but media timer doesn't grab any locks (and I will keep it this way in the future). [snip] That's it. I made a mistake by not calling timer_exit(), I'll
/archives/netdev/2000-05/msg00024.html (10,903 bytes)

11. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Date: Wed, 3 May 2000 10:45:26 +0800
[snip] mdio functions are called only from timer handler, open, and ioctl. They touch only MDIO specific control register, so they can be serialised by BH protection. I'll do it for eepro100 driver
/archives/netdev/2000-05/msg00025.html (9,463 bytes)

12. Re: tx_timeout and timer serialisation (score: 1)
Author: Bogdan Costescu <Bogdan.Costescu@xxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 3 May 2000 16:17:56 +0200 (CEST)
http://support.3com.com/infodeli/tools/nic/linux.htm Sorry, I didn't understand from this discussion if hard_start_xmit is protected WRT itself outside the driver or the driver should implement locks
/archives/netdev/2000-05/msg00026.html (10,286 bytes)

13. Re: tx_timeout and timer serialisation (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Wed, 3 May 2000 21:17:06 +0400 (MSK DST)
I said _code_. I did not see it too. Until understood that scheme for unloading netdevice modules (which I had assurance to claim to be the only modules, which are unloaded really cleanly 8)8)) is s
/archives/netdev/2000-05/msg00028.html (9,410 bytes)

14. Re: tx_timeout and timer serialisation (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Wed, 3 May 2000 22:08:42 +0400 (MSK DST)
It is. It should not. Alexey
/archives/netdev/2000-05/msg00030.html (9,586 bytes)

15. Re: tx_timeout and timer serialisation (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Fri, 5 May 2000 01:15:25 -0400 (EDT)
Here is the write-up I have in pci-skeleton.c v2.** from http://www.scyld.com/network/index.html ftp://scyld.com/pub/network/ ________________ IIId. SMP semantics The following are serialized with re
/archives/netdev/2000-05/msg00034.html (14,008 bytes)

16. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Thu, 11 May 2000 02:24:54 +0000
Hello indeed. I'm catching up on a week away... [ Regarding del_timer_sync() ] Why does the handler have to call timer_exit() at all? Could we not clear timer->running in run_timer_list()? That would
/archives/netdev/2000-05/msg00048.html (9,847 bytes)

17. Re: tx_timeout and timer serialisation (score: 1)
Author: kuznet@xxxxxxxxxxxxx
Date: Thu, 11 May 2000 17:09:29 +0400 (MSK DST)
Timers are self-destructable as rule. See? Normal usage for timer is to have it allocated inside an object and timer event detroys the object together with timer. In this case we have to use refcoun
/archives/netdev/2000-05/msg00049.html (9,839 bytes)

18. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Fri, 19 May 2000 00:06:05 +1000
I think there's a race in the timer code at present: int del_timer_sync(struct timer_list * timer) { int ret = 0; for (;;) { unsigned long flags; int running; spin_lock_irqsave(&timerlist_lock, flags
/archives/netdev/2000-05/msg00060.html (12,199 bytes)

19. Re: tx_timeout and timer serialisation (score: 1)
Author: Donald Becker <becker@xxxxxxxxx>
Date: Thu, 18 May 2000 10:34:02 -0400 (EDT)
I'm curious -- what code does this? I don't see the semantic problem here. This was the recommended way to use the timer routines. If the semantics have changed, there should be new names for the cha
/archives/netdev/2000-05/msg00061.html (10,854 bytes)

20. Re: tx_timeout and timer serialisation (score: 1)
Author: Andrew Morton <andrewm@xxxxxxxxxx>
Date: Fri, 19 May 2000 01:39:21 +1000
me too. Well, the timer handler could be executing on another CPU _while_ the timer is being deleted. So when del_timer() returns, the handler is still executing! So in this example, CPU0 could execu
/archives/netdev/2000-05/msg00068.html (12,003 bytes)


This search system is powered by Namazu