Home_greyopenFATE - openSUSE feature tracking > #312962
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Include acpi_osi=Linux pcie_aspm=force by default for Grub boot parameters

Feature state

openSUSE Distribution
Rejected Information


acpi_osi=Linux identifies the OS to the BIOS helping fix power and other issues.

pcie_aspm=force fixes power regression issue shown here; http://www.phoronix.com/scan.php?page=article&item=linux_2638_aspm&num=1


icons/user_comment.png B. F. wrote: (6 years ago)

As GHK answered by email on the mailinglist and you didn't report here the result :
would you like to kill 80% of working computers ? Just to save some type of Acer buggy bios.

I'm not for. please remove that feature.
or at least be kind enough to post the result of the discussion!

icons/user_comment.png J. N. wrote: (6 years ago)

Correct. Forcing these params is /wrong/ for the majority of computers out there. Besides, it appears as though a fix for this has just appeared in the last few days.

icons/user_comment.png J. M. wrote: (6 years ago)

Phoronix's articles lend the impression that the vast majority of boards reporting no support do actually support the feature, in contrast to the claim here to the contrary. They even have a list of several DOZEN motherboards that incorrectly report not supporting ASPM when they do. I don't know where the first commenter's idea this is simply an Acer problem comes from.

You are correct that patch(es) have just appeared that seem able to fix this. Hopefully, they'll be backported to OpenSUSE 12.1.

icons/user_comment.png T. E. wrote: (6 years ago)

The mailing list thread discussing it is here:

In short it's not a good idea, and Phoronix is not a reliable source of information compared to the kernel developers.

icons/user_comment.png J. M. wrote: (6 years ago)

To be fair, Phoronix was the one who found that the problem existed, and then found the source of the problem, not the kernel developers, through their testing of patch by patch to find the culprit and the first source of a workaround. The engineer from Red Hat is also the first person to introduce a potential patch to the problem, which otherwise went unaddressed through several kernel releases.
The mailing list also has unsupported assertions such as "Only works on some machines, not others, be careful, it can lock your machine up hard." which appear to be just a person's opinion, not a verifiable fact. Phoronix had tests on their benchmarking site openbenchmarking.org and compiled a list of dozens of motherboards that passed the tests successfully while still reporting that they did not support aspm. I beg to differ with you in that empirical facts are more reliable than assertions on a mailing list.
You can check here http://www.phoronix.com/scan.php?page=news_item&px=OTk4NQ to see a partial list of *152* motherboards that had at least two different submissions with a passing test result.

Given all this work Phoronix has put into studying this issue, it seems unfair to label them as being "unreliable" (for this issue, anyway).

icons/user_comment.png J. M. wrote: (6 years ago)

In addition, the sole proponent of this "you don't want to do it" approach is one person, Greg KH. He also states "Again, no, there is nothing the kernel can do, it is a broken BIOS you are dealing with, please push your vendor to provide an updated, fixed, one."
This shows that there simply wasn't an interest on the part of this kernel developer to fix the problem via the kernel. We know that it is virtually impossible to get motherboard makers to fix this issue (Gigabyte answered a query about this by writing back that they don't support Linux, and suggested "use Windows" as a solution!). We also know now that ONE DAY after Greg KH wrote this claim that it was impossible to do anything on the kernel end, Matthew Garrett did indeed do something on the kernel end in a scant 60 lines of code.

Phoronix and Matthew Garrett, both kernel outsiders, have led the way in identifying the issue, diagnosing the cause, AND implementing a solution. At this point, they have earned the status of being the authoritative sources of information on this issue.

icons/user_comment.png T. E. wrote: (6 years ago)

This kind of thing belongs in the release notes, please open a bug in the Opensuse bugzilla against the release notes.

Example: I found a regression in 12.1 where the developers of the radeon driver (default for all AMD/ATI graphics cards) had turned off HDMI sound output by default. The reason was bug reports of it completely breaking graphics on *some* hardware. All I could do was add a note to the release notes saying how to re-enable it with a kernel parameter.

So as much as it sucks it's the way it has to be - the distro has to boot up and work default on as wide an array of hardware as possible.

The best you can do is make sure it's documented somewhere prominent how to enable optimisations and disabled features, and wait for the fix. Luckily the kernel devs are quite good at whether they're employed by Redhat or someone else.

Last change: 17 months ago
Loading tags...
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint