https://bugzilla.kernel.org/show_bug.cgi?id=33742 Thomas Renninger <trenn@xxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trenn@xxxxxxx Component|cpufreq |BIOS AssignedTo|cpufreq@xxxxxxxxxxxxxxx |acpi_bios@xxxxxxxxxxxxxxxxx | |org Product|Power Management |ACPI --- Comment #5 from Thomas Renninger <trenn@xxxxxxx> 2011-04-21 10:13:12 --- > and the problems that I am seeing date back from at least version 2.6.24, from > what I can remember. Most likely a BIOS, _PPC issue, yes it is: before: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit:2001000 after: /sys/devices/system/cpu/cpu0/cpufreq/bios_limit:800000 That means _PPC does not return 0 anymore and BIOS tells the OS to limit the frequency. This is an ACPI problem, cpufreq subsystem bevhaves fine (at least this was always the case with similar bug reports recently). -> Re-assign to ACPI component. > Please attach dmesg output including an AC unplug/replug cycle. Best boot with log_buf_len=16777216 before you do the unplug/replug cycle copy this into a file, make it executable and follow instructions: ============== #!/bin/bash echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer echo 0xF >/sys/module/acpi/parameters/debug_level echo 7 >/sys/module/cpufreq/parameters/debug logger "Before unplug" echo "It's time to unplug ..." sleep 5 logger "AC got unplugged" echo "It's time to re-plug" sleep 5 echo 0x0 >/sys/module/acpi/parameters/debug_layer echo 0 >/sys/module/cpufreq/parameters/debug ============== and then attach whole dmesg and also acpidump output. Hm, before you should check for a BIOS upgrade and whether you find related BIOS settings. --- Comment #6 from RogÃrio Brito <rbrito@xxxxxxxxxx> 2011-04-22 09:17:19 --- Hi, Rafael, Thomas. Thank you for your answers. Here comes my follow up. (In reply to comment #5) > That means _PPC does not return 0 anymore and BIOS tells the OS to limit the > frequency. This is an ACPI problem, cpufreq subsystem bevhaves fine (at least > this was always the case with similar bug reports recently). > -> Re-assign to ACPI component. OK, sorry for assigning that to the wrong component. It is not always obvious where to file some bugs. > > Please attach dmesg output including an AC unplug/replug cycle. > Best boot with log_buf_len=16777216 > before you do the unplug/replug cycle copy this into a file, make it executable > and follow instructions: > ============== > #!/bin/bash > > echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer > echo 0xF >/sys/module/acpi/parameters/debug_level > echo 7 >/sys/module/cpufreq/parameters/debug > logger "Before unplug" > echo "It's time to unplug ..." > sleep 5 > logger "AC got unplugged" > echo "It's time to re-plug" > sleep 5 > echo 0x0 >/sys/module/acpi/parameters/debug_layer > echo 0 >/sys/module/cpufreq/parameters/debug > ============== OK. I did all that. As the logs are very big, I am including them compressed here. Please let me know if that's not what you want. > Hm, before you should check for a BIOS upgrade and whether you find related > BIOS settings. Unfortunately, I first tried to find the most recent BIOS update from the manufacturer (it's dated from 2010, IIRC) and, then, after flashing and noticing that it wasn't working, I filed the bug. I don't quite expect any updated version of the BIOS from MSI. Would there be any way to circumvent the buggy BIOS? If not in a clean and generic way, perhaps passing the kernel any extra option? Thanks, RogÃrio Brito. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.-- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
