Linux 2.4.20 ACPI

Linux 2.4.20 ACPI

[Margit Schubert-While]

	Any chance to get an ACPI update into 2.4.20 ?
	It doesn't like my Intel D845PESV.

	Margit

Re: Linux 2.4.20 ACPI

[Dave Jones]

On Tue, Nov 19, 2002 at 01:53:15PM +0100, Margit Schubert-While wrote:
 > 	Any chance to get an ACPI update into 2.4.20 ?

Now that we're in 2.4.20rc stage ? No chance.

 > 	It doesn't like my Intel D845PESV.
 
The newer ACPI code also introduces problems that aren't
present with the current 2.4.20rc code.
Eg: Last snapshot I tried, My Vaio wouldn't boot if it was
running on battery (which is the time I'd need it most).

It needs a lot more testing. 

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Linux 2.4.20 ACPI

[Ducrot Bruno]

Hi Dave,

On Tue, Nov 19, 2002 at 01:07:28PM +0000, Dave Jones wrote:
> On Tue, Nov 19, 2002 at 01:53:15PM +0100, Margit Schubert-While wrote:
>  > 	Any chance to get an ACPI update into 2.4.20 ?
> 
> Now that we're in 2.4.20rc stage ? No chance.
> 
>  > 	It doesn't like my Intel D845PESV.
>  
> The newer ACPI code also introduces problems that aren't
> present with the current 2.4.20rc code.

I disagree with you.  It introduces more enhancements,
and more bugfix than the current code.  I admit that tt
could introduce some news bugs, but in the balance it
should be more stable than before.
Really, I will be happy to see new code in mainstream.

> Eg: Last snapshot I tried, My Vaio wouldn't boot if it was
> running on battery (which is the time I'd need it most).

What is actually the trouble with your Vaio (I mean dmesg when
it failed) ?  I saw some (old) Vaio where new code worked
like a charm (even speedstep worked, but it's another
story ;)

I would be happy also to take a look to the DSDT table of your model.

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: Linux 2.4.20 ACPI

[Adrian Bunk]

On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:

>...
> I disagree with you.  It introduces more enhancements,
> and more bugfix than the current code.  I admit that tt
> could introduce some news bugs, but in the balance it
> should be more stable than before.
>...

It's not "in the balance". 2.4 is a stable kernel series. The problem is
that if you switch from one stable kernel series to another
(e.g. 2.2 -> 2.4) on a production machine you know that you have to
check whether everything works as before you upgrade your production
machines. This can take quite some time. Within a stable kernel series
everything that worked in earlier kernels within this series should work
in future kernels in this kernel series. Don't forget that e.g. a
fixed security problem might force people to do a quick upgrade of
production machines to the latest kernel in this series.

There's always the possibility that you apply patches or use one of the
many two-to-four-letter patches which might contain the patch you
need.

Note: I don't know the specific situation with the new ACPI code and
      whether it might be good to include it, my arguments are an
      answer to your "in the balance" argument.

> Cheers,

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

Re: Linux 2.4.20 ACPI

[Dave Jones]

On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
 > > The newer ACPI code also introduces problems that aren't
 > > present with the current 2.4.20rc code.
 > I disagree with you.  It introduces more enhancements,
 > and more bugfix than the current code.  I admit that tt
 > could introduce some news bugs, but in the balance it
 > should be more stable than before.
 > Really, I will be happy to see new code in mainstream.

In fact, the problem with my Vaio happens due to the changes
_already_ in 2.4.20pre. I'm now backing them out to try and
isolate the exact changes that caused the problem.

This is exactly the sort of thing I meant. The ACPI stuff is
so fragile a few tiny changes makes a box unbootable.
Merging nearly 3MB of changes at this stage would be lunacy.
Save it for .20pre

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: Linux 2.4.20 ACPI

[Dave Jones]

On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
 > > The newer ACPI code also introduces problems that aren't
 > > present with the current 2.4.20rc code.

Got it. This actually isn't a problem with new ACPI code, but
the addition of the new stack overflow check. It falls flat on
its face really early if that is enabled.

The box is totally dead before console is initialised, so I
don't have backtraces, I'll give that a shot with a serial
console later. In the meantime, acpi folks should probably
try testing with CONFIG_DEBUG_STACKOVERFLOW=y to see if they
hit the same problems I'm getting.

Back later..

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: Linux 2.4.20 ACPI

[Ducrot Bruno]

On Tue, Nov 19, 2002 at 06:30:54PM +0000, Dave Jones wrote:
> On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
>  > > The newer ACPI code also introduces problems that aren't
>  > > present with the current 2.4.20rc code.
> 
> Got it. This actually isn't a problem with new ACPI code, but
> the addition of the new stack overflow check. It falls flat on
> its face really early if that is enabled.
> 
> The box is totally dead before console is initialised, so I
> don't have backtraces, I'll give that a shot with a serial
> console later. In the meantime, acpi folks should probably
> try testing with CONFIG_DEBUG_STACKOVERFLOW=y to see if they
> hit the same problems I'm getting.
> 

BTW, did you use the sonyip driver?  I am not sure at 100% but
it look like that it request the same irq line than acpi...

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: Linux 2.4.20 ACPI

[Felix Seeger]

Hi,

I have a sony vaio qr10 and I use the sonypi driver.
If I boot the screen output will stop during acpi init and the notebook boots 
(but no screen output). I can use vnc but....

I think this also happens in 2.4, 2.5 isn't better in this.
I will try to build the kernel without sonypi (never done that) maybe it 
helps.

have fun
Felix

Am Wednesday 20 November 2002 07:37 schrieb Ducrot Bruno:
> On Tue, Nov 19, 2002 at 06:30:54PM +0000, Dave Jones wrote:
> > On Tue, Nov 19, 2002 at 03:27:31PM +0100, Ducrot Bruno wrote:
> >  > > The newer ACPI code also introduces problems that aren't
> >  > > present with the current 2.4.20rc code.
> >
> > Got it. This actually isn't a problem with new ACPI code, but
> > the addition of the new stack overflow check. It falls flat on
> > its face really early if that is enabled.
> >
> > The box is totally dead before console is initialised, so I
> > don't have backtraces, I'll give that a shot with a serial
> > console later. In the meantime, acpi folks should probably
> > try testing with CONFIG_DEBUG_STACKOVERFLOW=y to see if they
> > hit the same problems I'm getting.
>
> BTW, did you use the sonyip driver?  I am not sure at 100% but
> it look like that it request the same irq line than acpi...

Linux 2.4.20 ACPI

[Margit Schubert-While]

Well, I think that I would rather see SNIP2 (from Suse 8.1 distro) than
SNIP1 from 2.4.20-rc2.
And I hear that there are MB's that won't boot without ACPI.
While I take the point that we are talking about a stable kernel
series, one shouldn't forget that ACPI is configurable :-)

--- SNIP 1 ---

<4> tbutils-0200 [03] Tb_validate_table_head: Table signature at e080f390 
[c15ffe24] has invalid characters
<4> tbutils-0202: *** Warning: Invalid table signature ASF! found
<4> tbxface-0095: *** Error: Acpi_load_tables: Error getting required 
tables (DSDT/FADT/FACS):AE_BAD_SIGNATURE
<4> tbxface-0116: *** Error: Acpi_load_tables: Could not load tables: 
AE_BAD_SIGNATURE
<3>ACPI: System description table load failed

--- END SNIP 1 ---

--- SNIP 2 ---

<7>ACPI: have wakeup address 0x40001000
<6>Advanced speculative caching feature not present
<4>On node 0 totalpages: 130880
<4>zone(0): 4096 pages.
<4>zone(1): 126784 pages.
<4>zone(2): 0 pages.
<6>ACPI: RSDP (v000 ACPIAM                     ) @ 0x000f70d0
<6>ACPI: RSDT (v001 INTEL  D845PESV 08194.04144) @ 0x1ff40000
<6>ACPI: FADT (v002 INTEL  D845PESV 08194.04144) @ 0x1ff40200
<6>ACPI: MADT (v001 INTEL  D845PESV 08194.04144) @ 0x1ff40300
<6>ACPI: ASF! (v016 AMIASF I845GASF 00000.00001) @ 0x1ff44390
<5>ACPI: BIOS passes blacklist
<4>Building zonelist for node : 0
<6>ACPI: Subsystem revision 20020829
<6>PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=2
<6>PCI: Using configuration type 1
<6>ACPI: Interpreter enabled
<6>ACPI: Using PIC for interrupt routing
<6>ACPI: System [ACPI] (supports S0 S1 S4 S5)
<6>ACPI: PCI Root Bridge [PCI0] (00:00)
<4>PCI: Probing PCI hardware (bus 00)
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
<7>ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
<6>ACPI: Power Resource [URP1] (off)
<6>ACPI: Power Resource [FDDP] (off)
<6>ACPI: Power Resource [LPTP] (off)
<4>ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKB] (IRQs *3 4 5 7 9 10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 11 12 14 *15)
<4>ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 *14 15)
<4>ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 9 10 11 12 14 15)
<4>ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
<6>PCI: Probing PCI hardware

