RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Moore, Robert]

I agree with what Len has written.

Not only is the !Windows code path apparently untested for the most
part, we have discovered many machines that simply do not work properly
unless we report "Microsoft Windows NT" for the _OS string.  This is
another reason why we changed this string from "Linux"

Bob


> -----Original Message-----
> From: acpi-devel-admin@lists.sourceforge.net [mailto:acpi-devel-
> admin@lists.sourceforge.net] On Behalf Of Len Brown
> Sent: Monday, September 13, 2004 12:23 PM
> To: Alex Williamson
> Cc: linux-ia64@vger.kernel.org; ACPI Developers
> Subject: Re: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
> 
> On Mon, 2004-09-13 at 14:27, Alex Williamson wrote:
> >    A recent change to ACPI made the _OS object falsely report the OS
as
> > "Microsoft Windows NT".  This seems like a slippery slope, and I'd
> > rather not go down it for ia64.  I think all of the ia64 OEMs are
> > involved enough with Linux that this isn't necessary and the change
> > limits the options should ACPI firmware need to make an OS specific
work
> > around.  The patch below will make all ia64 boxes report a default
_OS
> > of "Linux".
> 
> While I share your pride in Linux, there are a couple of reasons
> why we do not make _OS return "Linux".
> 
> _OS is a deprecated interface -- it has been replaced
> by the more flexible _OSI.  So with _OS we're talking
> about past, not future systems.  And there is a total
> population of 0 systems in the installed base that check
> for _OS ="Linux" in their firmware.  On the other hand, there
> are zillions of systems that check for Windows with _OS,
> and the !Windows path through the firmware is effectivly
> unvalidated.
> 
> While this is really important on i386, it may not be
> important for ia64.  However, unless you can show
> me an existing system that checks for _OS=Linux, then
> it only adds risk w/o reward to make this change, even
> if just on ia64.  New systems should be using _OSI.
> 
> thanks,
> -Len
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement
on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

Re: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Alex Williamson]

On Mon, 2004-09-13 at 15:22 -0400, Len Brown wrote:
> On Mon, 2004-09-13 at 14:27, Alex Williamson wrote:
> >    A recent change to ACPI made the _OS object falsely report the OS as
> > "Microsoft Windows NT".  This seems like a slippery slope, and I'd
> > rather not go down it for ia64.  I think all of the ia64 OEMs are
> > involved enough with Linux that this isn't necessary and the change
> > limits the options should ACPI firmware need to make an OS specific work
> > around.  The patch below will make all ia64 boxes report a default _OS
> > of "Linux".
> 
> While I share your pride in Linux, there are a couple of reasons
> why we do not make _OS return "Linux".
> 
> _OS is a deprecated interface -- it has been replaced
> by the more flexible _OSI.  So with _OS we're talking
> about past, not future systems.  And there is a total
> population of 0 systems in the installed base that check
> for _OS ="Linux" in their firmware.  On the other hand, there
> are zillions of systems that check for Windows with _OS,
> and the !Windows path through the firmware is effectivly
> unvalidated.

  Perhaps true for i386.  While I don't know of any ia64 AML that checks
_OS, I do know that we extensively test any !Windows path that exists...
or at least we did.

> While this is really important on i386, it may not be
> important for ia64.  However, unless you can show
> me an existing system that checks for _OS=Linux, then
> it only adds risk w/o reward to make this change, even
> if just on ia64.  New systems should be using _OSI.

   I see the risk in *changing* the _OS, but not in leaving it the way
it was.  SLES9 has already shipped based on 2.6.5.  That ACPI CA set the
_OS to "Linux".  Many platforms have gone through full certification on
that kernel.  How is it more risky to stay with "Linux"?  If it's a
deprecated interface, why change it at the end of it's life when there
are no known benefits on ia64?  Thanks,

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab

RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Gerald Pfeifer]

On Mon, 13 Sep 2004, Moore, Robert wrote:
> Not only is the !Windows code path apparently untested for the most 
> part, we have discovered many machines that simply do not work properly 
> unless we report "Microsoft Windows NT" for the _OS string.

Can you name some of these (broken) systems?

Given that we apparently did not encounter this with our 2.6.5-based SLES9 
kernel so far, I'm a bit sceptical that many (if any) ia64 machines are 
affected.

Gerald

