DMI Information

DMI Information

[Gerard Hynes]

ACPI: EC: Look up EC in DSDT
ACPI: BIOS _OSI(Linux) query honored via cmdline
ACPI: DMI System Vendor: Dell Inc.
ACPI: DMI Product Name: Precision M4300
ACPI: DMI Product Version:
ACPI: DMI Board Name: 0UY141
ACPI: DMI BIOS Vendor: Dell Inc.
ACPI: DMI BIOS Date: 01/14/2008
ACPI: Please send DMI info above to linux-acpi@vger.kernel.org

If you'd like a sanatized complete dump of /usr/sbin/dmidecode - let me know.

"There are two major products that come out of Berkeley: LSD and UNIX. We don't
believe this to be a coincidence."                         - Jeremy S. Anderson

+-------------------------------------+
| =[gh]=                              |                   \|/  ______  \|/
| Gerard Hynes                        |                   "@' / ,  . \ `@"
| ghynes AT nfld.com / member.fsf.org |                   /__| \____/ |__\
+-------------------------------------+                       \___U__/

Re: DMI Information - Dell Precision M4300

[Len Brown]

On Tuesday 12 February 2008 22:25, Gerard Hynes wrote:
> 
> ACPI: EC: Look up EC in DSDT
> ACPI: BIOS _OSI(Linux) query honored via cmdline
> ACPI: DMI System Vendor: Dell Inc.
> ACPI: DMI Product Name: Precision M4300
> ACPI: DMI Product Version:
> ACPI: DMI Board Name: 0UY141
> ACPI: DMI BIOS Vendor: Dell Inc.
> ACPI: DMI BIOS Date: 01/14/2008
> ACPI: Please send DMI info above to linux-acpi@vger.kernel.org

please send me the output from acpidump.

thanks,
-Len

Re: DMI Information - Dell Precision M4300

[Len Brown]

> > On Tuesday 12 February 2008 22:25, Gerard Hynes wrote:
> > >
> > > ACPI: EC: Look up EC in DSDT
> > > ACPI: BIOS _OSI(Linux) query honored via cmdline
> > > ACPI: DMI System Vendor: Dell Inc.
> > > ACPI: DMI Product Name: Precision M4300
> > > ACPI: DMI Product Version:
> > > ACPI: DMI Board Name: 0UY141
> > > ACPI: DMI BIOS Vendor: Dell Inc.
> > > ACPI: DMI BIOS Date: 01/14/2008
> > > ACPI: Please send DMI info above to linux-acpi@vger.kernel.org
> >

Thanks for the acpidump output.  My review of it is inconclusive.
Please let me know if acpi_osi=Linux makes anything work better
on this box.  Mostly it looks like it shouldn't make any difference,
but there appears to be an SMM hook in the dock code where it may have an effect.

thanks,
-Len

OSID() is used throughout, but OSI(Linux) will not break it because
the comparisons are usually >= x20 etc, and Linux is assigned x40.

The excpetion is GDCK._UID, which may have an effect


    Name (W98S, "Microsoft Windows")
    Name (NT5S, "Microsoft Windows NT")
    Name (WINM, "Microsoft WindowsME: Millennium Edition")
    Name (WXP, "Windows 2001")
    Name (WLG, "Windows 2006")
    Name (LNX, "Linux")

    Method (OSID, 0, NotSerialized)
    {
        If (LEqual (MIS3, 0x00))
        {
            Store (0x01, MIS3)
            If (CondRefOf (\_OSI, Local0))
            {
                If (\_OSI (WXP))
                {
                    Store (0x10, MIS3)
                }

                If (\_OSI (WLG))
                {
                    Store (0x20, MIS3)
                }

                If (\_OSI (LNX))
                {
                    Store (0x40, MIS3)
# OSI(Linux) comes here

                }
            }
            Else
            {
                If (STRE (\_OS, W98S))
                {
                    Store (0x02, MIS3)
                }

                If (STRE (\_OS, NT5S))
                {
                    Store (0x08, MIS3)
                }

                If (STRE (\_OS, WINM))
                {
                    Store (0x04, MIS3)
                }
            }
        }

        Return (MIS3)
    }
...
               Device (GDCK)
                {
                    Name (_HID, EisaId ("PNP0C15"))
                    Method (_STA, 0, NotSerialized)
                    {
                        If (And (MIS5, 0x01))
                        {
                            Store (SMI (0x87, 0x00), Local2)
                            If (Local2)
                            {
                                Notify (\_SB.PCI0.PCIE.GDCK, 0x00)
                                Return (0x00)
                            }
                        }

                        Store (SMI (0x87, 0x00), Local0)
                        If (Local0)
                        {
                            Return (0x0F)
                        }

                        Return (0x00)
                    }

                    Method (_UID, 0, NotSerialized)
                    {
                        SX10 ()
                        SX30 (0x05)
                        SX30 (OSID ())
# OSID() output is passed to SX30
                        SX11 ()
                        Store (SX42 (), Local0)
                        SX12 ()
                        Return (Local0)
                    }
...
    Method (SX30, 1, NotSerialized)
    {
        Store (SXX2, Local0)
        Increment (Local0)
        If (LLessEqual (Local0, SizeOf (SXX0)))
        {
            CreateByteField (SXX0, SXX2, SX20)
            Store (Arg0, SX20)
            Store (Local0, SXX2)
        }
    }

I have no idea what this method and all its reference are trying todo,
but they're in with some SMI related code, so OSI(Linux) may have
an effect on SMM.

Re: DMI Information - Dell Precision M4300

[Len Brown]

On Thursday 14 February 2008 00:34, Gerard Hynes wrote:
> on Wed, 13 Feb 2008, Len Brown wrote:
> 
> Thank you for the detailed analysis.  Interestingly enough - this M4300 is
> sitting in a Dell docking station right now.  :-)
> 
> Perhaps on the weekend - I can put it thru some docking/un-docking cycles
> and note the behaviour if anything wierd happens - I'll definately forward any
> obvious/repeatable interactions to you.
> 
> In the meantime ... this machine is one smoking Linux box, (wicked fast) and
> everything is working extremely well (knock on wood).

Dell will be glad to hear that!

I'm pleased to notice that the "Tech Specs" for the Dell Precision M4300 & M6300
mention Linux.  (though it isn't immediately obvious how to order one w/o Windows)

Dell tells me off-list that they put the _OSI(Linux) hook into the M4300 BIOS
starting at version A05 specifically to handle Linux console-mode video restore
by invoking the video BIOS.

(what BIOS version do you have? -- unfortunately I neglected do dump that
 in the DMI printout...)

So, assuming that BIOS is shipping and you have that one or later,
then if you boot to console mode (eg init 3) w/o acpi_osi=Linux and suspend/resume
you may get no backlight restore and your screen will be black.
Boot with acpi_osi=Linux and the screen should restore properly.

Of course, you might not really care about restoring the LCD
if you never suspend in text mode...

It looks like the M4300/M6300 use nvidia graphics.
If that is the case, you'll need the nvidia kernel or X driver to restore video
after resume if the video BIOS hook above is not invoked.

If the SKU has Intel graphics, then 2.6.25's i915 driver can restore video,
even in console mode without running the BIOS.

thanks,
-Len