--- END SNIP 2 ---

Re: Linux 2.4.20 ACPI

[Ducrot Bruno]

On Wed, Nov 20, 2002 at 11:29:19AM +0100, Felix Seeger wrote:
> Hi,
> 
> I have a sony vaio qr10 and I use the sonypi driver.
> If I boot the screen output will stop during acpi init and the notebook boots 
> (but no screen output). I can use vnc but....
> 
> I think this also happens in 2.4, 2.5 isn't better in this.
> I will try to build the kernel without sonypi (never done that) maybe it 
> helps.
> 

What I mean is that the two seems to conflict.
Compiling with sonypi but without acpi is OK, without sonypi but
with acpi should also be OK, but the two should be not safe because
they use the same io registers in order to ack/clean/enable the same
interrupt.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

RE: Linux 2.4.20 ACPI

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup@poupinou.org] 
> What I mean is that the two seems to conflict.
> Compiling with sonypi but without acpi is OK, without sonypi but
> with acpi should also be OK, but the two should be not safe because
> they use the same io registers in order to ack/clean/enable the same
> interrupt.

It would be great if someone could take a look at the sonypi driver and see
what can be done to integrate it better with ACPI. ACPI includes an EC
driver, so at the minimum, sonypi should use that instead of poking the EC
itself, perhaps.

