Re: Changes to sysfs PM layer break userspace
On Fri, Dec 22, 2006 at 08:44:01PM +, Pavel Machek wrote: > Hi! > > > > which userspace is using this btw? > > > > Ubuntu uses it to disable wireless hardware under certain circumstances. > > I believe that Suse's powernowd uses it to power down wired ethernet > > hardware when it's not in use. Powersaved had implemented this, but it was always declared an experimental feature and AFAIK is gone since quite some time. > I flamed seife for this. It was always broken for 20%-or-so of > hardware. It is _not_ simple to fix. It was an experimental feature in the words sense: For experimentation. I never accepted any bugreports for that but told the reporters to go away :-) -- Stefan Seyfried QA / R&D Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." - 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: Changes to sysfs PM layer break userspace
Hi! > > which userspace is using this btw? > > Ubuntu uses it to disable wireless hardware under certain circumstances. > I believe that Suse's powernowd uses it to power down wired ethernet > hardware when it's not in use. I flamed seife for this. It was always broken for 20%-or-so of hardware. It is _not_ simple to fix. 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: Changes to sysfs PM layer break userspace
> > > > > What we should do is to revert 047bda36150d11422b2c7bacca1df324c909c0b3 > > > and > > > > Bad answer > > Is better than breaking stuff. .. stuff that made assumptions about something and did stuff it probably shouldn't have been doing for the intent it had ;) the semantics of this thing were clear as mud, and actually disfunctional (and the user of it that "broke" actually wanted something else, but didn't because a few drivers didn't implement it quite the right way) -- 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: Changes to sysfs PM layer break userspace
On Wednesday 20 December 2006 9:02 pm, Andrew Morton wrote: > > ... see my original reply in this thread. If "the answer" is > > to involve making PCI devices work again, better solutions include reverting > > the patch I mentioned (adding the suspend_late/resume_early support to PCI) > > or a version of what Matthew has produced (poking through bus layers so > > that test can be made to fail when the bus supports those methods but the > > specific device's driver doesn't use them). > > > > We appear to have a choice of three options. But I see no fix in Greg's > tree. Please let's not just accidentally forget to do this. Plus the fourth "leave it be" option, which I guess you're voting against. Of those options, I'd go for something like Matthew's patch to add a new layer-punching hook. (I'll look at his latest tomorrow, and do something appropriate with it.) It's interesting that there was no evident motion on these network PM issues after the OLS (and then netdev) discussion last summer ... but there is now much more active discussion. Evidently PM issues are still ignored until a fire gets set. - 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: Changes to sysfs PM layer break userspace
On Wed, 20 Dec 2006 20:56:27 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 20 December 2006 7:51 pm, Andrew Morton wrote:
>
> > > + if (!warned) {
> > > + printk(KERN_WARNING
> > > + "*** WARNING *** sysfs devices/.../power/state files "
> > > + "are only for testing, and will be removed\n");
> > > + warned = error;
> > > + }
> > > +
> > > /* disallow incomplete suspend sequences */
> > > if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early))
> > > return error;
> >
> > Well that's not much use. It tells people "hey, we broke it". They
> > already knew that.
>
> No, it only does what you asked for: warning people that they're using
> something that's going away. It says nothing about "broke".
>
But it's still broken, is it not?
>
> > What we should do is to revert 047bda36150d11422b2c7bacca1df324c909c0b3 and
>
> Bad answer
Is better than breaking stuff.
> ... see my original reply in this thread. If "the answer" is
> to involve making PCI devices work again, better solutions include reverting
> the patch I mentioned (adding the suspend_late/resume_early support to PCI)
> or a version of what Matthew has produced (poking through bus layers so
> that test can be made to fail when the bus supports those methods but the
> specific device's driver doesn't use them).
>
We appear to have a choice of three options. But I see no fix in Greg's
tree. Please let's not just accidentally forget to do this.
-
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: Changes to sysfs PM layer break userspace
On Wednesday 20 December 2006 7:51 pm, Andrew Morton wrote:
> > + if (!warned) {
> > + printk(KERN_WARNING
> > + "*** WARNING *** sysfs devices/.../power/state files "
> > + "are only for testing, and will be removed\n");
> > + warned = error;
> > + }
> > +
> > /* disallow incomplete suspend sequences */
> > if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early))
> > return error;
>
> Well that's not much use. It tells people "hey, we broke it". They
> already knew that.
No, it only does what you asked for: warning people that they're using
something that's going away. It says nothing about "broke".
> What we should do is to revert 047bda36150d11422b2c7bacca1df324c909c0b3 and
Bad answer ... see my original reply in this thread. If "the answer" is
to involve making PCI devices work again, better solutions include reverting
the patch I mentioned (adding the suspend_late/resume_early support to PCI)
or a version of what Matthew has produced (poking through bus layers so
that test can be made to fail when the bus supports those methods but the
specific device's driver doesn't use them).
- 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: Changes to sysfs PM layer break userspace
On Tue, 19 Dec 2006 19:29:13 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 19 December 2006 6:15 pm, Andrew Morton wrote:
> > On Tue, 19 Dec 2006 13:34:49 -0800
> > David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > Documentation/feature-removal-schedule.txt has warned about this since
> > > August
> >
> > Nobody reads that.
> >
> > Please, wherever possible, put a nice printk("this is going away") in the
> > code
> > when planning these things.
>
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
> Index: g26/drivers/base/power/sysfs.c
> ===
> --- g26.orig/drivers/base/power/sysfs.c 2006-09-27 16:19:00.0
> -0700
> +++ g26/drivers/base/power/sysfs.c2006-12-19 19:27:25.0 -0800
> @@ -42,9 +42,17 @@ static ssize_t state_show(struct device
>
> static ssize_t state_store(struct device * dev, struct device_attribute
> *attr, const char * buf, size_t n)
> {
> + static int warned;
> pm_message_t state;
> int error = -EINVAL;
>
> + if (!warned) {
> + printk(KERN_WARNING
> + "*** WARNING *** sysfs devices/.../power/state files "
> + "are only for testing, and will be removed\n");
> + warned = error;
> + }
> +
> /* disallow incomplete suspend sequences */
> if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early))
> return error;
Well that's not much use. It tells people "hey, we broke it". They
already knew that.
What we should do is to revert 047bda36150d11422b2c7bacca1df324c909c0b3 and
add a printk("hey, we'll be breaking this soon").
-
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: Changes to sysfs PM layer break userspace
On Dec 19, 2006, at 15:55:43, Arjan van de Ven wrote: On Tue, 2006-12-19 at 20:32 +, Matthew Garrett wrote: On Tue, Dec 19, 2006 at 09:23:05PM +0100, Arjan van de Ven wrote: On Tue, 2006-12-19 at 20:08 +, Matthew Garrett wrote: I'm not sure. Suspending the chip means you lose things like link beat detection, so it's not something you necessarily want to automatically tie to something like interface status. right now the "spec" for Linux network drivers assumes that you put the NIC into D3 on down, except for cases where Wake-on-Lan is enabled etc. Really? I can't find any drivers that seem to do this. The only calls to pci_set_power_state seem to be in the suspend, resume, init and exit routines. your grep missed tg3.c for example, which has a wrapper around the power state code and goes to D3hot on downing of the interface. (just the first one I looked at as a "reference driver", others probably do the same thing) I actually kind of like this feature; it makes it possible for "ifdown" to virtually "unplug" the cable, such that the remote end doesn't have an activated link. Admittedly it would be slightly more useful to have the ifdown and the virtual-unplug be separate events. There have been at least a few times where my Linux box is connected to a network port I don't control that maintains some independent state, and it's handy to be able to reset that state remotely. Cheers, Kyle Moffett - 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: Changes to sysfs PM layer break userspace
On Tue, 19 Dec 2006 18:35:39 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Dec 2006 18:15:24 -0800 Andrew Morton wrote:
>
> > On Tue, 19 Dec 2006 13:34:49 -0800
> > David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > > Documentation/feature-removal-schedule.txt has warned about this since
> > > August
> >
> > Nobody reads that.
>
> Ugh, I read it.
>
> > Please, wherever possible, put a nice printk("this is going away") in the
> > code
> > when planning these things.
>
> Can notices go in both places, or is in the source code (printk)
> now the preferred way?
I think printks grab a lot more attention. It's not surprising that people
get surprised when the feature they're using goes away.
Plus they may not even know that that they're using the feature. A printk
fixes that.
> I think that we can point people to Doc/feature-removal-schedule.txt
> easier (and more effectively) than we can source code (or noisy kernel
> logs).
Hopefully developers who see the printk will think to look in
feature-removal-schedule.txt for more details.
-
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: Changes to sysfs PM layer break userspace
On Tuesday 19 December 2006 6:15 pm, Andrew Morton wrote:
> On Tue, 19 Dec 2006 13:34:49 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Documentation/feature-removal-schedule.txt has warned about this since
> > August
>
> Nobody reads that.
>
> Please, wherever possible, put a nice printk("this is going away") in the code
> when planning these things.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: g26/drivers/base/power/sysfs.c
===
--- g26.orig/drivers/base/power/sysfs.c 2006-09-27 16:19:00.0 -0700
+++ g26/drivers/base/power/sysfs.c 2006-12-19 19:27:25.0 -0800
@@ -42,9 +42,17 @@ static ssize_t state_show(struct device
static ssize_t state_store(struct device * dev, struct device_attribute *attr,
const char * buf, size_t n)
{
+ static int warned;
pm_message_t state;
int error = -EINVAL;
+ if (!warned) {
+ printk(KERN_WARNING
+ "*** WARNING *** sysfs devices/.../power/state files "
+ "are only for testing, and will be removed\n");
+ warned = error;
+ }
+
/* disallow incomplete suspend sequences */
if (dev->bus && (dev->bus->suspend_late || dev->bus->resume_early))
return error;
-
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: Changes to sysfs PM layer break userspace
On Tue, 19 Dec 2006 18:15:24 -0800 Andrew Morton wrote:
> On Tue, 19 Dec 2006 13:34:49 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > Documentation/feature-removal-schedule.txt has warned about this since
> > August
>
> Nobody reads that.
Ugh, I read it.
> Please, wherever possible, put a nice printk("this is going away") in the code
> when planning these things.
Can notices go in both places, or is in the source code (printk)
now the preferred way?
I think that we can point people to Doc/feature-removal-schedule.txt
easier (and more effectively) than we can source code (or noisy kernel
logs).
---
~Randy
-
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: Changes to sysfs PM layer break userspace
On Tue, 19 Dec 2006 13:34:49 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> Documentation/feature-removal-schedule.txt has warned about this since
> August
Nobody reads that.
Please, wherever possible, put a nice printk("this is going away") in the code
when planning these things.
-
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: Changes to sysfs PM layer break userspace
On Tue, Dec 19, 2006 at 01:34:49PM -0800, David Brownell wrote: > Documentation/feature-removal-schedule.txt has warned about this since > August, and the PM list has discussed how broken that model is numerous > times over the past several years. (I'm pretty sure that discussion has > leaked out to LKML on occasion.) It shouldn't be news today. 1) feature-removal-schedule.txt says that it'll be removed in July 2007. This isn't July 2007. 2) The functionality was disabled in 2.6.19. The addition to feature-removal-schedule.txt was in, uh, 2.6.19. 3) "The whole _point_ of a kernel is to act as a abstraction layer and resource management between user programs and hardware/outside world. That's why kernels _exist_. Breaking user-land API's is thus by definition something totally idiotic. If you need to break something, you create a new interface, and try to translate between the two, and maybe you deprecate the old one so that it can be removed once it's not in use any more. If you can't see that this is how a kernel should work, you're missing the point of having a kernel in the first place." Linus, http://lkml.org/lkml/2006/10/4/327 -- 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: Changes to sysfs PM layer break userspace
On Tue, Dec 19, 2006 at 01:22:12PM -0800, David Brownell wrote: > Stop trying to use broken and deprecated APIs; and realize that "previously > working" meant you just hadn't tripped over the serious bugs yet. I'm happy to stop using broken and deprecated APIs, providing that there's *actually a replacement*. > Drivers can and should know how to do that sort of stuff themselves, > so the power savings are reliable and consistent no matter what user > space tools are (or aren't) used. To the extent that that's possible, I entirely agree - however, it clearly isn't always. Not all hardware can be powered down without losing functionality, and so in those cases it's important that there be a mechanism to allow that decision to be made by userspace. > Drivers know how to get power savings a lot better than any userspace > code ever could ... with the exception of hints like "ifdown eth0" > letting the driver know that right now is a good time to power down > almost everything, since it's not going to be used until "ifup". But in the cases where you don't have fine grained power management in the hardware, it's still desirable to be able to suspend an unused network agent. The driver can't do it by default, because that would break existing behaviour. > As a generic mechanism, that interface has *ALWAYS* been "broken > by design"; I'd call it unfixable. It's deprecated, and scheduled > to vanish; see Documentation/feature-removal-schedule.txt ... The fact that something is scheduled to be removed in July 2007 does *not* mean it's acceptable to break it in 2006. We need to find a way to fix this functionality in the meantime. -- 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: Changes to sysfs PM layer break userspace
On Tuesday 19 December 2006 12:32 pm, Matthew Garrett wrote: > On Tue, Dec 19, 2006 at 09:23:05PM +0100, Arjan van de Ven wrote: > > right now the "spec" for Linux network drivers assumes that you put the > > NIC into D3 on down, except for cases where Wake-on-Lan is enabled etc. > > Really? I can't find any drivers that seem to do this. The only calls to > pci_set_power_state seem to be in the suspend, resume, init and exit > routines. More drivers should do this, even though not many do so right now. In the ideal case, the PHY can be active for link detection without the rest of the adapter being powered up... > > > Some chips support more > > > fine-grained power management, so we could do something more sensible in > > > that case - but right now, there doesn't seem to be a lot of driver > > > support for it. > > > > sounds like that's the right approach at least .. not talking to the PCI > > hardware directly from userspace... > > I'd certainly agree that that's the right thing to do, but userspace has > a habit of using whatever functionality /is/ available to get to a given > end. The semantics of the device/power/state file were never made > terribly clear, and it did have the desired effect of suspending the > device. Removing it without providing warning or a transition pathway is > a pain. Documentation/feature-removal-schedule.txt has warned about this since August, and the PM list has discussed how broken that model is numerous times over the past several years. (I'm pretty sure that discussion has leaked out to LKML on occasion.) It shouldn't be news today. > > I can see the point of having more than just "UP" and "DOWN" as > > interface states; "UP", "DOWN" and "OFF" for example... > > Agreed. More than one driver stack probably needs to start paying attention to its power management models. I think Arjan is right about the basic mindset of "down == off" for network drivers. If there are cases where that doesn't work, those can start driving improvements. - 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: Changes to sysfs PM layer break userspace
On Tuesday 19 December 2006 10:52 am, Matthew Garrett wrote: > Commit 047bda36150d11422b2c7bacca1df324c909c0b3 broke userspace. Actually, no ... that just prevented breakage enabled by commit cbd69dbbf1adfce6e048f15afc8629901ca9dae5 which taught PCI how to use the new irqs-off suspend_late()/resume_early() driver model calls. > Previously, /sys/bus/pci/devices/foo/power/state could have values > echoed into it for triggering suspend/resume calls in the driver. In general, it still can; though not for PCI, because of the change I pointed out above. What the patch you mentioned changes is something else: it refuses to do so when those calls should require leaving the system in an IRQs-off mode. Rather obviously, IRQs-off is fine for entering system-wide suspend states. But Linux can't stay in that mode for normal operations ... > The > breakage is handily mentioned in the comment: > > "Devices with bus.suspend_late(), or bus.resume_early() methods fail > this operation; those methods couldn't be called." And the reason they couldn't be called is: that they guarantee IRQs would stay off between suspend_late() and resume_early(). > but there's no mention of what previously working code is supposed to do > now. Stop trying to use broken and deprecated APIs; and realize that "previously working" meant you just hadn't tripped over the serious bugs yet. Work with driver framework developers to come up with a solution for the _real_ problem, which IMO will look more like "teach stack about power management" than "bypass all the driver layers and go right to a PCI-specific mechanism, even for non-PCI drivers". >> Ubuntu uses it to disable wireless hardware under certain circumstances. >> I believe that Suse's powernowd uses it to power down wired ethernet >> hardware when it's not in use. Drivers can and should know how to do that sort of stuff themselves, so the power savings are reliable and consistent no matter what user space tools are (or aren't) used. Drivers know how to get power savings a lot better than any userspace code ever could ... with the exception of hints like "ifdown eth0" letting the driver know that right now is a good time to power down almost everything, since it's not going to be used until "ifup". (Agreed that other hints may be desirable, but that's a different issue ... probably best addressed at the framework level, e.g. WLAN, rather than by hacks to individual drivers.) > That's the second time in the past year or so that this interface > has been broken - can we have it working again, please, especially as > there doesn't appear to be an alternative yet? As a generic mechanism, that interface has *ALWAYS* been "broken by design"; I'd call it unfixable. It's deprecated, and scheduled to vanish; see Documentation/feature-removal-schedule.txt ... - 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: Changes to sysfs PM layer break userspace
On Tue, 2006-12-19 at 20:32 +, Matthew Garrett wrote: > On Tue, Dec 19, 2006 at 09:23:05PM +0100, Arjan van de Ven wrote: > > On Tue, 2006-12-19 at 20:08 +, Matthew Garrett wrote: > > > I'm not sure. Suspending the chip means you lose things like link beat > > > detection, so it's not something you necessarily want to automatically > > > tie to something like interface status. > > > > right now the "spec" for Linux network drivers assumes that you put the > > NIC into D3 on down, except for cases where Wake-on-Lan is enabled etc. > > Really? I can't find any drivers that seem to do this. The only calls to > pci_set_power_state seem to be in the suspend, resume, init and exit > routines. your grep missed tg3.c for example, which has a wrapper around the power state code and goes to D3hot on downing of the interface. (just the first one I looked at as a "reference driver", others probably do the same thing) -- 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: Changes to sysfs PM layer break userspace
On Tue, Dec 19, 2006 at 09:23:05PM +0100, Arjan van de Ven wrote: > On Tue, 2006-12-19 at 20:08 +, Matthew Garrett wrote: > > I'm not sure. Suspending the chip means you lose things like link beat > > detection, so it's not something you necessarily want to automatically > > tie to something like interface status. > > right now the "spec" for Linux network drivers assumes that you put the > NIC into D3 on down, except for cases where Wake-on-Lan is enabled etc. Really? I can't find any drivers that seem to do this. The only calls to pci_set_power_state seem to be in the suspend, resume, init and exit routines. > > Some chips support more > > fine-grained power management, so we could do something more sensible in > > that case - but right now, there doesn't seem to be a lot of driver > > support for it. > > sounds like that's the right approach at least .. not talking to the PCI > hardware directly from userspace... I'd certainly agree that that's the right thing to do, but userspace has a habit of using whatever functionality /is/ available to get to a given end. The semantics of the device/power/state file were never made terribly clear, and it did have the desired effect of suspending the device. Removing it without providing warning or a transition pathway is a pain. > I can see the point of having more than just "UP" and "DOWN" as > interface states; "UP", "DOWN" and "OFF" for example... Agreed. -- 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: Changes to sysfs PM layer break userspace
On Tue, 2006-12-19 at 20:08 +, Matthew Garrett wrote: > On Tue, Dec 19, 2006 at 09:03:21PM +0100, Arjan van de Ven wrote: > > > humm shouldn't the driver do this when the interface is brought down? > > sounds like you're playing with fire to do this behind the drivers' > > back > > I'm not sure. Suspending the chip means you lose things like link beat > detection, so it's not something you necessarily want to automatically > tie to something like interface status. right now the "spec" for Linux network drivers assumes that you put the NIC into D3 on down, except for cases where Wake-on-Lan is enabled etc. > Some chips support more > fine-grained power management, so we could do something more sensible in > that case - but right now, there doesn't seem to be a lot of driver > support for it. sounds like that's the right approach at least .. not talking to the PCI hardware directly from userspace... I can see the point of having more than just "UP" and "DOWN" as interface states; "UP", "DOWN" and "OFF" for example... -- 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: Changes to sysfs PM layer break userspace
On Tue, Dec 19, 2006 at 09:03:21PM +0100, Arjan van de Ven wrote: > humm shouldn't the driver do this when the interface is brought down? > sounds like you're playing with fire to do this behind the drivers' > back I'm not sure. Suspending the chip means you lose things like link beat detection, so it's not something you necessarily want to automatically tie to something like interface status. Some chips support more fine-grained power management, so we could do something more sensible in that case - but right now, there doesn't seem to be a lot of driver support for 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: Changes to sysfs PM layer break userspace
On Tue, 2006-12-19 at 19:44 +, Matthew Garrett wrote: > On Tue, Dec 19, 2006 at 08:34:48PM +0100, Arjan van de Ven wrote: > > > which userspace is using this btw? > > Ubuntu uses it to disable wireless hardware under certain circumstances. > I believe that Suse's powernowd uses it to power down wired ethernet > hardware when it's not in use. humm shouldn't the driver do this when the interface is brought down? sounds like you're playing with fire to do this behind the drivers' back -- 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: Changes to sysfs PM layer break userspace
On Tue, Dec 19, 2006 at 08:34:48PM +0100, Arjan van de Ven wrote: > which userspace is using this btw? Ubuntu uses it to disable wireless hardware under certain circumstances. I believe that Suse's powernowd uses it to power down wired ethernet hardware when it's not in use. -- 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: Changes to sysfs PM layer break userspace
On Tue, 2006-12-19 at 18:52 +, Matthew Garrett wrote: > Commit 047bda36150d11422b2c7bacca1df324c909c0b3 broke userspace. > Previously, /sys/bus/pci/devices/foo/power/state could have values > echoed into it for triggering suspend/resume calls in the driver. The > breakage is handily mentioned in the comment: > > "Devices with bus.suspend_late(), or bus.resume_early() methods fail > this operation; those methods couldn't be called." > > but there's no mention of what previously working code is supposed to do > now. That's the second time in the past year or so that this interface > has been broken - can we have it working again, please, especially as > there doesn't appear to be an alternative yet? which userspace is using this btw? - 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/
Changes to sysfs PM layer break userspace
Commit 047bda36150d11422b2c7bacca1df324c909c0b3 broke userspace. Previously, /sys/bus/pci/devices/foo/power/state could have values echoed into it for triggering suspend/resume calls in the driver. The breakage is handily mentioned in the comment: "Devices with bus.suspend_late(), or bus.resume_early() methods fail this operation; those methods couldn't be called." but there's no mention of what previously working code is supposed to do now. That's the second time in the past year or so that this interface has been broken - can we have it working again, please, especially as there doesn't appear to be an alternative yet? -- 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/
