All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Pasi Kärkkäinen" <pasik@iki.fi>
Cc: David Vrabel <david.vrabel@citrix.com>, xen-devel@lists.xen.org
Subject: Re: Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error
Date: Sun, 17 Mar 2013 13:00:48 -0400	[thread overview]
Message-ID: <20130317170047.GA13486@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <20130315213227.GB8912@reaktio.net>

> > > 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.

  reply	other threads:[~2013-03-17 17:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21  9:24 Linux 3.4 dom0 kernel error loading xen-acpi-processor: Input/output error Pasi Kärkkäinen
2013-02-21 12:29 ` Konrad Rzeszutek Wilk
2013-02-21 12:42   ` Pasi Kärkkäinen
2013-02-25 17:03     ` Konrad Rzeszutek Wilk
2013-02-25 19:08       ` Pasi Kärkkäinen
2013-02-24 22:05   ` Pasi Kärkkäinen
2013-03-03 18:53     ` Pasi Kärkkäinen
2013-03-05 17:45       ` Konrad Rzeszutek Wilk
2013-03-06 20:41         ` Pasi Kärkkäinen
2013-03-06 21:01           ` Pasi Kärkkäinen
2013-03-06 21:21             ` Pasi Kärkkäinen
2013-03-07  0:29               ` Konrad Rzeszutek Wilk
2013-03-07  7:48                 ` Pasi Kärkkäinen
2013-03-08 20:24                   ` Konrad Rzeszutek Wilk
2013-03-08 22:18                     ` Pasi Kärkkäinen
2013-03-12 20:51                       ` Pasi Kärkkäinen
2013-03-15 15:05                         ` Konrad Rzeszutek Wilk
2013-03-15 15:19                           ` Pasi Kärkkäinen
2013-03-15 19:37                             ` Pasi Kärkkäinen
2013-03-15 21:15                               ` Konrad Rzeszutek Wilk
2013-03-15 21:32                                 ` Pasi Kärkkäinen
2013-03-17 17:00                                   ` Konrad Rzeszutek Wilk [this message]
2013-03-18 13:06                                     ` Konrad Rzeszutek Wilk
2013-03-18 17:02                                       ` Pasi Kärkkäinen
2013-03-18 20:20                                         ` Konrad Rzeszutek Wilk
2013-05-12 16:51                                           ` Pasi Kärkkäinen
2013-05-13 13:46                                             ` Konrad Rzeszutek Wilk
2013-05-13 15:03                                               ` Pasi Kärkkäinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130317170047.GA13486@konrad-lan.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=pasik@iki.fi \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.