Regards -- Andy

Re: Linux 2.4.20 ACPI

[Willy Tarreau]

On Wed, Nov 20, 2002 at 12:02:03PM +0100, Margit Schubert-While wrote:
> While I take the point that we are talking about a stable kernel
> series, one shouldn't forget that ACPI is configurable :-)

So you mean that anything configurable should get into a stable kernel just
because users are not forced to configure it ?
Unless you have the time to add an option "old ACPI / newer ACPI", you cannot
guarantee that there's no risk to break something. If someone has a PC which
needs ACPI to boot, and only the older one, you'll break it. One of the next
pre-releases would be far more appropriate than an -rc.

BTW, I agree that recent ACPI releases seem far more reliable than the one
in vanilla kernel, and I would also be glad to get them in a near future, but
after .20.

Cheers,
Willy

Re: Linux 2.4.20 ACPI

[David Woodhouse]

andrew.grover@intel.com said:
>  It would be great if someone could take a look at the sonypi driver
> and see what can be done to integrate it better with ACPI. ACPI
> includes an EC driver, so at the minimum, sonypi should use that
> instead of poking the EC itself, perhaps. 

Surely a proper driver should always be preferred over binary-only bytecode?

The sonypi driver looks like it properly requests the regions it uses; they
should be marked busy. Why is the ACPI code touching them?

--
dwmw2

Re: Linux 2.4.20 ACPI

[David Woodhouse]

alan@lxorguk.ukuu.org.uk said:
>  I guess sonypi could take the ACPI global lock ?

I assume that's not a serious suggestion. Perhaps it could release the 
region while it's not _actually_ using it, and the ACPI code could be fixed 
to not touch regions which it doesn't own.

