← Back to team overview

kernel-packages team mailing list archive

[Bug 1249244] Re: hp xw4400 has a error in dmesg log

 

Launchpad has imported 15 comments from the remote bug at
https://bugzilla.novell.com/show_bug.cgi?id=516797.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2009-06-26T11:44:24+00:00 Trenn-s wrote:

When booting the machine you see this ACPI error message in syslog:
<4>ACPI Error (dsfield-0139): [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS
<4>ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff8800bef02fd0), AE_ALREADY_EXISTS
<4>ACPI: Marking method _OSC as Serialized because of AE_ALREADY_EXISTS error

The reason is the same (name) CreateDWordField (CAPD) is tried to be
created several times. While there is no negative side effect known yet,
this should be addressed as it could have sever side effects.

Scott: I try to figure out the correct ACPI code that should be added to
the BIOS, could you add someone from HP who can take care of and look at
this then, please.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/0

------------------------------------------------------------------------
On 2009-06-26T12:27:55+00:00 Trenn-s wrote:

Created attachment 300608
Broken ACPI function from DSDT

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/1

------------------------------------------------------------------------
On 2009-06-26T12:40:50+00:00 Trenn-s wrote:

Hi Bob, can you help finding the correct ASL code to suggest to HP,
please.

The problem is (with all occurrences of the multiple times created CAPD):
...
 While (Local0)
    {
        CreateDWordField (CAPB, Local1, CAPD)
        ...
              And (CAPD, 0x09, CAPD)
        ...
              Store (Zero, CAPD)
        ...
              If (And (CAPD, 0x08))
        ...

     }
...

I wonder how this should be converted into correct ASL code. There is AFAIK no way of undeclaring the CAPD object. It might work with using Index (CAPB, Local1) where CAPD is currently used. The offset should still be the same, not sure whether:
   Store(Zero, CAPD)
and
   Store(Zero, Index(CAPB, Local1)
would be the same or whether in the first case a whole DWord is zeroed.

But there might be a more elegant way of solving this.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/2

------------------------------------------------------------------------
On 2009-06-26T15:21:38+00:00 Trenn-s wrote:

Adjust product to 11.1 to make the bug public. This is the same code
base and should happen on both, probably still in mainline kernel.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/3

------------------------------------------------------------------------
On 2009-06-26T15:43:36+00:00 Robert Moore wrote:

A good way to create dynamic objects it to put them in a subroutine. I would
add a new method that is called from within the loop. The code below should
suffice.

However, I find this statement odd:

        Store (One, Local1)

This means that the input buffer is (DWORD) accessed at offsets 1, 5, 9, 13,
etc., instead of what I would expect: 0, 4, 8, 12, etc. It probably should be a
store of Zero to Local1.


    /*
     * Arg0 = CAPB buffer
     * Arg1 = byte index
     */
    Method (DCAP, 2)
    {
        CreateDWordField (Arg0, Zero, CAPF)
        CreateDWordField (Arg0, Arg1, CAPD)

        If (And (CAPF, 0x01))
        {
            If (LEqual (Arg1, 0x01))
            {
                And (CAPD, 0x09, CAPD)
            }
            Else
            {
                Store (Zero, CAPD)
            }
        }
        Else
        {
            If (LEqual (Arg1, 0x01))
            {
                If (And (CAPD, 0x08))
                {
/* 
                        Store (Zero, \_SB.PCI0.IOH1.PMGE)
                        Store (Zero, \_SB.PCI0.IOH3.PMGE)
                        Store (Zero, \_SB.PCI0.IOH7.PMGE)
                        Store (Zero, \_SB.PCI0.PCX1.PMCE)
                        Store (Zero, \_SB.PCI0.PCX6.PMCE)
                        Store (Zero, \_SB.PCI0.LPC.BPEN)
*/
                }
            }
        }
    }
    Method (_OSC, 4, NotSerialized)
    {
        Subtract (Arg2, 0x01, Local0)
        Name (CAPB, Buffer (Multiply (Arg2, 0x04)) {})
        Store (Arg3, CAPB)
        Store (One, Local1)

        While (Local0)
        {
            DCAP (CAPB, Local1)

            Decrement (Local0)
            Add (Local1, 0x04, Local1)
        }
        Return (CAPB)
    }

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/4

------------------------------------------------------------------------
On 2009-06-26T20:27:46+00:00 Trenn-s wrote:

Thanks Bob, your help is very much appreciated!

It's up to HP now to fix their BIOSes.
While I can't say what exactly breaks (I didn't test all PCI functionality, fortunately Linux ACPI error detection works rather well), a bug in this _OSC PCI method can have sever side effects for PCI devices.
I can say for sure that the code is wrong and not doing what the developer intended to do.
Also the error message in the syslog will make the customers "justifiable" (hope that translates) nervous.
AFAIK this machine ships with SUSE, but as this is an OS independent bug, chances are high that Windows is also affected.

