2.4.22 APM problems with IBM Thinkpad's

DISCUSSION Ruben Puettmann 4 participants 13 messages Aug 13, 2003 – Aug 14, 2003 1 message not in the archive

Share & tools

Ruben Puettmann

author

2003-08-13 12:32 UTC #0 lore raw

hy,

cause many problems with acpi I try to get apm running on my ibm thinkpad R40 ( 2722). But with 2.4.22-pre10 and 2.4.22-pre10-ac1.

Problems which happend:

apm -s don't work with radeonfb usb and so on see my mails on lkm the last days

If CONFIG_APM_DISPLAY_BLANK is Y the thinkpad freezed on blanking the display

If CONFIG_APM_REAL_MODE_POWER_OFF is Y or N te thinkpad never power off

Ruben

Signature · 3 lines

Ruben Puettmann
[email protected]
http://www.puettmann.net

Mikael Pettersson

2003-08-13 13:13 UTC #1 lore raw

Quoted 6 lines · Ruben Puettmann

    hy,
cause many problems with acpi I try to get apm running on my ibm thinkpad R40 ( 2722). But with 2.4.22-pre10 and 2.4.22-pre10-ac1.

Quoted 7 lines

Problems which happend:
apm -s don't work with radeonfb usb and so on see my mails on lkm the last days
If CONFIG_APM_DISPLAY_BLANK is Y the thinkpad freezed on blanking the display

This sounds like a well-known APM/local-APIC clash.

Never ever use DISPLAY_BLANK if you also have SMP or UP_APIC.

With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module

This is because the apm driver does BIOS calls, and many BIOSen (including the code in graphics cards, e.g. all Radeons it seems) like to hang if a local APIC timer interrupt arrives.

Ruben Puettmann

author

2003-08-13 13:32 UTC #2 lore raw

Quoted 2 lines · Mikael Pettersson

This sounds like a well-known APM/local-APIC clash.

nice to know ...

Quoted 2 lines

Never ever use DISPLAY_BLANK if you also have SMP or UP_APIC.

