Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*NETDEV_CHANGE\s+events\s+when\s+__LINK_STATE_NOCARRIER\s+is\s+modified\s*$/: 24 ]

Total 24 documents matching your query.

1. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Thu, 3 May 2001 19:03:44 -0400
Does anyone have an opinion or insight on this? Janice __________________________________________________________________ Janice Girouard girouard@xxxxxxxxxx 512-838-7981 -- Forwarded by Janice Girou
/archives/netdev/2001-05/msg00064.html (10,699 bytes)

2. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Thu, 3 May 2001 17:01:52 -0700 (PDT)
It is not a physical state change. This state bit is meant only as a hack for the isdn layers dial on demand like functionality. This is not the kind of state change the notifier chain listeners are
/archives/netdev/2001-05/msg00065.html (9,963 bytes)

3. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 4 May 2001 16:07:24 +1000 (EST)
<snip> (presuming first that these events can be propagated up to user space through some kind of listen on a socket style API, something that I don't think is possible _yet_) I beg to differ a littl
/archives/netdev/2001-05/msg00070.html (10,217 bytes)

4. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 4 May 2001 12:07:56 -0400
When I look at the timer.c code in the tulip directory, I can see that ethernet drivers are already using this flag to show the health of the card. I also see * xircom_cb.c set's this flag to show a
/archives/netdev/2001-05/msg00076.html (11,251 bytes)

5. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 04 May 2001 10:19:38 -0700
Consider these states, which most network drivers go through in about this order (if they distinguish them): (a) network interface (hardware) is present (b) interface is registered (c) hardware is co
/archives/netdev/2001-05/msg00077.html (14,004 bytes)

6. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 4 May 2001 20:17:02 +0200
Not the current ones. It would be useful in some cases to trigger a TCP retransmit though. This is needed for good behaviour on dynamic IP addresses with the ip_dynaddr hack. ip_dynaddr can only rewr
/archives/netdev/2001-05/msg00078.html (10,921 bytes)

7. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 04 May 2001 15:12:22 -0400
I either implemented these or suggested implementation to the driver authors... Alexey implemented netif_carrier_foo for tulip. I didn't put it into other drivers when someone (at the Summit?) pointe
/archives/netdev/2001-05/msg00079.html (10,096 bytes)

8. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 4 May 2001 15:15:12 -0400
I'm not sure I understand your comment. When you say "But it does seem to me that transitions to state (c) above are problematic just now." are you saying you don't think that we are currently able t
/archives/netdev/2001-05/msg00080.html (14,706 bytes)

9. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 04 May 2001 12:28:50 -0700
It's only a local marking. If Andi implements a mechanism and first client for it, then that'll fix this issue. I want to know exactly what that transition means, too. Notice that I was putting this
/archives/netdev/2001-05/msg00081.html (16,428 bytes)

10. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 4 May 2001 21:24:08 -0400 (EDT)
As well as SCTP could use this for failover. If i am not mistaken it was Alexey that removed this from the netlink interface sometime around 2.3. The problem was that link notification was done at in
/archives/netdev/2001-05/msg00083.html (10,235 bytes)

11. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Fri, 4 May 2001 18:50:31 -0700 (PDT)
I believe these events get sent to the cardmgr daemon and it does all the ifconf magic to change the device state. Later, David S. Miller davem@xxxxxxxxxx
/archives/netdev/2001-05/msg00085.html (9,463 bytes)

12. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: xxxxxx>
Date: Sat, 05 May 2001 16:03:41 +1000
schedule_task(). The now-standard way of punting asynchronous events up into process context. Yeah, we need to sort out the netif_carrier stuff. Some userspace apps want async notifications when the
/archives/netdev/2001-05/msg00086.html (9,736 bytes)

13. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: "Janice Girouard" <girouard@xxxxxxxxxx>
Date: Thu, 3 May 2001 19:03:44 -0400
Does anyone have an opinion or insight on this? Janice __________________________________________________________________ Janice Girouard girouard@xxxxxxxxxx 512-838-7981 -- Forwarded by Janice Girou
/archives/netdev/2001-05/msg00201.html (10,699 bytes)

14. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxx>
Date: Thu, 3 May 2001 17:01:52 -0700 (PDT)
It is not a physical state change. This state bit is meant only as a hack for the isdn layers dial on demand like functionality. This is not the kind of state change the notifier chain listeners are
/archives/netdev/2001-05/msg00202.html (10,113 bytes)

15. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: Roger Venning <c729953@xxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 4 May 2001 16:07:24 +1000 (EST)
<snip> (presuming first that these events can be propagated up to user space through some kind of listen on a socket style API, something that I don't think is possible _yet_) I beg to differ a littl
/archives/netdev/2001-05/msg00207.html (10,248 bytes)

16. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: "Janice Girouard" <girouard@xxxxxxxxxx>
Date: Fri, 4 May 2001 12:07:56 -0400
When I look at the timer.c code in the tulip directory, I can see that ethernet drivers are already using this flag to show the health of the card. I also see * xircom_cb.c set's this flag to show a
/archives/netdev/2001-05/msg00213.html (11,251 bytes)

17. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: David Brownell <david-b@xxxxxxxxxxx>
Date: Fri, 04 May 2001 10:19:38 -0700
Consider these states, which most network drivers go through in about this order (if they distinguish them): (a) network interface (hardware) is present (b) interface is registered (c) hardware is co
/archives/netdev/2001-05/msg00214.html (14,079 bytes)

18. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Fri, 4 May 2001 20:17:02 +0200
Not the current ones. It would be useful in some cases to trigger a TCP retransmit though. This is needed for good behaviour on dynamic IP addresses with the ip_dynaddr hack. ip_dynaddr can only rewr
/archives/netdev/2001-05/msg00215.html (11,174 bytes)

19. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: Jeff Garzik <jgarzik@xxxxxxxxxxxxxxxx>
Date: Fri, 04 May 2001 15:12:22 -0400
I either implemented these or suggested implementation to the driver authors... Alexey implemented netif_carrier_foo for tulip. I didn't put it into other drivers when someone (at the Summit?) pointe
/archives/netdev/2001-05/msg00216.html (10,171 bytes)

20. Re: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified (score: 1)
Author: "Janice Girouard" <girouard@xxxxxxxxxx>
Date: Fri, 4 May 2001 15:15:12 -0400
I'm not sure I understand your comment. When you say "But it does seem to me that transitions to state (c) above are problematic just now." are you saying you don't think that we are currently able t
/archives/netdev/2001-05/msg00217.html (14,706 bytes)


This search system is powered by Namazu