Or we write proper PM code for sonypi and make it not possible to use both 
sonypi and ACPI at once.

--
dwmw2

Re: Linux 2.4.20 ACPI

[Alan Cox]

On Wed, 2002-11-20 at 21:47, David Woodhouse wrote:
> 
> andrew.grover@intel.com said:
> >  It would be great if someone could take a look at the sonypi driver
> > and see what can be done to integrate it better with ACPI. ACPI
> > includes an EC driver, so at the minimum, sonypi should use that
> > instead of poking the EC itself, perhaps. 
> 
> Surely a proper driver should always be preferred over binary-only bytecode?
> 
> The sonypi driver looks like it properly requests the regions it uses; they
> should be marked busy. Why is the ACPI code touching them?

The same microcontroller is handling both power management related
operations and also funky things like the camera. In most laptops the
microcontroller is either doing ACPI or APM so there is a convenient
split. 

I guess sonypi could take the ACPI global lock ?

Re: Linux 2.4.20 ACPI

[Alan Cox]

On Wed, 2002-11-20 at 21:59, David Woodhouse wrote:
> 
> alan@lxorguk.ukuu.org.uk said:
> >  I guess sonypi could take the ACPI global lock ?
> 
> I assume that's not a serious suggestion. Perhaps it could release the 
> region while it's not _actually_ using it, and the ACPI code could be fixed 
> to not touch regions which it doesn't own.

It isnt about regions. The microcontroller talks a message protocol,
much the same actually as most power microcontroller seem to do. Its
just Sony also added other stuff to the protocol.

Taking the acpi lock looks like its a generic way to deal with this
situation. Its made more important because a few sony laptops actually
require ACPI to do pci/irq setup

RE: Linux 2.4.20 ACPI

[Grover, Andrew]

> From: David Woodhouse [mailto:dwmw2@infradead.org] 
> alan@lxorguk.ukuu.org.uk said:
> >  I guess sonypi could take the ACPI global lock ?
> 
> I assume that's not a serious suggestion. Perhaps it could 
> release the 
> region while it's not _actually_ using it, and the ACPI code 
> could be fixed 
> to not touch regions which it doesn't own.
> 
> Or we write proper PM code for sonypi and make it not 
> possible to use both 
> sonypi and ACPI at once.

When I looked a few years ago, 0x60 through 0x6F were marked owned by the
keyboard driver (even though it only really uses 0x60 and 0x64). I don't see
either ACPI *or* sonypi currently claiming those IO ports properly. (sonypi
claims some ioports but not 0x62 and 0x66, probably for this reason.)

> Surely a proper driver should always be preferred over 
> binary-only bytecode?

The ACPI EC driver uses AML to properly configure itself (the cmd and data
ports actually can vary, and grabbing the GL is only sometimes required) but
beyond that the interpreter is not used.

However, since the only user of the EC driver until now has been ACPI, we
will need to do some work there to have nice, externally-callable
interfaces.

...and I suppose there will need to be some ifdef trickery to keep things
working when the ACPI EC driver is not there.

Stelian Pop is the current mantainer? Or davej? I should be able to do a
patch shortly to submit to whomever.

Regards -- Andy

Re: Linux 2.4.20 ACPI

[Dave Jones]

On Wed, Nov 20, 2002 at 05:24:23PM -0800, Grover, Andrew wrote:
 > 
 > Stelian Pop is the current mantainer? Or davej? I should be able to do a
 > patch shortly to submit to whomever.

Stelian owns that one.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: Linux 2.4.20 ACPI

[Ducrot Bruno]

On Wed, Nov 20, 2002 at 09:59:30PM +0000, David Woodhouse wrote:
> 
> alan@lxorguk.ukuu.org.uk said:
> >  I guess sonypi could take the ACPI global lock ?
> 
> I assume that's not a serious suggestion. Perhaps it could release the 
> region while it's not _actually_ using it, and the ACPI code could be fixed 
> to not touch regions which it doesn't own.
> 
> Or we write proper PM code for sonypi and make it not possible to use both 
> sonypi and ACPI at once.

