E-17 no more ???

[Crow]

An interesting reading about the regression in kernel power management and a workaround, I thought someone may want to know:

http://desktoplinux.com/news/NS7241828987.html

[OMSkates]

An interesting reading about the regression in kernel power management and a workaround, I thought someone may want to know:

http://desktoplinux.com/news/NS7241828987.html

Where do I add extra boot parameters to my kernel?  I don't see a ~./boot.cfg file in /boot/grub

[djohnston]

You need to edit menu.lst.

su -
cd /boot/grub
cp menu.lst menu.lst.backup
leafpad menu.lst

Find the line beginning with "kernel". The line below is an example.

kernel (hd0,1)/boot/vmlinuz BOOT_IMAGE=linux root=LABEL=PCLOS quiet acpi=on resume=LABEL=SWAP splash=silent vga=792

Add pcie_aspm=force to the end of the line so that it reads:

kernel (hd0,1)/boot/vmlinuz BOOT_IMAGE=linux root=LABEL=PCLOS quiet acpi=on resume=LABEL=SWAP splash=silent vga=792 pcie_aspm=force

Save the file and reboot.

[OMSkates]

Thanks dj, good reminder to backup the menu.lst first as well

My first line is:

Code: [Select]

title linux
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=a43943e4-c7d0-4034-b1d4-50294927ac1a quiet nokmsboot acpi=on resume=UUID=fadb9697-d2cb-4ba7-8003-0ce57fa26856 splash=silent vga=791
initrd (hd0,0)/boot/initrd.img

Additional kernels added, for example my last line with latest kernel booting is

Code: [Select]

title 2.6.38.8-pclos1.bfs
kernel (hd0,0)/boot/vmlinuz-2.6.38.8-pclos1.bfs BOOT_IMAGE=2.6.38.8-pclos1.bfs root=UUID=a43943e4-c7d0-4034-b1d4-50294927ac1a quiet nokmsboot acpi=on resume=UUID=fadb9697-d2cb-4ba7-8003-0ce57fa26856 splash=silent vga=791
initrd (hd0,0)/boot/initrd-2.6.38.8-pclos1.bfs.imgWould I be adding my option to the end of that line or does the first line default to latest installed kernel?

[Linuxera]

You need to edit menu.lst.

su -
cd /boot/grub
cp menu.lst menu.lst.backup
leafpad menu.lst

Find the line beginning with "kernel". The line below is an example.

kernel (hd0,1)/boot/vmlinuz BOOT_IMAGE=linux root=LABEL=PCLOS quiet acpi=on resume=LABEL=SWAP splash=silent vga=792

Add pcie_aspm=force to the end of the line so that it reads:

kernel (hd0,1)/boot/vmlinuz BOOT_IMAGE=linux root=LABEL=PCLOS quiet acpi=on resume=LABEL=SWAP splash=silent vga=792 pcie_aspm=force

Save the file and reboot.

Nice find djohnston.     Would it hurt to add the line to each of the booting perameters?

[OMSkates]

Nice find djohnston.     Would it hurt to add the line to each of the booting perameters?

I was wondering the same

[djohnston]

Would I be adding my option to the end of that line or does the first line default to latest installed kernel?

Unless you have manually edited menu.lst, the default "title linux" boot menu section will always load the kernel which was last installed. Just to be sure of which kernel version vmlinuz points to, do a quick check in a terminal.

[darrel@Duron ~]$ ls -l /boot/vmlinuz
lrwxrwxrwx 1 root root 27 Jul 26 20:55 /boot/vmlinuz -> vmlinuz-2.6.38.8-pclos3.bfs
[darrel@Duron ~]$

Would it hurt to add the line to each of the booting perameters?

I should have said "Find the line(s) beginning with 'kernel' ". I should also have added that the pcie_aspm=force parameter should only be added to a kernel stanza that loads one of the kernels with the power management regression. If the kernel to be loaded has the power management regression, by all means, add the boot parameter.

[Just17]

An interesting reading about the regression in kernel power management and a workaround, I thought someone may want to know:

http://desktoplinux.com/news/NS7241828987.html

The problem stems from the fact that many BIOSes are oriented toward Windows power management, and are often flawed when it comes to communicating with Linux over power issues. As a result, ASPM is often being turned off even when the BIOS supports it on some devices.

Another one of those ....  Linux believing what it is told and acting accordingly.

Am I missing something or is this not really a kernel regression?

[djohnston]

Another one of those ....  Linux believing what it is told and acting accordingly.

Am I missing something or is this not really a kernel regression?

I called it a "regression" for lack of a better term. I don't believe it actually is one, either. The kernel listens to instructions from a buggy BIOS and executes those instructions. Therefore, the kernel is the culprit? Where is the manufacturers' API documentation? Like many Linux implementations, this was probably reverse engineered due to lack of specifications.

It's not the kernel that has the bug. It's the hardware.

[Linuxera]

Even if I added those lines to my install prior to rolling an ISO, it would not be installed from the ISO as the menu.lst is created during the install process (as far as I know it is).  So each person who has installed from an ISO with this type of kernel caused problem would have to go in and edit the menu.lst after install which really is defeating the advances made in 'ease of use'.  I will just keep making ISOs for laptops with the kernels known to function 'properly' until fixes in the kernel, or install procedure advances to help those with little CLI knowledge.

 

[djohnston]

Even if I added those lines to my install prior to rolling an ISO, it would not be installed from the ISO as the menu.lst is created during the install process (as far as I know it is).  So each person who has installed from an ISO with this type of kernel caused problem would have to go in and edit the menu.lst after install which really is defeating the advances made in 'ease of use'.

Yes, that's true. The extra kernel parameter is only needed for those who have the buggy BIOS. Wouldn't do a thing for my circa 2001 Compaq PC with ACPI version 1.0.

[Just17]

Another one of those ....  Linux believing what it is told and acting accordingly.

Am I missing something or is this not really a kernel regression?

I called it a "regression" for lack of a better term. I don't believe it actually is one, either. The kernel listens to instructions from a buggy BIOS and executes those instructions. Therefore, the kernel is the culprit? Where is the manufacturers' API documentation? Like many Linux implementations, this was probably reverse engineered due to lack of specifications.

It's not the kernel that has the bug. It's the hardware.

Thanks ....  that is as I understood it.