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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1249244 Title: hp xw4400 has a error in dmesg log To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1249244/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
