Created attachment 54772 [details] Brief description of the hardware that I have here. Hi. As per Zhang Rui's request in comment #87 of bug #11717, I am filing this bug. Here is my original description: > BTW, after further use of this notebook, I have discovered many other > power-related quirks. For instance, if I (accidentally or not) disconnect the > power from the mains outlet, the notebook will get stuck with both CPU cores > at > the lowest frequency (in this case, 800MHz), despite me: > > * changing the governor (ondemand, performance, powersave etc.---you name it, > it won't put back the frequency to 2.0GHz); > * putting back the power won't do and I still only get 800MHz. > > A simple reboot cures this problem. The (still existent) Windows Vista > install > doesn't have this problem, for whatever reason. Some extra notes: I got this notebook in 2008-07, and the problems that I am seeing date back from at least version 2.6.24, from what I can remember. I am attaching some extra data about this notebook so that this bug report is self contained. If any further information is needed, please let me know. Thanks, Rogério Brito.
Created attachment 54782 [details] A dmesg log of a regular use of this machine. This is probably noisy, but it is from some real usage.
Created attachment 54792 [details] Before unplugging the AC adapter Here is the output that I get from grep . /sys/devices/system/cpu/cpu*/cpufreq/* after a fresh boot, and before I unplug the AC adapter from the notebook.
Created attachment 54802 [details] After unplugging and replugging the AC adapter Here is the output that I get from grep . /sys/devices/system/cpu/cpu*/cpufreq/* after I unplug the AC adapter and replug it back.
Please attach dmesg output including an AC unplug/replug cycle.
> 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.
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.
Created attachment 54972 [details] Output from acpidump Please, note that there was an error (warning?) message sent to stderr saying that there was a checksum mismatch in one of the sections. I included it in the file, but I don't know if you just wanted the "pristine" acpidump or not. I am trying to err on the side of excess here. Thanks.
Created attachment 54982 [details] Compressed dmesg from before unplugging the AC adapter
Created attachment 54992 [details] Compressed dmesg after replugging the AC adapter It seems that the interesting stuff happens at around 160s, especially at 163.75s or so, but you people surely know better than I do what are the crucial points. Thanks.
Hi, just a reminder, I am ready to test things here, and am willing to play the guinea pig role. :-) Thanks in advance, Rogério Brito.
Hi. I said this in bug 11717, but that's valid here as well: > Oh, BTW, I still have this Windows Vista partition here (which I want to get > rid of, since it is mostly useless to me, as I have not used DOS/Windows in > the last 17 years and I don't see any value in that, aside of > reverse-engineering it to make Linux work out of the box). > What all this means is that I am willing to install some > development/debugging tools under Windows so that I can provide dumps, logs, > etc. to get the Linux kernel to work even with quiky hardware (which is, > unfortuately, not unheard of). > Unfortunately, Intel's http://biosbits.org/ (which, among other things, > claims to be able to set the BIOS parameters to sane defaults before booting > a kernel) says that my Core 2 Duo system is "unknown", which means that we > have one fewer tool at our disposal. > Do you happen to have any contacts with (or are one of the) people from that > project? I am willing to run many experiments here to get things straight on > this system. > Please, note how many times I have used something like "I am willing to" in > the paragraphs above. I hope that his helps in fixing (or, at least, working around) this bug. Thanks, Rogério Brito.
Argh, the _PPC function is in a dynamically loaded SSDT which the older acpidump does not dump. Can you either compile and run the latest acpidump: ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump or copy away and attach the exported tables from here, please: /sys/firmware/acpi/tables/dynamic/* Do you use the original power adapter/battery? There were several reports already where this happens when: - some ThinkPads if running on AC with battery unplugged (confirmed by Lenovo that this is intended). - 60W instead of 90W AC adapter and similar... I'll leave for holidays for 3 weeks. You can workaround the issue with: processor.ignore_ppc=1 boot parameter. If I have some time again, I can have another look why the BIOS is requesting the limit, ping in 4 weeks or so if things get stuck. I reduce prio of this. Such _PPC/frequency limit issues mostly boil down to be a BIOS issue and the kernel typically behaves correctly.
Hi, Thomas. On Thu, Apr 28, 2011 at 05:58, Thomas Renninger wrote: > --- Comment #12 from Thomas Renninger <trenn@suse.de> 2011-04-28 08:57:58 > --- > Argh, the _PPC function is in a dynamically loaded SSDT which the older > acpidump does not dump. Can you either compile and run the latest acpidump: > ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump No problems. Sure I can compile from that. Anything that you wish. > copy away and attach the exported tables from here, please: > /sys/firmware/acpi/tables/dynamic/* I am attaching here a (small, 850 bytes) tarball with the tables. Does that mean that the compilation of acpidump above is unnecessary? > Do you use the original power adapter/battery? Everything here is original, stock, except the BIOS that was asked to be upgraded, of course. But this issue was seen since I first acquired this notebook. > There were several reports already where this happens when: > - some ThinkPads if running on AC with battery unplugged (confirmed by > Lenovo > that this is intended). > - 60W instead of 90W AC adapter > and similar... OK. The notebook here is a Itautec N8320 (actually, a rebranded MSI PR200). Let me just check the AC adapter specs... OK, I'm back. Here it says that it generates (output, direct current) 19V with 3.42A, which would make that 19*3.42 = 64.98 W, or, in market-speak, 65W, right? > I'll leave for holidays for 3 weeks. You can workaround the issue with: > processor.ignore_ppc=1 > boot parameter. OK. I can live with that in my boot loader, thank you. Are there any unintended side-effects? > If I have some time again, I can have another look why the BIOS > is requesting the limit, ping in 4 weeks or so if things get stuck. OK, no problems. > I reduce prio of this. Such _PPC/frequency limit issues mostly boil down to > be > a BIOS issue and the kernel typically behaves correctly. Thank you very much for the workaround. I'm not really sure if we should cripple the kernel just because we have some defective BIOS, unless that can be summarized to a blacklist entry. OTOH, since you are an expert on ACPI, perhaps the other bug (11717) would benefit from your knowledge, as I am seeing some really weird behaviour of this notebook. I even put a video on my homepage showing how it works: http://www.ime.usp.br/~rbrito/linux/itautec-n8320-sleep-problems.webm I will just test the kernel parameter and post back what I find, so that you can be informed. Thank you very much for the reply, Thomas. -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Created attachment 55782 [details] Tarball with the ACPI tables Here is the tarball with the requested ACPI tables. They apparently didn't come with my e-mail. I hope that everything is right now. Thanks.
Hi, Thomas and others. On Thu, Apr 28, 2011 at 06:57, <bugzilla-daemon@bugzilla.kernel.org> wrote: >> I'll leave for holidays for 3 weeks. You can workaround the issue with: >> processor.ignore_ppc=1 boot parameter. > > OK. I can live with that in my boot loader, thank you. Are there any > unintended side-effects? Just for the record, passing that option seems to work well so far and I am so happy that after almost 4 years this notebook is now not restricted to being operated as a desktop only. Thank you so very much so far, Rogério Brito.
Hi again. (In reply to comment #13) > OK. I can live with that in my boot loader, thank you. Are there any > unintended side-effects? (...) > I will just test the kernel parameter and post back what I find, so > that you can be informed. Just keeping up with my promise, I have tested this, and I think that it works perfectly well. Actually, perhaps not 100% well, but I have yet to see if that is the parameter or if that is some other instability here, since I observed the following: I booted with processor.ignore_ppc=1, unplugged the power, plugged the power and started compiling a new kernel. Then, I left the computer for some minutes. After I returned it was turned off. That may have been a fluke, though. I will try with one of the stable series kernels and give feedback. Thanks.
It's great that the kernel bugzilla is back. Can you please verify if the problem still exists in the latest upstream kernel?
bug closed as there is no response from the bug reporter. please feel free to reopen it if the problem still exists in the latest upstream kernel.
Hi. This problem still exists with kernel 3.10.0-031000rc1-generic, which I took from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10-rc1-saucy/ Please let me know if further data is needed and I will do my best to provide it. Thanks in advance, Rogério Brito.
Method (_PSR, 0, NotSerialized) { If (POWS) { Return (One) } Else { If (LLess (MDCH, 0x0B)) { Or (0x11, PTHR, PTHR) Notify (\_PR.P001, 0x80) Sleep (0x0A) Notify (\_PR.P002, 0x80) } Return (Zero) } } AFAICS, this is a BIOS problem to me. the PTHR is not set properly when AC is reconnected, and this results in Method (_PPC, 0, NotSerialized) { If (LEqual (And (\PTHR, 0x01), 0x01)) { Return (Subtract (SizeOf (SPSS), 0x01)) } Else { Return (0x00) } } the _PPC method returns an non-zero value that limits the cpu frequency. Bug closed as there is nothing from OS side. Rogério Brito, please use processor.ignore_ppc=1 to workaround this issue. BTW, surely I can modidy the DSDT table to fix the AML code, but this is not preferred as you need to rebuild your kernel every time when you want to use a new kernel released. :)