[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error
> > > I also tested on my Ivy Bridge i7 desktop, and there xen-acpi-processor > > > driver loads OK.. > > > > And when I add some extra printks in working box I see that these calls: > > > > acpi_get_handle(pr->handle, "_PCT", &handle); > > acpi_get_handle(pr->handle, "_PSD", &handle); > > acpi_get_handle(pr->handle, "_PSS", &handle); > > > > work, yet in the SSDT and DSDT those strings don't show up? > > > > That's weird.. then again it probably explains why I didn't see > those strings either in SSDT/DSDT on the i7 boxes. > > > I think this > > requires some deep ACPI sorcery to figure out. On the AMD boxes they > > nicely show up. > > > > Yeah I was afraid of that ;) > > I've already tried simple things with acpi.debug_level=0xffffffff and > acpi.debug_layer=0xffffffff > but nothing obvious so far.. I need to dig deeper.. > > It'd help to understand how all that SSDT/DSDT and PCT/PSD/PSS stuff is > supposed to work.. > If you happen to have good links to read about this ACPI black magic let me > know (I'll probably regret asking for this ;) I've been using a combination of http://www.plasma-online.de/index.html?content=http%3A//www.plasma-online.de/english/identify/serial/pnp_id_pnp.html and the DSDT to eliminate all of the entries that are not relevant to power-states. Also, the P-states (and C-states) are all within the: Scope (\_PR) { .. } that. Also the ACPI spec - I took a look at the PCT, PSD, and PSS and what kind of information they are suppose to contain (which is pretty much just an structure of some data). There is also the _OSC method in ACPI which is to be executed by the ACPI AML, and by executing said method then the _PCT, _PSD, _PSS, etc are suppose to appear in the ACPI namespace. I also look at coreboot, since it has a bunch of AMLs and comments. Especially src/cpu/intel/haswell/acpi.c .. There is a ton of interesting stuff there: src/cpu/intel/turbo/turbo.c or src/northbridge/intel/sandybridge Anywho, back to the DSDT, which on my box shows: Scope (_PR) { OperationRegion (SSDT, SystemMemory, 0xBAE0AC18, 0x038C) OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084) Name (NCST, 0x02) Name (NPSS, 0x10) Name (HNDL, 0x80000000) Name (CHDL, 0x80000000) Name (TNLP, 0x0004) Name (CINT, Zero) Name (PDCV, 0xFFFFFFFF) Name (APSS, Package (0x10) { Package (0x06) { 0x0C1C, 0x0000FDE8, 0x000A, 0x000A, 0x1F00, 0x1F00 }, .. snip.. Method (OSC, 4, NotSerialized) { CreateDWordField (Arg3, Zero, STS) CreateDWordField (Arg3, 0x04, CAP) CreateDWordField (Arg0, Zero, IID0) CreateDWordField (Arg0, 0x04, IID1) CreateDWordField (Arg0, 0x08, IID2) CreateDWordField (Arg0, 0x0C, IID3) Name (UID0, Buffer (0x10) { /* 0000 */ 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29, 0xBE, 0x47, /* 0008 */ 0x9E, 0xBD, 0xD8, 0x70, 0x58, 0x71, 0x39, 0x53 }) CreateDWordField (UID0, Zero, EID0) CreateDWordField (UID0, 0x04, EID1) CreateDWordField (UID0, 0x08, EID2) CreateDWordField (UID0, 0x0C, EID3) If (LNot (LAnd (LAnd (LEqual (IID0, EID0), LEqual (IID1, EID1)), LAnd (LEqual (IID2, EID2), LEqual (IID3, EID3))))) { Store (0x06, Index (STS, Zero)) Return (Arg3) } And (PDCV, CAP, PDCV) If (LEqual (CINT, Zero)) { Store (One, CINT) If (LEqual (And (PDCV, 0x09), 0x09)) { If (LNotEqual (NPSS, Zero)) { Load (SSDT, HNDL) } } If (LEqual (And (PDCV, 0x10), 0x10)) { If (LNotEqual (NCST, 0xFF)) { Load (CSDT, CHDL) } } } Return (Arg3) } } Which looks to load an new SSDT or CSDT. Looking back at your DSDT - which BTW has tons of debug usage: Store ("Platform _OSC, APEI is implementend", Debug) should make it easier to narrow it down. You don't appear to have any Load method, so perhaps you have some SSDTs. If you look at those (there can be many), that might help. Again, you are looking at \_PR scope. On my box, I took the SSDT but it did not give any insight, except that the _PDC and _OSC end up calling in the \_PR.OSC method pasted above: Scope (\_PR) { Processor (P000, 0x01, 0x00000410, 0x06) { .. snip.. Method (_OSC, 4, NotSerialized) { Return (\_PR.OSC) Arg0 Arg1 Arg2 Arg3 } } } It looks like the magic incantations are in: OperationRegion (CSDT, SystemMemory, 0xBAE0BE18, 0x0084) so physical address 0xBAE0BE18. The machine is offline so it will have to wait until I can get the contents of that physical address. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |