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
--
Ruben Puettmann
[email protected]
http://www.puettmann.net
Ruben Puettmann writes:
>
> 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
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.
On Wed, Aug 13, 2003 at 03:13:02PM +0200, Mikael Pettersson wrote:
>
> This sounds like a well-known APM/local-APIC clash.
nice to know ...
>
> Never ever use DISPLAY_BLANK if you also have SMP or UP_APIC.
not nice so ;-( how is it with acpi? Same problem?
> 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?
> 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
--
Ruben Puettmann
[email protected]
http://www.puettmann.net
On Wed, Aug 13, 2003 at 03:10:43PM +0200, Damian Ko?kowski wrote:
>
> 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
--
Ruben Puettmann
[email protected]
http://www.puettmann.net
On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> 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.
Ruben Puettmann writes:
> On Wed, Aug 13, 2003 at 03:13:02PM +0200, Mikael Pettersson wrote:
> >
> > This sounds like a well-known APM/local-APIC clash.
>
> nice to know ...
> >
> > Never ever use DISPLAY_BLANK if you also have SMP or UP_APIC.
>
> not nice so ;-( how is it with acpi? Same problem?
>
> > 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?
>
> > 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 writes:
> On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> > 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.)
On Wed, Aug 13, 2003 at 03:11:27PM +0100, Alan Cox wrote:
> On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> > 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
--
Ruben Puettmann
[email protected]
http://www.puettmann.net
Ruben Puettmann writes:
> On Wed, Aug 13, 2003 at 03:11:27PM +0100, Alan Cox wrote:
> > On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> > > 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.
Because Winblows typically won't attempt to use the local APIC
on uniprocessor machines.
> 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.
On Iau, 2003-08-14 at 13:28, Ruben Puettmann wrote:
> > 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.
Alan Cox wrote:
> On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> > 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
Jamie Lokier writes:
> Alan Cox wrote:
> > On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> > > 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,?
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.
Mikael Pettersson wrote:
> Jamie Lokier writes:
> > Alan Cox wrote:
> > > On Mer, 2003-08-13 at 14:13, Mikael Pettersson wrote:
> > > > 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,?
>
> 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 :)
> 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