Dell OptiPlex 755 ACPI: DMI

Dell OptiPlex 755 ACPI: DMI

[Moritz Naumann]

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

ACPI: DMI System Vendor: Dell Inc.
ACPI: DMI Product Name: OptiPlex 755
ACPI: DMI Product Version:
ACPI: DMI Board Name: 0GM819
ACPI: DMI BIOS Vendor: Dell Inc.
ACPI: DMI BIOS Date: 01/30/2008

That's the latest BIOS version (Release A07) currently available for 
this system ( at http://ln-s.net/1X+3 or 
ftp://ftp.us.dell.com/bios/O755-A07.exe ).

$ cat /proc/version
Linux version 2.6.24-1-amd64 (Debian 2.6.24-4~snapshot.10470) 
(waldi@debian.org) (gcc version 4.1.3 20070718 (prerelease) (Debian 
4.1.2-14+1)) #1 SMP Mon Feb 11 02:24:55 UTC 2008

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1991 bytes --]

Re: Dell OptiPlex 755 ACPI: DMI

[Len Brown]

On Tuesday 12 February 2008 05:30, Moritz Naumann wrote:
> ACPI: DMI System Vendor: Dell Inc.
> ACPI: DMI Product Name: OptiPlex 755
> ACPI: DMI Product Version:
> ACPI: DMI Board Name: 0GM819
> ACPI: DMI BIOS Vendor: Dell Inc.
> ACPI: DMI BIOS Date: 01/30/2008
> 
> That's the latest BIOS version (Release A07) currently available for 
> this system ( at http://ln-s.net/1X+3 or 
> ftp://ftp.us.dell.com/bios/O755-A07.exe ).
> 
> $ cat /proc/version
> Linux version 2.6.24-1-amd64 (Debian 2.6.24-4~snapshot.10470) 
> (waldi@debian.org) (gcc version 4.1.3 20070718 (prerelease) (Debian 
> 4.1.2-14+1)) #1 SMP Mon Feb 11 02:24:55 UTC 2008

Please send me the output from acpidump.

thanks,
-Len

Re: Dell OptiPlex 755 ACPI: DMI

[Len Brown]

On Wednesday 13 February 2008 04:23, Moritz Naumann wrote:
> Len Brown schrieb:
> > Please send me the output from acpidump.
> 
> Please see the attached file.
> 
> Invocation was:
> # acpidump > acpidump_linux_`uname -r`.txt 2>&1
> 
> Note the "Wrong checksum for generic table!" message (which is why I 
> redirected stderr).

Linux appears to be a special case in this BIOS.
ISLI returns 1 for OSI(Linux), which causes GUSB to do nothing.
(otherwise GUSB appears to touch SMM).  GUSB is called at init time,
and also at wakup time.

Do you notice any difference in USB operation with acpi_osi=Linux?
How about after resume from suspend?

thanks,
-Len

       Method (ISLI, 0, NotSerialized)
        {
            If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Linux"))
                {
                    Return (One)
### hmmm, special case for Linux, every other OS returns Zero
                }
                Else
                {
                    Return (Zero)
                }
            }
            Else
            {
                Return (Zero)
            }
        }

    Method (GUSB, 0, NotSerialized)
    {
        If (ISLI ())
# only invocation of ISLI
        {
            Return (Zero)
# OSI(Linux) does nothing
        }
        Else
        {
            Return (SMI2 (0xBA))
# everybody else invokes SMM
        }
    }
...
    Method (SMI2, 1, NotSerialized)
    {
        Acquire (SMIM, 0xFFFF)
        Store (Arg0, SMIC)
        Store (MGIC, Local0)
        Store (SMIC, Local1)
        Store (SMID, Local0)
        ShiftLeft (Local0, 0x08, Local0)
        Add (Local1, Local0, Local0)
        Release (SMIM)
        Return (Local0)
    }
