The Leading Cause Of The Recent Linux Kernel Power Problems

[agd5f]

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.

[MaxToTheMax]

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

[89c51]

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

[V!NCENT]

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....

[Nobu]

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]

[Xake]

Coreboot is not a magic bullet.

It may not be a magic bullet, and is still a hell if you do not have the hardware specs, but it is a hell of a lot easier to fix yourself then a binary blob...

[ahlaht]

The ASPM-related messages from kernel can be very confusing, but there is an easy way to test if ASPM is active: Write something to /sys/module/pcie_aspm/parameters/policy

I get this on new kernels WITHOUT pcie_aspm=force:

$ sudo echo powersave > /sys/module/pcie_aspm/parameters/policy
bash: echo: write error: Operation not permitted

On older kernels (I tested 2.6.36) or with pcie_aspm=force the value can be changed.

[hircus]

The ASPM-related messages from kernel can be very confusing, but there is an easy way to test if ASPM is active: Write something to /sys/module/pcie_aspm/parameters/policy

That's a good way to find out before rebooting the system, thanks. In my Sony Vaio EB's /var/log/dmesg, ASPM only appear once -- and that's from an older kernel. But the policy file indeed cannot be modified. I'll try forcing it when I get home.

To the earlier poster with a Vaio -- which model? I'm guessing the top-line Z and S models might have a better BIOS than the ones in the budget lines.

[Nille]

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....

To Be Filled By O.E.M. sounds like ASRock.

[grotgrot]

My motherboard is an Intel DP55WG and the BIOS is written by Intel.

ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

Another possibility is that the kernel code that makes the above decision isn't quite right.