BIOS is from 26.05.2009, I can grep the exact BIOS string if needed.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/5

------------------------------------------------------------------------
On 2009-06-26T21:50:51+00:00 John-brown3 wrote:

Thanks, Thomas and Bob.  Just to clarify since I'll be passing this
along to our BIOS folks . . . is the required fix described by Bob in
comment #4?  Are there any other details I need to provide to our BIOS
engineers so they will know what is needed?  My apologies for these
questions but I am NOT a BIOS engineer myself!

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/6

------------------------------------------------------------------------
On 2009-06-26T21:53:37+00:00 Robert Moore wrote:

Yes, it's a possible fix to avoid the AE_ALREADY_EXISTS exceptions.
There is also a possible problem with Store (One, Local1).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/7

------------------------------------------------------------------------
On 2009-10-09T14:06:18+00:00 Trenn-s wrote:

BIOS issue and OEM got informed, there is not much more we can do.
BIOS bug unrelated to Linux -> closing invalid.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/8

------------------------------------------------------------------------
On 2011-03-23T16:41:41+00:00 Sbahling wrote:

Hi Thomas, I am reopening this because we are still hitting this message
with many HP systems, and we need to clarify the impact.

According to HP it was believed that "Linux error messages in the
dmesg.log file were due to the kernel ACPI parser not liking the fact
that the name CAPD was being redefined inside a while loop.  (It is
basically being used as a local pointer variable.)  The code is believed
to do what is intended, but if there is evidence that the ACPI code in
the Linux kernel really isn't doing that, we need to know."

So we need to know if the error message is more of a warning, or is the
redefinition of CAPD in the loop actually failing?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/9

------------------------------------------------------------------------
On 2011-03-23T16:49:39+00:00 Robert Moore wrote:

(In reply to comment #9)
> So we need to know if the error message is more of a warning, or is the
> redefinition of CAPD in the loop actually failing?

It is a serious error and ACPICA will immediately abort the method. The
ACPI specification specifically disallows the "multiple creation" of the
same name within a method, and I should point out that Windows fails on
this also, and may even blue-screen.

>From ACPI 4.0a
18.5.130 While (Conditional Loop)
...
Note: Creation of a named object more than once in a given scope is not allowed. As such, unconditionally creating named objects within a While loop must be avoided. A fatal error will be generated on the second iteration of the loop, during the attempt to create the same named object a second time.

Bob

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/10

------------------------------------------------------------------------
On 2011-03-24T13:23:22+00:00 Sbahling wrote:

Thanks Robert for the explanation. HP is now tracking this as a bug to
be addressed. In the meantime we need to understand the effects on Linux
with existing systems in the field.

In this case the _OSC method is corrupt and unusable. Will Linux safely
continue to operate as if there is no _OSC method defined?

>From reading the ACPI spec, this means we loose some PCI power
management, hotplug, and AER features (indeed the AER driver fails to
initialize). So are we just talking about loss of features, or is there
potential for system failures?

I also noticed mention of _OSC being used by the OS to register support
for MSI, but MSI seems to be functioning on the systems.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/11

------------------------------------------------------------------------
On 2011-03-24T14:36:01+00:00 Trenn-s wrote:

This is more a question for Rafael:
If the PCI _OSC method fails, due to a BIOS/ASL bug, what failure could one expect?

I'd say PCI will try to set up sane defaults if _OSC is not found.

I could imagine a scenario where a machine has a sever defect which is triggered by use of MSI/AER/.. and it tells the OS via _PCI._OSC func to not use this feature. If _OSC evaluation fails, it may get used (or not) and run into issues...
But this is more a theoretical issue, when devices work, all should be fine.
Rafael may want to correct me if I am wrong.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/12

------------------------------------------------------------------------
On 2011-03-25T00:54:33+00:00 Rjw-t wrote:

Well, there are two types of _OSC bits, support bits and control bits.
The support bits, if set, mean that the kernel supports specific features
(eg. MSI, PCIe ASPM etc.), while the control bits, if set, mean that the
kernel wants to control specific features.

The support bits we pass to the BIOS depend on the kernel configuration and
are subject to quirks (eg. if the machine is quirked not to use MSI, we
won't pass the MSI support bit to the BIOS).  Generally, the BIOS does whatever
it wants with those bits and that's beyond our control.

The mask of control bits we pass to the kernel depends on the support bits
plus some configuration switches.  For those bits the rule is that if _OSC
evaluation fails, pretty much whatever the reason, we won't use features the
control of which has not been granted.

IOW, we only use the _OSC features (for PCI that basically means PCI Express
native hotplug, PME and AER, plus SHPC on some systems, very rare) the control
of which has been explicitly granted by the BIOS.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/13

------------------------------------------------------------------------
On 2011-04-18T08:18:55+00:00 Trenn-s wrote:

This is nothing to fix for us, the bug was intended to point HP to a BIOS issue.
-> Closing invalid.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/comments/14


** Changed in: linux (Suse)
       Status: Unknown => Invalid

** Changed in: linux (Suse)
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1249244

Title:
  hp xw4400 has a error in dmesg log

Status in linux package in Ubuntu:
  Expired
Status in linux package in Suse:
  Invalid

Bug description:
  When I watched in my pc(HP xw4400)'s dmesg log.
  I found one error. please check this
  It says like this:
  [    0.085062] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
  [    0.085069] ACPI BIOS Error (bug): \_SB_.PCI0._OSC: Excess arguments - ASL declared 5, ACPI requires 4 (20130517/nsarguments-189)
  [    0.085113] ACPI Error: [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS (20130517/dsfield-211)
  [    0.085119] ACPI Error: Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff8802240770a0), AE_ALREADY_EXISTS (20130517/psparse-536)
  [    0.085125] ACPI: Marking method _OSC as Serialized because of AE_ALREADY_EXISTS error
  [    0.085133] ACPI BIOS Error (bug): \_SB_.PCI0._OSC: Excess arguments - ASL declared 5, ACPI requires 4 (20130517/nsarguments-189)
  [    0.085176] ACPI Error: [CAPD] Namespace lookup failure, AE_ALREADY_EXISTS (20130517/dsfield-211)
  [    0.085180] ACPI Error: Method parse/execution failed [\_SB_.PCI0._OSC] (Node ffff8802240770a0), AE_ALREADY_EXISTS (20130517/psparse-536)
  [    0.085189] acpi PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM

  my version is ubuntu 13.10
  i will attach all dmesglog

  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: linux-image-3.11.0-13-lowlatency 3.11.0-13.5
  ProcVersionSignature: Ubuntu 3.11.0-13.5-lowlatency 3.11.6
  Uname: Linux 3.11.0-13-lowlatency x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.12.5-0ubuntu2.1
  Architecture: amd64
  Date: Fri Nov  8 17:46:33 2013
  InstallationDate: Installed on 2012-10-29 (374 days ago)
  InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
  MarkForUpload: True
  SourcePackage: linux-lowlatency
  UpgradeStatus: Upgraded to saucy on 2013-10-20 (18 days ago)
  ---
  ApportVersion: 2.14.1-0ubuntu3.6
  Architecture: amd64
  AudioDevicesInUse:
   USER        PID ACCESS COMMAND
   /dev/snd/controlC2:  kokawa2003   4751 F.... pulseaudio
   /dev/snd/controlC1:  kokawa2003   4751 F.... pulseaudio
   /dev/snd/controlC0:  kokawa2003   4751 F.... pulseaudio
  CurrentDesktop: LXDE
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=9e76ebf7-11d7-4223-ba74-4bdb847207be
  InstallationDate: Installed on 2014-01-10 (364 days ago)
  InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
  MachineType: Hewlett-Packard HP xw4400 Workstation
  NonfreeKernelModules: nvidia_uvm nvidia
  Package: linux (not installed)
  ProcFB: 0 VESA VGA
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-44-generic root=UUID=93736552-fac1-413f-bc0d-9b99c5b92e3d ro quiet splash profile video=uvesafb clocksource=hpet pcie_aspm=force acpi_osi=Linux acpi_serialize intel_rng.no_fwh_detect=1 TPM
  ProcVersionSignature: Ubuntu 3.13.0-44.73-generic 3.13.11-ckt12
  RelatedPackageVersions:
   linux-restricted-modules-3.13.0-44-generic N/A
   linux-backports-modules-3.13.0-44-generic  N/A
   linux-firmware                             1.127.11
  RfKill:
   8: phy8: Wireless LAN
    Soft blocked: no
    Hard blocked: no
  StagingDrivers: zram
  Tags:  trusty staging
  Uname: Linux 3.13.0-44-generic x86_64
  UpgradeStatus: Upgraded to trusty on 2014-05-04 (250 days ago)
  UserGroups: adm cdrom dip kvm libvirtd lpadmin plugdev sambashare sudo vboxusers
  _MarkForUpload: True
  dmi.bios.date: 10/28/2010
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: 786D7 v02.07
  dmi.board.name: 0A68h
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.asset.tag: JPA73600VD
  dmi.chassis.type: 6
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: dmi:bvnHewlett-Packard:bvr786D7v02.07:bd10/28/2010:svnHewlett-Packard:pnHPxw4400Workstation:pvr:rvnHewlett-Packard:rn0A68h:rvr:cvnHewlett-Packard:ct6:cvr:
  dmi.product.name: HP xw4400 Workstation
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/+subscriptions