The Leading Cause Of The Recent Linux Kernel Power Problems

[Xake]

Every technology out there that Linux tries to support was mostly started by MS.

I think ARM-devs says otherwise.
Also, how come when linux kernel devs try to implement stuff they hit their head against upstreams that leave things as they are since their hardware/firmware "works in windows", and this because for example ASPM is not yet implemented in said platform at the time of manufacturing?

[Ceriousmall]

great work tracking down this bug Michael...now its time to see a fix going into the kernel and being back ported as well......................

[Michael]

now its time to see a fix going into the kernel and being back ported as well......................

As mentioned in the other post, due to what's happened, it's not something that will just be backported but you'll most likely be dependent upon new kernels going forward.

[djtm]

As a hotfix for 3.0 it would be possible to provide a boot parameter that has returns to the old behavior (-> ignores the bios flags and just uses aspm if possible). (*forcing* aspm on goes further, doesn't it?) I think my system didn't run well with aspm forced on, but it ran fine with 2.6.36.

[whitecat]

Every technology out there that Linux tries to support was mostly started by MS.

Every ? Not sure.
AMD64 ? GUID Partition Table ? USB3 ?

[deanjo]

Every ? Not sure.
AMD64 ? GUID Partition Table ? USB3 ?

MS had a HUGE role in getting AMD64 adopted as the 'defacto' standard 64 bit instruction set. At the time intel was promoting itanic. Had MS not given AMD64 the stamp of approval it is doubtful if AMD would have even survived. As far as USB3 goes, MS is part of the USB consortium.

[Xake]

MS had a HUGE role in getting AMD64 adopted as the 'defacto' standard 64 bit instruction set.

Yes, but it was still not _started_ by MS, they just helped getting it adopted since it would be more work for them to force people to run Microsofts software on itanic, and smoother for corporations to be able to switch to 64-bit OS when they are ready, not when the need new hardware.

[whitecat]

MS had a HUGE role in getting AMD64 adopted as the 'defacto' standard 64 bit instruction set. At the time intel was promoting itanic. Had MS not given AMD64 the stamp of approval it is doubtful if AMD would have even survived. As far as USB3 goes, MS is part of the USB consortium.

Yes MS is inside many consortium, but this doesn't mean that it perform good implementation.
MS is part of W3C Consortium since many years...

[yotambien]

Good job isolating it down Michael, it goes a long way of refewting some claims that a regression doesn't exist.

And yeah, great stuff done by Phoronix.

[Lennie]

Coreboot!:-D

The problem is that there are lots and lots of stadards, but hardware vedors ignores them as long as it "works with current windows". Guess why many MoBo-manufacturers has to update BIOSes when new versions of windows comes out? Because that version needs new things in the BIOS or because the old BIOS did not follow standards in some routines, which newer version of Windows did need to be done right?

Remember a blog-post from a Linux kernel dev that tried to get PM working on a PCI-E card, but never got it to wake up after he told the chips to go down into sleep mode. Did turn out IIRC that the chip in question did support that kind of PM, however the hardware manufacturer for the card did not wire the "wake up" pin to the bus, since "Windows did not support this kind of power management anyway"...

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/