Re: ACPI locks hardware devices when it doesn't detect vista

Re: ACPI locks hardware devices when it doesn't detect vista

[Rafael J. Wysocki]

On Saturday 22 August 2009, 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.

Oh well.

That should've been Cced to linux-acpi (now added).  I'm looking forward to
seeng a comment from Len. 

> On my system this it is still tolerable:
> 
>             Device (MIR)
>             {
>                 Name (_HID, EisaId ("ENE0100"))
>                 Method (_STA, 0, NotSerialized)
>                 {
>                     If (LGreaterEqual (OSYS, 0x07D6))
>                     {
>                         If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
>                         {
>                             Return (0x00)
>                         }
>                         Else
>                         {
>                             Return (0x0F)
>                         }
>                     }
>                     Else
>                     {
>                         Return (0x00)
>                     }
>                 }
> 
> But not so, on Mairo's system:
> 
>             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)
>                     }
>                 }
> 
> 	.......
> 
>     Method (_WAK, 1, NotSerialized)
>     {
>     .......
>         If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
>         {
>             Store (Zero, \_SB.PCI0.LPCB.IOR2)
>         }
> 
> 
> .....
> 
>     Scope (_SB)
>     {
>         Method (_INI, 0, NotSerialized)
>         {
>             If (DTSE)
>             {
>                 TRAP (0x47)
>             }
> 
>             Store (0x07D0, OSYS)
>             If (CondRefOf (_OSI, Local0))
>             {
>                 If (_OSI ("Linux"))
>                 {
>                     Store (One, LINX)
>                     Store (Zero, ECDY)
>                 }
> 
>                 If (_OSI ("Windows 2001"))
>                 {
>                     Store (0x07D1, OSYS)
>                 }
> 
>                 If (_OSI ("Windows 2001 SP1"))
>                 {
>                     Store (0x07D1, OSYS)
>                 }
> 
>                 If (_OSI ("Windows 2001 SP2"))
>                 {
>                     Store (0x07D2, OSYS)
>                 }
> 
>                 If (_OSI ("Windows 2006"))
>                 {
>                     Store (0x07D6, OSYS)
>                 }
> 
>                 If (LEqual (TPMV, One))
>                 {
>                     If (LLessEqual (OSYS, 0x07D2))
>                     {
>                         TRAP (0x49)
>                     }
>                 }
>             }
> 
>             If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
>             {
>                 TRAP (0x3D)
>             }
> 
>             TRAP (0x2B)
>         }
>     }
> 
> We have tried to boot the system with acpi_osi="Windows 2006", but it
> didn't help (kernel log confirmed that this parameter was set)
> 
> The only explanation I think of is ether his laptop is whitelisted on
> osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
> or that acpi_osi isn't yet in charge when _SB._INI is called.
> 
> 
> The kernel in question is quite recent kernel, (2.6.30.5 from debian
> unstable).
> 
> 
> The only way I managed to 'enable' this device is to 
> do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> 
> Or in other words undo the damage done by these ACPI commands.
> 
> Mairo, can you boot the system with acpi=off, and then poke the cir IO
> range (0x700-0x703) ?

Best,
Rafael

Re: ACPI locks hardware devices when it doesn't detect vista

[Maxim Levitsky]

On Sat, 2009-08-22 at 23:41 +0200, Rafael J. Wysocki wrote:
> On Saturday 22 August 2009, 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.

Just one note. At least I am now sure that OSI("Windows 2006") does
return true by default.

I have tried booting here with acpi_osi="!Windows 2006", and actually
the CIR PNP device disappeared. I guess that _STA that returns zero
causes that.

On his laptop, ENE0100 device doesn't disappear, but still someone
writes zero to LPCB.IOR2 (we checked and found out that it was zero)

Maybe its zero by default, but some 'magic' driver in windows sets it
up, but this is a PCI config register on LPC bridge, (0x88) and I am
almost sure that nobody except bios knows about it.

Windows IR driver doesn't touch it for sure.

So, it could be that _STA is once called before the _SB._INI ?


Best regards,
	Maxim Levitsky

> 
> Oh well.
> 
> That should've been Cced to linux-acpi (now added).  I'm looking forward to
> seeng a comment from Len. 
Sorry....
> 
> > On my system this it is still tolerable:
> > 
> >             Device (MIR)
> >             {
> >                 Name (_HID, EisaId ("ENE0100"))
> >                 Method (_STA, 0, NotSerialized)
> >                 {
> >                     If (LGreaterEqual (OSYS, 0x07D6))
> >                     {
> >                         If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
> >                         {
> >                             Return (0x00)
> >                         }
> >                         Else
> >                         {
> >                             Return (0x0F)
> >                         }
> >                     }
> >                     Else
> >                     {
> >                         Return (0x00)
> >                     }
> >                 }
> > 
> > But not so, on Mairo's system:
> > 
> >             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)
> >                     }
> >                 }
> > 
> > 	.......
> > 
> >     Method (_WAK, 1, NotSerialized)
> >     {
> >     .......
> >         If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
> >         {
> >             Store (Zero, \_SB.PCI0.LPCB.IOR2)
> >         }
> > 
> > 
> > .....
> > 
> >     Scope (_SB)
> >     {
> >         Method (_INI, 0, NotSerialized)
> >         {
> >             If (DTSE)
> >             {
> >                 TRAP (0x47)
> >             }
> > 
> >             Store (0x07D0, OSYS)
> >             If (CondRefOf (_OSI, Local0))
> >             {
> >                 If (_OSI ("Linux"))
> >                 {
> >                     Store (One, LINX)
> >                     Store (Zero, ECDY)
> >                 }
> > 
> >                 If (_OSI ("Windows 2001"))
> >                 {
> >                     Store (0x07D1, OSYS)
> >                 }
> > 
> >                 If (_OSI ("Windows 2001 SP1"))
> >                 {
> >                     Store (0x07D1, OSYS)
> >                 }
> > 
> >                 If (_OSI ("Windows 2001 SP2"))
> >                 {
> >                     Store (0x07D2, OSYS)
> >                 }
> > 
> >                 If (_OSI ("Windows 2006"))
> >                 {
> >                     Store (0x07D6, OSYS)
> >                 }
> > 
> >                 If (LEqual (TPMV, One))
> >                 {
> >                     If (LLessEqual (OSYS, 0x07D2))
> >                     {
> >                         TRAP (0x49)
> >                     }
> >                 }
> >             }
> > 
> >             If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
> >             {
> >                 TRAP (0x3D)
> >             }
> > 
> >             TRAP (0x2B)
> >         }
> >     }
> > 
> > We have tried to boot the system with acpi_osi="Windows 2006", but it
> > didn't help (kernel log confirmed that this parameter was set)
> > 
> > The only explanation I think of is ether his laptop is whitelisted on
> > osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
> > or that acpi_osi isn't yet in charge when _SB._INI is called.
> > 
> > 
> > The kernel in question is quite recent kernel, (2.6.30.5 from debian
> > unstable).
> > 
> > 
> > The only way I managed to 'enable' this device is to 
> > do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> > 
> > Or in other words undo the damage done by these ACPI commands.
> > 
> > Mairo, can you boot the system with acpi=off, and then poke the cir IO
> > range (0x700-0x703) ?
> 
> Best,
> 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

Re: ACPI locks hardware devices when it doesn't detect vista

[Maxim Levitsky]

On Sun, 2009-08-23 at 01:02 +0300, Maxim Levitsky wrote:
> On Sat, 2009-08-22 at 23:41 +0200, Rafael J. Wysocki wrote:
> > On Saturday 22 August 2009, 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.
> 
> Just one note. At least I am now sure that OSI("Windows 2006") does
> return true by default.
> 
> I have tried booting here with acpi_osi="!Windows 2006", and actually
> the CIR PNP device disappeared. I guess that _STA that returns zero
> causes that.
> 
> On his laptop, ENE0100 device doesn't disappear, but still someone
> writes zero to LPCB.IOR2 (we checked and found out that it was zero)
> 
> Maybe its zero by default, but some 'magic' driver in windows sets it
> up, but this is a PCI config register on LPC bridge, (0x88) and I am
> almost sure that nobody except bios knows about it.
> 
> Windows IR driver doesn't touch it for sure.
> 
> So, it could be that _STA is once called before the _SB._INI ?

We have just tested, and it turns out that on boot, the device is
unlocked. So it must ACPI

I have put a printk very early in kernel initialization, and it proved
that CIR io range is accessible, before acpi initialization.


Best regards,
	Maxim Levitsky



> Best regards,
> 	Maxim Levitsky
> 
> > 
> > Oh well.
> > 
> > That should've been Cced to linux-acpi (now added).  I'm looking forward to
> > seeng a comment from Len. 
> Sorry....
> > 
> > > On my system this it is still tolerable:
> > > 
> > >             Device (MIR)
> > >             {
> > >                 Name (_HID, EisaId ("ENE0100"))
> > >                 Method (_STA, 0, NotSerialized)
> > >                 {
> > >                     If (LGreaterEqual (OSYS, 0x07D6))
> > >                     {
> > >                         If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
> > >                         {
> > >                             Return (0x00)
> > >                         }
> > >                         Else
> > >                         {
> > >                             Return (0x0F)
> > >                         }
> > >                     }
> > >                     Else
> > >                     {
> > >                         Return (0x00)
> > >                     }
> > >                 }
> > > 
> > > But not so, on Mairo's system:
> > > 
> > >             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)
> > >                     }
> > >                 }
> > > 
> > > 	.......
> > > 
> > >     Method (_WAK, 1, NotSerialized)
> > >     {
> > >     .......
> > >         If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
> > >         {
> > >             Store (Zero, \_SB.PCI0.LPCB.IOR2)
> > >         }
> > > 
> > > 
> > > .....
> > > 
> > >     Scope (_SB)
> > >     {
> > >         Method (_INI, 0, NotSerialized)
> > >         {
> > >             If (DTSE)
> > >             {
> > >                 TRAP (0x47)
> > >             }
> > > 
> > >             Store (0x07D0, OSYS)
> > >             If (CondRefOf (_OSI, Local0))
> > >             {
> > >                 If (_OSI ("Linux"))
> > >                 {
> > >                     Store (One, LINX)
> > >                     Store (Zero, ECDY)
> > >                 }
> > > 
> > >                 If (_OSI ("Windows 2001"))
> > >                 {
> > >                     Store (0x07D1, OSYS)
> > >                 }
> > > 
> > >                 If (_OSI ("Windows 2001 SP1"))
> > >                 {
> > >                     Store (0x07D1, OSYS)
> > >                 }
> > > 
> > >                 If (_OSI ("Windows 2001 SP2"))
> > >                 {
> > >                     Store (0x07D2, OSYS)
> > >                 }
> > > 
> > >                 If (_OSI ("Windows 2006"))
> > >                 {
> > >                     Store (0x07D6, OSYS)
> > >                 }
> > > 
> > >                 If (LEqual (TPMV, One))
> > >                 {
> > >                     If (LLessEqual (OSYS, 0x07D2))
> > >                     {
> > >                         TRAP (0x49)
> > >                     }
> > >                 }
> > >             }
> > > 
> > >             If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
> > >             {
> > >                 TRAP (0x3D)
> > >             }
> > > 
> > >             TRAP (0x2B)
> > >         }
> > >     }
> > > 
> > > We have tried to boot the system with acpi_osi="Windows 2006", but it
> > > didn't help (kernel log confirmed that this parameter was set)
> > > 
> > > The only explanation I think of is ether his laptop is whitelisted on
> > > osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
> > > or that acpi_osi isn't yet in charge when _SB._INI is called.
> > > 
> > > 
> > > The kernel in question is quite recent kernel, (2.6.30.5 from debian
> > > unstable).
> > > 
> > > 
> > > The only way I managed to 'enable' this device is to 
> > > do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> > > 
> > > Or in other words undo the damage done by these ACPI commands.
> > > 
> > > Mairo, can you boot the system with acpi=off, and then poke the cir IO
> > > range (0x700-0x703) ?
> > 
> > Best,
> > 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
> 

Re: ACPI locks hardware devices when it doesn't detect vista

[Maxim Levitsky]

On Sun, 2009-08-23 at 01:36 +0300, Maxim Levitsky wrote:
> On Sun, 2009-08-23 at 01:02 +0300, Maxim Levitsky wrote:
> > On Sat, 2009-08-22 at 23:41 +0200, Rafael J. Wysocki wrote:
> > > On Saturday 22 August 2009, 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.
> > 
> > Just one note. At least I am now sure that OSI("Windows 2006") does
> > return true by default.
> > 
> > I have tried booting here with acpi_osi="!Windows 2006", and actually
> > the CIR PNP device disappeared. I guess that _STA that returns zero
> > causes that.
> > 
> > On his laptop, ENE0100 device doesn't disappear, but still someone
> > writes zero to LPCB.IOR2 (we checked and found out that it was zero)
> > 
Just to make it clear:
on Mairo's laptop, booting without any special parameters, doesn't
remove the device from pnp list, but its I/O range is blocked.
Booting with acpi_osi="!Windows 2006" actually removes it from pnp list,
exactly, like on my system (I don't have completely confirmation of
that, but according to dmesg, my driver never gets loaded)


Best regards,
	Maxim Levitsky


> > Maybe its zero by default, but some 'magic' driver in windows sets it
> > up, but this is a PCI config register on LPC bridge, (0x88) and I am
> > almost sure that nobody except bios knows about it.
> > 
> > Windows IR driver doesn't touch it for sure.
> > 
> > So, it could be that _STA is once called before the _SB._INI ?
> 
> We have just tested, and it turns out that on boot, the device is
> unlocked. So it must ACPI
> 
> I have put a printk very early in kernel initialization, and it proved
> that CIR io range is accessible, before acpi initialization.
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
> 
> 
> > Best regards,
> > 	Maxim Levitsky
> > 
> > > 
> > > Oh well.
> > > 
> > > That should've been Cced to linux-acpi (now added).  I'm looking forward to
> > > seeng a comment from Len. 
> > Sorry....
> > > 
> > > > On my system this it is still tolerable:
> > > > 
> > > >             Device (MIR)
> > > >             {
> > > >                 Name (_HID, EisaId ("ENE0100"))
> > > >                 Method (_STA, 0, NotSerialized)
> > > >                 {
> > > >                     If (LGreaterEqual (OSYS, 0x07D6))
> > > >                     {
> > > >                         If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
> > > >                         {
> > > >                             Return (0x00)
> > > >                         }
> > > >                         Else
> > > >                         {
> > > >                             Return (0x0F)
> > > >                         }
> > > >                     }
> > > >                     Else
> > > >                     {
> > > >                         Return (0x00)
> > > >                     }
> > > >                 }
> > > > 
> > > > But not so, on Mairo's system:
> > > > 
> > > >             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)
> > > >                     }
> > > >                 }
> > > > 
> > > > 	.......
> > > > 
> > > >     Method (_WAK, 1, NotSerialized)
> > > >     {
> > > >     .......
> > > >         If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
> > > >         {
> > > >             Store (Zero, \_SB.PCI0.LPCB.IOR2)
> > > >         }
> > > > 
> > > > 
> > > > .....
> > > > 
> > > >     Scope (_SB)
> > > >     {
> > > >         Method (_INI, 0, NotSerialized)
> > > >         {
> > > >             If (DTSE)
> > > >             {
> > > >                 TRAP (0x47)
> > > >             }
> > > > 
> > > >             Store (0x07D0, OSYS)
> > > >             If (CondRefOf (_OSI, Local0))
> > > >             {
> > > >                 If (_OSI ("Linux"))
> > > >                 {
> > > >                     Store (One, LINX)
> > > >                     Store (Zero, ECDY)
> > > >                 }
> > > > 
> > > >                 If (_OSI ("Windows 2001"))
> > > >                 {
> > > >                     Store (0x07D1, OSYS)
> > > >                 }
> > > > 
> > > >                 If (_OSI ("Windows 2001 SP1"))
> > > >                 {
> > > >                     Store (0x07D1, OSYS)
> > > >                 }
> > > > 
> > > >                 If (_OSI ("Windows 2001 SP2"))
> > > >                 {
> > > >                     Store (0x07D2, OSYS)
> > > >                 }
> > > > 
> > > >                 If (_OSI ("Windows 2006"))
> > > >                 {
> > > >                     Store (0x07D6, OSYS)
> > > >                 }
> > > > 
> > > >                 If (LEqual (TPMV, One))
> > > >                 {
> > > >                     If (LLessEqual (OSYS, 0x07D2))
> > > >                     {
> > > >                         TRAP (0x49)
> > > >                     }
> > > >                 }
> > > >             }
> > > > 
> > > >             If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
> > > >             {
> > > >                 TRAP (0x3D)
> > > >             }
> > > > 
> > > >             TRAP (0x2B)
> > > >         }
> > > >     }
> > > > 
> > > > We have tried to boot the system with acpi_osi="Windows 2006", but it
> > > > didn't help (kernel log confirmed that this parameter was set)
> > > > 
> > > > The only explanation I think of is ether his laptop is whitelisted on
> > > > osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
> > > > or that acpi_osi isn't yet in charge when _SB._INI is called.
> > > > 
> > > > 
> > > > The kernel in question is quite recent kernel, (2.6.30.5 from debian
> > > > unstable).
> > > > 
> > > > 
> > > > The only way I managed to 'enable' this device is to 
> > > > do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> > > > 
> > > > Or in other words undo the damage done by these ACPI commands.
> > > > 
> > > > Mairo, can you boot the system with acpi=off, and then poke the cir IO
> > > > range (0x700-0x703) ?
> > > 
> > > Best,
> > > 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
> > 
> 

Re: ACPI locks hardware devices when it doesn't detect vista

[Maxim Levitsky]

On Sun, 2009-08-23 at 03:02 +0300, Maxim Levitsky wrote:
> On Sun, 2009-08-23 at 01:36 +0300, Maxim Levitsky wrote:
> > On Sun, 2009-08-23 at 01:02 +0300, Maxim Levitsky wrote:
> > > On Sat, 2009-08-22 at 23:41 +0200, Rafael J. Wysocki wrote:
> > > > On Saturday 22 August 2009, 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.
> > > 
> > > Just one note. At least I am now sure that OSI("Windows 2006") does
> > > return true by default.
> > > 
> > > I have tried booting here with acpi_osi="!Windows 2006", and actually
> > > the CIR PNP device disappeared. I guess that _STA that returns zero
> > > causes that.
> > > 
> > > On his laptop, ENE0100 device doesn't disappear, but still someone
> > > writes zero to LPCB.IOR2 (we checked and found out that it was zero)
> > > 
> Just to make it clear:
> on Mairo's laptop, booting without any special parameters, doesn't
> remove the device from pnp list, but its I/O range is blocked.
> Booting with acpi_osi="!Windows 2006" actually removes it from pnp list,
> exactly, like on my system (I don't have completely confirmation of
> that, but according to dmesg, my driver never gets loaded)
> 
> 
> Best regards,
> 	Maxim Levitsky
> 
> 
> > > Maybe its zero by default, but some 'magic' driver in windows sets it
> > > up, but this is a PCI config register on LPC bridge, (0x88) and I am
> > > almost sure that nobody except bios knows about it.
> > > 
> > > Windows IR driver doesn't touch it for sure.
> > > 
> > > So, it could be that _STA is once called before the _SB._INI ?
> > 
> > We have just tested, and it turns out that on boot, the device is
> > unlocked. So it must ACPI
> > 
> > I have put a printk very early in kernel initialization, and it proved
> > that CIR io range is accessible, before acpi initialization.
> > 
> > 
> > Best regards,
> > 	Maxim Levitsky
> > 
> > 
Any update on that?

I have tried to 'reproduce' same issue on my system by editing my acpi
tables, but couldn't
(I am sure that I did everything correctly, and to be even more sure, I
have inverted the test for windows vista in _STA, and IR device did
lock)


Mairo, could you somehow compile latest kernel  from git from

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

you just need to exectute 

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Then remove the setpci workaround, boot that kernel, and see if acpi still locks the IR device
OK?


Best regards,
	Maxim Levitsky


> > 
> > > Best regards,
> > > 	Maxim Levitsky
> > > 
> > > > 
> > > > Oh well.
> > > > 
> > > > That should've been Cced to linux-acpi (now added).  I'm looking forward to
> > > > seeng a comment from Len. 
> > > Sorry....
> > > > 
> > > > > On my system this it is still tolerable:
> > > > > 
> > > > >             Device (MIR)
> > > > >             {
> > > > >                 Name (_HID, EisaId ("ENE0100"))
> > > > >                 Method (_STA, 0, NotSerialized)
> > > > >                 {
> > > > >                     If (LGreaterEqual (OSYS, 0x07D6))
> > > > >                     {
> > > > >                         If (LOr (And (OTHR, 0x02), And (OTHR, 0x40)))
> > > > >                         {
> > > > >                             Return (0x00)
> > > > >                         }
> > > > >                         Else
> > > > >                         {
> > > > >                             Return (0x0F)
> > > > >                         }
> > > > >                     }
> > > > >                     Else
> > > > >                     {
> > > > >                         Return (0x00)
> > > > >                     }
> > > > >                 }
> > > > > 
> > > > > But not so, on Mairo's system:
> > > > > 
> > > > >             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)
> > > > >                     }
> > > > >                 }
> > > > > 
> > > > > 	.......
> > > > > 
> > > > >     Method (_WAK, 1, NotSerialized)
> > > > >     {
> > > > >     .......
> > > > >         If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
> > > > >         {
> > > > >             Store (Zero, \_SB.PCI0.LPCB.IOR2)
> > > > >         }
> > > > > 
> > > > > 
> > > > > .....
> > > > > 
> > > > >     Scope (_SB)
> > > > >     {
> > > > >         Method (_INI, 0, NotSerialized)
> > > > >         {
> > > > >             If (DTSE)
> > > > >             {
> > > > >                 TRAP (0x47)
> > > > >             }
> > > > > 
> > > > >             Store (0x07D0, OSYS)
> > > > >             If (CondRefOf (_OSI, Local0))
> > > > >             {
> > > > >                 If (_OSI ("Linux"))
> > > > >                 {
> > > > >                     Store (One, LINX)
> > > > >                     Store (Zero, ECDY)
> > > > >                 }
> > > > > 
> > > > >                 If (_OSI ("Windows 2001"))
> > > > >                 {
> > > > >                     Store (0x07D1, OSYS)
> > > > >                 }
> > > > > 
> > > > >                 If (_OSI ("Windows 2001 SP1"))
> > > > >                 {
> > > > >                     Store (0x07D1, OSYS)
> > > > >                 }
> > > > > 
> > > > >                 If (_OSI ("Windows 2001 SP2"))
> > > > >                 {
> > > > >                     Store (0x07D2, OSYS)
> > > > >                 }
> > > > > 
> > > > >                 If (_OSI ("Windows 2006"))
> > > > >                 {
> > > > >                     Store (0x07D6, OSYS)
> > > > >                 }
> > > > > 
> > > > >                 If (LEqual (TPMV, One))
> > > > >                 {
> > > > >                     If (LLessEqual (OSYS, 0x07D2))
> > > > >                     {
> > > > >                         TRAP (0x49)
> > > > >                     }
> > > > >                 }
> > > > >             }
> > > > > 
> > > > >             If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
> > > > >             {
> > > > >                 TRAP (0x3D)
> > > > >             }
> > > > > 
> > > > >             TRAP (0x2B)
> > > > >         }
> > > > >     }
> > > > > 
> > > > > We have tried to boot the system with acpi_osi="Windows 2006", but it
> > > > > didn't help (kernel log confirmed that this parameter was set)
> > > > > 
> > > > > The only explanation I think of is ether his laptop is whitelisted on
> > > > > osi=Linux, or that _SB._INI is called by linux _after_ MIR._STA
> > > > > or that acpi_osi isn't yet in charge when _SB._INI is called.
> > > > > 
> > > > > 
> > > > > The kernel in question is quite recent kernel, (2.6.30.5 from debian
> > > > > unstable).
> > > > > 
> > > > > 
> > > > > The only way I managed to 'enable' this device is to 
> > > > > do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> > > > > 
> > > > > Or in other words undo the damage done by these ACPI commands.
> > > > > 
> > > > > Mairo, can you boot the system with acpi=off, and then poke the cir IO
> > > > > range (0x700-0x703) ?
> > > > 
> > > > Best,
> > > > 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
> > > 
> > 
> 

Re: ACPI locks hardware devices when it doesn't detect vista

[Mario]

Maxim,

I've compiled the latest kernel from the git (2.6.31-rc7).
No changes still only the setpci hack works.


Monday 24 of August 2009 18:17:16 Maxim Levitsky wrote:
> On Sun, 2009-08-23 at 03:02 +0300, Maxim Levitsky wrote:
> > On Sun, 2009-08-23 at 01:36 +0300, Maxim Levitsky wrote:
> > > On Sun, 2009-08-23 at 01:02 +0300, Maxim Levitsky wrote:
> > > > On Sat, 2009-08-22 at 23:41 +0200, Rafael J. Wysocki wrote:
> > > > > On Saturday 22 August 2009, 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.
> > > >
> > > > Just one note. At least I am now sure that OSI("Windows 2006") does
> > > > return true by default.
> > > >
> > > > I have tried booting here with acpi_osi="!Windows 2006", and actually
> > > > the CIR PNP device disappeared. I guess that _STA that returns zero
> > > > causes that.
> > > >
> > > > On his laptop, ENE0100 device doesn't disappear, but still someone
> > > > writes zero to LPCB.IOR2 (we checked and found out that it was zero)
> >
> > Just to make it clear:
> > on Mairo's laptop, booting without any special parameters, doesn't
> > remove the device from pnp list, but its I/O range is blocked.
> > Booting with acpi_osi="!Windows 2006" actually removes it from pnp list,
> > exactly, like on my system (I don't have completely confirmation of
> > that, but according to dmesg, my driver never gets loaded)
> >
> >
> > Best regards,
> > 	Maxim Levitsky
> >
> > > > Maybe its zero by default, but some 'magic' driver in windows sets it
> > > > up, but this is a PCI config register on LPC bridge, (0x88) and I am
> > > > almost sure that nobody except bios knows about it.
> > > >
> > > > Windows IR driver doesn't touch it for sure.
> > > >
> > > > So, it could be that _STA is once called before the _SB._INI ?
> > >
> > > We have just tested, and it turns out that on boot, the device is
> > > unlocked. So it must ACPI
> > >
> > > I have put a printk very early in kernel initialization, and it proved
> > > that CIR io range is accessible, before acpi initialization.
> > >
> > >
> > > Best regards,
> > > 	Maxim Levitsky
>
> Any update on that?
>
> I have tried to 'reproduce' same issue on my system by editing my acpi
> tables, but couldn't
> (I am sure that I did everything correctly, and to be even more sure, I
> have inverted the test for windows vista in _STA, and IR device did
> lock)
>
>
> Mairo, could you somehow compile latest kernel  from git from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> you just need to exectute
>
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> Then remove the setpci workaround, boot that kernel, and see if acpi still
> locks the IR device OK?
>
>
> Best regards,
> 	Maxim Levitsky
>
> > > > Best regards,
> > > > 	Maxim Levitsky
> > > >
> > > > > Oh well.
> > > > >
> > > > > That should've been Cced to linux-acpi (now added).  I'm looking
> > > > > forward to seeng a comment from Len.
> > > >
> > > > Sorry....
> > > >
> > > > > > On my system this it is still tolerable:
> > > > > >
> > > > > >             Device (MIR)
> > > > > >             {
> > > > > >                 Name (_HID, EisaId ("ENE0100"))
> > > > > >                 Method (_STA, 0, NotSerialized)
> > > > > >                 {
> > > > > >                     If (LGreaterEqual (OSYS, 0x07D6))
> > > > > >                     {
> > > > > >                         If (LOr (And (OTHR, 0x02), And (OTHR,
> > > > > > 0x40))) {
> > > > > >                             Return (0x00)
> > > > > >                         }
> > > > > >                         Else
> > > > > >                         {
> > > > > >                             Return (0x0F)
> > > > > >                         }
> > > > > >                     }
> > > > > >                     Else
> > > > > >                     {
> > > > > >                         Return (0x00)
> > > > > >                     }
> > > > > >                 }
> > > > > >
> > > > > > But not so, on Mairo's system:
> > > > > >
> > > > > >             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)
> > > > > >                     }
> > > > > >                 }
> > > > > >
> > > > > > 	.......
> > > > > >
> > > > > >     Method (_WAK, 1, NotSerialized)
> > > > > >     {
> > > > > >     .......
> > > > > >         If (Not (LAnd (MCIR, LEqual (OSYS, 0x07D6))))
> > > > > >         {
> > > > > >             Store (Zero, \_SB.PCI0.LPCB.IOR2)
> > > > > >         }
> > > > > >
> > > > > >
> > > > > > .....
> > > > > >
> > > > > >     Scope (_SB)
> > > > > >     {
> > > > > >         Method (_INI, 0, NotSerialized)
> > > > > >         {
> > > > > >             If (DTSE)
> > > > > >             {
> > > > > >                 TRAP (0x47)
> > > > > >             }
> > > > > >
> > > > > >             Store (0x07D0, OSYS)
> > > > > >             If (CondRefOf (_OSI, Local0))
> > > > > >             {
> > > > > >                 If (_OSI ("Linux"))
> > > > > >                 {
> > > > > >                     Store (One, LINX)
> > > > > >                     Store (Zero, ECDY)
> > > > > >                 }
> > > > > >
> > > > > >                 If (_OSI ("Windows 2001"))
> > > > > >                 {
> > > > > >                     Store (0x07D1, OSYS)
> > > > > >                 }
> > > > > >
> > > > > >                 If (_OSI ("Windows 2001 SP1"))
> > > > > >                 {
> > > > > >                     Store (0x07D1, OSYS)
> > > > > >                 }
> > > > > >
> > > > > >                 If (_OSI ("Windows 2001 SP2"))
> > > > > >                 {
> > > > > >                     Store (0x07D2, OSYS)
> > > > > >                 }
> > > > > >
> > > > > >                 If (_OSI ("Windows 2006"))
> > > > > >                 {
> > > > > >                     Store (0x07D6, OSYS)
> > > > > >                 }
> > > > > >
> > > > > >                 If (LEqual (TPMV, One))
> > > > > >                 {
> > > > > >                     If (LLessEqual (OSYS, 0x07D2))
> > > > > >                     {
> > > > > >                         TRAP (0x49)
> > > > > >                     }
> > > > > >                 }
> > > > > >             }
> > > > > >
> > > > > >             If (LAnd (MPEN, LEqual (OSYS, 0x07D1)))
> > > > > >             {
> > > > > >                 TRAP (0x3D)
> > > > > >             }
> > > > > >
> > > > > >             TRAP (0x2B)
> > > > > >         }
> > > > > >     }
> > > > > >
> > > > > > We have tried to boot the system with acpi_osi="Windows 2006",
> > > > > > but it didn't help (kernel log confirmed that this parameter was
> > > > > > set)
> > > > > >
> > > > > > The only explanation I think of is ether his laptop is
> > > > > > whitelisted on osi=Linux, or that _SB._INI is called by linux
> > > > > > _after_ MIR._STA or that acpi_osi isn't yet in charge when
> > > > > > _SB._INI is called.
> > > > > >
> > > > > >
> > > > > > The kernel in question is quite recent kernel, (2.6.30.5 from
> > > > > > debian unstable).
> > > > > >
> > > > > >
> > > > > > The only way I managed to 'enable' this device is to
> > > > > > do 'sudo setpci -s 00:1f.0 0x88.W=0x701'
> > > > > >
> > > > > > Or in other words undo the damage done by these ACPI commands.
> > > > > >
> > > > > > Mairo, can you boot the system with acpi=off, and then poke the
> > > > > > cir IO range (0x700-0x703) ?
> > > > >
> > > > > Best,
> > > > > 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

Re: ACPI locks hardware devices when it doesn't detect vista

[Maxim Levitsky]

Oh, and cc linux-acpi....

On Sat, 2009-08-29 at 02:53 +0300, 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.
> 
> 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?
> 
> Looking for comments,
> 	Best regards,
> 		Maxim Levitsky
> 

Re: ACPI locks hardware devices when it doesn't detect vista

[Maxim Levitsky]

What do you think to do in this case:

On Sat, 2009-08-29 at 03:40 +0300, Maxim Levitsky wrote:
> Oh, and cc linux-acpi....
> 
> On Sat, 2009-08-29 at 02:53 +0300, 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.
> > 
> > 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?
> > 
> > Looking for comments,
> > 	Best regards,
> > 		Maxim Levitsky
> > 
> 

Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Rafael J. Wysocki]

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?

Thanks,
Rafael

Re: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Maxim Levitsky]

[-- Attachment #1: Type: text/plain, Size: 5412 bytes --]

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

[-- Attachment #2: dump.txt.gz --]
[-- Type: application/x-gzip, Size: 40599 bytes --]

[-- Attachment #3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 68633 bytes --]

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Mario]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

Exact model is Compal JFL92.
I've attached a dmidecode output.
Regards
Mario

Saturday 29 of August 2009 21:51:24 Maxim Levitsky wrote:
> dmidecode

>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

[-- Attachment #2: dmidecode_output --]
[-- Type: text/plain, Size: 6732 bytes --]

# dmidecode 2.9
SMBIOS 2.4 present.
24 structures occupying 1067 bytes.
Table at 0x000DC010.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: COMPAL          
	Version: 1.16
	Release Date: 12/31/2007
	Address: 0xE6010
	Runtime Size: 106480 bytes
	ROM Size: 1024 kB
	Characteristics:
		PCI is supported
		PNP is supported
		APM is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		ESCD support is available
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		5.25"/360 KB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 KB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
	BIOS Revision: 49.49
	Firmware Revision: 49.49

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: -
	Product Name: N/A                                            
	Version: N/A                             
	Serial Number: N/A                                                             
	UUID: 9CCC7D2C-134E-11DD-9C8D-001EEC42BF70
	Wake-up Type: Power Switch
	SKU Number: Compal
	Family: Compal

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
	Manufacturer: -
	Product Name: JFL92         
	Version: IFT00
	Serial Number: N/A                                                                       

Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
	Manufacturer: No Enclosure
	Type: Notebook
	Lock: Not Present
	Version: N/A
	Serial Number: None
	Asset Tag: -
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00001234

Handle 0x0004, DMI type 4, 35 bytes
Processor Information
	Socket Designation: U2E1
	Type: Central Processor
	Family: Other
	Manufacturer: Intel
	ID: 76 06 01 00 FF FB EB BF
	Version: CPU Version
	Voltage: 3.3 V
	External Clock: Unknown
	Max Speed: 4096 MHz
	Current Speed: 2500 MHz
	Status: Populated, Enabled
	Upgrade: ZIF Socket
	L1 Cache Handle: 0x0005
	L2 Cache Handle: 0x0006
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1 Cache
	Configuration: Enabled, Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 64 KB
	Maximum Size: 64 KB
	Supported SRAM Types:
		Burst
		Pipeline Burst
		Asynchronous
	Installed SRAM Type: Asynchronous
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2 Cache
	Configuration: Enabled, Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 6144 KB
	Maximum Size: 4096 KB
	Supported SRAM Types:
		Burst
		Pipeline Burst
		Asynchronous
	Installed SRAM Type: Burst
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1A1
	Internal Connector Type: None
	External Reference Designator: Keyboard
	External Connector Type: Circular DIN-8 male
	Port Type: Keyboard Port

Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1A1
	Internal Connector Type: None
	External Reference Designator: PS/2 Mouse
	External Connector Type: Circular DIN-8 male
	Port Type: Mouse Port

Handle 0x0009, DMI type 9, 13 bytes
System Slot Information
	Designation: PEG Slot J6C1
	Type: 32-bit PCI Express
	Current Usage: In Use
	Length: Long
	ID: 6
	Characteristics:
		5.0 V is provided
		3.3 V is provided

Handle 0x000A, DMI type 10, 6 bytes
On Board Device Information
	Type: Sound
	Status: Disabled
	Description: HD-Audio

Handle 0x000B, DMI type 11, 5 bytes
OEM Strings
	String 1: -

Handle 0x000C, DMI type 12, 5 bytes
System Configuration Options
	Option 1: None

Handle 0x000D, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 1000 MB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x000E, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x000D
	Error Information Handle: No Error
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: 1
	Locator: M1
	Bank Locator: Bank 0
	Type: DDR2
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: Mfg 0
	Serial Number: 1234-B0
	Asset Tag: Not Specified
	Part Number: SODIMM000

Handle 0x000F, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x000D
	Error Information Handle: No Error
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: 1
	Locator: M2
	Bank Locator: Bank 1
	Type: DDR2
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: Mfg 1
	Serial Number: 1234-B1
	Asset Tag: Not Specified
	Part Number: SODIMM001

Handle 0x0010, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Array Handle: 0x000D
	Partition Width: 0

Handle 0x0011, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x000E
	Memory Array Mapped Address Handle: 0x0010
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 2

Handle 0x0012, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00080000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x000F
	Memory Array Mapped Address Handle: 0x0010
	Partition Row Position: 1
	Interleave Position: 1
	Interleaved Data Depth: 2

Handle 0x0013, DMI type 32, 20 bytes
System Boot Information
	Status: <OUT OF SPEC>

Handle 0x0014, DMI type 131, 22 bytes
OEM-specific Type
	Header and Data:
		83 16 14 00 01 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 01
	Strings:
		TVT-Enablement

Handle 0x0015, DMI type 131, 22 bytes
OEM-specific Type
	Header and Data:
		83 16 15 00 01 00 00 00 00 00 00 00 00 00 00 00
		00 00 00 00 00 01
	Strings:
		TVT-Enablement

Handle 0x0016, DMI type 135, 10 bytes
OEM-specific Type
	Header and Data:
		87 0A 16 00 50 54 07 03 01 00

Handle 0x0017, DMI type 127, 4 bytes
End Of Table

Re: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Rafael J. Wysocki]

On Saturday 29 August 2009, Mario wrote:
> Exact model is Compal JFL92.
> I've attached a dmidecode output.

OK

Maxim, Mario, can you create a bug entry in the kernel Bugzilla for this
issue and put my address into the CC list in there?

Best,
Rafael

Re: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Maxim Levitsky]

On Sun, 2009-08-30 at 00:37 +0200, Rafael J. Wysocki wrote:
> On Saturday 29 August 2009, Mario wrote:
> > Exact model is Compal JFL92.
> > I've attached a dmidecode output.
> 
> OK
> 
> Maxim, Mario, can you create a bug entry in the kernel Bugzilla for this
> issue and put my address into the CC list in there?

Done,

http://bugzilla.kernel.org/show_bug.cgi?id=14086


Best regards,
	Maxim Levitsky

Re: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Mario]