not nice so ;-( how is it with acpi? Same problem?

Quoted 4 lines

With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module

Why will this not be disabled in make *config so that nobody will run in this problem?

Quoted 3 lines

This is because the apm driver does BIOS calls, and many BIOSen (including the code in graphics cards, e.g. all Radeons it seems) like to hang if a local APIC timer interrupt arrives.

Yes radeonfb don't like apm -s on this thinkpad. apm -s works but on resume it freezed some on

modprobe radeonfb;
sleep 10;
rmmod radeonfb;
sleep 10;
modprobe radeonfb;

and thinkpad freezed .

Ruben

Signature · 3 lines

Ruben Puettmann
[email protected]
http://www.puettmann.net

Mikael Pettersson

2003-08-13 14:24 UTC #3 lore raw

Quoted 10 lines · Ruben Puettmann

Quoted 2 lines · Mikael Pettersson
This sounds like a well-known APM/local-APIC clash.
nice to know ...
Quoted 2 lines
Never ever use DISPLAY_BLANK if you also have SMP or UP_APIC.
not nice so ;-( how is it with acpi? Same problem?

Quoted 11 lines

Quoted 4 lines
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module
Why will this not be disabled in make *config so that nobody will run in this problem?
Quoted 3 lines
This is because the apm driver does BIOS calls, and many BIOSen (including the code in graphics cards, e.g. all Radeons it seems) like to hang if a local APIC timer interrupt arrives.

Several reasons:
- The interaction wasn't understood initially, and some problems didn't start appearing until late last year. The problems are also system & configuration dependent.
Case in point #1: my P3B-F and P4T-E ASUS mainboards never had problems until they started running 2.5 kernels, where HZ==1000 greatly increased the likelihood of a local APIC timer interrupt while in BIOS screen blanking code.
Case in point #2: my TUSL2-C ASUS mobo (RIP) worked great until I switched from a Millenium to a Radeon 8500, and found that it hung because of local APIC timer interrupts while in BIOS screen blanking code, even in 2.4 kernels.
- Fixing the APM driver would require that someone who understands it modifies it to avoid BIOS calls (other than suspend/resume) when UP_APIC is active. I'm not that person.
- The problems can be worked around by avoiding misconfigurations.

Alan Cox

2003-08-13 14:11 UTC #4 lore raw

In reply to Mikael Pettersson

Quoted 4 lines · Mikael Pettersson

With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module

This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.

Mikael Pettersson

2003-08-13 14:32 UTC #5 lore raw

Quoted 9 lines · Alan Cox

Quoted 4 lines · Mikael Pettersson
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.

For those Thinkpads a DMI blacklist entry should suffice. (Just like it solved the Inspiron problems.)

2.6-mm has the "lapic" and "nolapic" options I added so that P4s no longer are autoenabled, needed for broken ACPI BIOSen. Perhaps we should require the "lapic" option also for all P6s?

(Strangely, K7 machines seem to have fewer local APIC BIOS issues than either P6 or P4 machines.)

Ruben Puettmann

author

2003-08-14 12:29 UTC #6 lore raw

In reply to Alan Cox

Quoted 9 lines · Alan Cox

Quoted 4 lines · Mikael Pettersson
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.

sorry but why breaks this all under linux? O.K im not a friend if windows but on the preinstalled windowsXP it runs all fine.

Is this a problem of manpower or missing spec's?

Ruben

Signature · 3 lines

Ruben Puettmann
[email protected]
http://www.puettmann.net

Mikael Pettersson

2003-08-14 13:21 UTC #7 lore raw

Quoted 7 lines · Ruben Puettmann

Quoted 6 lines · Alan Cox
Quoted 4 lines · Mikael Pettersson
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module

Quoted 6 lines

Quoted 3 lines
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.
sorry but why breaks this all under linux? O.K im not a friend if windows but on the preinstalled windowsXP it runs all fine.

Because Winblows typically won't attempt to use the local APIC on uniprocessor machines.

Quoted 1 line

Is this a problem of manpower or missing spec's?

BIOS limitations or bugs (depending on your POV)

It tends to work on desktop machines but break on laptops.

Alan Cox

2003-08-14 13:47 UTC #8 lore raw

In reply to Ruben Puettmann

Quoted 8 lines · Ruben Puettmann

Quoted 3 lines
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.
sorry but why breaks this all under linux? O.K im not a friend if windows but on the preinstalled windowsXP it runs all fine.
Is this a problem of manpower or missing spec's?

The system isnt designed to run with APIC enabled it seems. There is no reason for the BIOS to handle this because its not a normal setup and given the horrors of SMM BIOS code I suspect they had enough on their hands anyway.

Jamie Lokier

2003-08-14 17:34 UTC #9 lore raw

In reply to Alan Cox

Quoted 9 lines · Alan Cox

Quoted 4 lines · Mikael Pettersson
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.

Is it feasible to disable the APIC during BIOS calls,?

If that's feasible, it could fix the APM problem though not the SMM trap problem on Thinkpads.

-- Jamie

Mikael Pettersson

2003-08-14 20:03 UTC #10 lore raw

Quoted 7 lines · Jamie Lokier

Quoted 6 lines · Alan Cox
Quoted 4 lines · Mikael Pettersson
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module

Quoted 5 lines

Quoted 3 lines
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.
Is it feasible to disable the APIC during BIOS calls,?

I don't think so.
One problem is that BIOS calls can be very frequent (one every time the kernel calls pm_idle, if CPU_IDLE=y, and one each time one of those battery-monitoring applets feels like polling the battery status). Each time we'd have to go through a full lapic_suspend/lapic_resume cycle, like we do now for PM suspends, and each time the local APIC timer would lose ticks. And in an UP_IOAPIC system we'd better disable and reenable the I/O-APIC too (or reprogram it to PIC mode, but that's horrible). Not pretty.

Personally I'd prefer checks in apm.c that cause it to refuse to do any BIOS calls except at suspend or poweroff.

Jamie Lokier

2003-08-14 21:40 UTC #11 lore raw

Quoted 14 lines · Mikael Pettersson

Quoted 7 lines · Jamie Lokier
Quoted 6 lines · Alan Cox
Quoted 4 lines · Mikael Pettersson
With APIC support enabled (SMP or UP_APIC), APM must be constrained:
DISPLAY_BLANK off
CPU_IDLE off
built-in driver, not module
Quoted 5 lines
Quoted 3 lines
This isnt sufficient because some of the SMM traps off the FN-key sequences also crash thinkpads if APIC is enabled. Basically *dont use local apic* except on SMP.
Is it feasible to disable the APIC during BIOS calls,?

Quoted 8 lines

I don't think so.
One problem is that BIOS calls can be very frequent (one every time the kernel calls pm_idle, if CPU_IDLE=y, and one each time one of those battery-monitoring applets feels like polling the battery status).
Each time we'd have to go through a full lapic_suspend/lapic_resume cycle, like we do now for PM suspends, and each time the local APIC timer would lose ticks.

That'll just be another way of losing ticks, then :)

Quoted 6 lines

And in an UP_IOAPIC system we'd better disable
and reenable the I/O-APIC too (or reprogram it to PIC mode, but that's horrible). Not pretty.
Personally I'd prefer checks in apm.c that cause it to refuse to do any BIOS calls except at suspend or poweroff.

I'd prefer that if APM idle or blanking are enabled, the default interrupt mode is to not use the APIC.

Saving power is pretty desirable on a laptop.

-- Jamie

A message that is not in the archive (sent off-list or not yet received): [email protected]

Ruben Puettmann

author

2003-08-13 13:36 UTC #13 lore raw

Quoted 7 lines · Damian Ko?kowski

Please send my your confog for 2.4.22-rc2, so I can help you.
Take care.
P.S. Have you run apcid or apmd?

I have try acpid with an acpi config but acpi is broken see :

http://bugzilla.kernel.org/show_bug.cgi?id=1038

but I hope it will run in the next weeks.

With apm I have running the apmd.

apm config:

CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

ruben

Signature · 3 lines

Ruben Puettmann
[email protected]
http://www.puettmann.net