Re: Network drivers that don't suspend on interface down
Hi! > > about your driver list; > > do you have an idea of what the top 5 relevant ones would be? > > I'd be surprised if the top 5 together had less than 95% market share, > > so if we fix those we'd be mostly done already. > > In terms of what I've seen on vaguely modern hardware, I'd guess at > e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, e1000 already powersaves when cable is not plugged in. Difference is ~0.5W, IIRC. Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Hi! about your driver list; do you have an idea of what the top 5 relevant ones would be? I'd be surprised if the top 5 together had less than 95% market share, so if we fix those we'd be mostly done already. In terms of what I've seen on vaguely modern hardware, I'd guess at e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, e1000 already powersaves when cable is not plugged in. Difference is ~0.5W, IIRC. Pavel -- Thanks for all the (sleeping) penguins. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, Dec 21, 2006 at 01:27:55PM -0500, [EMAIL PROTECTED] wrote: > On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said: > > It's also complicated because some switches are supposed to rfkill both > > an 802.11 module _and_ a bluetooth module at the same time, or I guess > > some laptops may even have one rfkill switch for each wireless device. > > On my Dell D820, it's bios-selectable if the switch is enabled, or if > it controls just the 802.11 card, or 802.11 and bluetooth, or just bluetooth, > or 802.11 and mobile broadband, or ... > > This way lies madness. :) > > (Oddest part - said bios config screen offers the choices for bluetooth > and mobile broadband even though the hardware config doesn't include it. ;) In this case changing the UI based on presence (and thus the printed docs etc.) winds up being difficult. Think of it as an embedded advertisement - you too could have bluetooth and mobile broadband... :-) -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Matthew Garrett <[EMAIL PROTECTED]> wrote:
>
> In terms of what I've seen on vaguely modern hardware, I'd guess at
> e1000 and sky2 as the top ones. b44 is still common in cheaper hardware,
> with via-rhine appearing at the very low end. I'll try to grep through
> our hardware database results to get a stronger idea about percentages.
The Sony laptop that I bought a year ago still has an e100 chipset so
that's probably worth fixing too.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said: > It's also complicated because some switches are supposed to rfkill both > an 802.11 module _and_ a bluetooth module at the same time, or I guess > some laptops may even have one rfkill switch for each wireless device. On my Dell D820, it's bios-selectable if the switch is enabled, or if it controls just the 802.11 card, or 802.11 and bluetooth, or just bluetooth, or 802.11 and mobile broadband, or ... This way lies madness. :) (Oddest part - said bios config screen offers the choices for bluetooth and mobile broadband even though the hardware config doesn't include it. ;) pgpcHoBKfiLmE.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 14:19 +0100, Sven-Haegar Koch wrote: > On Wed, 20 Dec 2006, Dan Williams wrote: > > >> If we define interface down as meaning that the device is powered down > >> and the radio switched off, then (b) and (c) would presumably just need > >> to ensure that the interface is downed. (a) is a slightly more special > >> case - if the switch disables the radio, I guess we then want the driver > >> to down the interface as well. > > > > Correct. > > > >> In the (a) case, drivers should presumably refuse to bring the interface > >> up if the radio is disabled? > > > > Right; the driver simply can't do anything about it, because the switch > > is hardwired to the card and either the card's firmware takes care of > > it, or the chipset takes care of it. The driver has no say whatsoever > > in the state of the card's radio for this case. I tend to think this > > case is on it's way out in the same way that fullmac cards are falling > > out of favor (ie, do everything in software and save $$$), but they are > > around and we need to support them. > > > > In this case, down really does mean down too. The driver cannot honor > > requests to set SSID, frequency, etc, because it's simply not possible > > at that time. > > What do you mean with this exactly? > Should the user not be able to set these values, or should the driver not > be able to activate them? > > I think it is correct when the driver does not activate them, but I think > the user should be able to configure them, have them stored inside > cfg80211/the driver, and have them activated/used when uping the > interface, or when the rfkill switch has been deactivated. Otherwise it > will get impossible to boot with rfkill disabled, toggle the switch later > on and have everything working. This would be an optimization. You could possibly _set_ values, but obviously an 'associate' command would fail, and so it should. But there's really not that much of a point to doing this, because cfg80211 should support "packaging" up all the config for a particular association request into one call, and then just blasting that to the card. Ideally configuration wouldn't be pushed to the card piecemeal. As WEXT stands right now, setting the SSID on the card is essentially the "associate" command, which obviously wouldn't work when the card is down. cfg80211 can fix that, you're right. > And another side to this: > if a disabled rfkill switch downs the interface (opposed to just > disabling it but staying "ifconfig up") - what happens to the ip config > of this interface? What reconfigures the needed routes when a re-enabled > rfkill switch reactivates the interface? Will manual route add and > ifconfig statements be impossible and we'll get forced to use some crappy > distri-scripts and daemons for it? For anything other than unencrypted and WEP-only networks, you already need a userspace program to configure your wireless card. Dynamic WEP, LEAP, WPA, WPA2, 802.1x all require much, much more handshake and validation that should _ever_ be in a driver. You should _never_, ever be configuring your wireless card with module parameters. I'm sure something like iwconfig would be fine to configure your card with. When the card goes down, it normally looses it's association to the access point anyway, and you need to start the assocaition and authentication over completely. At that point, it's no longer guaranteed that you could ever get a previous IP address back. What does downing an ethernet device do? It clears out routes associated with that device, and clears assigned addresses (I think?). Wireless is and should not be any different here. When you bring the device back up, you need to go through some amount of renegotiation anyway. > And third point just coming to my mind: > how is changing the mac address of the card supposed to work? Chaning it > through ifconfig only works when the interface is downed, so the newly > wanted mac address has to be saved somewhere before the interface is > reenabled and reinitialized on the next "ifconfig up". > (And I think it is an absolute requirement that NO packet with the > old/default mac address may be sent into the air whatsoever) That's how it should work. If you want to change the MAC address, the card shouldn't probably be down. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006, Dan Williams wrote: If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (a) is a slightly more special case - if the switch disables the radio, I guess we then want the driver to down the interface as well. Correct. In the (a) case, drivers should presumably refuse to bring the interface up if the radio is disabled? Right; the driver simply can't do anything about it, because the switch is hardwired to the card and either the card's firmware takes care of it, or the chipset takes care of it. The driver has no say whatsoever in the state of the card's radio for this case. I tend to think this case is on it's way out in the same way that fullmac cards are falling out of favor (ie, do everything in software and save $$$), but they are around and we need to support them. In this case, down really does mean down too. The driver cannot honor requests to set SSID, frequency, etc, because it's simply not possible at that time. What do you mean with this exactly? Should the user not be able to set these values, or should the driver not be able to activate them? I think it is correct when the driver does not activate them, but I think the user should be able to configure them, have them stored inside cfg80211/the driver, and have them activated/used when uping the interface, or when the rfkill switch has been deactivated. Otherwise it will get impossible to boot with rfkill disabled, toggle the switch later on and have everything working. And another side to this: if a disabled rfkill switch downs the interface (opposed to just disabling it but staying "ifconfig up") - what happens to the ip config of this interface? What reconfigures the needed routes when a re-enabled rfkill switch reactivates the interface? Will manual route add and ifconfig statements be impossible and we'll get forced to use some crappy distri-scripts and daemons for it? And third point just coming to my mind: how is changing the mac address of the card supposed to work? Chaning it through ifconfig only works when the interface is downed, so the newly wanted mac address has to be saved somewhere before the interface is reenabled and reinitialized on the next "ifconfig up". (And I think it is an absolute requirement that NO packet with the old/default mac address may be sent into the air whatsoever) c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-20-12 at 22:14 -0500, Dan Williams wrote: ... > Simple == good. Down == down. Lets just agree on that and save > ourselves a lot of pain. netdevices have well defined operational and administrative state machines. And very well defined relationship between operational and administrative status. IOW, care should be invoked not to reinvent. Power management to me seems like an operational state. A link could only transition to operational or down depending on whether it is "powered" up or down. To be complete, since a netdevice is a generic construct, nota bene: - a link could be a wireless association or ethernet cable or a PPP session or a ATM PVC, or an infrared channel etc. - events that result in operational link transitions could be anything from powering up an ethernet phy with an active cable plugged to an 802.1x auth on a wireless association to a on-demand ppp link seeing an outgoing packet. IMO, for this discussion to be meaningful, it would be useful to read Documentation/networking/operstates.txt And if you are keen you can then read RFC 2863... cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Stephen Hemminger <[EMAIL PROTECTED]> : [...] > We need to allow ethtool setting to be done before device has been brought > up and started autonegotiation. The current MII library doesn't really support > it. I completely agree. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
> Is there some reason why we can't have the OS just do the D3 > transition for all drivers that register support? I mean, this power > management using D states is actually driver *independent* and at > least way back in the day was supposed to be implemented for "OS power > management" all you need to do is 1 function call from your interface down code.. so it's really not a big deal to just do that call ;) (well and you want the D0 call in the up code, but that's ok) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 11:08 pm, Stephen Hemminger wrote: > David Brownell wrote: > > Hmm, this reminds me of a thread from last summer, following up on > > some PM discussions at OLS. Thread "Runtime power management for > > network interfaces", at the end of July. > > > > > > > >> 2) Network device infrastructure should make it easier for devices: > >> bring interface down on suspend and bring it up after resume > >> (if it was running when suspended). This would allow many devices to > >> have no suspend/resume hook; except those that have some better power > >> control over hardware. > >> > > > > The _intent_ of the class suspend() and resume() methods is to let > > infrastructure (the network stack was explicitly mentioned!) handle > > pretty much everything except putting the hardware in low power > > modes ... which last step might, for PCI devices at least, most > > naturally be done in suspend_late(). That way it'd be decoupled > > cleanly from anything else. > > > The class methods don't work right for that because the physical class > (PCI) gets called before the virtual class (network devices). I'd say they don't work just now because the virtual class code just doesn't get called ... at least, without someone setting up a field (device.class) that's flagged as "optional" and might be disappearing. But if you read the PM code, you'll observe that the class suspend method gets called BEFORE the bus/device suspend method. And that's how it's documented in Documentation/power/devices.txt too. ... However notice that "interface down" operations won't have that particular problem, they have net_device.class_dev.dev already ready for whatever PM operation is appropriate. - Dave > > Now, I recently tried refreshing a patch that used those class > > suspend() and resume() methods, and for some reason they're not > > getting called. I believe they used to get called, although it's > > true their parameter wasn't very useful ... it was called with the > > underlying device, not the class_device holding state that the > > class driver manages. > > > > I just wanted to point out that yes, this ground has been covered > > before, with some agreement on that approach. It'd be good to see > > it pursued. :) > > > > - Dave > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 11:08 pm, Stephen Hemminger wrote: David Brownell wrote: Hmm, this reminds me of a thread from last summer, following up on some PM discussions at OLS. Thread Runtime power management for network interfaces, at the end of July. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. The _intent_ of the class suspend() and resume() methods is to let infrastructure (the network stack was explicitly mentioned!) handle pretty much everything except putting the hardware in low power modes ... which last step might, for PCI devices at least, most naturally be done in suspend_late(). That way it'd be decoupled cleanly from anything else. The class methods don't work right for that because the physical class (PCI) gets called before the virtual class (network devices). I'd say they don't work just now because the virtual class code just doesn't get called ... at least, without someone setting up a field (device.class) that's flagged as optional and might be disappearing. But if you read the PM code, you'll observe that the class suspend method gets called BEFORE the bus/device suspend method. And that's how it's documented in Documentation/power/devices.txt too. ... However notice that interface down operations won't have that particular problem, they have net_device.class_dev.dev already ready for whatever PM operation is appropriate. - Dave Now, I recently tried refreshing a patch that used those class suspend() and resume() methods, and for some reason they're not getting called. I believe they used to get called, although it's true their parameter wasn't very useful ... it was called with the underlying device, not the class_device holding state that the class driver manages. I just wanted to point out that yes, this ground has been covered before, with some agreement on that approach. It'd be good to see it pursued. :) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Is there some reason why we can't have the OS just do the D3 transition for all drivers that register support? I mean, this power management using D states is actually driver *independent* and at least way back in the day was supposed to be implemented for OS power management all you need to do is 1 function call from your interface down code.. so it's really not a big deal to just do that call ;) (well and you want the D0 call in the up code, but that's ok) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Stephen Hemminger [EMAIL PROTECTED] : [...] We need to allow ethtool setting to be done before device has been brought up and started autonegotiation. The current MII library doesn't really support it. I completely agree. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-20-12 at 22:14 -0500, Dan Williams wrote: ... Simple == good. Down == down. Lets just agree on that and save ourselves a lot of pain. netdevices have well defined operational and administrative state machines. And very well defined relationship between operational and administrative status. IOW, care should be invoked not to reinvent. Power management to me seems like an operational state. A link could only transition to operational or down depending on whether it is powered up or down. To be complete, since a netdevice is a generic construct, nota bene: - a link could be a wireless association or ethernet cable or a PPP session or a ATM PVC, or an infrared channel etc. - events that result in operational link transitions could be anything from powering up an ethernet phy with an active cable plugged to an 802.1x auth on a wireless association to a on-demand ppp link seeing an outgoing packet. IMO, for this discussion to be meaningful, it would be useful to read Documentation/networking/operstates.txt And if you are keen you can then read RFC 2863... cheers, jamal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006, Dan Williams wrote: If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (a) is a slightly more special case - if the switch disables the radio, I guess we then want the driver to down the interface as well. Correct. In the (a) case, drivers should presumably refuse to bring the interface up if the radio is disabled? Right; the driver simply can't do anything about it, because the switch is hardwired to the card and either the card's firmware takes care of it, or the chipset takes care of it. The driver has no say whatsoever in the state of the card's radio for this case. I tend to think this case is on it's way out in the same way that fullmac cards are falling out of favor (ie, do everything in software and save $$$), but they are around and we need to support them. In this case, down really does mean down too. The driver cannot honor requests to set SSID, frequency, etc, because it's simply not possible at that time. What do you mean with this exactly? Should the user not be able to set these values, or should the driver not be able to activate them? I think it is correct when the driver does not activate them, but I think the user should be able to configure them, have them stored inside cfg80211/the driver, and have them activated/used when uping the interface, or when the rfkill switch has been deactivated. Otherwise it will get impossible to boot with rfkill disabled, toggle the switch later on and have everything working. And another side to this: if a disabled rfkill switch downs the interface (opposed to just disabling it but staying ifconfig up) - what happens to the ip config of this interface? What reconfigures the needed routes when a re-enabled rfkill switch reactivates the interface? Will manual route add and ifconfig statements be impossible and we'll get forced to use some crappy distri-scripts and daemons for it? And third point just coming to my mind: how is changing the mac address of the card supposed to work? Chaning it through ifconfig only works when the interface is downed, so the newly wanted mac address has to be saved somewhere before the interface is reenabled and reinitialized on the next ifconfig up. (And I think it is an absolute requirement that NO packet with the old/default mac address may be sent into the air whatsoever) c'ya sven -- The Internet treats censorship as a routing problem, and routes around it. (John Gilmore on http://www.cygnus.com/~gnu/) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 14:19 +0100, Sven-Haegar Koch wrote: On Wed, 20 Dec 2006, Dan Williams wrote: If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (a) is a slightly more special case - if the switch disables the radio, I guess we then want the driver to down the interface as well. Correct. In the (a) case, drivers should presumably refuse to bring the interface up if the radio is disabled? Right; the driver simply can't do anything about it, because the switch is hardwired to the card and either the card's firmware takes care of it, or the chipset takes care of it. The driver has no say whatsoever in the state of the card's radio for this case. I tend to think this case is on it's way out in the same way that fullmac cards are falling out of favor (ie, do everything in software and save $$$), but they are around and we need to support them. In this case, down really does mean down too. The driver cannot honor requests to set SSID, frequency, etc, because it's simply not possible at that time. What do you mean with this exactly? Should the user not be able to set these values, or should the driver not be able to activate them? I think it is correct when the driver does not activate them, but I think the user should be able to configure them, have them stored inside cfg80211/the driver, and have them activated/used when uping the interface, or when the rfkill switch has been deactivated. Otherwise it will get impossible to boot with rfkill disabled, toggle the switch later on and have everything working. This would be an optimization. You could possibly _set_ values, but obviously an 'associate' command would fail, and so it should. But there's really not that much of a point to doing this, because cfg80211 should support packaging up all the config for a particular association request into one call, and then just blasting that to the card. Ideally configuration wouldn't be pushed to the card piecemeal. As WEXT stands right now, setting the SSID on the card is essentially the associate command, which obviously wouldn't work when the card is down. cfg80211 can fix that, you're right. And another side to this: if a disabled rfkill switch downs the interface (opposed to just disabling it but staying ifconfig up) - what happens to the ip config of this interface? What reconfigures the needed routes when a re-enabled rfkill switch reactivates the interface? Will manual route add and ifconfig statements be impossible and we'll get forced to use some crappy distri-scripts and daemons for it? For anything other than unencrypted and WEP-only networks, you already need a userspace program to configure your wireless card. Dynamic WEP, LEAP, WPA, WPA2, 802.1x all require much, much more handshake and validation that should _ever_ be in a driver. You should _never_, ever be configuring your wireless card with module parameters. I'm sure something like iwconfig would be fine to configure your card with. When the card goes down, it normally looses it's association to the access point anyway, and you need to start the assocaition and authentication over completely. At that point, it's no longer guaranteed that you could ever get a previous IP address back. What does downing an ethernet device do? It clears out routes associated with that device, and clears assigned addresses (I think?). Wireless is and should not be any different here. When you bring the device back up, you need to go through some amount of renegotiation anyway. And third point just coming to my mind: how is changing the mac address of the card supposed to work? Chaning it through ifconfig only works when the interface is downed, so the newly wanted mac address has to be saved somewhere before the interface is reenabled and reinitialized on the next ifconfig up. (And I think it is an absolute requirement that NO packet with the old/default mac address may be sent into the air whatsoever) That's how it should work. If you want to change the MAC address, the card shouldn't probably be down. Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said: It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. On my Dell D820, it's bios-selectable if the switch is enabled, or if it controls just the 802.11 card, or 802.11 and bluetooth, or just bluetooth, or 802.11 and mobile broadband, or ... This way lies madness. :) (Oddest part - said bios config screen offers the choices for bluetooth and mobile broadband even though the hardware config doesn't include it. ;) pgpcHoBKfiLmE.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
Matthew Garrett [EMAIL PROTECTED] wrote:
In terms of what I've seen on vaguely modern hardware, I'd guess at
e1000 and sky2 as the top ones. b44 is still common in cheaper hardware,
with via-rhine appearing at the very low end. I'll try to grep through
our hardware database results to get a stronger idea about percentages.
The Sony laptop that I bought a year ago still has an e100 chipset so
that's probably worth fixing too.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, Dec 21, 2006 at 01:27:55PM -0500, [EMAIL PROTECTED] wrote: On Wed, 20 Dec 2006 22:06:51 EST, Dan Williams said: It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. On my Dell D820, it's bios-selectable if the switch is enabled, or if it controls just the 802.11 card, or 802.11 and bluetooth, or just bluetooth, or 802.11 and mobile broadband, or ... This way lies madness. :) (Oddest part - said bios config screen offers the choices for bluetooth and mobile broadband even though the hardware config doesn't include it. ;) In this case changing the UI based on presence (and thus the printed docs etc.) winds up being difficult. Think of it as an embedded advertisement - you too could have bluetooth and mobile broadband... :-) -Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
David Brownell wrote: Hmm, this reminds me of a thread from last summer, following up on some PM discussions at OLS. Thread "Runtime power management for network interfaces", at the end of July. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. The _intent_ of the class suspend() and resume() methods is to let infrastructure (the network stack was explicitly mentioned!) handle pretty much everything except putting the hardware in low power modes ... which last step might, for PCI devices at least, most naturally be done in suspend_late(). That way it'd be decoupled cleanly from anything else. The class methods don't work right for that because the physical class (PCI) gets called before the virtual class (network devices). Now, I recently tried refreshing a patch that used those class suspend() and resume() methods, and for some reason they're not getting called. I believe they used to get called, although it's true their parameter wasn't very useful ... it was called with the underlying device, not the class_device holding state that the class driver manages. I just wanted to point out that yes, this ground has been covered before, with some agreement on that approach. It'd be good to see it pursued. :) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Hmm, this reminds me of a thread from last summer, following up on some PM discussions at OLS. Thread "Runtime power management for network interfaces", at the end of July. > 2) Network device infrastructure should make it easier for devices: > bring interface down on suspend and bring it up after resume > (if it was running when suspended). This would allow many devices to > have no suspend/resume hook; except those that have some better power > control over hardware. The _intent_ of the class suspend() and resume() methods is to let infrastructure (the network stack was explicitly mentioned!) handle pretty much everything except putting the hardware in low power modes ... which last step might, for PCI devices at least, most naturally be done in suspend_late(). That way it'd be decoupled cleanly from anything else. Now, I recently tried refreshing a patch that used those class suspend() and resume() methods, and for some reason they're not getting called. I believe they used to get called, although it's true their parameter wasn't very useful ... it was called with the underlying device, not the class_device holding state that the class driver manages. I just wanted to point out that yes, this ground has been covered before, with some agreement on that approach. It'd be good to see it pursued. :) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 03:25 +, Matthew Garrett wrote: > On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote: > > Matthew Garrett wrote: > > >Hm. Does the spec not set any upper bound on how long it might take for > > >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. > > > > I'm not sure, but thats not entirely relevant either. The time it takes > > for the AP to respond is not related to the delay between userspace > > sending the siwscan and giwscan ioctls (unless you're thinking of > > userspace being too quick, but GIWSCAN already returns -EINPROGRESS when > > appropriate so this is detectable) > > Ah - I've mostly been looking at the ipw* drivers, where giwscan just > seems to return information cached by the ieee80211 layer. A quick scan > suggests that most cards behave like this, but prism54 seems to refer to > the hardware. I can see why that would cause problems. Prism54 (fullmac) does background scanning all the time when the interface is up. You can't turn it off AFAIK. If you look at SIWSCAN, you'll see that it's essentially a NOP since the firmware is always scanning, and you'll always have up-to-date scan results. Ideally, all drivers would do it like prism54 does (and some later ipw versions, I think). Dan > > > I think it's reasonable to keep the interface down, but then when the > > user does want to connect, bring the interface up, scan, present scan > > results. Scanning is quick, there would be minimal wait needed here. > > Yeah, that's true. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 03:14 +, Matthew Garrett wrote: > On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote: > > > a) tied to the wireless hardware, switch kills hardware directly > > b) tied to wireless hardware, but driver handles the kill request > > c) just another key, a separate key driver handles the event and asks > > the wireless driver to kill the card > > > > It's also complicated because some switches are supposed to rfkill both > > an 802.11 module _and_ a bluetooth module at the same time, or I guess > > some laptops may even have one rfkill switch for each wireless device. > > Furthermore, some people want to 'softkill' the hardware via software > > without pushing the key, which is a subset of (b) or (c) above. > > If we define interface down as meaning that the device is powered down > and the radio switched off, then (b) and (c) would presumably just need > to ensure that the interface is downed. (a) is a slightly more special > case - if the switch disables the radio, I guess we then want the driver > to down the interface as well. Correct. > In the (a) case, drivers should presumably refuse to bring the interface > up if the radio is disabled? Right; the driver simply can't do anything about it, because the switch is hardwired to the card and either the card's firmware takes care of it, or the chipset takes care of it. The driver has no say whatsoever in the state of the card's radio for this case. I tend to think this case is on it's way out in the same way that fullmac cards are falling out of favor (ie, do everything in software and save $$$), but they are around and we need to support them. In this case, down really does mean down too. The driver cannot honor requests to set SSID, frequency, etc, because it's simply not possible at that time. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 22:08 -0500, Daniel Drake wrote: > Matthew Garrett wrote: > >> There are additional implementation problems: scanning requires 2 > >> different ioctl calls: siwscan, then several giwscan. If you want the > >> driver to effectively temporarily bring the interface up when userspace > >> requests a scan but the interface was down, then how does the driver > >> know when to bring it down again? > > > > Hm. Does the spec not set any upper bound on how long it might take for > > APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. > > I'm not sure, but thats not entirely relevant either. The time it takes > for the AP to respond is not related to the delay between userspace > sending the siwscan and giwscan ioctls (unless you're thinking of > userspace being too quick, but GIWSCAN already returns -EINPROGRESS when > appropriate so this is detectable) Channel dwell time for a passive scan is usually around 100ms - 250ms, depending on how accurate you want your scan results (== wait longer), and how much power you want to save (== don't wait long). Correct userspace apps should: 1) Set a timer for, say, 8 seconds 2) Issue an SIWSCAN command 3) Wait for the GIWSCAN netlink event from the card, get results via GIWSCAN command when it comes; cancel the timer from (2) 4) If the timer fires because no GIWSCAN event was received, try to get scan results via GIWSCAN command from the driver anyway Note that NDIS requires a driver to return _something_ within 2 seconds of a scan request. Even if you're an 802.11a card (madwifi *cough*, I'm starting a new thing where I cough after...). So it's certainly possible to return scan results in a timely manner, since the Windows drivers for these cards are obviously doing it just fine. Drivers should buffer scan results from past scans, age them appropriately, and purge them when they get too old. Drivers should never, ever, clear the scan result list when SIWSCAN or GIWSCAN is called, because that means there's a window when a scan result request from some other app could illegitimately return no BSSID records. > > Picking a number out of thin air would be one answer, but clearly less > > than ideal. This may be a case of us not being able to satisfy everyone, > > and so just having to force the user to choose between low power or > > wireless scanning. > > I think it's reasonable to keep the interface down, but then when the > user does want to connect, bring the interface up, scan, present scan > results. Scanning is quick, there would be minimal wait needed here. Unless you're madwifi *cough* and then you may have to wait up to _14_ seconds for a full scan of all a/bg channels. That's just insane. I have no idea why that's the case (or at least was up to earlier this year) but it's just unacceptable. > Alternatively, if you do want to prepare scan results in the background > every 2 minutes, use a sequence something like: > > - bring interface up > - siwscan > - giwscan [...] > - bring interface down > - repeat after 2 mins > > If this kind of thing was implemented at the driver level, in most cases > it would be identical to doing the above anyway. Right. It should 100% be in userspace and not in the drivers. Who says 2 minutes is the right interval? Putting that stuff, and the get/set commands for changing that interval, in the driver is just plain wrong. Dan > Daniel > - > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote: > Matthew Garrett wrote: > >Hm. Does the spec not set any upper bound on how long it might take for > >APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. > > I'm not sure, but thats not entirely relevant either. The time it takes > for the AP to respond is not related to the delay between userspace > sending the siwscan and giwscan ioctls (unless you're thinking of > userspace being too quick, but GIWSCAN already returns -EINPROGRESS when > appropriate so this is detectable) Ah - I've mostly been looking at the ipw* drivers, where giwscan just seems to return information cached by the ieee80211 layer. A quick scan suggests that most cards behave like this, but prism54 seems to refer to the hardware. I can see why that would cause problems. > I think it's reasonable to keep the interface down, but then when the > user does want to connect, bring the interface up, scan, present scan > results. Scanning is quick, there would be minimal wait needed here. Yeah, that's true. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote: > a) tied to the wireless hardware, switch kills hardware directly > b) tied to wireless hardware, but driver handles the kill request > c) just another key, a separate key driver handles the event and asks > the wireless driver to kill the card > > It's also complicated because some switches are supposed to rfkill both > an 802.11 module _and_ a bluetooth module at the same time, or I guess > some laptops may even have one rfkill switch for each wireless device. > Furthermore, some people want to 'softkill' the hardware via software > without pushing the key, which is a subset of (b) or (c) above. If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (a) is a slightly more special case - if the switch disables the radio, I guess we then want the driver to down the interface as well. In the (a) case, drivers should presumably refuse to bring the interface up if the radio is disabled? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 02:18 +, Matthew Garrett wrote: > On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote: > > > Softmac isn't the only wireless code that likes to be configured after > > going > > up first. Configuring after the card goes up has generally been more > > reliable, though that should not be necessary and is a bug IMHO. > > Ok, that's nice to know. > > > In order to scan, we need to have the radio on and we need to be able to > > send > > and receive. What are you gonna turn off? > > The obvious route would be to power the card down, but come back up > every two minutes to perform a scan, or if userspace explicitly requests > one. Would this cause problems in some cases? Seriously, having all these different capabilities when the card is "down" is just madness. Down == Down!!! Furthermore, every card is going to support some other subset of capabilities when it's "down". When you bring "up" prism54 fullmac card, you have to power up the hardware, reload the firmware, let the firmware boot, and then talk to it. Doing that every 2 minutes is just a waste of time, effort, and power. If you want to scan, just bring the darn card up to do it. It's so much simpler that way, and I just don't see what having all this "every 2 minutes do a scan" policy really buys us. That doesn't belong in the kernel. If something wants to scan, userspace can wake the card up and do the scan. It's userspace that's using the scan results to configure the card anyway, so userspace can do the scan. Simple == good. Down == down. Lets just agree on that and save ourselves a lot of pain. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Matthew Garrett wrote: There are additional implementation problems: scanning requires 2 different ioctl calls: siwscan, then several giwscan. If you want the driver to effectively temporarily bring the interface up when userspace requests a scan but the interface was down, then how does the driver know when to bring it down again? Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. I'm not sure, but thats not entirely relevant either. The time it takes for the AP to respond is not related to the delay between userspace sending the siwscan and giwscan ioctls (unless you're thinking of userspace being too quick, but GIWSCAN already returns -EINPROGRESS when appropriate so this is detectable) Picking a number out of thin air would be one answer, but clearly less than ideal. This may be a case of us not being able to satisfy everyone, and so just having to force the user to choose between low power or wireless scanning. I think it's reasonable to keep the interface down, but then when the user does want to connect, bring the interface up, scan, present scan results. Scanning is quick, there would be minimal wait needed here. Alternatively, if you do want to prepare scan results in the background every 2 minutes, use a sequence something like: - bring interface up - siwscan - giwscan [...] - bring interface down - repeat after 2 mins If this kind of thing was implemented at the driver level, in most cases it would be identical to doing the above anyway. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 01:15 +, Matthew Garrett wrote: > On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote: > > > Entirely correct. If the card is DOWN, the radio should be off (both TX > > & RX) and it should be in max power save mode. If userspace expects to > > be able to get the card to do _anything_ when it's down, that's just > > 110% wrong. You can't get link events for many wired cards when they > > are down, so I fail to see where userspace could expect to do anything > > with a wireless card when it's down too. > > Because it works on the common hardware? If there's documentation about > what userspace can legitimately expect, then I'm happy to defer to that. > But in the absence of any indication as to what functionality users can > depend on, deciding that existing functionality is a bug is, well, > impolite. > > > Also, how does rfkill fit into this? rfkill implies killing TX, but do > > we have the granularity to still receive while the transmit paths are > > powered down? > > Is rfkill not just primarily an interface for us getting events when the > radio changes state? Every time I read up on it I get a little more > confused - some time I really need to make sense of it... That's OK, it's really complicated. There are 3 cases of rfkill switches AFAICT: a) tied to the wireless hardware, switch kills hardware directly b) tied to wireless hardware, but driver handles the kill request c) just another key, a separate key driver handles the event and asks the wireless driver to kill the card It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. Furthermore, some people want to 'softkill' the hardware via software without pushing the key, which is a subset of (b) or (c) above. It sucks. But we _need_ a unified interface to handle it. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 02:20 +, Matthew Garrett wrote: > On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote: > > (allowing scanning while the interface is down) > > > No, it's absolutely a bug. It just so happens that some drivers incorrectly > > allowed it. > > Ok. Would it be reasonable to add warnings to any devices that allow it? Quite reasonable. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 09:38:20PM -0500, Daniel Drake wrote: > I don't think that supporting scanning when the interface is supposed to > be disabled is sensible. If you want to scan, you are simply sending and > receiving frames, it's no different from having the interface up and > sending/receiving data frames. >From a usability point of view, it's helpful to power the card down as much as possible while it's not being actively used. However, it's also helpful to be able to provide a list of available wireless networks, though some degree of latency would be acceptable in that. These two desires are obviously not entirely compatible with one another, so it would be helpful if there was some means of providing an intermediate state. > There are additional implementation problems: scanning requires 2 > different ioctl calls: siwscan, then several giwscan. If you want the > driver to effectively temporarily bring the interface up when userspace > requests a scan but the interface was down, then how does the driver > know when to bring it down again? Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. Picking a number out of thin air would be one answer, but clearly less than ideal. This may be a case of us not being able to satisfy everyone, and so just having to force the user to choose between low power or wireless scanning. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Matthew Garrett wrote: In order to scan, we need to have the radio on and we need to be able to send and receive. What are you gonna turn off? The obvious route would be to power the card down, but come back up every two minutes to perform a scan, or if userspace explicitly requests one. Would this cause problems in some cases? I don't think it makes sense. For zd1211 the power consumption and heat emission goes up considerably when the interface is brought up (radio on, interrupts enabled, etc), and this is also a relatively long operation in terms of duration needed to bring the interface up and down. A scanning operation requires radio on, interrupts enabled, lots of register reading, RF calibration, RX/TX ringbuffers allocation, etc. I don't think that supporting scanning when the interface is supposed to be disabled is sensible. If you want to scan, you are simply sending and receiving frames, it's no different from having the interface up and sending/receiving data frames. There are additional implementation problems: scanning requires 2 different ioctl calls: siwscan, then several giwscan. If you want the driver to effectively temporarily bring the interface up when userspace requests a scan but the interface was down, then how does the driver know when to bring it down again? Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Matthew Garrett wrote: Veering off at something of a tangent - how much of this should be true for wireless devices? Softmac seems to be unhappy about setting the essid unless the card is up, which breaks various assumptions... You might regard that as a bug - I agree it probably makes sense for you to be able to set certain configuration variables before the interface is up, within reason. However, the mentality adopted by most wireless drivers is the SIWESSID wireless extension ioctl means *associate*, something which obviously shouldn't be possible when the interface is down (radio off, etc). While you might blame drivers for this possible misinterpretation, it can also be viewed as a design flaw in WE: the drivers have to handle the ioctl's directly, meaning that if you want some kind of configuration management then you have to do it on the driver level, and this doesn't feel right. The situation is also made worse due to WE generally being hard to implement, and also the lack of documentation (really the only source here is the iwconfig man page). This screams out for an 802.11-centric configuration system, and it looks like we have one on the way: cfg80211 From reading some mails, it looks like the drivers will simply have to provide functions for "associate", "scan", etc, and the configuration management will be offloaded to the upper layers. For the time being, I suggest you bring the interface up before setting the configuration. Regardless of the inconsistency of the current situation, and lack documentation saying which way it should be done, you are at least playing it safe and guaranteeing it works on all drivers. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 20:15, Matthew Garrett wrote: > Because it works on the common hardware? If there's documentation about > what userspace can legitimately expect, then I'm happy to defer to that. > But in the absence of any indication as to what functionality users can > depend on, deciding that existing functionality is a bug is, well, > impolite. > No, it's absolutely a bug. It just so happens that some drivers incorrectly allowed it. -Michael Wu pgp88tOEHFma3.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote: (allowing scanning while the interface is down) > No, it's absolutely a bug. It just so happens that some drivers incorrectly > allowed it. Ok. Would it be reasonable to add warnings to any devices that allow it? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote: > Softmac isn't the only wireless code that likes to be configured after going > up first. Configuring after the card goes up has generally been more > reliable, though that should not be necessary and is a bug IMHO. Ok, that's nice to know. > In order to scan, we need to have the radio on and we need to be able to send > and receive. What are you gonna turn off? The obvious route would be to power the card down, but come back up every two minutes to perform a scan, or if userspace explicitly requests one. Would this cause problems in some cases? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On 12/20/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > Yeah, I guess that's a problem. From a user perspective, the > functionality is only really useful if the latency is very small. I > think where possible we'd want to power down the chip while keeping the > phy up, but it would be nice to know how much power that would actually > cost us. I'm no expert but afaik the PHY is the power hungry part, the rest is peanuts. So if we can get the PHY to sleep most of the time that would be great. The MAC uses some part of power, but FYI at least e1000 already does phy power management when IF_DOWN, if wake on lan isn't enabled, smbus isn't enabled, etc etc. If we started using D3 power management its possible a whole bunch of code would go away out of e1000. Is there some reason why we can't have the OS just do the D3 transition for all drivers that register support? I mean, this power management using D states is actually driver *independent* and at least way back in the day was supposed to be implemented for "OS power management" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 20:12, Matthew Garrett wrote: > Veering off at something of a tangent - how much of this should be true > for wireless devices? Softmac seems to be unhappy about setting the > essid unless the card is up, which breaks various assumptions... > Softmac isn't the only wireless code that likes to be configured after going up first. Configuring after the card goes up has generally been more reliable, though that should not be necessary and is a bug IMHO. > Beyond that, I think your descriptions of up and down states make sense > for userspace. As Arjan suggests, there's then the intermediate state of > "disable as much as possible while still providing scanning and link > detection". > In order to scan, we need to have the radio on and we need to be able to send and receive. What are you gonna turn off? -Michael Wu pgpGWfZrTsIlb.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote: > Entirely correct. If the card is DOWN, the radio should be off (both TX > & RX) and it should be in max power save mode. If userspace expects to > be able to get the card to do _anything_ when it's down, that's just > 110% wrong. You can't get link events for many wired cards when they > are down, so I fail to see where userspace could expect to do anything > with a wireless card when it's down too. Because it works on the common hardware? If there's documentation about what userspace can legitimately expect, then I'm happy to defer to that. But in the absence of any indication as to what functionality users can depend on, deciding that existing functionality is a bug is, well, impolite. > Also, how does rfkill fit into this? rfkill implies killing TX, but do > we have the granularity to still receive while the transmit paths are > powered down? Is rfkill not just primarily an interface for us getting events when the radio changes state? Every time I read up on it I get a little more confused - some time I really need to make sense of it... -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:49:06PM -0800, Stephen Hemminger wrote: > When device is down, it should: >a) use as few resources as possible: > - not grab memory for buffers > - not assign IRQ unless it could get one > - turn off all power consumption possible >b) allow setting parameters like speed/duplex/autonegotiation, > ring buffers, ... with ethtool, and remember the state Veering off at something of a tangent - how much of this should be true for wireless devices? Softmac seems to be unhappy about setting the essid unless the card is up, which breaks various assumptions... Beyond that, I think your descriptions of up and down states make sense for userspace. As Arjan suggests, there's then the intermediate state of "disable as much as possible while still providing scanning and link detection". > 2) Network device infrastructure should make it easier for devices: > bring interface down on suspend and bring it up after resume > (if it was running when suspended). This would allow many devices to > have no suspend/resume hook; except those that have some better power > control over hardware. I'd have some concerns over how that would interact with the rest of the PM infrastructure, but it certainly sounds good in principle. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 21 Dec 2006 01:11:12 +0100 Francois Romieu <[EMAIL PROTECTED]> wrote: > Stephen Hemminger <[EMAIL PROTECTED]> : > [...] > >IMHO: > > When device is down, it should: > > a) use as few resources as possible: > >- not grab memory for buffers > >- not assign IRQ unless it could get one > >- turn off all power consumption possible > > b) allow setting parameters like speed/duplex/autonegotiation, > > ring buffers, ... with ethtool, and remember the state > > c) not accept data coming in, and drop packets queued > > > Imho speed/duplex/autoneg is not the business of the device: they belong > to the phy and it's up to it to decide if its state allows to set the > requested parameters or not. > > We need to allow ethtool setting to be done before device has been brought up and started autonegotiation. The current MII library doesn't really support it. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Stephen Hemminger <[EMAIL PROTECTED]> : [...] >IMHO: > When device is down, it should: >a) use as few resources as possible: > - not grab memory for buffers > - not assign IRQ unless it could get one > - turn off all power consumption possible >b) allow setting parameters like speed/duplex/autonegotiation, > ring buffers, ... with ethtool, and remember the state >c) not accept data coming in, and drop packets queued Imho speed/duplex/autoneg is not the business of the device: they belong to the phy and it's up to it to decide if its state allows to set the requested parameters or not. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
There are two different problems: 1) Behavior seems to be different depending on device driver author. We should document the expected semantics better. IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued What implications does c have for something like tcpdump? rick jones - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 15:37:41 -0800 Rick Jones <[EMAIL PROTECTED]> wrote: > > There are two different problems: > > > > 1) Behavior seems to be different depending on device driver > >author. We should document the expected semantics better. > > > >IMHO: > > When device is down, it should: > > a) use as few resources as possible: > >- not grab memory for buffers > >- not assign IRQ unless it could get one > >- turn off all power consumption possible > > b) allow setting parameters like speed/duplex/autonegotiation, > > ring buffers, ... with ethtool, and remember the state > > c) not accept data coming in, and drop packets queued > > What implications does c have for something like tcpdump? > > rick jones None, you can bring up the device without actually assigning an address to it. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 16:51:39 +0100 Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > > Yeah, I guess that's a problem. From a user perspective, the > > functionality is only really useful if the latency is very small. I > > think where possible we'd want to power down the chip while keeping the > > phy up, but it would be nice to know how much power that would actually > > cost us. > > > I'm no expert but afaik the PHY is the power hungry part, the rest is > peanuts. So if we can get the PHY to sleep most of the time that would > be great. > There are two different problems: 1) Behavior seems to be different depending on device driver author. We should document the expected semantics better. IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued When device is up, it should: a) Start negotiation if needed b) Not bring up carrier till it is ready c) Allow reconfiguration Wake on Lan should be disabled by default, until changed. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 21:40 +0100, Benny Amorsen wrote: > > "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes: > > AvdV> even if you have NO power savings you still don't meet your > AvdV> criteria. That's basic ethernet for you > > AvdV> That's what I was trying to say; your criteria is unrealistic > AvdV> regardless of what the kernel does, ethernet already dictates 30 > AvdV> to 45 seconds there. > > Can you get to such high numbers without STP? you can get the 30 seconds yes. Usually not with home equipment though, but with longer cables and expensive switches.. it does happen. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven: > 5 seconds is unfair and unrealistic though. The *hardware* negotiation > before link is seen can easily take upto 45 seconds already. > That's a network topology/hardware issue (spanning tree fun) that > software or even the hardware in your PC can do nothing about. Spanning tree decides whether or not a port forwards traffic. It has nothing to do with link beat detection and autonegotation, so it shouldn't be an issue here. Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes: AvdV> even if you have NO power savings you still don't meet your AvdV> criteria. That's basic ethernet for you AvdV> That's what I was trying to say; your criteria is unrealistic AvdV> regardless of what the kernel does, ethernet already dictates 30 AvdV> to 45 seconds there. Can you get to such high numbers without STP? /Benny - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 15:00 +0100, Jiri Benc wrote: > On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote: > > The situation is more complicated for wireless. Userspace expects to be > > able to get scan results from the card even if the interface is down. > > User space should get an error when trying to get scan results from the > interface that is down. Some drivers are broken and don't do this but > when they're fixed there is no problem here. Entirely correct. If the card is DOWN, the radio should be off (both TX & RX) and it should be in max power save mode. If userspace expects to be able to get the card to do _anything_ when it's down, that's just 110% wrong. You can't get link events for many wired cards when they are down, so I fail to see where userspace could expect to do anything with a wireless card when it's down too. > > In that case, I'm pretty sure we need a third state rather than just > > "up" or "down". > > We have that third state, it's IFF_DORMANT. Not supported yet by any > wireless driver/stack, unfortunately. So we have 3 states? What purpose does DORMANT serve and what is allowed in DORMANT? Also, how does rfkill fit into this? rfkill implies killing TX, but do we have the granularity to still receive while the transmit paths are powered down? Dan > Thanks, > > Jiri > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 17:40 +0100, Olivier Galibert wrote: > On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote: > > 5 seconds is unfair and unrealistic though. The *hardware* negotiation > > before link is seen can easily take upto 45 seconds already. > > That's a network topology/hardware issue (spanning tree fun) that > > software or even the hardware in your PC can do nothing about. > > It's about ergonomics, not technical capabilities or fairness. not entirely. > > > > this means that the "power up time" needs to be at least 45 seconds, if > > it's then down 5 seconds inbetween... that's not real power savings. > > Then that means you can't have usable autodetection and power savings > at the same time. even if you have NO power savings you still don't meet your criteria. That's basic ethernet for you That's what I was trying to say; your criteria is unrealistic regardless of what the kernel does, ethernet already dictates 30 to 45 seconds there. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote: > 5 seconds is unfair and unrealistic though. The *hardware* negotiation > before link is seen can easily take upto 45 seconds already. > That's a network topology/hardware issue (spanning tree fun) that > software or even the hardware in your PC can do nothing about. It's about ergonomics, not technical capabilities or fairness. > this means that the "power up time" needs to be at least 45 seconds, if > it's then down 5 seconds inbetween... that's not real power savings. Then that means you can't have usable autodetection and power savings at the same time. That's a pefectly acceptable answer, you just have to give the choice between the two to the user. From the kernel p.o.v, it just means that you probably need 3 modes: 1- active and exchanging packets 2- inactive but waiting for plugging and able to tell something is going on fast (like 0.5s fast) 3- powered off and they probably already exist (UP+addr/procmisc. set, UP and DOWN). And if the second mode can't be lower power than the first, that's just life. An hypothetical mode 4 identical to 2 without the "fast" part is just not worth bothering with. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006, Matthew Garrett wrote: > As far as I can tell, the following network devices don't put the > hardware into D3 on interface down: [...] > defxx No support in the hardware for that. Even revision 3 of the board which is the last one and the only to support PCI 2.2 says: Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- ;-) Maciej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
> Yeah, I guess that's a problem. From a user perspective, the > functionality is only really useful if the latency is very small. I > think where possible we'd want to power down the chip while keeping the > phy up, but it would be nice to know how much power that would actually > cost us. I'm no expert but afaik the PHY is the power hungry part, the rest is peanuts. So if we can get the PHY to sleep most of the time that would be great. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 16:27 +0100, Olivier Galibert wrote: > On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: > > [1] What kind of latency would be allowed? Would an implementation be > > allowed to power up the phy say once per minute or once per 5 minutes to > > see if there is link? The implementation could do this progressively; > > first poll every X seconds, then after an hour, every minute etc. > > I suspect that the hard maximum latency is the time needed by the user > to start the network himself, be it opening a root xterm and doing the > appropriate invocation or pulling up and clicking where appropriate in > a GUI. That's probably around 5 seconds. Over that, and they won't > even notice there is an autodetection running. > > But still, 5 seconds is probably too much too, because it's going to > look like it's unreliable. The user has to see something happen > within half-a-second or so, otherwise he's going to start doing it by > hand. The "see" part is distribution/desktop-dependant and not the > kernel problem, but the top chrono happens when the rj45 is plugged > in. 5 seconds is unfair and unrealistic though. The *hardware* negotiation before link is seen can easily take upto 45 seconds already. That's a network topology/hardware issue (spanning tree fun) that software or even the hardware in your PC can do nothing about. this means that the "power up time" needs to be at least 45 seconds, if it's then down 5 seconds inbetween... that's not real power savings. > . -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: > [1] What kind of latency would be allowed? Would an implementation be > allowed to power up the phy say once per minute or once per 5 minutes to > see if there is link? The implementation could do this progressively; > first poll every X seconds, then after an hour, every minute etc. I suspect that the hard maximum latency is the time needed by the user to start the network himself, be it opening a root xterm and doing the appropriate invocation or pulling up and clicking where appropriate in a GUI. That's probably around 5 seconds. Over that, and they won't even notice there is an autodetection running. But still, 5 seconds is probably too much too, because it's going to look like it's unreliable. The user has to see something happen within half-a-second or so, otherwise he's going to start doing it by hand. The "see" part is distribution/desktop-dependant and not the kernel problem, but the top chrono happens when the rj45 is plugged in. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: > about your driver list; > do you have an idea of what the top 5 relevant ones would be? > I'd be surprised if the top 5 together had less than 95% market share, > so if we fix those we'd be mostly done already. In terms of what I've seen on vaguely modern hardware, I'd guess at e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, with via-rhine appearing at the very low end. I'll try to grep through our hardware database results to get a stronger idea about percentages. > > The situation is more complicated for wireless. Userspace expects to be > > able to get scan results from the card even if the interface is down. > > if it's down userspace cannot currently expect this (if it does it's > broken), just as it currently can't expect link notifications when the > interface is down. It needs to have the interface up for this. > (but point taken for a 3rd state) The documentation for what userspace can legitimately expect of the kernel is distinctly lacking, and as far as I can tell most of the common drivers support scanning while the interface is down. It would be immensely helpful if we could have a better idea of which kernel behaviour is deliberate, and which bits of kernel functionality are accidental and might go away at any time. Right now, I have various scripts depending on this behaviour because there's absolutely no indication that I'm not supposed to be. (Of course, I may have missed it somewhere - I've never been able to find terribly comprehensive documentation on WE) > so what do you want from this 3rd state? rough guess based on what I > think the desktop wants (so please correct/append) Just to be clear: in this world view, "down" maps to "fully powered down", so this third state is a "low power consumption mode"? If so: > In the third state you > * don't expect to get or send "regular" packets > * don't have a dhcp lease or anything like that > * you do expect to get link change notification [1] > * you do expect to be able to scan for access points [2] Yes, I think that's a fair summary. > open questions > * what if you get a WOL event? In an ideal world, I think the information would be passed to userspace and it would get to make the distinction. I appreciate that the hardware may have different ideas about what's appropriate... > [1] What kind of latency would be allowed? Would an implementation be > allowed to power up the phy say once per minute or once per 5 minutes to > see if there is link? The implementation could do this progressively; > first poll every X seconds, then after an hour, every minute etc. Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to know how much power that would actually cost us. (We have a similar issue when it comes to stuff like monitor hotplug - it's the sort of thing that many users are willing to accept losing some battery for, and there probably isn't a single right answer) > [2] would it be permissible to temporarily power up the device on scan? > Eg how frequently does the desktop expect to poll for scanning, and what > kind of latency would be tolerable? network-manager's behaviour when the interface is inactive is to scan every 2 minutes. I don't think latency is too much of an issue. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote: > The situation is more complicated for wireless. Userspace expects to be > able to get scan results from the card even if the interface is down. User space should get an error when trying to get scan results from the interface that is down. Some drivers are broken and don't do this but when they're fixed there is no problem here. > In that case, I'm pretty sure we need a third state rather than just > "up" or "down". We have that third state, it's IFF_DORMANT. Not supported yet by any wireless driver/stack, unfortunately. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
about your driver list; do you have an idea of what the top 5 relevant ones would be? I'd be surprised if the top 5 together had less than 95% market share, so if we fix those we'd be mostly done already. > The situation is more complicated for wireless. Userspace expects to be > able to get scan results from the card even if the interface is down. if it's down userspace cannot currently expect this (if it does it's broken), just as it currently can't expect link notifications when the interface is down. It needs to have the interface up for this. (but point taken for a 3rd state) > In > that case, I'm pretty sure we need a third state rather than just "up" > or "down". so what do you want from this 3rd state? rough guess based on what I think the desktop wants (so please correct/append) In the third state you * don't expect to get or send "regular" packets * don't have a dhcp lease or anything like that * you do expect to get link change notification [1] * you do expect to be able to scan for access points [2] open questions * what if you get a WOL event? [1] What kind of latency would be allowed? Would an implementation be allowed to power up the phy say once per minute or once per 5 minutes to see if there is link? The implementation could do this progressively; first poll every X seconds, then after an hour, every minute etc. [2] would it be permissible to temporarily power up the device on scan? Eg how frequently does the desktop expect to poll for scanning, and what kind of latency would be tolerable? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 08:50:24AM +0100, Arjan van de Ven wrote: (Adding netdev - context is the altering of the runtime power management interface, with the effect that it's no longer possible for userspace to request that drivers suspend a device, so Arjan has suggested that we do it via other existing interfaces) > > Seriously. How many pieces of userspace-visible functionality have > > recently been removed without there being any sort of alternative? > > There IS an alternative, you're using it for networking: > > You *down the interface*. > > If there's a NIC that doesn't support that let us (or preferably netdev) > know and it'll get fixed quickly I'm sure. As far as I can tell, the following network devices don't put the hardware into D3 on interface down: 3c59x 8139too acenic amd8111e b44 cassini defxx dl2k e100 e1000 epic100 fealnx forcedeth hamachi hp100 ioc3-eth natsemi ne2k-pci ns83820 pcnet32 qla3xxx rtl8169 rrunner s2io saa9730 sis190 sis900 skge sky2 spider_net starfire sundance sungem sunhme tc35815 tlan via-rhine yellowfin while these ones do: bnx2 tg3 typhoon via-velocity tulip is somewhere in between - it puts the chip in a lower power state, but not D3. It's possible that some of the other drivers do something similar, but nothing leapt out at me. The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even if the interface is down. In that case, I'm pretty sure we need a third state rather than just "up" or "down". -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 08:50:24AM +0100, Arjan van de Ven wrote: (Adding netdev - context is the altering of the runtime power management interface, with the effect that it's no longer possible for userspace to request that drivers suspend a device, so Arjan has suggested that we do it via other existing interfaces) Seriously. How many pieces of userspace-visible functionality have recently been removed without there being any sort of alternative? There IS an alternative, you're using it for networking: You *down the interface*. If there's a NIC that doesn't support that let us (or preferably netdev) know and it'll get fixed quickly I'm sure. As far as I can tell, the following network devices don't put the hardware into D3 on interface down: 3c59x 8139too acenic amd8111e b44 cassini defxx dl2k e100 e1000 epic100 fealnx forcedeth hamachi hp100 ioc3-eth natsemi ne2k-pci ns83820 pcnet32 qla3xxx rtl8169 rrunner s2io saa9730 sis190 sis900 skge sky2 spider_net starfire sundance sungem sunhme tc35815 tlan via-rhine yellowfin while these ones do: bnx2 tg3 typhoon via-velocity tulip is somewhere in between - it puts the chip in a lower power state, but not D3. It's possible that some of the other drivers do something similar, but nothing leapt out at me. The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even if the interface is down. In that case, I'm pretty sure we need a third state rather than just up or down. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
about your driver list; do you have an idea of what the top 5 relevant ones would be? I'd be surprised if the top 5 together had less than 95% market share, so if we fix those we'd be mostly done already. The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even if the interface is down. if it's down userspace cannot currently expect this (if it does it's broken), just as it currently can't expect link notifications when the interface is down. It needs to have the interface up for this. (but point taken for a 3rd state) In that case, I'm pretty sure we need a third state rather than just up or down. so what do you want from this 3rd state? rough guess based on what I think the desktop wants (so please correct/append) In the third state you * don't expect to get or send regular packets * don't have a dhcp lease or anything like that * you do expect to get link change notification [1] * you do expect to be able to scan for access points [2] open questions * what if you get a WOL event? [1] What kind of latency would be allowed? Would an implementation be allowed to power up the phy say once per minute or once per 5 minutes to see if there is link? The implementation could do this progressively; first poll every X seconds, then after an hour, every minute etc. [2] would it be permissible to temporarily power up the device on scan? Eg how frequently does the desktop expect to poll for scanning, and what kind of latency would be tolerable? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: about your driver list; do you have an idea of what the top 5 relevant ones would be? I'd be surprised if the top 5 together had less than 95% market share, so if we fix those we'd be mostly done already. In terms of what I've seen on vaguely modern hardware, I'd guess at e1000 and sky2 as the top ones. b44 is still common in cheaper hardware, with via-rhine appearing at the very low end. I'll try to grep through our hardware database results to get a stronger idea about percentages. The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even if the interface is down. if it's down userspace cannot currently expect this (if it does it's broken), just as it currently can't expect link notifications when the interface is down. It needs to have the interface up for this. (but point taken for a 3rd state) The documentation for what userspace can legitimately expect of the kernel is distinctly lacking, and as far as I can tell most of the common drivers support scanning while the interface is down. It would be immensely helpful if we could have a better idea of which kernel behaviour is deliberate, and which bits of kernel functionality are accidental and might go away at any time. Right now, I have various scripts depending on this behaviour because there's absolutely no indication that I'm not supposed to be. (Of course, I may have missed it somewhere - I've never been able to find terribly comprehensive documentation on WE) so what do you want from this 3rd state? rough guess based on what I think the desktop wants (so please correct/append) Just to be clear: in this world view, down maps to fully powered down, so this third state is a low power consumption mode? If so: In the third state you * don't expect to get or send regular packets * don't have a dhcp lease or anything like that * you do expect to get link change notification [1] * you do expect to be able to scan for access points [2] Yes, I think that's a fair summary. open questions * what if you get a WOL event? In an ideal world, I think the information would be passed to userspace and it would get to make the distinction. I appreciate that the hardware may have different ideas about what's appropriate... [1] What kind of latency would be allowed? Would an implementation be allowed to power up the phy say once per minute or once per 5 minutes to see if there is link? The implementation could do this progressively; first poll every X seconds, then after an hour, every minute etc. Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to know how much power that would actually cost us. (We have a similar issue when it comes to stuff like monitor hotplug - it's the sort of thing that many users are willing to accept losing some battery for, and there probably isn't a single right answer) [2] would it be permissible to temporarily power up the device on scan? Eg how frequently does the desktop expect to poll for scanning, and what kind of latency would be tolerable? network-manager's behaviour when the interface is inactive is to scan every 2 minutes. I don't think latency is too much of an issue. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote: The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even if the interface is down. User space should get an error when trying to get scan results from the interface that is down. Some drivers are broken and don't do this but when they're fixed there is no problem here. In that case, I'm pretty sure we need a third state rather than just up or down. We have that third state, it's IFF_DORMANT. Not supported yet by any wireless driver/stack, unfortunately. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: [1] What kind of latency would be allowed? Would an implementation be allowed to power up the phy say once per minute or once per 5 minutes to see if there is link? The implementation could do this progressively; first poll every X seconds, then after an hour, every minute etc. I suspect that the hard maximum latency is the time needed by the user to start the network himself, be it opening a root xterm and doing the appropriate invocation or pulling up and clicking where appropriate in a GUI. That's probably around 5 seconds. Over that, and they won't even notice there is an autodetection running. But still, 5 seconds is probably too much too, because it's going to look like it's unreliable. The user has to see something happen within half-a-second or so, otherwise he's going to start doing it by hand. The see part is distribution/desktop-dependant and not the kernel problem, but the top chrono happens when the rj45 is plugged in. OG. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 16:27 +0100, Olivier Galibert wrote: On Wed, Dec 20, 2006 at 02:38:51PM +0100, Arjan van de Ven wrote: [1] What kind of latency would be allowed? Would an implementation be allowed to power up the phy say once per minute or once per 5 minutes to see if there is link? The implementation could do this progressively; first poll every X seconds, then after an hour, every minute etc. I suspect that the hard maximum latency is the time needed by the user to start the network himself, be it opening a root xterm and doing the appropriate invocation or pulling up and clicking where appropriate in a GUI. That's probably around 5 seconds. Over that, and they won't even notice there is an autodetection running. But still, 5 seconds is probably too much too, because it's going to look like it's unreliable. The user has to see something happen within half-a-second or so, otherwise he's going to start doing it by hand. The see part is distribution/desktop-dependant and not the kernel problem, but the top chrono happens when the rj45 is plugged in. 5 seconds is unfair and unrealistic though. The *hardware* negotiation before link is seen can easily take upto 45 seconds already. That's a network topology/hardware issue (spanning tree fun) that software or even the hardware in your PC can do nothing about. this means that the power up time needs to be at least 45 seconds, if it's then down 5 seconds inbetween... that's not real power savings. . -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to know how much power that would actually cost us. I'm no expert but afaik the PHY is the power hungry part, the rest is peanuts. So if we can get the PHY to sleep most of the time that would be great. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006, Matthew Garrett wrote: As far as I can tell, the following network devices don't put the hardware into D3 on interface down: [...] defxx No support in the hardware for that. Even revision 3 of the board which is the last one and the only to support PCI 2.2 says: Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- ;-) Maciej - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote: 5 seconds is unfair and unrealistic though. The *hardware* negotiation before link is seen can easily take upto 45 seconds already. That's a network topology/hardware issue (spanning tree fun) that software or even the hardware in your PC can do nothing about. It's about ergonomics, not technical capabilities or fairness. this means that the power up time needs to be at least 45 seconds, if it's then down 5 seconds inbetween... that's not real power savings. Then that means you can't have usable autodetection and power savings at the same time. That's a pefectly acceptable answer, you just have to give the choice between the two to the user. From the kernel p.o.v, it just means that you probably need 3 modes: 1- active and exchanging packets 2- inactive but waiting for plugging and able to tell something is going on fast (like 0.5s fast) 3- powered off and they probably already exist (UP+addr/procmisc. set, UP and DOWN). And if the second mode can't be lower power than the first, that's just life. An hypothetical mode 4 identical to 2 without the fast part is just not worth bothering with. OG. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 17:40 +0100, Olivier Galibert wrote: On Wed, Dec 20, 2006 at 04:34:17PM +0100, Arjan van de Ven wrote: 5 seconds is unfair and unrealistic though. The *hardware* negotiation before link is seen can easily take upto 45 seconds already. That's a network topology/hardware issue (spanning tree fun) that software or even the hardware in your PC can do nothing about. It's about ergonomics, not technical capabilities or fairness. not entirely. this means that the power up time needs to be at least 45 seconds, if it's then down 5 seconds inbetween... that's not real power savings. Then that means you can't have usable autodetection and power savings at the same time. even if you have NO power savings you still don't meet your criteria. That's basic ethernet for you That's what I was trying to say; your criteria is unrealistic regardless of what the kernel does, ethernet already dictates 30 to 45 seconds there. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 15:00 +0100, Jiri Benc wrote: On Wed, 20 Dec 2006 12:53:14 +, Matthew Garrett wrote: The situation is more complicated for wireless. Userspace expects to be able to get scan results from the card even if the interface is down. User space should get an error when trying to get scan results from the interface that is down. Some drivers are broken and don't do this but when they're fixed there is no problem here. Entirely correct. If the card is DOWN, the radio should be off (both TX RX) and it should be in max power save mode. If userspace expects to be able to get the card to do _anything_ when it's down, that's just 110% wrong. You can't get link events for many wired cards when they are down, so I fail to see where userspace could expect to do anything with a wireless card when it's down too. In that case, I'm pretty sure we need a third state rather than just up or down. We have that third state, it's IFF_DORMANT. Not supported yet by any wireless driver/stack, unfortunately. So we have 3 states? What purpose does DORMANT serve and what is allowed in DORMANT? Also, how does rfkill fit into this? rfkill implies killing TX, but do we have the granularity to still receive while the transmit paths are powered down? Dan Thanks, Jiri - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
AvdV == Arjan van de Ven [EMAIL PROTECTED] writes: AvdV even if you have NO power savings you still don't meet your AvdV criteria. That's basic ethernet for you AvdV That's what I was trying to say; your criteria is unrealistic AvdV regardless of what the kernel does, ethernet already dictates 30 AvdV to 45 seconds there. Can you get to such high numbers without STP? /Benny - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Am Mittwoch, 20. Dezember 2006 16:34 schrieb Arjan van de Ven: 5 seconds is unfair and unrealistic though. The *hardware* negotiation before link is seen can easily take upto 45 seconds already. That's a network topology/hardware issue (spanning tree fun) that software or even the hardware in your PC can do nothing about. Spanning tree decides whether or not a port forwards traffic. It has nothing to do with link beat detection and autonegotation, so it shouldn't be an issue here. Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 21:40 +0100, Benny Amorsen wrote: AvdV == Arjan van de Ven [EMAIL PROTECTED] writes: AvdV even if you have NO power savings you still don't meet your AvdV criteria. That's basic ethernet for you AvdV That's what I was trying to say; your criteria is unrealistic AvdV regardless of what the kernel does, ethernet already dictates 30 AvdV to 45 seconds there. Can you get to such high numbers without STP? you can get the 30 seconds yes. Usually not with home equipment though, but with longer cables and expensive switches.. it does happen. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 16:51:39 +0100 Arjan van de Ven [EMAIL PROTECTED] wrote: Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to know how much power that would actually cost us. I'm no expert but afaik the PHY is the power hungry part, the rest is peanuts. So if we can get the PHY to sleep most of the time that would be great. There are two different problems: 1) Behavior seems to be different depending on device driver author. We should document the expected semantics better. IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued When device is up, it should: a) Start negotiation if needed b) Not bring up carrier till it is ready c) Allow reconfiguration Wake on Lan should be disabled by default, until changed. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 20 Dec 2006 15:37:41 -0800 Rick Jones [EMAIL PROTECTED] wrote: There are two different problems: 1) Behavior seems to be different depending on device driver author. We should document the expected semantics better. IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued What implications does c have for something like tcpdump? rick jones None, you can bring up the device without actually assigning an address to it. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
There are two different problems: 1) Behavior seems to be different depending on device driver author. We should document the expected semantics better. IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued What implications does c have for something like tcpdump? rick jones - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Stephen Hemminger [EMAIL PROTECTED] : [...] IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued nit Imho speed/duplex/autoneg is not the business of the device: they belong to the phy and it's up to it to decide if its state allows to set the requested parameters or not. /nit -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 21 Dec 2006 01:11:12 +0100 Francois Romieu [EMAIL PROTECTED] wrote: Stephen Hemminger [EMAIL PROTECTED] : [...] IMHO: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state c) not accept data coming in, and drop packets queued nit Imho speed/duplex/autoneg is not the business of the device: they belong to the phy and it's up to it to decide if its state allows to set the requested parameters or not. /nit We need to allow ethtool setting to be done before device has been brought up and started autonegotiation. The current MII library doesn't really support it. -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 02:49:06PM -0800, Stephen Hemminger wrote: When device is down, it should: a) use as few resources as possible: - not grab memory for buffers - not assign IRQ unless it could get one - turn off all power consumption possible b) allow setting parameters like speed/duplex/autonegotiation, ring buffers, ... with ethtool, and remember the state Veering off at something of a tangent - how much of this should be true for wireless devices? Softmac seems to be unhappy about setting the essid unless the card is up, which breaks various assumptions... Beyond that, I think your descriptions of up and down states make sense for userspace. As Arjan suggests, there's then the intermediate state of disable as much as possible while still providing scanning and link detection. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. I'd have some concerns over how that would interact with the rest of the PM infrastructure, but it certainly sounds good in principle. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote: Entirely correct. If the card is DOWN, the radio should be off (both TX RX) and it should be in max power save mode. If userspace expects to be able to get the card to do _anything_ when it's down, that's just 110% wrong. You can't get link events for many wired cards when they are down, so I fail to see where userspace could expect to do anything with a wireless card when it's down too. Because it works on the common hardware? If there's documentation about what userspace can legitimately expect, then I'm happy to defer to that. But in the absence of any indication as to what functionality users can depend on, deciding that existing functionality is a bug is, well, impolite. Also, how does rfkill fit into this? rfkill implies killing TX, but do we have the granularity to still receive while the transmit paths are powered down? Is rfkill not just primarily an interface for us getting events when the radio changes state? Every time I read up on it I get a little more confused - some time I really need to make sense of it... -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 20:12, Matthew Garrett wrote: Veering off at something of a tangent - how much of this should be true for wireless devices? Softmac seems to be unhappy about setting the essid unless the card is up, which breaks various assumptions... Softmac isn't the only wireless code that likes to be configured after going up first. Configuring after the card goes up has generally been more reliable, though that should not be necessary and is a bug IMHO. Beyond that, I think your descriptions of up and down states make sense for userspace. As Arjan suggests, there's then the intermediate state of disable as much as possible while still providing scanning and link detection. In order to scan, we need to have the radio on and we need to be able to send and receive. What are you gonna turn off? -Michael Wu pgpGWfZrTsIlb.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
On 12/20/06, Arjan van de Ven [EMAIL PROTECTED] wrote: Yeah, I guess that's a problem. From a user perspective, the functionality is only really useful if the latency is very small. I think where possible we'd want to power down the chip while keeping the phy up, but it would be nice to know how much power that would actually cost us. I'm no expert but afaik the PHY is the power hungry part, the rest is peanuts. So if we can get the PHY to sleep most of the time that would be great. The MAC uses some part of power, but FYI at least e1000 already does phy power management when IF_DOWN, if wake on lan isn't enabled, smbus isn't enabled, etc etc. If we started using D3 power management its possible a whole bunch of code would go away out of e1000. Is there some reason why we can't have the OS just do the D3 transition for all drivers that register support? I mean, this power management using D states is actually driver *independent* and at least way back in the day was supposed to be implemented for OS power management - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote: Softmac isn't the only wireless code that likes to be configured after going up first. Configuring after the card goes up has generally been more reliable, though that should not be necessary and is a bug IMHO. Ok, that's nice to know. In order to scan, we need to have the radio on and we need to be able to send and receive. What are you gonna turn off? The obvious route would be to power the card down, but come back up every two minutes to perform a scan, or if userspace explicitly requests one. Would this cause problems in some cases? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote: (allowing scanning while the interface is down) No, it's absolutely a bug. It just so happens that some drivers incorrectly allowed it. Ok. Would it be reasonable to add warnings to any devices that allow it? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wednesday 20 December 2006 20:15, Matthew Garrett wrote: Because it works on the common hardware? If there's documentation about what userspace can legitimately expect, then I'm happy to defer to that. But in the absence of any indication as to what functionality users can depend on, deciding that existing functionality is a bug is, well, impolite. No, it's absolutely a bug. It just so happens that some drivers incorrectly allowed it. -Michael Wu pgp88tOEHFma3.pgp Description: PGP signature
Re: Network drivers that don't suspend on interface down
Matthew Garrett wrote: Veering off at something of a tangent - how much of this should be true for wireless devices? Softmac seems to be unhappy about setting the essid unless the card is up, which breaks various assumptions... You might regard that as a bug - I agree it probably makes sense for you to be able to set certain configuration variables before the interface is up, within reason. However, the mentality adopted by most wireless drivers is the SIWESSID wireless extension ioctl means *associate*, something which obviously shouldn't be possible when the interface is down (radio off, etc). While you might blame drivers for this possible misinterpretation, it can also be viewed as a design flaw in WE: the drivers have to handle the ioctl's directly, meaning that if you want some kind of configuration management then you have to do it on the driver level, and this doesn't feel right. The situation is also made worse due to WE generally being hard to implement, and also the lack of documentation (really the only source here is the iwconfig man page). This screams out for an 802.11-centric configuration system, and it looks like we have one on the way: cfg80211 From reading some mails, it looks like the drivers will simply have to provide functions for associate, scan, etc, and the configuration management will be offloaded to the upper layers. For the time being, I suggest you bring the interface up before setting the configuration. Regardless of the inconsistency of the current situation, and lack documentation saying which way it should be done, you are at least playing it safe and guaranteeing it works on all drivers. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Matthew Garrett wrote: In order to scan, we need to have the radio on and we need to be able to send and receive. What are you gonna turn off? The obvious route would be to power the card down, but come back up every two minutes to perform a scan, or if userspace explicitly requests one. Would this cause problems in some cases? I don't think it makes sense. For zd1211 the power consumption and heat emission goes up considerably when the interface is brought up (radio on, interrupts enabled, etc), and this is also a relatively long operation in terms of duration needed to bring the interface up and down. A scanning operation requires radio on, interrupts enabled, lots of register reading, RF calibration, RX/TX ringbuffers allocation, etc. I don't think that supporting scanning when the interface is supposed to be disabled is sensible. If you want to scan, you are simply sending and receiving frames, it's no different from having the interface up and sending/receiving data frames. There are additional implementation problems: scanning requires 2 different ioctl calls: siwscan, then several giwscan. If you want the driver to effectively temporarily bring the interface up when userspace requests a scan but the interface was down, then how does the driver know when to bring it down again? Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 09:38:20PM -0500, Daniel Drake wrote: I don't think that supporting scanning when the interface is supposed to be disabled is sensible. If you want to scan, you are simply sending and receiving frames, it's no different from having the interface up and sending/receiving data frames. From a usability point of view, it's helpful to power the card down as much as possible while it's not being actively used. However, it's also helpful to be able to provide a list of available wireless networks, though some degree of latency would be acceptable in that. These two desires are obviously not entirely compatible with one another, so it would be helpful if there was some means of providing an intermediate state. There are additional implementation problems: scanning requires 2 different ioctl calls: siwscan, then several giwscan. If you want the driver to effectively temporarily bring the interface up when userspace requests a scan but the interface was down, then how does the driver know when to bring it down again? Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. Picking a number out of thin air would be one answer, but clearly less than ideal. This may be a case of us not being able to satisfy everyone, and so just having to force the user to choose between low power or wireless scanning. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 02:20 +, Matthew Garrett wrote: On Wed, Dec 20, 2006 at 08:57:05PM -0500, Michael Wu wrote: (allowing scanning while the interface is down) No, it's absolutely a bug. It just so happens that some drivers incorrectly allowed it. Ok. Would it be reasonable to add warnings to any devices that allow it? Quite reasonable. Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 01:15 +, Matthew Garrett wrote: On Wed, Dec 20, 2006 at 01:12:51PM -0500, Dan Williams wrote: Entirely correct. If the card is DOWN, the radio should be off (both TX RX) and it should be in max power save mode. If userspace expects to be able to get the card to do _anything_ when it's down, that's just 110% wrong. You can't get link events for many wired cards when they are down, so I fail to see where userspace could expect to do anything with a wireless card when it's down too. Because it works on the common hardware? If there's documentation about what userspace can legitimately expect, then I'm happy to defer to that. But in the absence of any indication as to what functionality users can depend on, deciding that existing functionality is a bug is, well, impolite. Also, how does rfkill fit into this? rfkill implies killing TX, but do we have the granularity to still receive while the transmit paths are powered down? Is rfkill not just primarily an interface for us getting events when the radio changes state? Every time I read up on it I get a little more confused - some time I really need to make sense of it... That's OK, it's really complicated. There are 3 cases of rfkill switches AFAICT: a) tied to the wireless hardware, switch kills hardware directly b) tied to wireless hardware, but driver handles the kill request c) just another key, a separate key driver handles the event and asks the wireless driver to kill the card It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. Furthermore, some people want to 'softkill' the hardware via software without pushing the key, which is a subset of (b) or (c) above. It sucks. But we _need_ a unified interface to handle it. Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Matthew Garrett wrote: There are additional implementation problems: scanning requires 2 different ioctl calls: siwscan, then several giwscan. If you want the driver to effectively temporarily bring the interface up when userspace requests a scan but the interface was down, then how does the driver know when to bring it down again? Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. I'm not sure, but thats not entirely relevant either. The time it takes for the AP to respond is not related to the delay between userspace sending the siwscan and giwscan ioctls (unless you're thinking of userspace being too quick, but GIWSCAN already returns -EINPROGRESS when appropriate so this is detectable) Picking a number out of thin air would be one answer, but clearly less than ideal. This may be a case of us not being able to satisfy everyone, and so just having to force the user to choose between low power or wireless scanning. I think it's reasonable to keep the interface down, but then when the user does want to connect, bring the interface up, scan, present scan results. Scanning is quick, there would be minimal wait needed here. Alternatively, if you do want to prepare scan results in the background every 2 minutes, use a sequence something like: - bring interface up - siwscan - giwscan [...] - bring interface down - repeat after 2 mins If this kind of thing was implemented at the driver level, in most cases it would be identical to doing the above anyway. Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 02:18 +, Matthew Garrett wrote: On Wed, Dec 20, 2006 at 09:05:27PM -0500, Michael Wu wrote: Softmac isn't the only wireless code that likes to be configured after going up first. Configuring after the card goes up has generally been more reliable, though that should not be necessary and is a bug IMHO. Ok, that's nice to know. In order to scan, we need to have the radio on and we need to be able to send and receive. What are you gonna turn off? The obvious route would be to power the card down, but come back up every two minutes to perform a scan, or if userspace explicitly requests one. Would this cause problems in some cases? Seriously, having all these different capabilities when the card is down is just madness. Down == Down!!! Furthermore, every card is going to support some other subset of capabilities when it's down. When you bring up prism54 fullmac card, you have to power up the hardware, reload the firmware, let the firmware boot, and then talk to it. Doing that every 2 minutes is just a waste of time, effort, and power. If you want to scan, just bring the darn card up to do it. It's so much simpler that way, and I just don't see what having all this every 2 minutes do a scan policy really buys us. That doesn't belong in the kernel. If something wants to scan, userspace can wake the card up and do the scan. It's userspace that's using the scan results to configure the card anyway, so userspace can do the scan. Simple == good. Down == down. Lets just agree on that and save ourselves a lot of pain. Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote: a) tied to the wireless hardware, switch kills hardware directly b) tied to wireless hardware, but driver handles the kill request c) just another key, a separate key driver handles the event and asks the wireless driver to kill the card It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. Furthermore, some people want to 'softkill' the hardware via software without pushing the key, which is a subset of (b) or (c) above. If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (a) is a slightly more special case - if the switch disables the radio, I guess we then want the driver to down the interface as well. In the (a) case, drivers should presumably refuse to bring the interface up if the radio is disabled? -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote: Matthew Garrett wrote: Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. I'm not sure, but thats not entirely relevant either. The time it takes for the AP to respond is not related to the delay between userspace sending the siwscan and giwscan ioctls (unless you're thinking of userspace being too quick, but GIWSCAN already returns -EINPROGRESS when appropriate so this is detectable) Ah - I've mostly been looking at the ipw* drivers, where giwscan just seems to return information cached by the ieee80211 layer. A quick scan suggests that most cards behave like this, but prism54 seems to refer to the hardware. I can see why that would cause problems. I think it's reasonable to keep the interface down, but then when the user does want to connect, bring the interface up, scan, present scan results. Scanning is quick, there would be minimal wait needed here. Yeah, that's true. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Wed, 2006-12-20 at 22:08 -0500, Daniel Drake wrote: Matthew Garrett wrote: There are additional implementation problems: scanning requires 2 different ioctl calls: siwscan, then several giwscan. If you want the driver to effectively temporarily bring the interface up when userspace requests a scan but the interface was down, then how does the driver know when to bring it down again? Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. I'm not sure, but thats not entirely relevant either. The time it takes for the AP to respond is not related to the delay between userspace sending the siwscan and giwscan ioctls (unless you're thinking of userspace being too quick, but GIWSCAN already returns -EINPROGRESS when appropriate so this is detectable) Channel dwell time for a passive scan is usually around 100ms - 250ms, depending on how accurate you want your scan results (== wait longer), and how much power you want to save (== don't wait long). Correct userspace apps should: 1) Set a timer for, say, 8 seconds 2) Issue an SIWSCAN command 3) Wait for the GIWSCAN netlink event from the card, get results via GIWSCAN command when it comes; cancel the timer from (2) 4) If the timer fires because no GIWSCAN event was received, try to get scan results via GIWSCAN command from the driver anyway rant Note that NDIS requires a driver to return _something_ within 2 seconds of a scan request. Even if you're an 802.11a card (madwifi *cough*, I'm starting a new thing where I cough after...). So it's certainly possible to return scan results in a timely manner, since the Windows drivers for these cards are obviously doing it just fine. Drivers should buffer scan results from past scans, age them appropriately, and purge them when they get too old. Drivers should never, ever, clear the scan result list when SIWSCAN or GIWSCAN is called, because that means there's a window when a scan result request from some other app could illegitimately return no BSSID records. /rant Picking a number out of thin air would be one answer, but clearly less than ideal. This may be a case of us not being able to satisfy everyone, and so just having to force the user to choose between low power or wireless scanning. I think it's reasonable to keep the interface down, but then when the user does want to connect, bring the interface up, scan, present scan results. Scanning is quick, there would be minimal wait needed here. Unless you're madwifi *cough* and then you may have to wait up to _14_ seconds for a full scan of all a/bg channels. That's just insane. I have no idea why that's the case (or at least was up to earlier this year) but it's just unacceptable. Alternatively, if you do want to prepare scan results in the background every 2 minutes, use a sequence something like: - bring interface up - siwscan - giwscan [...] - bring interface down - repeat after 2 mins If this kind of thing was implemented at the driver level, in most cases it would be identical to doing the above anyway. Right. It should 100% be in userspace and not in the drivers. Who says 2 minutes is the right interval? Putting that stuff, and the get/set commands for changing that interval, in the driver is just plain wrong. Dan Daniel - 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 03:14 +, Matthew Garrett wrote: On Wed, Dec 20, 2006 at 10:06:51PM -0500, Dan Williams wrote: a) tied to the wireless hardware, switch kills hardware directly b) tied to wireless hardware, but driver handles the kill request c) just another key, a separate key driver handles the event and asks the wireless driver to kill the card It's also complicated because some switches are supposed to rfkill both an 802.11 module _and_ a bluetooth module at the same time, or I guess some laptops may even have one rfkill switch for each wireless device. Furthermore, some people want to 'softkill' the hardware via software without pushing the key, which is a subset of (b) or (c) above. If we define interface down as meaning that the device is powered down and the radio switched off, then (b) and (c) would presumably just need to ensure that the interface is downed. (a) is a slightly more special case - if the switch disables the radio, I guess we then want the driver to down the interface as well. Correct. In the (a) case, drivers should presumably refuse to bring the interface up if the radio is disabled? Right; the driver simply can't do anything about it, because the switch is hardwired to the card and either the card's firmware takes care of it, or the chipset takes care of it. The driver has no say whatsoever in the state of the card's radio for this case. I tend to think this case is on it's way out in the same way that fullmac cards are falling out of favor (ie, do everything in software and save $$$), but they are around and we need to support them. In this case, down really does mean down too. The driver cannot honor requests to set SSID, frequency, etc, because it's simply not possible at that time. Dan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
On Thu, 2006-12-21 at 03:25 +, Matthew Garrett wrote: On Wed, Dec 20, 2006 at 10:08:22PM -0500, Daniel Drake wrote: Matthew Garrett wrote: Hm. Does the spec not set any upper bound on how long it might take for APs to respond? I'm afraid that my 802.11 knowledge is pretty slim. I'm not sure, but thats not entirely relevant either. The time it takes for the AP to respond is not related to the delay between userspace sending the siwscan and giwscan ioctls (unless you're thinking of userspace being too quick, but GIWSCAN already returns -EINPROGRESS when appropriate so this is detectable) Ah - I've mostly been looking at the ipw* drivers, where giwscan just seems to return information cached by the ieee80211 layer. A quick scan suggests that most cards behave like this, but prism54 seems to refer to the hardware. I can see why that would cause problems. Prism54 (fullmac) does background scanning all the time when the interface is up. You can't turn it off AFAIK. If you look at SIWSCAN, you'll see that it's essentially a NOP since the firmware is always scanning, and you'll always have up-to-date scan results. Ideally, all drivers would do it like prism54 does (and some later ipw versions, I think). Dan I think it's reasonable to keep the interface down, but then when the user does want to connect, bring the interface up, scan, present scan results. Scanning is quick, there would be minimal wait needed here. Yeah, that's true. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
Hmm, this reminds me of a thread from last summer, following up on some PM discussions at OLS. Thread Runtime power management for network interfaces, at the end of July. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. The _intent_ of the class suspend() and resume() methods is to let infrastructure (the network stack was explicitly mentioned!) handle pretty much everything except putting the hardware in low power modes ... which last step might, for PCI devices at least, most naturally be done in suspend_late(). That way it'd be decoupled cleanly from anything else. Now, I recently tried refreshing a patch that used those class suspend() and resume() methods, and for some reason they're not getting called. I believe they used to get called, although it's true their parameter wasn't very useful ... it was called with the underlying device, not the class_device holding state that the class driver manages. I just wanted to point out that yes, this ground has been covered before, with some agreement on that approach. It'd be good to see it pursued. :) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network drivers that don't suspend on interface down
David Brownell wrote: Hmm, this reminds me of a thread from last summer, following up on some PM discussions at OLS. Thread Runtime power management for network interfaces, at the end of July. 2) Network device infrastructure should make it easier for devices: bring interface down on suspend and bring it up after resume (if it was running when suspended). This would allow many devices to have no suspend/resume hook; except those that have some better power control over hardware. The _intent_ of the class suspend() and resume() methods is to let infrastructure (the network stack was explicitly mentioned!) handle pretty much everything except putting the hardware in low power modes ... which last step might, for PCI devices at least, most naturally be done in suspend_late(). That way it'd be decoupled cleanly from anything else. The class methods don't work right for that because the physical class (PCI) gets called before the virtual class (network devices). Now, I recently tried refreshing a patch that used those class suspend() and resume() methods, and for some reason they're not getting called. I believe they used to get called, although it's true their parameter wasn't very useful ... it was called with the underlying device, not the class_device holding state that the class driver manages. I just wanted to point out that yes, this ground has been covered before, with some agreement on that approach. It'd be good to see it pursued. :) - Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
