Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On 7/28/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: > Andreas Schwab wrote: > > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Len Brown wrote: > >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a > >> modulo of the size of section __mod_acpi_device_table=144. > > Are you cross-compiling? The definition of kernel_ulong_t won't work on > > x86. > Yes, sorry, should have mentioned that. Build system is x86. Still, > it didn't happen before the recent acpi merge. I also have the same error, which I didn't have in 2.6.22: FATAL: drivers/acpi/ac: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=48. Fix definition of struct acpi_device_id in mod_devicetable.h make[1]: *** [__modpost] Error 1 Build system is x86_64. I'm not cross-compiling, as the target machine (not the build machine) is also x86_64. - Yasha - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Mon 2007-07-30 21:09:33, [EMAIL PROTECTED] wrote: > On Mon, 30 Jul 2007, Len Brown wrote: > > >On Saturday 28 July 2007 12:55, Linus Torvalds wrote: > > > >>So I think the real issue is that we allow that > >>"suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in > >>the first place. It's not supposed to work that way. > > > >I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. > >This e-mail thread would have never happened if it were simply included > >in CONFIG_SMP, always. > > > >I agree, of course, that ACPI should never have had to work-around > >this by selecting HOTPLUG_CPU. But even though it is now done at > >the right layer, I don't see why PM should have to > >be bothered with selecting HOTPLUG_CPU either -- > >it should just come with SMP. > > why do you need hotplug just becouse you have muliple cpus? if you never > have any intention of useing suspend and your hardware doesn't support > hotplugging, why should you have to include the code for it? Because otherwise we have way too many config options, and there are basically no downsides? Too many options => too little testing of each permutation... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Mon, 30 Jul 2007, Len Brown wrote: On Saturday 28 July 2007 12:55, Linus Torvalds wrote: So I think the real issue is that we allow that "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. why do you need hotplug just becouse you have muliple cpus? if you never have any intention of useing suspend and your hardware doesn't support hotplugging, why should you have to include the code for it? Dvaid Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Saturday 28 July 2007 12:55, Linus Torvalds wrote: > So I think the real issue is that we allow that > "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in > the first place. It's not supposed to work that way. I don't see how CONFIG_HOTPLUG_CPU justifies its own existence. This e-mail thread would have never happened if it were simply included in CONFIG_SMP, always. I agree, of course, that ACPI should never have had to work-around this by selecting HOTPLUG_CPU. But even though it is now done at the right layer, I don't see why PM should have to be bothered with selecting HOTPLUG_CPU either -- it should just come with SMP. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote: > > OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require > quite a bit of (compilation) testing on different architectures. Sure. I'm not too worried, the fallout should be of the trivial kind. Also, mind basing it on the (independent) cleanups that Adrian already sent out. This is all intertwined.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Saturday, 28 July 2007 18:55, Linus Torvalds wrote: > > On Sat, 28 Jul 2007, Linus Torvalds wrote: > > > > And it's the *top*level* code that selects HOTPLUG_CPU. Through > > SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. > > In other words, the problem seems to be that > > kernel/power/main.c: > suspend_devices_and_enter() > > does the proper "disable/enable_nonboot_cpus()", but it does so without > having enabled CPU hotplug. > > And you seem to think that it's ACPI that should enable the hotplug, even > though the code that actually needs it is _outside_ ACPI. And I think > that's wrong, and that this is a bug. > > So I think the real issue is that we allow that > "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in > the first place. It's not supposed to work that way. > > Of course, it may well be that other architectures can happily suspend > even with multiple CPU's active, which may be the cause of this mess. But > I really think it shouldn't be ACPI that has to select the CPU hotplug, > since it's not ACPI that _uses_ it in the first place. > > Rafael: making a config option for STR (the same way we have a config > option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU > seems to be the right thing. Len is right in that we do insane things > right now (trying to STR with multiple CPU's still active), and I just > don't think he's the one that should work around it! Well, I agree and that's why I asked. :-) OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require quite a bit of (compilation) testing on different architectures. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Linus Torvalds wrote: > > And it's the *top*level* code that selects HOTPLUG_CPU. Through > SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. In other words, the problem seems to be that kernel/power/main.c: suspend_devices_and_enter() does the proper "disable/enable_nonboot_cpus()", but it does so without having enabled CPU hotplug. And you seem to think that it's ACPI that should enable the hotplug, even though the code that actually needs it is _outside_ ACPI. And I think that's wrong, and that this is a bug. So I think the real issue is that we allow that "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. Of course, it may well be that other architectures can happily suspend even with multiple CPU's active, which may be the cause of this mess. But I really think it shouldn't be ACPI that has to select the CPU hotplug, since it's not ACPI that _uses_ it in the first place. Rafael: making a config option for STR (the same way we have a config option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU seems to be the right thing. Len is right in that we do insane things right now (trying to STR with multiple CPU's still active), and I just don't think he's the one that should work around it! Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Len Brown wrote: > > That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. Explain that to me. There should *be* no resume. ACPI doesn't suspend/resume on its own, I hope. It is all done by the top-level suspend/resume code, not by ACPI. ACPI is a pure helper, and if you've changed that, then I think we need to revert more than a few lines. And it's the *top*level* code that selects HOTPLUG_CPU. Through SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. This is why it's so *totally* and *utterly* bogus for ACPI to select features that it has nothign what-so-ever to do with. In other words: ACPI isn't in the driving seat. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Andreas Schwab wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Len Brown wrote: >>> Hi Linus, >>> >>> please pull from: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git >>> release >> This seems to break ia64 defconfig: >> >> Building modules, stage 2. >> MODPOST 157 modules >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo >> of the size of section __mod_acpi_device_table=144. > > Are you cross-compiling? The definition of kernel_ulong_t won't work on > x86. Yes, sorry, should have mentioned that. Build system is x86. Still, it didn't happen before the recent acpi merge. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday 26 July 2007 16:55, Linus Torvalds wrote: > Anyway, I think the ACPI problem really is as trivial as the following > three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't > force it on him. ... > - # for sleep > - select HOTPLUG_CPU if X86 && SMP > - select SUSPEND_SMP if X86 && SMP That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. While cpu0 is in a known state when the power goes out, without HOTPLUG_CPU the other cpus (and the memory they touch) are in an indeterminate state. Yes, we could invent a new mechanism to offline the other CPUS before suspend and online them upon resume, but that is what the more general HOTPLUG_CPU code does for us already. Indeed, that is pretty much _all_ that HOTPLUG_CPU code does on X86 -- as we don't have any physical hotplug support today beneath this the logical hotplug support -- you could call it CONFIG_CPU_OFFLINE_ONLINE... > A nicer fix might be to also make some of the ACPI helper routines depend > on whether they are needed or not (which in turn will depend on whether > suspend support has been compiled into the kernel), but quite frankly, > that's secondary at least for me. > > So if we have a few ACPI routines that will never get called (because we > don't even enable the interfaces that would *cause* them to be called), I > don't think that's a huge problem. It's a beauty wart, but nobody really > cares (and it's even something that we could get the compiler to optimize > away for us if we really cared). Re: warts, I agree. My question is why the HOTPLUG_CPU=y code is any different. When I compile HOTPLUG_CPU out of an x86_64 kernel, the kernel shrinks by only 18KB, which on a kernel that has ACPI+SMP doesn't seem like such a big wart. Yes, now that you brought it up, I think it would be just dandy if HOTPLUG_CPU simply got folded into SMP -- for I see little to no benefit to having it as its own config option. But on the assumption that you are not swayed (when was the last time you were?) and you still feel strongly we should be able to exclude ACPI_SLEEP and HOTPLUG_CPU from ACPI+SMP kernels, I'll send you a patch do to that properly. It will largely restores things to how we had them in 2.6.22. It looks like a step backwards to me, but you may see it differently. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Jan Dittmer <[EMAIL PROTECTED]> writes: > Len Brown wrote: >> Hi Linus, >> >> please pull from: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release > > This seems to break ia64 defconfig: > > Building modules, stage 2. > MODPOST 157 modules > FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo > of the size of section __mod_acpi_device_table=144. Are you cross-compiling? The definition of kernel_ulong_t won't work on x86. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Fri, 2007-07-27 at 08:26 +0200, Jan Dittmer wrote: > Len Brown wrote: > > Hi Linus, > > > > please pull from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > release > > This seems to break ia64 defconfig: > >Building modules, stage 2. >MODPOST 157 modules > FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo > of the size of section __mod_acpi_device_table=144. > Fix definition of struct acpi_device_id in mod_devicetable.h > make[2]: *** [__modpost] Error 1 > make[1]: *** [modules] Error 2 > make: *** [_all] Error 2 > > gcc 3.3.6, binutils 2.15.94 > > http://l4x.org/k/?d=32569 This is strange, I just compiled on a IA64 with button as module (defconfig), but with gcc version 4.1.2, all is fine. Anyone an idea how to run into that? I won't be able to detailed debug this before Monday, but be sure I will do so then. Thanks, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This seems to break ia64 defconfig: Building modules, stage 2. MODPOST 157 modules FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144. Fix definition of struct acpi_device_id in mod_devicetable.h make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [_all] Error 2 gcc 3.3.6, binutils 2.15.94 http://l4x.org/k/?d=32569 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: > > My point is we have ACPI dependent on PM, so if you want ACPI, you end > up with all of the STR stuff built in, which is what you don't like (if I > understand that correctly). If we have CONFIG_SUSPEND, you'll be able to > choose ACPI alone. :-) Good point. Anyway, I think the ACPI problem really is as trivial as the following three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't force it on him. A nicer fix might be to also make some of the ACPI helper routines depend on whether they are needed or not (which in turn will depend on whether suspend support has been compiled into the kernel), but quite frankly, that's secondary at least for me. So if we have a few ACPI routines that will never get called (because we don't even enable the interfaces that would *cause* them to be called), I don't think that's a huge problem. It's a beauty wart, but nobody really cares (and it's even something that we could get the compiler to optimize away for us if we really cared). Linus --- Don't force-enable suspend/hibernate support just for ACPI It's a totally independent decision for the user whether he wants suspend and/or hibernation support, and ACPI shouldn't care. Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> --- drivers/acpi/Kconfig |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 251344c..22b401b 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -11,9 +11,6 @@ menuconfig ACPI depends on PCI depends on PM select PNP - # for sleep - select HOTPLUG_CPU if X86 && SMP - select SUSPEND_SMP if X86 && SMP default y ---help--- Advanced Configuration and Power Interface (ACPI) support for - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday, 26 July 2007 21:57, Linus Torvalds wrote: > > On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: > > > > Hmm, perhaps we should introduce a CONFIG_SUSPEND and change > > CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on > > CONFIG_PM? > > > > There's quite some code needed only for suspend compiled in when CONFIG_PM > > is > > set ... > > Sounds like a good idea, although I suspect that CONFIG_PM really *is* > fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is > largely useless without at least STR. My point is we have ACPI dependent on PM, so if you want ACPI, you end up with all of the STR stuff built in, which is what you don't like (if I understand that correctly). If we have CONFIG_SUSPEND, you'll be able to choose ACPI alone. :-) > (Yes, I realize that you can do per-driver suspend events etc, but I > suspect not a lot of people have used it). > > But from a logical standpoint, it does make sense to have a separate > config option for the STR support. Exactly. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote: > > Hmm, perhaps we should introduce a CONFIG_SUSPEND and change > CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on > CONFIG_PM? > > There's quite some code needed only for suspend compiled in when CONFIG_PM is > set ... Sounds like a good idea, although I suspect that CONFIG_PM really *is* fairly close to CONFIG_SUSPEND. The thing is, all the stuff it enabled is largely useless without at least STR. (Yes, I realize that you can do per-driver suspend events etc, but I suspect not a lot of people have used it). But from a logical standpoint, it does make sense to have a separate config option for the STR support. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday, 26 July 2007 19:45, Len Brown wrote: > On Thursday 26 July 2007 02:55, Linus Torvalds wrote: > > > > On Thu, 26 Jul 2007, Len Brown wrote: > > > > > > Feel free to share what you know about the benefits vs. the costs > > > of maintaining CONFIG_ACPI_SLEEP as a build option. > > > > Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND > > and STR? > > CONFIG_STR doesn't exist. Hmm, perhaps we should introduce a CONFIG_SUSPEND and change CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on CONFIG_PM? There's quite some code needed only for suspend compiled in when CONFIG_PM is set ... Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Len Brown wrote: > On Thursday 26 July 2007 06:07, Gabriel C wrote: > >>> If you feel that your system has been degraded >>> because it now includes what used to be excluded under >>> CONFIG_ACPI_SLEEP=n, please let me know how. >> Even if I want to SUSPEND* to I can't on my Dell Precision 530 >> boxes , >> SCSI is broken with suspend therefore all these boxes have the whole >> SUSPEND* off, >> all I need is ACPI. > > Linux is already way behind the competition on both STR and STD. > Disabling it because it doesn't work will makes this situation > worse, not better. Heh what else can I do ? The _bug_(s) are reporter for ages. See this one as example ( this kills all my Dells ) and there are a lot more reported. http://bugzilla.kernel.org/show_bug.cgi?id=3062 ... Description From Nathan Bryant 2004-07-13 18:14 ... Notice '2004' and still no one really cares .. So all I can do for now is to disable it. > >> So why you think I want to have this all enabled by default now ? >> Just to bloat the kernel with something doesn't even work for me ? > > Can you be specific about how much additional "bloat" your system > must endure with CONFIG_ACPI_SLEEP=y At least I was not forced to use HOTPLUG_CPU .. Really I just enable what I need / works on my box(es). > config ACPI_SLEEP select HOTPLUG_CPU if X86 && SMP select SUSPEND_SMP if X86 && SMP instead of makeing it dependant on ACPI. >>> If more config options where better, then this >>> would indeed be an improvement over 2.6.22. >>> But more config options isn't better -- except for "some people":-) >> But in this case some config / new config is better. >> >> I do not need ACPI to SUSPEND but to make the box work properly. > > You also don't need a lot of other code in your kernel. > > At some point the complexity of supporting more configuration options > out-weights the benefits of having them. I have a pretty good idea > of the cost of maintaining the code. So my question to you is > is what, exactly, is the benefit of having 2.6.22 CONFIG_ACPI_SLEEP=y > that is now lost in 2.6.23-git? > >> Ohh and isn't better to make 'ACPI_PROCESSOR select SUSPEND_SMP and >> HOTPLUG_CPU if X86 && SMP' ? >> >> ... >> >> config ACPI_PROCESSOR >> tristate "Processor" >> default y >> help >> This driver installs ACPI as the idle handler for Linux, and uses >> ACPI C2 and C3 processor states to save power, on systems that >> support it. It is required by several flavors of cpufreq >> Performance-state drivers. >> >> ... >> >> Is more logical for me to do it here but I may be wrong. > > ACPI_PROCESSOR supports C-states and P-states and is not directly > related to support for system sleep states. If your system is recent, > then it is likely that you want to enable this (and cpufreq) to save power -- > even if you are not interested in system-wide sleep states. Oh ok. Well then add a dummy config onpion, ACPI_DESKTOP_SUSPEND or something , move the 2 selects to there , make it visible in the menu and make it even default y but that way one can disable it. You have a config option more even you hate that =) but no #ifdef's in code. > > -Len > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Linus Torvalds wrote: On Thu, 26 Jul 2007, [EMAIL PROTECTED] wrote: how about the fact that Linus found the problem becouse his system didn't work right? No, it works, it just forces me to use a configuration that I'm not personally interested in on that particular machine. I tend to like using minimal kernels. I don't use modules on most of my machines, and I actually look over my config. Maybe I'm odd. But I think it's a good thing to let people decide what they want (and what they do _not_ want) in their kernels. I think forcing people to use CPU_HOTPLUG is a mistake. There's a reason that existed as a config option. The ACPI changes basically mean that the whole CPU_HOTPLUG config option is totally pointless, because everybody is forced to have it. Indeed -- forced to have a feature that is applicable in reality to 0.0001% of the user population, I'd wager :) I read and hone my .config to utter minimalist perfection too :) So count my vote here too, for -not- wanting CPU_HOTPLUG dead code in my kernel. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
> > I was actually asking how somebody's _system_ has been degraded > > by this change -- but I haven't got an objective answer to that one yet. > > how about the fact that Linus found the problem becouse his system didn't > work right? I guess I missed that message. What system didn't work right, and how did it fail? > > The context for this is the EPA ENERGY STAR specification for Computers, > > which went into effect this month. This spec says that systems which > > can not automatically go into suspend within 15 minutes of idle > > can _not_ earn a sticker. No sticker, no client computer sales to > > governments. > > If Linux can't get STR working, broadly deployed, and enabled by default, > > then our plans for world domination are going to take a significant hit. > > isn't the sticker and specification for hardware? but in any case not all > hardware needs to get that sticker. No, the sticker is for the entire system (HW+SW) as shipped to the customer. ie. It is possible for the same hardware solution running Windows to earn a sticker and land a sale, while Linux fails to earn a sticker and loses the contract. You're right, not all systems need to earn the sticker. Indeed, ENERGY STAR is supposed to be a "premium" brand. However, several governments disqualify bids for large contracts if they do not meet ENERGY STAR. > > yes, I understand that there are SMP systems that want ACPI and don't > > need sleep or CONFIG_HOGPLUG_CPU. However, I don't see major distros > > shipping kernels to their server customers that way, so I didn't think > > it would offend a significant part of the community's sense of freedom > > if this config option were removed. Maybe I was wrong. > > distros aren't everything Apparently a market for more config options of is alive and well. Thank you for helping make the future of Linux more clear to me. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote: > > Can you be specific about how much additional "bloat" your system > must endure with CONFIG_ACPI_SLEEP=y All of CONFIG_HOTPLUG_CPU. Len, this is not about ACPI code. This is about CONFIG_HOTPLUG_CPU. Which I don't want. And which you forced on me. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, [EMAIL PROTECTED] wrote: > > how about the fact that Linus found the problem becouse his system didn't work > right? No, it works, it just forces me to use a configuration that I'm not personally interested in on that particular machine. I tend to like using minimal kernels. I don't use modules on most of my machines, and I actually look over my config. Maybe I'm odd. But I think it's a good thing to let people decide what they want (and what they do _not_ want) in their kernels. I think forcing people to use CPU_HOTPLUG is a mistake. There's a reason that existed as a config option. The ACPI changes basically mean that the whole CPU_HOTPLUG config option is totally pointless, because everybody is forced to have it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thursday 26 July 2007 06:07, Gabriel C wrote: > > If you feel that your system has been degraded > > because it now includes what used to be excluded under > > CONFIG_ACPI_SLEEP=n, please let me know how. > > Even if I want to SUSPEND* to I can't on my Dell Precision 530 > boxes , > SCSI is broken with suspend therefore all these boxes have the whole SUSPEND* > off, > all I need is ACPI. Linux is already way behind the competition on both STR and STD. Disabling it because it doesn't work will makes this situation worse, not better. > So why you think I want to have this all enabled by default now ? > Just to bloat the kernel with something doesn't even work for me ? Can you be specific about how much additional "bloat" your system must endure with CONFIG_ACPI_SLEEP=y > >> config ACPI_SLEEP > >> select HOTPLUG_CPU if X86 && SMP > >> select SUSPEND_SMP if X86 && SMP > >> > >> instead of makeing it dependant on ACPI. > > > > If more config options where better, then this > > would indeed be an improvement over 2.6.22. > > But more config options isn't better -- except for "some people":-) > > But in this case some config / new config is better. > > I do not need ACPI to SUSPEND but to make the box work properly. You also don't need a lot of other code in your kernel. At some point the complexity of supporting more configuration options out-weights the benefits of having them. I have a pretty good idea of the cost of maintaining the code. So my question to you is is what, exactly, is the benefit of having 2.6.22 CONFIG_ACPI_SLEEP=y that is now lost in 2.6.23-git? > Ohh and isn't better to make 'ACPI_PROCESSOR select SUSPEND_SMP and > HOTPLUG_CPU if X86 && SMP' ? > > ... > > config ACPI_PROCESSOR > tristate "Processor" > default y > help > This driver installs ACPI as the idle handler for Linux, and uses > ACPI C2 and C3 processor states to save power, on systems that > support it. It is required by several flavors of cpufreq > Performance-state drivers. > > ... > > Is more logical for me to do it here but I may be wrong. ACPI_PROCESSOR supports C-states and P-states and is not directly related to support for system sleep states. If your system is recent, then it is likely that you want to enable this (and cpufreq) to save power -- even if you are not interested in system-wide sleep states. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote: On Thursday 26 July 2007 02:55, Linus Torvalds wrote: On Thu, 26 Jul 2007, Len Brown wrote: If you feel that your system has been degraded because it now includes what used to be excluded under CONFIG_ACPI_SLEEP=n, please let me know how. I feel that I get asked to include a feature that (a) I have no interest in on that machine (b) I didn't need to include before. What was the advantage? And what was it that caused something like this to be a post-rc1 thing. That makes me really unhappy. This is a *regression*. I'm sorry that one fewer config options has offended your feeling of freedom, honestly, I am. I was actually asking how somebody's _system_ has been degraded by this change -- but I haven't got an objective answer to that one yet. how about the fact that Linus found the problem becouse his system didn't work right? As I said in my pull request, I agree that the D-state fixes ideally should have merged a week earlier -- before the rc1 cutoff. Indeed, we had a hack that could have gone up much earlier. However, we waited for Rafael's more general list-blessed solution -- and it turned out that solution tripped over CONFIG_ACPI_SLEEP=n. The reason is because there is a dependency between D-states and S-states. In particular, devices which are enabled to be system wakeup devices can be limited in what D-states they can enter (else they may no longer be able to wake up the system when it is suspended) you are assuming that people want to suspend I figured that rather than adding more ifdefs to solve that problem, it was simpler to remove ifdefs. I was also shocked to find i386 defconfig with CONFIG_ACPI_SLEEP=n. Maybe others are not shocked by this and there is a reason that defconfig on x86_64 supports sleep and i386 does not. I assumed it was a bug, maybe I was wrong. The context for this is the EPA ENERGY STAR specification for Computers, which went into effect this month. This spec says that systems which can not automatically go into suspend within 15 minutes of idle can _not_ earn a sticker. No sticker, no client computer sales to governments. If Linux can't get STR working, broadly deployed, and enabled by default, then our plans for world domination are going to take a significant hit. isn't the sticker and specification for hardware? but in any case not all hardware needs to get that sticker. yes, I understand that there are SMP systems that want ACPI and don't need sleep or CONFIG_HOGPLUG_CPU. However, I don't see major distros shipping kernels to their server customers that way, so I didn't think it would offend a significant part of the community's sense of freedom if this config option were removed. Maybe I was wrong. distros aren't everything Obviously, your vote counts more than the sum total of a lot of the community, so if you want me to put a config option in to allow ACPI w/o ACPI_SLEEP, I'll simply do it for you. However, I could do a better job of it if I had a clear understanding of what the technical benefit of that option is supposed to be, and how it will make Linux better. the idea is that code that doesn't get compiled into the kernel can't cause the system to misbehave. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote: > > I was actually asking how somebody's _system_ has been degraded > by this change -- but I haven't got an objective answer to that one yet. According to that logic, we should always compile *everything* in. Do you see the problem? And can you realize that this should not have happened after -rc1? So send me the patch to undo this breakage, and stop making excuses. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thursday 26 July 2007 02:55, Linus Torvalds wrote: > > On Thu, 26 Jul 2007, Len Brown wrote: > > > > Feel free to share what you know about the benefits vs. the costs > > of maintaining CONFIG_ACPI_SLEEP as a build option. > > Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND > and STR? CONFIG_STR doesn't exist. I agree it is an attractive notion to have a high level feature presented to the user, and that the tools should select what is needed to satisfy the user's request. Unfortunately Kconfig is exceptionally bad at supporting this model. "depend" frustrates users by making config options vanish without explanation, and "select" is fundamentally broken because it doesn't enforce dependencies. > > If you feel that your system has been degraded > > because it now includes what used to be excluded under > > CONFIG_ACPI_SLEEP=n, please let me know how. > > I feel that I get asked to include a feature that > (a) I have no interest in on that machine > (b) I didn't need to include before. > > What was the advantage? And what was it that caused something like this to > be a post-rc1 thing. That makes me really unhappy. This is a *regression*. I'm sorry that one fewer config options has offended your feeling of freedom, honestly, I am. I was actually asking how somebody's _system_ has been degraded by this change -- but I haven't got an objective answer to that one yet. As I said in my pull request, I agree that the D-state fixes ideally should have merged a week earlier -- before the rc1 cutoff. Indeed, we had a hack that could have gone up much earlier. However, we waited for Rafael's more general list-blessed solution -- and it turned out that solution tripped over CONFIG_ACPI_SLEEP=n. The reason is because there is a dependency between D-states and S-states. In particular, devices which are enabled to be system wakeup devices can be limited in what D-states they can enter (else they may no longer be able to wake up the system when it is suspended) I figured that rather than adding more ifdefs to solve that problem, it was simpler to remove ifdefs. I was also shocked to find i386 defconfig with CONFIG_ACPI_SLEEP=n. Maybe others are not shocked by this and there is a reason that defconfig on x86_64 supports sleep and i386 does not. I assumed it was a bug, maybe I was wrong. The context for this is the EPA ENERGY STAR specification for Computers, which went into effect this month. This spec says that systems which can not automatically go into suspend within 15 minutes of idle can _not_ earn a sticker. No sticker, no client computer sales to governments. If Linux can't get STR working, broadly deployed, and enabled by default, then our plans for world domination are going to take a significant hit. yes, I understand that there are SMP systems that want ACPI and don't need sleep or CONFIG_HOGPLUG_CPU. However, I don't see major distros shipping kernels to their server customers that way, so I didn't think it would offend a significant part of the community's sense of freedom if this config option were removed. Maybe I was wrong. Obviously, your vote counts more than the sum total of a lot of the community, so if you want me to put a config option in to allow ACPI w/o ACPI_SLEEP, I'll simply do it for you. However, I could do a better job of it if I had a clear understanding of what the technical benefit of that option is supposed to be, and how it will make Linux better. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Len Brown wrote: > On Wednesday 25 July 2007 22:20, [EMAIL PROTECTED] wrote: >> On Wed, 25 Jul 2007, Len Brown wrote: >> >>> On Wednesday 25 July 2007 14:48, Linus Torvalds wrote: >>> ... ACPI now seems to select CPU hotplug. Why? >>> ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support, >>> and that requires HOTPLUG_CPU=y. >>> Well *require* if I want SUSPEND*. >>> Note that ACPI=y SMP=n systems do not need it, >>> and thus will not select HOTPLUG_CPU=y >>> That is just *broken*. Sure, if you select STR or hibernation, we need CPU hotplug, but just for picking ACPI? Why? >>> My assumption is that if somebody selects CONFIG_ACPI, >>> that 99% of the time, they intend that to include support for >>> the ACPI hooks for system sleep states. >>> >>> Conversely, supporting the 1% of people who don't want it >>> isn't worth messing with the 99% who do, nor is >>> the burden of yet another config option to maintain and >>> #ifdefs in the code. >> so you are saying that you know better then we do what we need? > > Feel free to share what you know about the benefits vs. the costs > of maintaining CONFIG_ACPI_SLEEP as a build option. > >> some people configure ACPI only becouse their system won't work properly >> without it. they have no intention of ever doing a STR or hibernate. > > I agree. > > Further, I expect that 100% - (some people %) = 99% > > If you feel that your system has been degraded > because it now includes what used to be excluded under > CONFIG_ACPI_SLEEP=n, please let me know how. Even if I want to SUSPEND* to I can't on my Dell Precision 530 boxes , SCSI is broken with suspend therefore all these boxes have the whole SUSPEND* off, all I need is ACPI. So why you think I want to have this all enabled by default now ? Just to bloat the kernel with something doesn't even work for me ? And I don't get from where you have the '99%' thing ? > >>> On UP, they'd get ACPI system sleep support 100% of the time >>> by default, but on SMP this option had become problematic. >>> >>> We used to have this: >>> >>> if ACPI >>> ... >>> config ACPI_SLEEP >>>bool "Sleep States" >>>depends on X86 && (!SMP || SUSPEND_SMP) >>>depends on PM >>>default y >>> >>> So the poster-child failure was i386/defconfig itself... >>> It couldn't support suspend to RAM because it didn't include >>> CONFIG_ACPI_SLEEP. Not trivial for a user to select it >>> when it doesn't even appear on the menu. It doesn't appear >>> because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't >>> appear either -- because CONFIG_HOTPLUG_CPU isn't selected. >> so have something like >> >> config ACPI_SLEEP >> select HOTPLUG_CPU if X86 && SMP >> select SUSPEND_SMP if X86 && SMP >> >> instead of makeing it dependant on ACPI. > > If more config options where better, then this > would indeed be an improvement over 2.6.22. > But more config options isn't better -- except for "some people":-) But in this case some config / new config is better. I do not need ACPI to SUSPEND but to make the box work properly. Ohh and isn't better to make 'ACPI_PROCESSOR select SUSPEND_SMP and HOTPLUG_CPU if X86 && SMP' ? ... config ACPI_PROCESSOR tristate "Processor" default y help This driver installs ACPI as the idle handler for Linux, and uses ACPI C2 and C3 processor states to save power, on systems that support it. It is required by several flavors of cpufreq Performance-state drivers. ... Is more logical for me to do it here but I may be wrong. > > thanks. > -Len > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Wed, 25 Jul 2007, Len Brown wrote: > On Wednesday 25 July 2007 14:48, Linus Torvalds wrote: > > > ... ACPI now seems to select CPU hotplug. Why? > > ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support, > and that requires HOTPLUG_CPU=y. .. and why do you think I want system sleep support? That's the bug. > Note that ACPI=y SMP=n systems do not need it, > and thus will not select HOTPLUG_CPU=y I want SMP, dammit. This machine has multi-core. And I want ACPI. I just don't want the system sleep thing. I didn't have it before, I don't need it, I don't want it. > My assumption is that if somebody selects CONFIG_ACPI, > that 99% of the time, they intend that to include support for > the ACPI hooks for system sleep states. That wasn't true before, and it makes no sense what-so-ever as an assumption. The system sleep states are mostly usable on laptops. Not always even then. They are seldom used on desktops or servers, but both of those are often SMP machines, and certainly want ACPI. So your "99%" makes no sense. > So today we have this: > > menuconfig ACPI > ... > select HOTPLUG_CPU if X86 && SMP > select SUSPEND_SMP if X86 && SMP But why the *hell* is this dependent on ACPI? Why not just do ACPI_SLEEP, and have *that* do "select HOTPLUG_CPU/SUSPEND_CPU". > Which I think leads to fewer surprises, and less complicated code. That makes no sense. You're tying together things that have *nothing* to do with each other. As mentioned (and as is *obvious*), pretty much everybody who has a multi-core CPU on x86 wants ACPI and SMP. But the set of people who want to sw-suspend such a machine is *much* smaller. There is no 99%. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote: > > Feel free to share what you know about the benefits vs. the costs > of maintaining CONFIG_ACPI_SLEEP as a build option. Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND and STR? > If you feel that your system has been degraded > because it now includes what used to be excluded under > CONFIG_ACPI_SLEEP=n, please let me know how. I feel that I get asked to include a feature that (a) I have no interest in on that machine (b) I didn't need to include before. What was the advantage? And what was it that caused something like this to be a post-rc1 thing. That makes me really unhappy. This is a *regression*. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
[EMAIL PROTECTED] wrote: > On Thu, 26 Jul 2007, Len Brown wrote: > > On Wednesday 25 July 2007 16:40, Al Boldi wrote: > >> Linus Torvalds wrote: > >>> On Wed, 25 Jul 2007, Len Brown wrote: > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > release > > Fixes regressions -- a build failure, an oops, some dmesg spam. > Also fixes some D-state issues and adds ACPI module auto-loading. > Yes, I'd hoped to get the last two in before rc1. > I'm hopeful that a couple-days into rc2 is sufficiently early for > them. > >>> > >>> I hate pulling this, but I did. However, what I hate even more after > >>> having done so is that ACPI now seems to select CPU hotplug. Why? > >>> > >>> That is just *broken*. Sure, if you select STR or hibernation, we need > >>> CPU hotplug, > >> > >> You are kidding, right? CPU hotplug is broken big time; it kills a > >> machine like virus-scanner. I always turn it of as a rule. And now > >> you want STR/STD to be dependent on it? Even on UP? Why? > > > > CPU_HOTPLUG is needed to take the non-boot processors off-line before > > the suspend, and to bring them on-line upon the resume. If you have > > specific problems with bringing logical processors offline and online, > > then please speak up because many are depending on this functionality > > working. > > nobody is arguing that CPU_HOTPLUG should not be a requirement for > suspend, what we are questioning is why simply enabling ACPI should > require CPU_HOTPLUG. > > not everyone who configures ACPI wants to use suspend (of any flavor) Actually, I would go one step further and just rip out hotplug from the kernel proper, and let userland handle it. Really, just like devfs, hotplug has no place in the kernel. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote: CONFIG_ACPI_SLEEP. Not trivial for a user to select it when it doesn't even appear on the menu. It doesn't appear because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't appear either -- because CONFIG_HOTPLUG_CPU isn't selected. so have something like config ACPI_SLEEP select HOTPLUG_CPU if X86 && SMP select SUSPEND_SMP if X86 && SMP instead of makeing it dependant on ACPI. If more config options where better, then this would indeed be an improvement over 2.6.22. But more config options isn't better -- except for "some people":-) coupling unrelated fetures togeather isn't better either. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Wednesday 25 July 2007 22:20, [EMAIL PROTECTED] wrote: > On Wed, 25 Jul 2007, Len Brown wrote: > > > On Wednesday 25 July 2007 14:48, Linus Torvalds wrote: > > > >> ... ACPI now seems to select CPU hotplug. Why? > > > > ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support, > > and that requires HOTPLUG_CPU=y. > > > > Note that ACPI=y SMP=n systems do not need it, > > and thus will not select HOTPLUG_CPU=y > > > >> That is just *broken*. Sure, if you select STR or hibernation, we need CPU > >> hotplug, but just for picking ACPI? Why? > > > > My assumption is that if somebody selects CONFIG_ACPI, > > that 99% of the time, they intend that to include support for > > the ACPI hooks for system sleep states. > > > > Conversely, supporting the 1% of people who don't want it > > isn't worth messing with the 99% who do, nor is > > the burden of yet another config option to maintain and > > #ifdefs in the code. > > so you are saying that you know better then we do what we need? Feel free to share what you know about the benefits vs. the costs of maintaining CONFIG_ACPI_SLEEP as a build option. > some people configure ACPI only becouse their system won't work properly > without it. they have no intention of ever doing a STR or hibernate. I agree. Further, I expect that 100% - (some people %) = 99% If you feel that your system has been degraded because it now includes what used to be excluded under CONFIG_ACPI_SLEEP=n, please let me know how. > > On UP, they'd get ACPI system sleep support 100% of the time > > by default, but on SMP this option had become problematic. > > > > We used to have this: > > > > if ACPI > > ... > > config ACPI_SLEEP > >bool "Sleep States" > >depends on X86 && (!SMP || SUSPEND_SMP) > >depends on PM > >default y > > > > So the poster-child failure was i386/defconfig itself... > > It couldn't support suspend to RAM because it didn't include > > CONFIG_ACPI_SLEEP. Not trivial for a user to select it > > when it doesn't even appear on the menu. It doesn't appear > > because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't > > appear either -- because CONFIG_HOTPLUG_CPU isn't selected. > > so have something like > > config ACPI_SLEEP > select HOTPLUG_CPU if X86 && SMP > select SUSPEND_SMP if X86 && SMP > > instead of makeing it dependant on ACPI. If more config options where better, then this would indeed be an improvement over 2.6.22. But more config options isn't better -- except for "some people":-) thanks. -Len > > Most users don't want that. > > > > So today we have this: > > > > menuconfig ACPI > > ... > >select HOTPLUG_CPU if X86 && SMP > >select SUSPEND_SMP if X86 && SMP > > > > Which I think leads to fewer surprises, and less complicated code. > > (even though using select itself is fraught with peril:-) > > > > thanks, > > -Len > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Thu, 26 Jul 2007, Len Brown wrote: On Wednesday 25 July 2007 16:40, Al Boldi wrote: Linus Torvalds wrote: On Wed, 25 Jul 2007, Len Brown wrote: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release Fixes regressions -- a build failure, an oops, some dmesg spam. Also fixes some D-state issues and adds ACPI module auto-loading. Yes, I'd hoped to get the last two in before rc1. I'm hopeful that a couple-days into rc2 is sufficiently early for them. I hate pulling this, but I did. However, what I hate even more after having done so is that ACPI now seems to select CPU hotplug. Why? That is just *broken*. Sure, if you select STR or hibernation, we need CPU hotplug, You are kidding, right? CPU hotplug is broken big time; it kills a machine like virus-scanner. I always turn it of as a rule. And now you want STR/STD to be dependent on it? Even on UP? Why? CPU_HOTPLUG is needed to take the non-boot processors off-line before the suspend, and to bring them on-line upon the resume. If you have specific problems with bringing logical processors offline and online, then please speak up because many are depending on this functionality working. nobody is arguing that CPU_HOTPLUG should not be a requirement for suspend, what we are questioning is why simply enabling ACPI should require CPU_HOTPLUG. not everyone who configures ACPI wants to use suspend (of any flavor) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Wednesday 25 July 2007 16:40, Al Boldi wrote: > Linus Torvalds wrote: > > On Wed, 25 Jul 2007, Len Brown wrote: > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > > release > > > > > > Fixes regressions -- a build failure, an oops, some dmesg spam. > > > Also fixes some D-state issues and adds ACPI module auto-loading. > > > Yes, I'd hoped to get the last two in before rc1. > > > I'm hopeful that a couple-days into rc2 is sufficiently early for them. > > > > I hate pulling this, but I did. However, what I hate even more after > > having done so is that ACPI now seems to select CPU hotplug. Why? > > > > That is just *broken*. Sure, if you select STR or hibernation, we need CPU > > hotplug, > > You are kidding, right? CPU hotplug is broken big time; it kills a machine > like virus-scanner. I always turn it of as a rule. And now you want > STR/STD to be dependent on it? Even on UP? Why? CPU_HOTPLUG is needed to take the non-boot processors off-line before the suspend, and to bring them on-line upon the resume. If you have specific problems with bringing logical processors offline and online, then please speak up because many are depending on this functionality working. SMP system sleep support has always depended on CPU_HOTPLUG, per above. No, uniprocessor system sleep does not depend on CPU_HOTPLUG. -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Wed, 25 Jul 2007, Len Brown wrote: On Wednesday 25 July 2007 14:48, Linus Torvalds wrote: ... ACPI now seems to select CPU hotplug. Why? ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support, and that requires HOTPLUG_CPU=y. Note that ACPI=y SMP=n systems do not need it, and thus will not select HOTPLUG_CPU=y That is just *broken*. Sure, if you select STR or hibernation, we need CPU hotplug, but just for picking ACPI? Why? My assumption is that if somebody selects CONFIG_ACPI, that 99% of the time, they intend that to include support for the ACPI hooks for system sleep states. Conversely, supporting the 1% of people who don't want it isn't worth messing with the 99% who do, nor is the burden of yet another config option to maintain and #ifdefs in the code. so you are saying that you know better then we do what we need? some people configure ACPI only becouse their system won't work properly without it. they have no intention of ever doing a STR or hibernate. David Lang On UP, they'd get ACPI system sleep support 100% of the time by default, but on SMP this option had become problematic. We used to have this: if ACPI ... config ACPI_SLEEP bool "Sleep States" depends on X86 && (!SMP || SUSPEND_SMP) depends on PM default y So the poster-child failure was i386/defconfig itself... It couldn't support suspend to RAM because it didn't include CONFIG_ACPI_SLEEP. Not trivial for a user to select it when it doesn't even appear on the menu. It doesn't appear because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't appear either -- because CONFIG_HOTPLUG_CPU isn't selected. so have something like config ACPI_SLEEP select HOTPLUG_CPU if X86 && SMP select SUSPEND_SMP if X86 && SMP instead of makeing it dependant on ACPI. David Lang Most users don't want that. So today we have this: menuconfig ACPI ... select HOTPLUG_CPU if X86 && SMP select SUSPEND_SMP if X86 && SMP Which I think leads to fewer surprises, and less complicated code. (even though using select itself is fraught with peril:-) thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Wednesday 25 July 2007 14:48, Linus Torvalds wrote: > ... ACPI now seems to select CPU hotplug. Why? ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support, and that requires HOTPLUG_CPU=y. Note that ACPI=y SMP=n systems do not need it, and thus will not select HOTPLUG_CPU=y > That is just *broken*. Sure, if you select STR or hibernation, we need CPU > hotplug, but just for picking ACPI? Why? My assumption is that if somebody selects CONFIG_ACPI, that 99% of the time, they intend that to include support for the ACPI hooks for system sleep states. Conversely, supporting the 1% of people who don't want it isn't worth messing with the 99% who do, nor is the burden of yet another config option to maintain and #ifdefs in the code. On UP, they'd get ACPI system sleep support 100% of the time by default, but on SMP this option had become problematic. We used to have this: if ACPI ... config ACPI_SLEEP bool "Sleep States" depends on X86 && (!SMP || SUSPEND_SMP) depends on PM default y So the poster-child failure was i386/defconfig itself... It couldn't support suspend to RAM because it didn't include CONFIG_ACPI_SLEEP. Not trivial for a user to select it when it doesn't even appear on the menu. It doesn't appear because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't appear either -- because CONFIG_HOTPLUG_CPU isn't selected. Most users don't want that. So today we have this: menuconfig ACPI ... select HOTPLUG_CPU if X86 && SMP select SUSPEND_SMP if X86 && SMP Which I think leads to fewer surprises, and less complicated code. (even though using select itself is fraught with peril:-) thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Linus Torvalds wrote: > On Wed, 25 Jul 2007, Len Brown wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > release > > > > Fixes regressions -- a build failure, an oops, some dmesg spam. > > Also fixes some D-state issues and adds ACPI module auto-loading. > > Yes, I'd hoped to get the last two in before rc1. > > I'm hopeful that a couple-days into rc2 is sufficiently early for them. > > I hate pulling this, but I did. However, what I hate even more after > having done so is that ACPI now seems to select CPU hotplug. Why? > > That is just *broken*. Sure, if you select STR or hibernation, we need CPU > hotplug, You are kidding, right? CPU hotplug is broken big time; it kills a machine like virus-scanner. I always turn it of as a rule. And now you want STR/STD to be dependent on it? Even on UP? Why? Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
On Wed, 25 Jul 2007, Len Brown wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release > > Fixes regressions -- a build failure, an oops, some dmesg spam. > Also fixes some D-state issues and adds ACPI module auto-loading. > Yes, I'd hoped to get the last two in before rc1. > I'm hopeful that a couple-days into rc2 is sufficiently early for them. I hate pulling this, but I did. However, what I hate even more after having done so is that ACPI now seems to select CPU hotplug. Why? That is just *broken*. Sure, if you select STR or hibernation, we need CPU hotplug, but just for picking ACPI? Why? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
