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@xxxxxxxxxxxxxxx
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
