Page 10 of 15 FirstFirst ... 89101112 ... LastLast
Results 91 to 100 of 145

Thread: The Leading Cause Of The Recent Linux Kernel Power Problems

  1. #91
    Join Date
    Apr 2010
    Posts
    99

    Default

    Quote Originally Posted by Lennie View Post
    I say, let's start with CoreBoot, I'm more than willing to just buy AMD if that solves any problems:

    http://blogs.amd.com/work/2011/05/05...e-on-coreboot/
    Let's hope AMD will use Coreboot not only for its embedded solutions, but also for the desktop ones (the future Bulldozer line and beyond). And also that motherboard vendors follow example.

    Quote Originally Posted by phoronix View Post
    The good news though is that at least one major OEM is preparing to ship Coreboot on select products beginning late in Q3 (September) or in Q4 (October through December) of this calendar year. This is information I have received from a reliable source that's at Computex Taipei this week.
    *crosses fingers*

  2. #92

    Default

    Quote Originally Posted by deanjo View Post
    Good job isolating it down Michael, it goes a long way of refewting some claims that a regression doesn't exist.
    Nice dig at me personally, but all this "proves" is that Michael found code doing it's job.

    Calling this a "regression" rather than a method to work around a badly implemented BIOS is silly.

    This is not a "regression". You can claim that I'm wrong, but you can't prove it because I am not wrong. This problem impacts a very tiny subset of systems with a bad BIOS implementation that keeps ASPM control within the BIOS. If you read the patch it becomes clear that this behavior is by design meaning that it is A: not a regression and B: exactly what I implied when I said that it impacts a limited number of machines if any.

    Change the code such that we
    explicitly clear ASPM if the FADT indicates that ASPM isn't supported,
    and make sure we tidy up appropriately on device removal in order to deal
    with the hotplug case. If ASPM is disabled because the BIOS doesn't hand
    over control then we won't touch the registers.
    ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
    - http://git.kernel.org/?p=linux/kerne...ec550c13b8fe72

    Something of interest to all of your readers would be that this patch actually fixed problems with systems crashing when ASPM was enabled on systems where the BIOS registered that it wasn't available.

    The patch that Michael is calling a regression actually corrected those issues.

    Read about it here: https://bugzilla.redhat.com/show_bug.cgi?id=681017

    More here: http://lwn.net/Articles/449648/

    Even more here: http://lwn.net/SubscriberLink/449448/95c739f46051924f/

    Specifically -

    In the latter case, the system may simply lock up - a state with even worse latency characteristics combined with surprisingly bad power use. So this workaround may be welcomed by users who have seen their battery life decline significantly, but it is not a proper solution to the problem.
    This site has NO credibility, none .. zero.

  3. #93
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by fewt View Post
    Calling this a "regression" rather than a method to work around a badly implemented BIOS is silly.
    Well we went from power management to no powermanagement. That is a regression. But this isn't a Linux regression; it was simply called that because this issue was dubbed a Linux regression.

    This site has NO credibility, none .. zero.
    The propperly working patch actually does increase powerusage by 4-5%, as evident by eyewitness testimony here. Do you have hard evidence that this patch mostly increases enegry efficiency on faulty BIOSes?

  4. #94

    Default

    Quote Originally Posted by V!NCENT View Post
    Well we went from power management to no powermanagement. That is a regression. But this isn't a Linux regression; it was simply called that because this issue was dubbed a Linux regression.
    No you did not go from power management to no power management. Some hardware devices (PCIe) lost power management in some cases. It was dubbed a regression due to a fundamental lack of understanding of the issue.

    Quote Originally Posted by V!NCENT View Post
    The propperly working patch actually does increase powerusage by 4-5%, as evident by eyewitness testimony here. Do you have hard evidence that this patch mostly increases enegry efficiency on faulty BIOSes?
    There is plenty of evidence that it only impacted some systems, in past threads here, and elsewhere.

  5. #95
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,791

    Default

    How do I interpret this lspci output?

    Code:
    01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870] (prog-if 00 [VGA controller])
    ...
    LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
    	ClockPM- Surprise- LLActRep- BwNot-
    LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
    	ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-

  6. #96
    Join Date
    May 2011
    Posts
    353

    Default

    It is called a regression because they at first thought it was.

  7. #97
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,584

    Default

    Quote Originally Posted by fewt View Post
    There is plenty of evidence that it only impacted some systems, in past threads here, and elsewhere.
    Which is a long ways away from your claim that it didn't even exist based on your "expertise" and "thousands of users".

  8. #98
    Join Date
    Oct 2008
    Posts
    3,135

    Default

    Quote Originally Posted by fewt View Post
    It was dubbed a regression due to a fundamental lack of understanding of the issue.
    No, that's not true. You can have a planned regression, or an expected regression. It's still a regression, due to the fact that the new power behavior is worse than it used to be. Even if that fixes other bugs, it's fixes crashes while simultaneously regressing power usage.

  9. #99
    Join Date
    Dec 2009
    Posts
    110

    Default

    Always interesting to see a thread go from something interesting (which BIOS-devs sucks at their implementations) to something completely unnecessary (whoo, is-it-a-regression-or-not grammar-nazi style, whooo michael-sucks-because-I-really-has-nothing-better-to-say, troll-style ), effectively killing the thread.

    Please address your more nasty aggression/mental/inferiority-problems before posting.

    From my side, cudos to Michael for instead of just hunting dow one regression taking the time and automating the process.
    The only thing I am currently missing is a more automated test-platform for hardware to find what is working according to specs and definitions, something like the BIOS test Intel released earlier this year, but more automated and with the possibility to send it to a central DB for everyone to know how good/shitty products some vendors do. I actually think it would be easier to get hardware-vendors to sign their products with "passes <name-of-hw-check>-<version-of-said-test>" then sign them "works with linux", mostly if Intel and AMD pushes them to use that test to create less shitty BIOSes. Some BIOS-devs would like it too, I think, the possibility to test out features in a easy way before Windows supports said technology.

  10. #100
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    The entire motherboard chip design is hugely based on the BIOS. Why not just gather another 'standards body/consortium' (like they all like to do), totaly whipe all the crap from the tabel, start out with Coreboot in the 'just load this from here to there and execute and bye-bye'-mode and strip and patch the shit out of the lower kernel layers and... Simply be done with it.

    You would think that all these companies would do that anyway, to save some serious licensing and programming money, but appearantly they've something better to do, like putting F4tality1337-uberGamer on the box...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •