Thanks for the report on the locking issue. A fix is checked in locally.
> From: Petr Vandrovec [mailto:[EMAIL PROTECTED]]
> Replying to myself, after following change in additon to acpi_ex_...
> poweroff on my machine works. It should probably map type 0
> => 0, 3 => 1
> and 7 => 2, but it is
Thanks for the report on the locking issue. A fix is checked in locally.
From: Petr Vandrovec [mailto:[EMAIL PROTECTED]]
Replying to myself, after following change in additon to acpi_ex_...
poweroff on my machine works. It should probably map type 0
= 0, 3 = 1
and 7 = 2, but it is hard to
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > BTW of course ACPI can be turned off via make menuconfig.
>
> Can you point me to the name of the option? I can't find it on my IA64
ACPI is required for IA64 to boot, so you can't disable it AFAIK. Sorry, I
should have included that
Some of this discussion's getting a little X-Files-y.
However, there are some points I'd like to touch on...
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> Well lets take a look at the asm shall we
> 1.It doesnt have a seperate loop when it fails to take the lock
> polling it (See
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> events/evxface.c:610:acpi_acquire_global_lock ->
> events/evmisc.c:337:acpi_ev_acquire_global_lock ->
> include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK
>
> My immediate objections are,
> (a) acgcc.h is re-implementing spinlocks in a
From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
events/evxface.c:610:acpi_acquire_global_lock -
events/evmisc.c:337:acpi_ev_acquire_global_lock -
include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK
My immediate objections are,
(a) acgcc.h is re-implementing spinlocks in a non-standard,
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
BTW of course ACPI can be turned off via make menuconfig.
Can you point me to the name of the option? I can't find it on my IA64
ACPI is required for IA64 to boot, so you can't disable it AFAIK. Sorry, I
should have included that caveat in
Some of this discussion's getting a little X-Files-y.
However, there are some points I'd like to touch on...
From: Alan Cox [mailto:[EMAIL PROTECTED]]
Well lets take a look at the asm shall we
1.It doesnt have a seperate loop when it fails to take the lock
polling it (See intels
Their processor power state code looks dormant at the moment, so they
haven't hit this particular issue.
They have in the past run into a number of problems, and submitted fixes.
The Linux version is getting much wider testing right now.
-- Andy
PS Just FreeBSD, no Net or OpenBSD just yet.
>
Their processor power state code looks dormant at the moment, so they
haven't hit this particular issue.
They have in the past run into a number of problems, and submitted fixes.
The Linux version is getting much wider testing right now.
-- Andy
PS Just FreeBSD, no Net or OpenBSD just yet.
> From: Alan Cox [mailto:[EMAIL PROTECTED]]
> I've seen several people report ACPI eats disks. ACPI is
> incredibly complex
> badly designed crud. My advice is never use ACPI. This
> incidentally appears
> to be the advice Microsoft give people too - they tell people
> to disable
> ACPI as one
Just a note, in 2.4.6-pre5, the acpi=no-idle option goes away, but you
should no longer experience any corruption issues, either.
Regards -- Andy
PS sorry you experienced problems - glad you could recover.
> From: Pavel Roskin [mailto:[EMAIL PROTECTED]]
> Hello!
>
> It's just a word of
Just a note, in 2.4.6-pre5, the acpi=no-idle option goes away, but you
should no longer experience any corruption issues, either.
Regards -- Andy
PS sorry you experienced problems - glad you could recover.
From: Pavel Roskin [mailto:[EMAIL PROTECTED]]
Hello!
It's just a word of warning
From: Alan Cox [mailto:[EMAIL PROTECTED]]
I've seen several people report ACPI eats disks. ACPI is
incredibly complex
badly designed crud. My advice is never use ACPI. This
incidentally appears
to be the advice Microsoft give people too - they tell people
to disable
ACPI as one of the
[trimmed CCs]
Hi Philip,
That code no longer exists in latest acpi snapshots, therefore it no longer
has the bug ;-)
I appreciate it, though.
Regards -- Andy
> -Original Message-
> From: Philip Wang [mailto:[EMAIL PROTECTED]]
> Sent: Monday, May 21, 2001 8:46 PM
> To: [EMAIL
[trimmed CCs]
Hi Philip,
That code no longer exists in latest acpi snapshots, therefore it no longer
has the bug ;-)
I appreciate it, though.
Regards -- Andy
-Original Message-
From: Philip Wang [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 21, 2001 8:46 PM
To: [EMAIL PROTECTED]
ACPI now has more config options. Make sure you enable bus manager and
system driver, at the very least.
Regards -- Andy
> From: Mike Panetta [mailto:[EMAIL PROTECTED]]
> ACPI seems to be broken on 2.4.4-ac6 or atleast
> poweroff is broken. During bootup all ACPI
> prints is that it was
ACPI now has more config options. Make sure you enable bus manager and
system driver, at the very least.
Regards -- Andy
From: Mike Panetta [mailto:[EMAIL PROTECTED]]
ACPI seems to be broken on 2.4.4-ac6 or atleast
poweroff is broken. During bootup all ACPI
prints is that it was enabled,
[trimming CC's. Recommend [EMAIL PROTECTED] for followups]
As you mentioned, the ACPI driver does something similar, and I think the
approach is generally sound (or at least we haven't been able to come up
with anything better ;-) I do have the following comments:
- It's probably easier to put
[trimming CC's. Recommend [EMAIL PROTECTED] for followups]
As you mentioned, the ACPI driver does something similar, and I think the
approach is generally sound (or at least we haven't been able to come up
with anything better ;-) I do have the following comments:
- It's probably easier to put
(btw ACPI 2.0 spec section 12.1.1 discusses this)
> From: Pavel Machek [mailto:[EMAIL PROTECTED]]
> > No, the ACPI standard requires CPUs to shut themselves down before
> > any damage would occur from overheading. Well, at least the 1.0b
> > version of the standard did; I haven't read 2.0 yet.
(btw ACPI 2.0 spec section 12.1.1 discusses this)
From: Pavel Machek [mailto:[EMAIL PROTECTED]]
No, the ACPI standard requires CPUs to shut themselves down before
any damage would occur from overheading. Well, at least the 1.0b
version of the standard did; I haven't read 2.0 yet.
BTW
> From: David S. Miller [mailto:[EMAIL PROTECTED]]
> > IMHO an abstracted interface at this point is overengineering.
>
> ACPI is the epitome of overengineering.
Hi David,
I definitely set myself up for that one. ;-) And, you're not wrong. But,
let's be clear on one thing, there are two
From: David S. Miller [mailto:[EMAIL PROTECTED]]
IMHO an abstracted interface at this point is overengineering.
ACPI is the epitome of overengineering.
Hi David,
I definitely set myself up for that one. ;-) And, you're not wrong. But,
let's be clear on one thing, there are two interfaces
It seems like we need to implement down_timeout (and
down_timeout_interruptible) to fully flesh out the semaphore implementation.
It is difficult and inefficient to emulate this using wrapper functions, as
far as I can see.
Seems like this is a fairly standard interface to have for OS
> > It'd be great if you could focus your testing and patches
> on this code base
> > -- I think it's a lot better but it's still a work in progress.
>
> Are you planning to merge to 2.4.4?
Planning on merging ASAP. That may be 2.4.4, we'll see.
> > PS I'm not quite sure why you copied the
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> Stephen Torri wrote:
> >
> > I noticed that the big update patch for ACPI was a part of
> 2.4.3-ac11 (Can
> > remember). Now its not a part of 2.4.3-ac12. Has it been
> removed? I have
> > turned on experimental settings when running make
Pavel,
We already have lid support in the latest ACPI versions (not in the official
kernel yet.) You can download this code from
http://developer.intel.com/technology/iapc/acpi/downloads.htm .
It'd be great if you could focus your testing and patches on this code base
-- I think it's a lot
Pavel,
We already have lid support in the latest ACPI versions (not in the official
kernel yet.) You can download this code from
http://developer.intel.com/technology/iapc/acpi/downloads.htm .
It'd be great if you could focus your testing and patches on this code base
-- I think it's a lot
From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
Stephen Torri wrote:
I noticed that the big update patch for ACPI was a part of
2.4.3-ac11 (Can
remember). Now its not a part of 2.4.3-ac12. Has it been
removed? I have
turned on experimental settings when running make xconfig.
Alan
It'd be great if you could focus your testing and patches
on this code base
-- I think it's a lot better but it's still a work in progress.
Are you planning to merge to 2.4.4?
Planning on merging ASAP. That may be 2.4.4, we'll see.
PS I'm not quite sure why you copied the acpi list
It seems like we need to implement down_timeout (and
down_timeout_interruptible) to fully flesh out the semaphore implementation.
It is difficult and inefficient to emulate this using wrapper functions, as
far as I can see.
Seems like this is a fairly standard interface to have for OS
> From: John Fremlin [mailto:[EMAIL PROTECTED]]
> [...]
>
> > Fair enough. I don't think I would be out of line to say that our
> > resources are focused on enabling full ACPI functionality for Linux,
> > including a full-featured PM policy daemon. That said, I don't think
> > there's anything
> From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
> | ACPI is meant to abstract the OS from all the "magic
> numbers". It's very
> | possible to do things in a platform-specific way, but if
> you want to handle
> | all platforms, you'd end up with something ACPI-like.
>
> This isn't me
> From: Simon Richter
> > We are going to need some software that handles button
> events, as well as
> > thermal events, battery events, polling the battery, AC
> adapter status
> > changes, sleeping the system, and more.
>
> Yes, that will be a separate daemon that will also get the
>
From: Simon Richter
We are going to need some software that handles button
events, as well as
thermal events, battery events, polling the battery, AC
adapter status
changes, sleeping the system, and more.
Yes, that will be a separate daemon that will also get the
events. But I
From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
| ACPI is meant to abstract the OS from all the "magic
numbers". It's very
| possible to do things in a platform-specific way, but if
you want to handle
| all platforms, you'd end up with something ACPI-like.
This isn't me talking, but I
From: John Fremlin [mailto:[EMAIL PROTECTED]]
[...]
Fair enough. I don't think I would be out of line to say that our
resources are focused on enabling full ACPI functionality for Linux,
including a full-featured PM policy daemon. That said, I don't think
there's anything precluding
[do we want to move this to linux-power?]
> From: John Fremlin [mailto:[EMAIL PROTECTED]]
> > We are going to need some software that handles button events, as
> > well as thermal events, battery events, polling the battery, AC
> > adapter status changes, sleeping the system, and more.
>
>
> From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
> Pardon me for butting in, but perhaps this is relevant...
>
> I've seen the odd program which manipulates the ACPI tables/registers
> directly rather than through an ASL compiler then an AML interpreter.
> These appear to use the "magic
> From: Pavel Machek [mailto:[EMAIL PROTECTED]]
> > I would think that it would make sense to keep shutdown
> with all the other
> > power management events. Perhaps it will makes more sense
> to handle UPS's
> > through the power management code.
>
> Yes, that would be another acceptable
From: Pavel Machek [mailto:[EMAIL PROTECTED]]
I would think that it would make sense to keep shutdown
with all the other
power management events. Perhaps it will makes more sense
to handle UPS's
through the power management code.
Yes, that would be another acceptable solution.
From: Martin Hamilton [mailto:[EMAIL PROTECTED]]
Pardon me for butting in, but perhaps this is relevant...
I've seen the odd program which manipulates the ACPI tables/registers
directly rather than through an ASL compiler then an AML interpreter.
These appear to use the "magic numbers"
[do we want to move this to linux-power?]
From: John Fremlin [mailto:[EMAIL PROTECTED]]
We are going to need some software that handles button events, as
well as thermal events, battery events, polling the battery, AC
adapter status changes, sleeping the system, and more.
Dealing with
> From: Pavel Machek [mailto:[EMAIL PROTECTED]]
> There are 32 signals, and signals can carry more information, if
> required. I really think doing it way UPS-es are done is right
> approach.
I would think that it would make sense to keep shutdown with all the other
power management events.
> From: Chris Meadors [mailto:[EMAIL PROTECTED]]
> I saw no mention of the ACPI idle problem I see on my Athlons. Is the
> acpi=no-idle work around the perminate fix?
Fixed. I will be submitting a big ACPI patch to Linus & Alan very soon.
Regards -- Andy
-
To unsubscribe from this list: send
From: Chris Meadors [mailto:[EMAIL PROTECTED]]
I saw no mention of the ACPI idle problem I see on my Athlons. Is the
acpi=no-idle work around the perminate fix?
Fixed. I will be submitting a big ACPI patch to Linus Alan very soon.
Regards -- Andy
-
To unsubscribe from this list: send the
From: Pavel Machek [mailto:[EMAIL PROTECTED]]
There are 32 signals, and signals can carry more information, if
required. I really think doing it way UPS-es are done is right
approach.
I would think that it would make sense to keep shutdown with all the other
power management events. Perhaps
> > Proper place to do this discussion is
> [EMAIL PROTECTED]
>
> It sounds good in theory. In practice, though, almost all of the
> design discussions have been occuring in private e-mail.
> For example, I have seen none of the messages discussing
> the changes planned for the power
I'm hesitant to do this, since 1) You can put those printk's in yourself to
find out if your particular system is working and 2) You can just cat
/proc/sys/event, hit a button, and you should see output if it works.
Regards -- Andy
> From: John Fremlin [mailto:[EMAIL PROTECTED]]
> &
I'm hesitant to do this, since 1) You can put those printk's in yourself to
find out if your particular system is working and 2) You can just cat
/proc/sys/event, hit a button, and you should see output if it works.
Regards -- Andy
From: John Fremlin [mailto:[EMAIL PROTECTED]]
"G
Proper place to do this discussion is
[EMAIL PROTECTED]
It sounds good in theory. In practice, though, almost all of the
design discussions have been occuring in private e-mail.
For example, I have seen none of the messages discussing
the changes planned for the power management
This is because at this stage of ACPI development, we want to be as strict
as possible w.r.t. AML, to expose bugs in the software.
That said, maybe it's better to just emit a warning here, instead of
failing. I'll bring it up with the team.
Regards -- Andy
> From: Pavel Machek [mailto:[EMAIL
This is not correct, because we want the power button to be configurable.
The user should be able to redefine the power button's action, perhaps to
only sleep the system. We currently surface button events to acpid, which
then can do the right thing, including a shutdown -h now (which I assume
This is not correct, because we want the power button to be configurable.
The user should be able to redefine the power button's action, perhaps to
only sleep the system. We currently surface button events to acpid, which
then can do the right thing, including a shutdown -h now (which I assume
This is because at this stage of ACPI development, we want to be as strict
as possible w.r.t. AML, to expose bugs in the software.
That said, maybe it's better to just emit a warning here, instead of
failing. I'll bring it up with the team.
Regards -- Andy
From: Pavel Machek [mailto:[EMAIL
> From: Trever L. Adams [mailto:[EMAIL PROTECTED]]
> I do have a question that you might be able to answer.
>
> Since I left the 2.2.x series of kernels, my harddrives never
> spin down
> now. I do not know what else doesn't sleep. This is the
> case with APM
> (on a box that doesn't crash
> From: Trever L. Adams [mailto:[EMAIL PROTECTED]]
> 2.4.3 no longer shuts down automatically with S5.
>
> [2.] Full description of the problem/report:
>
> 2.4.3 no longer shuts down automatically with S5. I have an Athlon
> based system using the FIC-SD11 motherboard. In 2.4.1 and possibly
I'm confused. 3c59x.c has a little acpi WOL stuff, but that's it.
What specifically is ACPI doing to break things? Are ACPI and the NIC
sharing any resources?
Regards -- Andy
> -Original Message-
> From: Prasanna P Subash [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2001
I'm confused. 3c59x.c has a little acpi WOL stuff, but that's it.
What specifically is ACPI doing to break things? Are ACPI and the NIC
sharing any resources?
Regards -- Andy
-Original Message-
From: Prasanna P Subash [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 05, 2001 11:12
From: Trever L. Adams [mailto:[EMAIL PROTECTED]]
2.4.3 no longer shuts down automatically with S5.
[2.] Full description of the problem/report:
2.4.3 no longer shuts down automatically with S5. I have an Athlon
based system using the FIC-SD11 motherboard. In 2.4.1 and possibly
2.4.2
No there isn't a chipset patch for ACPI, because IMHO vendor-specific code
is the wrong way to go regarding this. ACPI defines how shutdown should
happen, and if it doesn't work on a given system, then either the code has
a bug or the hardware is not ACPI compliant.
(I think the ACPI code has a
I'm not sure what you mean by well-defined. Do you mean, does it have a
fixed address? No, it is relocatable. The ACPI driver can find it because
the base address is specified in the ACPI tables. After the ACPI driver is
loaded the driver could export a pmtimer read function. This is great except
I'm not sure what you mean by well-defined. Do you mean, does it have a
fixed address? No, it is relocatable. The ACPI driver can find it because
the base address is specified in the ACPI tables. After the ACPI driver is
loaded the driver could export a pmtimer read function. This is great except
Sounds like the TSC makes a lousy calibration method ;-)
I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz.
Could udelay use that, or are there other timers that are better (maybe
without the ACPI dependency)?
Regards -- Andy
> -Original Message-
> From: Pavel
Sounds like the TSC makes a lousy calibration method ;-)
I know on ACPI systems you are guaranteed a PM timer running at ~3.57 Mhz.
Could udelay use that, or are there other timers that are better (maybe
without the ACPI dependency)?
Regards -- Andy
-Original Message-
From: Pavel
> From: Ingo Oeser [mailto:[EMAIL PROTECTED]]
> > > As i recompiled 2.4.2-ac20 with ACPI support
> > > the system cannot switch itself off.
> > > I get a message "Couldn't switch to S5" if
> > > try to call reboot(2).
> > > At load it shows that the mode is supported.
> >
> > Same with AMR
From: Ingo Oeser [mailto:[EMAIL PROTECTED]]
As i recompiled 2.4.2-ac20 with ACPI support
the system cannot switch itself off.
I get a message "Couldn't switch to S5" if
try to call reboot(2).
At load it shows that the mode is supported.
Same with AMR P6BAP-AP and P6VAP-AP ()
> During resume the IBM thinkpad with the cs46xx driver needs
> to delay 700
> milleseconds, so if the machine is booted up on battery power, then to
> ensure that the delay is long enough, then a value of 3000
> milleseconds is
> must be programmed into the driver (3 seconds!). all the
>
During resume the IBM thinkpad with the cs46xx driver needs
to delay 700
milleseconds, so if the machine is booted up on battery power, then to
ensure that the delay is long enough, then a value of 3000
milleseconds is
must be programmed into the driver (3 seconds!). all the
mdelay and
Well the ACPI bugs look legitimate. We'll work on getting those fixed.
Thanks for your efforts!
Regards -- Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Well the ACPI bugs look legitimate. We'll work on getting those fixed.
Thanks for your efforts!
Regards -- Andy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi all.
This is a preliminary patch against 2.4.2 to uhci.c that puts the host
controller into global suspend when there are no devices attached. This
conserves power on mobile systems, and because suspending the host
controller ceases UHCI's incessant busmastering activity, it allows the CPU
to
Hi all.
This is a preliminary patch against 2.4.2 to uhci.c that puts the host
controller into global suspend when there are no devices attached. This
conserves power on mobile systems, and because suspending the host
controller ceases UHCI's incessant busmastering activity, it allows the CPU
to
> From: Stephen Torri [mailto:[EMAIL PROTECTED]]
> I am using kernel-2.4.2-ac12 (will try ac14). The motherboard is a
> Supermicro P6DBU. (I will need to check the board when I get home to
> confirm). I get the messages below when the system starts:
>
> acpi: system description tables not found
From: Stephen Torri [mailto:[EMAIL PROTECTED]]
I am using kernel-2.4.2-ac12 (will try ac14). The motherboard is a
Supermicro P6DBU. (I will need to check the board when I get home to
confirm). I get the messages below when the system starts:
acpi: system description tables not found
There are definitely plans to do this, and in fact on IA64 ACPI is already
used to obtain PCI routing. However, IA32 ACPI efforts have been focused on
other things, since we assumed MPS tables would be around for a while
longer. I guess that is no longer a correct assumption.
So yes, there are
There are definitely plans to do this, and in fact on IA64 ACPI is already
used to obtain PCI routing. However, IA32 ACPI efforts have been focused on
other things, since we assumed MPS tables would be around for a while
longer. I guess that is no longer a correct assumption.
So yes, there are
Hi Dale,
Thanks! Applied.
I feel I must mention that while I (and you, and others) have been working
on improving the current codebase, other people here have been working on a
totally different design. In general, the new codebase has better ACPI
functionality, is more modular, etc. My hope is
Hi Dale,
Thanks! Applied.
I feel I must mention that while I (and you, and others) have been working
on improving the current codebase, other people here have been working on a
totally different design. In general, the new codebase has better ACPI
functionality, is more modular, etc. My hope is
> From: Tony Hoyle [mailto:[EMAIL PROTECTED]]
> OK I see that safe_halt() will re-enable interrupts. However
> this is only
> called in S1. If your machine gets as far as S3 you have...
I think you mean C1 and C3, but I know what you mean.. :)
[C3 code snipped]
> There is no halt here...
From: Tony Hoyle [mailto:[EMAIL PROTECTED]]
OK I see that safe_halt() will re-enable interrupts. However
this is only
called in S1. If your machine gets as far as S3 you have...
I think you mean C1 and C3, but I know what you mean.. :)
[C3 code snipped]
There is no halt here... the
Well, someone else had PPP slowness due to ACPI idle, so I'd guess that's
the problem here too.
Workin' on it -- Andy
> From: Juraj Bednar [mailto:[EMAIL PROTECTED]]
> I just found a strange thing in 2.4.1 (don't know, if the same
> occured in 2.4.0) and 2.4.1-ac3. When I enable ACPI, my
Hi Benson,
ACPI idle is pretty broken at the moment, as you've seen.
The next ACPI patch (early next week maybe?) will have some more messages to
help me fix this, as well as a cmdline option to not use ACPI for idle.
> From: Benson Chow [mailto:[EMAIL PROTECTED]]
> ACPI: System firmware
Well, someone else had PPP slowness due to ACPI idle, so I'd guess that's
the problem here too.
Workin' on it -- Andy
From: Juraj Bednar [mailto:[EMAIL PROTECTED]]
I just found a strange thing in 2.4.1 (don't know, if the same
occured in 2.4.0) and 2.4.1-ac3. When I enable ACPI, my serial
> > The problem the diff below fixes is a BIOS issue - the _STA
> control method
> > should always be returning a value, but in this case it doesn't. The
> > approach we're taking is "get everything working and THEN
> worry about broken
> > ACPI implementations" and hopefully in the meantime,
The problem the diff below fixes is a BIOS issue - the _STA control method
should always be returning a value, but in this case it doesn't. The
approach we're taking is "get everything working and THEN worry about broken
ACPI implementations" and hopefully in the meantime, people will release
> From: Drew Bertola [mailto:[EMAIL PROTECTED]]
> > This is a temporary interface, just to see if we're returning values
> > properly. Your points below are well taken. People really care about
> > minutes/percentage remaining. In your opinion should we
> just report that
> > through /proc or
Do maestro and acpi share an interrupt on your machine?
If so, is maestro's ISR ever getting called? Is ACPI's ISR
(drivers/acpi/events/evsci.c acpi_ev_sci_handler()) getting called and
reporting them handled when it shouldn't?
Thanks -- Regards -- Andy
> From: Pavel Machek [mailto:[EMAIL
Do maestro and acpi share an interrupt on your machine?
If so, is maestro's ISR ever getting called? Is ACPI's ISR
(drivers/acpi/events/evsci.c acpi_ev_sci_handler()) getting called and
reporting them handled when it shouldn't?
Thanks -- Regards -- Andy
From: Pavel Machek [mailto:[EMAIL
From: Drew Bertola [mailto:[EMAIL PROTECTED]]
This is a temporary interface, just to see if we're returning values
properly. Your points below are well taken. People really care about
minutes/percentage remaining. In your opinion should we
just report that
through /proc or should we
The problem the diff below fixes is a BIOS issue - the _STA control method
should always be returning a value, but in this case it doesn't. The
approach we're taking is "get everything working and THEN worry about broken
ACPI implementations" and hopefully in the meantime, people will release
The problem the diff below fixes is a BIOS issue - the _STA
control method
should always be returning a value, but in this case it doesn't. The
approach we're taking is "get everything working and THEN
worry about broken
ACPI implementations" and hopefully in the meantime, people
If you have ACPI enabled, it is the culprit.
(I'm workin' on it! ;-)
Anyway, ACPI driver is marked "developmental and/or incomplete" and will not
be otherwise any time soon so it's broken-ness should IMO not hold up kernel
releases.
Regards -- Andy
(ACPI maintainer)
> -Original
> Despite the latest ACPI update, I still get the ACPI slowdown on
> initialisation which started with the -pre10 changes. Also, the uhci
> module doesn't work for me (the latest patch from Johannes
> Erdfelt does
> work). This is an Abit KA7-100, which has the KX133 chipset. Here is
> the
> On Sun, 28 Jan 2001, Dieter Nützel wrote:
>
> > > I just uploaded it to kernel.org, and I expect that I'll
> do the final
> > > 2.4.1 tomorrow, before leaving for NY and LinuxWorld.
> Please test that the
> > > pre-kernel works for you..
> >
> > Hello Linus,
> >
> > can we please see
On Sun, 28 Jan 2001, Dieter Ntzel wrote:
I just uploaded it to kernel.org, and I expect that I'll
do the final
2.4.1 tomorrow, before leaving for NY and LinuxWorld.
Please test that the
pre-kernel works for you..
Hello Linus,
can we please see Andrew's latest ACPI fixes
Despite the latest ACPI update, I still get the ACPI slowdown on
initialisation which started with the -pre10 changes. Also, the uhci
module doesn't work for me (the latest patch from Johannes
Erdfelt does
work). This is an Abit KA7-100, which has the KX133 chipset. Here is
the dmesg
I think it is too. For now, remove ACPI support.
-- Andy
(ACPI maintainer)
> -Original Message-
> From: Terje Rosten [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 25, 2001 12:23 PM
> To: Ondrej Sury
> Cc: [EMAIL PROTECTED]
> Subject: Re: 2.4.1-pre10 slowdown at boot.
>
I think it is too. For now, remove ACPI support.
-- Andy
(ACPI maintainer)
-Original Message-
From: Terje Rosten [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 25, 2001 12:23 PM
To: Ondrej Sury
Cc: [EMAIL PROTECTED]
Subject: Re: 2.4.1-pre10 slowdown at boot.
Importance: High
1 - 100 of 117 matches
Mail list logo