....
    Method (_WAK, 1, NotSerialized)
    {
        If (LEqual (Arg0, 0x04))
        {
# wakeup from hibernate

            GUSB ()
        }
        Else
        {
            If (LEqual (Arg0, 0x03))
            {
# wakeup from suspend
                If (And (0x20, CMRD (0x49)))
                {
                    GUSB ()
                }
            }
        }
...
    Scope (_SB.PCI0)
    {
        Device (USB0)
        {
            Name (_ADR, 0x001D0000)
            Name (_UID, 0x05)
            Name (_PRW, Package (0x02)
            {
                0x03,
                0x03
            })
            OperationRegion (UPC1, PCI_Config, 0xC1, One)
            Field (UPC1, ByteAcc, NoLock, Preserve)
            {
                LEGK,   8
            }

            Method (_INI, 0, NotSerialized)
            {
                If (HACK ()) {}
                Else
                {
                    Store (LEGK, Local0)
                    And (Local0, 0x60, Local0)
                    Or (Local0, 0x20, Local0)
                    Store (Local0, LEGK)
                }

                GUSB ()
            }

Re: Dell OptiPlex 755 ACPI: DMI

[Moritz Naumann]

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

Len Brown wrote:
> Linux appears to be a special case in this BIOS.
> ISLI returns 1 for OSI(Linux), which causes GUSB to do nothing.
> (otherwise GUSB appears to touch SMM).  GUSB is called at init time,
> and also at wakup time.

I will need to read up a little on these terms (ISLI, GUSB, SMM), as I 
know neither of them so far.

> Do you notice any difference in USB operation with acpi_osi=Linux?
> How about after resume from suspend?

I assume you are referring to suspend to disk? I don't use this on this 
system.

I don't know whether it is related, but on this kernel (recent Debian 
testing backport to stable)...

Linux version 2.6.22-3-amd64 (Debian 2.6.22-6~bpo40+1) 
(nobse@backports.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 
4.1.1-21)) #1 SMP Mon Nov 12 17:53:18 UTC 2007

...this got written to syslog when I switched on my monitor, a DELL 
2007WFPb, which contains a USB hub (yes this is silly) which is 
connected to a rear USB connector of the PC:

Feb 14 09:42:54 pcnau kernel: usb 7-5: new high speed USB device using 
ehci_hcd and address 5
Feb 14 09:42:54 pcnau kernel: usb 7-5: configuration #1 chosen from 1 choice
Feb 14 09:42:54 pcnau kernel: hub 7-5:1.0: USB hub found
Feb 14 09:42:54 pcnau kernel: hub 7-5:1.0: 4 ports detected
Feb 14 09:46:14 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:46:28 pcnau last message repeated 11 times
Feb 14 09:46:31 pcnau kernel: printk: 8 messages suppressed.
Feb 14 09:46:31 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:46:40 pcnau kernel: printk: 20 messages suppressed.
Feb 14 09:46:40 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:47:03 pcnau kernel: printk: 1 messages suppressed.
Feb 14 09:47:03 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:47:04 pcnau last message repeated 4 times
Feb 14 09:47:11 pcnau kernel: printk: 13 messages suppressed.
Feb 14 09:47:11 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:47:11 pcnau kernel: printk: 6 messages suppressed.
Feb 14 09:47:11 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:47:30 pcnau kernel: printk: 13 messages suppressed.
Feb 14 09:47:30 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:47:32 pcnau last message repeated 3 times
Feb 14 09:47:43 pcnau kernel: printk: 18 messages suppressed.
Feb 14 09:47:43 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:49:16 pcnau kernel: rtc: lost some interrupts at 2048Hz.
Feb 14 09:49:16 pcnau kernel: rtc: lost some interrupts at 2048Hz.

I can try the same thing with acpi_osi=Linux if it would help. I could 
also run a speed test for writing to USB flash disks with and without 
acpi_osi=Linux if this would be of help. Other than that, I don't know 
what exactly to look for (and I have not run in acpi_osi=Linux mode, 
yet). Can you recommend a specific test to run?

Moritz

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 1991 bytes --]

Re: Dell OptiPlex 755 ACPI: DMI

[Len Brown]

On Thursday 14 February 2008 04:59, Moritz Naumann wrote:
> Len Brown wrote:
> > Linux appears to be a special case in this BIOS.
> > ISLI returns 1 for OSI(Linux), which causes GUSB to do nothing.
> > (otherwise GUSB appears to touch SMM).  GUSB is called at init time,
> > and also at wakup time.
> 
> I will need to read up a little on these terms (ISLI, GUSB, SMM), as I 
> know neither of them so far.

ISLI and GUSB are arbitrary method names in the source code for
the ACPI BIOS -- they have no inherent meaning.  One can often guess
what the BIOS programmer meant though -- GUSB touches the USB device,
for example...

Unfortunately, the architectes of ACPI chose to limit identifiers
to 4 characters, so there is a limit at how expressive they can be...

SMM is System Management Mode.
This is a feature of x86 chips where BIOS code can transparently
run without the OS knowing it.  Basically, you enter this mode
via an SMI (System Management Interrupt) run your hidden BIOS code
and then return and the OS never knows it happened.

SMM is probably the most hated platform feature by OS people,
even worse than ACPI.  The reason is beause we can't debug it.

> > Do you notice any difference in USB operation with acpi_osi=Linux?
> > How about after resume from suspend?
> 
> I assume you are referring to suspend to disk? I don't use this on this 
> system.

either hibernate to disk or suspend to ram may be affected.

> I don't know whether it is related, but on this kernel (recent Debian 
> testing backport to stable)...
> 
> Linux version 2.6.22-3-amd64 (Debian 2.6.22-6~bpo40+1) 
> (nobse@backports.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 
> 4.1.1-21)) #1 SMP Mon Nov 12 17:53:18 UTC 2007
> 
> ...this got written to syslog when I switched on my monitor, a DELL 
> 2007WFPb, which contains a USB hub (yes this is silly) which is 
> connected to a rear USB connector of the PC:
> 
> Feb 14 09:42:54 pcnau kernel: usb 7-5: new high speed USB device using 
> ehci_hcd and address 5
> Feb 14 09:42:54 pcnau kernel: usb 7-5: configuration #1 chosen from 1 choice
> Feb 14 09:42:54 pcnau kernel: hub 7-5:1.0: USB hub found
> Feb 14 09:42:54 pcnau kernel: hub 7-5:1.0: 4 ports detected
> Feb 14 09:46:14 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:46:28 pcnau last message repeated 11 times
> Feb 14 09:46:31 pcnau kernel: printk: 8 messages suppressed.
> Feb 14 09:46:31 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:46:40 pcnau kernel: printk: 20 messages suppressed.
> Feb 14 09:46:40 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:47:03 pcnau kernel: printk: 1 messages suppressed.
> Feb 14 09:47:03 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:47:04 pcnau last message repeated 4 times
> Feb 14 09:47:11 pcnau kernel: printk: 13 messages suppressed.
> Feb 14 09:47:11 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:47:11 pcnau kernel: printk: 6 messages suppressed.
> Feb 14 09:47:11 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:47:30 pcnau kernel: printk: 13 messages suppressed.
> Feb 14 09:47:30 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:47:32 pcnau last message repeated 3 times
> Feb 14 09:47:43 pcnau kernel: printk: 18 messages suppressed.
> Feb 14 09:47:43 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:49:16 pcnau kernel: rtc: lost some interrupts at 2048Hz.
> Feb 14 09:49:16 pcnau kernel: rtc: lost some interrupts at 2048Hz.

curious.  I wonder why you're using the rtc in the first place.

> I can try the same thing with acpi_osi=Linux if it would help.

it would help if you notice a difference.
my guess is that it will not make a difference and this issue
is related to rtc and USB and not related to ACPI.

The possible exception might be SMM related to USB,
which is always really difficult to debug.

> I could  
> also run a speed test for writing to USB flash disks with and without 
> acpi_osi=Linux if this would be of help. Other than that, I don't know 
> what exactly to look for (and I have not run in acpi_osi=Linux mode, 
> yet). Can you recommend a specific test to run?

well, asside from trying suspend and hibernate, see if USB works
the same way in both modes.  yes, dumping data to a flash drive
sounds like a good test.

thanks,
-Len