Hi,
I am using ACPI for few years now. As far as I can see, on my
machine it is only usfeul for binding events to Power button (like
running fbdump) and for powering off. I'm also experimenting
with swsusp, which I run by /proc/acpi/sleep.
2.6.0-test4 has a surprise for me:
Linux version 2.6.0-test4 (zdzichu@mother) (gcc version 3.3.1) #15 Sat Aug 23 12:03:
02 CEST 2003
Video mode to be used for restore is ffff
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000013ff0000 (usable)
BIOS-e820: 0000000013ff0000 - 0000000013ff3000 (ACPI NVS)
BIOS-e820: 0000000013ff3000 - 0000000014000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
319MB LOWMEM available.
On node 0 totalpages: 81904
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 77808 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
DMI 2.1 present.
ACPI disabled because your bios is from 00 and too old
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You can enable it with acpi=force
ACPI: RSDP (v000 VIA693 ) @ 0x000f70c0
ACPI: RSDT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x13ff3000
ACPI: FADT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x13ff3040
ACPI: DSDT (v001 VIA693 AWRDACPI 0x00001000 MSFT 0x0100000a) @ 0x00000000
WTF? My BIOS was perfectly good all those years! And no, there is
no upgrade for my motherboard available. Using acpi=force is ugly
and un-understandable.
There are also some strange directories in /proc :
dr-xr-xr-x 2 root root 0 Aug 23 12:50 /proc/ac_adapter/
dr-xr-xr-x 2 root root 0 Aug 23 12:50 /proc/fan
they are empty, but they should be in /proc/acpi/
Attached files:
Output from dmidecode, lspci -v, my dmesg and /proc/cpuinfo
[Please CC me on replies. Thank you].
--
Tomasz Torcz "God, root, what's the difference?"
[email protected] "God is more forgiving."
If you're using run-time ACPI features, you'll probably want to
make sure that your MB BIOS is the latest available.
I didn't see which VIA 693 MB you've got, but it could be that a
BIOS upgrade would move it from 09/13/00 to something past 1/1/2001 --
the (yes, arbitrary) cutoff for enabling ACPI by default.
Or you could add "acpi=force" to your command line, as suggested in the
dmesg output.
Or you could change the source to alter or disable #define
ACPI_BLACKLIST_CUTOFF_YEAR 2001
If your system misbehaves when ACPI is enabled by one of these methods,
please let me know.
Thanks,
-Len
> -----Original Message-----
> From: Tomasz Torcz [mailto:[email protected]]
> Sent: Saturday, August 23, 2003 6:53 AM
> To: LKML
> Subject: 2.6.0-test4 - lost ACPI
>
>
>
> Hi,
>
> I am using ACPI for few years now. As far as I can see, on my
> machine it is only usfeul for binding events to Power button (like
> running fbdump) and for powering off. I'm also experimenting
> with swsusp, which I run by /proc/acpi/sleep.
>
> 2.6.0-test4 has a surprise for me:
>
> Linux version 2.6.0-test4 (zdzichu@mother) (gcc version
> 3.3.1) #15 Sat Aug 23 12:03:
> 02 CEST 2003
> Video mode to be used for restore is ffff
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 0000000013ff0000 (usable)
> BIOS-e820: 0000000013ff0000 - 0000000013ff3000 (ACPI NVS)
> BIOS-e820: 0000000013ff3000 - 0000000014000000 (ACPI data)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> 319MB LOWMEM available.
> On node 0 totalpages: 81904
> DMA zone: 4096 pages, LIFO batch:1
> Normal zone: 77808 pages, LIFO batch:16
> HighMem zone: 0 pages, LIFO batch:1
> DMI 2.1 present.
> ACPI disabled because your bios is from 00 and too old
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> You can enable it with acpi=force
> ACPI: RSDP (v000 VIA693 )
> @ 0x000f70c0
> ACPI: RSDT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000)
> @ 0x13ff3000
> ACPI: FADT (v001 AWARD AWRDACPI 0x42302e31 AWRD 0x00000000)
> @ 0x13ff3040
> ACPI: DSDT (v001 VIA693 AWRDACPI 0x00001000 MSFT 0x0100000a)
> @ 0x00000000
>
> WTF? My BIOS was perfectly good all those years! And no, there is
> no upgrade for my motherboard available. Using acpi=force is ugly
> and un-understandable.
>
> There are also some strange directories in /proc :
> dr-xr-xr-x 2 root root 0 Aug 23 12:50
> /proc/ac_adapter/
> dr-xr-xr-x 2 root root 0 Aug 23 12:50 /proc/fan
>
> they are empty, but they should be in /proc/acpi/
>
> Attached files:
> Output from dmidecode, lspci -v, my dmesg and /proc/cpuinfo
>
> [Please CC me on replies. Thank you].
>
> --
> Tomasz Torcz "God, root, what's the difference?"
> [email protected] "God is more forgiving."
>
On Sat, Aug 23, 2003 at 12:47:04PM -0400, Brown, Len wrote:
> I didn't see which VIA 693 MB you've got, but it could be that a
> BIOS upgrade would move it from 09/13/00 to something past 1/1/2001 --
> the (yes, arbitrary) cutoff for enabling ACPI by default.
It's Matsonic 7132A (http://www.matsonic.com/ms7132a.htm ;
http://206.135.80.155/manual/ms7132a.pdf).
Pretty nice board. Latest bios for it is dated 09/13/00 and
there is no upgrade.
> Or you could add "acpi=force" to your command line, as suggested in the
> dmesg output.
Tried this with strange results - kernel halted during boot,
after displaying:
[... dmesg ...]
PM: Adding info for ide:1.0
hda: max request size: 1024KiB
hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(66)
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
mice: PS/2 mouse device common for all mice
HALT. No sysrq, no shift+pgup, no response for power button.
Dmesg _without_ acpi=force:
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
Advanced Linux Sound Architecture Driver Version 0.9.6 (Wed Aug 20 20:27:13 2003 UTC).
PCI: Found IRQ 10 for device 0000:00:0b.0
And so on.
> Or you could change the source to alter or disable #define
> ACPI_BLACKLIST_CUTOFF_YEAR 2001
I will try this next. ACPI was working flawlessly for me almost from
the beginning.
--
Tomasz Torcz 72->| 80->|
[email protected] 72->| 80->|
manually modifying ACPI_BLACKLIST_CUTOFF_YEAR and using acpi=force on
the cmdline should have the same effect.
pci=noacpi is also an option. If it works, then it means you got burnt
by ACPI's PCI interrupt code. We've had trouble with Award/VIA in this
area recently, so it wouldn't be surprising to have trouble with a
3-year old Award/VIA BIOS. The puzzling thing is why ACPI enabled
worked for you before and doesn't work now.
I'd be interested in looking over a copy of your /proc/acpi/dsdt, or
even better, the output from acpidmp, which you can get from the pmtools
package here:
http://developer.intel.com/technology/iapc/acpi/downloads/pmtools-200107
30.tar.gz
Thanks,
-Len
> -----Original Message-----
> From: Tomasz Torcz [mailto:[email protected]]
> Sent: Saturday, August 23, 2003 12:59 PM
> To: Brown, Len
> Cc: LKML
> Subject: Re: 2.6.0-test4 - lost ACPI
>
>
> On Sat, Aug 23, 2003 at 12:47:04PM -0400, Brown, Len wrote:
>
> > I didn't see which VIA 693 MB you've got, but it could be that a
> > BIOS upgrade would move it from 09/13/00 to something past
> 1/1/2001 --
> > the (yes, arbitrary) cutoff for enabling ACPI by default.
>
> It's Matsonic 7132A (http://www.matsonic.com/ms7132a.htm ;
> http://206.135.80.155/manual/ms7132a.pdf).
> Pretty nice board. Latest bios for it is dated 09/13/00 and
> there is no upgrade.
>
> > Or you could add "acpi=force" to your command line, as
> suggested in the
> > dmesg output.
>
> Tried this with strange results - kernel halted during boot,
> after displaying:
>
> [... dmesg ...]
> PM: Adding info for ide:1.0
> hda: max request size: 1024KiB
> hda: 156301488 sectors (80026 MB) w/2048KiB Cache,
> CHS=16383/255/63, UDMA(66)
> /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
> hdc: ATAPI 32X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
> Uniform CD-ROM driver Revision: 3.12
> mice: PS/2 mouse device common for all mice
>
> HALT. No sysrq, no shift+pgup, no response for power button.
>
> Dmesg _without_ acpi=force:
>
> hdc: ATAPI 32X CD-ROM CD-R/RW drive, 8192kB Cache, DMA
> Uniform CD-ROM driver Revision: 3.12
> mice: PS/2 mouse device common for all mice
> serio: i8042 AUX port at 0x60,0x64 irq 12
> input: AT Set 2 keyboard on isa0060/serio0
> serio: i8042 KBD port at 0x60,0x64 irq 1
> Advanced Linux Sound Architecture Driver Version 0.9.6 (Wed
> Aug 20 20:27:13 2003 UTC).
> PCI: Found IRQ 10 for device 0000:00:0b.0
>
> And so on.
>
> > Or you could change the source to alter or disable #define
> > ACPI_BLACKLIST_CUTOFF_YEAR 2001
>
> I will try this next. ACPI was working flawlessly for me almost from
> the beginning.
>
> --
> Tomasz Torcz
> 72->| 80->|
> [email protected]
> 72->| 80->|
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Tomasz Torcz <[email protected]> wrote:
>
> I am using ACPI for few years now. As far as I can see, on my
> machine it is only usfeul for binding events to Power button (like
> running fbdump) and for powering off. I'm also experimenting
> with swsusp, which I run by /proc/acpi/sleep.
>
> 2.6.0-test4 has a surprise for me:
me too.
> ACPI disabled because your bios is from 00 and too old
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
One of my trusty-but-old testboxes does exactly the same thing. It's just
the ACPI guys running away from broken BIOSes I think ;)
Add "acpi=force" to your kernel boot command line and everything should work
as before.
On Sat, Aug 23, 2003 at 02:55:45PM -0700, Andrew Morton wrote:
> Tomasz Torcz <[email protected]> wrote:
>
> > ACPI disabled because your bios is from 00 and too old
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Add "acpi=force" to your kernel boot command line and everything should work
> as before.
It does not work. It halts in beetween ps/2 mouse init and serio init.
Adding "acpi=force pci=noacpi" solves that.
--
Tomasz Torcz RIP is irrevelant. Spoofing is futile.
[email protected] Your routes will be aggreggated. -- Alex Yuriev
Tomasz Torcz <[email protected]> wrote:
>
> On Sat, Aug 23, 2003 at 02:55:45PM -0700, Andrew Morton wrote:
> > Tomasz Torcz <[email protected]> wrote:
> >
> > > ACPI disabled because your bios is from 00 and too old
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Add "acpi=force" to your kernel boot command line and everything should work
> > as before.
>
> It does not work. It halts in beetween ps/2 mouse init and serio init.
> Adding "acpi=force pci=noacpi" solves that.
>
OK. Please send a full report to [email protected]. Here is Len's
how-to-report-ACPI problems recipe:
Regarding how to field these in general...
Bugzilla would be really helpful, because we've got multiple bugs and
multiple people working on them and bugzilla is better than e-mail at
keeping the relevant bits together. bugzilla with component=ACPI and
owner [email protected] or [email protected] should do the
trick.
The dmesg output of the failing case is really helpful,
As is the output of acpidmp to examine the ACPI tables on the system.
(Red Hat includes both of these in their severn beta1, acpidmp is also
in pmtools on intel's ACPI web page)
dmidecode output is useful to identify the BIOS version.
Of course the 1st thing to check with ACPI failures is that the BIOS
version shown by dmidmp is the latest provided by the vendor... Plus,
if we determine the BIOS is toast, DMI provides what we need to add the
system to the DMI or acpi blacklists.
We're seeting the most problems on VIA chip-sets with no IO-APIC.
The one below is unusual because it is a 2-way system with 3 IO-APICs.
The latest code in linus' tree includes ACPICA 20030813, which is
slightly newer than the one below, it might be a good idea to try that
with CONFIG_ACPI_DEBUG. Note that it will spit out the DMI info upon
the mount root failure automatically.
Tomasz,
I'm glad that 'acpi=force pci=noacpi' got your system up and running.
Andrew is right, needing acpi=force is intentional due to the age of the
system --
we're running away from aging broken BIOS's that vendors
refuse to update, and we need to draw the line someplace.
Some say that the 2001 should really be 2002...
But, needing pci=noacpi if you successfully ran with ACPI enabled before
would be a regression.
Thanks for sending the acpidmp output.
The DSDT shows Award's "VT86" PIRQ mapping code that we've been
struggling with recently.
Indeed, the lastest ACPI patch seems to help the modern descendents of
your machine.
But I don't see any obvious errors in the AML for the interrupt part on
your box.
Using IASL to re-build your disassembled DSDT showed some static errors
that will kill you if you hit them them at run time. If you really want
to use ACPI for run-time features on this box you'd probably need to
modify your DSDT and over-ride it for starters. There are a number of
web pages devoted to that hobby.
I'm more interested in the interrupt issue. If you'd like to help us
debug it, then please file a bug at http://bugzilla.kernel.org/
Category: power management, componenet: ACPI and attach your dmidecode
and acpidmp output. The next piece to get would be the console messages
from the failing case -- you'd need a serial console to capture them.
Thanks,
-Len
lenb@dhcppc4:/smb/tomasz.torcz> acpixtract DSDT acpidmp >DSDT
lenb@dhcppc4:/smb/tomasz.torcz> iasl -d DSDT
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030522 [May 23
2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
Loading Acpi table from file DSDT
Acpi table [DSDT] successfully installed and loaded
Pass 1 parse of [DSDT]
Pass 2 parse of [DSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
........................................................................
...........................................................
Parsing completed
Disassembly completed, written to "DSDT.dsl"
lenb@dhcppc4:/smb/tomasz.torcz>
lenb@dhcppc4:/smb/tomasz.torcz> ls
DSDT DSDT.dsl acpidisasm acpidmp dmesg.pcinoacpi.acpioff dsdt
lenb@dhcppc4:/smb/tomasz.torcz> iasl DSDT.dsl
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20030522 [May 23
2003]
Copyright (C) 2000 - 2003 Intel Corporation
Supports ACPI Specification Revision 2.0b
DSDT.dsl 257: Method (\_WAK, 1, NotSerialized)
Warning 2026 - ^ Reserved method must return a value
(_WAK)
DSDT.dsl 269: Store (Local0, Local0)
Error 1013 - ^ Method local variable is not
initialized (Local0)
DSDT.dsl 277: Store (Local0, Local0)
Error 1013 - ^ Method local variable is not
initialized (Local0)
DSDT.dsl 1761: Store (Local0, Local0)
Error 1013 - ^ Method local
variable is not initialized (Local0)
DSDT.dsl 1995: Method (_STA, 0, NotSerialized)
Warning 2019 - ^ Not all control paths
return a value (_STA)
DSDT.dsl 1995: Method (_STA, 0, NotSerialized)
Warning 2026 - ^ Reserved method must
return a value (_STA)
ASL Input: DSDT.dsl - 2203 lines, 75934 bytes, 987 keywords
Compilation complete. 3 Errors, 3 Warnings, 0 Remarks, 235 Optimizations
lenb@dhcppc4:/smb/tomasz.torcz>
> -----Original Message-----
> From: Tomasz Torcz [mailto:[email protected]]
> Sent: Saturday, August 23, 2003 5:38 PM
> To: Brown, Len
> Subject: Re: 2.6.0-test4 - lost ACPI
>
>
> On Sat, Aug 23, 2003 at 04:58:00PM -0400, Brown, Len wrote:
> > pci=noacpi is also an option. If it works, then it means
> you got burnt
> > by ACPI's PCI interrupt code.
>
> Good shot! With 'acpi=force pci=noacpi' it booted ok and works.
> I've attached dmesg FYI.
>
> > We've had trouble with Award/VIA in this
> > area recently, so it wouldn't be surprising to have trouble with a
> > 3-year old Award/VIA BIOS. The puzzling thing is why ACPI enabled
> > worked for you before and doesn't work now.
>
> I can test patches. Unfortunetely I'm not good enough programmer to
> create them.
>
> > I'd be interested in looking over a copy of your /proc/acpi/dsdt, or
> > even better, the output from acpidmp,
>
> Attached (gzipped)
>
> --
> Tomasz Torcz RIP is irrevelant. Spoofing is futile.
> [email protected] Your routes will be
> aggreggated. -- Alex Yuriev
>
----- Original Message -----
From: Tomasz Torcz <[email protected]>
Date: Sun, 24 Aug 2003 00:04:38 +0200
To: LKML <[email protected]>
Subject: Re: 2.6.0-test4 - lost ACPI
> On Sat, Aug 23, 2003 at 02:55:45PM -0700, Andrew Morton wrote:
> > Tomasz Torcz <[email protected]> wrote:
> >
> > > ACPI disabled because your bios is from 00 and too old
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > Add "acpi=force" to your kernel boot command line and everything should work
> > as before.
>
> It does not work. It halts in beetween ps/2 mouse init and serio init.
> Adding "acpi=force pci=noacpi" solves that.
Yeah! I have the same problem on my P4 box. Please, take a look at:
http://bugzilla.kernel.org/show_bug.cgi?id=1123ml/
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
I don't recall seeing the ACPI disabled line, but mine had the same
problem halting between PS/2 init and serio. The change I noticed was
that IRQ's were being allocated differently, and that is what I
attributed this failure to. My motherboard worked with 2.6.0-test3-mm2,
but has not worked since 2.6.0-test3-mm3 (when the new ACPI code was
added).
I'll have to try this acpi=force and pci=noacpi, otherwise I have to
disable USB and sound to get it to boot.
Wes
Tomasz Torcz wrote:
>On Sat, Aug 23, 2003 at 02:55:45PM -0700, Andrew Morton wrote:
>
>
>>Tomasz Torcz <[email protected]> wrote:
>>
>>
>>
>>> ACPI disabled because your bios is from 00 and too old
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>
>>>
>>Add "acpi=force" to your kernel boot command line and everything should work
>>as before.
>>
>>
>
>It does not work. It halts in beetween ps/2 mouse init and serio init.
>Adding "acpi=force pci=noacpi" solves that.
>
>
>