* Re: NAK new drivers without proper power management? [not found] ` <fa.Jy0FJQtASvVEpsy8Q96uoHtyEVA@ifi.uio.no> @ 2007-02-10 1:50 ` Robert Hancock 2007-02-10 1:59 ` Lee Revell ` (2 more replies) 0 siblings, 3 replies; 155+ messages in thread From: Robert Hancock @ 2007-02-10 1:50 UTC (permalink / raw) To: linux-kernel; +Cc: Jeff Garzik, nigel Jeff Garzik wrote: > Nigel Cunningham wrote: >> Hi. >> >> On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: >>> On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: >>>> Hi. >>>> >>>> I don't think this is already done (feel free to correct me if I'm >>>> wrong).. >>>> >>>> Can we start to NAK new drivers that don't have proper power management >>>> implemented? There really is no excuse for writing a new driver and not >>>> putting .suspend and .resume methods in anymore, is there? >>> >>> to a large degree, a device driver that doesn't suspend is better than >>> no device driver at all, right? >> >> I'm not sure it is. It only makes more work for everyone else: We have >> to help people figure out what causes their computer to fail to resume >> (which can take quite a while), then get them them complain to driver >> author, and the driver author has to submit patches to fix it. >> >> All of this is avoided if they'll just do it right in the first place. > > A lot of a lot of things could have been avoided, if they just did it > right the first time. > > I think it's more valuable to users to get a basic network driver that > pings or a basic ATA driver that reads/writes, than peripheral issues > like suspend/resume. > > Certainly we should ask for it, but it shouldn't be a merge-stopper. > > Jeff I would disagree that it's a peripheral issue, it's pretty core these days, at least for any hardware that you can stuff in a laptop (though a fair number of desktops get suspended and resumed these days too). One driver on a system which doesn't suspend or resume properly can ruin the entire process, causing a ton of user frustration. Certainly I would consider a driver without suspend/resume support to be incomplete. The trouble with deferring adding this support is that it's a lot harder to add this support in after the fact than if it was considered during the original driver development. I would be in favor of not merging drivers lacking suspend unless there's a very good reason they're lacking it. It also kind of bothers me that if a driver has no suspend/resume functions, and you suspend and resume the system, we don't complain about it even though there's a very good chance that device is not going to function properly. How about something in dmesg like: Warning: driver for device XXXX has no suspend or resume support. Device may not function properly after resume. so that users know who to complain to. Maybe there are some devices that truly don't need any handling for suspend, but if so I suspect the number of those is small enough that adding empty functions would be a good-enough solution. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 1:50 ` NAK new drivers without proper power management? Robert Hancock @ 2007-02-10 1:59 ` Lee Revell 2007-02-10 2:09 ` Nigel Cunningham ` (2 more replies) 2007-02-10 2:05 ` Nigel Cunningham 2007-02-10 3:02 ` [PATCH] " Nigel Cunningham 2 siblings, 3 replies; 155+ messages in thread From: Lee Revell @ 2007-02-10 1:59 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel, Jeff Garzik, nigel On 2/9/07, Robert Hancock <hancockr@shaw.ca> wrote: > I would disagree that it's a peripheral issue, it's pretty core these > days, at least for any hardware that you can stuff in a laptop (though a > fair number of desktops get suspended and resumed these days too). Servers are still the most important Linux market, and don't care about suspend/resume. I would consider implementing suspend./resume for a driver that will only be used in server or HPC class hardware a waste of valuable development resources. Lee ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 1:59 ` Lee Revell @ 2007-02-10 2:09 ` Nigel Cunningham 2007-02-10 2:22 ` Lee Revell 2007-02-10 4:35 ` Joseph Fannin 2007-02-10 12:47 ` Stefan Richter 2 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 2:09 UTC (permalink / raw) To: Lee Revell; +Cc: Robert Hancock, linux-kernel, Jeff Garzik Hi. On Fri, 2007-02-09 at 20:59 -0500, Lee Revell wrote: > On 2/9/07, Robert Hancock <hancockr@shaw.ca> wrote: > > I would disagree that it's a peripheral issue, it's pretty core these > > days, at least for any hardware that you can stuff in a laptop (though a > > fair number of desktops get suspended and resumed these days too). > > Servers are still the most important Linux market, and don't care > about suspend/resume. I would consider implementing suspend./resume > for a driver that will only be used in server or HPC class hardware a > waste of valuable development resources. Not necessarily. Imagine suspending to disk in order to replace a faulty card. That could be way faster and less disruptive than shutting down normally and loosing caches and so on. Irrespective of the above, servers tend not to have too much in the way of hardware unique to them anyway, and even if you don't find it useful, that's not to say others won't want it. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 2:09 ` Nigel Cunningham @ 2007-02-10 2:22 ` Lee Revell 2007-02-10 3:21 ` Kevin Fox 2007-02-10 20:40 ` Adrian Bunk 0 siblings, 2 replies; 155+ messages in thread From: Lee Revell @ 2007-02-10 2:22 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, linux-kernel, Jeff Garzik On 2/9/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > On Fri, 2007-02-09 at 20:59 -0500, Lee Revell wrote: > > On 2/9/07, Robert Hancock <hancockr@shaw.ca> wrote: > > > I would disagree that it's a peripheral issue, it's pretty core these > > > days, at least for any hardware that you can stuff in a laptop (though a > > > fair number of desktops get suspended and resumed these days too). > > > > Servers are still the most important Linux market, and don't care > > about suspend/resume. I would consider implementing suspend./resume > > for a driver that will only be used in server or HPC class hardware a > > waste of valuable development resources. > > Not necessarily. Imagine suspending to disk in order to replace a faulty > card. That could be way faster and less disruptive than shutting down > normally and loosing caches and so on. > Hmm. If uptime is critical I would make sure to have redundant systems anyway and I would just reboot the thing. I would not expect the suspend/resume paths on server class hardware like 10gig ethernet, Infiniband adapters, or high end SCSI to be particularly well tested. > Irrespective of the above, servers tend not to have too much in the way > of hardware unique to them anyway, and even if you don't find it useful, > that's not to say others won't want it. Yes but for such hardware, suspend/resume is likely to be a lot of work to implement, and I'd rather the developers devote those resources to making the driver as stable and performant as possible. I agree 100% that drivers for desktop and laptop hardware should be rejected if missing suspend/resume. Lee ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 2:22 ` Lee Revell @ 2007-02-10 3:21 ` Kevin Fox 2007-02-10 20:40 ` Adrian Bunk 1 sibling, 0 replies; 155+ messages in thread From: Kevin Fox @ 2007-02-10 3:21 UTC (permalink / raw) To: Lee Revell; +Cc: nigel, Robert Hancock, linux-kernel, Jeff Garzik On Fri, 2007-02-09 at 18:22 -0800, Lee Revell wrote: > On 2/9/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > > On Fri, 2007-02-09 at 20:59 -0500, Lee Revell wrote: > > > On 2/9/07, Robert Hancock <hancockr@shaw.ca> wrote: > > > > I would disagree that it's a peripheral issue, it's pretty core > these > > > > days, at least for any hardware that you can stuff in a laptop > (though a > > > > fair number of desktops get suspended and resumed these days > too). > > > > > > Servers are still the most important Linux market, and don't care > > > about suspend/resume. I would consider implementing > suspend./resume > > > for a driver that will only be used in server or HPC class > hardware a > > > waste of valuable development resources. > > > > Not necessarily. Imagine suspending to disk in order to replace a > faulty > > card. That could be way faster and less disruptive than shutting > down > > normally and loosing caches and so on. > > > > Hmm. If uptime is critical I would make sure to have redundant > systems anyway and I would just reboot the thing. I would not expect > the suspend/resume paths on server class hardware like 10gig ethernet, > Infiniband adapters, or high end SCSI to be particularly well tested. Speaking from the HPC standpoint, we are gaining more and more nodes in clusters as time goes on, so the potential for single failures affecting performance is growing. A lot of the server class nodes have redundancy such that the node slows down but not die on failure. Unfortunately, slowdown in a single node in a tightly coupled job can greatly affect performance. A good example would be ECC memory. If a chip is going bad, the machine can detect it but it will run slower until the memory is replaced. This one node can affect thousands of other nodes in the same job. Having a mechanism to migrate the operating system that is running on this failing node to another node would be quite beneficial to performance. If all drivers properly supported suspend/resume, it could possibly be extended to support migration to another node as well. At least for the HPC world, we'd like to see, and encourage, the hardware you describe getting full support for suspend/resume. Kevin > > Irrespective of the above, servers tend not to have too much in the > way > > of hardware unique to them anyway, and even if you don't find it > useful, > > that's not to say others won't want it. > > Yes but for such hardware, suspend/resume is likely to be a lot of > work to implement, and I'd rather the developers devote those > resources to making the driver as stable and performant as possible. > > I agree 100% that drivers for desktop and laptop hardware should be > rejected if missing suspend/resume. > > Lee > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 2:22 ` Lee Revell 2007-02-10 3:21 ` Kevin Fox @ 2007-02-10 20:40 ` Adrian Bunk 1 sibling, 0 replies; 155+ messages in thread From: Adrian Bunk @ 2007-02-10 20:40 UTC (permalink / raw) To: Lee Revell; +Cc: nigel, Robert Hancock, linux-kernel, Jeff Garzik On Fri, Feb 09, 2007 at 09:22:48PM -0500, Lee Revell wrote: > On 2/9/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > >On Fri, 2007-02-09 at 20:59 -0500, Lee Revell wrote: > >> On 2/9/07, Robert Hancock <hancockr@shaw.ca> wrote: > >> > I would disagree that it's a peripheral issue, it's pretty core these > >> > days, at least for any hardware that you can stuff in a laptop (though > >a > >> > fair number of desktops get suspended and resumed these days too). > >> > >> Servers are still the most important Linux market, and don't care > >> about suspend/resume. I would consider implementing suspend./resume > >> for a driver that will only be used in server or HPC class hardware a > >> waste of valuable development resources. > > > >Not necessarily. Imagine suspending to disk in order to replace a faulty > >card. That could be way faster and less disruptive than shutting down > >normally and loosing caches and so on. > > > > Hmm. If uptime is critical I would make sure to have redundant > systems anyway and I would just reboot the thing. I would not expect > the suspend/resume paths on server class hardware like 10gig ethernet, > Infiniband adapters, or high end SCSI to be particularly well tested. >... 10gig ethernet will be commodity hardware 5 years from now like 1gig ethernet today where you can get cards for 12 Euro and switches for 40 Euro. > Lee cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 1:59 ` Lee Revell 2007-02-10 2:09 ` Nigel Cunningham @ 2007-02-10 4:35 ` Joseph Fannin 2007-02-13 21:08 ` Pavel Machek 2007-02-10 12:47 ` Stefan Richter 2 siblings, 1 reply; 155+ messages in thread From: Joseph Fannin @ 2007-02-10 4:35 UTC (permalink / raw) To: Lee Revell; +Cc: Robert Hancock, linux-kernel, Jeff Garzik, nigel On Fri, Feb 09, 2007 at 08:59:55PM -0500, Lee Revell wrote: > On 2/9/07, Robert Hancock <hancockr@shaw.ca> wrote: > >I would disagree that it's a peripheral issue, it's pretty core these > >days, at least for any hardware that you can stuff in a laptop (though a > >fair number of desktops get suspended and resumed these days too). > > Servers are still the most important Linux market, and don't care > about suspend/resume. I would consider implementing suspend./resume > for a driver that will only be used in server or HPC class hardware a > waste of valuable development resources. Please allow me to be offensively blunt for a moment. So, the situation seems to be: 1. The work of the suspend developer who engages the users who put effort into making suspend work on their hardware (bless their addled little heads) often doesn't meet kernel standards, or isn't well enough documented to prove the real *need* for the features and/or hacks that have happened to get actual users' systems sleeping and running again. 2. The swsusp maintainer continues in the belief that as long as their are no bug reports in kernel bugzilla or crossing the (relatively obscure) swsusp mailing lists, it has zarro boogs and meanwhile works on the fourth implementation of suspend support in as many years. It's in CVS on sourceforge. There's no documentation whatsoever. 3. There's another guy who appears to be doing a lot of work, so I shan't leave him out. Like the two developers previously mentioned, he seems to be working pretty hard on the whole thing. The previously mentioned fourth suspend implementation seems to be largely his doing, for good and for ill. 4. "Everybody" knows suspend doesn't work on Linux without a huge amount of tinkering, deep magic, and dead chickens. Only Gentoo users seem to bother; everyone else waits for Ubuntu 12.04 wherein suspend will "just work". The Gentoo users all use swsusp2, as it contains the hacks to work around: 5. All the suspend developers blame the lack of power-management support in drivers for the inablility of Linux to properly suspend on anything that doesn't support APM. 6. Getting proper power-management support in Linux device drivers is not a priority; drivers without any power management support whatsoever should not only be accepted -- they should be merged without comment or complaint. How is working suspend support ever supposed to happen? -- Joseph Fannin jfannin@gmail.com || jhf@columbus.rr.com ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 4:35 ` Joseph Fannin @ 2007-02-13 21:08 ` Pavel Machek 0 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-13 21:08 UTC (permalink / raw) To: Lee Revell, Robert Hancock, linux-kernel, Jeff Garzik, nigel Hi! > > >I would disagree that it's a peripheral issue, it's pretty core these > > >days, at least for any hardware that you can stuff in a laptop (though a > > >fair number of desktops get suspended and resumed these days too). > > > > Servers are still the most important Linux market, and don't care > > about suspend/resume. I would consider implementing suspend./resume > > for a driver that will only be used in server or HPC class hardware a > > waste of valuable development resources. > > Please allow me to be offensively blunt for a moment. > > So, the situation seems to be: > > 1. The work of the suspend developer who engages the users who put > effort into making suspend work on their hardware (bless > their addled little heads) often doesn't meet kernel standards, > or isn't well enough documented to prove the real *need* for > the features and/or hacks that have happened to get actual > users' systems sleeping and running again. > > 2. The swsusp maintainer continues in the belief that as long as > their are no bug reports in kernel bugzilla or crossing the > (relatively obscure) swsusp mailing lists, it has zarro boogs > and meanwhile works on the fourth implementation of suspend > support in as many years. It's in CVS on sourceforge. There's > no documentation whatsoever. .... > 4. "Everybody" knows suspend doesn't work on Linux without a huge > amount of tinkering, deep magic, and dead chickens. Only > Gentoo users seem to bother; everyone else waits for Ubuntu > 12.04 wherein suspend will "just work". The Gentoo users all > use swsusp2, as it contains the hacks to work around: Suspend just works in suse10.2 (and suse10.1, and suse10.0, ...)... thanks to work seife did on pm scripts. It is not my fault if it is broken on your distro. > 6. Getting proper power-management support in Linux device drivers > is not a priority; drivers without any power management support > whatsoever should not only be accepted -- they should be merged > without comment or complaint. > > How is working suspend support ever supposed to happen? If people stopped sending rants and started sending patches... yep, that would help. I don't have all the notebooks ever produced, sorry. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 1:59 ` Lee Revell 2007-02-10 2:09 ` Nigel Cunningham 2007-02-10 4:35 ` Joseph Fannin @ 2007-02-10 12:47 ` Stefan Richter 2 siblings, 0 replies; 155+ messages in thread From: Stefan Richter @ 2007-02-10 12:47 UTC (permalink / raw) To: Lee Revell; +Cc: Robert Hancock, linux-kernel, Jeff Garzik, nigel Lee Revell wrote: > Servers are still the most important Linux market, To whom? -- Stefan Richter -=====-=-=== --=- -=-=- http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 1:50 ` NAK new drivers without proper power management? Robert Hancock 2007-02-10 1:59 ` Lee Revell @ 2007-02-10 2:05 ` Nigel Cunningham 2007-02-10 3:27 ` Dmitry Torokhov 2007-02-10 3:02 ` [PATCH] " Nigel Cunningham 2 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 2:05 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel, Jeff Garzik Hi. On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > Jeff Garzik wrote: > > Nigel Cunningham wrote: > >> Hi. > >> > >> On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > >>> On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > >>>> Hi. > >>>> > >>>> I don't think this is already done (feel free to correct me if I'm > >>>> wrong).. > >>>> > >>>> Can we start to NAK new drivers that don't have proper power management > >>>> implemented? There really is no excuse for writing a new driver and not > >>>> putting .suspend and .resume methods in anymore, is there? > >>> > >>> to a large degree, a device driver that doesn't suspend is better than > >>> no device driver at all, right? > >> > >> I'm not sure it is. It only makes more work for everyone else: We have > >> to help people figure out what causes their computer to fail to resume > >> (which can take quite a while), then get them them complain to driver > >> author, and the driver author has to submit patches to fix it. > >> > >> All of this is avoided if they'll just do it right in the first place. > > > > A lot of a lot of things could have been avoided, if they just did it > > right the first time. > > > > I think it's more valuable to users to get a basic network driver that > > pings or a basic ATA driver that reads/writes, than peripheral issues > > like suspend/resume. > > > > Certainly we should ask for it, but it shouldn't be a merge-stopper. > > > > Jeff > > I would disagree that it's a peripheral issue, it's pretty core these > days, at least for any hardware that you can stuff in a laptop (though a > fair number of desktops get suspended and resumed these days too). One > driver on a system which doesn't suspend or resume properly can ruin the > entire process, causing a ton of user frustration. Certainly I would > consider a driver without suspend/resume support to be incomplete. > > The trouble with deferring adding this support is that it's a lot harder > to add this support in after the fact than if it was considered during > the original driver development. > > I would be in favor of not merging drivers lacking suspend unless > there's a very good reason they're lacking it. > > It also kind of bothers me that if a driver has no suspend/resume > functions, and you suspend and resume the system, we don't complain > about it even though there's a very good chance that device is not going > to function properly. How about something in dmesg like: > > Warning: driver for device XXXX has no suspend or resume support. > Device may not function properly after resume. > > so that users know who to complain to. Maybe there are some devices that > truly don't need any handling for suspend, but if so I suspect the > number of those is small enough that adding empty functions would be a > good-enough solution. I've already made a start on doing just that. Rafael was clearly right in asserting that some drivers would need to have warnings suppressed, but that can be dealt with (see below). Even if no-one wants it for vanilla, I think I'll put this in Suspend2. It will at least help my users with debugging issues. Regards, Nigel [ 14.936667] Device driver platform lacks bus and class support for being suspended or resumed. [ 14.937612] Device driver vtcon0 lacks bus and class support for being suspended or resumed. [ 14.955258] Device driver pci0000:00 lacks bus and class support for being suspended or resumed. [ 15.004268] Device driver pnp0 lacks bus and class support for being suspended or resumed. [ 15.010618] Device driver mem lacks bus and class support for being suspended or resumed. [ 15.010779] Device driver kmem lacks bus and class support for being suspended or resumed. [ 15.010932] Device driver null lacks bus and class support for being suspended or resumed. [ 15.011090] Device driver port lacks bus and class support for being suspended or resumed. [ 15.011248] Device driver zero lacks bus and class support for being suspended or resumed. [ 15.011414] Device driver full lacks bus and class support for being suspended or resumed. [ 15.011566] Device driver random lacks bus and class support for being suspended or resumed. [ 15.011723] Device driver urandom lacks bus and class support for being suspended or resumed. [ 15.011875] Device driver kmsg lacks bus and class support for being suspended or resumed. [ 15.305495] Device driver mcelog lacks bus and class support for being suspended or resumed. [ 15.305688] Device driver msr0 lacks bus and class support for being suspended or resumed. [ 15.306571] Device driver snapshot lacks bus and class support for being suspended or resumed. [ 15.359006] Device driver fb0 lacks bus and class support for being suspended or resumed. [ 15.359471] Device driver vtcon1 lacks bus and class support for being suspended or resumed. [ 15.455642] Device driver tty lacks bus and class support for being suspended or resumed. [ 15.455815] Device driver console lacks bus and class support for being suspended or resumed. [ 15.455991] Device driver ptmx lacks bus and class support for being suspended or resumed. [ 15.456157] Device driver tty0 lacks bus and class support for being suspended or resumed. [ 15.456336] Device driver vcs lacks bus and class support for being suspended or resumed. [ 15.456495] Device driver vcsa lacks bus and class support for being suspended or resumed. [ 15.456668] Device driver tty1 lacks bus and class support for being suspended or resumed. [ 15.456860] Device driver tty2 lacks bus and class support for being suspended or resumed. [ 15.457057] Device driver tty3 lacks bus and class support for being suspended or resumed. [ 15.457256] Device driver tty4 lacks bus and class support for being suspended or resumed. [ 15.457447] Device driver tty5 lacks bus and class support for being suspended or resumed. [ 15.457642] Device driver tty6 lacks bus and class support for being suspended or resumed. [ 15.457833] Device driver tty7 lacks bus and class support for being suspended or resumed. [ 15.458024] Device driver tty8 lacks bus and class support for being suspended or resumed. [ 15.458219] Device driver tty9 lacks bus and class support for being suspended or resumed. [ 15.458419] Device driver tty10 lacks bus and class support for being suspended or resumed. [ 15.458615] Device driver tty11 lacks bus and class support for being suspended or resumed. [ 15.458808] Device driver tty12 lacks bus and class support for being suspended or resumed. ... [ 15.469106] Device driver rtc lacks bus and class support for being suspended or resumed. [ 15.469283] Device driver hpet lacks bus and class support for being suspended or resumed. [ 15.469585] Device driver ttyS0 lacks bus and class support for being suspended or resumed. [ 15.469777] Device driver ttyS1 lacks bus and class support for being suspended or resumed. [ 15.469972] Device driver ttyS2 lacks bus and class support for being suspended or resumed. [ 15.470173] Device driver ttyS3 lacks bus and class support for being suspended or resumed. [ 15.470808] Device driver ttyS0 lacks bus and class support for being suspended or resumed. [ 15.471159] Device driver ttyS0 lacks bus and class support for being suspended or resumed. [ 15.471501] Device driver ttyS0 lacks bus and class support for being suspended or resumed. [ 15.471844] Device driver ttyS0 lacks bus and class support for being suspended or resumed. [ 15.472213] Device driver ttyS0 lacks bus and class support for being suspended or resumed. [ 15.472583] Device driver ttyS1 lacks bus and class support for being suspended or resumed. [ 15.472916] Device driver ttyS2 lacks bus and class support for being suspended or resumed. [ 15.473271] Device driver ttyS2 lacks bus and class support for being suspended or resumed. [ 15.473641] Device driver ttyS2 lacks bus and class support for being suspended or resumed. [ 15.474009] Device driver ttyS3 lacks bus and class support for being suspended or resumed. [ 15.775682] Device driver ide0 lacks bus and class support for being suspended or resumed. [ 17.632766] Device driver ide1 lacks bus and class support for being suspended or resumed. [ 17.633462] PCI driver ALI15x3_IDE lacks driver specific suspend and resume support. [ 17.633465] PCI driver ALI15x3_IDE lacks a driver specific resume method. [ 17.633547] PCI driver PIIX_IDE lacks driver specific suspend and resume support. [ 17.633549] PCI driver PIIX_IDE lacks a driver specific resume method. [ 17.684475] Device driver serio0 lacks bus and class support for being resumed. [ 17.684724] Device driver serio1 lacks bus and class support for being resumed. [ 17.684874] Device driver psaux lacks bus and class support for being suspended or resumed. [ 17.685015] Device driver serio2 lacks bus and class support for being resumed. [ 18.373576] Device driver serio3 lacks bus and class support for being resumed. [ 18.375666] Device driver serio4 lacks bus and class support for being resumed. ... [ 22.656888] Device driver timer lacks bus and class support for being suspended or resumed. [ 23.314970] Device driver pcmC0D2p lacks bus and class support for being suspended or resumed. [ 23.315327] Device driver pcmC0D1c lacks bus and class support for being suspended or resumed. [ 23.315648] Device driver adsp lacks bus and class support for being suspended or resumed. [ 23.316036] Device driver pcmC0D0p lacks bus and class support for being suspended or resumed. [ 23.316352] Device driver pcmC0D0c lacks bus and class support for being suspended or resumed. [ 23.316672] Device driver dsp lacks bus and class support for being suspended or resumed. [ 23.317053] Device driver audio lacks bus and class support for being suspended or resumed. [ 23.317530] Device driver controlC0 lacks bus and class support for being suspended or resumed. [ 23.317875] Device driver mixer lacks bus and class support for being suspended or resumed. [ 28.806277] Device driver vcs1 lacks bus and class support for being suspended or resumed. [ 28.806479] Device driver vcsa1 lacks bus and class support for being suspended or resumed. [ 71.656860] Device driver vcs1 lacks bus and class support for being suspended or resumed. [ 71.657062] Device driver vcsa1 lacks bus and class support for being suspended or resumed. [ 71.657563] Device driver vcs1 lacks bus and class support for being suspended or resumed. [ 71.657758] Device driver vcsa1 lacks bus and class support for being suspended or resumed. [ 71.658342] Device driver vcs1 lacks bus and class support for being suspended or resumed. [ 71.658530] Device driver vcsa1 lacks bus and class support for being suspended or resumed. [ 71.674825] Device driver vcs1 lacks bus and class support for being suspended or resumed. [ 71.675010] Device driver vcsa1 lacks bus and class support for being suspended or resumed. [ 75.573394] PCI driver ali15x3_smbus lacks driver specific suspend and resume support. [ 75.573396] PCI driver ali15x3_smbus lacks a driver specific resume method. [ 75.844125] Device driver usbdev1.1_ep00 lacks bus and class support for being suspended or resumed. [ 75.951810] Device driver usbdev1.1_ep81 lacks bus and class support for being suspended or resumed. [ 76.013809] Device driver usbdev2.1_ep00 lacks bus and class support for being suspended or resumed. [ 76.121522] Device driver usbdev2.1_ep81 lacks bus and class support for being suspended or resumed. [ 76.122026] PCI driver ali1535_smbus lacks driver specific suspend and resume support. [ 76.122028] PCI driver ali1535_smbus lacks a driver specific resume method. [ 76.151696] Device driver usbdev3.1_ep00 lacks bus and class support for being suspended or resumed. [ 76.301270] Device driver usbdev3.1_ep81 lacks bus and class support for being suspended or resumed. [ 86.348191] Device driver vcs7 lacks bus and class support for being suspended or resumed. [ 86.348373] Device driver vcsa7 lacks bus and class support for being suspended or resumed. [ 113.547039] Device driver vmmon lacks bus and class support for being suspended or resumed. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 2:05 ` Nigel Cunningham @ 2007-02-10 3:27 ` Dmitry Torokhov 2007-02-10 4:18 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Dmitry Torokhov @ 2007-02-10 3:27 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, linux-kernel, Jeff Garzik Hi Nigel, On Friday 09 February 2007 21:05, Nigel Cunningham wrote: > [ 17.684475] Device driver serio0 lacks bus and class support for being resumed. > [ 17.684724] Device driver serio1 lacks bus and class support for being resumed. > [ 17.684874] Device driver psaux lacks bus and class support for being suspended or resumed. > [ 17.685015] Device driver serio2 lacks bus and class support for being resumed. > [ 18.373576] Device driver serio3 lacks bus and class support for being resumed. > [ 18.375666] Device driver serio4 lacks bus and class support for being resumed. > You should probably only warn if driver does not have resume method - not having suspend is quite valid if driver is able to restore state at resume without explicitely saving anything at suspend time. -- Dmitry ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 3:27 ` Dmitry Torokhov @ 2007-02-10 4:18 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 4:18 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Robert Hancock, linux-kernel, Jeff Garzik Hi Dmitry! On Fri, 2007-02-09 at 22:27 -0500, Dmitry Torokhov wrote: > Hi Nigel, > > On Friday 09 February 2007 21:05, Nigel Cunningham wrote: > > [ 17.684475] Device driver serio0 lacks bus and class support for being resumed. > > [ 17.684724] Device driver serio1 lacks bus and class support for being resumed. > > [ 17.684874] Device driver psaux lacks bus and class support for being suspended or resumed. > > [ 17.685015] Device driver serio2 lacks bus and class support for being resumed. > > [ 18.373576] Device driver serio3 lacks bus and class support for being resumed. > > [ 18.375666] Device driver serio4 lacks bus and class support for being resumed. > > > > You should probably only warn if driver does not have resume method - not > having suspend is quite valid if driver is able to restore state at resume > without explicitely saving anything at suspend time. Can do. Will do :) Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 1:50 ` NAK new drivers without proper power management? Robert Hancock 2007-02-10 1:59 ` Lee Revell 2007-02-10 2:05 ` Nigel Cunningham @ 2007-02-10 3:02 ` Nigel Cunningham 2007-02-10 9:34 ` Rafael J. Wysocki 2 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 3:02 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel, Jeff Garzik Hi. On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > It also kind of bothers me that if a driver has no suspend/resume > functions, and you suspend and resume the system, we don't complain > about it even though there's a very good chance that device is not going > to function properly. How about something in dmesg like: > > Warning: driver for device XXXX has no suspend or resume support. > Device may not function properly after resume. > > so that users know who to complain to. Maybe there are some devices that > truly don't need any handling for suspend, but if so I suspect the > number of those is small enough that adding empty functions would be a > good-enough solution. Here's my current version of a patch to do this, if anyone wants to try it out. It dumps stack with the warning to make it easier to see what the source of the message is: drivers/base/core.c | 25 +++++++++++++++++++++++++ drivers/pci/pci-driver.c | 6 ++++++ drivers/usb/core/driver.c | 5 +++++ include/linux/device.h | 1 + 4 files changed, 37 insertions(+) diff -ruNp 920-report-no-pm-support.patch-old/drivers/base/core.c 920-report-no-pm-support.patch-new/drivers/base/core.c --- 920-report-no-pm-support.patch-old/drivers/base/core.c 2007-02-06 14:48:31.000000000 +1100 +++ 920-report-no-pm-support.patch-new/drivers/base/core.c 2007-02-10 13:36:33.000000000 +1100 @@ -552,6 +552,30 @@ int device_add(struct device *dev) class_intf->add_dev(dev, class_intf); up(&dev->class->sem); } + +#ifdef CONFIG_PM + { + int nosusp = 0, nores = 0; + + if (!((dev->class && dev->class->suspend) || + (dev->bus && (dev->bus->suspend || dev->bus->suspend_late)))) + nosusp = 1; + + if (!((dev->class && dev->class->resume) || + (dev->bus && (dev->bus->resume || dev->bus->resume_early)))) + nores = 1; + + if ((nosusp || nores) && !dev->pm_safe) { + printk("Device driver %s lacks bus and class support for " + "being %s.\n", + kobject_name(&dev->kobj), + nosusp ? (nores ? "suspended or resumed" : + "resumed") : "suspended"); + dump_stack(); + } + } +#endif + Done: kfree(class_name); put_device(dev); @@ -851,6 +875,7 @@ struct device *device_create(struct clas dev->class = class; dev->parent = parent; dev->release = device_create_release; + dev->pm_safe = 1; va_start(args, fmt); vsnprintf(dev->bus_id, BUS_ID_SIZE, fmt, args); diff -ruNp 920-report-no-pm-support.patch-old/drivers/pci/pci-driver.c 920-report-no-pm-support.patch-new/drivers/pci/pci-driver.c --- 920-report-no-pm-support.patch-old/drivers/pci/pci-driver.c 2007-02-06 14:48:44.000000000 +1100 +++ 920-report-no-pm-support.patch-new/drivers/pci/pci-driver.c 2007-02-10 14:00:39.000000000 +1100 @@ -449,6 +449,12 @@ int __pci_register_driver(struct pci_dri if (error) driver_unregister(&drv->driver); + if (!drv->suspend || !drv->resume) + printk("PCI driver %s lacks driver specific %s support.\n", + drv->name, + !drv->suspend ? (drv->resume ? "suspend" : + "suspend and resume") : "resume"); + return error; } diff -ruNp 920-report-no-pm-support.patch-old/drivers/usb/core/driver.c 920-report-no-pm-support.patch-new/drivers/usb/core/driver.c --- 920-report-no-pm-support.patch-old/drivers/usb/core/driver.c 2007-02-06 14:48:47.000000000 +1100 +++ 920-report-no-pm-support.patch-new/drivers/usb/core/driver.c 2007-02-10 12:32:57.000000000 +1100 @@ -709,6 +709,11 @@ int usb_register_device_driver(struct us pr_info("%s: registered new device driver %s\n", usbcore_name, new_udriver->name); usbfs_update_special(); + if (!new_udriver->suspend || !new_udriver->resume) + printk("USB driver %s lacks %s support.\n", + new_udriver->name, !new_udriver->suspend ? + (new_udriver->resume ? "suspend" : + "suspend and resume") : "resume"); } else { printk(KERN_ERR "%s: error %d registering device " " driver %s\n", diff -ruNp 920-report-no-pm-support.patch-old/include/linux/device.h 920-report-no-pm-support.patch-new/include/linux/device.h --- 920-report-no-pm-support.patch-old/include/linux/device.h 2007-02-06 14:48:56.000000000 +1100 +++ 920-report-no-pm-support.patch-new/include/linux/device.h 2007-02-10 13:36:01.000000000 +1100 @@ -356,6 +356,7 @@ struct device { struct kobject kobj; char bus_id[BUS_ID_SIZE]; /* position on parent bus */ unsigned is_registered:1; + unsigned pm_safe:1; /* No suspend/resume fns ok? */ struct device_attribute uevent_attr; struct device_attribute *devt_attr; My output: nigel@nigel:~$ dmesg | grep lacks [ 15.113674] Device driver platform lacks bus and class support for being suspended or resumed. [ 15.131601] Device driver pci0000:00 lacks bus and class support for being suspended or resumed. [ 15.179802] Device driver pnp0 lacks bus and class support for being suspended or resumed. [ 15.972661] Device driver ide0 lacks bus and class support for being suspended or resumed. [ 17.829746] Device driver ide1 lacks bus and class support for being suspended or resumed. [ 17.830878] PCI driver ALI15x3_IDE lacks driver specific suspend and resume support. [ 17.830963] PCI driver PIIX_IDE lacks driver specific suspend and resume support. [ 17.878190] Device driver serio0 lacks bus and class support for being resumed. [ 17.878442] Device driver serio1 lacks bus and class support for being resumed. [ 17.878672] Device driver serio2 lacks bus and class support for being resumed. [ 18.555856] Device driver serio3 lacks bus and class support for being resumed. [ 18.558109] Device driver serio4 lacks bus and class support for being resumed. [ 78.487717] Device driver usbdev1.1_ep00 lacks bus and class support for being suspended or resumed. [ 78.595362] Device driver usbdev1.1_ep81 lacks bus and class support for being suspended or resumed. [ 78.657382] Device driver usbdev2.1_ep00 lacks bus and class support for being suspended or resumed. [ 78.765044] Device driver usbdev2.1_ep81 lacks bus and class support for being suspended or resumed. [ 78.795324] Device driver usbdev3.1_ep00 lacks bus and class support for being suspended or resumed. [ 78.904912] Device driver usbdev3.1_ep81 lacks bus and class support for being suspended or resumed. [ 78.936997] PCI driver ali15x3_smbus lacks driver specific suspend and resume support. [ 78.996318] PCI driver ali1535_smbus lacks driver specific suspend and resume support. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 3:02 ` [PATCH] " Nigel Cunningham @ 2007-02-10 9:34 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 9:34 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list Hi, On Saturday, 10 February 2007 04:02, Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > > It also kind of bothers me that if a driver has no suspend/resume > > functions, and you suspend and resume the system, we don't complain > > about it even though there's a very good chance that device is not going > > to function properly. How about something in dmesg like: > > > > Warning: driver for device XXXX has no suspend or resume support. > > Device may not function properly after resume. > > > > so that users know who to complain to. Maybe there are some devices that > > truly don't need any handling for suspend, but if so I suspect the > > number of those is small enough that adding empty functions would be a > > good-enough solution. > > Here's my current version of a patch to do this, if anyone wants to try > it out. It dumps stack with the warning to make it easier to see what > the source of the message is: I have an alternative idea. There is a test mode of swsusp that's triggered with "echo test > /sys/power/disk" and "echo disk > /sys/power/state". We can make it set a switch that will be used to trigger the warnings in the core. This way the warnings will only appear in the user's dmesg in the test mode and not always. Would that be acceptable? Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-10 9:34 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 9:34 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, Pavel Machek, pm list, linux-kernel, Jeff Garzik Hi, On Saturday, 10 February 2007 04:02, Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > > It also kind of bothers me that if a driver has no suspend/resume > > functions, and you suspend and resume the system, we don't complain > > about it even though there's a very good chance that device is not going > > to function properly. How about something in dmesg like: > > > > Warning: driver for device XXXX has no suspend or resume support. > > Device may not function properly after resume. > > > > so that users know who to complain to. Maybe there are some devices that > > truly don't need any handling for suspend, but if so I suspect the > > number of those is small enough that adding empty functions would be a > > good-enough solution. > > Here's my current version of a patch to do this, if anyone wants to try > it out. It dumps stack with the warning to make it easier to see what > the source of the message is: I have an alternative idea. There is a test mode of swsusp that's triggered with "echo test > /sys/power/disk" and "echo disk > /sys/power/state". We can make it set a switch that will be used to trigger the warnings in the core. This way the warnings will only appear in the user's dmesg in the test mode and not always. Would that be acceptable? Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 9:34 ` Rafael J. Wysocki (?) @ 2007-02-10 10:02 ` Nigel Cunningham 2007-02-10 10:30 ` Rafael J. Wysocki -1 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 10:02 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list Gidday. On Sat, 2007-02-10 at 10:34 +0100, Rafael J. Wysocki wrote: > On Saturday, 10 February 2007 04:02, Nigel Cunningham wrote: > > On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > > > It also kind of bothers me that if a driver has no suspend/resume > > > functions, and you suspend and resume the system, we don't complain > > > about it even though there's a very good chance that device is not going > > > to function properly. How about something in dmesg like: > > > > > > Warning: driver for device XXXX has no suspend or resume support. > > > Device may not function properly after resume. > > > > > > so that users know who to complain to. Maybe there are some devices that > > > truly don't need any handling for suspend, but if so I suspect the > > > number of those is small enough that adding empty functions would be a > > > good-enough solution. > > > > Here's my current version of a patch to do this, if anyone wants to try > > it out. It dumps stack with the warning to make it easier to see what > > the source of the message is: > > I have an alternative idea. > > There is a test mode of swsusp that's triggered with > "echo test > /sys/power/disk" and "echo disk > /sys/power/state". We can make > it set a switch that will be used to trigger the warnings in the core. > > This way the warnings will only appear in the user's dmesg in the test mode > and not always. > > Would that be acceptable? Well, the original desire was to stop new drivers getting in without proper power management. For this to help achieve that aim, one or more of the following would need to happen: * developers of new drivers would have to remember to run the test after/during writing their driver. Of course if they remember to do this, they've already remembered that they need to implement power management; * you, I or someone else would need to test all these trees before Andrew and Linus merge them and report problems to the developers before they get their new drivers merged; * Andrew or Linus would run it prior to or after merging a whole lot of stuff. I'm afraid I don't like the chances of any of those things happening, so I'm not sure that it is an acceptable alternative from my perspective. Sticking a printk in dmesg doesn't exactly put the problem in flashing red 36 point characters before the developer either, but I think they're slightly more likely to see it there if only because they might stick printks in that they want to read (eg perhaps while debugging the driver) and therefore see the message when checking output from the driver being loaded/initialised. Maybe another alternative would be to make the warnings compile time warnings - if that's possible? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 10:02 ` Nigel Cunningham @ 2007-02-10 10:30 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 10:30 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list Hi, On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > Gidday. > > On Sat, 2007-02-10 at 10:34 +0100, Rafael J. Wysocki wrote: > > On Saturday, 10 February 2007 04:02, Nigel Cunningham wrote: > > > On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > > > > It also kind of bothers me that if a driver has no suspend/resume > > > > functions, and you suspend and resume the system, we don't complain > > > > about it even though there's a very good chance that device is not going > > > > to function properly. How about something in dmesg like: > > > > > > > > Warning: driver for device XXXX has no suspend or resume support. > > > > Device may not function properly after resume. > > > > > > > > so that users know who to complain to. Maybe there are some devices that > > > > truly don't need any handling for suspend, but if so I suspect the > > > > number of those is small enough that adding empty functions would be a > > > > good-enough solution. > > > > > > Here's my current version of a patch to do this, if anyone wants to try > > > it out. It dumps stack with the warning to make it easier to see what > > > the source of the message is: > > > > I have an alternative idea. > > > > There is a test mode of swsusp that's triggered with > > "echo test > /sys/power/disk" and "echo disk > /sys/power/state". We can make > > it set a switch that will be used to trigger the warnings in the core. > > > > This way the warnings will only appear in the user's dmesg in the test mode > > and not always. > > > > Would that be acceptable? > > Well, the original desire was to stop new drivers getting in without > proper power management. I know, but I agree with the argument that having a driver without the suspend/resume support is better than not having the driver at all. Moreover, if you _know_ which of the drivers you use have no suspend/resume support, usually you _can_ suspend (at least to disk) and resume anyway - you only need to unload their modules before the suspend. Of course, this is not true for the disk (and related) drivers and for the drivers that cannot be unloaded. [I think it generally is not true for the suspend-to-RAM either.] Also, I think there are quite some drivers already in the tree that don't support suspend/resume explicitly and honestly we should start from adding the suspend/resume routines to these drivers _before_ we ban new drivers like that. > For this to help achieve that aim, one or more > of the following would need to happen: > > * developers of new drivers would have to remember to run the test > after/during writing their driver. Of course if they remember to do > this, they've already remembered that they need to implement power > management; > * you, I or someone else would need to test all these trees before > Andrew and Linus merge them and report problems to the developers before > they get their new drivers merged; > * Andrew or Linus would run it prior to or after merging a whole lot of > stuff. > > I'm afraid I don't like the chances of any of those things happening, so > I'm not sure that it is an acceptable alternative from my perspective. > > Sticking a printk in dmesg doesn't exactly put the problem in flashing > red 36 point characters before the developer either, but I think they're > slightly more likely to see it there if only because they might stick > printks in that they want to read (eg perhaps while debugging the > driver) and therefore see the message when checking output from the > driver being loaded/initialised. > > Maybe another alternative would be to make the warnings compile time > warnings - if that's possible? Well, maybe. Still, I'd like to create standard debugging procedures for suspend/resume, so that if someone reports a problem, we can tell him exactly what to do next. >From this point of view, the idea of having warnings related to the lack of .suspend or .resume routines in drivers that will appear in the user's dmesg in the test mode seems to be a good one. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-10 10:30 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 10:30 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, Pavel Machek, pm list, linux-kernel, Jeff Garzik Hi, On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > Gidday. > > On Sat, 2007-02-10 at 10:34 +0100, Rafael J. Wysocki wrote: > > On Saturday, 10 February 2007 04:02, Nigel Cunningham wrote: > > > On Fri, 2007-02-09 at 19:50 -0600, Robert Hancock wrote: > > > > It also kind of bothers me that if a driver has no suspend/resume > > > > functions, and you suspend and resume the system, we don't complain > > > > about it even though there's a very good chance that device is not going > > > > to function properly. How about something in dmesg like: > > > > > > > > Warning: driver for device XXXX has no suspend or resume support. > > > > Device may not function properly after resume. > > > > > > > > so that users know who to complain to. Maybe there are some devices that > > > > truly don't need any handling for suspend, but if so I suspect the > > > > number of those is small enough that adding empty functions would be a > > > > good-enough solution. > > > > > > Here's my current version of a patch to do this, if anyone wants to try > > > it out. It dumps stack with the warning to make it easier to see what > > > the source of the message is: > > > > I have an alternative idea. > > > > There is a test mode of swsusp that's triggered with > > "echo test > /sys/power/disk" and "echo disk > /sys/power/state". We can make > > it set a switch that will be used to trigger the warnings in the core. > > > > This way the warnings will only appear in the user's dmesg in the test mode > > and not always. > > > > Would that be acceptable? > > Well, the original desire was to stop new drivers getting in without > proper power management. I know, but I agree with the argument that having a driver without the suspend/resume support is better than not having the driver at all. Moreover, if you _know_ which of the drivers you use have no suspend/resume support, usually you _can_ suspend (at least to disk) and resume anyway - you only need to unload their modules before the suspend. Of course, this is not true for the disk (and related) drivers and for the drivers that cannot be unloaded. [I think it generally is not true for the suspend-to-RAM either.] Also, I think there are quite some drivers already in the tree that don't support suspend/resume explicitly and honestly we should start from adding the suspend/resume routines to these drivers _before_ we ban new drivers like that. > For this to help achieve that aim, one or more > of the following would need to happen: > > * developers of new drivers would have to remember to run the test > after/during writing their driver. Of course if they remember to do > this, they've already remembered that they need to implement power > management; > * you, I or someone else would need to test all these trees before > Andrew and Linus merge them and report problems to the developers before > they get their new drivers merged; > * Andrew or Linus would run it prior to or after merging a whole lot of > stuff. > > I'm afraid I don't like the chances of any of those things happening, so > I'm not sure that it is an acceptable alternative from my perspective. > > Sticking a printk in dmesg doesn't exactly put the problem in flashing > red 36 point characters before the developer either, but I think they're > slightly more likely to see it there if only because they might stick > printks in that they want to read (eg perhaps while debugging the > driver) and therefore see the message when checking output from the > driver being loaded/initialised. > > Maybe another alternative would be to make the warnings compile time > warnings - if that's possible? Well, maybe. Still, I'd like to create standard debugging procedures for suspend/resume, so that if someone reports a problem, we can tell him exactly what to do next. >From this point of view, the idea of having warnings related to the lack of .suspend or .resume routines in drivers that will appear in the user's dmesg in the test mode seems to be a good one. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 10:30 ` Rafael J. Wysocki @ 2007-02-10 17:52 ` Daniel Barkalow -1 siblings, 0 replies; 155+ messages in thread From: Daniel Barkalow @ 2007-02-10 17:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > Well, the original desire was to stop new drivers getting in without > > proper power management. > > I know, but I agree with the argument that having a driver without the > suspend/resume support is better than not having the driver at all. How about if "proper power management" is defined to include the driver explicitly preventing suspend? It seems to me like the current problem is that driver writers don't think about power management at all, and the result is that, after suspend/resume, the system doesn't come back. It would be better if driver writers had to think about power management just enough to realize that it's not going to work, and make this information available to the system. At that point, it's relatively easy for the system to do something useful about it. > Also, I think there are quite some drivers already in the tree that don't > support suspend/resume explicitly and honestly we should start from adding the > suspend/resume routines to these drivers _before_ we ban new drivers like that. It'd be relatively quick to modify all the current drivers that don't explicitly support suspend/resume to explicitly not support it. (Or to explicitly support it trivially; /dev/null obviously doesn't need anything.) -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-10 17:52 ` Daniel Barkalow 0 siblings, 0 replies; 155+ messages in thread From: Daniel Barkalow @ 2007-02-10 17:52 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, Jeff Garzik, Pavel Machek, pm list, linux-kernel On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > Well, the original desire was to stop new drivers getting in without > > proper power management. > > I know, but I agree with the argument that having a driver without the > suspend/resume support is better than not having the driver at all. How about if "proper power management" is defined to include the driver explicitly preventing suspend? It seems to me like the current problem is that driver writers don't think about power management at all, and the result is that, after suspend/resume, the system doesn't come back. It would be better if driver writers had to think about power management just enough to realize that it's not going to work, and make this information available to the system. At that point, it's relatively easy for the system to do something useful about it. > Also, I think there are quite some drivers already in the tree that don't > support suspend/resume explicitly and honestly we should start from adding the > suspend/resume routines to these drivers _before_ we ban new drivers like that. It'd be relatively quick to modify all the current drivers that don't explicitly support suspend/resume to explicitly not support it. (Or to explicitly support it trivially; /dev/null obviously doesn't need anything.) -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 17:52 ` Daniel Barkalow @ 2007-02-10 19:50 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 19:50 UTC (permalink / raw) To: Daniel Barkalow Cc: nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Saturday, 10 February 2007 18:52, Daniel Barkalow wrote: > On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > > > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > > > Well, the original desire was to stop new drivers getting in without > > > proper power management. > > > > I know, but I agree with the argument that having a driver without the > > suspend/resume support is better than not having the driver at all. > > How about if "proper power management" is defined to include the driver > explicitly preventing suspend? It seems to me like the current problem is > that driver writers don't think about power management at all, and the > result is that, after suspend/resume, the system doesn't come back. It > would be better if driver writers had to think about power management just > enough to realize that it's not going to work, and make this information > available to the system. At that point, it's relatively easy for the > system to do something useful about it. Actually, it is easy for the driver authors to do this right now. They can just make the .suspend() routine always return an error. Well, I think this is a good idea: if the device in question requires specific power management during the suspend/resume, but it is not implemented by the driver, we should require the author of the driver to define the .suspend() routine that returns -ENOSYS (preferably, with an explanatory warning in dmesg). Thoughts? > > Also, I think there are quite some drivers already in the tree that don't > > support suspend/resume explicitly and honestly we should start from adding the > > suspend/resume routines to these drivers _before_ we ban new drivers like that. > > It'd be relatively quick to modify all the current drivers that don't > explicitly support suspend/resume to explicitly not support it. (Or to > explicitly support it trivially; /dev/null obviously doesn't need > anything.) The problem is we have to review quite a lot of drivers for this purpose. Still it looks like we should do this anyway. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-10 19:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 19:50 UTC (permalink / raw) To: Daniel Barkalow Cc: Robert Hancock, Jeff Garzik, Pavel Machek, pm list, linux-kernel On Saturday, 10 February 2007 18:52, Daniel Barkalow wrote: > On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > > > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > > > Well, the original desire was to stop new drivers getting in without > > > proper power management. > > > > I know, but I agree with the argument that having a driver without the > > suspend/resume support is better than not having the driver at all. > > How about if "proper power management" is defined to include the driver > explicitly preventing suspend? It seems to me like the current problem is > that driver writers don't think about power management at all, and the > result is that, after suspend/resume, the system doesn't come back. It > would be better if driver writers had to think about power management just > enough to realize that it's not going to work, and make this information > available to the system. At that point, it's relatively easy for the > system to do something useful about it. Actually, it is easy for the driver authors to do this right now. They can just make the .suspend() routine always return an error. Well, I think this is a good idea: if the device in question requires specific power management during the suspend/resume, but it is not implemented by the driver, we should require the author of the driver to define the .suspend() routine that returns -ENOSYS (preferably, with an explanatory warning in dmesg). Thoughts? > > Also, I think there are quite some drivers already in the tree that don't > > support suspend/resume explicitly and honestly we should start from adding the > > suspend/resume routines to these drivers _before_ we ban new drivers like that. > > It'd be relatively quick to modify all the current drivers that don't > explicitly support suspend/resume to explicitly not support it. (Or to > explicitly support it trivially; /dev/null obviously doesn't need > anything.) The problem is we have to review quite a lot of drivers for this purpose. Still it looks like we should do this anyway. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 19:50 ` Rafael J. Wysocki @ 2007-02-11 6:54 ` Willy Tarreau -1 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 6:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sat, Feb 10, 2007 at 08:50:27PM +0100, Rafael J. Wysocki wrote: > On Saturday, 10 February 2007 18:52, Daniel Barkalow wrote: > > On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > > > > > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > > > > > Well, the original desire was to stop new drivers getting in without > > > > proper power management. > > > > > > I know, but I agree with the argument that having a driver without the > > > suspend/resume support is better than not having the driver at all. > > > > How about if "proper power management" is defined to include the driver > > explicitly preventing suspend? It seems to me like the current problem is > > that driver writers don't think about power management at all, and the > > result is that, after suspend/resume, the system doesn't come back. It > > would be better if driver writers had to think about power management just > > enough to realize that it's not going to work, and make this information > > available to the system. At that point, it's relatively easy for the > > system to do something useful about it. > > Actually, it is easy for the driver authors to do this right now. They can > just make the .suspend() routine always return an error. > > Well, I think this is a good idea: if the device in question requires specific > power management during the suspend/resume, but it is not implemented by the > driver, we should require the author of the driver to define the .suspend() > routine that returns -ENOSYS (preferably, with an explanatory warning in > dmesg). instead of modifying all drivers to explicitly state that they don't support it, we should start with a test of the NULL pointer for .suspend which should mean exactly the same without modifying the drivers. I find it obvious that a driver which does provide a suspend function will not support it. And if some drivers (eg /dev/null) can support it anyway, it's better to change *those* drivers to explicitly mark them as compatible. regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 6:54 ` Willy Tarreau 0 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 6:54 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, Jeff Garzik, Pavel Machek, Daniel Barkalow, pm list, linux-kernel On Sat, Feb 10, 2007 at 08:50:27PM +0100, Rafael J. Wysocki wrote: > On Saturday, 10 February 2007 18:52, Daniel Barkalow wrote: > > On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > > > > > On Saturday, 10 February 2007 11:02, Nigel Cunningham wrote: > > > > > > > Well, the original desire was to stop new drivers getting in without > > > > proper power management. > > > > > > I know, but I agree with the argument that having a driver without the > > > suspend/resume support is better than not having the driver at all. > > > > How about if "proper power management" is defined to include the driver > > explicitly preventing suspend? It seems to me like the current problem is > > that driver writers don't think about power management at all, and the > > result is that, after suspend/resume, the system doesn't come back. It > > would be better if driver writers had to think about power management just > > enough to realize that it's not going to work, and make this information > > available to the system. At that point, it's relatively easy for the > > system to do something useful about it. > > Actually, it is easy for the driver authors to do this right now. They can > just make the .suspend() routine always return an error. > > Well, I think this is a good idea: if the device in question requires specific > power management during the suspend/resume, but it is not implemented by the > driver, we should require the author of the driver to define the .suspend() > routine that returns -ENOSYS (preferably, with an explanatory warning in > dmesg). instead of modifying all drivers to explicitly state that they don't support it, we should start with a test of the NULL pointer for .suspend which should mean exactly the same without modifying the drivers. I find it obvious that a driver which does provide a suspend function will not support it. And if some drivers (eg /dev/null) can support it anyway, it's better to change *those* drivers to explicitly mark them as compatible. regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 6:54 ` Willy Tarreau (?) @ 2007-02-11 12:13 ` Matthew Garrett 2007-02-11 13:09 ` Willy Tarreau ` (2 more replies) -1 siblings, 3 replies; 155+ messages in thread From: Matthew Garrett @ 2007-02-11 12:13 UTC (permalink / raw) To: Willy Tarreau Cc: Rafael J. Wysocki, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sun, Feb 11, 2007 at 07:54:04AM +0100, Willy Tarreau wrote: > instead of modifying all drivers to explicitly state that they don't support > it, we should start with a test of the NULL pointer for .suspend which should > mean exactly the same without modifying the drivers. I find it obvious that > a driver which does provide a suspend function will not support it. And if > some drivers (eg /dev/null) can support it anyway, it's better to change > *those* drivers to explicitly mark them as compatible. No, that doesn't work. In the absence of suspend/resume methods, the PCI layer will implement basic PM itself. In some cases, this works. In others, it doesn't. There's no way to automatically determine which is which without modifying the drivers. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 12:13 ` Matthew Garrett @ 2007-02-11 13:09 ` Willy Tarreau 2007-02-11 17:36 ` Robert Hancock 2007-02-11 22:49 ` Nigel Cunningham 2 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 13:09 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sun, Feb 11, 2007 at 12:13:40PM +0000, Matthew Garrett wrote: > On Sun, Feb 11, 2007 at 07:54:04AM +0100, Willy Tarreau wrote: > > > instead of modifying all drivers to explicitly state that they don't support > > it, we should start with a test of the NULL pointer for .suspend which should > > mean exactly the same without modifying the drivers. I find it obvious that > > a driver which does provide a suspend function will not support it. And if > > some drivers (eg /dev/null) can support it anyway, it's better to change > > *those* drivers to explicitly mark them as compatible. > > No, that doesn't work. In the absence of suspend/resume methods, the PCI > layer will implement basic PM itself. In some cases, this works. In > others, it doesn't. There's no way to automatically determine which is > which without modifying the drivers. Then change the PCI layer to do the basic PM only for known compatible drivers, and modify only the known-compatible drivers to mark them explicitly compatible. IMHO, it generally is a bad idea to require that any driver explicitly states what it *does not* support. It's the reason why users encounter problem on new features with old drivers. For instance, do you know if the old ISA NE2000 driver breaks suspend ? I don't know, but I would at least expect it not to support it by default. It's best to announce what *is* supported and consider everything unimplemented otherwise explicitly stated. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 13:09 ` Willy Tarreau 0 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 13:09 UTC (permalink / raw) To: Matthew Garrett Cc: Robert Hancock, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, linux-kernel On Sun, Feb 11, 2007 at 12:13:40PM +0000, Matthew Garrett wrote: > On Sun, Feb 11, 2007 at 07:54:04AM +0100, Willy Tarreau wrote: > > > instead of modifying all drivers to explicitly state that they don't support > > it, we should start with a test of the NULL pointer for .suspend which should > > mean exactly the same without modifying the drivers. I find it obvious that > > a driver which does provide a suspend function will not support it. And if > > some drivers (eg /dev/null) can support it anyway, it's better to change > > *those* drivers to explicitly mark them as compatible. > > No, that doesn't work. In the absence of suspend/resume methods, the PCI > layer will implement basic PM itself. In some cases, this works. In > others, it doesn't. There's no way to automatically determine which is > which without modifying the drivers. Then change the PCI layer to do the basic PM only for known compatible drivers, and modify only the known-compatible drivers to mark them explicitly compatible. IMHO, it generally is a bad idea to require that any driver explicitly states what it *does not* support. It's the reason why users encounter problem on new features with old drivers. For instance, do you know if the old ISA NE2000 driver breaks suspend ? I don't know, but I would at least expect it not to support it by default. It's best to announce what *is* supported and consider everything unimplemented otherwise explicitly stated. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 13:09 ` Willy Tarreau (?) @ 2007-02-11 13:19 ` Matthew Garrett 2007-02-11 13:37 ` Willy Tarreau -1 siblings, 1 reply; 155+ messages in thread From: Matthew Garrett @ 2007-02-11 13:19 UTC (permalink / raw) To: Willy Tarreau Cc: Rafael J. Wysocki, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > Then change the PCI layer to do the basic PM only for known compatible > drivers, and modify only the known-compatible drivers to mark them > explicitly compatible. IMHO, it generally is a bad idea to require that > any driver explicitly states what it *does not* support. It's the reason > why users encounter problem on new features with old drivers. For instance, > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > but I would at least expect it not to support it by default. It's best > to announce what *is* supported and consider everything unimplemented > otherwise explicitly stated. This ignores the reality of the situation, which is that many drivers support suspend and resume despite the lack of any explicit implementation. Changing things so they're flagged as broken when they're not would be a regression. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 13:19 ` Matthew Garrett @ 2007-02-11 13:37 ` Willy Tarreau 0 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 13:37 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > Then change the PCI layer to do the basic PM only for known compatible > > drivers, and modify only the known-compatible drivers to mark them > > explicitly compatible. IMHO, it generally is a bad idea to require that > > any driver explicitly states what it *does not* support. It's the reason > > why users encounter problem on new features with old drivers. For instance, > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > but I would at least expect it not to support it by default. It's best > > to announce what *is* supported and consider everything unimplemented > > otherwise explicitly stated. > > This ignores the reality of the situation, which is that many drivers > support suspend and resume despite the lack of any explicit > implementation. Changing things so they're flagged as broken when > they're not would be a regression. Those which are identified as OK should be flagged OK. Only those for which we have no idea should be flagged broken. It's better than leaving them in the wild waiting for a victim. And given what Nigel would like, they would all have to be reviewed to get .suspend/.resume entries anyway. But at least, we would only have to change the known good instead of all of them. And the remaining ones would not cause trouble to users. Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 13:37 ` Willy Tarreau 0 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 13:37 UTC (permalink / raw) To: Matthew Garrett Cc: Robert Hancock, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, linux-kernel On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > Then change the PCI layer to do the basic PM only for known compatible > > drivers, and modify only the known-compatible drivers to mark them > > explicitly compatible. IMHO, it generally is a bad idea to require that > > any driver explicitly states what it *does not* support. It's the reason > > why users encounter problem on new features with old drivers. For instance, > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > but I would at least expect it not to support it by default. It's best > > to announce what *is* supported and consider everything unimplemented > > otherwise explicitly stated. > > This ignores the reality of the situation, which is that many drivers > support suspend and resume despite the lack of any explicit > implementation. Changing things so they're flagged as broken when > they're not would be a regression. Those which are identified as OK should be flagged OK. Only those for which we have no idea should be flagged broken. It's better than leaving them in the wild waiting for a victim. And given what Nigel would like, they would all have to be reviewed to get .suspend/.resume entries anyway. But at least, we would only have to change the known good instead of all of them. And the remaining ones would not cause trouble to users. Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 13:37 ` Willy Tarreau @ 2007-02-11 13:50 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 13:50 UTC (permalink / raw) To: Willy Tarreau Cc: Matthew Garrett, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sunday, 11 February 2007 14:37, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > > > Then change the PCI layer to do the basic PM only for known compatible > > > drivers, and modify only the known-compatible drivers to mark them > > > explicitly compatible. IMHO, it generally is a bad idea to require that > > > any driver explicitly states what it *does not* support. It's the reason > > > why users encounter problem on new features with old drivers. For instance, > > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > > but I would at least expect it not to support it by default. It's best > > > to announce what *is* supported and consider everything unimplemented > > > otherwise explicitly stated. > > > > This ignores the reality of the situation, which is that many drivers > > support suspend and resume despite the lack of any explicit > > implementation. Changing things so they're flagged as broken when > > they're not would be a regression. > > Those which are identified as OK should be flagged OK. Only those for > which we have no idea should be flagged broken. I think we don't need to flag the drivers identified as OK. Let's flag only the suspicious ones. Whatever we finally come up with, I'd like to avoid modifying drivers that are known good. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 13:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 13:50 UTC (permalink / raw) To: Willy Tarreau Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, linux-kernel On Sunday, 11 February 2007 14:37, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > > > Then change the PCI layer to do the basic PM only for known compatible > > > drivers, and modify only the known-compatible drivers to mark them > > > explicitly compatible. IMHO, it generally is a bad idea to require that > > > any driver explicitly states what it *does not* support. It's the reason > > > why users encounter problem on new features with old drivers. For instance, > > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > > but I would at least expect it not to support it by default. It's best > > > to announce what *is* supported and consider everything unimplemented > > > otherwise explicitly stated. > > > > This ignores the reality of the situation, which is that many drivers > > support suspend and resume despite the lack of any explicit > > implementation. Changing things so they're flagged as broken when > > they're not would be a regression. > > Those which are identified as OK should be flagged OK. Only those for > which we have no idea should be flagged broken. I think we don't need to flag the drivers identified as OK. Let's flag only the suspicious ones. Whatever we finally come up with, I'd like to avoid modifying drivers that are known good. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 13:50 ` Rafael J. Wysocki @ 2007-02-11 13:57 ` Willy Tarreau -1 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 13:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sun, Feb 11, 2007 at 02:50:48PM +0100, Rafael J. Wysocki wrote: > On Sunday, 11 February 2007 14:37, Willy Tarreau wrote: > > On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > > > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > > > > > Then change the PCI layer to do the basic PM only for known compatible > > > > drivers, and modify only the known-compatible drivers to mark them > > > > explicitly compatible. IMHO, it generally is a bad idea to require that > > > > any driver explicitly states what it *does not* support. It's the reason > > > > why users encounter problem on new features with old drivers. For instance, > > > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > > > but I would at least expect it not to support it by default. It's best > > > > to announce what *is* supported and consider everything unimplemented > > > > otherwise explicitly stated. > > > > > > This ignores the reality of the situation, which is that many drivers > > > support suspend and resume despite the lack of any explicit > > > implementation. Changing things so they're flagged as broken when > > > they're not would be a regression. > > > > Those which are identified as OK should be flagged OK. Only those for > > which we have no idea should be flagged broken. > > I think we don't need to flag the drivers identified as OK. Let's flag only > the suspicious ones. > > Whatever we finally come up with, I'd like to avoid modifying drivers that are > known good. I understand your concerns, but the problem is not *current* drivers, but what will happen to *new* drivers. If we make it implicit that a driver is compatible, then new drivers will be promoted as good even if nothing has been done for this. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 13:57 ` Willy Tarreau 0 siblings, 0 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 13:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, linux-kernel On Sun, Feb 11, 2007 at 02:50:48PM +0100, Rafael J. Wysocki wrote: > On Sunday, 11 February 2007 14:37, Willy Tarreau wrote: > > On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > > > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > > > > > Then change the PCI layer to do the basic PM only for known compatible > > > > drivers, and modify only the known-compatible drivers to mark them > > > > explicitly compatible. IMHO, it generally is a bad idea to require that > > > > any driver explicitly states what it *does not* support. It's the reason > > > > why users encounter problem on new features with old drivers. For instance, > > > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > > > but I would at least expect it not to support it by default. It's best > > > > to announce what *is* supported and consider everything unimplemented > > > > otherwise explicitly stated. > > > > > > This ignores the reality of the situation, which is that many drivers > > > support suspend and resume despite the lack of any explicit > > > implementation. Changing things so they're flagged as broken when > > > they're not would be a regression. > > > > Those which are identified as OK should be flagged OK. Only those for > > which we have no idea should be flagged broken. > > I think we don't need to flag the drivers identified as OK. Let's flag only > the suspicious ones. > > Whatever we finally come up with, I'd like to avoid modifying drivers that are > known good. I understand your concerns, but the problem is not *current* drivers, but what will happen to *new* drivers. If we make it implicit that a driver is compatible, then new drivers will be promoted as good even if nothing has been done for this. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 13:57 ` Willy Tarreau @ 2007-02-11 14:36 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 14:36 UTC (permalink / raw) To: Willy Tarreau Cc: Matthew Garrett, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sunday, 11 February 2007 14:57, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 02:50:48PM +0100, Rafael J. Wysocki wrote: > > On Sunday, 11 February 2007 14:37, Willy Tarreau wrote: > > > On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > > > > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > > > > > > > Then change the PCI layer to do the basic PM only for known compatible > > > > > drivers, and modify only the known-compatible drivers to mark them > > > > > explicitly compatible. IMHO, it generally is a bad idea to require that > > > > > any driver explicitly states what it *does not* support. It's the reason > > > > > why users encounter problem on new features with old drivers. For instance, > > > > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > > > > but I would at least expect it not to support it by default. It's best > > > > > to announce what *is* supported and consider everything unimplemented > > > > > otherwise explicitly stated. > > > > > > > > This ignores the reality of the situation, which is that many drivers > > > > support suspend and resume despite the lack of any explicit > > > > implementation. Changing things so they're flagged as broken when > > > > they're not would be a regression. > > > > > > Those which are identified as OK should be flagged OK. Only those for > > > which we have no idea should be flagged broken. > > > > I think we don't need to flag the drivers identified as OK. Let's flag only > > the suspicious ones. > > > > Whatever we finally come up with, I'd like to avoid modifying drivers that are > > known good. > > I understand your concerns, but the problem is not *current* drivers, but > what will happen to *new* drivers. If we make it implicit that a driver > is compatible, then new drivers will be promoted as good even if nothing > has been done for this. The problem is it was made implicit long ago. The design is "optimistic", so to speak, and I think we have the following choices: 1) Change the design to make the kernel refuse to suspend if there are any drivers not explicitly flagged as "suspend/resume-safe". [This looks like a lot of work to me, but it is generally doable provided that someone has enough time to do it. Unfortunately it has to be done in one shot for all of the known good drivers to avoid user-observable regressions.] 2) Require the authors of new drivers to _either_ ensure that their drivers will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly flag the drivers as "suspend/resume-unsafe", for example by impelenting .suspend() routines returning -ENOSYS. [The existing drivers can be modified to follow this convention gradually.] Now IMO 1) has some disadvantages: - Potential for introducing some regressions (eg. if we omit a known-good driver) - Necessity to review a lot of drivers simultaneously - Problem what to do with drivers that work for some people and don't work for the others (ie. if we don't flag them as known good, we will break the setups in which they work) The advantage of 1), however, is that we can differentiate drivers that are safe only with respect to the suspend to disk from those that are safe with respect to the suspend to RAM too (there are some). I'd prefer 2), because it's simpler to make happen. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 14:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 14:36 UTC (permalink / raw) To: Willy Tarreau Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, linux-kernel On Sunday, 11 February 2007 14:57, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 02:50:48PM +0100, Rafael J. Wysocki wrote: > > On Sunday, 11 February 2007 14:37, Willy Tarreau wrote: > > > On Sun, Feb 11, 2007 at 01:19:57PM +0000, Matthew Garrett wrote: > > > > On Sun, Feb 11, 2007 at 02:09:43PM +0100, Willy Tarreau wrote: > > > > > > > > > Then change the PCI layer to do the basic PM only for known compatible > > > > > drivers, and modify only the known-compatible drivers to mark them > > > > > explicitly compatible. IMHO, it generally is a bad idea to require that > > > > > any driver explicitly states what it *does not* support. It's the reason > > > > > why users encounter problem on new features with old drivers. For instance, > > > > > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > > > > > but I would at least expect it not to support it by default. It's best > > > > > to announce what *is* supported and consider everything unimplemented > > > > > otherwise explicitly stated. > > > > > > > > This ignores the reality of the situation, which is that many drivers > > > > support suspend and resume despite the lack of any explicit > > > > implementation. Changing things so they're flagged as broken when > > > > they're not would be a regression. > > > > > > Those which are identified as OK should be flagged OK. Only those for > > > which we have no idea should be flagged broken. > > > > I think we don't need to flag the drivers identified as OK. Let's flag only > > the suspicious ones. > > > > Whatever we finally come up with, I'd like to avoid modifying drivers that are > > known good. > > I understand your concerns, but the problem is not *current* drivers, but > what will happen to *new* drivers. If we make it implicit that a driver > is compatible, then new drivers will be promoted as good even if nothing > has been done for this. The problem is it was made implicit long ago. The design is "optimistic", so to speak, and I think we have the following choices: 1) Change the design to make the kernel refuse to suspend if there are any drivers not explicitly flagged as "suspend/resume-safe". [This looks like a lot of work to me, but it is generally doable provided that someone has enough time to do it. Unfortunately it has to be done in one shot for all of the known good drivers to avoid user-observable regressions.] 2) Require the authors of new drivers to _either_ ensure that their drivers will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly flag the drivers as "suspend/resume-unsafe", for example by impelenting .suspend() routines returning -ENOSYS. [The existing drivers can be modified to follow this convention gradually.] Now IMO 1) has some disadvantages: - Potential for introducing some regressions (eg. if we omit a known-good driver) - Necessity to review a lot of drivers simultaneously - Problem what to do with drivers that work for some people and don't work for the others (ie. if we don't flag them as known good, we will break the setups in which they work) The advantage of 1), however, is that we can differentiate drivers that are safe only with respect to the suspend to disk from those that are safe with respect to the suspend to RAM too (there are some). I'd prefer 2), because it's simpler to make happen. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 14:36 ` Rafael J. Wysocki @ 2007-02-11 15:19 ` Pekka Enberg -1 siblings, 0 replies; 155+ messages in thread From: Pekka Enberg @ 2007-02-11 15:19 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Willy Tarreau, Matthew Garrett, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On 2/11/07, Rafael J. Wysocki <rjw@sisk.pl> wrote: > Unfortunately it has to be done in one shot for all of the known good drivers to avoid > user-observable regressions. No you don't. You can make it a config option that defaults to n during a transition period. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 15:19 ` Pekka Enberg 0 siblings, 0 replies; 155+ messages in thread From: Pekka Enberg @ 2007-02-11 15:19 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, Willy Tarreau, linux-kernel On 2/11/07, Rafael J. Wysocki <rjw@sisk.pl> wrote: > Unfortunately it has to be done in one shot for all of the known good drivers to avoid > user-observable regressions. No you don't. You can make it a config option that defaults to n during a transition period. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 15:19 ` Pekka Enberg @ 2007-02-11 18:31 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 18:31 UTC (permalink / raw) To: Pekka Enberg Cc: Willy Tarreau, Matthew Garrett, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sunday, 11 February 2007 16:19, Pekka Enberg wrote: > On 2/11/07, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > Unfortunately it has to be done in one shot for all of the known good drivers to avoid > > user-observable regressions. > > No you don't. You can make it a config option that defaults to n > during a transition period. Yes, that's possible. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 18:31 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 18:31 UTC (permalink / raw) To: Pekka Enberg Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, Willy Tarreau, linux-kernel On Sunday, 11 February 2007 16:19, Pekka Enberg wrote: > On 2/11/07, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > Unfortunately it has to be done in one shot for all of the known good drivers to avoid > > user-observable regressions. > > No you don't. You can make it a config option that defaults to n > during a transition period. Yes, that's possible. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 14:36 ` Rafael J. Wysocki (?) (?) @ 2007-02-11 17:27 ` Daniel Barkalow 2007-02-11 18:53 ` Rafael J. Wysocki -1 siblings, 1 reply; 155+ messages in thread From: Daniel Barkalow @ 2007-02-11 17:27 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Willy Tarreau, Matthew Garrett, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sun, 11 Feb 2007, Rafael J. Wysocki wrote: > The problem is it was made implicit long ago. The design is "optimistic", so > to speak, and I think we have the following choices: > > 1) Change the design to make the kernel refuse to suspend if there are any > drivers not explicitly flagged as "suspend/resume-safe". [This looks like a > lot of work to me, but it is generally doable provided that someone has enough > time to do it. Unfortunately it has to be done in one shot for all of the > known good drivers to avoid user-observable regressions.] The kernel wouldn't necessarily have to refuse to suspend. It could just warn (and list the drivers that aren't marked), or could require some extra insistance from the user. It would be good to have it log a message saying something like: "If you can read this, report that ne2000 seems to be safe for suspend/resume". Having drivers explicitly marked as to whether they are safe is a good kernel feature; what to do if they're not is policy. > 2) Require the authors of new drivers to _either_ ensure that their drivers > will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly > flag the drivers as "suspend/resume-unsafe", for example by impelenting > .suspend() routines returning -ENOSYS. [The existing drivers can be modified > to follow this convention gradually.] I don't see any reason not to do (2) regardless of (1). That was (my idea of) the statement that started this thread: new drivers need to not mess up on suspend/resume, as a matter of suitability for inclusion. Of course, we need some way for drivers to indicate that they work fine with the PCI-layer defaults. And it should probably more machine-readable than the author telling reviewers that it works. > - Problem what to do with drivers that work for some people and don't work > for the others (ie. if we don't flag them as known good, we will break the > setups in which they work) I think the only interesting case here is when a device resumes fine with no driver support if the BIOS manages to deal effectively with it, but the BIOS generally doesn't. Otherwise, I think it's only going to work at all if the author put in the effort to make it work (so it should be "known good"), but there may be bugs (firmware, BIOS, driver, etc). But that's true of any functionality. -Daniel *This .sig left intentionally blank* ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 17:27 ` Daniel Barkalow @ 2007-02-11 18:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 18:53 UTC (permalink / raw) To: Daniel Barkalow Cc: Willy Tarreau, Matthew Garrett, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Sunday, 11 February 2007 18:27, Daniel Barkalow wrote: > On Sun, 11 Feb 2007, Rafael J. Wysocki wrote: > > > The problem is it was made implicit long ago. The design is "optimistic", so > > to speak, and I think we have the following choices: > > > > 1) Change the design to make the kernel refuse to suspend if there are any > > drivers not explicitly flagged as "suspend/resume-safe". [This looks like a > > lot of work to me, but it is generally doable provided that someone has enough > > time to do it. Unfortunately it has to be done in one shot for all of the > > known good drivers to avoid user-observable regressions.] > > The kernel wouldn't necessarily have to refuse to suspend. Well, not from the start, but I think at some point in the fufure it would. > It could just warn (and list the drivers that aren't marked), or could > require some extra insistance from the user. We would have to change the interface for that and I don't want to do it. > It would be good to have it log a message saying something like: "If you can > read this, report that ne2000 seems to be safe for suspend/resume". Sure, it would. > Having drivers explicitly marked as to whether they are safe is a good kernel > feature; what to do if they're not is policy. That's true, but I assume that the people who opt for doing that are also willing to take part in the review of the drivers. :-) > > 2) Require the authors of new drivers to _either_ ensure that their drivers > > will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly > > flag the drivers as "suspend/resume-unsafe", for example by impelenting > > .suspend() routines returning -ENOSYS. [The existing drivers can be modified > > to follow this convention gradually.] > > I don't see any reason not to do (2) regardless of (1). That was (my idea > of) the statement that started this thread: new drivers need to not mess > up on suspend/resume, as a matter of suitability for inclusion. Of course, > we need some way for drivers to indicate that they work fine with the > PCI-layer defaults. And it should probably more machine-readable than the > author telling reviewers that it works. Well, if we change the design to fail by default, the authors of new drivers will only have to flag them if they believe that the drivers are suspend/resume-safe. > > - Problem what to do with drivers that work for some people and don't work > > for the others (ie. if we don't flag them as known good, we will break the > > setups in which they work) > > I think the only interesting case here is when a device resumes fine with > no driver support if the BIOS manages to deal effectively with it, but the > BIOS generally doesn't. Well, I don't think so. Let's estimate the number of drivers that define .resume() right now: $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc 102 102 4169 And I think there are much more drivers that really work fine with respect to the suspend/resume. This indicates that in fact many drivers can be marked as known good even though they don't define the .suspend() or .resume() routines. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 18:53 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 18:53 UTC (permalink / raw) To: Daniel Barkalow Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, pm list, Willy Tarreau, linux-kernel On Sunday, 11 February 2007 18:27, Daniel Barkalow wrote: > On Sun, 11 Feb 2007, Rafael J. Wysocki wrote: > > > The problem is it was made implicit long ago. The design is "optimistic", so > > to speak, and I think we have the following choices: > > > > 1) Change the design to make the kernel refuse to suspend if there are any > > drivers not explicitly flagged as "suspend/resume-safe". [This looks like a > > lot of work to me, but it is generally doable provided that someone has enough > > time to do it. Unfortunately it has to be done in one shot for all of the > > known good drivers to avoid user-observable regressions.] > > The kernel wouldn't necessarily have to refuse to suspend. Well, not from the start, but I think at some point in the fufure it would. > It could just warn (and list the drivers that aren't marked), or could > require some extra insistance from the user. We would have to change the interface for that and I don't want to do it. > It would be good to have it log a message saying something like: "If you can > read this, report that ne2000 seems to be safe for suspend/resume". Sure, it would. > Having drivers explicitly marked as to whether they are safe is a good kernel > feature; what to do if they're not is policy. That's true, but I assume that the people who opt for doing that are also willing to take part in the review of the drivers. :-) > > 2) Require the authors of new drivers to _either_ ensure that their drivers > > will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly > > flag the drivers as "suspend/resume-unsafe", for example by impelenting > > .suspend() routines returning -ENOSYS. [The existing drivers can be modified > > to follow this convention gradually.] > > I don't see any reason not to do (2) regardless of (1). That was (my idea > of) the statement that started this thread: new drivers need to not mess > up on suspend/resume, as a matter of suitability for inclusion. Of course, > we need some way for drivers to indicate that they work fine with the > PCI-layer defaults. And it should probably more machine-readable than the > author telling reviewers that it works. Well, if we change the design to fail by default, the authors of new drivers will only have to flag them if they believe that the drivers are suspend/resume-safe. > > - Problem what to do with drivers that work for some people and don't work > > for the others (ie. if we don't flag them as known good, we will break the > > setups in which they work) > > I think the only interesting case here is when a device resumes fine with > no driver support if the BIOS manages to deal effectively with it, but the > BIOS generally doesn't. Well, I don't think so. Let's estimate the number of drivers that define .resume() right now: $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc 102 102 4169 And I think there are much more drivers that really work fine with respect to the suspend/resume. This indicates that in fact many drivers can be marked as known good even though they don't define the .suspend() or .resume() routines. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 18:53 ` Rafael J. Wysocki @ 2007-02-11 23:06 ` Nigel Cunningham -1 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Daniel Barkalow, Willy Tarreau, Matthew Garrett, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list Hi. On Sun, 2007-02-11 at 19:53 +0100, Rafael J. Wysocki wrote: > > Having drivers explicitly marked as to whether they are safe is a good kernel > > feature; what to do if they're not is policy. > > That's true, but I assume that the people who opt for doing that are also > willing to take part in the review of the drivers. :-) Absolutely :) > Well, I don't think so. Let's estimate the number of drivers that define > .resume() right now: > > $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc > 102 102 4169 I think the '.resume =' doesn't help - some have tabs. I ran '\.resume' and got 351. It would be interesting to see how many struct pci_driver etc instances lack resume methods. Regards, Nige ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 23:06 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, Willy Tarreau, linux-kernel Hi. On Sun, 2007-02-11 at 19:53 +0100, Rafael J. Wysocki wrote: > > Having drivers explicitly marked as to whether they are safe is a good kernel > > feature; what to do if they're not is policy. > > That's true, but I assume that the people who opt for doing that are also > willing to take part in the review of the drivers. :-) Absolutely :) > Well, I don't think so. Let's estimate the number of drivers that define > .resume() right now: > > $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc > 102 102 4169 I think the '.resume =' doesn't help - some have tabs. I ran '\.resume' and got 351. It would be interesting to see how many struct pci_driver etc instances lack resume methods. Regards, Nige ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 23:06 ` Nigel Cunningham @ 2007-02-11 23:10 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:10 UTC (permalink / raw) To: nigel Cc: Daniel Barkalow, Willy Tarreau, Matthew Garrett, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list On Monday, 12 February 2007 00:06, Nigel Cunningham wrote: > Hi. > > On Sun, 2007-02-11 at 19:53 +0100, Rafael J. Wysocki wrote: > > > Having drivers explicitly marked as to whether they are safe is a good kernel > > > feature; what to do if they're not is policy. > > > > That's true, but I assume that the people who opt for doing that are also > > willing to take part in the review of the drivers. :-) > > Absolutely :) > > > Well, I don't think so. Let's estimate the number of drivers that define > > .resume() right now: > > > > $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc > > 102 102 4169 > > I think the '.resume =' doesn't help - some have tabs. I ran '\.resume' > and got 351. Ah, good catch. I have searched for ".resume" only and got 612, but this is the number of files, not the number of drivers. And it is not exactly large. ;-) > It would be interesting to see how many struct pci_driver etc instances > lack resume methods. Yes, I'll try to invent a test. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 23:10 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:10 UTC (permalink / raw) To: nigel Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, Willy Tarreau, linux-kernel On Monday, 12 February 2007 00:06, Nigel Cunningham wrote: > Hi. > > On Sun, 2007-02-11 at 19:53 +0100, Rafael J. Wysocki wrote: > > > Having drivers explicitly marked as to whether they are safe is a good kernel > > > feature; what to do if they're not is policy. > > > > That's true, but I assume that the people who opt for doing that are also > > willing to take part in the review of the drivers. :-) > > Absolutely :) > > > Well, I don't think so. Let's estimate the number of drivers that define > > .resume() right now: > > > > $ grep -I -l -r '.resume =' linux-2.6.20/drivers/ | wc > > 102 102 4169 > > I think the '.resume =' doesn't help - some have tabs. I ran '\.resume' > and got 351. Ah, good catch. I have searched for ".resume" only and got 612, but this is the number of files, not the number of drivers. And it is not exactly large. ;-) > It would be interesting to see how many struct pci_driver etc instances > lack resume methods. Yes, I'll try to invent a test. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 14:36 ` Rafael J. Wysocki @ 2007-02-11 21:04 ` Stefan Richter -1 siblings, 0 replies; 155+ messages in thread From: Stefan Richter @ 2007-02-11 21:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Willy Tarreau, Matthew Garrett, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list Rafael J. Wysocki wrote: > - Problem what to do with drivers that work for some people and don't work > for the others (ie. if we don't flag them as known good, we will break the > setups in which they work) And this issue is independent of whether a driver has .suspend and .resume or not. For example, ohci1394 had them for ages but they didn't work as expected before 2.6.20. What's more, ohci1394's resume routine alone is insufficient; an additional facility in ieee1394 was necessary and added for 2.6.21(-rc). This shows that the original authors of ohci1394's .suspend and .resume didn't test with actual external devices or gave up when they figured that the problem reaches into upper subsystem layers. (We still haven't tested interaction with most of the IEEE 1394 high level.) -- Stefan Richter -=====-=-=== --=- -=-== http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 21:04 ` Stefan Richter 0 siblings, 0 replies; 155+ messages in thread From: Stefan Richter @ 2007-02-11 21:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Robert Hancock, Matthew Garrett, Pavel Machek, Jeff Garzik, Daniel Barkalow, pm list, Willy Tarreau, linux-kernel Rafael J. Wysocki wrote: > - Problem what to do with drivers that work for some people and don't work > for the others (ie. if we don't flag them as known good, we will break the > setups in which they work) And this issue is independent of whether a driver has .suspend and .resume or not. For example, ohci1394 had them for ages but they didn't work as expected before 2.6.20. What's more, ohci1394's resume routine alone is insufficient; an additional facility in ieee1394 was necessary and added for 2.6.21(-rc). This shows that the original authors of ohci1394's .suspend and .resume didn't test with actual external devices or gave up when they figured that the problem reaches into upper subsystem layers. (We still haven't tested interaction with most of the IEEE 1394 high level.) -- Stefan Richter -=====-=-=== --=- -=-== http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 13:09 ` Willy Tarreau (?) (?) @ 2007-02-11 21:10 ` Pavel Machek -1 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 21:10 UTC (permalink / raw) To: Willy Tarreau Cc: Matthew Garrett, Rafael J. Wysocki, Daniel Barkalow, nigel, Robert Hancock, linux-kernel, Jeff Garzik, pm list Hi! > > > instead of modifying all drivers to explicitly state that they don't support > > > it, we should start with a test of the NULL pointer for .suspend which should > > > mean exactly the same without modifying the drivers. I find it obvious that > > > a driver which does provide a suspend function will not support it. And if > > > some drivers (eg /dev/null) can support it anyway, it's better to change > > > *those* drivers to explicitly mark them as compatible. > > > > No, that doesn't work. In the absence of suspend/resume methods, the PCI > > layer will implement basic PM itself. In some cases, this works. In > > others, it doesn't. There's no way to automatically determine which is > > which without modifying the drivers. > > Then change the PCI layer to do the basic PM only for known compatible > drivers, and modify only the known-compatible drivers to mark them > explicitly compatible. IMHO, it generally is a bad idea to require that > any driver explicitly states what it *does not* support. It's the reason > why users encounter problem on new features with old drivers. For instance, > do you know if the old ISA NE2000 driver breaks suspend ? I don't know, > but I would at least expect it not to support it by default. It's best > to announce what *is* supported and consider everything unimplemented > otherwise explicitly stated. Actually, ne2k driver is okay. ne2k cards are notoriously buggy, so it responds with "****, that damn card has just locked up again, lets reset it". Ok, it takes timeout to realize card is "locked up", so it could be improved... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 12:13 ` Matthew Garrett 2007-02-11 13:09 ` Willy Tarreau @ 2007-02-11 17:36 ` Robert Hancock 2007-02-11 22:49 ` Nigel Cunningham 2 siblings, 0 replies; 155+ messages in thread From: Robert Hancock @ 2007-02-11 17:36 UTC (permalink / raw) To: Matthew Garrett Cc: Willy Tarreau, Rafael J. Wysocki, Daniel Barkalow, nigel, linux-kernel, Jeff Garzik, Pavel Machek, pm list Matthew Garrett wrote: > On Sun, Feb 11, 2007 at 07:54:04AM +0100, Willy Tarreau wrote: > >> instead of modifying all drivers to explicitly state that they don't support >> it, we should start with a test of the NULL pointer for .suspend which should >> mean exactly the same without modifying the drivers. I find it obvious that >> a driver which does provide a suspend function will not support it. And if >> some drivers (eg /dev/null) can support it anyway, it's better to change >> *those* drivers to explicitly mark them as compatible. > > No, that doesn't work. In the absence of suspend/resume methods, the PCI > layer will implement basic PM itself. In some cases, this works. In > others, it doesn't. There's no way to automatically determine which is > which without modifying the drivers. > The only thing that the PCI layer does for PM is the stuff that the driver would normally tell the PCI layer to do as part of a proper suspend/resume implementation: enable/disable the device and save/restore the PCI configuration space (only the standardized part, I believe). This is the bare minimum that's needed on all PCI devices, whether or not they even have a driver loaded. I suspect the number of PCI devices where this is truly all they need, i.e. no state in any IO ports or MMIO registers that need to be reset on resume, is quite low. Maybe in some cases it may appear to work by luck, i.e. the registers happening to be set to the correct values (especially on suspend-to-disk) but this is not a proper implementation. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-11 12:13 ` Matthew Garrett 2007-02-11 13:09 ` Willy Tarreau 2007-02-11 17:36 ` Robert Hancock @ 2007-02-11 22:49 ` Nigel Cunningham 2 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 22:49 UTC (permalink / raw) To: Matthew Garrett Cc: Willy Tarreau, Rafael J. Wysocki, Daniel Barkalow, Robert Hancock, linux-kernel, Jeff Garzik, Pavel Machek, pm list Hi. On Sun, 2007-02-11 at 12:13 +0000, Matthew Garrett wrote: > On Sun, Feb 11, 2007 at 07:54:04AM +0100, Willy Tarreau wrote: > > > instead of modifying all drivers to explicitly state that they don't support > > it, we should start with a test of the NULL pointer for .suspend which should > > mean exactly the same without modifying the drivers. I find it obvious that > > a driver which does provide a suspend function will not support it. And if > > some drivers (eg /dev/null) can support it anyway, it's better to change > > *those* drivers to explicitly mark them as compatible. > > No, that doesn't work. In the absence of suspend/resume methods, the PCI > layer will implement basic PM itself. In some cases, this works. In > others, it doesn't. There's no way to automatically determine which is > which without modifying the drivers. I think we have it backwards there. Power management support for a driver should always start with the driver itself. If there's a generic routine that can be used for the bus, the driver should explicitly set the routine to the generic routine. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? 2007-02-10 17:52 ` Daniel Barkalow @ 2007-02-11 19:37 ` Pavel Machek -1 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 19:37 UTC (permalink / raw) To: Daniel Barkalow Cc: Rafael J. Wysocki, nigel, Robert Hancock, linux-kernel, Jeff Garzik, pm list Hi! > > Also, I think there are quite some drivers already in the tree that don't > > support suspend/resume explicitly and honestly we should start from adding the > > suspend/resume routines to these drivers _before_ we ban new drivers like that. > > It'd be relatively quick to modify all the current drivers that don't > explicitly support suspend/resume to explicitly not support it. (Or Well, I think that is more work than you realize, but yes, that patch would really be welcome. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: [PATCH] Re: NAK new drivers without proper power management? @ 2007-02-11 19:37 ` Pavel Machek 0 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 19:37 UTC (permalink / raw) To: Daniel Barkalow; +Cc: Robert Hancock, Jeff Garzik, pm list, linux-kernel Hi! > > Also, I think there are quite some drivers already in the tree that don't > > support suspend/resume explicitly and honestly we should start from adding the > > suspend/resume routines to these drivers _before_ we ban new drivers like that. > > It'd be relatively quick to modify all the current drivers that don't > explicitly support suspend/resume to explicitly not support it. (Or Well, I think that is more work than you realize, but yes, that patch would really be welcome. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
[parent not found: <fa.DhkemAgVI60diqZy0t9GzpwyLmk@ifi.uio.no>]
[parent not found: <fa.E/NjHlgg0HqDg5CgZjnCHFi2AMM@ifi.uio.no>]
[parent not found: <fa.kop49l/7yexJoUGrzk6vVeIP934@ifi.uio.no>]
* Re: NAK new drivers without proper power management? [not found] ` <fa.kop49l/7yexJoUGrzk6vVeIP934@ifi.uio.no> @ 2007-02-10 23:20 ` Robert Hancock 2007-02-11 0:44 ` Rafael J. Wysocki [not found] ` <fa.EgQN5JpU6xrZSLyOY0kWjJ26hUM@ifi.uio.no> [not found] ` <fa.O1YH4k5KtBGCNs5i2yB17bPvPGw@ifi.uio.no> 2 siblings, 1 reply; 155+ messages in thread From: Robert Hancock @ 2007-02-10 23:20 UTC (permalink / raw) To: nigel, linux-kernel; +Cc: Rafael J. Wysocki Nigel Cunningham wrote: > If your device requires power management, and you know it requires power > management, why not just implement power management? Doing -ENOSYS > instead is like saying -ESPAMMEBECAUSEIMLAZY. > > Let me put it another way: People keep talking about Linux being ready > for the desktop. To me at least (but I dare say for lots of other people > too), being ready for the desktop means that things just work, without > having to recompile kernels or bug driver authors or wait twelve > months. > > And it means that doing a bare minimum isn't enough. We keep claiming > that Open Source is better than Proprietary software. If we accept > half-pie jobs of implementing support for anything - driver power > management support or hibernation support or whatever - as 'good > enough', we're undercutting that argument. Linux's power management > support should - as far as we're able - be at least as good as that > other operating system's and preferably way, way better. > > -ENOSYS is just not acceptable. Well, it's probably more acceptable than silently doing nothing and the device failing or locking up the machine on resume, but I couldn't agree more that it's not what we want to be encouraging. Perfect may be the enemy of the good, but "works except no power management" is hardly what I would call good these days, more like pretty sloppy.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 23:20 ` Robert Hancock @ 2007-02-11 0:44 ` Rafael J. Wysocki 2007-02-11 17:01 ` Pavel Machek 2007-02-11 22:40 ` Nigel Cunningham 0 siblings, 2 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 0:44 UTC (permalink / raw) To: Robert Hancock; +Cc: nigel, linux-kernel, Pavel Machek On Sunday, 11 February 2007 00:20, Robert Hancock wrote: > Nigel Cunningham wrote: > > If your device requires power management, and you know it requires power > > management, why not just implement power management? Doing -ENOSYS > > instead is like saying -ESPAMMEBECAUSEIMLAZY. > > > > Let me put it another way: People keep talking about Linux being ready > > for the desktop. To me at least (but I dare say for lots of other people > > too), being ready for the desktop means that things just work, without > > having to recompile kernels or bug driver authors or wait twelve > > months. > > > > And it means that doing a bare minimum isn't enough. We keep claiming > > that Open Source is better than Proprietary software. If we accept > > half-pie jobs of implementing support for anything - driver power > > management support or hibernation support or whatever - as 'good > > enough', we're undercutting that argument. Linux's power management > > support should - as far as we're able - be at least as good as that > > other operating system's and preferably way, way better. > > > > -ENOSYS is just not acceptable. > > Well, it's probably more acceptable than silently doing nothing and the > device failing or locking up the machine on resume, but I couldn't agree > more that it's not what we want to be encouraging. Perfect may be the > enemy of the good, but "works except no power management" is hardly what > I would call good these days, more like pretty sloppy.. I think there are situations in which it can be justified, like: - The driver is not entirely finished, but we want to merge it early, because of many potential users, - The driver has only a few users who aren't interested in the suspend/resume functionality, - The device is undocumented and we don't know how to make it handle the suspend/resume (we may learn that in the future or not). For this reason I 100% agree that we should _encourage_ implementing .suspend and .resume, but we should not make it an unbreakable rule cast in stone. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 0:44 ` Rafael J. Wysocki @ 2007-02-11 17:01 ` Pavel Machek 2007-02-11 22:40 ` Nigel Cunningham 1 sibling, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 17:01 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Robert Hancock, nigel, linux-kernel Hi! > > > -ENOSYS is just not acceptable. > > > > Well, it's probably more acceptable than silently doing nothing and the > > device failing or locking up the machine on resume, but I couldn't agree > > more that it's not what we want to be encouraging. Perfect may be the > > enemy of the good, but "works except no power management" is hardly what > > I would call good these days, more like pretty sloppy.. > > I think there are situations in which it can be justified, like: > - The driver is not entirely finished, but we want to merge it early, because > of many potential users, > - The driver has only a few users who aren't interested in the suspend/resume > functionality, > - The device is undocumented and we don't know how to make it handle the > suspend/resume (we may learn that in the future or not). > > For this reason I 100% agree that we should _encourage_ implementing .suspend > and .resume, but we should not make it an unbreakable rule cast in stone. No rules are ever unbreakable, so that should be okay. 'Make it suspend, if you can't for some good reason, at least return -ENOSYS from .suspend' sounds good to me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 0:44 ` Rafael J. Wysocki 2007-02-11 17:01 ` Pavel Machek @ 2007-02-11 22:40 ` Nigel Cunningham 2007-02-11 23:29 ` Rafael J. Wysocki 1 sibling, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 22:40 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Robert Hancock, linux-kernel, Pavel Machek Hi. On Sun, 2007-02-11 at 01:44 +0100, Rafael J. Wysocki wrote: > > Well, it's probably more acceptable than silently doing nothing and the > > device failing or locking up the machine on resume, but I couldn't agree > > more that it's not what we want to be encouraging. Perfect may be the > > enemy of the good, but "works except no power management" is hardly what > > I would call good these days, more like pretty sloppy.. > > I think there are situations in which it can be justified, like: > - The driver is not entirely finished, but we want to merge it early, because > of many potential users, > - The driver has only a few users who aren't interested in the suspend/resume > functionality, How do you determine that? How many users have to want suspend/resume functionality before you say "Ok. It has to be done now"? > - The device is undocumented and we don't know how to make it handle the > suspend/resume (we may learn that in the future or not). If we know how to initialise/cleanup, we know a good portion of what is needed for suspend/resume. Sure, for some video chipsets, you need more (you need to know how to reprogram the whole thing after S3), but they're the exception. Yes, there are other cases. But on the whole, we're not talking about esoteric knowledge. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:40 ` Nigel Cunningham @ 2007-02-11 23:29 ` Rafael J. Wysocki 2007-02-11 23:40 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:29 UTC (permalink / raw) To: nigel; +Cc: Robert Hancock, linux-kernel, Pavel Machek On Sunday, 11 February 2007 23:40, Nigel Cunningham wrote: > Hi. > > On Sun, 2007-02-11 at 01:44 +0100, Rafael J. Wysocki wrote: > > > Well, it's probably more acceptable than silently doing nothing and the > > > device failing or locking up the machine on resume, but I couldn't agree > > > more that it's not what we want to be encouraging. Perfect may be the > > > enemy of the good, but "works except no power management" is hardly what > > > I would call good these days, more like pretty sloppy.. > > > > I think there are situations in which it can be justified, like: > > - The driver is not entirely finished, but we want to merge it early, because > > of many potential users, > > - The driver has only a few users who aren't interested in the suspend/resume > > functionality, > > How do you determine that? How many users have to want suspend/resume > functionality before you say "Ok. It has to be done now"? That depends on what the driver author tells us. If he says there's only one such device in the world and it needs a Linux drivers, but the system in question will never be suspended, that will be fine, I think. There are such cases already and I see no reason why there won't be any more in the future. > > - The device is undocumented and we don't know how to make it handle the > > suspend/resume (we may learn that in the future or not). > > If we know how to initialise/cleanup, we know a good portion of what is > needed for suspend/resume. Sure, for some video chipsets, you need more > (you need to know how to reprogram the whole thing after S3), but > they're the exception. Yes, there are other cases. But on the whole, > we're not talking about esoteric knowledge. No, in general this is not _that_ simple. Please browse the archives of bcm43xx-dev, for example. While I agree that the support for suspend and resume _is_ generally important, I also admit that there are situations in which it doesn't matter and there are many people who won't care a whit for it. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:29 ` Rafael J. Wysocki @ 2007-02-11 23:40 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:40 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Robert Hancock, linux-kernel, Pavel Machek Hi. On Mon, 2007-02-12 at 00:29 +0100, Rafael J. Wysocki wrote: > > On Sun, 2007-02-11 at 01:44 +0100, Rafael J. Wysocki wrote: > > > > Well, it's probably more acceptable than silently doing nothing and the > > > > device failing or locking up the machine on resume, but I couldn't agree > > > > more that it's not what we want to be encouraging. Perfect may be the > > > > enemy of the good, but "works except no power management" is hardly what > > > > I would call good these days, more like pretty sloppy.. > > > > > > I think there are situations in which it can be justified, like: > > > - The driver is not entirely finished, but we want to merge it early, because > > > of many potential users, > > > - The driver has only a few users who aren't interested in the suspend/resume > > > functionality, > > > > How do you determine that? How many users have to want suspend/resume > > functionality before you say "Ok. It has to be done now"? > > That depends on what the driver author tells us. If he says there's only one > such device in the world and it needs a Linux drivers, but the system in > question will never be suspended, that will be fine, I think. There are such > cases already and I see no reason why there won't be any more in the future. > > > > - The device is undocumented and we don't know how to make it handle the > > > suspend/resume (we may learn that in the future or not). > > > > If we know how to initialise/cleanup, we know a good portion of what is > > needed for suspend/resume. Sure, for some video chipsets, you need more > > (you need to know how to reprogram the whole thing after S3), but > > they're the exception. Yes, there are other cases. But on the whole, > > we're not talking about esoteric knowledge. > > No, in general this is not _that_ simple. Please browse the archives of > bcm43xx-dev, for example. Yeah. The problems of not having documentation + having to reassociate and so on. > While I agree that the support for suspend and resume _is_ generally important, > I also admit that there are situations in which it doesn't matter and there are > many people who won't care a whit for it. Ok, but that's the exception, right? Not the rule? So in those cases, an exception is made. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
[parent not found: <fa.EgQN5JpU6xrZSLyOY0kWjJ26hUM@ifi.uio.no>]
* Re: NAK new drivers without proper power management? [not found] ` <fa.EgQN5JpU6xrZSLyOY0kWjJ26hUM@ifi.uio.no> @ 2007-02-11 18:31 ` Robert Hancock 2007-02-11 21:52 ` Willy Tarreau 0 siblings, 1 reply; 155+ messages in thread From: Robert Hancock @ 2007-02-11 18:31 UTC (permalink / raw) To: Willy Tarreau, linux-kernel; +Cc: Nigel Cunningham Willy Tarreau wrote: > Nigel, don't take it as a personal offense, but I think it is a very > centric view of Linux usages. Where I work, Linux is used a lot on > servers and appliances. It is used for mail relays, HTTP proxies, > anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > etc... Nobody would ever want to enable power management on those > machines, let alone suspend which would cause a major havoc, would > the system decide to enter suspend for any reason. > > Many people also have Linux on their notebooks, but as a dual-boot. You > read the word ? "dual-boot". It means that they cleanly shutdown their > system every time they don't use it anymore, and they won't know what > OS they'll use next time. > > I've never heard anyone there complaining "oh, I'm fed up with this > boring boot, I always have to wait 30 seconds when I need to do > something, I wish I could suspend and resume". It is considered the > normal way of using their PCs. I think your experience is rather different than that of Joe Average User who doesn't frequent kernel lists, and also I think you'll find that for a lot of Linux laptop users that don't use supend, the reason is that it doesn't work reliably, quite often due to driver issues. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 18:31 ` Robert Hancock @ 2007-02-11 21:52 ` Willy Tarreau 2007-02-11 22:26 ` Nigel Cunningham 2007-02-12 12:19 ` Pavel Machek 0 siblings, 2 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 21:52 UTC (permalink / raw) To: Robert Hancock; +Cc: linux-kernel, Nigel Cunningham On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote: > Willy Tarreau wrote: > >Nigel, don't take it as a personal offense, but I think it is a very > >centric view of Linux usages. Where I work, Linux is used a lot on > >servers and appliances. It is used for mail relays, HTTP proxies, > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > >etc... Nobody would ever want to enable power management on those > >machines, let alone suspend which would cause a major havoc, would > >the system decide to enter suspend for any reason. > > > >Many people also have Linux on their notebooks, but as a dual-boot. You > >read the word ? "dual-boot". It means that they cleanly shutdown their > >system every time they don't use it anymore, and they won't know what > >OS they'll use next time. > > > >I've never heard anyone there complaining "oh, I'm fed up with this > >boring boot, I always have to wait 30 seconds when I need to do > >something, I wish I could suspend and resume". It is considered the > >normal way of using their PCs. > > I think your experience is rather different than that of Joe Average > User who doesn't frequent kernel lists, and also I think you'll find > that for a lot of Linux laptop users that don't use supend, the reason > is that it doesn't work reliably, quite often due to driver issues. I would believe it if I knew people using suspend/resume on the other OS. But that's not the case either. Also, it happens that with today's RAM sizes, suspend-to-disk then resume can be several times slower than a clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 seconds to shut down, and as much to restart. Compare this to 5-10 seconds for a shutdown and 30-50 seconds for a cold boot, and it might give you another clue why there are people not interested in such a feature. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 21:52 ` Willy Tarreau @ 2007-02-11 22:26 ` Nigel Cunningham 2007-02-11 22:46 ` Willy Tarreau 2007-02-11 23:41 ` Rafael J. Wysocki 2007-02-12 12:19 ` Pavel Machek 1 sibling, 2 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 22:26 UTC (permalink / raw) To: Willy Tarreau; +Cc: Robert Hancock, linux-kernel Hi. On Sun, 2007-02-11 at 22:52 +0100, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote: > > Willy Tarreau wrote: > > >Nigel, don't take it as a personal offense, but I think it is a very > > >centric view of Linux usages. Where I work, Linux is used a lot on > > >servers and appliances. It is used for mail relays, HTTP proxies, > > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > > >etc... Nobody would ever want to enable power management on those > > >machines, let alone suspend which would cause a major havoc, would > > >the system decide to enter suspend for any reason. > > > > > >Many people also have Linux on their notebooks, but as a dual-boot. You > > >read the word ? "dual-boot". It means that they cleanly shutdown their > > >system every time they don't use it anymore, and they won't know what > > >OS they'll use next time. > > > > > >I've never heard anyone there complaining "oh, I'm fed up with this > > >boring boot, I always have to wait 30 seconds when I need to do > > >something, I wish I could suspend and resume". It is considered the > > >normal way of using their PCs. > > > > I think your experience is rather different than that of Joe Average > > User who doesn't frequent kernel lists, and also I think you'll find > > that for a lot of Linux laptop users that don't use supend, the reason > > is that it doesn't work reliably, quite often due to driver issues. > > I would believe it if I knew people using suspend/resume on the other OS. > But that's not the case either. Also, it happens that with today's RAM > sizes, suspend-to-disk then resume can be several times slower than a > clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 > seconds to shut down, and as much to restart. Compare this to 5-10 > seconds for a shutdown and 30-50 seconds for a cold boot, and it might > give you another clue why there are people not interested in such a > feature. I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv card that Linux doesn't support well yet), and I know other Suspend2 users doing the same. It's made earier by the fact that Suspend2 lets you reboot instead of powering down. As to comparing the speed with the time to boot, your estimates are way out. Both will of course vary with the harddrive and cpu speeds and compression qualities of the image, but with Suspend2, I'm seeing speeds more in the range of 40-100MB/s, and even had a resport of 160MB/s a couple of days ago. The rule of thumb I use is: Run hdparm -t (or equiv) on the drive you'll be using: nigel@nigel:~$ sudo hdparm -t /dev/hda /dev/hda: Timing buffered disk reads: 120 MB in 3.02 seconds = 39.70 MB/sec Then calculate RAM_IN_MB / 2 / HDPARM_RESULT = seconds to read/write image. In my case: 1024 / 2 / 39.7 = approx 12 seconds. The / 2 is because with LZF compression, you normally get about 50% compression. I think the mean reason some people aren't interested in suspend to disk is because of myths (if you'll excuse the term) like the one you've put above. Of course that values you give were more accurate for swsusp and uswsusp until recently, but Suspend2 has had async I/O and compression for years, so all I can really do is encourage you to try again. Of course there's another factor you're not taking into account: With suspending to disk, you don't have to close and reopen documents or shut down and restart applications. The time to do that should be factored into the non-suspend-to-disk time to compare apples with apples. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:26 ` Nigel Cunningham @ 2007-02-11 22:46 ` Willy Tarreau 2007-02-11 23:18 ` Nigel Cunningham ` (2 more replies) 2007-02-11 23:41 ` Rafael J. Wysocki 1 sibling, 3 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 22:46 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Robert Hancock, linux-kernel On Mon, Feb 12, 2007 at 09:26:26AM +1100, Nigel Cunningham wrote: > Hi. > > On Sun, 2007-02-11 at 22:52 +0100, Willy Tarreau wrote: > > On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote: > > > Willy Tarreau wrote: > > > >Nigel, don't take it as a personal offense, but I think it is a very > > > >centric view of Linux usages. Where I work, Linux is used a lot on > > > >servers and appliances. It is used for mail relays, HTTP proxies, > > > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > > > >etc... Nobody would ever want to enable power management on those > > > >machines, let alone suspend which would cause a major havoc, would > > > >the system decide to enter suspend for any reason. > > > > > > > >Many people also have Linux on their notebooks, but as a dual-boot. You > > > >read the word ? "dual-boot". It means that they cleanly shutdown their > > > >system every time they don't use it anymore, and they won't know what > > > >OS they'll use next time. > > > > > > > >I've never heard anyone there complaining "oh, I'm fed up with this > > > >boring boot, I always have to wait 30 seconds when I need to do > > > >something, I wish I could suspend and resume". It is considered the > > > >normal way of using their PCs. > > > > > > I think your experience is rather different than that of Joe Average > > > User who doesn't frequent kernel lists, and also I think you'll find > > > that for a lot of Linux laptop users that don't use supend, the reason > > > is that it doesn't work reliably, quite often due to driver issues. > > > > I would believe it if I knew people using suspend/resume on the other OS. > > But that's not the case either. Also, it happens that with today's RAM > > sizes, suspend-to-disk then resume can be several times slower than a > > clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 > > seconds to shut down, and as much to restart. Compare this to 5-10 > > seconds for a shutdown and 30-50 seconds for a cold boot, and it might > > give you another clue why there are people not interested in such a > > feature. > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > card that Linux doesn't support well yet), and I know other Suspend2 > users doing the same. It's made earier by the fact that Suspend2 lets > you reboot instead of powering down. > > As to comparing the speed with the time to boot, your estimates are way > out. Both will of course vary with the harddrive and cpu speeds and > compression qualities of the image, but with Suspend2, I'm seeing speeds > more in the range of 40-100MB/s, and even had a resport of 160MB/s a > couple of days ago. The rule of thumb I use is: > > Run hdparm -t (or equiv) on the drive you'll be using: > > nigel@nigel:~$ sudo hdparm -t /dev/hda > > /dev/hda: > Timing buffered disk reads: 120 MB in 3.02 seconds = 39.70 MB/sec > > Then calculate RAM_IN_MB / 2 / HDPARM_RESULT = seconds to read/write > image. > > In my case: 1024 / 2 / 39.7 = approx 12 seconds. The / 2 is because with > LZF compression, you normally get about 50% compression. > > I think the mean reason some people aren't interested in suspend to disk > is because of myths (if you'll excuse the term) like the one you've put > above. Of course that values you give were more accurate for swsusp and > uswsusp until recently, but Suspend2 has had async I/O and compression > for years, so all I can really do is encourage you to try again. Well, I agree that you give some good arguments here. > Of course there's another factor you're not taking into account: With > suspending to disk, you don't have to close and reopen documents or shut > down and restart applications. The time to do that should be factored > into the non-suspend-to-disk time to compare apples with apples. Hmm sorry, but we don't have the same usages of notebooks. For no reason would I keep documents open, for two reasons : - when I shutdown my notebook, it is to move from one customer to home/company/another customer. There's no related work anyway, the network will have changed and I'll have to switch nearly all of my apps anyway. So using suspend just to save one reboot is not worth it (for me) IMHO. - I would certainly not keep open documents that are on crypted FS while I travel. Otherwise, it would be a total waste of time to enter my passphrase everytime I need to access them ! Some might argue that it would save me a lot of time, providing me with the ability to type my passphrase only once a month, but that's not what I'm looking for :-) I can barely understand why one would prefer to suspend when the notebook does not move at all, but under the conditions above, advantages are really faint. I now realize that people I work with also face the same constraints, which can explain why they don't use such features either, whatever the OS. Best regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:46 ` Willy Tarreau @ 2007-02-11 23:18 ` Nigel Cunningham 2007-02-11 23:38 ` Willy Tarreau 2007-02-11 23:23 ` Alan 2007-02-11 23:38 ` Rafael J. Wysocki 2 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:18 UTC (permalink / raw) To: Willy Tarreau; +Cc: Robert Hancock, linux-kernel Hi. On Sun, 2007-02-11 at 23:46 +0100, Willy Tarreau wrote: > > On Sun, 2007-02-11 at 22:52 +0100, Willy Tarreau wrote: > > > On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote: > > > > Willy Tarreau wrote: > > > > >Nigel, don't take it as a personal offense, but I think it is a very > > > > >centric view of Linux usages. Where I work, Linux is used a lot on > > > > >servers and appliances. It is used for mail relays, HTTP proxies, > > > > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > > > > >etc... Nobody would ever want to enable power management on those > > > > >machines, let alone suspend which would cause a major havoc, would > > > > >the system decide to enter suspend for any reason. > > > > > > > > > >Many people also have Linux on their notebooks, but as a dual-boot. You > > > > >read the word ? "dual-boot". It means that they cleanly shutdown their > > > > >system every time they don't use it anymore, and they won't know what > > > > >OS they'll use next time. > > > > > > > > > >I've never heard anyone there complaining "oh, I'm fed up with this > > > > >boring boot, I always have to wait 30 seconds when I need to do > > > > >something, I wish I could suspend and resume". It is considered the > > > > >normal way of using their PCs. > > > > > > > > I think your experience is rather different than that of Joe Average > > > > User who doesn't frequent kernel lists, and also I think you'll find > > > > that for a lot of Linux laptop users that don't use supend, the reason > > > > is that it doesn't work reliably, quite often due to driver issues. > > > > > > I would believe it if I knew people using suspend/resume on the other OS. > > > But that's not the case either. Also, it happens that with today's RAM > > > sizes, suspend-to-disk then resume can be several times slower than a > > > clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 > > > seconds to shut down, and as much to restart. Compare this to 5-10 > > > seconds for a shutdown and 30-50 seconds for a cold boot, and it might > > > give you another clue why there are people not interested in such a > > > feature. > > > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > card that Linux doesn't support well yet), and I know other Suspend2 > > users doing the same. It's made earier by the fact that Suspend2 lets > > you reboot instead of powering down. > > > > As to comparing the speed with the time to boot, your estimates are way > > out. Both will of course vary with the harddrive and cpu speeds and > > compression qualities of the image, but with Suspend2, I'm seeing speeds > > more in the range of 40-100MB/s, and even had a resport of 160MB/s a > > couple of days ago. The rule of thumb I use is: > > > > Run hdparm -t (or equiv) on the drive you'll be using: > > > > nigel@nigel:~$ sudo hdparm -t /dev/hda > > > > /dev/hda: > > Timing buffered disk reads: 120 MB in 3.02 seconds = 39.70 MB/sec > > > > Then calculate RAM_IN_MB / 2 / HDPARM_RESULT = seconds to read/write > > image. > > > > In my case: 1024 / 2 / 39.7 = approx 12 seconds. The / 2 is because with > > LZF compression, you normally get about 50% compression. > > > > I think the mean reason some people aren't interested in suspend to disk > > is because of myths (if you'll excuse the term) like the one you've put > > above. Of course that values you give were more accurate for swsusp and > > uswsusp until recently, but Suspend2 has had async I/O and compression > > for years, so all I can really do is encourage you to try again. > > Well, I agree that you give some good arguments here. > > > Of course there's another factor you're not taking into account: With > > suspending to disk, you don't have to close and reopen documents or shut > > down and restart applications. The time to do that should be factored > > into the non-suspend-to-disk time to compare apples with apples. > > Hmm sorry, but we don't have the same usages of notebooks. For no reason > would I keep documents open, for two reasons : > > - when I shutdown my notebook, it is to move from one customer to > home/company/another customer. There's no related work anyway, the > network will have changed and I'll have to switch nearly all of my > apps anyway. So using suspend just to save one reboot is not worth > it (for me) IMHO. The network configuration utilities can help there. In addition, Suspend2 preserves the commandline you used to boot with (/sys/power/suspend2/resume_commandline), so you can use a combination of slightly varying grub entries (I have one for not starting ath0 and one for starting it) and scripts to do different things in different environments. The resume_commandline is writable, so can be cleared after usage if there were anything sensitive there. > - I would certainly not keep open documents that are on crypted FS > while I travel. Otherwise, it would be a total waste of time to > enter my passphrase everytime I need to access them ! Some might > argue that it would save me a lot of time, providing me with the > ability to type my passphrase only once a month, but that's not > what I'm looking for :-) People are using Suspend2 with encryption today (I'm not sure about uswsusp). Some of them have set things up so you need to use a passphrase or usb key to resume, and the image itself is of course encrypted too. You could also close the document and not the app. Or both and just get the benefit of having the app in page cache post-resume. > I can barely understand why one would prefer to suspend when the notebook > does not move at all, but under the conditions above, advantages are really > faint. I now realize that people I work with also face the same constraints, > which can explain why they don't use such features either, whatever the OS. I guess the thing you're highlighting to me is the lack of awareness of the options that are available. Maybe I need to work harder at making people aware of the possible usage scenarios! :) Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:18 ` Nigel Cunningham @ 2007-02-11 23:38 ` Willy Tarreau 2007-02-11 23:45 ` Nigel Cunningham 2007-02-12 0:26 ` Alan 0 siblings, 2 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 23:38 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Robert Hancock, linux-kernel On Mon, Feb 12, 2007 at 10:18:42AM +1100, Nigel Cunningham wrote: [snip] > > Hmm sorry, but we don't have the same usages of notebooks. For no reason > > would I keep documents open, for two reasons : > > > > - when I shutdown my notebook, it is to move from one customer to > > home/company/another customer. There's no related work anyway, the > > network will have changed and I'll have to switch nearly all of my > > apps anyway. So using suspend just to save one reboot is not worth > > it (for me) IMHO. > > The network configuration utilities can help there. In addition, > Suspend2 preserves the commandline you used to boot with > (/sys/power/suspend2/resume_commandline), so you can use a combination > of slightly varying grub entries (I have one for not starting ath0 and > one for starting it) and scripts to do different things in different > environments. The resume_commandline is writable, so can be cleared > after usage if there were anything sensitive there. OK, I see there are features to make life easier when I decide to use suspend. But it looks like that using suspend is the goal and dealing with the constraints is a lot of work and I'm still far from being convinced that it would provide me advantage. > > - I would certainly not keep open documents that are on crypted FS > > while I travel. Otherwise, it would be a total waste of time to > > enter my passphrase everytime I need to access them ! Some might > > argue that it would save me a lot of time, providing me with the > > ability to type my passphrase only once a month, but that's not > > what I'm looking for :-) > > People are using Suspend2 with encryption today (I'm not sure about > uswsusp). Some of them have set things up so you need to use a > passphrase or usb key to resume, and the image itself is of course > encrypted too. Unless I'm mistaken, I have to type the passphrase twice then : - once at suspend - once at resume which is once more per "boot" than what I'm doing on loop-aes. > You could also close the document and not the app. Or both and just get > the benefit of having the app in page cache post-resume. I'm not much convinced by the advantage of reading 500 MB on disk to have emacs in hot cache :-) > > I can barely understand why one would prefer to suspend when the notebook > > does not move at all, but under the conditions above, advantages are really > > faint. I now realize that people I work with also face the same constraints, > > which can explain why they don't use such features either, whatever the OS. > > I guess the thing you're highlighting to me is the lack of awareness of > the options that are available. Maybe I need to work harder at making > people aware of the possible usage scenarios! :) You're certainly right. I really think that this feature is clearly not for me but it's more featureful than I initially thought, and I could encourage some people to give it a try. Best regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:38 ` Willy Tarreau @ 2007-02-11 23:45 ` Nigel Cunningham 2007-02-12 0:26 ` Alan 1 sibling, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:45 UTC (permalink / raw) To: Willy Tarreau; +Cc: Robert Hancock, linux-kernel Hi. On Mon, 2007-02-12 at 00:38 +0100, Willy Tarreau wrote: > On Mon, Feb 12, 2007 at 10:18:42AM +1100, Nigel Cunningham wrote: > [snip] > > > Hmm sorry, but we don't have the same usages of notebooks. For no reason > > > would I keep documents open, for two reasons : > > > > > > - when I shutdown my notebook, it is to move from one customer to > > > home/company/another customer. There's no related work anyway, the > > > network will have changed and I'll have to switch nearly all of my > > > apps anyway. So using suspend just to save one reboot is not worth > > > it (for me) IMHO. > > > > The network configuration utilities can help there. In addition, > > Suspend2 preserves the commandline you used to boot with > > (/sys/power/suspend2/resume_commandline), so you can use a combination > > of slightly varying grub entries (I have one for not starting ath0 and > > one for starting it) and scripts to do different things in different > > environments. The resume_commandline is writable, so can be cleared > > after usage if there were anything sensitive there. > > OK, I see there are features to make life easier when I decide to use > suspend. But it looks like that using suspend is the goal and dealing > with the constraints is a lot of work and I'm still far from being > convinced that it would provide me advantage. Ok. I don't feel like I have to convince everyone :) > > > - I would certainly not keep open documents that are on crypted FS > > > while I travel. Otherwise, it would be a total waste of time to > > > enter my passphrase everytime I need to access them ! Some might > > > argue that it would save me a lot of time, providing me with the > > > ability to type my passphrase only once a month, but that's not > > > what I'm looking for :-) > > > > People are using Suspend2 with encryption today (I'm not sure about > > uswsusp). Some of them have set things up so you need to use a > > passphrase or usb key to resume, and the image itself is of course > > encrypted too. > > Unless I'm mistaken, I have to type the passphrase twice then : > - once at suspend > - once at resume > > which is once more per "boot" than what I'm doing on loop-aes. I'm not sure. I don't use encryption myself, so I don't understand all the fine details. I just know that there are people out there using encryption, loop-aes, dmsetup and all that sort of stuff. I don't have to worry about it because they use an initrd/ramfs to do whatever they need to do to provide access to the device on which the image is found, then echo /dev/whatever_funny_device > /sys/power/suspend2/resume2 echo > /sys/power/suspend2/do_resume > > You could also close the document and not the app. Or both and just get > > the benefit of having the app in page cache post-resume. > > I'm not much convinced by the advantage of reading 500 MB on disk to have > emacs in hot cache :-) Neither am I! Presumably you'd have a lot more than emacs in there though :) You could always switch to vim! (*ducks*) Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:38 ` Willy Tarreau 2007-02-11 23:45 ` Nigel Cunningham @ 2007-02-12 0:26 ` Alan 2007-02-12 5:19 ` Willy Tarreau 1 sibling, 1 reply; 155+ messages in thread From: Alan @ 2007-02-12 0:26 UTC (permalink / raw) To: Willy Tarreau; +Cc: linux-kernel > Unless I'm mistaken, I have to type the passphrase twice then : > - once at suspend > - once at resume > > which is once more per "boot" than what I'm doing on loop-aes. You don't need to type in a key at suspend time if you don't want to. Think about gpg email - I can send you an encrypted email without typing any keys, you need the right key however to read it. Alan ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 0:26 ` Alan @ 2007-02-12 5:19 ` Willy Tarreau 2007-02-12 20:20 ` Rafael J. Wysocki 2007-02-12 22:36 ` Nigel Cunningham 0 siblings, 2 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-12 5:19 UTC (permalink / raw) To: Alan; +Cc: linux-kernel On Mon, Feb 12, 2007 at 12:26:52AM +0000, Alan wrote: > > Unless I'm mistaken, I have to type the passphrase twice then : > > - once at suspend > > - once at resume > > > > which is once more per "boot" than what I'm doing on loop-aes. > > You don't need to type in a key at suspend time if you don't want to. > Think about gpg email - I can send you an encrypted email without typing > any keys, you need the right key however to read it. OK, so that means that it can generate a random secret which is crypted with your public key. That's very different from a crypted FS which has to keep the same secret key over time for obvious reasons, but it is smart to proceed this way. One less "myth" as Nigel would say call it ;-) Thanks Alan for clarifications Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 5:19 ` Willy Tarreau @ 2007-02-12 20:20 ` Rafael J. Wysocki 2007-02-12 22:36 ` Nigel Cunningham 1 sibling, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 20:20 UTC (permalink / raw) To: Willy Tarreau; +Cc: Alan, linux-kernel On Monday, 12 February 2007 06:19, Willy Tarreau wrote: > On Mon, Feb 12, 2007 at 12:26:52AM +0000, Alan wrote: > > > Unless I'm mistaken, I have to type the passphrase twice then : > > > - once at suspend > > > - once at resume > > > > > > which is once more per "boot" than what I'm doing on loop-aes. > > > > You don't need to type in a key at suspend time if you don't want to. > > Think about gpg email - I can send you an encrypted email without typing > > any keys, you need the right key however to read it. > > OK, so that means that it can generate a random secret which is crypted > with your public key. That's very different from a crypted FS which has > to keep the same secret key over time for obvious reasons, but it is > smart to proceed this way. > > One less "myth" as Nigel would say call it ;-) Yup. Our userland suspend tools available from http://suspend.sf.net are capable of doing that in a more or less transparent way. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 5:19 ` Willy Tarreau 2007-02-12 20:20 ` Rafael J. Wysocki @ 2007-02-12 22:36 ` Nigel Cunningham 1 sibling, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-12 22:36 UTC (permalink / raw) To: Willy Tarreau; +Cc: Alan, linux-kernel Hi. On Mon, 2007-02-12 at 06:19 +0100, Willy Tarreau wrote: > One less "myth" as Nigel would say call it ;-) You know me too well! :> ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:46 ` Willy Tarreau 2007-02-11 23:18 ` Nigel Cunningham @ 2007-02-11 23:23 ` Alan 2007-02-11 23:38 ` Rafael J. Wysocki 2 siblings, 0 replies; 155+ messages in thread From: Alan @ 2007-02-11 23:23 UTC (permalink / raw) To: Willy Tarreau; +Cc: Nigel Cunningham, Robert Hancock, linux-kernel > Hmm sorry, but we don't have the same usages of notebooks. For no reason > would I keep documents open, for two reasons : > > - when I shutdown my notebook, it is to move from one customer to > home/company/another customer. There's no related work anyway, the > network will have changed and I'll have to switch nearly all of my > apps anyway. So using suspend just to save one reboot is not worth > it (for me) IMHO. > > - I would certainly not keep open documents that are on crypted FS > while I travel. You use the encryption patches for suspend. And even if you turn your laptop off and leave it somewhere for a bit I can turn it on install a trojan and turn it off again. Suspend/Resume is supposed to work, many people find it useful. One non suspend friendly driver makes every suspend aware driver on that system useless so we really should be tight about suspend/resume. Alan ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:46 ` Willy Tarreau 2007-02-11 23:18 ` Nigel Cunningham 2007-02-11 23:23 ` Alan @ 2007-02-11 23:38 ` Rafael J. Wysocki 2 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:38 UTC (permalink / raw) To: Willy Tarreau; +Cc: Nigel Cunningham, Robert Hancock, linux-kernel On Sunday, 11 February 2007 23:46, Willy Tarreau wrote: > On Mon, Feb 12, 2007 at 09:26:26AM +1100, Nigel Cunningham wrote: > > Hi. > > > > On Sun, 2007-02-11 at 22:52 +0100, Willy Tarreau wrote: > > > On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote: > > > > Willy Tarreau wrote: > > > > >Nigel, don't take it as a personal offense, but I think it is a very > > > > >centric view of Linux usages. Where I work, Linux is used a lot on > > > > >servers and appliances. It is used for mail relays, HTTP proxies, > > > > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > > > > >etc... Nobody would ever want to enable power management on those > > > > >machines, let alone suspend which would cause a major havoc, would > > > > >the system decide to enter suspend for any reason. > > > > > > > > > >Many people also have Linux on their notebooks, but as a dual-boot. You > > > > >read the word ? "dual-boot". It means that they cleanly shutdown their > > > > >system every time they don't use it anymore, and they won't know what > > > > >OS they'll use next time. > > > > > > > > > >I've never heard anyone there complaining "oh, I'm fed up with this > > > > >boring boot, I always have to wait 30 seconds when I need to do > > > > >something, I wish I could suspend and resume". It is considered the > > > > >normal way of using their PCs. > > > > > > > > I think your experience is rather different than that of Joe Average > > > > User who doesn't frequent kernel lists, and also I think you'll find > > > > that for a lot of Linux laptop users that don't use supend, the reason > > > > is that it doesn't work reliably, quite often due to driver issues. > > > > > > I would believe it if I knew people using suspend/resume on the other OS. > > > But that's not the case either. Also, it happens that with today's RAM > > > sizes, suspend-to-disk then resume can be several times slower than a > > > clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 > > > seconds to shut down, and as much to restart. Compare this to 5-10 > > > seconds for a shutdown and 30-50 seconds for a cold boot, and it might > > > give you another clue why there are people not interested in such a > > > feature. I use the suspend to disk on a regular basis, because it takes at least 3x more time to boot and get KDE started than to resume. > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > card that Linux doesn't support well yet), and I know other Suspend2 > > users doing the same. It's made earier by the fact that Suspend2 lets > > you reboot instead of powering down. > > > > As to comparing the speed with the time to boot, your estimates are way > > out. Both will of course vary with the harddrive and cpu speeds and > > compression qualities of the image, but with Suspend2, I'm seeing speeds > > more in the range of 40-100MB/s, and even had a resport of 160MB/s a > > couple of days ago. The rule of thumb I use is: > > > > Run hdparm -t (or equiv) on the drive you'll be using: > > > > nigel@nigel:~$ sudo hdparm -t /dev/hda > > > > /dev/hda: > > Timing buffered disk reads: 120 MB in 3.02 seconds = 39.70 MB/sec > > > > Then calculate RAM_IN_MB / 2 / HDPARM_RESULT = seconds to read/write > > image. > > > > In my case: 1024 / 2 / 39.7 = approx 12 seconds. The / 2 is because with > > LZF compression, you normally get about 50% compression. > > > > I think the mean reason some people aren't interested in suspend to disk > > is because of myths (if you'll excuse the term) like the one you've put > > above. Of course that values you give were more accurate for swsusp and > > uswsusp until recently, but Suspend2 has had async I/O and compression > > for years, so all I can really do is encourage you to try again. > > Well, I agree that you give some good arguments here. > > > Of course there's another factor you're not taking into account: With > > suspending to disk, you don't have to close and reopen documents or shut > > down and restart applications. The time to do that should be factored > > into the non-suspend-to-disk time to compare apples with apples. > > Hmm sorry, but we don't have the same usages of notebooks. For no reason > would I keep documents open, for two reasons : > > - when I shutdown my notebook, it is to move from one customer to > home/company/another customer. There's no related work anyway, the > network will have changed and I'll have to switch nearly all of my > apps anyway. So using suspend just to save one reboot is not worth > it (for me) IMHO. > > - I would certainly not keep open documents that are on crypted FS > while I travel. Otherwise, it would be a total waste of time to > enter my passphrase everytime I need to access them ! Some might > argue that it would save me a lot of time, providing me with the > ability to type my passphrase only once a month, but that's not > what I'm looking for :-) > > I can barely understand why one would prefer to suspend when the notebook > does not move at all, but under the conditions above, advantages are really > faint. I now realize that people I work with also face the same constraints, > which can explain why they don't use such features either, whatever the OS. Please note we're talking about the suspend to RAM here too and, arguably, the support in drivers is more important for the suspend to RAM. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:26 ` Nigel Cunningham 2007-02-11 22:46 ` Willy Tarreau @ 2007-02-11 23:41 ` Rafael J. Wysocki 2007-02-11 23:47 ` Nigel Cunningham 1 sibling, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:41 UTC (permalink / raw) To: nigel; +Cc: Willy Tarreau, Robert Hancock, linux-kernel On Sunday, 11 February 2007 23:26, Nigel Cunningham wrote: > Hi. > > On Sun, 2007-02-11 at 22:52 +0100, Willy Tarreau wrote: > > On Sun, Feb 11, 2007 at 12:31:14PM -0600, Robert Hancock wrote: > > > Willy Tarreau wrote: > > > >Nigel, don't take it as a personal offense, but I think it is a very > > > >centric view of Linux usages. Where I work, Linux is used a lot on > > > >servers and appliances. It is used for mail relays, HTTP proxies, > > > >anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > > > >etc... Nobody would ever want to enable power management on those > > > >machines, let alone suspend which would cause a major havoc, would > > > >the system decide to enter suspend for any reason. > > > > > > > >Many people also have Linux on their notebooks, but as a dual-boot. You > > > >read the word ? "dual-boot". It means that they cleanly shutdown their > > > >system every time they don't use it anymore, and they won't know what > > > >OS they'll use next time. > > > > > > > >I've never heard anyone there complaining "oh, I'm fed up with this > > > >boring boot, I always have to wait 30 seconds when I need to do > > > >something, I wish I could suspend and resume". It is considered the > > > >normal way of using their PCs. > > > > > > I think your experience is rather different than that of Joe Average > > > User who doesn't frequent kernel lists, and also I think you'll find > > > that for a lot of Linux laptop users that don't use supend, the reason > > > is that it doesn't work reliably, quite often due to driver issues. > > > > I would believe it if I knew people using suspend/resume on the other OS. > > But that's not the case either. Also, it happens that with today's RAM > > sizes, suspend-to-disk then resume can be several times slower than a > > clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 > > seconds to shut down, and as much to restart. Compare this to 5-10 > > seconds for a shutdown and 30-50 seconds for a cold boot, and it might > > give you another clue why there are people not interested in such a > > feature. > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > card that Linux doesn't support well yet), and I know other Suspend2 > users doing the same. It's made earier by the fact that Suspend2 lets > you reboot instead of powering down. Well, I don't know why you're saying it's a special capability of suspend2. Even the "old" swsusp has been able to do this since I can remember. ;-) Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:41 ` Rafael J. Wysocki @ 2007-02-11 23:47 ` Nigel Cunningham 2007-02-11 23:50 ` Rafael J. Wysocki 0 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:47 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Willy Tarreau, Robert Hancock, linux-kernel Hi. On Mon, 2007-02-12 at 00:41 +0100, Rafael J. Wysocki wrote: > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > card that Linux doesn't support well yet), and I know other Suspend2 > > users doing the same. It's made earier by the fact that Suspend2 lets > > you reboot instead of powering down. > > Well, I don't know why you're saying it's a special capability of suspend2. > Even the "old" swsusp has been able to do this since I can remember. ;-) It does?! I just did cat /sys/power/disk and it only says platform. How do you make swsusp reboot instead of powering down? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:47 ` Nigel Cunningham @ 2007-02-11 23:50 ` Rafael J. Wysocki 2007-02-11 23:55 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:50 UTC (permalink / raw) To: nigel; +Cc: Willy Tarreau, Robert Hancock, linux-kernel On Monday, 12 February 2007 00:47, Nigel Cunningham wrote: > Hi. > > On Mon, 2007-02-12 at 00:41 +0100, Rafael J. Wysocki wrote: > > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > > card that Linux doesn't support well yet), and I know other Suspend2 > > > users doing the same. It's made earier by the fact that Suspend2 lets > > > you reboot instead of powering down. > > > > Well, I don't know why you're saying it's a special capability of suspend2. > > Even the "old" swsusp has been able to do this since I can remember. ;-) > > It does?! I just did cat /sys/power/disk and it only says platform. How > do you make swsusp reboot instead of powering down? echo reboot > /sys/power/disk && echo disk > /sys/power/state Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:50 ` Rafael J. Wysocki @ 2007-02-11 23:55 ` Nigel Cunningham 2007-02-12 0:09 ` Rafael J. Wysocki 0 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:55 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Willy Tarreau, Robert Hancock, linux-kernel Hi. On Mon, 2007-02-12 at 00:50 +0100, Rafael J. Wysocki wrote: > On Monday, 12 February 2007 00:47, Nigel Cunningham wrote: > > Hi. > > > > On Mon, 2007-02-12 at 00:41 +0100, Rafael J. Wysocki wrote: > > > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > > > card that Linux doesn't support well yet), and I know other Suspend2 > > > > users doing the same. It's made earier by the fact that Suspend2 lets > > > > you reboot instead of powering down. > > > > > > Well, I don't know why you're saying it's a special capability of suspend2. > > > Even the "old" swsusp has been able to do this since I can remember. ;-) > > > > It does?! I just did cat /sys/power/disk and it only says platform. How > > do you make swsusp reboot instead of powering down? > > echo reboot > /sys/power/disk && echo disk > /sys/power/state Ah. Perhaps you should make it show reboot when you cat it? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:55 ` Nigel Cunningham @ 2007-02-12 0:09 ` Rafael J. Wysocki 2007-02-12 0:15 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 0:09 UTC (permalink / raw) To: nigel; +Cc: Willy Tarreau, Robert Hancock, linux-kernel On Monday, 12 February 2007 00:55, Nigel Cunningham wrote: > Hi. > > On Mon, 2007-02-12 at 00:50 +0100, Rafael J. Wysocki wrote: > > On Monday, 12 February 2007 00:47, Nigel Cunningham wrote: > > > Hi. > > > > > > On Mon, 2007-02-12 at 00:41 +0100, Rafael J. Wysocki wrote: > > > > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > > > > card that Linux doesn't support well yet), and I know other Suspend2 > > > > > users doing the same. It's made earier by the fact that Suspend2 lets > > > > > you reboot instead of powering down. > > > > > > > > Well, I don't know why you're saying it's a special capability of suspend2. > > > > Even the "old" swsusp has been able to do this since I can remember. ;-) > > > > > > It does?! I just did cat /sys/power/disk and it only says platform. How > > > do you make swsusp reboot instead of powering down? > > > > echo reboot > /sys/power/disk && echo disk > /sys/power/state > > Ah. Perhaps you should make it show reboot when you cat it? albercik:~ # echo reboot > /sys/power/disk albercik:~ # cat /sys/power/disk reboot It shows the current value, and "platform" happens to be the default now. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 0:09 ` Rafael J. Wysocki @ 2007-02-12 0:15 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-12 0:15 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Willy Tarreau, Robert Hancock, linux-kernel Hi. On Mon, 2007-02-12 at 01:09 +0100, Rafael J. Wysocki wrote: > On Monday, 12 February 2007 00:55, Nigel Cunningham wrote: > > Hi. > > > > On Mon, 2007-02-12 at 00:50 +0100, Rafael J. Wysocki wrote: > > > On Monday, 12 February 2007 00:47, Nigel Cunningham wrote: > > > > Hi. > > > > > > > > On Mon, 2007-02-12 at 00:41 +0100, Rafael J. Wysocki wrote: > > > > > > I'm using M$ hibernation and Suspend2 to dual boot on our desktop (dtv > > > > > > card that Linux doesn't support well yet), and I know other Suspend2 > > > > > > users doing the same. It's made earier by the fact that Suspend2 lets > > > > > > you reboot instead of powering down. > > > > > > > > > > Well, I don't know why you're saying it's a special capability of suspend2. > > > > > Even the "old" swsusp has been able to do this since I can remember. ;-) > > > > > > > > It does?! I just did cat /sys/power/disk and it only says platform. How > > > > do you make swsusp reboot instead of powering down? > > > > > > echo reboot > /sys/power/disk && echo disk > /sys/power/state > > > > Ah. Perhaps you should make it show reboot when you cat it? > > albercik:~ # echo reboot > /sys/power/disk > albercik:~ # cat /sys/power/disk > reboot > > It shows the current value, and "platform" happens to be the default now. Oh, so the problem is that it shows the current value, not the possibilities. I wrongly assumed it would work like /sys/power/disk. That explains it :) Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 21:52 ` Willy Tarreau 2007-02-11 22:26 ` Nigel Cunningham @ 2007-02-12 12:19 ` Pavel Machek 1 sibling, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-12 12:19 UTC (permalink / raw) To: Willy Tarreau; +Cc: Robert Hancock, linux-kernel, Nigel Cunningham Hi! > > I think your experience is rather different than that of Joe Average > > User who doesn't frequent kernel lists, and also I think you'll find > > that for a lot of Linux laptop users that don't use supend, the reason > > is that it doesn't work reliably, quite often due to driver issues. > > I would believe it if I knew people using suspend/resume on the other OS. > But that's not the case either. Also, it happens that with today's RAM > sizes, suspend-to-disk then resume can be several times slower than a > clean fresh boot. When you have 1 GB to write at 20 MB/s, it takes 50 Stop spreading FUD. swsusp only saves _used_ memory, not all memory, so it indeed should be faster these days. And yes, it supports encryption these days. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
[parent not found: <fa.O1YH4k5KtBGCNs5i2yB17bPvPGw@ifi.uio.no>]
[parent not found: <fa.RfzClbTP/7B79AoEbQLNj3ABfIk@ifi.uio.no>]
[parent not found: <fa.AaJ/ugmiUmPO8uC+y1rS9JLuuMc@ifi.uio.no>]
* Re: NAK new drivers without proper power management? [not found] ` <fa.AaJ/ugmiUmPO8uC+y1rS9JLuuMc@ifi.uio.no> @ 2007-02-12 0:59 ` Robert Hancock 0 siblings, 0 replies; 155+ messages in thread From: Robert Hancock @ 2007-02-12 0:59 UTC (permalink / raw) To: Tilman Schmidt, linux-kernel; +Cc: nigel Tilman Schmidt wrote: >>>> If your device requires power management, and you know it requires power >>>> management, why not just implement power management? [...] >>> Like it or not, power management is far from trivial, and people >>> writing device drivers have limited resources. [...] >> It's not that complex. All we're really talking about is a bit of extra >> code to cleanup and configure hardware state; things that the driver >> author already knows how to do. S3 might require a bit more >> initialisation if firmware needs to be reloaded or more extensive >> configuration needs to be done, but if there's firmware to be loaded, >> there is a reasonably good probability that we loaded it from Linux to >> start with anyway. > > You are assuming a perfect world where driver authors have complete > knowledge of their devices. In reality, many drivers (including > those I have the mixed pleasure of maintaining) are based at least > in part on reverse engineering, and managing power states may well > fall into the domain of things not yet sufficiently reverse > engineered. > >>> Also, in your argument you neglected a few cases: >>> - What if my device does not require power management? >> Then you as a generic routine that does nothing but return success >> (potentially shared with other drivers that are in the same situation). > > But if I just write an empty routine like that I open myself up to > criticism along the lines of "writing dummy routines just in order > to shut up kernel warnings". BTDT. Well, it couldn't actually be an empty routine (at least not for a PCI device), since the generic PCI suspend/resume handling doesn't get called if you have suspend/resume functions defined, so you'd have to do the pci_save_state, pci_disable_device, pci_set_power_state, etc. in there at least. Using empty functions would prevent those from being called and result in your PCI config space contain crap after resuming, which can break the whole system. That's a bit messy, actually.. I know we can't just do that stuff unconditionally in the PCI layer since some devices blow up if you disable them, which we normally do, etc. We should just have some generic function you can stick in the .suspend slot that just says "I know how to suspend, but don't need anything more than the generic handling". And if you do need more than that (which is almost always the case), you can just call that from your own function and then add what you need, instead of duplicating the code a million times (sometimes in an incomplete/incorrect fashion) like we do now. >>> - What if I don't know whether my device requires power management? >> The questions are straight forward: Is there hardware state that needs >> to be configured if you've just booted the computer and nothing else has >> touched it? If so, that needs to be done in a resume method. Do you need >> to clean up state prior to doing the things in the resume method, or >> otherwise do things to quiesce the driver? If so, they will need to be >> done in the suspend method. The result will be roughly similar to what >> you do for module load/unload, except maybe less complete in some cases. > > I don't doubt your basic assessment. However it doesn't translate that > easily into a real implementation. In my case, I maintain a USB driver, > so I have to deal with USB specifics of suspend/resume which happen not > to be that well documented. My driver provides an isdn4linux device but > isdn4linux knows nothing about suspend/resume so I am on my own on how > to reconcile the two. The device itself, though in turn far from trivial, > is actually the least of my worries. That is one good excuse for not implementing it - the driver is part of a framework which does not handle suspend/resume itself. (The current FireWire stack is another case like this.) This is the kind of situation where I would say the driver should just define a suspend function that returns -ENOSYS and then the user would know they have to remove that module, etc. before suspending (there is at least some distro script support for doing that automatically based on a config file), since it hasn't a hope of working after resume until the framework is updated to support suspending. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from hancockr@nospamshaw.ca Home Page: http://www.roberthancock.com/ ^ permalink raw reply [flat|nested] 155+ messages in thread
* NAK new drivers without proper power management? @ 2007-02-09 21:57 Nigel Cunningham 2007-02-09 22:17 ` Arjan van de Ven 2007-02-10 3:42 ` Matthew Garrett 0 siblings, 2 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-09 21:57 UTC (permalink / raw) To: LKML Hi. I don't think this is already done (feel free to correct me if I'm wrong).. Can we start to NAK new drivers that don't have proper power management implemented? There really is no excuse for writing a new driver and not putting .suspend and .resume methods in anymore, is there? Regards, Nigel-getting-sick-of-drivers-without-pm-support Cunningham ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 21:57 Nigel Cunningham @ 2007-02-09 22:17 ` Arjan van de Ven 2007-02-09 22:26 ` Nigel Cunningham 2007-02-10 19:38 ` Pavel Machek 2007-02-10 3:42 ` Matthew Garrett 1 sibling, 2 replies; 155+ messages in thread From: Arjan van de Ven @ 2007-02-09 22:17 UTC (permalink / raw) To: nigel; +Cc: LKML On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > Hi. > > I don't think this is already done (feel free to correct me if I'm > wrong).. > > Can we start to NAK new drivers that don't have proper power management > implemented? There really is no excuse for writing a new driver and not > putting .suspend and .resume methods in anymore, is there? to a large degree, a device driver that doesn't suspend is better than no device driver at all, right? now.. if you want to make the core warn about it, that's very fair ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:17 ` Arjan van de Ven @ 2007-02-09 22:26 ` Nigel Cunningham 2007-02-09 22:44 ` Rafael J. Wysocki ` (2 more replies) 2007-02-10 19:38 ` Pavel Machek 1 sibling, 3 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-09 22:26 UTC (permalink / raw) To: Arjan van de Ven; +Cc: LKML Hi. On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > Hi. > > > > I don't think this is already done (feel free to correct me if I'm > > wrong).. > > > > Can we start to NAK new drivers that don't have proper power management > > implemented? There really is no excuse for writing a new driver and not > > putting .suspend and .resume methods in anymore, is there? > > > to a large degree, a device driver that doesn't suspend is better than > no device driver at all, right? I'm not sure it is. It only makes more work for everyone else: We have to help people figure out what causes their computer to fail to resume (which can take quite a while), then get them them complain to driver author, and the driver author has to submit patches to fix it. All of this is avoided if they'll just do it right in the first place. > now.. if you want to make the core warn about it, that's very fair That's probably a good idea too, since I'm only suggesting this for new drivers. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:26 ` Nigel Cunningham @ 2007-02-09 22:44 ` Rafael J. Wysocki 2007-02-10 0:25 ` Jeff Garzik 2007-02-10 7:15 ` Arjan van de Ven 2 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-09 22:44 UTC (permalink / raw) To: nigel; +Cc: Arjan van de Ven, LKML, pm list On Friday, 9 February 2007 23:26, Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > > Hi. > > > > > > I don't think this is already done (feel free to correct me if I'm > > > wrong).. > > > > > > Can we start to NAK new drivers that don't have proper power management > > > implemented? There really is no excuse for writing a new driver and not > > > putting .suspend and .resume methods in anymore, is there? > > > > > > to a large degree, a device driver that doesn't suspend is better than > > no device driver at all, right? > > I'm not sure it is. It only makes more work for everyone else: We have > to help people figure out what causes their computer to fail to resume > (which can take quite a while), then get them them complain to driver > author, and the driver author has to submit patches to fix it. > > All of this is avoided if they'll just do it right in the first place. > > > now.. if you want to make the core warn about it, that's very fair > > That's probably a good idea too, since I'm only suggesting this for new > drivers. I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not having .suspend or .resume routines. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? @ 2007-02-09 22:44 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-09 22:44 UTC (permalink / raw) To: nigel; +Cc: pm list, LKML, Arjan van de Ven On Friday, 9 February 2007 23:26, Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > > Hi. > > > > > > I don't think this is already done (feel free to correct me if I'm > > > wrong).. > > > > > > Can we start to NAK new drivers that don't have proper power management > > > implemented? There really is no excuse for writing a new driver and not > > > putting .suspend and .resume methods in anymore, is there? > > > > > > to a large degree, a device driver that doesn't suspend is better than > > no device driver at all, right? > > I'm not sure it is. It only makes more work for everyone else: We have > to help people figure out what causes their computer to fail to resume > (which can take quite a while), then get them them complain to driver > author, and the driver author has to submit patches to fix it. > > All of this is avoided if they'll just do it right in the first place. > > > now.. if you want to make the core warn about it, that's very fair > > That's probably a good idea too, since I'm only suggesting this for new > drivers. I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not having .suspend or .resume routines. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:44 ` Rafael J. Wysocki @ 2007-02-09 22:51 ` Nigel Cunningham -1 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-09 22:51 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Arjan van de Ven, LKML, pm list Hi. On Fri, 2007-02-09 at 23:44 +0100, Rafael J. Wysocki wrote: > On Friday, 9 February 2007 23:26, Nigel Cunningham wrote: > > Hi. > > > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > > > Hi. > > > > > > > > I don't think this is already done (feel free to correct me if I'm > > > > wrong).. > > > > > > > > Can we start to NAK new drivers that don't have proper power management > > > > implemented? There really is no excuse for writing a new driver and not > > > > putting .suspend and .resume methods in anymore, is there? > > > > > > > > > to a large degree, a device driver that doesn't suspend is better than > > > no device driver at all, right? > > > > I'm not sure it is. It only makes more work for everyone else: We have > > to help people figure out what causes their computer to fail to resume > > (which can take quite a while), then get them them complain to driver > > author, and the driver author has to submit patches to fix it. > > > > All of this is avoided if they'll just do it right in the first place. > > > > > now.. if you want to make the core warn about it, that's very fair > > > > That's probably a good idea too, since I'm only suggesting this for new > > drivers. > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > having .suspend or .resume routines. The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. CONFIG_PM instead? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? @ 2007-02-09 22:51 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-09 22:51 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: pm list, LKML, Arjan van de Ven Hi. On Fri, 2007-02-09 at 23:44 +0100, Rafael J. Wysocki wrote: > On Friday, 9 February 2007 23:26, Nigel Cunningham wrote: > > Hi. > > > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > > > Hi. > > > > > > > > I don't think this is already done (feel free to correct me if I'm > > > > wrong).. > > > > > > > > Can we start to NAK new drivers that don't have proper power management > > > > implemented? There really is no excuse for writing a new driver and not > > > > putting .suspend and .resume methods in anymore, is there? > > > > > > > > > to a large degree, a device driver that doesn't suspend is better than > > > no device driver at all, right? > > > > I'm not sure it is. It only makes more work for everyone else: We have > > to help people figure out what causes their computer to fail to resume > > (which can take quite a while), then get them them complain to driver > > author, and the driver author has to submit patches to fix it. > > > > All of this is avoided if they'll just do it right in the first place. > > > > > now.. if you want to make the core warn about it, that's very fair > > > > That's probably a good idea too, since I'm only suggesting this for new > > drivers. > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > having .suspend or .resume routines. The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. CONFIG_PM instead? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:51 ` Nigel Cunningham @ 2007-02-09 23:12 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-09 23:12 UTC (permalink / raw) To: nigel; +Cc: Arjan van de Ven, LKML, pm list Hi, On Friday, 9 February 2007 23:51, Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 23:44 +0100, Rafael J. Wysocki wrote: > > On Friday, 9 February 2007 23:26, Nigel Cunningham wrote: > > > Hi. > > > > > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > > > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > > > > Hi. > > > > > > > > > > I don't think this is already done (feel free to correct me if I'm > > > > > wrong).. > > > > > > > > > > Can we start to NAK new drivers that don't have proper power management > > > > > implemented? There really is no excuse for writing a new driver and not > > > > > putting .suspend and .resume methods in anymore, is there? > > > > > > > > > > > > to a large degree, a device driver that doesn't suspend is better than > > > > no device driver at all, right? > > > > > > I'm not sure it is. It only makes more work for everyone else: We have > > > to help people figure out what causes their computer to fail to resume > > > (which can take quite a while), then get them them complain to driver > > > author, and the driver author has to submit patches to fix it. > > > > > > All of this is avoided if they'll just do it right in the first place. > > > > > > > now.. if you want to make the core warn about it, that's very fair > > > > > > That's probably a good idea too, since I'm only suggesting this for new > > > drivers. > > > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > > having .suspend or .resume routines. > > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. > CONFIG_PM instead? Well, I can imagine a driver that doesn't need a .suspend routine, for example, and I don't think we should make the kernel always complain about that. I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it and report back. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? @ 2007-02-09 23:12 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-09 23:12 UTC (permalink / raw) To: nigel; +Cc: pm list, LKML, Arjan van de Ven Hi, On Friday, 9 February 2007 23:51, Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 23:44 +0100, Rafael J. Wysocki wrote: > > On Friday, 9 February 2007 23:26, Nigel Cunningham wrote: > > > Hi. > > > > > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > > > > On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > > > > > Hi. > > > > > > > > > > I don't think this is already done (feel free to correct me if I'm > > > > > wrong).. > > > > > > > > > > Can we start to NAK new drivers that don't have proper power management > > > > > implemented? There really is no excuse for writing a new driver and not > > > > > putting .suspend and .resume methods in anymore, is there? > > > > > > > > > > > > to a large degree, a device driver that doesn't suspend is better than > > > > no device driver at all, right? > > > > > > I'm not sure it is. It only makes more work for everyone else: We have > > > to help people figure out what causes their computer to fail to resume > > > (which can take quite a while), then get them them complain to driver > > > author, and the driver author has to submit patches to fix it. > > > > > > All of this is avoided if they'll just do it right in the first place. > > > > > > > now.. if you want to make the core warn about it, that's very fair > > > > > > That's probably a good idea too, since I'm only suggesting this for new > > > drivers. > > > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > > having .suspend or .resume routines. > > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. > CONFIG_PM instead? Well, I can imagine a driver that doesn't need a .suspend routine, for example, and I don't think we should make the kernel always complain about that. I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it and report back. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 23:12 ` Rafael J. Wysocki @ 2007-02-09 23:28 ` Nigel Cunningham -1 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-09 23:28 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Arjan van de Ven, LKML, pm list Hi. On Sat, 2007-02-10 at 00:12 +0100, Rafael J. Wysocki wrote: > > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > > > having .suspend or .resume routines. > > > > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. > > CONFIG_PM instead? > > Well, I can imagine a driver that doesn't need a .suspend routine, for example, > and I don't think we should make the kernel always complain about that. How about... #ifdef CONFIG_PM_PARANOIA static int empty_suspend_routine(struct device *dev, pm_message_t state) { return 0; } #define empty_suspend empty_suspend_routine #else #define empty_suspend NULL #endif ... .suspend = empty_suspend; ... Then CONFIG_PM_PARANOIA can be enabled by default for now, and when we eventually device it's not needed anymore, someone can submit a patch replacing either turning off the CONFIG by default or removing the whole mechanism. > I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it > and report back. We can, but the whole point to the suggestion was to make your life and mine easier, as well as those of our users. Making it dependent on CONFIG_PM instead achieves that by: - Saving you, I and distro people from having to tell their users to enable the option (and how to) - Saving the users the problem of going through all the steps, making mistakes, potentially ending up with unbootable systems because they make mistakes and so on. This way, they just need to look in dmesg. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? @ 2007-02-09 23:28 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-09 23:28 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: pm list, LKML, Arjan van de Ven Hi. On Sat, 2007-02-10 at 00:12 +0100, Rafael J. Wysocki wrote: > > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > > > having .suspend or .resume routines. > > > > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. > > CONFIG_PM instead? > > Well, I can imagine a driver that doesn't need a .suspend routine, for example, > and I don't think we should make the kernel always complain about that. How about... #ifdef CONFIG_PM_PARANOIA static int empty_suspend_routine(struct device *dev, pm_message_t state) { return 0; } #define empty_suspend empty_suspend_routine #else #define empty_suspend NULL #endif ... .suspend = empty_suspend; ... Then CONFIG_PM_PARANOIA can be enabled by default for now, and when we eventually device it's not needed anymore, someone can submit a patch replacing either turning off the CONFIG by default or removing the whole mechanism. > I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it > and report back. We can, but the whole point to the suggestion was to make your life and mine easier, as well as those of our users. Making it dependent on CONFIG_PM instead achieves that by: - Saving you, I and distro people from having to tell their users to enable the option (and how to) - Saving the users the problem of going through all the steps, making mistakes, potentially ending up with unbootable systems because they make mistakes and so on. This way, they just need to look in dmesg. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 23:28 ` Nigel Cunningham @ 2007-02-10 0:12 ` Rafael J. Wysocki -1 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 0:12 UTC (permalink / raw) To: nigel; +Cc: Arjan van de Ven, LKML, pm list On Saturday, 10 February 2007 00:28, Nigel Cunningham wrote: > Hi. > > On Sat, 2007-02-10 at 00:12 +0100, Rafael J. Wysocki wrote: > > > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > > > > having .suspend or .resume routines. > > > > > > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. > > > CONFIG_PM instead? > > > > Well, I can imagine a driver that doesn't need a .suspend routine, for example, > > and I don't think we should make the kernel always complain about that. > > How about... > > #ifdef CONFIG_PM_PARANOIA > static int empty_suspend_routine(struct device *dev, pm_message_t state) > { > return 0; > } > #define empty_suspend empty_suspend_routine > #else > #define empty_suspend NULL > #endif > > ... > > .suspend = empty_suspend; > ... > > > Then CONFIG_PM_PARANOIA can be enabled by default for now, and when we > eventually device it's not needed anymore, someone can submit a patch > replacing either turning off the CONFIG by default or removing the whole > mechanism. I think that would be tempting people to abuse it, for example by defining or undefining things just to quieten the warning. In my opinion the only way to make the warning go away should be to define a non-NULL .suspend (.resume) routine and that's why I don't think the warning should be mandatory. > > I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it > > and report back. > > We can, but the whole point to the suggestion was to make your life and > mine easier, as well as those of our users. > > Making it dependent on CONFIG_PM instead achieves that by: > - Saving you, I and distro people from having to tell their users to > enable the option (and how to) I think the distro people can patch their kernels to fit their needs. > - Saving the users the problem of going through all the steps, making > mistakes, potentially ending up with unbootable systems because they > make mistakes and so on. > > This way, they just need to look in dmesg. Well, IMO, if someone doesn't know how to compile and install the kernel, he'll be using a distro kernel anyway and then see above. Otherwise we can safely ask him to turn on whatever debugging options we need. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? @ 2007-02-10 0:12 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 0:12 UTC (permalink / raw) To: nigel; +Cc: pm list, LKML, Arjan van de Ven On Saturday, 10 February 2007 00:28, Nigel Cunningham wrote: > Hi. > > On Sat, 2007-02-10 at 00:12 +0100, Rafael J. Wysocki wrote: > > > > I think if CONFIG_PM_DEBUG is set, the core should warn about drivers not > > > > having .suspend or .resume routines. > > > > > > The only problem with that is, not everyone turns on CONFIG_PM_DEBUG. > > > CONFIG_PM instead? > > > > Well, I can imagine a driver that doesn't need a .suspend routine, for example, > > and I don't think we should make the kernel always complain about that. > > How about... > > #ifdef CONFIG_PM_PARANOIA > static int empty_suspend_routine(struct device *dev, pm_message_t state) > { > return 0; > } > #define empty_suspend empty_suspend_routine > #else > #define empty_suspend NULL > #endif > > ... > > .suspend = empty_suspend; > ... > > > Then CONFIG_PM_PARANOIA can be enabled by default for now, and when we > eventually device it's not needed anymore, someone can submit a patch > replacing either turning off the CONFIG by default or removing the whole > mechanism. I think that would be tempting people to abuse it, for example by defining or undefining things just to quieten the warning. In my opinion the only way to make the warning go away should be to define a non-NULL .suspend (.resume) routine and that's why I don't think the warning should be mandatory. > > I think if someone doesn't set CONFIG_PM_DEBUG, we can ask him to set it > > and report back. > > We can, but the whole point to the suggestion was to make your life and > mine easier, as well as those of our users. > > Making it dependent on CONFIG_PM instead achieves that by: > - Saving you, I and distro people from having to tell their users to > enable the option (and how to) I think the distro people can patch their kernels to fit their needs. > - Saving the users the problem of going through all the steps, making > mistakes, potentially ending up with unbootable systems because they > make mistakes and so on. > > This way, they just need to look in dmesg. Well, IMO, if someone doesn't know how to compile and install the kernel, he'll be using a distro kernel anyway and then see above. Otherwise we can safely ask him to turn on whatever debugging options we need. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:26 ` Nigel Cunningham 2007-02-09 22:44 ` Rafael J. Wysocki @ 2007-02-10 0:25 ` Jeff Garzik 2007-02-10 6:43 ` Willy Tarreau 2007-02-10 7:15 ` Arjan van de Ven 2 siblings, 1 reply; 155+ messages in thread From: Jeff Garzik @ 2007-02-10 0:25 UTC (permalink / raw) To: nigel; +Cc: Arjan van de Ven, LKML Nigel Cunningham wrote: > Hi. > > On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: >> On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: >>> Hi. >>> >>> I don't think this is already done (feel free to correct me if I'm >>> wrong).. >>> >>> Can we start to NAK new drivers that don't have proper power management >>> implemented? There really is no excuse for writing a new driver and not >>> putting .suspend and .resume methods in anymore, is there? >> >> to a large degree, a device driver that doesn't suspend is better than >> no device driver at all, right? > > I'm not sure it is. It only makes more work for everyone else: We have > to help people figure out what causes their computer to fail to resume > (which can take quite a while), then get them them complain to driver > author, and the driver author has to submit patches to fix it. > > All of this is avoided if they'll just do it right in the first place. A lot of a lot of things could have been avoided, if they just did it right the first time. I think it's more valuable to users to get a basic network driver that pings or a basic ATA driver that reads/writes, than peripheral issues like suspend/resume. Certainly we should ask for it, but it shouldn't be a merge-stopper. Jeff ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 0:25 ` Jeff Garzik @ 2007-02-10 6:43 ` Willy Tarreau 2007-02-10 23:52 ` Tilman Schmidt 0 siblings, 1 reply; 155+ messages in thread From: Willy Tarreau @ 2007-02-10 6:43 UTC (permalink / raw) To: Jeff Garzik; +Cc: nigel, Arjan van de Ven, LKML On Fri, Feb 09, 2007 at 07:25:34PM -0500, Jeff Garzik wrote: > Nigel Cunningham wrote: > >Hi. > > > >On Fri, 2007-02-09 at 23:17 +0100, Arjan van de Ven wrote: > >>On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: > >>>Hi. > >>> > >>>I don't think this is already done (feel free to correct me if I'm > >>>wrong).. > >>> > >>>Can we start to NAK new drivers that don't have proper power management > >>>implemented? There really is no excuse for writing a new driver and not > >>>putting .suspend and .resume methods in anymore, is there? > >> > >>to a large degree, a device driver that doesn't suspend is better than > >>no device driver at all, right? > > > >I'm not sure it is. It only makes more work for everyone else: We have > >to help people figure out what causes their computer to fail to resume > >(which can take quite a while), then get them them complain to driver > >author, and the driver author has to submit patches to fix it. > > > >All of this is avoided if they'll just do it right in the first place. > > A lot of a lot of things could have been avoided, if they just did it > right the first time. > > I think it's more valuable to users to get a basic network driver that > pings or a basic ATA driver that reads/writes, than peripheral issues > like suspend/resume. 100% agreed. I've been used to a notebook (VAIO) which did not correctly shut down, and did not support reboot. Now the one I have behaves normally on both features. I've never ever felt the need for suspend/resume, that I've always attributed to "geeks" requirements. I had to debug the shutdown code myself for the previous notebook, and discovered that it was caused by bugs in the ACPI state transitions for suspend and such fancy features. I would really have prefered that the people writing the ACPI code had focused first on power-on/ power-off before the rest. > Certainly we should ask for it, but it shouldn't be a merge-stopper. I think we should even proceed in the opposite direction : refuse to suspend if at least one driver does not support the feature, and enumerate the faulty drivers on the console. While I agree that a machine which resumes in a bad state is not funny at all to debug, at least when the user expects his notebook to suspend and sees that it refuses, he can complain about the drivers which do not support it, and can even unload them first if unneeded. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 6:43 ` Willy Tarreau @ 2007-02-10 23:52 ` Tilman Schmidt 0 siblings, 0 replies; 155+ messages in thread From: Tilman Schmidt @ 2007-02-10 23:52 UTC (permalink / raw) To: Willy Tarreau; +Cc: Jeff Garzik, nigel, Arjan van de Ven, LKML [-- Attachment #1: Type: text/plain, Size: 1073 bytes --] Am 10.02.2007 07:43 schrieb Willy Tarreau: > On Fri, Feb 09, 2007 at 07:25:34PM -0500, Jeff Garzik wrote: >>>> On Sat, 2007-02-10 at 08:57 +1100, Nigel Cunningham wrote: >>>>> Can we start to NAK new drivers that don't have proper power management >>>>> implemented? [...] >> Certainly we should ask for it, but it shouldn't be a merge-stopper. > > I think we should even proceed in the opposite direction : refuse to suspend > if at least one driver does not support the feature, and enumerate the > faulty drivers on the console. While I agree that a machine which resumes > in a bad state is not funny at all to debug, at least when the user expects > his notebook to suspend and sees that it refuses, he can complain about the > drivers which do not support it, and can even unload them first if unneeded. I agree wholeheartedly. That's the correct way to handle this. -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany - In theory, there is no difference between theory and practice. In practice, there is. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 253 bytes --] ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:26 ` Nigel Cunningham 2007-02-09 22:44 ` Rafael J. Wysocki 2007-02-10 0:25 ` Jeff Garzik @ 2007-02-10 7:15 ` Arjan van de Ven 2 siblings, 0 replies; 155+ messages in thread From: Arjan van de Ven @ 2007-02-10 7:15 UTC (permalink / raw) To: nigel; +Cc: LKML > > > > to a large degree, a device driver that doesn't suspend is better than > > no device driver at all, right? > > I'm not sure it is. It only makes more work for everyone else: We have > to help people figure out what causes their computer to fail to resume > (which can take quite a while), so we make the kernel printk on suspend if there are devices without suspend/resume. Heck, make a config option that prints that at modprobe time. -- 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 ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 22:17 ` Arjan van de Ven 2007-02-09 22:26 ` Nigel Cunningham @ 2007-02-10 19:38 ` Pavel Machek 2007-02-10 22:20 ` Rafael J. Wysocki 1 sibling, 1 reply; 155+ messages in thread From: Pavel Machek @ 2007-02-10 19:38 UTC (permalink / raw) To: Arjan van de Ven; +Cc: nigel, LKML Hi! > > I don't think this is already done (feel free to correct me if I'm > > wrong).. > > > > Can we start to NAK new drivers that don't have proper power management > > implemented? There really is no excuse for writing a new driver and not > > putting .suspend and .resume methods in anymore, is there? > > to a large degree, a device driver that doesn't suspend is better than > no device driver at all, right? > now.. if you want to make the core warn about it, that's very fair Well, driver that is broken on SMP is arguably better than no driver at all, yet we'd probably avoid merging that. It would be nice to start including suspend in 'must work' list... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 19:38 ` Pavel Machek @ 2007-02-10 22:20 ` Rafael J. Wysocki 2007-02-10 22:37 ` Nigel Cunningham ` (2 more replies) 0 siblings, 3 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-10 22:20 UTC (permalink / raw) To: Pavel Machek; +Cc: Arjan van de Ven, nigel, LKML Hi, On Saturday, 10 February 2007 20:38, Pavel Machek wrote: > Hi! > > > > I don't think this is already done (feel free to correct me if I'm > > > wrong).. > > > > > > Can we start to NAK new drivers that don't have proper power management > > > implemented? There really is no excuse for writing a new driver and not > > > putting .suspend and .resume methods in anymore, is there? > > > > to a large degree, a device driver that doesn't suspend is better than > > no device driver at all, right? > > now.. if you want to make the core warn about it, that's very fair > > Well, driver that is broken on SMP is arguably better than no driver > at all, yet we'd probably avoid merging that. It would be nice to > start including suspend in 'must work' list... What about this: "If the device requires that, implement .suspend and .resume or at least define .suspend that will always return -ENOSYS (then people will know they have to unload the driver before the suspend). Similarly, if you aren't sure whether or not the device requires .suspend and .resume, define .suspend that will always return -ENOSYS." Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 22:20 ` Rafael J. Wysocki @ 2007-02-10 22:37 ` Nigel Cunningham 2007-02-10 23:45 ` Tilman Schmidt 2007-02-11 6:46 ` Willy Tarreau 2007-02-11 19:42 ` Pavel Machek 2007-02-12 8:49 ` Geert Uytterhoeven 2 siblings, 2 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 22:37 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Arjan van de Ven, LKML Hi. On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: > Hi, > > On Saturday, 10 February 2007 20:38, Pavel Machek wrote: > > Hi! > > > > > > I don't think this is already done (feel free to correct me if I'm > > > > wrong).. > > > > > > > > Can we start to NAK new drivers that don't have proper power management > > > > implemented? There really is no excuse for writing a new driver and not > > > > putting .suspend and .resume methods in anymore, is there? > > > > > > to a large degree, a device driver that doesn't suspend is better than > > > no device driver at all, right? > > > now.. if you want to make the core warn about it, that's very fair > > > > Well, driver that is broken on SMP is arguably better than no driver > > at all, yet we'd probably avoid merging that. It would be nice to > > start including suspend in 'must work' list... > > What about this: > > "If the device requires that, implement .suspend and .resume or at least > define .suspend that will always return -ENOSYS (then people will know they > have to unload the driver before the suspend). Similarly, if you aren't sure > whether or not the device requires .suspend and .resume, define .suspend that > will always return -ENOSYS." If your device requires power management, and you know it requires power management, why not just implement power management? Doing -ENOSYS instead is like saying -ESPAMMEBECAUSEIMLAZY. Let me put it another way: People keep talking about Linux being ready for the desktop. To me at least (but I dare say for lots of other people too), being ready for the desktop means that things just work, without having to recompile kernels or bug driver authors or wait twelve months. And it means that doing a bare minimum isn't enough. We keep claiming that Open Source is better than Proprietary software. If we accept half-pie jobs of implementing support for anything - driver power management support or hibernation support or whatever - as 'good enough', we're undercutting that argument. Linux's power management support should - as far as we're able - be at least as good as that other operating system's and preferably way, way better. -ENOSYS is just not acceptable. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 22:37 ` Nigel Cunningham @ 2007-02-10 23:45 ` Tilman Schmidt 2007-02-11 0:27 ` Rafael J. Wysocki 2007-02-11 22:37 ` Nigel Cunningham 2007-02-11 6:46 ` Willy Tarreau 1 sibling, 2 replies; 155+ messages in thread From: Tilman Schmidt @ 2007-02-10 23:45 UTC (permalink / raw) To: nigel; +Cc: Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML [-- Attachment #1: Type: text/plain, Size: 2364 bytes --] Am 10.02.2007 23:37 schrieb Nigel Cunningham: > If your device requires power management, and you know it requires power > management, why not just implement power management? Doing -ENOSYS > instead is like saying -ESPAMMEBECAUSEIMLAZY. Like it or not, power management is far from trivial, and people writing device drivers have limited resources. Calling them lazy does not help that in the least. If you try to put pressure on them by refusing to merge their work as long as it doesn't provide this or that functionality, you *may* end up with a few drivers having that functionality which otherwise wouldn't, but you *will* also end up with a number of drivers never making it into the kernel because their authors just have to give up. Also, in your argument you neglected a few cases: - What if my device does not require power management? - What if I don't know whether my device requires power management? - What if I know my device would require power management, but don't know how to implement it? > Let me put it another way: People keep talking about Linux being ready > for the desktop. To me at least (but I dare say for lots of other people > too), being ready for the desktop means that things just work, without > having to recompile kernels or bug driver authors or wait twelve > months. Exactly. > And it means that doing a bare minimum isn't enough. We keep claiming > that Open Source is better than Proprietary software. If we accept > half-pie jobs of implementing support for anything - driver power > management support or hibernation support or whatever - as 'good > enough', we're undercutting that argument. Linux's power management > support should - as far as we're able - be at least as good as that > other operating system's and preferably way, way better. > > -ENOSYS is just not acceptable. Your argument falls down the moment you consider the alternative: not merging the driver means that the device won't work at all. (Given that out-of-tree drivers are actively discouraged, to put it mildly.) That's arguably farther from "desktop readiness" than a device not supporting power management. -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany - In theory, there is no difference between theory and practice. In practice, there is. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 253 bytes --] ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 23:45 ` Tilman Schmidt @ 2007-02-11 0:27 ` Rafael J. Wysocki 2007-02-11 22:41 ` Nigel Cunningham 2007-02-11 22:37 ` Nigel Cunningham 1 sibling, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 0:27 UTC (permalink / raw) To: Tilman Schmidt; +Cc: nigel, Pavel Machek, Arjan van de Ven, LKML On Sunday, 11 February 2007 00:45, Tilman Schmidt wrote: > Am 10.02.2007 23:37 schrieb Nigel Cunningham: > > If your device requires power management, and you know it requires power > > management, why not just implement power management? Doing -ENOSYS > > instead is like saying -ESPAMMEBECAUSEIMLAZY. > > Like it or not, power management is far from trivial, and people > writing device drivers have limited resources. Calling them lazy > does not help that in the least. If you try to put pressure on them > by refusing to merge their work as long as it doesn't provide this > or that functionality, you *may* end up with a few drivers having > that functionality which otherwise wouldn't, but you *will* also > end up with a number of drivers never making it into the kernel > because their authors just have to give up. > > Also, in your argument you neglected a few cases: > - What if my device does not require power management? > - What if I don't know whether my device requires power management? > - What if I know my device would require power management, but don't > know how to implement it? Plus: - What if I'm planning to implement the power managemet, but not just right now? > > Let me put it another way: People keep talking about Linux being ready > > for the desktop. To me at least (but I dare say for lots of other people > > too), being ready for the desktop means that things just work, without > > having to recompile kernels or bug driver authors or wait twelve > > months. > > Exactly. > > > And it means that doing a bare minimum isn't enough. We keep claiming > > that Open Source is better than Proprietary software. If we accept > > half-pie jobs of implementing support for anything - driver power > > management support or hibernation support or whatever - as 'good > > enough', we're undercutting that argument. Linux's power management > > support should - as far as we're able - be at least as good as that > > other operating system's and preferably way, way better. > > > > -ENOSYS is just not acceptable. > > Your argument falls down the moment you consider the alternative: > not merging the driver means that the device won't work at all. > (Given that out-of-tree drivers are actively discouraged, to put > it mildly.) That's arguably farther from "desktop readiness" than > a device not supporting power management. Agreed. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 0:27 ` Rafael J. Wysocki @ 2007-02-11 22:41 ` Nigel Cunningham 2007-02-13 15:55 ` Mark Lord 0 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 22:41 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Tilman Schmidt, Pavel Machek, Arjan van de Ven, LKML On Sun, 2007-02-11 at 01:27 +0100, Rafael J. Wysocki wrote: > On Sunday, 11 February 2007 00:45, Tilman Schmidt wrote: > > Am 10.02.2007 23:37 schrieb Nigel Cunningham: > > > If your device requires power management, and you know it requires power > > > management, why not just implement power management? Doing -ENOSYS > > > instead is like saying -ESPAMMEBECAUSEIMLAZY. > > > > Like it or not, power management is far from trivial, and people > > writing device drivers have limited resources. Calling them lazy > > does not help that in the least. If you try to put pressure on them > > by refusing to merge their work as long as it doesn't provide this > > or that functionality, you *may* end up with a few drivers having > > that functionality which otherwise wouldn't, but you *will* also > > end up with a number of drivers never making it into the kernel > > because their authors just have to give up. > > > > Also, in your argument you neglected a few cases: > > - What if my device does not require power management? > > - What if I don't know whether my device requires power management? > > - What if I know my device would require power management, but don't > > know how to implement it? > > Plus: > - What if I'm planning to implement the power managemet, but not just right > now? Why not right now? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:41 ` Nigel Cunningham @ 2007-02-13 15:55 ` Mark Lord 2007-02-13 16:06 ` Christoph Hellwig 0 siblings, 1 reply; 155+ messages in thread From: Mark Lord @ 2007-02-13 15:55 UTC (permalink / raw) To: nigel Cc: Rafael J. Wysocki, Tilman Schmidt, Pavel Machek, Arjan van de Ven, LKML Nigel Cunningham wrote: > On Sun, 2007-02-11 at 01:27 +0100, Rafael J. Wysocki wrote: >> Plus: >> - What if I'm planning to implement the power managemet, but not just right >> now? > > Why not right now? LKML is much more receptive to drivers that follow the "release early, release often" mantra. Which means we really have to be more accomodating of drivers that start out simple, and then gain all of the non-essential capabilities gradually over time. Simple observation here shows much more hostility :) to drivers that are simply "presented" as a complete whole. Often for good reason -- starting out with a framework and then adding the rest bit by bit allows for much better peer review and feedback. And not all devices / situations need power management, and lack of documentation on the hardware often prevents us from implementing it at the outset. Cheers ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-13 15:55 ` Mark Lord @ 2007-02-13 16:06 ` Christoph Hellwig 0 siblings, 0 replies; 155+ messages in thread From: Christoph Hellwig @ 2007-02-13 16:06 UTC (permalink / raw) To: Mark Lord Cc: nigel, Rafael J. Wysocki, Tilman Schmidt, Pavel Machek, Arjan van de Ven, LKML On Tue, Feb 13, 2007 at 10:55:18AM -0500, Mark Lord wrote: > LKML is much more receptive to drivers that follow > the "release early, release often" mantra. Exactly. > Which means we really have to be more accomodating of > drivers that start out simple, and then gain all of the > non-essential capabilities gradually over time. We usually are, the endless flamewar lurkers might not :) > > Simple observation here shows much more hostility :) > to drivers that are simply "presented" as a complete whole. > Often for good reason -- starting out with a framework > and then adding the rest bit by bit allows for much better > peer review and feedback. *nod* > And not all devices / situations need power management, > and lack of documentation on the hardware often prevents > us from implementing it at the outset. *nod* So can be use Mark's excellent post as closing of this utterly useless thread and go on to real work now? ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 23:45 ` Tilman Schmidt 2007-02-11 0:27 ` Rafael J. Wysocki @ 2007-02-11 22:37 ` Nigel Cunningham 2007-02-12 0:10 ` Tilman Schmidt 1 sibling, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 22:37 UTC (permalink / raw) To: Tilman Schmidt; +Cc: Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML Hi. On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote: > Am 10.02.2007 23:37 schrieb Nigel Cunningham: > > If your device requires power management, and you know it requires power > > management, why not just implement power management? Doing -ENOSYS > > instead is like saying -ESPAMMEBECAUSEIMLAZY. > > Like it or not, power management is far from trivial, and people > writing device drivers have limited resources. Calling them lazy > does not help that in the least. If you try to put pressure on them > by refusing to merge their work as long as it doesn't provide this > or that functionality, you *may* end up with a few drivers having > that functionality which otherwise wouldn't, but you *will* also > end up with a number of drivers never making it into the kernel > because their authors just have to give up. It's not that complex. All we're really talking about is a bit of extra code to cleanup and configure hardware state; things that the driver author already knows how to do. S3 might require a bit more initialisation if firmware needs to be reloaded or more extensive configuration needs to be done, but if there's firmware to be loaded, there is a reasonably good probability that we loaded it from Linux to start with anyway. > Also, in your argument you neglected a few cases: > - What if my device does not require power management? Then you as a generic routine that does nothing but return success (potentially shared with other drivers that are in the same situation). > - What if I don't know whether my device requires power management? The questions are straight forward: Is there hardware state that needs to be configured if you've just booted the computer and nothing else has touched it? If so, that needs to be done in a resume method. Do you need to clean up state prior to doing the things in the resume method, or otherwise do things to quiesce the driver? If so, they will need to be done in the suspend method. The result will be roughly similar to what you do for module load/unload, except maybe less complete in some cases. > - What if I know my device would require power management, but don't > know how to implement it? I've just told you above :) Now you know! > > Let me put it another way: People keep talking about Linux being ready > > for the desktop. To me at least (but I dare say for lots of other people > > too), being ready for the desktop means that things just work, without > > having to recompile kernels or bug driver authors or wait twelve > > months. > > Exactly. > > > And it means that doing a bare minimum isn't enough. We keep claiming > > that Open Source is better than Proprietary software. If we accept > > half-pie jobs of implementing support for anything - driver power > > management support or hibernation support or whatever - as 'good > > enough', we're undercutting that argument. Linux's power management > > support should - as far as we're able - be at least as good as that > > other operating system's and preferably way, way better. > > > > -ENOSYS is just not acceptable. > > Your argument falls down the moment you consider the alternative: > not merging the driver means that the device won't work at all. > (Given that out-of-tree drivers are actively discouraged, to put > it mildly.) That's arguably farther from "desktop readiness" than > a device not supporting power management. I disagree (but I would, of course!). If we apply your logic consistently, we should merge the driver as soon as any code is written for it (anything is better than nothing). I'm simply arguing that a driver that handling suspend and resume should be as much of a requirement as not causing memory corruption or such like are. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:37 ` Nigel Cunningham @ 2007-02-12 0:10 ` Tilman Schmidt 2007-02-12 0:20 ` Rafael J. Wysocki 2007-02-12 4:08 ` Nigel Cunningham 0 siblings, 2 replies; 155+ messages in thread From: Tilman Schmidt @ 2007-02-12 0:10 UTC (permalink / raw) To: nigel; +Cc: Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML [-- Attachment #1: Type: text/plain, Size: 4387 bytes --] Hi, Am 11.02.2007 23:37 schrieb Nigel Cunningham: > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote: >> Am 10.02.2007 23:37 schrieb Nigel Cunningham: >>> If your device requires power management, and you know it requires power >>> management, why not just implement power management? [...] >> Like it or not, power management is far from trivial, and people >> writing device drivers have limited resources. [...] > It's not that complex. All we're really talking about is a bit of extra > code to cleanup and configure hardware state; things that the driver > author already knows how to do. S3 might require a bit more > initialisation if firmware needs to be reloaded or more extensive > configuration needs to be done, but if there's firmware to be loaded, > there is a reasonably good probability that we loaded it from Linux to > start with anyway. You are assuming a perfect world where driver authors have complete knowledge of their devices. In reality, many drivers (including those I have the mixed pleasure of maintaining) are based at least in part on reverse engineering, and managing power states may well fall into the domain of things not yet sufficiently reverse engineered. >> Also, in your argument you neglected a few cases: >> - What if my device does not require power management? > > Then you as a generic routine that does nothing but return success > (potentially shared with other drivers that are in the same situation). But if I just write an empty routine like that I open myself up to criticism along the lines of "writing dummy routines just in order to shut up kernel warnings". BTDT. >> - What if I don't know whether my device requires power management? > > The questions are straight forward: Is there hardware state that needs > to be configured if you've just booted the computer and nothing else has > touched it? If so, that needs to be done in a resume method. Do you need > to clean up state prior to doing the things in the resume method, or > otherwise do things to quiesce the driver? If so, they will need to be > done in the suspend method. The result will be roughly similar to what > you do for module load/unload, except maybe less complete in some cases. I don't doubt your basic assessment. However it doesn't translate that easily into a real implementation. In my case, I maintain a USB driver, so I have to deal with USB specifics of suspend/resume which happen not to be that well documented. My driver provides an isdn4linux device but isdn4linux knows nothing about suspend/resume so I am on my own on how to reconcile the two. The device itself, though in turn far from trivial, is actually the least of my worries. >> - What if I know my device would require power management, but don't >> know how to implement it? > > I've just told you above :) Now you know! No I don't. See above. >>> -ENOSYS is just not acceptable. >> Your argument falls down the moment you consider the alternative: >> not merging the driver means that the device won't work at all. >> (Given that out-of-tree drivers are actively discouraged, to put >> it mildly.) That's arguably farther from "desktop readiness" than >> a device not supporting power management. > > I disagree (but I would, of course!). If we apply your logic > consistently, we should merge the driver as soon as any code is written > for it (anything is better than nothing). I'm simply arguing that a > driver that handling suspend and resume should be as much of a > requirement as not causing memory corruption or such like are. Well, that's a common fallacy about applying any logic consistently. There's a continuum of usefulness from "hardly works at all" through "causes random memory corruption", "doesn't support power management", and "does not support some esoteric protocol variety no one ever heard of anyways" up to "supports any and all uses to which anyone could possibly want to put the device". I would argue that "doesn't support power management" is *much* farther up that ladder than, for example, "causes random memory corruption". Regards, Tilman -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 253 bytes --] ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 0:10 ` Tilman Schmidt @ 2007-02-12 0:20 ` Rafael J. Wysocki 2007-02-12 4:08 ` Nigel Cunningham 1 sibling, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 0:20 UTC (permalink / raw) To: Tilman Schmidt; +Cc: nigel, Pavel Machek, Arjan van de Ven, LKML Hi, On Monday, 12 February 2007 01:10, Tilman Schmidt wrote: > Hi, > > Am 11.02.2007 23:37 schrieb Nigel Cunningham: > > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote: > >> Am 10.02.2007 23:37 schrieb Nigel Cunningham: > >>> If your device requires power management, and you know it requires power > >>> management, why not just implement power management? [...] > >> Like it or not, power management is far from trivial, and people > >> writing device drivers have limited resources. [...] > > It's not that complex. All we're really talking about is a bit of extra > > code to cleanup and configure hardware state; things that the driver > > author already knows how to do. S3 might require a bit more > > initialisation if firmware needs to be reloaded or more extensive > > configuration needs to be done, but if there's firmware to be loaded, > > there is a reasonably good probability that we loaded it from Linux to > > start with anyway. > > You are assuming a perfect world where driver authors have complete > knowledge of their devices. In reality, many drivers (including > those I have the mixed pleasure of maintaining) are based at least > in part on reverse engineering, and managing power states may well > fall into the domain of things not yet sufficiently reverse > engineered. Exactly. > >> Also, in your argument you neglected a few cases: > >> - What if my device does not require power management? > > > > Then you as a generic routine that does nothing but return success > > (potentially shared with other drivers that are in the same situation). > > But if I just write an empty routine like that I open myself up to > criticism along the lines of "writing dummy routines just in order > to shut up kernel warnings". BTDT. Well, for me the design that required driver authors to write empty routines returning success, would be bad. > >> - What if I don't know whether my device requires power management? > > > > The questions are straight forward: Is there hardware state that needs > > to be configured if you've just booted the computer and nothing else has > > touched it? If so, that needs to be done in a resume method. Do you need > > to clean up state prior to doing the things in the resume method, or > > otherwise do things to quiesce the driver? If so, they will need to be > > done in the suspend method. The result will be roughly similar to what > > you do for module load/unload, except maybe less complete in some cases. > > I don't doubt your basic assessment. However it doesn't translate that > easily into a real implementation. In my case, I maintain a USB driver, > so I have to deal with USB specifics of suspend/resume which happen not > to be that well documented. My driver provides an isdn4linux device but > isdn4linux knows nothing about suspend/resume so I am on my own on how > to reconcile the two. The device itself, though in turn far from trivial, > is actually the least of my worries. > > >> - What if I know my device would require power management, but don't > >> know how to implement it? > > > > I've just told you above :) Now you know! > > No I don't. See above. > > >>> -ENOSYS is just not acceptable. > >> Your argument falls down the moment you consider the alternative: > >> not merging the driver means that the device won't work at all. > >> (Given that out-of-tree drivers are actively discouraged, to put > >> it mildly.) That's arguably farther from "desktop readiness" than > >> a device not supporting power management. > > > > I disagree (but I would, of course!). If we apply your logic > > consistently, we should merge the driver as soon as any code is written > > for it (anything is better than nothing). I'm simply arguing that a > > driver that handling suspend and resume should be as much of a > > requirement as not causing memory corruption or such like are. > > Well, that's a common fallacy about applying any logic consistently. > There's a continuum of usefulness from "hardly works at all" through > "causes random memory corruption", "doesn't support power management", > and "does not support some esoteric protocol variety no one ever heard > of anyways" up to "supports any and all uses to which anyone could > possibly want to put the device". I would argue that "doesn't support > power management" is *much* farther up that ladder than, for example, > "causes random memory corruption". I agree with that. Moreover, I think that the suspend/resume support is something you _can_ _live_ without while living, for instance, without networking at all would be difficult these days. Therefore I would certainly accept the driver that didn't support suspend/resume for my network adapter and I'd be happy to use it anyway. On the other hand, it would be nice if that driver did something that would prevent the system from suspending when it's loaded, just in case. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 0:10 ` Tilman Schmidt 2007-02-12 0:20 ` Rafael J. Wysocki @ 2007-02-12 4:08 ` Nigel Cunningham 2007-02-12 20:06 ` Rafael J. Wysocki 1 sibling, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-12 4:08 UTC (permalink / raw) To: Tilman Schmidt; +Cc: Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML Howdy! On Mon, 2007-02-12 at 01:10 +0100, Tilman Schmidt wrote: > Hi, > > Am 11.02.2007 23:37 schrieb Nigel Cunningham: > > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote: > >> Am 10.02.2007 23:37 schrieb Nigel Cunningham: > >>> If your device requires power management, and you know it requires power > >>> management, why not just implement power management? [...] > >> Like it or not, power management is far from trivial, and people > >> writing device drivers have limited resources. [...] > > It's not that complex. All we're really talking about is a bit of extra > > code to cleanup and configure hardware state; things that the driver > > author already knows how to do. S3 might require a bit more > > initialisation if firmware needs to be reloaded or more extensive > > configuration needs to be done, but if there's firmware to be loaded, > > there is a reasonably good probability that we loaded it from Linux to > > start with anyway. > > You are assuming a perfect world where driver authors have complete > knowledge of their devices. In reality, many drivers (including > those I have the mixed pleasure of maintaining) are based at least > in part on reverse engineering, and managing power states may well > fall into the domain of things not yet sufficiently reverse > engineered. Nope. I'm assuming that the driver author knows what needs to be done to get the driver out of whatever state the BIOS puts it in to start with, and into an operational state, and that they therefore also know what needs to be done to take it out of the operational state again. I'm admitting that there's also another state - the post suspend-to-ram driver state - that they may not know how to deal with. But for suspend-to-disk, if you know how to get the driver to work in the first place, you know enough to stop it working (.suspend) and start it up again (.resume) for the hibernate case at least. I'm not assuming that you know enough to be able to put the driver into a low state and get it out again. This is definitely preferable, and at least possibly essential for suspend to ram, but for some unknown reason I'm quite hibernation focused, and for that, just the above is sufficient. > >> Also, in your argument you neglected a few cases: > >> - What if my device does not require power management? > > > > Then you as a generic routine that does nothing but return success > > (potentially shared with other drivers that are in the same situation). > > But if I just write an empty routine like that I open myself up to > criticism along the lines of "writing dummy routines just in order > to shut up kernel warnings". BTDT. Well, it might not be completely empty. I think someone already pointed out that there's a minimal workset for the pci bus that pci drivers would want to invoke. But we wouldn't (rightly) accuse you of such things if we decided that the policy was "Every driver ought to have a resume routine, even if it's just a minimal I-just-work route". > >> - What if I don't know whether my device requires power management? > > > > The questions are straight forward: Is there hardware state that needs > > to be configured if you've just booted the computer and nothing else has > > touched it? If so, that needs to be done in a resume method. Do you need > > to clean up state prior to doing the things in the resume method, or > > otherwise do things to quiesce the driver? If so, they will need to be > > done in the suspend method. The result will be roughly similar to what > > you do for module load/unload, except maybe less complete in some cases. > > I don't doubt your basic assessment. However it doesn't translate that > easily into a real implementation. In my case, I maintain a USB driver, > so I have to deal with USB specifics of suspend/resume which happen not > to be that well documented. My driver provides an isdn4linux device but > isdn4linux knows nothing about suspend/resume so I am on my own on how > to reconcile the two. The device itself, though in turn far from trivial, > is actually the least of my worries. Mmm, so that's a case where we need to prod those who write documentation and bus support first. You're probably closer! :) Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 4:08 ` Nigel Cunningham @ 2007-02-12 20:06 ` Rafael J. Wysocki 2007-02-12 22:38 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 20:06 UTC (permalink / raw) To: nigel; +Cc: Tilman Schmidt, Pavel Machek, Arjan van de Ven, LKML On Monday, 12 February 2007 05:08, Nigel Cunningham wrote: > Howdy! > > On Mon, 2007-02-12 at 01:10 +0100, Tilman Schmidt wrote: > > Hi, > > > > Am 11.02.2007 23:37 schrieb Nigel Cunningham: > > > On Sun, 2007-02-11 at 00:45 +0100, Tilman Schmidt wrote: > > >> Am 10.02.2007 23:37 schrieb Nigel Cunningham: > > >>> If your device requires power management, and you know it requires power > > >>> management, why not just implement power management? [...] > > >> Like it or not, power management is far from trivial, and people > > >> writing device drivers have limited resources. [...] > > > It's not that complex. All we're really talking about is a bit of extra > > > code to cleanup and configure hardware state; things that the driver > > > author already knows how to do. S3 might require a bit more > > > initialisation if firmware needs to be reloaded or more extensive > > > configuration needs to be done, but if there's firmware to be loaded, > > > there is a reasonably good probability that we loaded it from Linux to > > > start with anyway. > > > > You are assuming a perfect world where driver authors have complete > > knowledge of their devices. In reality, many drivers (including > > those I have the mixed pleasure of maintaining) are based at least > > in part on reverse engineering, and managing power states may well > > fall into the domain of things not yet sufficiently reverse > > engineered. > > Nope. I'm assuming that the driver author knows what needs to be done to > get the driver out of whatever state the BIOS puts it in to start with, > and into an operational state, and that they therefore also know what > needs to be done to take it out of the operational state again. I'm > admitting that there's also another state - the post suspend-to-ram > driver state - that they may not know how to deal with. But for > suspend-to-disk, if you know how to get the driver to work in the first > place, you know enough to stop it working (.suspend) and start it up > again (.resume) for the hibernate case at least. We're talking about _both_ the STR and STD. The drivers that have problems with the STR cannot be regarded as suspend/resume-safe IMO. > I'm not assuming that you know enough to be able to put the driver into > a low state and get it out again. This is definitely preferable, and at > least possibly essential for suspend to ram, but for some unknown reason > I'm quite hibernation focused, and for that, just the above is > sufficient. Please take the STR into consideration too. After all we use the same suspend/resume code for both STD and STR so it should work with both. If it doesn't work with one of them, we have a problem. > > >> Also, in your argument you neglected a few cases: > > >> - What if my device does not require power management? > > > > > > Then you as a generic routine that does nothing but return success > > > (potentially shared with other drivers that are in the same situation). > > > > But if I just write an empty routine like that I open myself up to > > criticism along the lines of "writing dummy routines just in order > > to shut up kernel warnings". BTDT. > > Well, it might not be completely empty. I think someone already pointed > out that there's a minimal workset for the pci bus that pci drivers > would want to invoke. But we wouldn't (rightly) accuse you of such > things if we decided that the policy was "Every driver ought to have a > resume routine, even if it's just a minimal I-just-work route". I'm still thinking that would be wasteful. I think there are more drivers that work than there are drivers that don't work. > > >> - What if I don't know whether my device requires power management? > > > > > > The questions are straight forward: Is there hardware state that needs > > > to be configured if you've just booted the computer and nothing else has > > > touched it? If so, that needs to be done in a resume method. Do you need > > > to clean up state prior to doing the things in the resume method, or > > > otherwise do things to quiesce the driver? If so, they will need to be > > > done in the suspend method. The result will be roughly similar to what > > > you do for module load/unload, except maybe less complete in some cases. > > > > I don't doubt your basic assessment. However it doesn't translate that > > easily into a real implementation. In my case, I maintain a USB driver, > > so I have to deal with USB specifics of suspend/resume which happen not > > to be that well documented. My driver provides an isdn4linux device but > > isdn4linux knows nothing about suspend/resume so I am on my own on how > > to reconcile the two. The device itself, though in turn far from trivial, > > is actually the least of my worries. > > Mmm, so that's a case where we need to prod those who write > documentation and bus support first. You're probably closer! :) Actually, the lack of documentation is a major problem that we all should try to fix in the first place. Unfortunately the code has been recently changing quite often, so that's difficult. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 20:06 ` Rafael J. Wysocki @ 2007-02-12 22:38 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-12 22:38 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Tilman Schmidt, Pavel Machek, Arjan van de Ven, LKML Hi. On Mon, 2007-02-12 at 21:06 +0100, Rafael J. Wysocki wrote: > On Monday, 12 February 2007 05:08, Nigel Cunningham wrote: > > Nope. I'm assuming that the driver author knows what needs to be done to > > get the driver out of whatever state the BIOS puts it in to start with, > > and into an operational state, and that they therefore also know what > > needs to be done to take it out of the operational state again. I'm > > admitting that there's also another state - the post suspend-to-ram > > driver state - that they may not know how to deal with. But for > > suspend-to-disk, if you know how to get the driver to work in the first > > place, you know enough to stop it working (.suspend) and start it up > > again (.resume) for the hibernate case at least. > > We're talking about _both_ the STR and STD. The drivers that have problems > with the STR cannot be regarded as suspend/resume-safe IMO. Yeah, I'm not disagreeing at all. I'm just admitting my bias toward the bit I concentrate on more. [...] > > Mmm, so that's a case where we need to prod those who write > > documentation and bus support first. You're probably closer! :) > > Actually, the lack of documentation is a major problem that we all should > try to fix in the first place. Unfortunately the code has been recently > changing quite often, so that's difficult. Yeah. Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 22:37 ` Nigel Cunningham 2007-02-10 23:45 ` Tilman Schmidt @ 2007-02-11 6:46 ` Willy Tarreau 2007-02-11 13:04 ` Rafael J. Wysocki ` (3 more replies) 1 sibling, 4 replies; 155+ messages in thread From: Willy Tarreau @ 2007-02-11 6:46 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman Hi Nigel, On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: (...) > > What about this: > > > > "If the device requires that, implement .suspend and .resume or at least > > define .suspend that will always return -ENOSYS (then people will know they > > have to unload the driver before the suspend). Similarly, if you aren't sure > > whether or not the device requires .suspend and .resume, define .suspend that > > will always return -ENOSYS." > > If your device requires power management, and you know it requires power > management, why not just implement power management? Doing -ENOSYS > instead is like saying -ESPAMMEBECAUSEIMLAZY. No, it means "Not implemented because I don't want to screw that driver with something I'm not expert in". And it also means "Other people will quickly notice it and will know how to fix this if they really need it". > Let me put it another way: People keep talking about Linux being ready > for the desktop. To me at least (but I dare say for lots of other people > too), being ready for the desktop means that things just work, without > having to recompile kernels or bug driver authors or wait twelve > months. It's *one* usage of Linux. For this usage, you could also suggest to stop supporting UP kernels and always build everything with SMP enabled since more and more often, people will use multi-core systems. It will exempt the users from upgrading their kernels when they replace their CPU. We could also try to chase down all the drivers which do not correctly behave when the CPU switches to a lower frequency. > And it means that doing a bare minimum isn't enough. We keep claiming > that Open Source is better than Proprietary software. If we accept > half-pie jobs of implementing support for anything - driver power > management support or hibernation support or whatever - as 'good > enough', we're undercutting that argument. Linux's power management > support should - as far as we're able - be at least as good as that > other operating system's and preferably way, way better. > > -ENOSYS is just not acceptable. Nigel, don't take it as a personal offense, but I think it is a very centric view of Linux usages. Where I work, Linux is used a lot on servers and appliances. It is used for mail relays, HTTP proxies, anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, etc... Nobody would ever want to enable power management on those machines, let alone suspend which would cause a major havoc, would the system decide to enter suspend for any reason. Many people also have Linux on their notebooks, but as a dual-boot. You read the word ? "dual-boot". It means that they cleanly shutdown their system every time they don't use it anymore, and they won't know what OS they'll use next time. I've never heard anyone there complaining "oh, I'm fed up with this boring boot, I always have to wait 30 seconds when I need to do something, I wish I could suspend and resume". It is considered the normal way of using their PCs. So globally, those hundreds of notebooks, workstations and servers will not be customers of the suspend code any time soon. It would be a shame to deprive them from working drivers. You must just accept that a lot of people are not interested in your work. It's the same for all of us here. I know that a lot of people are not interested in 2.4 anymore and I'm perfectly fine with that. I'm not asking 2.6 driver authors to ensure that their driver is easy to backport for instance. What I really think would be a clean solution would be sort of a capability. Either the driver *is* suspend/resume-capable, and the system can be suspended. Or it is not, and the system must refuse to suspend. It should not be a problem to proceed like this because drivers which will not support suspend will mainly be those which will not have to. And if a user occasionnaly complains that one driver does not support it, at least you will have a good argument against its author to implement suspend. Best regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 6:46 ` Willy Tarreau @ 2007-02-11 13:04 ` Rafael J. Wysocki 2007-02-11 22:47 ` Nigel Cunningham ` (2 subsequent siblings) 3 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 13:04 UTC (permalink / raw) To: Willy Tarreau Cc: Nigel Cunningham, Pavel Machek, Arjan van de Ven, LKML, tilman On Sunday, 11 February 2007 07:46, Willy Tarreau wrote: [--snip--] > What I really think would be a clean solution would be sort of > a capability. Either the driver *is* suspend/resume-capable, and > the system can be suspended. Or it is not, and the system must > refuse to suspend. It should not be a problem to proceed like > this because drivers which will not support suspend will mainly > be those which will not have to. And if a user occasionnaly > complains that one driver does not support it, at least you will > have a good argument against its author to implement suspend. I agree, but the suspend/resume safeness has to be somehow indicated by the driver. We could add a flag for that, but it would require us to modify lots of existing drivers (unless there's something obvious I don't see). However, the driver can effectively say "I'm not suspend/resume-safe" by returning an error from .suspend(), in which case the system will automatically refuse to suspend. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 6:46 ` Willy Tarreau 2007-02-11 13:04 ` Rafael J. Wysocki @ 2007-02-11 22:47 ` Nigel Cunningham 2007-02-11 22:57 ` Manu Abraham 2007-02-12 12:59 ` Gerhard Mack 2007-02-12 13:51 ` Tino Keitel 3 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 22:47 UTC (permalink / raw) To: Willy Tarreau Cc: Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman Hi. On Sun, 2007-02-11 at 07:46 +0100, Willy Tarreau wrote: > Hi Nigel, > > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: > (...) > > > What about this: > > > > > > "If the device requires that, implement .suspend and .resume or at least > > > define .suspend that will always return -ENOSYS (then people will know they > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > whether or not the device requires .suspend and .resume, define .suspend that > > > will always return -ENOSYS." > > > > If your device requires power management, and you know it requires power > > management, why not just implement power management? Doing -ENOSYS > > instead is like saying -ESPAMMEBECAUSEIMLAZY. > > No, it means "Not implemented because I don't want to screw that driver with > something I'm not expert in". And it also means "Other people will quickly > notice it and will know how to fix this if they really need it". Ok, that was a bit rough. Sorry. At the same time though, we were talking about new drivers. If you know enough to implement the rest of the driver, surely you know enough to implement the power management part too. (See my previous comment about the similarities to module load/unload code). > > Let me put it another way: People keep talking about Linux being ready > > for the desktop. To me at least (but I dare say for lots of other people > > too), being ready for the desktop means that things just work, without > > having to recompile kernels or bug driver authors or wait twelve > > months. > > It's *one* usage of Linux. For this usage, you could also suggest to stop > supporting UP kernels and always build everything with SMP enabled since > more and more often, people will use multi-core systems. It will exempt > the users from upgrading their kernels when they replace their CPU. We > could also try to chase down all the drivers which do not correctly behave > when the CPU switches to a lower frequency. > > > And it means that doing a bare minimum isn't enough. We keep claiming > > that Open Source is better than Proprietary software. If we accept > > half-pie jobs of implementing support for anything - driver power > > management support or hibernation support or whatever - as 'good > > enough', we're undercutting that argument. Linux's power management > > support should - as far as we're able - be at least as good as that > > other operating system's and preferably way, way better. > > > > -ENOSYS is just not acceptable. > > Nigel, don't take it as a personal offense, but I think it is a very > centric view of Linux usages. Where I work, Linux is used a lot on > servers and appliances. It is used for mail relays, HTTP proxies, > anti-viruses, firewalls, routers, load balancers, UTM, SSH relays, > etc... Nobody would ever want to enable power management on those > machines, let alone suspend which would cause a major havoc, would > the system decide to enter suspend for any reason. I agree. > Many people also have Linux on their notebooks, but as a dual-boot. You > read the word ? "dual-boot". It means that they cleanly shutdown their > system every time they don't use it anymore, and they won't know what > OS they'll use next time. Not necessarily. I dual boot our desktop machine, and hibernate both, using grub to select with OS to run. > I've never heard anyone there complaining "oh, I'm fed up with this > boring boot, I always have to wait 30 seconds when I need to do > something, I wish I could suspend and resume". It is considered the > normal way of using their PCs. > > So globally, those hundreds of notebooks, workstations and servers > will not be customers of the suspend code any time soon. It would > be a shame to deprive them from working drivers. You must just > accept that a lot of people are not interested in your work. It's > the same for all of us here. I know that a lot of people are not > interested in 2.4 anymore and I'm perfectly fine with that. I'm > not asking 2.6 driver authors to ensure that their driver is easy > to backport for instance. Neither am I. I'm just asking that new drivers have power management as standard. > What I really think would be a clean solution would be sort of > a capability. Either the driver *is* suspend/resume-capable, and > the system can be suspended. Or it is not, and the system must > refuse to suspend. It should not be a problem to proceed like > this because drivers which will not support suspend will mainly > be those which will not have to. And if a user occasionnaly > complains that one driver does not support it, at least you will > have a good argument against its author to implement suspend. Yes, but why should the user have to complain to start with? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:47 ` Nigel Cunningham @ 2007-02-11 22:57 ` Manu Abraham 2007-02-11 23:20 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Manu Abraham @ 2007-02-11 22:57 UTC (permalink / raw) To: nigel Cc: Willy Tarreau, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > Neither am I. I'm just asking that new drivers have power management as > standard. What if the hardware doesn't support power management ? regards, manu ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 22:57 ` Manu Abraham @ 2007-02-11 23:20 ` Nigel Cunningham 2007-02-11 23:25 ` Manu Abraham 0 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:20 UTC (permalink / raw) To: Manu Abraham Cc: Willy Tarreau, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman Hi. On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote: > On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > > > Neither am I. I'm just asking that new drivers have power management as > > standard. > What if the hardware doesn't support power management ? You would still want to do the cleanup and configuration that you'd do for module load/unload. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:20 ` Nigel Cunningham @ 2007-02-11 23:25 ` Manu Abraham 2007-02-11 23:29 ` Pavel Machek ` (2 more replies) 0 siblings, 3 replies; 155+ messages in thread From: Manu Abraham @ 2007-02-11 23:25 UTC (permalink / raw) To: nigel Cc: Willy Tarreau, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > Hi. > > On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote: > > On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > > > > > Neither am I. I'm just asking that new drivers have power management as > > > standard. > > > What if the hardware doesn't support power management ? > > You would still want to do the cleanup and configuration that you'd do > for module load/unload. > By adding dummy functions, wouldn't that just look awkward ? regards, manu ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:25 ` Manu Abraham @ 2007-02-11 23:29 ` Pavel Machek 2007-02-11 23:33 ` Nigel Cunningham 2007-02-12 9:45 ` Arjan van de Ven 2 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 23:29 UTC (permalink / raw) To: Manu Abraham Cc: nigel, Willy Tarreau, Rafael J. Wysocki, Arjan van de Ven, LKML, tilman Hi! > >> > Neither am I. I'm just asking that new drivers have power management as > >> > standard. > > > >> What if the hardware doesn't support power management ? > > > >You would still want to do the cleanup and configuration that you'd do > >for module load/unload. > > > > By adding dummy functions, wouldn't that just look awkward ? No, it is not by dummy functions. Checkout how swsusp works; it needs no hw support, still it needs driver support. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:25 ` Manu Abraham 2007-02-11 23:29 ` Pavel Machek @ 2007-02-11 23:33 ` Nigel Cunningham 2007-02-12 16:52 ` Pavel Machek 2007-02-12 9:45 ` Arjan van de Ven 2 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:33 UTC (permalink / raw) To: Manu Abraham Cc: Willy Tarreau, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman Hi. On Mon, 2007-02-12 at 03:25 +0400, Manu Abraham wrote: > On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > > Hi. > > > > On Mon, 2007-02-12 at 02:57 +0400, Manu Abraham wrote: > > > On 2/12/07, Nigel Cunningham <nigel@nigel.suspend2.net> wrote: > > > > > > > Neither am I. I'm just asking that new drivers have power management as > > > > standard. > > > > > What if the hardware doesn't support power management ? > > > > You would still want to do the cleanup and configuration that you'd do > > for module load/unload. > > > By adding dummy functions, wouldn't that just look awkward ? If all you need to do is say 'I don't need to do anything' and we have a shared function that does that, all we're talking about doing is adding to your struct pci_device (or whatever) .resume = generic_empty_resume; To me at least, that doesn't look awkward, and says cleanly and clearly that you've checked things over and decided you know what's required. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:33 ` Nigel Cunningham @ 2007-02-12 16:52 ` Pavel Machek 2007-02-12 20:31 ` Rafael J. Wysocki 0 siblings, 1 reply; 155+ messages in thread From: Pavel Machek @ 2007-02-12 16:52 UTC (permalink / raw) To: Nigel Cunningham Cc: Manu Abraham, Willy Tarreau, Rafael J. Wysocki, Arjan van de Ven, LKML, tilman Hi! > > > > > Neither am I. I'm just asking that new drivers have power management as > > > > > standard. > > > > > > > What if the hardware doesn't support power management ? > > > > > > You would still want to do the cleanup and configuration that you'd do > > > for module load/unload. > > > > > By adding dummy functions, wouldn't that just look awkward ? > > If all you need to do is say 'I don't need to do anything' and we have a > shared function that does that, all we're talking about doing is adding > to your struct pci_device (or whatever) > > .resume = generic_empty_resume; > > To me at least, that doesn't look awkward, and says cleanly and clearly > that you've checked things over and decided you know what's required. Actually, I'd like it to be .resume = generic_empty_resume; /* Explain, why your driver needs no resume */ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 16:52 ` Pavel Machek @ 2007-02-12 20:31 ` Rafael J. Wysocki 2007-02-12 20:58 ` Pavel Machek 2007-02-13 9:42 ` Tilman Schmidt 0 siblings, 2 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 20:31 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, tilman, Robert Hancock On Monday, 12 February 2007 17:52, Pavel Machek wrote: > Hi! > > > > > > > Neither am I. I'm just asking that new drivers have power management as > > > > > > standard. > > > > > > > > > What if the hardware doesn't support power management ? > > > > > > > > You would still want to do the cleanup and configuration that you'd do > > > > for module load/unload. > > > > > > > By adding dummy functions, wouldn't that just look awkward ? > > > > If all you need to do is say 'I don't need to do anything' and we have a > > shared function that does that, all we're talking about doing is adding > > to your struct pci_device (or whatever) > > > > .resume = generic_empty_resume; > > > > To me at least, that doesn't look awkward, and says cleanly and clearly > > that you've checked things over and decided you know what's required. > > Actually, I'd like it to be > > .resume = generic_empty_resume; /* Explain, why your driver needs no > resume */ Okay, but we can't define an empty .resume(), because, for example, the PCI's generic suspend/resume won't be called. I think we can introduce a "pm_safe" flag that will indicate if the driver handles suspend/resume correctly. If we do it, we can flag all of the drivers currently in the tree as "pm_safe" unless we know that they aren't. Next, we can convert the core to fail the suspend for any driver that is not flagged as "pm_safe". But I think that will take time. In the meantime, I'd like to ask the authors of new drivers to define error-returning .suspend() if they don't intend to define "real" .suspend() and .resume() for now. When we are ready with the conversion, we'll be able to drop the error-returning .suspend()s and clear "pm_safe" for them. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 20:31 ` Rafael J. Wysocki @ 2007-02-12 20:58 ` Pavel Machek 2007-02-12 21:01 ` Rafael J. Wysocki 2007-02-13 9:42 ` Tilman Schmidt 1 sibling, 1 reply; 155+ messages in thread From: Pavel Machek @ 2007-02-12 20:58 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, tilman, Robert Hancock Hi! > > > If all you need to do is say 'I don't need to do anything' and we have a > > > shared function that does that, all we're talking about doing is adding > > > to your struct pci_device (or whatever) > > > > > > .resume = generic_empty_resume; > > > > > > To me at least, that doesn't look awkward, and says cleanly and clearly > > > that you've checked things over and decided you know what's required. > > > > Actually, I'd like it to be > > > > .resume = generic_empty_resume; /* Explain, why your driver needs no > > resume */ > > Okay, but we can't define an empty .resume(), because, for example, the PCI's > generic suspend/resume won't be called. PCI drivers should just do .resume = pci_generic_resume, explicitely. > In the meantime, I'd like to ask the authors of new drivers to define > error-returning .suspend() if they don't intend to define "real" .suspend() > and .resume() for now. When we are ready with the conversion, we'll be able > to drop the error-returning .suspend()s and clear "pm_safe" for them. Yes... please. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 20:58 ` Pavel Machek @ 2007-02-12 21:01 ` Rafael J. Wysocki 2007-02-12 21:24 ` Nigel Cunningham 0 siblings, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 21:01 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, tilman, Robert Hancock On Monday, 12 February 2007 21:58, Pavel Machek wrote: > Hi! > > > > > If all you need to do is say 'I don't need to do anything' and we have a > > > > shared function that does that, all we're talking about doing is adding > > > > to your struct pci_device (or whatever) > > > > > > > > .resume = generic_empty_resume; > > > > > > > > To me at least, that doesn't look awkward, and says cleanly and clearly > > > > that you've checked things over and decided you know what's required. > > > > > > Actually, I'd like it to be > > > > > > .resume = generic_empty_resume; /* Explain, why your driver needs no > > > resume */ > > > > Okay, but we can't define an empty .resume(), because, for example, the PCI's > > generic suspend/resume won't be called. > > PCI drivers should just do .resume = pci_generic_resume, explicitely. Well, I generally agree, but I think the idea with the "pm_safe" flag has some advantages. For example, the drivers that do deffine .suspend() and .resume() which don't work correctly could be flagged as not "pm_safe" until the problems are fixed. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 21:01 ` Rafael J. Wysocki @ 2007-02-12 21:24 ` Nigel Cunningham 2007-02-12 21:43 ` Rafael J. Wysocki 0 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-12 21:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, tilman, Robert Hancock Hi. On Mon, 2007-02-12 at 22:01 +0100, Rafael J. Wysocki wrote: > On Monday, 12 February 2007 21:58, Pavel Machek wrote: > > Hi! > > > > > > > If all you need to do is say 'I don't need to do anything' and we have a > > > > > shared function that does that, all we're talking about doing is adding > > > > > to your struct pci_device (or whatever) > > > > > > > > > > .resume = generic_empty_resume; > > > > > > > > > > To me at least, that doesn't look awkward, and says cleanly and clearly > > > > > that you've checked things over and decided you know what's required. > > > > > > > > Actually, I'd like it to be > > > > > > > > .resume = generic_empty_resume; /* Explain, why your driver needs no > > > > resume */ > > > > > > Okay, but we can't define an empty .resume(), because, for example, the PCI's > > > generic suspend/resume won't be called. > > > > PCI drivers should just do .resume = pci_generic_resume, explicitely. > > Well, I generally agree, but I think the idea with the "pm_safe" flag has some > advantages. For example, the drivers that do deffine .suspend() and .resume() > which don't work correctly could be flagged as not "pm_safe" until the problems > are fixed. Oooh. Now I like that idea. Are you thinking of a document in Documentation/power that describes why pm_safe is off, or comments in the code itself? Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 21:24 ` Nigel Cunningham @ 2007-02-12 21:43 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 21:43 UTC (permalink / raw) To: nigel Cc: Pavel Machek, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, tilman, Robert Hancock On Monday, 12 February 2007 22:24, Nigel Cunningham wrote: > Hi. > > On Mon, 2007-02-12 at 22:01 +0100, Rafael J. Wysocki wrote: > > On Monday, 12 February 2007 21:58, Pavel Machek wrote: > > > Hi! > > > > > > > > > If all you need to do is say 'I don't need to do anything' and we have a > > > > > > shared function that does that, all we're talking about doing is adding > > > > > > to your struct pci_device (or whatever) > > > > > > > > > > > > .resume = generic_empty_resume; > > > > > > > > > > > > To me at least, that doesn't look awkward, and says cleanly and clearly > > > > > > that you've checked things over and decided you know what's required. > > > > > > > > > > Actually, I'd like it to be > > > > > > > > > > .resume = generic_empty_resume; /* Explain, why your driver needs no > > > > > resume */ > > > > > > > > Okay, but we can't define an empty .resume(), because, for example, the PCI's > > > > generic suspend/resume won't be called. > > > > > > PCI drivers should just do .resume = pci_generic_resume, explicitely. > > > > Well, I generally agree, but I think the idea with the "pm_safe" flag has some > > advantages. For example, the drivers that do define .suspend() and .resume() > > which don't work correctly could be flagged as not "pm_safe" until the problems > > are fixed. > > Oooh. Now I like that idea. Are you thinking of a document in > Documentation/power that describes why pm_safe is off, or comments in > the code itself? I think the code should be commented in the first place. Additionally, we can create a file or a directory under Documentation/power for documenting more complicated cases, if necessary. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 20:31 ` Rafael J. Wysocki 2007-02-12 20:58 ` Pavel Machek @ 2007-02-13 9:42 ` Tilman Schmidt 2007-02-13 19:24 ` Rafael J. Wysocki 1 sibling, 1 reply; 155+ messages in thread From: Tilman Schmidt @ 2007-02-13 9:42 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Nigel Cunningham, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, tilman, Robert Hancock [-- Attachment #1: Type: text/plain, Size: 1440 bytes --] Rafael J. Wysocki schrieb: > I think we can introduce a "pm_safe" flag that will indicate if the driver > handles suspend/resume correctly. If we do it, we can flag all of the drivers > currently in the tree as "pm_safe" unless we know that they aren't. Next, > we can convert the core to fail the suspend for any driver that is not flagged > as "pm_safe". But I think that will take time. Why a new flag? IMHO it would be both more readable and more efficient to create a pm_generic_nosuspend() function which does "return -ENOSYS", and set that as the .suspend method on drivers known to break suspend/resume. New drivers should either have .suspend and .resume methods of their own or set .suspend = pm_generic_nosuspend. That way, NULL .suspend/.resume methods retain their current semantics ("don't know whether suspend would work, never thought about it"), error-returning ones would clearly signal "cannot suspend safely", and success-returning ones would equally clearly signal "suspend works ok". (Bugs nonwithstanding.) There could then be a policy parameter (Kconfig selectable to start) to abort suspend when encountering a driver without .suspend/.resume methods, or to proceed with a warning message. -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 250 bytes --] ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-13 9:42 ` Tilman Schmidt @ 2007-02-13 19:24 ` Rafael J. Wysocki 2007-02-14 23:45 ` Stefan Richter 0 siblings, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-13 19:24 UTC (permalink / raw) To: Tilman Schmidt Cc: Pavel Machek, Nigel Cunningham, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, Robert Hancock On Tuesday, 13 February 2007 10:42, Tilman Schmidt wrote: > Rafael J. Wysocki schrieb: > > I think we can introduce a "pm_safe" flag that will indicate if the driver > > handles suspend/resume correctly. If we do it, we can flag all of the drivers > > currently in the tree as "pm_safe" unless we know that they aren't. Next, > > we can convert the core to fail the suspend for any driver that is not flagged > > as "pm_safe". But I think that will take time. > > Why a new flag? For example, there are drivers that define .suspend() and .resume() which do not work correctly and we can use the flag to mark them. > IMHO it would be both more readable and more efficient > to create a pm_generic_nosuspend() function which does "return -ENOSYS", > and set that as the .suspend method on drivers known to break > suspend/resume. New drivers should either have .suspend and .resume > methods of their own or set .suspend = pm_generic_nosuspend. This is quite similar to what we are trying to do now: ask driver authors to define .suspend that will return -ENOSYS if they can't ensure that the driver will handle the suspend and resume correctly. > That way, NULL .suspend/.resume methods retain their current semantics > ("don't know whether suspend would work, never thought about it"), I think this convention is unfortunate. The default should be to fail the suspend if there's no .suspend defined, IMO. Still, it's hard to change now. > error-returning ones would clearly signal "cannot suspend safely", and > success-returning ones would equally clearly signal "suspend works ok". > (Bugs nonwithstanding.) > > There could then be a policy parameter (Kconfig selectable to start) > to abort suspend when encountering a driver without .suspend/.resume > methods, or to proceed with a warning message. I think there are many drivers without .suspend and .resume already in the tree, so that wouldn't be practical. Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-13 19:24 ` Rafael J. Wysocki @ 2007-02-14 23:45 ` Stefan Richter 0 siblings, 0 replies; 155+ messages in thread From: Stefan Richter @ 2007-02-14 23:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Tilman Schmidt, Pavel Machek, Nigel Cunningham, Manu Abraham, Willy Tarreau, Arjan van de Ven, LKML, Robert Hancock Rafael J. Wysocki wrote: >> Why a new flag? > > For example, there are drivers that define .suspend() and .resume() which > do not work correctly and we can use the flag to mark them. Depending on how serious the problems with these .suspend/.resume()s are, you could also put a printk in them or #if 0 bad_code #else return -ENOSYS #endif around them. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:25 ` Manu Abraham 2007-02-11 23:29 ` Pavel Machek 2007-02-11 23:33 ` Nigel Cunningham @ 2007-02-12 9:45 ` Arjan van de Ven 2 siblings, 0 replies; 155+ messages in thread From: Arjan van de Ven @ 2007-02-12 9:45 UTC (permalink / raw) To: Manu Abraham Cc: nigel, Willy Tarreau, Rafael J. Wysocki, Pavel Machek, LKML, tilman > > By adding dummy functions, wouldn't that just look awkward ? not really; if you have a template pm_no_suspend_needed and pm_no_restore_needed functions, and just make it part of ALL device structs that don't need it.. it's not that bad or maybe pm_generic_no_suspend pm_generic_no_resume as names, more in line what we use elsewhere in the kernel -- 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 ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 6:46 ` Willy Tarreau 2007-02-11 13:04 ` Rafael J. Wysocki 2007-02-11 22:47 ` Nigel Cunningham @ 2007-02-12 12:59 ` Gerhard Mack 2007-02-12 20:20 ` Willy Tarreau 2007-02-12 20:46 ` Rafael J. Wysocki 2007-02-12 13:51 ` Tino Keitel 3 siblings, 2 replies; 155+ messages in thread From: Gerhard Mack @ 2007-02-12 12:59 UTC (permalink / raw) To: Willy Tarreau Cc: Nigel Cunningham, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman On Sun, 11 Feb 2007, Willy Tarreau wrote: > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: > > Many people also have Linux on their notebooks, but as a dual-boot. You > read the word ? "dual-boot". It means that they cleanly shutdown their > system every time they don't use it anymore, and they won't know what > OS they'll use next time. Please tell me your joking. Linux' crappy suspend support is a common reason people give me for not wanting Linux anywhere near their laptops. I have a single boot laptop that's somewhat of a mobile debugging station that needs Linux and I absolutely hate it. Right now my laptop takes far too long to boot and even if it didn't I wish I could suspend. I'm actually a huge Linux fan.. I use it exclusively on my server and on my PC but if I get another laptop I will probably run something else on it. Linux is just too annoying for that use. Gerhard -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 12:59 ` Gerhard Mack @ 2007-02-12 20:20 ` Willy Tarreau 2007-02-13 15:23 ` Brad Campbell 2007-02-12 20:46 ` Rafael J. Wysocki 1 sibling, 1 reply; 155+ messages in thread From: Willy Tarreau @ 2007-02-12 20:20 UTC (permalink / raw) To: Gerhard Mack Cc: Nigel Cunningham, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman On Mon, Feb 12, 2007 at 07:59:40AM -0500, Gerhard Mack wrote: > On Sun, 11 Feb 2007, Willy Tarreau wrote: > > > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: > > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: > > > > Many people also have Linux on their notebooks, but as a dual-boot. You > > read the word ? "dual-boot". It means that they cleanly shutdown their > > system every time they don't use it anymore, and they won't know what > > OS they'll use next time. > > Please tell me your joking. Linux' crappy suspend support is a common > reason people give me for not wanting Linux anywhere near their laptops. No, I'm not kidding. The most annoyed ones are those who don't have serial ports and who need those annoying USB adapters. But fortunately, not all of them need to access router consoles :-) > I have a single boot laptop that's somewhat of a mobile debugging station > that needs Linux and I absolutely hate it. Right now my laptop takes far > too long to boot and even if it didn't I wish I could suspend. Probably that you got the wrong laptop. If you buy an ultra-thin with highly proprietary hardware, it may be hard. But if you choose in profesionnal ranges, there is rarely any problem. I have a compaq nc8000 on which everything works fine, and it boots in about 20 seconds. Other people I know have Toshibas, NECs, Dells and IBMs and are happy with them. My previous VAIO was a dirty crap that I would never recommend to anybody though. > I'm actually a huge Linux fan.. I use it exclusively on my server and on > my PC but if I get another laptop I will probably run something else on > it. Linux is just too annoying for that use. Everyone has different needs, that's all. Sorry, but I fell like we're becoming a bit off-topic here. Regards, Willy ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 20:20 ` Willy Tarreau @ 2007-02-13 15:23 ` Brad Campbell 0 siblings, 0 replies; 155+ messages in thread From: Brad Campbell @ 2007-02-13 15:23 UTC (permalink / raw) To: Willy Tarreau Cc: Gerhard Mack, Nigel Cunningham, Rafael J. Wysocki, Pavel Machek, Arjan van de Ven, LKML, tilman Willy Tarreau wrote: > Probably that you got the wrong laptop. If you buy an ultra-thin with highly > proprietary hardware, it may be hard. But if you choose in profesionnal ranges, > there is rarely any problem. I have a compaq nc8000 on which everything works > fine, and it boots in about 20 seconds. Other people I know have Toshibas, > NECs, Dells and IBMs and are happy with them. My previous VAIO was a dirty > crap that I would never recommend to anybody though. Whereas my "ultru-thin" VAIO works perfectly with both S2D and S2R and the only thing I have some difficulty with is the SD reader. Would not hesitate to recommend it to anyone. I often hibernate linux to boot into a hibernated windows session, then go back the other way as required, and my machine might do 80-100 "suspend2both" sessions a month between reboots. 30-40 seconds to suspend mostly (1.5GB of RAM) and about 15 to come back. That's what I call highly useful. Different strokes and all that I guess.. Brad -- "Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." -- Douglas Adams ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 12:59 ` Gerhard Mack 2007-02-12 20:20 ` Willy Tarreau @ 2007-02-12 20:46 ` Rafael J. Wysocki 1 sibling, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 20:46 UTC (permalink / raw) To: Gerhard Mack Cc: Willy Tarreau, Nigel Cunningham, Pavel Machek, Arjan van de Ven, LKML, tilman On Monday, 12 February 2007 13:59, Gerhard Mack wrote: > On Sun, 11 Feb 2007, Willy Tarreau wrote: > > > On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote: > > > On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote: > > > > Many people also have Linux on their notebooks, but as a dual-boot. You > > read the word ? "dual-boot". It means that they cleanly shutdown their > > system every time they don't use it anymore, and they won't know what > > OS they'll use next time. > > Please tell me your joking. Linux' crappy suspend support is a common > reason people give me for not wanting Linux anywhere near their laptops. > > I have a single boot laptop that's somewhat of a mobile debugging station > that needs Linux and I absolutely hate it. Right now my laptop takes far > too long to boot and even if it didn't I wish I could suspend. When did you try last time? Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 6:46 ` Willy Tarreau ` (2 preceding siblings ...) 2007-02-12 12:59 ` Gerhard Mack @ 2007-02-12 13:51 ` Tino Keitel 3 siblings, 0 replies; 155+ messages in thread From: Tino Keitel @ 2007-02-12 13:51 UTC (permalink / raw) To: LKML On Sun, Feb 11, 2007 at 07:46:36 +0100, Willy Tarreau wrote: [...] > Many people also have Linux on their notebooks, but as a dual-boot. You > read the word ? "dual-boot". It means that they cleanly shutdown their > system every time they don't use it anymore, and they won't know what > OS they'll use next time. I can suspend to disk my Mac mini, reboot into MacOS X, shutdown, and then resume in Linux. I also did this with APM suspend to disk support on my ThinkPad some years ago, using Linux and Windows. So, dualboot and suspend support isn't mutual exclusive. This is only the case if suspend is limited to suspend to RAM. Regards, Tino ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 22:20 ` Rafael J. Wysocki 2007-02-10 22:37 ` Nigel Cunningham @ 2007-02-11 19:42 ` Pavel Machek 2007-02-11 21:02 ` Alan 2007-02-11 22:21 ` Tilman Schmidt 2007-02-12 8:49 ` Geert Uytterhoeven 2 siblings, 2 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 19:42 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Arjan van de Ven, nigel, LKML Hi! > > > > Can we start to NAK new drivers that don't have proper power management > > > > implemented? There really is no excuse for writing a new driver and not > > > > putting .suspend and .resume methods in anymore, is there? > > > > > > to a large degree, a device driver that doesn't suspend is better than > > > no device driver at all, right? > > > now.. if you want to make the core warn about it, that's very fair > > > > Well, driver that is broken on SMP is arguably better than no driver > > at all, yet we'd probably avoid merging that. It would be nice to > > start including suspend in 'must work' list... > > What about this: > > "If the device requires that, implement .suspend and .resume or at least > define .suspend that will always return -ENOSYS (then people will know they > have to unload the driver before the suspend). Similarly, if you aren't sure > whether or not the device requires .suspend and .resume, define .suspend that > will always return -ENOSYS." Sounds ok to me. Where should this text go? Documentation/SubmittingDrivers ? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 19:42 ` Pavel Machek @ 2007-02-11 21:02 ` Alan 2007-02-11 23:04 ` Rafael J. Wysocki 2007-02-11 23:10 ` Nigel Cunningham 2007-02-11 22:21 ` Tilman Schmidt 1 sibling, 2 replies; 155+ messages in thread From: Alan @ 2007-02-11 21:02 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Arjan van de Ven, nigel, LKML > > "If the device requires that, implement .suspend and .resume or at least > > define .suspend that will always return -ENOSYS (then people will know they > > have to unload the driver before the suspend). Similarly, if you aren't sure > > whether or not the device requires .suspend and .resume, define .suspend that > > will always return -ENOSYS." > > Sounds ok to me. Where should this text go? > Documentation/SubmittingDrivers ? And testing/submitting drivers, perhaps with additional text in that to make it clear we want suspend/resume support or good excuses "Please verify your driver correctly handles suspend and resume. If it does not your patch submission is likely to be suspended and only resume when the driver correctly handles this feature" ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 21:02 ` Alan @ 2007-02-11 23:04 ` Rafael J. Wysocki 2007-02-12 0:28 ` Alan 2007-02-11 23:10 ` Nigel Cunningham 1 sibling, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:04 UTC (permalink / raw) To: Alan; +Cc: Pavel Machek, Arjan van de Ven, nigel, LKML On Sunday, 11 February 2007 22:02, Alan wrote: > > > "If the device requires that, implement .suspend and .resume or at least > > > define .suspend that will always return -ENOSYS (then people will know they > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > whether or not the device requires .suspend and .resume, define .suspend that > > > will always return -ENOSYS." > > > > Sounds ok to me. Where should this text go? > > Documentation/SubmittingDrivers ? > > And testing/submitting drivers, perhaps with additional text in that to > make it clear we want suspend/resume support or good excuses > > "Please verify your driver correctly handles suspend and resume. If it > does not your patch submission is likely to be suspended and only resume > when the driver correctly handles this feature" I have prepared a patch against Documentation/SubmittingDrivers. Please have a look. --- Documentation/SubmittingDrivers | 12 ++++++++++++ 1 file changed, 12 insertions(+) Index: linux-2.6.20-git4/Documentation/SubmittingDrivers =================================================================== --- linux-2.6.20-git4.orig/Documentation/SubmittingDrivers +++ linux-2.6.20-git4/Documentation/SubmittingDrivers @@ -87,6 +87,18 @@ Clarity: It helps if anyone can see how driver that intentionally obfuscates how the hardware works it will go in the bitbucket. +PM support: Since Linux is used on many portable and desktop systems, your + driver is likely to be used on such a system and therefore it + should support basic power management by implementing, if + necessary, the .suspend and .resume methods used during the + system-wide suspend and resume transitions. You should verify + that your driver correctly handles the suspend and resume, but + if you are unable to ensure that, please at least define the + .suspend method returning the -ENOSYS ("Function not + implemented") error. Note, however, that in such a case your + submission is likely to be suspended and only resumed when the + driver correctly handles this feature. + Control: In general if there is active maintainance of a driver by the author then patches will be redirected to them unless they are totally obvious and without need of checking. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:04 ` Rafael J. Wysocki @ 2007-02-12 0:28 ` Alan 2007-02-12 0:24 ` Rafael J. Wysocki 0 siblings, 1 reply; 155+ messages in thread From: Alan @ 2007-02-12 0:28 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Arjan van de Ven, nigel, LKML > +PM support: Since Linux is used on many portable and desktop systems, your > + driver is likely to be used on such a system and therefore it > + should support basic power management by implementing, if > + necessary, the .suspend and .resume methods used during the > + system-wide suspend and resume transitions. You should verify > + that your driver correctly handles the suspend and resume, but > + if you are unable to ensure that, please at least define the > + .suspend method returning the -ENOSYS ("Function not > + implemented") error. Note, however, that in such a case your > + submission is likely to be suspended and only resumed when the > + driver correctly handles this feature. I'd lose the last bit. Just end it at "error.", there are going to be people who produce good reasons not to handle suspend/resume. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 0:28 ` Alan @ 2007-02-12 0:24 ` Rafael J. Wysocki 0 siblings, 0 replies; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-12 0:24 UTC (permalink / raw) To: Alan; +Cc: Pavel Machek, Arjan van de Ven, nigel, LKML On Monday, 12 February 2007 01:28, Alan wrote: > > +PM support: Since Linux is used on many portable and desktop systems, your > > + driver is likely to be used on such a system and therefore it > > + should support basic power management by implementing, if > > + necessary, the .suspend and .resume methods used during the > > + system-wide suspend and resume transitions. You should verify > > + that your driver correctly handles the suspend and resume, but > > + if you are unable to ensure that, please at least define the > > + .suspend method returning the -ENOSYS ("Function not > > + implemented") error. Note, however, that in such a case your > > + submission is likely to be suspended and only resumed when the > > + driver correctly handles this feature. > > I'd lose the last bit. Just end it at "error.", there are going to be > people who produce good reasons not to handle suspend/resume. OK, I will. ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 21:02 ` Alan 2007-02-11 23:04 ` Rafael J. Wysocki @ 2007-02-11 23:10 ` Nigel Cunningham 2007-02-11 23:16 ` Rafael J. Wysocki 2007-02-11 23:21 ` Pavel Machek 1 sibling, 2 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:10 UTC (permalink / raw) To: Alan; +Cc: Pavel Machek, Rafael J. Wysocki, Arjan van de Ven, LKML Hi. On Sun, 2007-02-11 at 21:02 +0000, Alan wrote: > > > "If the device requires that, implement .suspend and .resume or at least > > > define .suspend that will always return -ENOSYS (then people will know they > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > whether or not the device requires .suspend and .resume, define .suspend that > > > will always return -ENOSYS." > > > > Sounds ok to me. Where should this text go? > > Documentation/SubmittingDrivers ? > > And testing/submitting drivers, perhaps with additional text in that to > make it clear we want suspend/resume support or good excuses > > "Please verify your driver correctly handles suspend and resume. If it > does not your patch submission is likely to be suspended and only resume > when the driver correctly handles this feature" Maybe make it explicit that testing should be done for both suspend to ram and to disk, and with the following usage scenarios as applicable? - built in; - modular, loaded while suspending but not loaded prior to resume from disk; - modular, loaded while suspending and loaded prior to resume from disk; Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:10 ` Nigel Cunningham @ 2007-02-11 23:16 ` Rafael J. Wysocki 2007-02-11 23:22 ` Nigel Cunningham 2007-02-11 23:21 ` Pavel Machek 1 sibling, 1 reply; 155+ messages in thread From: Rafael J. Wysocki @ 2007-02-11 23:16 UTC (permalink / raw) To: nigel; +Cc: Alan, Pavel Machek, Arjan van de Ven, LKML On Monday, 12 February 2007 00:10, Nigel Cunningham wrote: > Hi. > > On Sun, 2007-02-11 at 21:02 +0000, Alan wrote: > > > > "If the device requires that, implement .suspend and .resume or at least > > > > define .suspend that will always return -ENOSYS (then people will know they > > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > > whether or not the device requires .suspend and .resume, define .suspend that > > > > will always return -ENOSYS." > > > > > > Sounds ok to me. Where should this text go? > > > Documentation/SubmittingDrivers ? > > > > And testing/submitting drivers, perhaps with additional text in that to > > make it clear we want suspend/resume support or good excuses > > > > "Please verify your driver correctly handles suspend and resume. If it > > does not your patch submission is likely to be suspended and only resume > > when the driver correctly handles this feature" > > Maybe make it explicit that testing should be done for both suspend to > ram and to disk, and with the following usage scenarios as applicable? > > - built in; > - modular, loaded while suspending but not loaded prior to resume from > disk; > - modular, loaded while suspending and loaded prior to resume from disk; I think we should state the general rule in Documentation/SubmittingDrivers and give more details in Documentation/power/devices.txt Greetings, Rafael ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:16 ` Rafael J. Wysocki @ 2007-02-11 23:22 ` Nigel Cunningham 2007-02-11 23:23 ` Pavel Machek 0 siblings, 1 reply; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:22 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Alan, Pavel Machek, Arjan van de Ven, LKML Hi. On Mon, 2007-02-12 at 00:16 +0100, Rafael J. Wysocki wrote: > On Monday, 12 February 2007 00:10, Nigel Cunningham wrote: > > Hi. > > > > On Sun, 2007-02-11 at 21:02 +0000, Alan wrote: > > > > > "If the device requires that, implement .suspend and .resume or at least > > > > > define .suspend that will always return -ENOSYS (then people will know they > > > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > > > whether or not the device requires .suspend and .resume, define .suspend that > > > > > will always return -ENOSYS." > > > > > > > > Sounds ok to me. Where should this text go? > > > > Documentation/SubmittingDrivers ? > > > > > > And testing/submitting drivers, perhaps with additional text in that to > > > make it clear we want suspend/resume support or good excuses > > > > > > "Please verify your driver correctly handles suspend and resume. If it > > > does not your patch submission is likely to be suspended and only resume > > > when the driver correctly handles this feature" > > > > Maybe make it explicit that testing should be done for both suspend to > > ram and to disk, and with the following usage scenarios as applicable? > > > > - built in; > > - modular, loaded while suspending but not loaded prior to resume from > > disk; > > - modular, loaded while suspending and loaded prior to resume from disk; > > I think we should state the general rule in Documentation/SubmittingDrivers > and give more details in Documentation/power/devices.txt Sounds good. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:22 ` Nigel Cunningham @ 2007-02-11 23:23 ` Pavel Machek 0 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-11 23:23 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Alan, Arjan van de Ven, LKML Hi! > > > - built in; > > > - modular, loaded while suspending but not loaded prior to resume from > > > disk; > > > - modular, loaded while suspending and loaded prior to resume from disk; > > > > I think we should state the general rule in Documentation/SubmittingDrivers > > and give more details in Documentation/power/devices.txt > > Sounds good. Ok, so who does the patch? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:10 ` Nigel Cunningham 2007-02-11 23:16 ` Rafael J. Wysocki @ 2007-02-11 23:21 ` Pavel Machek 2007-02-11 23:29 ` Nigel Cunningham 1 sibling, 1 reply; 155+ messages in thread From: Pavel Machek @ 2007-02-11 23:21 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Alan, Rafael J. Wysocki, Arjan van de Ven, LKML Hi! > > > > define .suspend that will always return -ENOSYS (then people will know they > > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > > whether or not the device requires .suspend and .resume, define .suspend that > > > > will always return -ENOSYS." > > > > > > Sounds ok to me. Where should this text go? > > > Documentation/SubmittingDrivers ? > > > > And testing/submitting drivers, perhaps with additional text in that to > > make it clear we want suspend/resume support or good excuses > > > > "Please verify your driver correctly handles suspend and resume. If it > > does not your patch submission is likely to be suspended and only resume > > when the driver correctly handles this feature" > > Maybe make it explicit that testing should be done for both suspend to > ram and to disk, and with the following usage scenarios as > applicable? Well, for many people s2ram does not work even today... so requiring them to test it is slightly draconian. > - built in; > - modular, loaded while suspending but not loaded prior to resume from > disk; These two should be equivalent. > - modular, loaded while suspending and loaded prior to resume from disk; Ok.. but I'm not sure how many people will actually test it _that_ thoroughly. "Try to test it" is good enough for a first version. When suspend is in better shape, we can ask for more. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 23:21 ` Pavel Machek @ 2007-02-11 23:29 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-11 23:29 UTC (permalink / raw) To: Pavel Machek; +Cc: Alan, Rafael J. Wysocki, Arjan van de Ven, LKML Hi. On Mon, 2007-02-12 at 00:21 +0100, Pavel Machek wrote: > Hi! > > > > > > define .suspend that will always return -ENOSYS (then people will know they > > > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > > > whether or not the device requires .suspend and .resume, define .suspend that > > > > > will always return -ENOSYS." > > > > > > > > Sounds ok to me. Where should this text go? > > > > Documentation/SubmittingDrivers ? > > > > > > And testing/submitting drivers, perhaps with additional text in that to > > > make it clear we want suspend/resume support or good excuses > > > > > > "Please verify your driver correctly handles suspend and resume. If it > > > does not your patch submission is likely to be suspended and only resume > > > when the driver correctly handles this feature" > > > > Maybe make it explicit that testing should be done for both suspend to > > ram and to disk, and with the following usage scenarios as > > applicable? > > Well, for many people s2ram does not work even today... so requiring > them to test it is slightly draconian. > > > - built in; > > - modular, loaded while suspending but not loaded prior to resume from > > disk; > > These two should be equivalent. No. The differences are: Built in: The initcalls will have run, but the driver may or may not actually have been used, depending on whether it's used before we start the resume. It should probably be tested with both having been used and not having been used. Modular, loaded prior to suspending but not prior to resuming: At resume time, will still be in whatever config the bios puts it in. No Linux driver code will have touched it. Modular, loaded prior to suspending and resuming: Should be equivalent to built in (module initcalls will have run), but may vary if there's some difference in code/timing between being a module and built in. (This shouldn't happen, but that's the point to testing). > > - modular, loaded while suspending and loaded prior to resume from disk; > > Ok.. but I'm not sure how many people will actually test it _that_ > thoroughly. "Try to test it" is good enough for a first version. When > suspend is in better shape, we can ask for more. I'd prefer to ask for what should be done from the start. Will we expect people to go back and retest if we change the rules, or do we prefer them to complain "You didn't adequately point out the testing I needed to do, and I got all these complaints from my users!" Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-11 19:42 ` Pavel Machek 2007-02-11 21:02 ` Alan @ 2007-02-11 22:21 ` Tilman Schmidt 1 sibling, 0 replies; 155+ messages in thread From: Tilman Schmidt @ 2007-02-11 22:21 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Arjan van de Ven, nigel, LKML [-- Attachment #1: Type: text/plain, Size: 735 bytes --] Am 11.02.2007 20:42 schrieb Pavel Machek: [...] >> What about this: >> >> "If the device requires that, implement .suspend and .resume or at least >> define .suspend that will always return -ENOSYS (then people will know they >> have to unload the driver before the suspend). Similarly, if you aren't sure >> whether or not the device requires .suspend and .resume, define .suspend that >> will always return -ENOSYS." > > Sounds ok to me. Where should this text go? > Documentation/SubmittingDrivers ? Documentation/power/devices.txt? -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany - In theory, there is no difference between theory and practice. In practice, there is. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 253 bytes --] ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 22:20 ` Rafael J. Wysocki 2007-02-10 22:37 ` Nigel Cunningham 2007-02-11 19:42 ` Pavel Machek @ 2007-02-12 8:49 ` Geert Uytterhoeven 2007-02-12 15:04 ` Pavel Machek 2 siblings, 1 reply; 155+ messages in thread From: Geert Uytterhoeven @ 2007-02-12 8:49 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Arjan van de Ven, nigel, LKML On Sat, 10 Feb 2007, Rafael J. Wysocki wrote: > What about this: > > "If the device requires that, implement .suspend and .resume or at least ^^^^^^^^ > define .suspend that will always return -ENOSYS (then people will know they ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > have to unload the driver before the suspend). Similarly, if you aren't sure > whether or not the device requires .suspend and .resume, define .suspend that ^^^^^^^^^^^^^^^^^^^^ > will always return -ENOSYS." ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL? It's nicer if you don't have to implement dummy functions at all. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 8:49 ` Geert Uytterhoeven @ 2007-02-12 15:04 ` Pavel Machek 2007-02-12 15:57 ` Geert Uytterhoeven 0 siblings, 1 reply; 155+ messages in thread From: Pavel Machek @ 2007-02-12 15:04 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Rafael J. Wysocki, Arjan van de Ven, nigel, LKML Hi! > > "If the device requires that, implement .suspend and .resume or at least > ^^^^^^^^ > > define .suspend that will always return -ENOSYS (then people will know they > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > have to unload the driver before the suspend). Similarly, if you aren't sure > > whether or not the device requires .suspend and .resume, define .suspend that > ^^^^^^^^^^^^^^^^^^^^ > > will always return -ENOSYS." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL? > It's nicer if you don't have to implement dummy functions at all. Unfortunately, drivers currently assume "NULL == nothing is needed", so we'd have t do big search & replace... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 15:04 ` Pavel Machek @ 2007-02-12 15:57 ` Geert Uytterhoeven 2007-02-12 16:55 ` Pavel Machek ` (2 more replies) 0 siblings, 3 replies; 155+ messages in thread From: Geert Uytterhoeven @ 2007-02-12 15:57 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Arjan van de Ven, nigel, LKML On Mon, 12 Feb 2007, Pavel Machek wrote: > > > "If the device requires that, implement .suspend and .resume or at least > > ^^^^^^^^ > > > define .suspend that will always return -ENOSYS (then people will know they > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > whether or not the device requires .suspend and .resume, define .suspend that > > ^^^^^^^^^^^^^^^^^^^^ > > > will always return -ENOSYS." > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL? > > It's nicer if you don't have to implement dummy functions at all. > > Unfortunately, drivers currently assume "NULL == nothing is needed", > so we'd have t do big search & replace... Which means you also cannot easily keep track of which driver supports suspend/resume and which doesn't, as there will always be drivers where a missing suspend/resume function is correct. Wouldn't it be more sensible to have .suspend = suspend_nothing_to_do instead, and reserve NULL for `not yet implemented'? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 15:57 ` Geert Uytterhoeven @ 2007-02-12 16:55 ` Pavel Machek 2007-02-12 20:38 ` Nigel Cunningham 2007-02-13 10:02 ` Tilman Schmidt 2 siblings, 0 replies; 155+ messages in thread From: Pavel Machek @ 2007-02-12 16:55 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Rafael J. Wysocki, Arjan van de Ven, nigel, LKML Hi! > > > > "If the device requires that, implement .suspend and .resume or at least > > > ^^^^^^^^ > > > > define .suspend that will always return -ENOSYS (then people will know they > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > have to unload the driver before the suspend). Similarly, if you aren't sure > > > > whether or not the device requires .suspend and .resume, define .suspend that > > > ^^^^^^^^^^^^^^^^^^^^ > > > > will always return -ENOSYS." > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL? > > > It's nicer if you don't have to implement dummy functions at all. > > > > Unfortunately, drivers currently assume "NULL == nothing is needed", > > so we'd have t do big search & replace... > > Which means you also cannot easily keep track of which driver supports > suspend/resume and which doesn't, as there will always be drivers where a > missing suspend/resume function is correct. > > Wouldn't it be more sensible to have > > .suspend = suspend_nothing_to_do > > instead, and reserve NULL for `not yet implemented'? It would be. Patch would be welcome :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 15:57 ` Geert Uytterhoeven 2007-02-12 16:55 ` Pavel Machek @ 2007-02-12 20:38 ` Nigel Cunningham 2007-02-13 10:02 ` Tilman Schmidt 2 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-12 20:38 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Pavel Machek, Rafael J. Wysocki, Arjan van de Ven, LKML Hi. On Mon, 2007-02-12 at 16:57 +0100, Geert Uytterhoeven wrote: > On Mon, 12 Feb 2007, Pavel Machek wrote: > > > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL? > > > It's nicer if you don't have to implement dummy functions at all. > > > > Unfortunately, drivers currently assume "NULL == nothing is needed", > > so we'd have t do big search & replace... > > Which means you also cannot easily keep track of which driver supports > suspend/resume and which doesn't, as there will always be drivers where a > missing suspend/resume function is correct. > > Wouldn't it be more sensible to have > > .suspend = suspend_nothing_to_do > > instead, and reserve NULL for `not yet implemented'? Agreed. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-12 15:57 ` Geert Uytterhoeven 2007-02-12 16:55 ` Pavel Machek 2007-02-12 20:38 ` Nigel Cunningham @ 2007-02-13 10:02 ` Tilman Schmidt 2 siblings, 0 replies; 155+ messages in thread From: Tilman Schmidt @ 2007-02-13 10:02 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Pavel Machek, Rafael J. Wysocki, Arjan van de Ven, nigel, LKML [-- Attachment #1: Type: text/plain, Size: 1200 bytes --] Geert Uytterhoeven schrieb: > On Mon, 12 Feb 2007, Pavel Machek wrote: >> > Can't the upper layer just assume -ENOSYS if .resume/.suspend is NULL? >> > It's nicer if you don't have to implement dummy functions at all. >> >> Unfortunately, drivers currently assume "NULL == nothing is needed", More often than not they assume nothing of the kind. >> so we'd have t do big search & replace... > > Which means you also cannot easily keep track of which driver supports > suspend/resume and which doesn't, as there will always be drivers where a > missing suspend/resume function is correct. I think those are rare exceptions. They could and should be asked to make this statement explicit, as you propose: > Wouldn't it be more sensible to have > > .suspend = suspend_nothing_to_do > > instead, and reserve NULL for `not yet implemented'? NULL is already taken for 'don't know'. So *two* new values are needed, one for "nothing to do" and one for "not supported". -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 250 bytes --] ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-09 21:57 Nigel Cunningham 2007-02-09 22:17 ` Arjan van de Ven @ 2007-02-10 3:42 ` Matthew Garrett 2007-02-10 4:42 ` Nigel Cunningham 1 sibling, 1 reply; 155+ messages in thread From: Matthew Garrett @ 2007-02-10 3:42 UTC (permalink / raw) To: Nigel Cunningham; +Cc: LKML On Sat, Feb 10, 2007 at 08:57:49AM +1100, Nigel Cunningham wrote: > Can we start to NAK new drivers that don't have proper power management > implemented? There really is no excuse for writing a new driver and not > putting .suspend and .resume methods in anymore, is there? The PCI layer is able to deal with drivers that have no PM methods in the most simple case. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 155+ messages in thread
* Re: NAK new drivers without proper power management? 2007-02-10 3:42 ` Matthew Garrett @ 2007-02-10 4:42 ` Nigel Cunningham 0 siblings, 0 replies; 155+ messages in thread From: Nigel Cunningham @ 2007-02-10 4:42 UTC (permalink / raw) To: Matthew Garrett; +Cc: LKML Hi. On Sat, 2007-02-10 at 03:42 +0000, Matthew Garrett wrote: > On Sat, Feb 10, 2007 at 08:57:49AM +1100, Nigel Cunningham wrote: > > > Can we start to NAK new drivers that don't have proper power management > > implemented? There really is no excuse for writing a new driver and not > > putting .suspend and .resume methods in anymore, is there? > > The PCI layer is able to deal with drivers that have no PM methods in > the most simple case. Yeah. I suppose we could use a pm_safe bit flag in struct device_driver and/or struct pci_driver. I have other things to do right now, but will seek to understand the relationship between those structs better later. Regards, Nigel ^ permalink raw reply [flat|nested] 155+ messages in thread
end of thread, other threads:[~2007-02-14 23:46 UTC | newest] Thread overview: 155+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <fa.xSKPgY66Q+DPCZ1pszFFfdrJ0To@ifi.uio.no> [not found] ` <fa.FzHdYYYH5Ru57c8/yRxLylpH0Kk@ifi.uio.no> [not found] ` <fa.DuG12yQo+RR4jIjJTnoOwtKM0Ao@ifi.uio.no> [not found] ` <fa.Jy0FJQtASvVEpsy8Q96uoHtyEVA@ifi.uio.no> 2007-02-10 1:50 ` NAK new drivers without proper power management? Robert Hancock 2007-02-10 1:59 ` Lee Revell 2007-02-10 2:09 ` Nigel Cunningham 2007-02-10 2:22 ` Lee Revell 2007-02-10 3:21 ` Kevin Fox 2007-02-10 20:40 ` Adrian Bunk 2007-02-10 4:35 ` Joseph Fannin 2007-02-13 21:08 ` Pavel Machek 2007-02-10 12:47 ` Stefan Richter 2007-02-10 2:05 ` Nigel Cunningham 2007-02-10 3:27 ` Dmitry Torokhov 2007-02-10 4:18 ` Nigel Cunningham 2007-02-10 3:02 ` [PATCH] " Nigel Cunningham 2007-02-10 9:34 ` Rafael J. Wysocki 2007-02-10 9:34 ` Rafael J. Wysocki 2007-02-10 10:02 ` Nigel Cunningham 2007-02-10 10:30 ` Rafael J. Wysocki 2007-02-10 10:30 ` Rafael J. Wysocki 2007-02-10 17:52 ` Daniel Barkalow 2007-02-10 17:52 ` Daniel Barkalow 2007-02-10 19:50 ` Rafael J. Wysocki 2007-02-10 19:50 ` Rafael J. Wysocki 2007-02-11 6:54 ` Willy Tarreau 2007-02-11 6:54 ` Willy Tarreau 2007-02-11 12:13 ` Matthew Garrett 2007-02-11 13:09 ` Willy Tarreau 2007-02-11 13:09 ` Willy Tarreau 2007-02-11 13:19 ` Matthew Garrett 2007-02-11 13:37 ` Willy Tarreau 2007-02-11 13:37 ` Willy Tarreau 2007-02-11 13:50 ` Rafael J. Wysocki 2007-02-11 13:50 ` Rafael J. Wysocki 2007-02-11 13:57 ` Willy Tarreau 2007-02-11 13:57 ` Willy Tarreau 2007-02-11 14:36 ` Rafael J. Wysocki 2007-02-11 14:36 ` Rafael J. Wysocki 2007-02-11 15:19 ` Pekka Enberg 2007-02-11 15:19 ` Pekka Enberg 2007-02-11 18:31 ` Rafael J. Wysocki 2007-02-11 18:31 ` Rafael J. Wysocki 2007-02-11 17:27 ` Daniel Barkalow 2007-02-11 18:53 ` Rafael J. Wysocki 2007-02-11 18:53 ` Rafael J. Wysocki 2007-02-11 23:06 ` Nigel Cunningham 2007-02-11 23:06 ` Nigel Cunningham 2007-02-11 23:10 ` Rafael J. Wysocki 2007-02-11 23:10 ` Rafael J. Wysocki 2007-02-11 21:04 ` Stefan Richter 2007-02-11 21:04 ` Stefan Richter 2007-02-11 21:10 ` Pavel Machek 2007-02-11 17:36 ` Robert Hancock 2007-02-11 22:49 ` Nigel Cunningham 2007-02-11 19:37 ` Pavel Machek 2007-02-11 19:37 ` Pavel Machek [not found] ` <fa.DhkemAgVI60diqZy0t9GzpwyLmk@ifi.uio.no> [not found] ` <fa.E/NjHlgg0HqDg5CgZjnCHFi2AMM@ifi.uio.no> [not found] ` <fa.kop49l/7yexJoUGrzk6vVeIP934@ifi.uio.no> 2007-02-10 23:20 ` Robert Hancock 2007-02-11 0:44 ` Rafael J. Wysocki 2007-02-11 17:01 ` Pavel Machek 2007-02-11 22:40 ` Nigel Cunningham 2007-02-11 23:29 ` Rafael J. Wysocki 2007-02-11 23:40 ` Nigel Cunningham [not found] ` <fa.EgQN5JpU6xrZSLyOY0kWjJ26hUM@ifi.uio.no> 2007-02-11 18:31 ` Robert Hancock 2007-02-11 21:52 ` Willy Tarreau 2007-02-11 22:26 ` Nigel Cunningham 2007-02-11 22:46 ` Willy Tarreau 2007-02-11 23:18 ` Nigel Cunningham 2007-02-11 23:38 ` Willy Tarreau 2007-02-11 23:45 ` Nigel Cunningham 2007-02-12 0:26 ` Alan 2007-02-12 5:19 ` Willy Tarreau 2007-02-12 20:20 ` Rafael J. Wysocki 2007-02-12 22:36 ` Nigel Cunningham 2007-02-11 23:23 ` Alan 2007-02-11 23:38 ` Rafael J. Wysocki 2007-02-11 23:41 ` Rafael J. Wysocki 2007-02-11 23:47 ` Nigel Cunningham 2007-02-11 23:50 ` Rafael J. Wysocki 2007-02-11 23:55 ` Nigel Cunningham 2007-02-12 0:09 ` Rafael J. Wysocki 2007-02-12 0:15 ` Nigel Cunningham 2007-02-12 12:19 ` Pavel Machek [not found] ` <fa.O1YH4k5KtBGCNs5i2yB17bPvPGw@ifi.uio.no> [not found] ` <fa.RfzClbTP/7B79AoEbQLNj3ABfIk@ifi.uio.no> [not found] ` <fa.AaJ/ugmiUmPO8uC+y1rS9JLuuMc@ifi.uio.no> 2007-02-12 0:59 ` Robert Hancock 2007-02-09 21:57 Nigel Cunningham 2007-02-09 22:17 ` Arjan van de Ven 2007-02-09 22:26 ` Nigel Cunningham 2007-02-09 22:44 ` Rafael J. Wysocki 2007-02-09 22:44 ` Rafael J. Wysocki 2007-02-09 22:51 ` Nigel Cunningham 2007-02-09 22:51 ` Nigel Cunningham 2007-02-09 23:12 ` Rafael J. Wysocki 2007-02-09 23:12 ` Rafael J. Wysocki 2007-02-09 23:28 ` Nigel Cunningham 2007-02-09 23:28 ` Nigel Cunningham 2007-02-10 0:12 ` Rafael J. Wysocki 2007-02-10 0:12 ` Rafael J. Wysocki 2007-02-10 0:25 ` Jeff Garzik 2007-02-10 6:43 ` Willy Tarreau 2007-02-10 23:52 ` Tilman Schmidt 2007-02-10 7:15 ` Arjan van de Ven 2007-02-10 19:38 ` Pavel Machek 2007-02-10 22:20 ` Rafael J. Wysocki 2007-02-10 22:37 ` Nigel Cunningham 2007-02-10 23:45 ` Tilman Schmidt 2007-02-11 0:27 ` Rafael J. Wysocki 2007-02-11 22:41 ` Nigel Cunningham 2007-02-13 15:55 ` Mark Lord 2007-02-13 16:06 ` Christoph Hellwig 2007-02-11 22:37 ` Nigel Cunningham 2007-02-12 0:10 ` Tilman Schmidt 2007-02-12 0:20 ` Rafael J. Wysocki 2007-02-12 4:08 ` Nigel Cunningham 2007-02-12 20:06 ` Rafael J. Wysocki 2007-02-12 22:38 ` Nigel Cunningham 2007-02-11 6:46 ` Willy Tarreau 2007-02-11 13:04 ` Rafael J. Wysocki 2007-02-11 22:47 ` Nigel Cunningham 2007-02-11 22:57 ` Manu Abraham 2007-02-11 23:20 ` Nigel Cunningham 2007-02-11 23:25 ` Manu Abraham 2007-02-11 23:29 ` Pavel Machek 2007-02-11 23:33 ` Nigel Cunningham 2007-02-12 16:52 ` Pavel Machek 2007-02-12 20:31 ` Rafael J. Wysocki 2007-02-12 20:58 ` Pavel Machek 2007-02-12 21:01 ` Rafael J. Wysocki 2007-02-12 21:24 ` Nigel Cunningham 2007-02-12 21:43 ` Rafael J. Wysocki 2007-02-13 9:42 ` Tilman Schmidt 2007-02-13 19:24 ` Rafael J. Wysocki 2007-02-14 23:45 ` Stefan Richter 2007-02-12 9:45 ` Arjan van de Ven 2007-02-12 12:59 ` Gerhard Mack 2007-02-12 20:20 ` Willy Tarreau 2007-02-13 15:23 ` Brad Campbell 2007-02-12 20:46 ` Rafael J. Wysocki 2007-02-12 13:51 ` Tino Keitel 2007-02-11 19:42 ` Pavel Machek 2007-02-11 21:02 ` Alan 2007-02-11 23:04 ` Rafael J. Wysocki 2007-02-12 0:28 ` Alan 2007-02-12 0:24 ` Rafael J. Wysocki 2007-02-11 23:10 ` Nigel Cunningham 2007-02-11 23:16 ` Rafael J. Wysocki 2007-02-11 23:22 ` Nigel Cunningham 2007-02-11 23:23 ` Pavel Machek 2007-02-11 23:21 ` Pavel Machek 2007-02-11 23:29 ` Nigel Cunningham 2007-02-11 22:21 ` Tilman Schmidt 2007-02-12 8:49 ` Geert Uytterhoeven 2007-02-12 15:04 ` Pavel Machek 2007-02-12 15:57 ` Geert Uytterhoeven 2007-02-12 16:55 ` Pavel Machek 2007-02-12 20:38 ` Nigel Cunningham 2007-02-13 10:02 ` Tilman Schmidt 2007-02-10 3:42 ` Matthew Garrett 2007-02-10 4:42 ` Nigel Cunningham
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.