* [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
@ 2001-03-06 1:30 Keith Owens
2001-03-06 18:49 ` Mallick, Asit K
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: Keith Owens @ 2001-03-06 1:30 UTC (permalink / raw)
To: linux-ia64
BugSur 2 B1 cpus. PAL 2213, BIOS W460GXBS2.86E.0070.B.200008150911.
Kernel 2.4.2 + ia64-010228. I am getting semi-random data in the acpi
tables which more often than not will hang the machine during boot.
Linux version 2.4.2-ia64-010228-kdb (kaos@sherman.melbourne.sgi.com) (gcc version 2.96-ia64-000717 snap 001117) #17 SMP Tue Mar 6 11:28:03 EST 2001
Warning: EFI system table major version mismatch: got 0.99, expected 1.00
EFI v0.99 by INTEL: SALsystab=0x3ff23a80 ACPI=0x3ffd9be0 MPS=0x3ffd0000 SMBIOS=0xf0020
CPU 0: mapping PAL code [0x3ff40000-0x3ff7a000) into [0xe000000030000000-0xe000000040000000)
SAL v2.90: oem=INTEL MSL REF SAL , product=
sal[0] - entry: pal_proc=0x3ff48010, sal_proc=0x3fe4bd70
SAL: Platform features BusLock
sal[27] - wakeup type 0, 0xf0
SAL: AP wakeup using external interrupt vector 0xf0
CPU 0: 51 virtual and 44 physical address bits
ACPI: Intel RSDT 0.0
Acpi cfg:bind to Boot time Acpi OSD
Acpi cfg:initializ_subsysteme pass
Acpi cfg:load firmware tables pass
ACPI: install SCI 32 handler pass
Acpi cfg:enable_subsystem pass
CPU 0 (0000:0000): Available.
CPU 1 (0000:0003): Available.
Acpi Cfg: _PRT found. Need 336 bytes
Acpi cfg:path=[\_SB_.PCI0]
Acpi cfg:_BBN busnum is 0
Acpi cfg:no _STA: pci bus 0 exist
KAO acpi_cf_add_to_pci_routing_tables e000000000013b88
Acpi Cfg: _PRT found. Need 312 bytes
Acpi cfg:path=[\_SB_.PCI1]
Acpi cfg:_BBN busnum is 1
Acpi cfg:no _STA: pci bus 1 exist
KAO acpi_cf_add_to_pci_routing_tables e000000000015d88
Acpi Cfg: _PRT found. Need 216 bytes
Acpi cfg:path=[\_SB_.PCI2]
Acpi cfg:_BBN busnum is 2
Acpi cfg:_STA: pci bus 2 exist
KAO acpi_cf_add_to_pci_routing_tables e000000000017488
Acpi Cfg: _PRT found. Need 48 bytes
Acpi cfg:path=[\_SB_.PCI3]
Acpi cfg:_BBN busnum is 3
Acpi cfg:no _STA: pci bus 3 exist
On a clean boot, the first acpi table looks like this, note the zero at
0xe000000000013cd8.
[0]kdb> md e000000000013b88
0xe000000000013b88 00000018 00000000 0004ffff 00000000 ........ÿÿ......
0xe000000000013b98 0000002d 00000000 00000018 00000000 -...............
0xe000000000013ba8 0005ffff 00000000 0000002c 00000000 ÿÿ......,.......
0xe000000000013bb8 00000018 00000000 0001ffff 00000000 ........ÿÿ......
0xe000000000013bc8 00000023 00000000 00000018 00000001 #...............
0xe000000000013bd8 0001ffff 00000000 00000022 00000000 ÿÿ......".......
0xe000000000013be8 00000018 00000002 0001ffff 00000000 ........ÿÿ......
0xe000000000013bf8 00000021 00000000 00000018 00000003 !...............
0xe000000000013c08 0001ffff 00000000 00000020 00000000 ÿÿ...... .......
0xe000000000013c18 00000018 00000000 0002ffff 00000000 ........ÿÿ......
0xe000000000013c28 00000027 00000000 00000018 00000001 '...............
0xe000000000013c38 0002ffff 00000000 00000026 00000000 ÿÿ......&.......
0xe000000000013c48 00000018 00000002 0002ffff 00000000 ........ÿÿ......
0xe000000000013c58 00000025 00000000 00000018 00000003 %...............
0xe000000000013c68 0002ffff 00000000 00000024 00000000 ÿÿ......$.......
0xe000000000013c78 00000018 00000000 0003ffff 00000000 ........ÿÿ......
0xe000000000013c88 0000002e 00000000 00000018 00000001 ................
0xe000000000013c98 0003ffff 00000000 0000002e 00000000 ÿÿ..............
0xe000000000013ca8 00000018 00000002 0003ffff 00000000 ........ÿÿ......
0xe000000000013cb8 0000002f 00000000 00000018 00000003 /...............
0xe000000000013cc8 0003ffff 00000000 0000002f 00000000 ÿÿ....../.......
0xe000000000013cd8 00000000 00000000 00000000 00000000 ................
0xe000000000013ce8 00000000 00000000 00000000 00000000 ................
0xe000000000013cf8 00000000 00000000 00000010 00000000 ................
On a failing boot, the first acpi table looks like this. 0xe000000000013cd8
contains 000000ee which sends acpi_cf_convert_prt_to_vectors off to the
wrong location, gets unaligned accesses and more often than not will
hang the machine.
[0]kdb> md e000000000013b88
0xe000000000013b88 00000018 00000000 0004ffff 00000000 ........ÿÿ......
0xe000000000013b98 0000002d 00000000 00000018 00000000 -...............
0xe000000000013ba8 0005ffff 00000000 0000002c 00000000 ÿÿ......,.......
0xe000000000013bb8 00000018 00000000 0001ffff 00000000 ........ÿÿ......
0xe000000000013bc8 00000023 00000000 00000018 00000001 #...............
0xe000000000013bd8 0001ffff 00000000 00000022 00000000 ÿÿ......".......
0xe000000000013be8 00000018 00000002 0001ffff 00000000 ........ÿÿ......
0xe000000000013bf8 00000021 00000000 00000018 00000003 !...............
0xe000000000013c08 0001ffff 00000000 00000020 00000000 ÿÿ...... .......
0xe000000000013c18 00000018 00000000 0002ffff 00000000 ........ÿÿ......
0xe000000000013c28 00000027 00000000 00000018 00000001 '...............
0xe000000000013c38 0002ffff 00000000 00000026 00000000 ÿÿ......&.......
0xe000000000013c48 00000018 00000002 0002ffff 00000000 ........ÿÿ......
0xe000000000013c58 00000025 00000000 00000018 00000003 %...............
0xe000000000013c68 0002ffff 00000000 00000024 00000000 ÿÿ......$.......
0xe000000000013c78 00000018 00000000 0003ffff 00000000 ........ÿÿ......
0xe000000000013c88 0000002e 00000000 00000018 00000001 ................
0xe000000000013c98 0003ffff 00000000 0000002e 00000000 ÿÿ..............
0xe000000000013ca8 00000018 00000002 0003ffff 00000000 ........ÿÿ......
0xe000000000013cb8 0000002f 00000000 00000018 00000003 /...............
0xe000000000013cc8 0003ffff 00000000 0000002f 00000000 ÿÿ....../.......
0xe000000000013cd8 000000ee 00000000 00000000 00000000 î...............
0xe000000000013ce8 00000000 00000000 0001d1d1 00000000 ........ÑÑ......
0xe000000000013cf8 000100ee 00000000 00000010 00000000 î...............
Since we know the table size (Acpi Cfg: _PRT found. Need 336 bytes)
should acpi use the table size instead of looking for a zero length?
2.4.1-ia64-010131 with the same config and compiler works fine on this
machine. It may not be relevant but even when 2.4.2 boots past the
acpi problem, /sbin/init spins in user space. No idea why yet, it is
very rare that I can get past acpi.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
2001-03-06 1:30 [Linux-ia64] ACPI problems in 2.4.2-ia64-010228 Keith Owens
@ 2001-03-06 18:49 ` Mallick, Asit K
2001-03-06 23:06 ` Keith Owens
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Mallick, Asit K @ 2001-03-06 18:49 UTC (permalink / raw)
To: linux-ia64
Looks like the FW is build 70 and was built on 8/15. Do you see this problem
with newer version of the FW also? We will look into this problem.
Thanks,
Asit
> -----Original Message-----
> From: Keith Owens [mailto:kaos@melbourne.sgi.com]
> Sent: Monday, March 05, 2001 5:31 PM
> To: davidm@hpl.hp.com
> Cc: Grover, Andrew; linux-ia64@linuxia64.org
> Subject: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
>
>
> BugSur 2 B1 cpus. PAL 2213, BIOS W460GXBS2.86E.0070.B.200008150911.
> Kernel 2.4.2 + ia64-010228. I am getting semi-random data in the acpi
> tables which more often than not will hang the machine during boot.
>
> Linux version 2.4.2-ia64-010228-kdb
> (kaos@sherman.melbourne.sgi.com) (gcc version
> 2.96-ia64-000717 snap 001117) #17 SMP Tue Mar 6 11:28:03 EST 2001
> Warning: EFI system table major version mismatch: got 0.99,
> expected 1.00
> EFI v0.99 by INTEL: SALsystab=0x3ff23a80 ACPI=0x3ffd9be0
> MPS=0x3ffd0000 SMBIOS=0xf0020
> CPU 0: mapping PAL code [0x3ff40000-0x3ff7a000) into
> [0xe000000030000000-0xe000000040000000)
> SAL v2.90: oem=INTEL MSL REF SAL , product=
> sal[0] - entry: pal_proc=0x3ff48010, sal_proc=0x3fe4bd70
> SAL: Platform features BusLock
> sal[27] - wakeup type 0, 0xf0
> SAL: AP wakeup using external interrupt vector 0xf0
> CPU 0: 51 virtual and 44 physical address bits
> ACPI: Intel RSDT 0.0
> Acpi cfg:bind to Boot time Acpi OSD
> Acpi cfg:initializ_subsysteme pass
> Acpi cfg:load firmware tables pass
> ACPI: install SCI 32 handler pass
> Acpi cfg:enable_subsystem pass
> CPU 0 (0000:0000): Available.
> CPU 1 (0000:0003): Available.
> Acpi Cfg: _PRT found. Need 336 bytes
> Acpi cfg:path=[\_SB_.PCI0]
> Acpi cfg:_BBN busnum is 0
> Acpi cfg:no _STA: pci bus 0 exist
> KAO acpi_cf_add_to_pci_routing_tables e000000000013b88
> Acpi Cfg: _PRT found. Need 312 bytes
> Acpi cfg:path=[\_SB_.PCI1]
> Acpi cfg:_BBN busnum is 1
> Acpi cfg:no _STA: pci bus 1 exist
> KAO acpi_cf_add_to_pci_routing_tables e000000000015d88
> Acpi Cfg: _PRT found. Need 216 bytes
> Acpi cfg:path=[\_SB_.PCI2]
> Acpi cfg:_BBN busnum is 2
> Acpi cfg:_STA: pci bus 2 exist
> KAO acpi_cf_add_to_pci_routing_tables e000000000017488
> Acpi Cfg: _PRT found. Need 48 bytes
> Acpi cfg:path=[\_SB_.PCI3]
> Acpi cfg:_BBN busnum is 3
> Acpi cfg:no _STA: pci bus 3 exist
>
> On a clean boot, the first acpi table looks like this, note
> the zero at
> 0xe000000000013cd8.
>
> [0]kdb> md e000000000013b88
> 0xe000000000013b88 00000018 00000000 0004ffff 00000000
> ........ÿÿ......
> 0xe000000000013b98 0000002d 00000000 00000018 00000000
> -...............
> 0xe000000000013ba8 0005ffff 00000000 0000002c 00000000
> ÿÿ......,.......
> 0xe000000000013bb8 00000018 00000000 0001ffff 00000000
> ........ÿÿ......
> 0xe000000000013bc8 00000023 00000000 00000018 00000001
> #...............
> 0xe000000000013bd8 0001ffff 00000000 00000022 00000000
> ÿÿ......".......
> 0xe000000000013be8 00000018 00000002 0001ffff 00000000
> ........ÿÿ......
> 0xe000000000013bf8 00000021 00000000 00000018 00000003
> !...............
> 0xe000000000013c08 0001ffff 00000000 00000020 00000000
> ÿÿ...... .......
> 0xe000000000013c18 00000018 00000000 0002ffff 00000000
> ........ÿÿ......
> 0xe000000000013c28 00000027 00000000 00000018 00000001
> '...............
> 0xe000000000013c38 0002ffff 00000000 00000026 00000000
> ÿÿ......&.......
> 0xe000000000013c48 00000018 00000002 0002ffff 00000000
> ........ÿÿ......
> 0xe000000000013c58 00000025 00000000 00000018 00000003
> %...............
> 0xe000000000013c68 0002ffff 00000000 00000024 00000000
> ÿÿ......$.......
> 0xe000000000013c78 00000018 00000000 0003ffff 00000000
> ........ÿÿ......
> 0xe000000000013c88 0000002e 00000000 00000018 00000001
> ................
> 0xe000000000013c98 0003ffff 00000000 0000002e 00000000
> ÿÿ..............
> 0xe000000000013ca8 00000018 00000002 0003ffff 00000000
> ........ÿÿ......
> 0xe000000000013cb8 0000002f 00000000 00000018 00000003
> /...............
> 0xe000000000013cc8 0003ffff 00000000 0000002f 00000000
> ÿÿ....../.......
> 0xe000000000013cd8 00000000 00000000 00000000 00000000
> ................
> 0xe000000000013ce8 00000000 00000000 00000000 00000000
> ................
> 0xe000000000013cf8 00000000 00000000 00000010 00000000
> ................
>
> On a failing boot, the first acpi table looks like this.
> 0xe000000000013cd8
> contains 000000ee which sends acpi_cf_convert_prt_to_vectors
> off to the
> wrong location, gets unaligned accesses and more often than not will
> hang the machine.
>
> [0]kdb> md e000000000013b88
> 0xe000000000013b88 00000018 00000000 0004ffff 00000000
> ........ÿÿ......
> 0xe000000000013b98 0000002d 00000000 00000018 00000000
> -...............
> 0xe000000000013ba8 0005ffff 00000000 0000002c 00000000
> ÿÿ......,.......
> 0xe000000000013bb8 00000018 00000000 0001ffff 00000000
> ........ÿÿ......
> 0xe000000000013bc8 00000023 00000000 00000018 00000001
> #...............
> 0xe000000000013bd8 0001ffff 00000000 00000022 00000000
> ÿÿ......".......
> 0xe000000000013be8 00000018 00000002 0001ffff 00000000
> ........ÿÿ......
> 0xe000000000013bf8 00000021 00000000 00000018 00000003
> !...............
> 0xe000000000013c08 0001ffff 00000000 00000020 00000000
> ÿÿ...... .......
> 0xe000000000013c18 00000018 00000000 0002ffff 00000000
> ........ÿÿ......
> 0xe000000000013c28 00000027 00000000 00000018 00000001
> '...............
> 0xe000000000013c38 0002ffff 00000000 00000026 00000000
> ÿÿ......&.......
> 0xe000000000013c48 00000018 00000002 0002ffff 00000000
> ........ÿÿ......
> 0xe000000000013c58 00000025 00000000 00000018 00000003
> %...............
> 0xe000000000013c68 0002ffff 00000000 00000024 00000000
> ÿÿ......$.......
> 0xe000000000013c78 00000018 00000000 0003ffff 00000000
> ........ÿÿ......
> 0xe000000000013c88 0000002e 00000000 00000018 00000001
> ................
> 0xe000000000013c98 0003ffff 00000000 0000002e 00000000
> ÿÿ..............
> 0xe000000000013ca8 00000018 00000002 0003ffff 00000000
> ........ÿÿ......
> 0xe000000000013cb8 0000002f 00000000 00000018 00000003
> /...............
> 0xe000000000013cc8 0003ffff 00000000 0000002f 00000000
> ÿÿ....../.......
> 0xe000000000013cd8 000000ee 00000000 00000000 00000000
> î...............
> 0xe000000000013ce8 00000000 00000000 0001d1d1 00000000
> ........ÑÑ......
> 0xe000000000013cf8 000100ee 00000000 00000010 00000000
> î...............
>
> Since we know the table size (Acpi Cfg: _PRT found. Need 336 bytes)
> should acpi use the table size instead of looking for a zero length?
>
> 2.4.1-ia64-010131 with the same config and compiler works fine on this
> machine. It may not be relevant but even when 2.4.2 boots past the
> acpi problem, /sbin/init spins in user space. No idea why yet, it is
> very rare that I can get past acpi.
>
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
2001-03-06 1:30 [Linux-ia64] ACPI problems in 2.4.2-ia64-010228 Keith Owens
2001-03-06 18:49 ` Mallick, Asit K
@ 2001-03-06 23:06 ` Keith Owens
2001-03-07 7:11 ` Keith Owens
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Keith Owens @ 2001-03-06 23:06 UTC (permalink / raw)
To: linux-ia64
On Tue, 6 Mar 2001 10:49:42 -0800,
"Mallick, Asit K" <asit.k.mallick@intel.com> wrote:
>Looks like the FW is build 70 and was built on 8/15. Do you see this problem
>with newer version of the FW also? We will look into this problem.
The strange thing is that 2.4.1-ia64-010131 with the same config and
compiler works fine on this machine. I will look into upgrading the
firmware.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
2001-03-06 1:30 [Linux-ia64] ACPI problems in 2.4.2-ia64-010228 Keith Owens
2001-03-06 18:49 ` Mallick, Asit K
2001-03-06 23:06 ` Keith Owens
@ 2001-03-07 7:11 ` Keith Owens
2001-03-07 11:01 ` Keith Owens
2001-03-07 19:38 ` Jonathan_Kwahk
4 siblings, 0 replies; 6+ messages in thread
From: Keith Owens @ 2001-03-07 7:11 UTC (permalink / raw)
To: linux-ia64
On Tue, 06 Mar 2001 12:30:55 +1100,
Keith Owens <kaos@melbourne.sgi.com> wrote:
>BugSur 2 B1 cpus. PAL 2213, BIOS W460GXBS2.86E.0070.B.200008150911.
>Kernel 2.4.2 + ia64-010228. I am getting semi-random data in the acpi
>tables which more often than not will hang the machine during boot.
Upgraded to PAL 2215, W460GXBS2.86E.0084.P02.200010271750. Still
getting the ACPI problems. Currently EFI 0.99, is there a more recent
version version of EFI for BigSur?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
2001-03-06 1:30 [Linux-ia64] ACPI problems in 2.4.2-ia64-010228 Keith Owens
` (2 preceding siblings ...)
2001-03-07 7:11 ` Keith Owens
@ 2001-03-07 11:01 ` Keith Owens
2001-03-07 19:38 ` Jonathan_Kwahk
4 siblings, 0 replies; 6+ messages in thread
From: Keith Owens @ 2001-03-07 11:01 UTC (permalink / raw)
To: linux-ia64
On Wed, 07 Mar 2001 18:11:47 +1100,
Keith Owens <kaos@melbourne.sgi.com> wrote:
>Upgraded to PAL 2215, W460GXBS2.86E.0084.P02.200010271750. Still
>getting the ACPI problems.
It gets worse. Since upgrading the BIOS I have had two occurrences
where the timer stopped moving on cpu 0 and one occurrence where the
timer stopped on both cpus. The clock was not changing and the timer
interrupt count had frozen. Kernel 2.4.1.
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
2001-03-06 1:30 [Linux-ia64] ACPI problems in 2.4.2-ia64-010228 Keith Owens
` (3 preceding siblings ...)
2001-03-07 11:01 ` Keith Owens
@ 2001-03-07 19:38 ` Jonathan_Kwahk
4 siblings, 0 replies; 6+ messages in thread
From: Jonathan_Kwahk @ 2001-03-07 19:38 UTC (permalink / raw)
To: linux-ia64
Yes, for Big Sur there is a more recent BIOS build than 89B (I currently
have 99 PAL 6.6.19).
I believe the EFI version is 12.33 based on the EFI spec. rev. 1.02.
SAL revision is 1.01 based on SAL spec. rev. 2.9.
I would try to get my hands on the 99 build since it supports many missing
SMBIOS structure types, MCA (i think it's memory correction algorithm), and
other fixes.
J
-----Original Message-----
From: Keith Owens [mailto:kaos@melbourne.sgi.com]
Sent: Wednesday, March 07, 2001 1:12 AM
To: davidm@hpl.hp.com; Grover, Andrew; linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] ACPI problems in 2.4.2-ia64-010228
On Tue, 06 Mar 2001 12:30:55 +1100,
Keith Owens <kaos@melbourne.sgi.com> wrote:
>BugSur 2 B1 cpus. PAL 2213, BIOS W460GXBS2.86E.0070.B.200008150911.
>Kernel 2.4.2 + ia64-010228. I am getting semi-random data in the acpi
>tables which more often than not will hang the machine during boot.
Upgraded to PAL 2215, W460GXBS2.86E.0084.P02.200010271750. Still
getting the ACPI problems. Currently EFI 0.99, is there a more recent
version version of EFI for BigSur?
_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2001-03-07 19:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-06 1:30 [Linux-ia64] ACPI problems in 2.4.2-ia64-010228 Keith Owens
2001-03-06 18:49 ` Mallick, Asit K
2001-03-06 23:06 ` Keith Owens
2001-03-07 7:11 ` Keith Owens
2001-03-07 11:01 ` Keith Owens
2001-03-07 19:38 ` Jonathan_Kwahk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox