The 3.9.x-ck has brought me a bunch of problems. I don't know if it's a good idea to post all my problems to one topic, but I think that all are relative to each other. First of all, an error when I plug in usb devices:
Sometimes it also gives me a stack trace error, but not this time. After the stack trace it just hangs and I have to hard reboot (that's why I can't save it...)
Also, most times I can't suspend. I just get a black screen with an underscore. The system seems to suspend, but it just hangs. Hard reboot is the only solution once again.
Last, my GPU fan does not stop going crazy. After 5-10' of system boot, the GPU fan goes crazy and never stops. It used to do like that when I played games (either wine or native ones), but now for no reason. I use awesome wm, so I do nearly zero usage of GPU resources.
Please tell me what logs should I search and post them here
Last edited by ttouch (2013-07-01 13:22:25)
This doesn't seem to be anything that could be related to the CK patchset in my opinion. The linux-ck packages changes the CPU and IO schedulers, not the USB modules or the GPU.
Try using the stock Arch kernel first, it's probably a much more general problem than just the CK kernel, then report back.
3.10 was mainlined last night. Why not try it and see if you're problem are fixed? You'll have to wait for it to hit testing or roll your own.
How much will it take to be stable enough for arch core repos?
Likely 2-3 weeks in [testing] if history is any guide. That doesn't mean you can't try it and downgrade back to stable if something is bad.
The system seems to suspend, but it just hangs. Hard reboot is the only solution once again.
I've had this issue throughout the 3.9.x-ck series. It is intermittent, occurring with a frequency of ~1/5 suspend attempts. The system "partly" suspends and is not resumable. It's a ThinkPad X201s. The suspend indicator light (crecent moon) flashes rapidly rather than staying solid. The system must be powered off as even a sysrq is ineffective.
I initially attributed this to KDE's power management, having previously disabled systemd's part in the suspend process. However I recently removed KDE entirely and switched to i3wm, and the problem persisted.
Next I thought it was direcly resulting from an issue caused by the upstream 3.9.x kernels as this did not ever happen with a 3.8.x kernel.
I'm now I'm using systemd exclusively for suspend. I can reproduce this problem only on ck-kernels. As I've been busy scripting around systemd/i3lock/dunst, I've easily been through 40-50 suspend/resume cycles. I cannot triggger this problem with the default Arch kernel 3.9.9. So far it has only happened with the ck kernel.
I've been on ck kernels for quite a while now, and really appreciate graysky's efforts. This is the very first issue I've ever isolated to be ck-specific.
Today I gave the new linux-ck-nehalem 3.10-1 kernel a whirl. I was able to reproduce the borked suspend function on the 2nd attempt.
No time? Graysky provides a PKGBUILD, which makes compiling the CK kernel about a minute of work on your part. Otherwise, it may take some time to compile the kernel itself, but once it is going, it does not require you to actually do anything...
While I enjoy compiling my own kernels, if time is really a concern why not just use repo-ck?
That's where I get my *-ck kernels from, pre-built per architecture. Nehalem in my laptop's case.
Would it be better to start a new thread re:suspend problem with ck-kernels? Is every issue in the OP ck-specific?
As this issue continues to plague the ck-3.10.x series kernel, I want to ping Graysky with whatever info could be useful.
@ttouch: Please do test suspend functionality with the latest ck build v3.10.1-2. If you are no longer experiencing any problems I'll start a new thread.
I can still easily reproduce the failed suspend problem on ck-kernel v3.10.1-2. It was coincidental, but ulitimately irrelevant, that the -2 rebuild fixed a very similar suspend issue:
Back to stock kernels for now...
Not sure what I can add here... for one, I don't suspend my machine Even if I did, all I could do was either confirm or not the behavior you're writing about. Is this potentially your problem: https://bugs.archlinux.org/task/36107
I also can't suspend towards the end of the 3.9 releases and now 3.10
This was with nvidia blob, and now with the radeon driver as I had to RMA my card. So the video card drivers are out of the question of what could cause the suspend to hang. And I don't have any other PCI device or fancy usb device connected.
Asus M4A785TD-V ;; Phenom II X4 @ 3.9GHz ;; Ripjaws 12GB DDR3-1600 ;; 128GB Samsung 830 ;; MSI GTX460 v2 w/ blob ;; Arch Linux + KDE 4.x
Is this potentially your problem: https://bugs.archlinux.org/task/36107
Thanks for the suggestion. It seems that bug report applies to the standard arch kernel 3.10 and is also regarding resume. For me, when suspend fails, the system just hangs (fan still running, suspend incomplete) and there is no resume. Requires hard power-off.
Mine is a ck-specific problem. On the standard Arch kernel 3.9.x series I've had no issues whatsoever with suspend. With 3.9.9 nehalem ck suspend fails ~25% rate. If I were to make an uneducated guess at the cause, I'd say the ck kernel is just too fast!
I might try the generic ck kernel next to see if it's the nehalem-specific flags, and maybe roll my own with the patchset to try to isolate the cause. It would be a shame if I can't use ck kernels any longer.
Last edited by tekstryder (2013-07-16 00:27:41)
After a day using -ck sandybridge, same problems appeared. Also, I had a resume failure. It suspended right, but it hanged on resume. Also the fan actually runs like crazy after a reboot.
Back to arch for a while...
Last edited by ttouch (2013-07-16 07:41:45)
I suspend my computer a lot, so this is a problematic issue for me. I'm experiencing hard freezes almost everytime when going into suspend only with the -ck kernels. Vanilla Arch kernel works fine. I noticed the problem happens more frequently when over half of my RAM is consumed when going into suspend.
I have tried suspending usbcore, vboxdrv, iwlwifi driver modules but it has not helped so far.
local/linux-ck-ivybridge 3.10.1-2 (ck-ivybridge) Linux Kernel and modules with the ck1 patchset featuring the Brain Fuck Scheduler v0.440. Third Gen Intel Core i3/i5/i7 optimized. local/linux-ck-ivybridge-headers 3.10.1-2 (ck-ivybridge) Header files and scripts to build modules for linux-ck. Third Gen Intel Core i3/i5/i7 optimized. local/nvidia-ck-ivybridge 319.32-3 (ck-ivybridge) NVIDIA drivers for linux-ck. Third Gen Intel Core i3/i5/i7 optimized. local/virtualbox-ck-host-modules-ivybridge 4.2.16-3 (ck-ivybridge) Host kernel modules for VirtualBox running under Linux-ck. Third Gen Intel Core i3/i5/i7 optimized.
Intel(R) Core(TM) i7-3720QM
NVIDIA Corporation GF114M [GeForce GTX 675M] - nvidia/not nouveau
HDA Intel Audio - Creative CA0132 Card
Intel Corporation Centrino Wireless-N 2230 - iwlwifi
Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader (I noticed this causes hard freezes with suspend occasionally)
I'll try the -ck kernel without the BFQ scheduler and see if it changes anything.
Last edited by awbs (2013-07-21 23:19:29)
Agreed. RAM usage is not a factor for me either.
I can reproduce the failed suspend using ck kernels immediately following a clean boot. Using only ~150MB / 4GB.