lkml.org 
[lkml]   [2009]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)
    From
    Date
    On Sat, 2009-08-29 at 21:40 +0200, Rafael J. Wysocki wrote:
    > On Saturday 29 August 2009, Maxim Levitsky wrote:
    > > On Sat, 2009-08-22 at 15:48 +0300, Maxim Levitsky wrote:
    > > > Hi,
    > > >
    > > > <joke>
    > > > This should be brought to a Microsoft antitrust case...
    > > > </joke>
    > > >
    > > >
    > > > Today many notebooks ship with a embedded infrared receiver.
    > > > In Vista there is new subsystem that decodes these signals.
    > > > (of course it works only with Microsoft Certificated Remotes (TM)...)
    > > >
    > > > The receiver is usually presented to system as a pnp device
    > > > (using acpi tables)
    > > >
    > > > It turns out that some bioses actually use the OSI, ACPI feature of the
    > > > operation system to detect if running inside Vista. If not they disable
    > > > the infrared receiver.
    > > >
    > > > Device (MIR)
    > > > {
    > > > Name (_HID, EisaId ("ENE0100"))
    > > > Method (_STA, 0, NotSerialized)
    > > > {
    > > > If (LAnd (MCIR, LEqual (OSYS, 0x07D6)))
    > > > {
    > > > Return (0x0F)
    > > > }
    > > > Else
    > > > {
    > > > Store (Zero, ^^LPCB.IOR2)
    > > > Return (Zero)
    > > > }
    > > > }
    > > >
    > > > .......
    > > >
    > >
    > > > Scope (_SB)
    > > > {
    > > > Method (_INI, 0, NotSerialized)
    > > > {
    > > ....
    > >
    > > > If (CondRefOf (_OSI, Local0))
    > > > {
    > > > If (_OSI ("Linux"))
    > > > {
    > > > Store (One, LINX)
    > > > Store (Zero, ECDY)
    > > > }
    > >
    > > ..........
    > > >
    > >
    > > > If (_OSI ("Windows 2006"))
    > > > {
    > > > Store (0x07D6, OSYS)
    > > > }
    > > .......
    > >
    > >
    > > I have finally managed to find root case of this problem.
    > >
    > > Indeed the _STA method of infrared receiver is called before the _INI of
    > > _SB.
    >
    > This is a bug IMO. Len, what do you think?
    >
    > > The problem lies in acpi_bus_init()
    > > /*
    > > * ACPI 2.0 requires the EC driver to be loaded and work before
    > > * the EC device is found in the namespace (i.e. before acpi_initialize_objects()
    > > * is called).
    > > *
    > > * This is accomplished by looking for the ECDT table, and getting
    > > * the EC parameters out of that.
    > > */
    > >
    > > status = acpi_ec_ecdt_probe();
    > > /* Ignore result. Not having an ECDT is not fatal. */
    > >
    > > status = acpi_initialize_objects(ACPI_FULL_INITIALIZATION);
    > > if (ACPI_FAILURE(status)) {
    > > printk(KERN_ERR PREFIX "Unable to initialize ACPI objects\n");
    > > goto error1;
    > > }
    > > .......
    > >
    > >
    > > on Mairo's system (just as well as on mine) there is no ECDT.
    > > Thus, acpi_ec_ecdt_probe() triggers a acpi namespace walk,
    > > which in turn triggers invocation on _STA (which is supposed to be
    > > harmless, but the <beep>, the bios developers produce doesn't seem to
    > > meet this criteria....).
    > >
    > > And this is done before running _INI methods, which are run just later,
    > > in acpi_initialize_objects.
    > >
    > > I suspect that many systems use _SB._INI to test the OS version, thus
    > > this behavior needs to be revised.
    > >
    > > The fact that this (as usual) works in windows suggest that it might be
    > > good to look up the ECDT table before acpi_initialize_objects, but if
    > > not found, look up the EC later.
    > >
    > > On my system, although I have tried to reproduce this bug, I couldn't,
    > > and I know now why: It just so happens that on my system CIR device is
    > > listed in acpi tables after the EC, but on Mairo's system EC is just
    > > first device.
    > >
    > > Maybe we can add a 'walk only' function, that walks the namespace, but
    > > doesn't touch the _STA, and use it to find the EC there?
    >
    > To my eyes, this problem is a result of a workaround in acpi_ec_ecdt_probe(),
    > that according to the comment in there "is needed only on some broken machines
    > which require early EC, but fail to provide ECDT".
    >
    > You probably wrote that in one of the previous messages, but is your machine an
    > ASUS one by chance?
    >
    > Len, really, the things done by acpi_ec_ecdt_probe() in case ECDT is not found
    > don't look good to me at all.
    >
    > Why do we run the workaround for everyone, not just for _the_ broken systems?
    >
    > Moreover, why is "ASUS" hardcoded into the function as a known bad vendor
    > rather than put into a table?

    No, Mairo's system is a compal laptop, and I know that it does't have a
    ECDT (as well as mine btw, today hardware is quite similar)

    On top of that, I have asked Mairo to put acpi_ec_ecdt_probe(); just
    below the acpi_initialize_objects, but he said his system didn't boot
    after this change.

    _SB._INI does some black SMI magic that might need a EC after all.

    For reference, I attach acpidump of his system, and dmesg with some acpi
    debugging enabled.

    Mairo, could you post output of dmidecode, so I know exactly the laptop
    model.


    Best regards,
    Maxim Levitsky

    >
    > Thanks,
    > Rafael
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    [unhandled content-type:application/x-gzip][unhandled content-type:application/x-gzip]
    \
     
     \ /
      Last update: 2009-08-29 22:23    [W:0.049 / U:31.268 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site