It could be a solution, especially if you have a proper APM, but
you have also to implement in sonypi at least a replacement for the
idle loop in order to get power state saving of the processor, and
also have more battery saving.  Of course, this is the first feature
I think about the new acpi code.

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: Linux 2.4.20 ACPI

[Pavel Machek]

Hi!

> >...
> > I disagree with you.  It introduces more enhancements,
> > and more bugfix than the current code.  I admit that tt
> > could introduce some news bugs, but in the balance it
> > should be more stable than before.
> >...
> 
> It's not "in the balance". 2.4 is a stable kernel series. The problem is
> that if you switch from one stable kernel series to another
> (e.g. 2.2 -> 2.4) on a production machine you know that you have to
> check whether everything works as before you upgrade your production
> machines. This can take quite some time. Within a stable kernel series
> everything that worked in earlier kernels within this series should work
> in future kernels in this kernel series. Don't forget that e.g. a
> fixed security problem might force people to do a quick upgrade of
> production machines to the latest kernel in this series.

ACPI is marked experimental (and it *is* experimental), if you run it
on production machine you loose.

								Pavel

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: Linux 2.4.20 ACPI

[Dave Jones]

On Sat, Nov 23, 2002 at 08:57:20PM +0100, Pavel Machek wrote:
 
 > ACPI is marked experimental (and it *is* experimental), if you run it
 > on production machine you loose.

Nice. Shame about all those boxes that won't boot without ACPI.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: Linux 2.4.20 ACPI

[Arjan van de Ven]

On Mon, 2002-11-25 at 13:15, Dave Jones wrote:
> On Sat, Nov 23, 2002 at 08:57:20PM +0100, Pavel Machek wrote:
>  
>  > ACPI is marked experimental (and it *is* experimental), if you run it
>  > on production machine you loose.
> 
> Nice. Shame about all those boxes that won't boot without ACPI.

Fortunately there are very very few of those, with the exception of some
laptops with defective IRQ routing tables where the ACPI table happens
to be correct. 

Re: Linux 2.4.20 ACPI

[David Woodhouse]

davej@codemonkey.org.uk said:
>  Nice. Shame about all those boxes that won't boot without ACPI. 

I've heard a lot about such beasts but have never actually _met_ one. 

If I accidentally bought a box which wouldn't boot without ACPI, it would 
go immediately back from whence it came -- just as it would if it turned up 
with an nVidia graphics card.

--
dwmw2

Re: Linux 2.4.20 ACPI

[John Jasen]

On Mon, 25 Nov 2002, David Woodhouse wrote:

> davej@codemonkey.org.uk said:
> >  Nice. Shame about all those boxes that won't boot without ACPI. 
> 
> I've heard a lot about such beasts but have never actually _met_ one. 
> 
> If I accidentally bought a box which wouldn't boot without ACPI, it would 
> go immediately back from whence it came -- just as it would if it turned up 
> with an nVidia graphics card.

A Vaio GR390 comes very close to not booting without the patches from 
acpi.sourceforge.net.

-- 
-- John E. Jasen (jjasen@realityfailure.org)
-- User Error #2361: Please insert coffee and try again.

Re: Linux 2.4.20 ACPI

[Pavel Machek]

Hi!

> >  Nice. Shame about all those boxes that won't boot without ACPI. 
> 
> I've heard a lot about such beasts but have never actually _met_ one. 
> 
> If I accidentally bought a box which wouldn't boot without ACPI, it would 
> go immediately back from whence it came -- just as it would if it turned up 
> with an nVidia graphics card.

I have omnibook xe3, will boot without ACPI but USB will not work due
to interrupt routing problems. It has buggy PIR$ table, acpi tables
are okay. Of course it is HP bug.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.

Re: Linux 2.4.20 ACPI

[David Woodhouse]

pavel@suse.cz said:
>  I have omnibook xe3, will boot without ACPI but USB will not work due
> to interrupt routing problems. It has buggy PIR$ table, acpi tables
> are okay. Of course it is HP bug.

BIOS authors are universally shite. Film at 11. 

If it didn't have working ACPI tables either, what would we do? Probably fix
it with a DMI table entry. This box probably doesn't actually require ACPI
to boot. 

