Re: [Devel] MP configuration table construction
by Zhao, Yakui
-----Original Message-----
From: devel-bounces(a)acpica.org [mailto:devel-bounces@acpica.org] On Behalf Of Carter, Richard
Sent: Friday, September 18, 2009 10:29 AM
To: devel(a)acpica.org
Subject: [Devel] MP configuration table construction
I work for a commercial OS vendor. I've been asked to use ACPI to
construct MP tables for some pentium boards that either lack a table or
have errors in it. I have some questions and hope someone out in the
community can answer them.
As noted in the ACPI spec (par 5.2.11.7), should the MP table always
have entries for the 16 ISA interrupts when dual-8259 support is
indicated in the MADT?
If dual-8259 support is not indicated, how do I determine which ISA
interrupts are available?
[Yakui]: Only the override interrupt entry is provided in MADT table.
So when we construct the MP table by using ACPI MADT table, we should first use the
Override interrupt entry to construct the ISA interrupts. Then the remaining ISA
Interrupts are filled with the legacy setting.
The PCI routing table reported by acpiGetIrqRoutingTable doesn't
indicate interrupt level and triggering. Do PCI interrupts always
conform to the bus specification or is there some other method for ACPI
to report differences?
[Yakui]: This depends on the returned value in _PRT table.
If the following _PRT entry is returned, it uses the default PCI interrupt level/triggering.
Package (0x04)
{
0x001DFFFF,
0x01,
0x00,
0x15
},
If the following _PRT entry is returned, it uses the interrupt level/triggering parsed in
The corresponding LINK device.
Package (0x04) {
0xFFFF,
0x00,
\_SB.PCI0.LNKA,
0x00
},
When there is more tha 1 IOAPIC, how does one determine which IOAPIC an
interrupt reported by the _PRT belongs to? I see a GlobalIrqBase
reported in the MADT IOAPIC record. Is this normally used to lookup
which IOAPIC the IRQ is connected to?
[Yakui]: Every IOAPIC has its own GSI interrupt base. When we get one GSI
Number for one PCI device, we can use the GSI number to identify which IOAPIC is
Used. For IRQ umber: We should first get the corresponding GSI number(This info can
Be found in dmesg). And we can use the gsi number to find which IOAPIC is connected.
Thanks.
Thanks in advance
Rich Carter
603-897-2071
_______________________________________________
Devel mailing list
Devel(a)acpica.org
http://lists.acpica.org/listinfo/devel
13 years
MP configuration table construction
by Carter, Richard
I work for a commercial OS vendor. I've been asked to use ACPI to
construct MP tables for some pentium boards that either lack a table or
have errors in it. I have some questions and hope someone out in the
community can answer them.
As noted in the ACPI spec (par 5.2.11.7), should the MP table always
have entries for the 16 ISA interrupts when dual-8259 support is
indicated in the MADT?
If dual-8259 support is not indicated, how do I determine which ISA
interrupts are available?
The PCI routing table reported by acpiGetIrqRoutingTable doesn't
indicate interrupt level and triggering. Do PCI interrupts always
conform to the bus specification or is there some other method for ACPI
to report differences?
When there is more tha 1 IOAPIC, how does one determine which IOAPIC an
interrupt reported by the _PRT belongs to? I see a GlobalIrqBase
reported in the MADT IOAPIC record. Is this normally used to lookup
which IOAPIC the IRQ is connected to?
Thanks in advance
Rich Carter
603-897-2071
13 years
Re: [Devel] [PATCH] Repair predefined Package -> Buffer
by Jung-uk Kim
On Tuesday 08 September 2009 01:09 pm, Jung-uk Kim wrote:
> On Friday 04 September 2009 06:36 pm, Moore, Robert wrote:
> > Sounds like a good idea. I'll look at it next week.
>
> Here I attached an optimized version of the patch.
>
> > In general, we now have the capability to add these kinds of
> > fixes easily, so keep your eye out for anything that can be
> > repaired like this.
>
> I will.
I found we need another patch for nspredef.c. When we repair Package
-> Buffer, the previous package is still referenced to check
sub-object type and causes trouble. I think there are three options:
1) reset ReturnObject from *ReturnObjectPtr if it is repaired, 2)
reset ReturnObject unconditionally, or 3) do not test sub-object if
the package is repaired assuming AcpiNsRepairObject() does the right
thing. The attached patch is option #1 but feel free to implement #2
or #3. :-)
Thanks,
Jung-uk Kim
13 years
FW: [PATCH] Repair predefined Package -> Buffer
by Moore, Robert
-----Original Message-----
From: Moore, Robert
Sent: Friday, September 04, 2009 3:37 PM
To: 'Jung-uk Kim'
Cc: Lin, Ming M
Subject: RE: [Devel] [PATCH] Repair predefined Package -> Buffer
Sounds like a good idea. I'll look at it next week.
In general, we now have the capability to add these kinds of fixes easily, so keep your eye out for anything that can be repaired like this.
Thanks,
Bob
>-----Original Message-----
>From: devel-bounces(a)acpica.org [mailto:devel-bounces@acpica.org] On Behalf
>Of Jung-uk Kim
>Sent: Friday, September 04, 2009 3:10 PM
>To: devel(a)acpica.org
>Subject: [Devel] [PATCH] Repair predefined Package -> Buffer
>
>One of the most common mistake of _FDE is returning Package instead of
>Buffer of five 32-bit integers. The attached patch repairs the case.
>Do you think it is a reasonable fix? Basically, I want to get rid of
>a quirk handling in FreeBSD. :-)
>
>Thanks!
>
>Jung-uk Kim
13 years, 1 month
[PATCH] Repair predefined Package -> Buffer
by Jung-uk Kim
One of the most common mistake of _FDE is returning Package instead of
Buffer of five 32-bit integers. The attached patch repairs the case.
Do you think it is a reasonable fix? Basically, I want to get rid of
a quirk handling in FreeBSD. :-)
Thanks!
Jung-uk Kim
13 years, 1 month
Correct ACPI setup sequence
by Joerg Sonnenberger
Hi all,
after some puzzling issues with different DSDT on various system I would
like to know the correct/best way to setup ACPICA.
The core of the init sequence is:
AcpiEnableSubsystem(ACPI_FULL_INITIALIZATION);
AcpiInitializeObjects(ACPI_FULL_INITIALIZATION);
As part of the former call, the event subsystem is initialised,
including setting up the SCI. To process that request, the overrides in
the MADT have to be parsed and that in turn requires switching to APIC
mode.
This now leaves two primary options:
- Switch to APIC mode and parse the MADT from the
AcpiOsInstallInterruptHandler
- Defer the SCI setup until after the call.
The second is messy and can't be the intention of the code. The former
makes me wonder about the error resilience though. We have seen some
DSDTs in NetBSD that do not setup the _PRT correctly before the object
initialisations are done. I don't know yet, if the _INI change in the
last release fixed that. I am wondering though, if the MADT processing
can be affecting by the same issue. Are there any known cases of such
DSDTs?
The second issue is the question of reentrancy. Is ACPICA supposed to be
reentrant enough to allow this?
Joerg
13 years, 1 month
[Bug 738] iASL mishandles Alias() when target is longer than single nameseg
by bugzilla-daemon＠mail.opensource.intel.com
show_bug.cgi?id=738
Bob Moore <robert.moore(a)intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED
--- Comment #13 from Bob Moore <robert.moore(a)intel.com> 2009-09-03 14:03:02 ---
Fixed in ACPICA version 20090903.
--
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
13 years, 1 month
ACPICA version 20090903 released
by Moore, Robert
03 September 2009. Summary of changes for version 20090903:
This release is available at www.acpica.org/downloads
1) ACPI CA Core Subsystem:
For Windows Vista compatibility, added the automatic execution of an _INI method located at the namespace root (\_INI). This method is executed at table load time. This support is in addition to the automatic execution of \_SB._INI. Lin Ming.
Fixed a possible memory leak in the interpreter for AML package objects if the package initializer list is longer than the defined size of the package. This apparently can only happen if the BIOS changes the package size on the fly (seen in a _PSS object), as ASL compilers do not allow this. The interpreter will truncate the package to the defined size (and issue an error message), but previously could leave the extra objects undeleted if they were pre-created during the argument processing (such is the case if the package consists of a number of sub-packages as in the _PSS.) ACPICA BZ 805.
Fixed a problem seen when a Buffer or String is stored to itself via ASL. This has been reported in the field. Previously, ACPICA would zero out the buffer/string. Now, the operation is treated as a noop. Provides Windows compatibility. ACPICA BZ 803. Lin Ming.
Removed an extraneous error message for ASL constructs of the form Store(LocalX,LocalX) when LocalX is uninitialized. These curious statements are seen in many BIOSs and are once again treated as NOOPs and no error is emitted when they are encountered. ACPICA BZ 785.
Fixed an extraneous warning message if a _DSM reserved method returns a Package object. _DSM can return any type of object, so validation on the return type cannot be performed. ACPICA BZ 802.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 6.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Previous Release:
Non-Debug Version: 85.5K Code, 18.0K Data, 103.5K Total
Debug Version: 161.6K Code, 50.9K Data, 212.5K Total
Current Release:
Non-Debug Version: 85.6K Code, 18.0K Data, 103.6K Total
Debug Version: 161.7K Code, 50.9K Data, 212.6K Total
2) iASL Compiler/Disassembler and Tools:
iASL: Fixed a problem with the use of the Alias operator and Resource Templates. The correct alias is now constructed and no error is emitted. ACPICA BZ 738.
iASL: Implemented the -I option to specify additional search directories for include files. Allows multiple additional search paths for include files. Directories are searched in the order specified on the command line (after the local directory is searched.) ACPICA BZ 800.
iASL: Fixed a problem where the full pathname for include files was not emitted for warnings/errors. This caused the IDE support to not work properly. ACPICA BZ 765.
iASL: Implemented the -@ option to specify a Windows-style response file containing additional command line options. ACPICA BZ 801.
AcpiExec: Added support to load multiple AML files simultaneously (such as a DSDT and multiple SSDTs). Also added support for wildcards within the AML pathname. These features allow all machine tables to be easily loaded and debugged together. ACPICA BZ 804.
Disassembler: Added missing support for disassembly of HEST table Error Bank subtables.
13 years, 1 month
[Bug 738] iASL mishandles Alias() when target is longer than single nameseg
by bugzilla-daemon＠mail.opensource.intel.com
show_bug.cgi?id=738
--- Comment #12 from Bob Moore <robert.moore(a)intel.com> 2009-09-01 13:24:58 ---
The comments starting at #4 are describing a different problem than the
original.
--
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
13 years, 1 month