Maxim, 

I did the test regarding last coment from Alexey Starikovskiy on the bugzilla.

>What happens if acpi_ec_ecdt_probe() is not called at all? Do you have same
>hang as with changed order?

That did it. System starts and MIR works ok without setpci solution.

Regards
Mario

Sunday 30 of August 2009 01:30:34 Maxim Levitsky wrote:
> On Sun, 2009-08-30 at 00:37 +0200, Rafael J. Wysocki wrote:
> > On Saturday 29 August 2009, Mario wrote:
> > > Exact model is Compal JFL92.
> > > I've attached a dmidecode output.
> >
> > OK
> >
> > Maxim, Mario, can you create a bug entry in the kernel Bugzilla for this
> > issue and put my address into the CC list in there?
>
> Done,
>
> http://bugzilla.kernel.org/show_bug.cgi?id=14086
>
>
> Best regards,
> 	Maxim Levitsky

Re: Is acpi_ec_ecdt_probe() broken? (was: Re: ACPI locks hardware devices when it doesn't detect vista)

[Rafael J. Wysocki]

On Sunday 30 August 2009, Mario wrote:
> Maxim, 
> 
> I did the test regarding last coment from Alexey Starikovskiy on the bugzilla.
> 
> >What happens if acpi_ec_ecdt_probe() is not called at all? Do you have same
> >hang as with changed order?
> 
> That did it. System starts and MIR works ok without setpci solution.

Could you please put that information into the Bugzilla entry at
http://bugzilla.kernel.org/show_bug.cgi?id=14086 (you'll need to create a
Bugzilla account for yourself for this purpose, sorry for the inconvenience)?

The ACPI people generally use the Bugzilla rather than e-mail for tracking
bugs.

Best,
Rafael