On Tue, 9 Oct 2007, Kevin wrote:
>
> I don't own a digital camera but I did jot the info down by hand.
Heh, yeah, that's what I used to do too (and still do if a camera isn't
handy).
> Call Trace:
> [<c010e852>] apm_bios_call_simple+0x92/0x110
> [<c0285a0>] acpi_hw_clear_gpe_block+00/0x32
> [<c010e8ec>] set_system_power_state+0x1c/0x30
> [<c010f93a>] apm_system_power_off+0x6a/0x80
> [<c010f8d0>] apm_system_power_off+0x0/0x80
> [<c010e434>] native_machine_power_off+0x14/0x20
> [<c010e406>] machine_power_off+0x6/0x10
> [<c0127cb9>] sys_reboot+0x99/0x140
>...
> Code: Bad EIP Value
> EIP: [<00007825>] 0x7825 SS:ESP 0068:e7305de8
> /etc/rc.d/rc.0: Line 261: 2796 Segmentation Fault /sbin/poweroff
Ahh. APM. That does explain the strange EIP register values: we're jumping
into the BIOS, and the BIOS is doing something unexpected.
However, that doesn't really explain the oops, because I don't think
anything changed in APM from 2.6.22->23, and in particular, I don't think
it has anything to do with the thing that caused problems for PPC.
We did have some APM *detection* changes, and maybe APM wasn't even
detected for you before, or it was detected differently. That would be due
to the bootup changes, I'm Cc'ing Peter Anvin (and the kernel mailing
list, in case somebody else see a pattern to this).
Can you please
- try with APM turned off (APM really shouldn't be useful on any machines
built in the last ten years or so), just to verify that things work
without APM.
- send the bootup "dmesg" output and a machine description (and please
keep people Cc'd - sending things just to me is a sure-fire way to get
things dropped eventually, if only because I'm a lazy clutz).
- what was the last kernel that worked (and if you can bisect the
problem, that would likely help enormously)
Thanks,
Linus
Linus Torvalds wrote:
>
> We did have some APM *detection* changes, and maybe APM wasn't even
> detected for you before, or it was detected differently. That would be due
> to the bootup changes, I'm Cc'ing Peter Anvin (and the kernel mailing
> list, in case somebody else see a pattern to this).
>
Well, I did have exactly one bug report about APM, and that was a user
who had inadvertently flipped his CONFIG_APM setting (from on to off in
his particular case -- it was a 10-year-old machine without ACPI.)
-hpa
On Wednesday 10 October 2007 07:57:52 am you wrote:
> On Tue, 9 Oct 2007, Kevin wrote:
> > I don't own a digital camera but I did jot the info down by hand.
>
> Heh, yeah, that's what I used to do too (and still do if a camera isn't
> handy).
>
> > Call Trace:
> > [<c010e852>] apm_bios_call_simple+0x92/0x110
> > [<c0285a0>] acpi_hw_clear_gpe_block+00/0x32
> > [<c010e8ec>] set_system_power_state+0x1c/0x30
> > [<c010f93a>] apm_system_power_off+0x6a/0x80
> > [<c010f8d0>] apm_system_power_off+0x0/0x80
> > [<c010e434>] native_machine_power_off+0x14/0x20
> > [<c010e406>] machine_power_off+0x6/0x10
> > [<c0127cb9>] sys_reboot+0x99/0x140
> >...
> > Code: Bad EIP Value
> > EIP: [<00007825>] 0x7825 SS:ESP 0068:e7305de8
> > /etc/rc.d/rc.0: Line 261: 2796 Segmentation Fault /sbin/poweroff
>
> Ahh. APM. That does explain the strange EIP register values: we're jumping
> into the BIOS, and the BIOS is doing something unexpected.
>
> However, that doesn't really explain the oops, because I don't think
> anything changed in APM from 2.6.22->23, and in particular, I don't think
> it has anything to do with the thing that caused problems for PPC.
>
> We did have some APM *detection* changes, and maybe APM wasn't even
> detected for you before, or it was detected differently. That would be due
> to the bootup changes, I'm Cc'ing Peter Anvin (and the kernel mailing
> list, in case somebody else see a pattern to this).
>
> Can you please
> - try with APM turned off (APM really shouldn't be useful on any machines
> built in the last ten years or so), just to verify that things work
> without APM.
That fixed the problem.
> - send the bootup "dmesg" output and a machine description (and please
> keep people Cc'd - sending things just to me is a sure-fire way to get
> things dropped eventually, if only because I'm a lazy clutz).
Both "dmesg" (before and after the fix) are attached. Also, here is the
machine specs:
Gigabyte Main Board
Name GA-K8NSC -939
Type / Chipset Socket 939 / nVidia nForce3 250 Gb Chipset
Dimensions +++ 35 mm (58 mm radius) around the socket to the next capacitor
or other parts of the
mainboard - for further information see Fit for Fan.
The overall size is 305 x 245mm.
Slots +++ 5x pci, 1x AGP (1.5V 4x/8x), 4x DDR PC2100 - PC3200 (max. 4GB RAM)
Connectors
+++ 1x Floppy, 4x UDMA133, 2x SATA150, 2x seriell, 1x parallel, 2x PS/2,
onBoard 10/100/1000 Mbps base-T Ethernet LAN (Marvell 8001),
8x USB 2.0/1.1 (4x internal but mounting bracket isn't included),
8-Channel AC'97 RealTek ALC850 onboard (1x int. CD in, 1x int. S/PDIF, ext.
Line in, ext. Mic, ext. Line out, int. optional connector for 8-Channel Audio
Combo Kit, not included)
and 3x fan connectors (1x used for chipset fan).
Vcore ++++ BIOS between 0.80 Volt and 1.7 Volt in steps of 0.025 and 0.05
Volt / Jumper not available
Multiplier ++++ BIOS between 4x and 25x (max multi depends on used CPU) /
Jumper not available
FSB ++++ BIOS between 200 and 455 MHz (AGP 66 - 100 MHz) / Jumper not
available
VIO/VDD ++++ VDDR +0.1 - +0.2 / VAGP +0.1 - +0.3 / V HT-Link +0.1 - +0.3
Home page:
http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=1881
BIOS upgrade (F8)
http://www.gigabyte.com.tw/Support/Motherboard/BIOS_Model.aspx?ProductID=1881
Also lspci -v
root@fosters:/home/kevin# lspci -v
00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at f4000000 (32-bit, prefetchable) [size=32M]
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [c0] AGP version 2.0
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
Subsystem: Giga-byte Technology Unknown device 0c11
Flags: bus master, 66MHz, fast devsel, latency 0
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)
Subsystem: Giga-byte Technology Unknown device 0c11
Flags: 66MHz, fast devsel, IRQ 11
I/O ports at e400 [size=32]
I/O ports at 1c00 [size=64]
I/O ports at 2000 [size=64]
Capabilities: [44] Power Management version 2
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
(prog-if 10 [OHCI])
Subsystem: Giga-byte Technology Unknown device 5004
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 9
Memory at fd003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
(prog-if 10 [OHCI])
Subsystem: Giga-byte Technology Unknown device 5004
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 9
Memory at fd004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller
(rev a2) (prog-if 20 [EHCI])
Subsystem: Giga-byte Technology Unknown device 5004
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 9
Memory at fd005000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb AC'97
Audio Controller (rev a1)
Subsystem: Giga-byte Technology Unknown device a002
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 7
I/O ports at bc00 [size=256]
I/O ports at c000 [size=128]
Memory at fd001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5)
(rev a2) (prog-if 8a [Master SecP PriP])
Subsystem: Giga-byte Technology Unknown device 5002
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled]
[size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled]
[size=1]
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled]
[size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled]
[size=1]
I/O ports at f000 [size=16]
Capabilities: [44] Power Management version 2
00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5)
(rev a2) (prog-if 85 [Master SecO PriO])
Subsystem: Giga-byte Technology Unknown device b002
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11
I/O ports at 09f0 [size=8]
I/O ports at 0bf0 [size=4]
I/O ports at 0970 [size=8]
I/O ports at 0b70 [size=4]
I/O ports at dc00 [size=16]
I/O ports at e000 [size=128]
Capabilities: [44] Power Management version 2
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge
(rev a2) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 16
Bus: primary=00, secondary=01, subordinate=01, sec-latency=10
Memory behind bridge: f8000000-faffffff
Prefetchable memory behind bridge: f6000000-f7ffffff
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev
a2) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=128
I/O behind bridge: 0000a000-0000afff
Memory behind bridge: fb000000-fcffffff
Prefetchable memory behind bridge: 88000000-880fffff
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: [80] HyperTransport: Host or Secondary Interface
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
Flags: fast devsel
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
Flags: fast devsel
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
Flags: fast devsel
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01)
(prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc. Millennium G550 Dual Head DDR 32Mb
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at f6000000 (32-bit, prefetchable) [size=32M]
Memory at f8000000 (32-bit, non-prefetchable) [size=16K]
Memory at f9000000 (32-bit, non-prefetchable) [size=8M]
[virtual] Expansion ROM at f8020000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Capabilities: [f0] AGP version 2.0
02:06.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 4
I/O ports at a000 [size=32]
Capabilities: [80] Power Management version 2
02:06.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 50) (prog-if 00 [UHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller
Flags: bus master, medium devsel, latency 32, IRQ 10
I/O ports at a400 [size=32]
Capabilities: [80] Power Management version 2
02:06.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) (prog-if 20
[EHCI])
Subsystem: VIA Technologies, Inc. (Wrong ID) Unknown device 1234
Flags: bus master, medium devsel, latency 32, IRQ 3
Memory at fc004000 (32-bit, non-prefetchable) [size=256]
Capabilities: [80] Power Management version 2
02:07.0 Multimedia controller: Philips Semiconductors SAA7130 Video Broadcast
Decoder (rev 01)
Subsystem: Avermedia Technologies Inc AVerMedia DVD EZMaker
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fc005000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [40] Power Management version 1
02:0b.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit
Ethernet Controller (rev 13)
Subsystem: Giga-byte Technology Marvell 88E8001 Gigabit Ethernet
Controller (Gigabyte)
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
Memory at fc000000 (32-bit, non-prefetchable) [size=16K]
I/O ports at a800 [size=256]
[virtual] Expansion ROM at 88000000 [disabled] [size=128K]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
root@fosters:/home/kevin#
> - what was the last kernel that worked (and if you can bisect the
> problem, that would likely help enormously)
The last kernel I used was 6.2.22 the "dmesg" the file is attached:
dmesg 2.6.22 line 158 > apm: overridden by ACPI.
dmesg, APM on, has no line > apm: overridden by ACPI.
Also, a diff -u file is enclosed in case it might help.
> Thanks,
>
>
> Linus
Hope this helps
Kevin
--
----------------------- ++ ---------------------------
Kevin Myers
? ???? ? [email protected]
??? ?http://members.cox.net/jwblack
----------------------- ++ ---------------------------
--
Your Fortune:
The Killer Ducks are coming!!!
On Wed, 10 Oct 2007, Kevin wrote:
>
> The last kernel I used was 6.2.22 the "dmesg" the file is attached:
>
> dmesg 2.6.22 line 158 > apm: overridden by ACPI.
>
> dmesg, APM on, has no line > apm: overridden by ACPI.
Ok, this is the real reason.
The APM code does:
if (PM_IS_ACTIVE()) {
printk(KERN_NOTICE "apm: overridden by ACPI.\n");
apm_info.disabled = 1;
return -ENODEV;
}
and in previous kernels that would notice that you have ACPI enabled, and
APM gets shut out, and you never see your buggy APM BIOS.
In 2.6.23, this apparently doesn't happen for some reason.
And I think I see the problem: it's a config change. You don't have
PM_LEGACY enabled. Your config file diff shows:
-CONFIG_PM_LEGACY=y
+# CONFIG_PM_LEGACY is not set
I suspect we should make CONFIG_APM either depend on, or select,
PM_LEGACY. But as far as I can see, nothing has actually changed in this
area in the kernel, and this bug has been there before - just your config
change made it appear.
Rafael? Stephen? Opinions? I'd think that making APM depend on
CONFIG_PM_LEGACY is the right thing to do these days..
Linus
Linus Torvalds wrote:
>
> On Wed, 10 Oct 2007, Kevin wrote:
>> The last kernel I used was 6.2.22 the "dmesg" the file is attached:
>>
>> dmesg 2.6.22 line 158 > apm: overridden by ACPI.
>>
>> dmesg, APM on, has no line > apm: overridden by ACPI.
>
> Ok, this is the real reason.
>
> The APM code does:
>
> if (PM_IS_ACTIVE()) {
> printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> apm_info.disabled = 1;
> return -ENODEV;
> }
>
> and in previous kernels that would notice that you have ACPI enabled, and
> APM gets shut out, and you never see your buggy APM BIOS.
>
> In 2.6.23, this apparently doesn't happen for some reason.
>
> And I think I see the problem: it's a config change. You don't have
> PM_LEGACY enabled. Your config file diff shows:
>
> -CONFIG_PM_LEGACY=y
> +# CONFIG_PM_LEGACY is not set
>
> I suspect we should make CONFIG_APM either depend on, or select,
> PM_LEGACY. But as far as I can see, nothing has actually changed in this
> area in the kernel, and this bug has been there before - just your config
> change made it appear.
>
> Rafael? Stephen? Opinions? I'd think that making APM depend on
> CONFIG_PM_LEGACY is the right thing to do these days..
Speaking as the author of
[PATCH] move pm_register/etc. to CONFIG_PM_LEGACY, pm_legacy.h
I agree. arch/i386/kernel/apm.c clearly requires
include/linux/pm_legacy.h and the legacy PM API.
I would vote for a dependency rather than select, but don't have any
strong feelings on the matter...
Jeff
On Thu, Oct 11, 2007 at 02:42:01PM -0400, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >
> > And I think I see the problem: it's a config change. You don't have
> > PM_LEGACY enabled. Your config file diff shows:
> >
> > -CONFIG_PM_LEGACY=y
> > +# CONFIG_PM_LEGACY is not set
> >
> > I suspect we should make CONFIG_APM either depend on, or select,
> > PM_LEGACY. But as far as I can see, nothing has actually changed in this
> > area in the kernel, and this bug has been there before - just your config
> > change made it appear.
> >
> > Rafael? Stephen? Opinions? I'd think that making APM depend on
> > CONFIG_PM_LEGACY is the right thing to do these days..
>
> Speaking as the author of
>
> [PATCH] move pm_register/etc. to CONFIG_PM_LEGACY, pm_legacy.h
>
> I agree. arch/i386/kernel/apm.c clearly requires
> include/linux/pm_legacy.h and the legacy PM API.
>
> I would vote for a dependency rather than select, but don't have any
> strong feelings on the matter...
gti revert 987d4613e52e4f655278265aabbcc69237018b1d
should do the trick.
Dave
--
http://www.codemonkey.org.uk
On Thursday, 11 October 2007 20:42, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >
> > On Wed, 10 Oct 2007, Kevin wrote:
> >> The last kernel I used was 6.2.22 the "dmesg" the file is attached:
> >>
> >> dmesg 2.6.22 line 158 > apm: overridden by ACPI.
> >>
> >> dmesg, APM on, has no line > apm: overridden by ACPI.
> >
> > Ok, this is the real reason.
> >
> > The APM code does:
> >
> > if (PM_IS_ACTIVE()) {
> > printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> > apm_info.disabled = 1;
> > return -ENODEV;
> > }
> >
> > and in previous kernels that would notice that you have ACPI enabled, and
> > APM gets shut out, and you never see your buggy APM BIOS.
> >
> > In 2.6.23, this apparently doesn't happen for some reason.
> >
> > And I think I see the problem: it's a config change. You don't have
> > PM_LEGACY enabled. Your config file diff shows:
> >
> > -CONFIG_PM_LEGACY=y
> > +# CONFIG_PM_LEGACY is not set
> >
> > I suspect we should make CONFIG_APM either depend on, or select,
> > PM_LEGACY. But as far as I can see, nothing has actually changed in this
> > area in the kernel, and this bug has been there before - just your config
> > change made it appear.
> >
> > Rafael? Stephen? Opinions? I'd think that making APM depend on
> > CONFIG_PM_LEGACY is the right thing to do these days..
>
> Speaking as the author of
>
> [PATCH] move pm_register/etc. to CONFIG_PM_LEGACY, pm_legacy.h
>
> I agree. arch/i386/kernel/apm.c clearly requires
> include/linux/pm_legacy.h and the legacy PM API.
>
> I would vote for a dependency rather than select, but don't have any
> strong feelings on the matter...
I agree and yes, I'd vote for a dependency too.
Greetings,
Rafael
On Thu, Oct 11, 2007 at 02:42:01PM -0400, Jeff Garzik wrote:
> Linus Torvalds wrote:
>> On Wed, 10 Oct 2007, Kevin wrote:
>>> The last kernel I used was 6.2.22 the "dmesg" the file is attached:
>>>
>>> dmesg 2.6.22 line 158 > apm: overridden by ACPI.
>>>
>>> dmesg, APM on, has no line > apm: overridden by ACPI.
>> Ok, this is the real reason. The APM code does:
>> if (PM_IS_ACTIVE()) {
>> printk(KERN_NOTICE "apm: overridden by ACPI.\n");
>> apm_info.disabled = 1;
>> return -ENODEV;
>> }
>> and in previous kernels that would notice that you have ACPI enabled, and
>> APM gets shut out, and you never see your buggy APM BIOS.
>> In 2.6.23, this apparently doesn't happen for some reason.
>> And I think I see the problem: it's a config change. You don't have
>> PM_LEGACY enabled. Your config file diff shows:
>> -CONFIG_PM_LEGACY=y
>> +# CONFIG_PM_LEGACY is not set
>> I suspect we should make CONFIG_APM either depend on, or select,
>> PM_LEGACY. But as far as I can see, nothing has actually changed in this
>> area in the kernel, and this bug has been there before - just your config
>> change made it appear. Rafael? Stephen? Opinions? I'd think that making
>> APM depend on CONFIG_PM_LEGACY is the right thing to do these days..
>
> Speaking as the author of
>
> [PATCH] move pm_register/etc. to CONFIG_PM_LEGACY, pm_legacy.h
>
> I agree. arch/i386/kernel/apm.c clearly requires include/linux/pm_legacy.h
> and the legacy PM API.
>
> I would vote for a dependency rather than select, but don't have any strong
> feelings on the matter...
It should be a select since a dependency would make it needlessly hard
for kconfig users to find the APM option.
> Jeff
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
On Friday, 12 October 2007 01:27, Adrian Bunk wrote:
> On Thu, Oct 11, 2007 at 02:42:01PM -0400, Jeff Garzik wrote:
> > Linus Torvalds wrote:
> >> On Wed, 10 Oct 2007, Kevin wrote:
> >>> The last kernel I used was 6.2.22 the "dmesg" the file is attached:
> >>>
> >>> dmesg 2.6.22 line 158 > apm: overridden by ACPI.
> >>>
> >>> dmesg, APM on, has no line > apm: overridden by ACPI.
> >> Ok, this is the real reason. The APM code does:
> >> if (PM_IS_ACTIVE()) {
> >> printk(KERN_NOTICE "apm: overridden by ACPI.\n");
> >> apm_info.disabled = 1;
> >> return -ENODEV;
> >> }
> >> and in previous kernels that would notice that you have ACPI enabled, and
> >> APM gets shut out, and you never see your buggy APM BIOS.
> >> In 2.6.23, this apparently doesn't happen for some reason.
> >> And I think I see the problem: it's a config change. You don't have
> >> PM_LEGACY enabled. Your config file diff shows:
> >> -CONFIG_PM_LEGACY=y
> >> +# CONFIG_PM_LEGACY is not set
> >> I suspect we should make CONFIG_APM either depend on, or select,
> >> PM_LEGACY. But as far as I can see, nothing has actually changed in this
> >> area in the kernel, and this bug has been there before - just your config
> >> change made it appear. Rafael? Stephen? Opinions? I'd think that making
> >> APM depend on CONFIG_PM_LEGACY is the right thing to do these days..
> >
> > Speaking as the author of
> >
> > [PATCH] move pm_register/etc. to CONFIG_PM_LEGACY, pm_legacy.h
> >
> > I agree. arch/i386/kernel/apm.c clearly requires include/linux/pm_legacy.h
> > and the legacy PM API.
> >
> > I would vote for a dependency rather than select, but don't have any strong
> > feelings on the matter...
>
> It should be a select since a dependency would make it needlessly hard
> for kconfig users to find the APM option.
Well, my experience with selects is such that I'd rather avoid them in the
future, if possible ...
Greetings,
Rafael