Re: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Nate Lawson]

Gerald Pfeifer wrote:
> On Mon, 13 Sep 2004, Moore, Robert wrote:
> 
>>Not only is the !Windows code path apparently untested for the most 
>>part, we have discovered many machines that simply do not work properly 
>>unless we report "Microsoft Windows NT" for the _OS string.
> 
> Can you name some of these (broken) systems?
> 
> Given that we apparently did not encounter this with our 2.6.5-based SLES9 
> kernel so far, I'm a bit sceptical that many (if any) ia64 machines are 
> affected.

The only ones I've seen have been i386.  One was a broken irq routing 
mechanism in the !windows case.  It's likely the case that there are no 
broken ia64 machines.  But it's also likely that no ia64 systems read 
\_OS so why should it matter what we put there?  I agree with Len, if 
you need to key off something OS-specific for Linux, use \_OSI.

-- 
Nate

RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Alex Williamson]

On Mon, 2004-09-13 at 15:59 -0700, Moore, Robert wrote:
> Here's an example:
> 

   But how can we be sure we're bug for bug and feature for feature
compatible with an arbitrary version of Windows?  I got curious and
looked at the DSDT on my home PC, generic VIA KM266 chipset.  Sure
enough:

    Name (OSFL, 0x00)
    Method (_INI, 0, NotSerialized)
    {
        \_SB.PCI0.IODT ()
        If (MCTH (\_OS, "Microsoft Windows NT"))
        {
            Store (0x00, OSFL)
        }
        Else
        {
            If (MCTH (\_OS, "Microsoft Windows"))
            {
                Store (0x01, OSFL)
            }
            Else
            {
                If (MCTH (\_OS, "Microsoft WindowsME: Millennium Edition"))
                {
                    Store (0x02, OSFL)
                }
                Else
                {
                    Store (0x03, OSFL)
                }
            }
        }
    }

Looking for consumers of OSFL...

        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_ADR, 0x00)
            Name (_BBN, 0x00)
            Method (_S3D, 0, NotSerialized)
            {
                If (OSFL)
                {
                    Return (0x02)
                }
                Else
                {
                    Return (0x03)
                }
            }

OK, maybe that's a good thing...  several more like that on USB devices.

        Device (SYSR)
        {
            Name (_HID, EisaId ("PNP0C02"))
            Method (_STA, 0, NotSerialized)
            {
                If (OSFL)
                {
                    Return (0x0F)
                }

                Return (0x00)
            }
             Name (IORG, ResourceTemplate ()
            {
                FixedIO (0x0010, 0x10)
                FixedIO (0x0022, 0x1E)
                FixedIO (0x0044, 0x1C)
                ...
            })
            Method (_CRS, 0, NotSerialized)
            {
                Return (IORG)
            }
        }

Hmm, it's not so obvious this one is a win.  There's another like that
for a PNP0C01 device listing Memory32Fixed ranges.  And another named
PIC providing an interrupt resource.  The motherboard driver could have
made use of these if they were marked as present, but they aren't for
"Microsoft Windows NT".

    Method (_PTS, 1, NotSerialized)
    {
        Store (Arg0, DBG8)
        If (LAnd (LEqual (Arg0, 0x04), LEqual (\_SB.PCI0.OSFL, 0x02)))
        {
            Sleep (0x0BB8)
        }
        ...
        If (LNot (\_SB.PCI0.OSFL))
        {
            Store (\_SB.PCI0.TLBC, PTB1)
        }
       ...
       Store (\_SB.PCI0.OSFL, \_SB.PCI0.W2FG)
       ...

Ok, we're doing some special stuff here, a stall for Windows ME, a store
for Windows NT, but how do we know those aren't bug workarounds specific
to that version?  There's a corresponding Windows NT check in the _WAK
method. 

   Of course these are all examples of i386 ACPI implementations.  If
there was an ia64 ACPI implementation that used _OS, who's to say that
"Microsoft Windows NT" wouldn't be the untested case.  I don't know what
Windows sets the _OS to for their ia64 releases.  "Microsoft Windows NT"
might be as arbitrary as setting it to "foo" there.

   I assume a blacklist was discussed when this was brought up earlier
on the list.  I'll have to go look why that didn't fly.  Thanks,

	Alex

RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Moore, Robert]

