Announcement

Collapse
No announcement yet.

The Leading Cause Of The Recent Linux Kernel Power Problems

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

  • #31
    I really need to learn C... porting my Latitude E5400 with a really crappy BIOS (thanks Dell!) to coreboot must be easy, just a different Super I/O.

    Thanks Michael! I second what has been said about ads: flash ads are a big no-no

    Comment


    • #32
      I'm not having any problems on my laptop or desktop. I have an expensive Gigabyte motherboard and a Sony Vaio laptop with vt enabled.

      With computers, never ever settle for low price components, ever. This is what you get in return.

      Comment


      • #33
        As some people have seen, for some equipment setting pcie_aspm=force
        doesn't enable ASPM (I've a HP i5 laptop also). Message is:
        [ 0.000000] PCIe ASPM is forcedly enabled -> (Result of pcie_aspm=force)
        [ 0.809691] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
        -> (Result of crap ACPI tables. FADT for beeing more precise)

        Dumping and disassembling the ACPI tables, and looking into FACP, you can read:
        PCIe ASPM Not Supported (V4) : 1
        So the kernel, even when forcing aspm, is disabling it due to not support claimed by the ACPI tables.

        In my particular case, my laptop (HP with core i5) has been giving me a lot of problems due to bad ACPI tables related to hybrid graphics (DSDT table), and now the power draining pbroblems results from the same.

        The real origin for most of this problems are related to buggy/crappy ACPI tables made by manufacturers like HP and others. Two reasons arise here for doing that:

        First is that many manufacturers use Microsoft iasl compiler instead of Intel one, being the MS one more permissive and far less standard compliant than Intel one. Linux uses intel standards, so a problem is reached here. Use of Microsoft compiler gives more compliance with W7 than with ACPI standars, and so is favorable for this purpose. It's like the past problem with IE6 and mozilla with HTML standars, mozilla was close to the standard, but pages were mainly designed for IE.

        And second, that many manufactures have agreements with MS (Haven't you seen the W7 recommended logo?), so using MS compiler and enhancing the divergence with the standard, or directly giving bad options when no W7 OS could be part of their agreement, as it's easy to demonstrate for some HP laptops.

        Reaching this point, I think that the real step forward for Linux market share growth,
        is to have a very strict database of Linux-compliant hardware. Ubuntu has started to do this in: http://www.ubuntu.com/certification/
        and I'm sure that my next laptop will be from that list.

        The problem with this list is that it only contains ubuntu certified systems, and probably canonical has no so much equipment to test, so the list, right now, is small.
        At this point, an effort to develop a live iso cd/usb with a full set of tests that can ensure users that they are buying a Linux-compatible equipment would be very nice.
        This automated test should automatically report the results and feed a database of certified and not certified equipment for the iso version. This will allow users to chose ubuntu certified equipment (mainly enterprise grade), or test-suite certified equipment, avoiding to buy non-certified equipment, and thus avoiding
        a lot of bugs and developer efforts.

        If the iso test-suite is fully automated and works well, I could expect that many people like me, and even vendors will run it in their selling equipment, and so, It could reach a point (If MS lets that happens) that some manufacturers stop their policies of ACPI sabotage.

        Think twice, problems like this, hybrid, and other never would happen without the ACPI crap/buggy/sabotage tables by makers.

        Comment


        • #34
          Originally posted by esquio View Post
          So the kernel, even when forcing aspm, is disabling it due to not support claimed by the ACPI tables.
          Not true unless it's disabled somewhere else too: The functions "pcie_clear_aspm()" and "pcie_no_aspm()" do nothing if aspm is forced on.

          Comment


          • #35
            Originally posted by esquio View Post
            The real origin for most of this problems are related to buggy/crappy ACPI tables made by manufacturers like HP and others. Two reasons arise here for doing that:

            First is that many manufacturers use Microsoft iasl compiler instead of Intel one, being the MS one more permissive and far less standard compliant than Intel one. Linux uses intel standards, so a problem is reached here.
            The Linux kernel does not use the Intel ASL compiler - the compiler has nothing to do with the Linux implementation of the ACPI interpreter and core.

            The Linux ACPI maintainers have in fact moved to a policy over the last few years of being more compliant with Windows these days, than trying to stick to the 'spec', since the ACPI spec is just way too long and there is no defined compliance test as to whether your system is or isn't compliant - and frankly, that's as much Intel's fault as Microsoft's, as they were both involved in writing the ACPI spec, hence the current situation.

            Comment


            • #36
              As far as I got it now:

              If the kernel disables ASPM, it's a BIOS bug (on newer systems)?
              I got a Thinkpad 410. So I request Lenovo to fix that?

              Comment


              • #37
                Originally posted by esquio View Post
                At this point, an effort to develop a live iso cd/usb with a full set of tests that can ensure users that they are buying a Linux-compatible equipment would be very nice.
                This automated test should automatically report the results and feed a database of certified and not certified equipment for the iso version. This will allow users to chose ubuntu certified equipment (mainly enterprise grade), or test-suite certified equipment, avoiding to buy non-certified equipment, and thus avoiding
                a lot of bugs and developer efforts.

                If the iso test-suite is fully automated and works well, I could expect that many people like me, and even vendors will run it in their selling equipment, and so, It could reach a point (If MS lets that happens) that some manufacturers stop their policies of ACPI sabotage.
                You mean something like Linux Firmware Kit?

                Good luck persuading manufacturers to invest money in fixing their BIOSes for Linux. Expect the "Linux is not a supported OS" crap response.

                I have more faith in Coreboot (but not much more).
                *cross fingers for a high end desktop AMD motherboard with Coreboot*


                PS: I have Adblock disabled on phoronix, and also phoronix.com in the NoScript white list, but I don't see ads. I can see them from my phone though.

                Comment


                • #38
                  Originally posted by esquio View Post
                  Dumping and disassembling the ACPI tables, and looking into FACP, you can read:
                  PCIe ASPM Not Supported (V4) : 1
                  Does that mean that it doesn't work, doesn't work to the specs but works or just that it works but the flag is wrong?

                  First is that many manufacturers use Microsoft iasl compiler instead of Intel one, being the MS one more permissive and far less standard compliant than Intel one. Linux uses intel standards, so a problem is reached here. Use of Microsoft compiler gives more compliance with W7 than with ACPI standars, and so is favorable for this purpose.
                  Is there a way to do a bunch of tests with Windows on Qemu (or Virtualbox) to figure out what the hell Windows asks the BIOS to do? This could be put in a PDF and send to Linux developpers.

                  Think twice, problems like this, hybrid, and other never would happen without the ACPI crap/buggy/sabotage tables by makers.
                  But if ACPI has no standard test and everything is open for interpretation, then it is bascially crap. So it wouldn't be bad at all to copy Microsoft's ACPI interpretation as it is just as bad as Intel's ACPI implementation.

                  PS: But the real win would be if this legacy crap of a BIOS would be replaced by Coreboot. This should have happened the very day that operating systems for IBM PC's stopped doing firmware and started doing drivers. Hell the fact that this BIOS is still around for DOS is what's realy mindfscking me. Even the ATi Radeon 9800 pro had DOS compatible graphics circuitry. What the F-... why?!
                  Last edited by V!NCENT; 06-27-2011, 08:59 AM.

                  Comment


                  • #39
                    Originally posted by DeiF View Post
                    You mean something like Linux Firmware Kit?
                    I think that was exactly what he meant, but having something like that feeding a DB about the hardware, so potential buyers can look into that db to see if they will hit bugs like this. If people knew about this kind of bugs beforehand, then they would not buy it. And since every other site is more interested in "w000t, this shit is sooo l33t fast" more then "This shit actually work in every aspect" that kind of DB would be niced. Maybe even integrated into smolt?

                    Comment


                    • #40
                      http://smolt.fedoraproject.org/static/stats/stats.html

                      This site also tells a story...
                      "System Product Name", "System Name" and "To Be Filled By O.E.M. To Be Filled By O.E.M." are all the predefined values, and supposed to be filled in by the BIOS developers before shipping. If they cannot even fill this in....

                      Comment


                      • #41
                        Coreboot is not a magic bullet. While it is open source, there are still likely to be bugs in specific implementations if an oem was to use it. Getting rid of the bios is also not exactly a good option either. With no bios, you lack a standard way to boot the system and you end up with a mess like linux arm currently is (tons and tons of system-specific configurations that make booting a generic kernel almost impossible). Also, for things like ASPM, they have to be validated on the platform. If the OS doesn't support it (IIRC, XP did not), the different combinations of hw were not likely to be validated so they may not work in practice.

                        Comment


                        • #42
                          Terrific work, although the content-free first page was kind of milking it a bit.

                          Comment


                          • #43
                            Originally posted by agd5f View Post
                            Coreboot is not a magic bullet. While it is open source, there are still likely to be bugs in specific implementations if an oem was to use it. Getting rid of the bios is also not exactly a good option either. With no bios, you lack a standard way to boot the system and you end up with a mess like linux arm currently is (tons and tons of system-specific configurations that make booting a generic kernel almost impossible). Also, for things like ASPM, they have to be validated on the platform. If the OS doesn't support it (IIRC, XP did not), the different combinations of hw were not likely to be validated so they may not work in practice.
                            i feel that despite all the hate for bios efi uefi noone has proposed something that will lead to a solution. probably there cannot be a cure all but at least there must be something that satisfies most people

                            Comment


                            • #44
                              Originally posted by agd5f View Post
                              Coreboot is not a magic bullet. While it is open source, there are still likely to be bugs in specific implementations if an oem was to use it.
                              First of all Coreboot is mostly C. This greatly reduces problems due to readability. PS: It also reduces complexity by a 100-fold.

                              Getting rid of the bios is also not exactly a good option either. With no bios, you lack a standard way to boot the system and you end up with a mess like linux arm currently is (tons and tons of system-specific configurations that make booting a generic kernel almost impossible).
                              The standard way of booting is how a system should be booting and has always booted before the BIOS came around and that is loading a fscking piece of instructions to be performed. That's it. Instead the BIOS wants to be an OS and it should not be an OS.

                              Futhermore ARM is a piece of SOC crap that requires insanely rediculous configs with even basic circuitry bugs for which a rediculous erreta is always present. Needles to say that a x86 CPU is way easyer to boot. In fact, by getting rid of the BIOS, there is no need for stupid Philips audo cable connectors from the south bridge (to the RAM) to properly config the fscking RAM. John von Neumann would turn around in his grave if he were to hear this.

                              Also, for things like ASPM, they have to be validated on the platform. If the OS doesn't support it (IIRC, XP did not), the different combinations of hw were not likely to be validated so they may not work in practice.
                              So if Linux doesn't support hardware then the HW doesn't work? Yawn....
                              Last edited by V!NCENT; 06-27-2011, 10:38 AM.

                              Comment


                              • #45
                                Originally posted by Xake View Post
                                http://smolt.fedoraproject.org/static/stats/stats.html

                                This site also tells a story...
                                "System Product Name", "System Name" and "To Be Filled By O.E.M. To Be Filled By O.E.M." are all the predefined values, and supposed to be filled in by the BIOS developers before shipping. If they cannot even fill this in....
                                You think that's bad...there's one called "System Manufacturer", which I assume is supposed to be changed by the system manufacturer to a more appropriate name, which is second only to Dell.

                                [OFFTOPIC] HP laptops--at least, recent ones--aren't that great anyway, regardless of what OS you're running.

                                [/OFFTOPIC]

                                Comment

                                Working...
                                X