Hello,
I'm sorry to bother, but I'm having the same exact suspend problem as liubenyuan on a ThinkPad X230 and, even after a long search, I couldn't find anything specific.Could someone please link me the aforementioned thread(s) or point me in the right direction?
Thanks!
It's strange I don't have that problem.But I am running "normal" kernel.Maybe something to do with TLP instead of Powerdown no?
]]>Could someone please link me the aforementioned thread(s) or point me in the right direction?
Thanks!
]]>This has been reported over and over and over again in these forums. Do a quick search and I'm sure you are bound to find something. I know it is at least covered in graysky's CK thread.
]]>Have you ever experienced a system lock up when you suspend-to-ram the X230?
I follow the x230 wikipage and using linux-ck kernel. Sometimes when I pressed the Fn + F4 (sleep) button, the power led and the sleep led keep on flashing (much faster than the normal sleep mode) and the system was unable to wake up. I had to shut down the x230 by holding the power buttons.
]]>I cannot speak for the X230 specifically, but I have a very similar machine, hardware wise. I have an E430, and it too has an i5 3210M, and I had an Intel 2230 wifi card which used iwlwifi. I belive this is the same card as mentioned in the post. There are iwlwifi bugs, and for some users they do screw with this particular card quite a bit (mine was fine), but in no way is the ck patchet the answer.
I think where you are most right is that it does not save power. The machine can be configured to save power, but it does not come from a partiularly patched kernel. After getting such a response about the review thing, I figured it wasn't worth trying to convince bassu that this information might be a bit misguided.
I think that you have shown in the post above that you have the knowledge on the matter to make changes to the wiki page that would both clarify and improve the content. So I encourage you to do so. In any case, it is a wiki, so it is not like the old content is gone, you can see each and every revision made.
]]>To get started, The first thing that catches my eye is that the page suggests users "run 'linux-ck' instead of the default kernel to conserve power" and to resolve some sort of wifi issue with sleep states*. Graysky's "linux-ck" kernel is pretty much the stock Arch kernel patched with -CK(BFS) and BFQ, there should be no reason it would resolve any sort of ACPI* or WiFi issues unless specifically patched to do so, which it isnt. The -CK patchset is currently more or less just BFS and shouldn't conserve power in any way, its not designed to. Although one way that a user could maybe conserve power is to tweak the scheduler to use a Tickless timer and lower its frequency (The recommended settings for a laptop are Tickless at 300Hz (this is also the Default ARCH setting) - BFS-Configuration-FAQ.txt ). Graysky's -CK kernel did use these settings but it has since been changed to 1000Hz* by default. It would also certainly be beneficial to use a governor (CPU Frequency Scaling/Throttling) to ensure the CPU is using less power while Idle.
(*) https://wiki.archlinux.org/index.php/Linux-ck
The tick rate has been increase from 300 Hz (Arch default) to 1k Hz to avoid interactions with the scheduler and the ability of the 3.9.x kernel to reboot and shutdown. For more on this evolving issue, see this entry in ck's blog and the Arch bug report linked therein.
The Brain Fuck Scheduler (BFS) is a CPU Scheduler written by Con Kolivas to improve system responsiveness over other CPU Schedulers like the stock Linux Scheduler CFS. In fact without going into superfluous detail, there was a time with the 2.6.xx kernels when it was a necessity over CFS for many users like myself. Lets see what Con has to say about it:
(Taken from ck.kolivas.org/patches/bfs/BFS-FAQ.txt)
What is it?BFS is the Brain Fuck Scheduler. It was designed to be forward looking only, make the most of lower spec machines, and not scale to massive hardware. ie it is a desktop orientated scheduler, with extremely low latencies for excellent interactivity by design rather than "calculated", with rigid fairness, nice priority distribution and extreme scalability within normal load levels.
Extreme scalability within normal load levels? Isn't that a contradiction?
For years we've been doing our workloads on linux to have more work than we had CPUs because we thought that the "jobservers" were limited in their ability to utilise the CPUs effectively (so we did make -j6 or more on a quad core machine for example). This scheduler proves that the jobservers weren't at fault at all, because make -j4 on a quad core machine with BFS is faster than *any* choice of job numbers on CFS. See reverse scalability graph courtesy of Serge Belyshev showing various job numbers on a kernel build on a quad core machine. The problem has always been that the mainline scheduler can't keep the CPUs busy enough; ie it doesn't make the most of your hardware in the most common situations on a desktop! Note that the reverse scalability graph is old; the scalability has improved since then.
Next I noticed in the "Power Saving" section; "The parameter elevator=bfq enables the Brain Fuck Scheduler written by Con Kolivas, part of Linux-ck and Linux-pf kernel forks.", and what immediately concerns me is that we are recommending that people use the -pf kernel without providing an explanation as to why, other than suggesting that the -pf and -ck kernels will somehow save on power consumption because they use BFS, which I've already shown isn't really the case. The wiki entry also makes no attempt to even link to any information regarding the other patches included in the -pf kernel or their effects on I/O, and possible performance gains or issues regarding SSDs and modern HDDs. Furthermore BFS is already enabled by default in Graysky's -ck kernel and requires no further configuration, I also suspect this is the case with the -pf kernel.
The Budget Fair Queueing (BFQ) scheduler is enabled by appending "elevator=bfq" to the kernel boot string and is in no way related to BFS, the -CK patchset, or Con Kolivas. BFQ is written by Paolo Valente, it is an I/O Scheduler designed to replace CFQ and increase Read/Write performance to disks. More information relating to BFQ can be found here at Paolo's website and here.
Lets see what Paolo has to say about BFQ:
(Taken from http://algo.ing.unimo.it/people/paolo/d … iption.php)
BFQ (Budget Fair Queueing) is a Proportional Share, or equivalently Fair Queueing, disk scheduler that allows each process/thread to be assigned a fraction of the disk throughput. It has the following characteristics.It distributes the disk throughput to disk-bound processes as desired, even if it fluctuates, independently of the disk parameters and with any workload. BFQ does not provide this sector-domain fairness to processes issuing random requests, as this would easily cause the disk throughput to drop on one hand, and other processes to experience very high latencies on the other hand. For these processes BFQ switches to a more appropriate time-domain fairness, in which it is the disk time to be fairly distributed (basically the same service scheme of CFQ).
BFQ guarantees to each disk request a tight delay with respect to the completion time that the request would enjoy in an ideal (unfeasible) perfectly-fair system. This is especially beneficial for soft real-time applications.
BFQ exports a low_latency tunable. If enabled (currently the default), BFQ executes a special heuristics that automatically gives to interactive and soft real-time applications more than their fair share of the disk throughput, to reduce their latency. According to our results, for desktop or handheld usage, the system becomes virtually as responsive as if the disk was idle, whatever the actual disk load is. Soft real-time applications enjoy up to 3-time lower latencies than under CFQ and do not suffer from almost any glitch even in presence of heavy background workloads.
Low-latency guarantees are preserved also in presence of NCQ.
Optimized (from v4) to achieve a high throughput on SSDs without losing low-latency guarantees.
According to our results, BFQ achieves up to 30% higher aggregate disk throughput than CFQ with most of the workloads considered, or the same throughput with the others.
Differently from CFQ, BFQ uses (from v6) a unified mechanism (Early Queue Merge, EQM) to get a sequential read pattern, and hence a high throughput, with any set of processes performing interleaved I/O. EQM also preserves low latency. More details here.
Lastly, under the "Suspension" section I see that you/bassu declare(s) "The only fix [for the iwlwifi driver bug] is to either enable PREEMPT & BFS with [a] custom compiled kernel or use an optimized kernel like Linux-ck as reported by forum user Bassu. Default kernels are not suitable for power-conservation anyway.", again with no explanation or information. As stated above, BFS should have nothing to do with this. I suspect using a preemptive kernel however, could resolve this issue by preventing the system from hanging on tasks taking a long time to finish (perhaps killing or re-initializing the wireless device) the while switching power states on multicore SMP cpus like bassu's Dual Core hyperthreaded i5-3210M. But honestly, if you're using an SMP CPU, especially if its multi-core, PREEMPT is in your best interest.
Finally, The reason I havn't corrected the wiki is due to my lack of experience with this particular machine and possible device specific bugs, fixes, and scenarios. My goal in this post was to attempt to resolve any confusion that you may be having with -CK/BFS (CPU Scheduling), BFQ (I/O Scheduling), and their effects (which are minimal or nonexistent) on power consumption. I sincerely hope I have clarified some things and assisted you or someone else in possibly improving the ThinkPad_X230 wiki page.
]]>guiniol wrote:skinnie wrote:vanilla 3.9.3 here.Zero problems.
Like I said before instead of Powerdown I am using TLP, and no suspension scripts.Vanilla as in compiled yourself? or the default arch one?
I'm using neither Powerdown nor TLP, and I don't have any suspension scripts.
I'm using gummiboot as a bootloader, maybe that's where the problem comes from.Default arch one.Maybe, I am using GRUB.
Apparently, there seems to be a problem with efistub.
I'm not the only one but it's kind of random, no one really knows why and what is happening...
skinnie wrote:vanilla 3.9.3 here.Zero problems.
Like I said before instead of Powerdown I am using TLP, and no suspension scripts.Vanilla as in compiled yourself? or the default arch one?
I'm using neither Powerdown nor TLP, and I don't have any suspension scripts.
I'm using gummiboot as a bootloader, maybe that's where the problem comes from.
Default arch one.Maybe, I am using GRUB.
]]>vanilla 3.9.3 here.Zero problems.
Like I said before instead of Powerdown I am using TLP, and no suspension scripts.
Vanilla as in compiled yourself? or the default arch one?
I'm using neither Powerdown nor TLP, and I don't have any suspension scripts.
I'm using gummiboot as a bootloader, maybe that's where the problem comes from.
Does anyone else have trouble with the latest kernels?
I can't seem to boot on anything more recent than the 3.9.2, be it the standard arch one or the ck one.
All I get is a black screen after the bootloader.