Announcement

Collapse
No announcement yet.

A Comment On The Linux 2.6.38 Power Regression

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • A Comment On The Linux 2.6.38 Power Regression

    Phoronix: A Comment On The Linux 2.6.38 Power Regression

    Jesse Barnes, the maintainer of the PCI subsystem for the Linux kernel and one of the developers who signed-off on the patch that I discovered is causing the major Linux 2.6.38 kernel power regression, has commented on the matter...

    http://www.phoronix.com/vr.php?view=OTYwNA

  • #2
    Jesse believes that Microsoft must have additional checks in place when determining whether Windows should handle Active-State Power Management or not.
    Quoting Bill Gates:
    One thing I find myself wondering about is whether we shouldn’t try and make the "ACPI" extensions somehow Windows specific.
    It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work.
    Maybe there is no way Io avoid this problem but it does bother me. Maybe we couid define the APIs so that they work well with NT and not the others even if they are open.
    Someone put this quote on a comment about this Phoronix finding on Slashdot.

    It's originally from this email sent by Bill Gates.

    Comment


    • #3
      Originally posted by DeiF View Post
      Quoting Bill Gates:

      Someone put this quote on a comment about this Phoronix finding on Slashdot.

      It's originally from this email sent by Bill Gates.
      Well...they did a good job

      Comment


      • #4
        I appreciate this story. but how do we know *if* we are affected? THAT should be a story. There were a few comments in the other story today about possible ways to check but no one knew for sure. This is important enough to be a story of it's own.

        Comment


        • #5
          Very disappointing to know that the problem was found BUT nothing will be done about it in the short (or even medium) term. <sarcasm>That will surely help linux get a good reputation.</sarcasm>

          Comment


          • #6
            Since this issue (setting ASPM bits and ignoring BIOS) didn't seem to cause many crashes/device failure before, can't we set by default and create a black list for devices that have faulty BIOS ASPM settings?

            Comment


            • #7
              Originally posted by devius View Post
              Very disappointing to know that the problem was found BUT nothing will be done about it in the short (or even medium) term. <sarcasm>That will surely help linux get a good reputation.</sarcasm>
              'Linux' doesn't have control over mobo vendors and can't force them to write proper ACPI tables. Microsoft's monopolistic practices are at fault for that.

              Comment


              • #8
                Originally posted by DanL View Post
                'Linux' doesn't have control over mobo vendors and can't force them to write proper ACPI tables. Microsoft's monopolistic practices are at fault for that.
                Not really, it is still the manufacturers fault. It is just that MS allows them to get away with it instead of having a proper implementation.

                Comment


                • #9
                  Originally posted by deanjo View Post
                  Not really, it is still the manufacturers fault. It is just that MS allows them to get away with it instead of having a proper implementation.
                  I agree, it IS the manufacturers' fault to some degree because they've allowed themselves to be bullied by Microsoft.

                  Comment


                  • #10
                    Originally posted by DanL View Post
                    I agree, it IS the manufacturers' fault to some degree because they've allowed themselves to be bullied by Microsoft.
                    It's not MS bullying them. A proper BIOS works in windows just as well.

                    Comment


                    • #11
                      If the BIOS is enabling ASPM on a port, despite claiming not to support it, should we consider keeping it enabled?

                      Comment


                      • #12
                        Originally posted by phoronix
                        Tomorrow is a look at the Catalyst vs. Radeon DRM/KMS power consumption in different power management modes.
                        Looking forward to this. Even with ASPM enabled, I think Catalyst is gonna slaughter the open source drivers here, unfortunately. Performance is getting more and more competitive, but power consumption isn't. I can feel the heat difference in my room between how much my big card (HD5970) puts out, when running Catalyst vs. the open source drivers. Even just using kwin and no other 3d apps, my card gets as hot as it does when playing a AAA DirectX 11 title on Windows.

                        Comment


                        • #13
                          Code:
                          Jun 27 19:01:51 smorg kernel: [    0.912182] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912293] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912322] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912336] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P6._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912350] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912367] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE1._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912380] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE3._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912393] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.NPE7._PRT]
                          Jun 27 19:01:51 smorg kernel: [    0.912409]  pci0000:00: Requesting ACPI _OSC control (0x1d)
                          Jun 27 19:01:51 smorg kernel: [    0.912435] Unable to assume _OSC PCIe control. Disabling ASPM
                          Jun 27 19:01:51 smorg kernel: [    0.918144] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 6 7 10 *11 12 14 15)
                          Jun 27 19:01:51 smorg kernel: [    0.918309] ACPI: PCI Interrupt Link [LNKB] (IRQs *5)
                          Jun 27 19:01:51 smorg kernel: [    0.918386] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 6 7 *10 11 12 14 15)
                          Jun 27 19:01:51 smorg kernel: [    0.918549] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 6 7 10 11 12 *14 15)
                          Jun 27 19:01:51 smorg kernel: [    0.919238] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 6 7 10 11 12 14 *15)
                          Jun 27 19:01:51 smorg kernel: [    0.919401] ACPI: PCI Interrupt Link [LNKF] (IRQs *3 4 6 7 10 11 12 14 15)
                          Jun 27 19:01:51 smorg kernel: [    0.919562] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 6 *7 10 11 12 14 15)
                          Jun 27 19:01:51 smorg kernel: [    0.919724] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 *4 6 7 10 11 12 14 15)
                          So is that doing the right thing or just guessing?

                          Comment


                          • #14
                            Originally posted by Smorg View Post
                            Code:
                            Jun 27 19:01:51 smorg kernel: [    0.912409]  pci0000:00: Requesting ACPI _OSC control (0x1d)
                            Jun 27 19:01:51 smorg kernel: [    0.912435] Unable to assume _OSC PCIe control. Disabling ASPM
                            So is that doing the right thing or just guessing?
                            It means that Linux is asking the BIOS to hand off the management of ASPM using _OSC (operating system capabilities) method; the BIOS returns a mask acknowledging the transition from platform to OS control and in this case it's actively refusing to transfer control. The problem is that there's no way of knowing whether the firmware is really managing ASPM or it's lying.

                            Comment


                            • #15
                              But how does Windows know when to enable ASPM? Do hardware manufacturers put that into their drivers?

                              Maybe we should make a whitelist of ASPM-compatible devices that will always be forced to use ASPM, even when the BIOS doesn't advertise it.
                              What about putting a script on internet that uploads ASPM data from computers with a proper BIOS (yes, they exist !)?
                              Then volunteers from all over the world can, without too much technical knowledge, send their ASPM data. And then it can be put into the kernel.
                              Last edited by AlbertP; 06-28-2011, 06:06 AM.

                              Comment

                              Working...
                              X