--
dwmw2

Re: Linux 2.4.20 ACPI

[Alan Cox]

On Mon, 2002-11-25 at 21:34, David Woodhouse wrote:
> 
> pavel@suse.cz said:
> >  I have omnibook xe3, will boot without ACPI but USB will not work due
> > to interrupt routing problems. It has buggy PIR$ table, acpi tables
> > are okay. Of course it is HP bug.
> 
> BIOS authors are universally shite. Film at 11. 

Not quite all of them. There are a few good ones out there, but not many

Re: Linux 2.4.20 ACPI

[Tom Diehl]

On Mon, 25 Nov 2002, David Woodhouse wrote:

> 
> pavel@suse.cz said:
> >  I have omnibook xe3, will boot without ACPI but USB will not work due
> > to interrupt routing problems. It has buggy PIR$ table, acpi tables
> > are okay. Of course it is HP bug.
> 
> BIOS authors are universally shite. Film at 11. 
> 
> If it didn't have working ACPI tables either, what would we do? Probably fix
> it with a DMI table entry. This box probably doesn't actually require ACPI
> to boot. 

Is this the same problem that Intel L440GX Motherboards have. In order to get
it to boot I need to compile a custom kernel with acpi enabled. I am told it
is some kind of irq routing problem and only Intel can fix it with a BIOS update
which they do seem interested in addressing. :-( Sure would be nice to be able
to boot stock Red Hat kernels on this machine.

-- 
.............Tom	"Nothing would please me more than being able to 
tdiehl@rogueind.com	hire ten programmers and deluge the hobby market 
			with good software." -- Bill Gates 1976

   			We are still waiting ....

Linux 2.4.20 ACPI

[Margit Schubert-While]

The latest ACPI acpi-20021118-2.4.20-rc1.diff.gz over at
http://sourceforge.net/project/showfiles.php?group_id=36832
applies cleanly to 2.4.20-rc3
Leading to :
<6>ACPI: RSDP (v000 ACPIAM                     ) @ 0x000f70d0
<6>ACPI: RSDT (v001 INTEL  D845PESV 08194.04144) @ 0x1ff40000
<6>ACPI: FADT (v002 INTEL  D845PESV 08194.04144) @ 0x1ff40200
<6>ACPI: MADT (v001 INTEL  D845PESV 08194.04144) @ 0x1ff40300
<6>ACPI: ASF! (v016 AMIASF I845GASF 00000.00001) @ 0x1ff44390
<6>ACPI: DSDT (v001 INTEL  D845PESV 00000.00266) @ 0x00000000
<5>ACPI: BIOS passes blacklist

etc. instead of :

<4> tbutils-0200 [03] Tb_validate_table_head: Table signature at e080f390 
[c15ffe24] has invalid characters
<4> tbutils-0202: *** Warning: Invalid table signature ASF! found
<4> tbxface-0095: *** Error: Acpi_load_tables: Error getting required 
tables (DSDT/FADT/FACS):AE_BAD_SIGNATURE
<4> tbxface-0116: *** Error: Acpi_load_tables: Could not load tables: 
AE_BAD_SIGNATURE
<3>ACPI: System description table load failed

- Tom Diehl - Try a Suse 8.1 distro, it has ACPI enabled by default :-)

Margit

Re: Linux 2.4.20 ACPI

[Bill Davidsen]

On Tue, 26 Nov 2002, Tom Diehl wrote:

> Is this the same problem that Intel L440GX Motherboards have. In order to get
> it to boot I need to compile a custom kernel with acpi enabled. I am told it
> is some kind of irq routing problem and only Intel can fix it with a BIOS update
> which they do seem interested in addressing. :-( Sure would be nice to be able
> to boot stock Red Hat kernels on this machine.

>From memory, if both ACPI and APM are enabled, the ACPI notices the APM
and doesn't enable (or partially disables). Have you tried booting a RH
kernel with "noapm" to see if ACPI is there and would work for you if APM
were not there?

Do note, I haven't gone back to look at the RH config, I will try it for
grins the next time I reboot.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.