> 
>    But how can we be sure we're bug for bug and feature for feature
> compatible with an arbitrary version of Windows?  I got curious and
> looked at the DSDT on my home PC, generic VIA KM266 chipset.  Sure
> enough:

We aren't ever "sure".

All I can say is that MS is the "defacto" implementation and that we
attempt to both adhere to the ACPI spec and make some accommodations to
the MS implementation (such as supporting the control method "implicit
return")

The NT/XP MS implementation is their best version with the fewest bugs,
so this is the version that we are compatible with.

Given this, and the fact that most iA32 platform BIOSs are developed and
tested with XP, using the "Microsoft Windows NT" identification string
seems to be the best way to go.  By doing this, we have fixed at least
several machines (maybe more) that were not working properly under
Linux, and there haven't been any problems reported that I know of.

Bob

RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Moore, Robert]

A new example:

> -----Original Message-----
> From: Moore, Robert
> Sent: Friday, September 17, 2004 10:10 AM
> To: 'Andreas Leppert'; acpi-devel@lists.sourceforge.net
> Subject: RE: [ACPI] ACPI_OS_NAME: no battery or no ac_adapter
> 
> In newer versions of ACPI CA, we have changed ACPI_OS_NAME to "Microsoft
> Windows NT" for exactly this reason.
> 
> Bob
> 
> 
> > -----Original Message-----
> > From: acpi-devel-admin@lists.sourceforge.net [mailto:acpi-devel-
> > admin@lists.sourceforge.net] On Behalf Of Andreas Leppert
> > Sent: Friday, September 17, 2004 6:04 AM
> > To: acpi-devel@lists.sourceforge.net
> > Subject: [ACPI] ACPI_OS_NAME: no battery or no ac_adapter
> >
> > hi,
> >
> > i've a strange problem on my fujitsu laptop.  If i compile my kernel
> using
> > acpi, everything works fine, but acpi -V doesn't change the value of
> > ac_adapter info. it's always set to "on-line". it doesnt matter if the
> > ac_adapter is plugged in or not. always "on-line".
> >
> > then i found this:
> > http://sourceforge.net/mailarchive/message.php?msg_id=8560832
> >
> > so i changed the value of ACPI_OS_NAME in my
> > /usr/src/linux/include/acpi/platform/aclinux.h from "Linux" to
> "Microsoft
> > Windows NT". Now, ac_adapter changes its value from "on-line" to "off-
> > line" if i unplug the ac_adapter.
> >
> > But now, acpi -V doesnt show me any battery information. the line is
> just
> > omitted! so what to do?
> >
> > under http://andileppert.de/dsdtl.dsl you can find my dsdt. you will see
> > that there are a few _OS commands...  what can i do? this is a strange
> > thing...
> >
> > thanks in advance
> > Andi Leppert
> > _________________________________________________________
> > Mit WEB.DE FreePhone® mit höchster Qualität ab 0 Ct./Min.
> > weltweit telefonieren! http://freephone.web.de/?mc=021201
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> > _______________________________________________
> > Acpi-devel mailing list
> > Acpi-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/acpi-devel

> -----Original Message-----
> From: Moore, Robert
> Sent: Tuesday, September 14, 2004 8:00 AM
> To: 'Alex Williamson'
> Cc: Gerald Pfeifer; Brown, Len; linux-ia64@vger.kernel.org; ACPI
> Developers
> Subject: RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
> 
> 
> >
> >    But how can we be sure we're bug for bug and feature for feature
> > compatible with an arbitrary version of Windows?  I got curious and
> > looked at the DSDT on my home PC, generic VIA KM266 chipset.  Sure
> > enough:
> 
> We aren't ever "sure".
> 
> All I can say is that MS is the "defacto" implementation and that we
> attempt to both adhere to the ACPI spec and make some accommodations to
> the MS implementation (such as supporting the control method "implicit
> return")
> 
> The NT/XP MS implementation is their best version with the fewest bugs, so
> this is the version that we are compatible with.
> 
> Given this, and the fact that most iA32 platform BIOSs are developed and
> tested with XP, using the "Microsoft Windows NT" identification string
> seems to be the best way to go.  By doing this, we have fixed at least
> several machines (maybe more) that were not working properly under Linux,
> and there haven't been any problems reported that I know of.
> 
> Bob
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html