gmane.linux.swsusp.devel
http://blog.gmane.org/gmane.linux.swsusp.devel
hourly11901-01-01T00:00+00:00Gmanehttp://gmane.org/img/gmane-25t.png
http://gmane.org
Freeing memory
http://comments.gmane.org/gmane.linux.swsusp.devel/14260
<pre>Hi Nigel,
I've updated to current git in the hope the memory freeing problems
would be solved. Unfortunately, they are still there and I've been
trying to narrow the issue down. Actually, there are two issues:
First, the memory eating process seems to lock up the machine when it
requests too much memory. Commmit
f8262d476823a7ea1eb497ff9676d1eab2393c75 "PM / Hibernate: fix the number
of pages used for hibernate/thaw buffering" doesn't help with that.
Maybe tuxonice needs to play catch up on that? Using smaller values and
more tries seems to help with the freezes, but I don't know what a safe
value would be.
Next, there seems to be a limit to what amount of the pagecache is
freeable using the tuxonice memory eater method. Having a total of 16
GiB, I increased the max tries and set a limit of max 4096MiB to free
per try so that it would not freeze, but the memory eater hit some limit
(at that time 4973MiB) where it could not free more memory. Dropping the
caches manually via "echo 1 > /proc/sys/vm/drop_caches" immediately
solved the problem and resulted in an image of 2180MiB, IIRC
image_size_limit was set to 3GiB.
There is an easy way to reproduce this, probably both issues actually:
Just copy some big files, e.g. videos, before hibernating.
I've also used the shrink_all_memory call instead of the separate
requests for freeing low and high pages, but that didn't make any
noticable difference. BTW: That debug message in
tuxonice_prepare_image.c "Asked shrink_all_memory for ... low pages &
... pages from anywhere) is a bit outdated, since shrink_all_memory is
no longer used.
I believe that memory freeing seemed to work fine before and the culprit
is some commit between 3.2-rc6 and 3.3. Might it have to do something
with what f8262d476823a7ea1eb497ff9676d1eab2393c75 tried to fix?
However, my machines are all 64 bit. Do you have any idea, shall I try
to bisect?
Harald
</pre>Harald Judt2012-05-21T06:46:53BUG() during restore
http://comments.gmane.org/gmane.linux.swsusp.devel/14259
<pre>Hello,
I'm using pf-sources-3.3.3 (vanilla patched with last toi I think..) and during
resume I'm getting a lot of
[ 512.314188] BUG: using smp_processor_id() in preemptible [00000000] code:
ktoi_io/2/4196
[ 512.314209] caller is worker_rw_loop+0x408/0xbe0
[ 512.314212] Pid: 4196, comm: ktoi_io/2 Tainted: G W 3.3.3-pf #4
[ 512.314215] Call Trace:
[ 512.314221] [<ffffffff811f8978>] ? debug_smp_processor_id+0xd8/0xf0
[ 512.314224] [<ffffffff8105ed68>] ? worker_rw_loop+0x408/0xbe0
[ 512.314228] [<ffffffff8104d390>] ? add_wait_queue+0x60/0x60
[ 512.314230] [<ffffffff8105e960>] ? attempt_to_parse_resume_device2+0x20/0x20
[ 512.314234] [<ffffffff8104ca25>] ? kthread+0x85/0x90
[ 512.314239] [<ffffffff81488f94>] ? kernel_thread_helper+0x4/0x10
[ 512.314242] [<ffffffff8104c9a0>] ? kthread_freezable_should_stop+0x60/0x60
[ 512.314245] [<ffffffff81488f90>] ? gs_change+0xb/0xb
I tried to change one onvocation of smp_processor_id() in worker_rw_loop() to
get_cpu() but the result is the same. I think the bug is somewhere else..
I hope it can help. Please tell me if can do something else!
Cheers,
</pre>Antonio Quartulli2012-05-01T09:16:18Unable to free memory with current tuxonice-git
http://comments.gmane.org/gmane.linux.swsusp.devel/14258
<pre>Hi,
Actually the following error has already been there since >3.2-rc7, but
until now I simply worked around it using echo 1 > /proc/sys/vm/drop_caches.
In short, tuxonice can't free enough memory:
TuxOnIce 3.2.1, with support for usm, compression, block i/o, swap
storage, userui.
Initiating a hibernation cycle.
Using configuration file /etc/splash/tuxonice/1920x1080.cfg.
No silent picture specified in the theme config.
Framebuffer support initialised successfully.
Starting other threads.Freezing user space processes ... (elapsed 0.01
seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Asked shrink_all_memory for 2028770 low pages & 610379 pages from
anywhere, got 0.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Asked shrink_all_memory for 2013849 low pages & 595383 pages from
anywhere, got 0.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Restarting kernel threads ... done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Free:40974(40974). Sets:2653287(2653287),0(0).
Nosave:1497981-1494456=3525. Storage:1045374/1045374(1615972=>1591972).
Needed:579630,0,1998065(100,1303,40000,2560) (PS2:no)
Failed to prepare the image because...
- The maximum number of iterations was reached without successfully
preparing the image.
- We need at least 1591972 pages of storage (ignoring the header), but
only have 1045374.
- We need to free 579630 lowmem pageset 1 pages.
Restarting tasks ... Restarting kernel threads ... done.
done.
TuxOnIce debugging info:
- TuxOnIce core : 3.2.1
- Kernel Version : 3.3.2+
- Compiler vers. : 4.6
- Attempt number : 3
- Parameters : 4233 700424 0 1 2560 5
- Overall expected compression percentage: 40.
- Compressor is 'lzo'.
- Block I/O active.
Used 0 pages from swap on /dev/sdb2.
- Max outstanding reads 1. Max writes 0.
Memory_needed: 1024 x (4096 + 360 + 104) = 4669440 bytes.
Free mem throttle point reached 0.
- Swap Allocator enabled.
Swap available for image: 1048575 pages.
- No I/O speed stats available.
- Extra pages : 16279 used/40000.
- Result : Hibernation was aborted.
: Insufficient storage was available.
: Unable to free enough memory to hibernate.
: We were unable to successfully prepare an image.
Note the shrink_all_memory results. It's not that there is not enough
memory available, but nothing gets freed. The whole process is over very
quickly.
As already said, echo 1 > /proc/sys/vm/drop_caches makes it work. But
then, no memory needs to be freed.
Harald
</pre>Harald Judt2012-04-26T09:06:44BFS vs Tuxonice issue
http://comments.gmane.org/gmane.linux.swsusp.devel/14256
<pre>Hi Nigel,
Did you have time to look into the BFS compatibility issue when
multi-threaded compression is enabled?
With the current tuxonice 3.2.1 linux-3.3.2 from git I get the following
error now (it's the same message repeated many many many times):
BUG: scheduling while atomic: BFS/2/0/0x00000002
Modules linked in: tun ehci_hcd w83627ehf hwmon_vid coretemp ipt_REJECT
ipt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack
xt_multiport ipv6 iptable_filter ip_tables x_tables vboxdrv(O) loop
joydev gspca_pac207 gspca_main videodev v4l2_compat_ioctl32 usbhid
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_emu10k1
snd_hwdep snd_util_mem snd_ac97_codec ac97_bus snd_rawmidi
snd_seq_device snd_hda_codec sr_mod xhci_hcd usbcore 8250_pnp 8250
serial_core emu10k1_gp gameport snd_pcm processor snd_page_alloc
snd_timer snd soundcore usb_common i2c_i801 thermal_sys button [last
unloaded: ehci_hcd]
Pid: 0, comm: BFS/2 Tainted: G D O 3.3.2+ #24
Call Trace:
[<ffffffff813f2c3f>] __schedule_bug+0x55/0x59
[<ffffffff813f8e6a>] schedule+0x9f/0xb2e
[<ffffffff813fa2ad>] ? _raw_spin_unlock_irqrestore+0x28/0x2a
[<ffffffff8103f8a0>] ? __hrtimer_start_range_ns+0x25d/0x26f
[<ffffffff8103f8d6>] ? hrtimer_start_range_ns+0xf/0x11
[<ffffffff81000817>] cpu_idle+0xab/0xb4
[<ffffffff813ee551>] start_secondary+0x1ca/0x1cf
Apart from these error messages there seem to be no other negative
effects. These errors did not occur when using tuxonice+linux-3.3.0
(same configuration).
ProcSetting no_multithreaded_io 1
ProcSetting no_flusher_thread 1
BTW: It's a pity they turned around the snapshot/atomic copy
reading/writing. Now the nice tuxoniceui is only visible for a very
short time (atomic copy) when resuming. But as long as it works, one
should not complain...
Thanks for keeping tuxonice up-to-date.
Harald
</pre>Harald Judt2012-04-23T18:08:21Cannot hibernate using tuxonice
http://comments.gmane.org/gmane.linux.swsusp.devel/14255
<pre>Hi,
I have been trying to hibernate my desktop (AMD, Ubuntu 11.10, Nvidia
Graphic Drivers) and so far I am not able o successfully do it. Ubuntu
kernel was always a problem, but in earlier tuxonice use to work perfectly
alright. Every since I upgrade to 11.10, I can't hibernate using TOI.
Please help me in debugging this issue. Attached are the files.
Thanks,
Niren Sinha | nirensinha< at >gmail.com
_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel</pre>Niren Sinha2012-04-20T11:28:57ifdefs fixes for TOI
http://comments.gmane.org/gmane.linux.swsusp.devel/14248
<pre>Hi. Nigel.
The following changes since commit ce3052791e80fd1cab87da52dd6e4d675b33ede5:
add ifdefs to handle CONFIG_FREEZER properly (2012-04-12 22:14:42 +0300)
are available in the git repository at:
git://github.com/pfactum/pf-kernel.git toi-fixes-for-3.3-1
for you to fetch changes up to ce3052791e80fd1cab87da52dd6e4d675b33ede5:
add ifdefs to handle CONFIG_FREEZER properly (2012-04-12 22:14:42 +0300)
Regards,
post-factum
_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel</pre>Oleksandr Natalenko2012-04-12T19:28:31userspace ui doesn't work with latest tuxonice-head
http://comments.gmane.org/gmane.linux.swsusp.devel/14247
<pre>Hello everybody,
I have tried the latest tuxonice-head git tree and I notice that the
userspace interface doesn't work. I get this message in the logs:
pc-francois kernel: [ 48.132314] userspace ui: Failed to contact
userspace process.
I don't encounter this problem with tuxonice on the 3.3 kernel.
Does anybody knows what's happening ?
Thanks in advance for your help.
</pre>François Valenduc2012-04-08T10:05:40TOI fails with 3.3
http://comments.gmane.org/gmane.linux.swsusp.devel/14242
<pre>Hi!
I've experienced bunch of problems with TOI branch for Linux 3.3. First,
kernel oopsed on b43 driver during hibernation, then I repeated
hibernation and got kernel panic. Third try was broken because TOI
didn't find storage…
Are those problem well-known? What should I try to report about first?
Regards,
post-factum
_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel</pre>Oleksandr Natalenko2012-04-06T12:27:31duplicate boot_kernel_data_buffer
http://comments.gmane.org/gmane.linux.swsusp.devel/14238
<pre>Hi all,
I'm doing porting development of the TuxOnIce to ARM/BeagleBoard.
I'm investigating the phenomenon (The board freezes at the time of RESUME) where RESUME is not stabilized,
and I have a question about boot_kernel_data_buffer.
The debugging code for displaying restore_pblist was added. (below)
When the phenomenon to freeze occurs, orig_address of boot_kernel_data_buffer is displayed(printk output) twice.
Please tell me whether it is a bug that there is a duplicate to pblist boot_kernel_data_buffer.
tuxonice_pagedir.c:
int add_boot_kernel_data_pbe(void)
{
this_low_pbe->address = (char *) __toi_get_nonconflicting_page();
if (!this_low_pbe->address) {
printk(KERN_INFO "Failed to get bkd atomic restore buffer.");
return -ENOMEM;
}
toi_bkd.size = sizeof(toi_bkd);
memcpy(this_low_pbe->address, &toi_bkd, sizeof(toi_bkd));
*last_low_pbe_ptr = this_low_pbe;
this_low_pbe->orig_address = (char *) boot_kernel_data_buffer;
this_low_pbe->next = NULL;
/*********************** DEBUG CODE ***********************/
#ifdefPBLIST_DUMP
static struct pbe *temp_pbe;
printk(" ------- restore_pblist dump ------- ¥n");
temp_pbe = restore_pblist;
while(1) {
if(temp_pbe == (struct pbe*)0) break;
printk("address = 0x%08x, orig_address = 0x%08x, next = 0x%08x¥n",
temp_pbe->address, temp_pbe->orig_address, temp_pbe->next);
temp_pbe = temp_pbe->next;
}
#endif
return 0;
}
Regards,
sabakawa
</pre>natuki.sabakawa< at >gmail.com2012-03-20T04:42:01task kworker/1:0:9 blocked for more than 120seconds after resume
http://comments.gmane.org/gmane.linux.swsusp.devel/14237
<pre>Hi all,
Today I tried tuxonice 3.2.1 (I got from git and merged it with ubuntu's 3.2 kernel).
Tuxonice can hibernate easily, but after it resumes, I saw this:
---
Mar 20 09:06:44 raynor kernel: [ 182.064578] TuxOnIce debugging info:
Mar 20 09:06:44 raynor kernel: [ 182.064578] - TuxOnIce core : 3.2.1
Mar 20 09:06:44 raynor kernel: [ 182.064578] - Kernel Version : 3.2.0-19-generic-tuxonice
Mar 20 09:06:44 raynor kernel: [ 182.064579] - Compiler vers. : 4.6
Mar 20 09:06:44 raynor kernel: [ 182.064579] - Attempt number : 1
Mar 20 09:06:44 raynor kernel: [ 182.064579] - Parameters : 0 667656 0 1 -2 5
Mar 20 09:06:44 raynor kernel: [ 182.064580] - Overall expected compression percentage: 0.
Mar 20 09:06:44 raynor kernel: [ 182.064580] - Checksum method is 'md4'.
Mar 20 09:06:44 raynor kernel: [ 182.064580] 0 pages resaved in atomic copy.
Mar 20 09:06:44 raynor kernel: [ 182.064581] - Compressor is 'lzo'.
Mar 20 09:06:44 raynor kernel: [ 182.064581] Compressed 1007841280 bytes into 349281655 (65 percent compression).
Mar 20 09:06:44 raynor kernel: [ 182.064582] - Block I/O active.
Mar 20 09:06:44 raynor kernel: [ 182.064582] Used 86209 pages from swap on /dev/sdb3.
Mar 20 09:06:44 raynor kernel: [ 182.064582] - Max outstanding reads 1268. Max writes 17288.
Mar 20 09:06:44 raynor kernel: [ 182.064583] Memory_needed: 1024 x (4096 + 368 + 112) = 4685824 bytes.
Mar 20 09:06:44 raynor kernel: [ 182.064583] Free mem throttle point reached 0.
Mar 20 09:06:44 raynor kernel: [ 182.064583] - Swap Allocator enabled.
Mar 20 09:06:44 raynor kernel: [ 182.064584] Swap available for image: 12207030 pages.
Mar 20 09:06:44 raynor kernel: [ 182.064584] - File Allocator active.
Mar 20 09:06:44 raynor kernel: [ 182.064584] Storage available for image: 0 pages.
Mar 20 09:06:44 raynor kernel: [ 182.064585] - I/O speed: Write 259 MB/s, Read 238 MB/s.
Mar 20 09:06:44 raynor kernel: [ 182.064585] - Extra pages : 0 used/2000.
Mar 20 09:06:44 raynor kernel: [ 182.064586] - Result : Succeeded.
Mar 20 09:06:45 raynor kernel: [ 182.559587] r8169 0000:04:00.0: eth0: link up
Mar 20 09:09:43 raynor kernel: [ 360.849233] INFO: task kworker/1:0:9 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.849554] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.849890] kworker/1:0 D ffffffff81806240 0 9 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.849892] ffff880425f3dab0 0000000000000046 ffff880425f344e8 0000000000000001
Mar 20 09:09:43 raynor kernel: [ 360.849895] ffff880425f3dfd8 ffff880425f3dfd8 ffff880425f3dfd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.849896] ffff880425fc96e0 ffff880425f344a0 ffff880425f3da90 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.849898] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.849903] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.849905] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.849907] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.849909] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.849911] [<ffffffff8167609f>] ? schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.849913] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.849915] [<ffffffff8103dbb9>] ? default_spin_lock_flags+0x9/0x10
Mar 20 09:09:43 raynor kernel: [ 360.849916] [<ffffffff8167823e>] ? _raw_spin_lock_irqsave+0x2e/0x40
Mar 20 09:09:43 raynor kernel: [ 360.849919] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.849920] [<ffffffff81052012>] ? ttwu_queue+0x92/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.849922] [<ffffffff8105fa4e>] ? try_to_wake_up+0x18e/0x200
Mar 20 09:09:43 raynor kernel: [ 360.849924] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.849926] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.849928] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.849929] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.849930] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.849932] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.849935] [<ffffffff810859e0>] ? manage_workers.isra.29+0x130/0x130
Mar 20 09:09:43 raynor kernel: [ 360.849936] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.849938] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.849940] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.849941] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.849942] INFO: task migration/2:13 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.850287] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.850643] migration/2 D 0000000000000000 0 13 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.850645] ffff880425fd3ab0 0000000000000046 0000000000000000 0000000000000000
Mar 20 09:09:43 raynor kernel: [ 360.850647] ffff880425fd3fd8 ffff880425fd3fd8 ffff880425fd3fd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.850649] ffff880425fe2dc0 ffff880425fcc4a0 00000000000005fa ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.850650] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.850652] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.850653] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.850656] [<ffffffff81322db6>] ? cpumask_next_and+0x36/0x50
Mar 20 09:09:43 raynor kernel: [ 360.850657] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.850659] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.850660] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.850663] [<ffffffff81033b44>] ? __assign_irq_vector+0x234/0x290
Mar 20 09:09:43 raynor kernel: [ 360.850664] [<ffffffff81033b44>] ? __assign_irq_vector+0x234/0x290
Mar 20 09:09:43 raynor kernel: [ 360.850666] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.850667] [<ffffffff81090ffd>] ? sched_clock_cpu+0xbd/0x110
Mar 20 09:09:43 raynor kernel: [ 360.850669] [<ffffffff810126e5>] ? __switch_to+0xf5/0x360
Mar 20 09:09:43 raynor kernel: [ 360.850671] [<ffffffff81677fae>] ? _raw_spin_lock+0xe/0x20
Mar 20 09:09:43 raynor kernel: [ 360.850672] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.850673] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.850674] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.850676] [<ffffffff810d6801>] ? queue_stop_cpus_work+0x51/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.850677] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.850679] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.850680] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.850681] [<ffffffff810d69f0>] ? __stop_cpus+0x80/0x80
Mar 20 09:09:43 raynor kernel: [ 360.850683] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.850684] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.850685] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.850687] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.850688] INFO: task kworker/2:0:14 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.851057] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.851438] kworker/2:0 D ffffffff81806240 0 14 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.851439] ffff880425fd9ab0 0000000000000046 ffff880425fcdbc8 0000000000000001
Mar 20 09:09:43 raynor kernel: [ 360.851441] ffff880425fd9fd8 ffff880425fd9fd8 ffff880425fd9fd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.851443] ffff880425fe16e0 ffff880425fcdb80 0000000000000000 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.851445] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.851446] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.851448] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.851449] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.851451] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.851452] [<ffffffff8167609f>] ? schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.851454] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.851455] [<ffffffff8103dbb9>] ? default_spin_lock_flags+0x9/0x10
Mar 20 09:09:43 raynor kernel: [ 360.851456] [<ffffffff8167823e>] ? _raw_spin_lock_irqsave+0x2e/0x40
Mar 20 09:09:43 raynor kernel: [ 360.851458] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.851459] [<ffffffff81052012>] ? ttwu_queue+0x92/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.851461] [<ffffffff8105fa4e>] ? try_to_wake_up+0x18e/0x200
Mar 20 09:09:43 raynor kernel: [ 360.851462] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.851463] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.851464] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.851466] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.851467] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.851468] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.851470] [<ffffffff810859e0>] ? manage_workers.isra.29+0x130/0x130
Mar 20 09:09:43 raynor kernel: [ 360.851471] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.851473] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.851474] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.851476] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.851477] INFO: task watchdog/2:16 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.851865] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.852267] watchdog/2 D 0000000000000000 0 16 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.852269] ffff880425febab0 0000000000000046 ffff880402618000 ffff88043fa13840
Mar 20 09:09:43 raynor kernel: [ 360.852271] ffff880425febfd8 ffff880425febfd8 ffff880425febfd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.852272] ffff880402618000 ffff880425fe2dc0 ffff880425febb00 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.852274] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.852276] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.852277] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.852279] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.852280] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.852281] [<ffffffff81322db6>] ? cpumask_next_and+0x36/0x50
Mar 20 09:09:43 raynor kernel: [ 360.852283] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.852285] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.852286] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.852287] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.852288] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.852290] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.852291] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.852292] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.852294] [<ffffffff810619c3>] ? sched_setscheduler+0x13/0x20
Mar 20 09:09:43 raynor kernel: [ 360.852296] [<ffffffff810ed650>] ? watchdog_enable+0x100/0x100
Mar 20 09:09:43 raynor kernel: [ 360.852297] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.852299] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.852300] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.852301] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.852302] INFO: task migration/3:17 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.852715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.853146] migration/3 D 0000000000000000 0 17 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.853147] ffff880425fedab0 0000000000000046 0000000000000000 0000000000000000
Mar 20 09:09:43 raynor kernel: [ 360.853149] ffff880425fedfd8 ffff880425fedfd8 ffff880425fedfd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.853151] ffff880425802dc0 ffff880425fe44a0 0000000000000438 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.853153] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.853154] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.853156] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.853157] [<ffffffff81322db6>] ? cpumask_next_and+0x36/0x50
Mar 20 09:09:43 raynor kernel: [ 360.853159] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.853160] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.853162] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.853163] [<ffffffff81033b44>] ? __assign_irq_vector+0x234/0x290
Mar 20 09:09:43 raynor kernel: [ 360.853165] [<ffffffff81033b44>] ? __assign_irq_vector+0x234/0x290
Mar 20 09:09:43 raynor kernel: [ 360.853166] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.853168] [<ffffffff81090ffd>] ? sched_clock_cpu+0xbd/0x110
Mar 20 09:09:43 raynor kernel: [ 360.853169] [<ffffffff810126e5>] ? __switch_to+0xf5/0x360
Mar 20 09:09:43 raynor kernel: [ 360.853171] [<ffffffff81677fae>] ? _raw_spin_lock+0xe/0x20
Mar 20 09:09:43 raynor kernel: [ 360.853172] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.853174] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.853176] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.853178] [<ffffffff810d6801>] ? queue_stop_cpus_work+0x51/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.853181] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.853183] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.853185] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.853187] [<ffffffff810d69f0>] ? __stop_cpus+0x80/0x80
Mar 20 09:09:43 raynor kernel: [ 360.853189] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.853192] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.853194] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.853196] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.853198] INFO: task kworker/3:0:18 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.853635] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.854085] kworker/3:0 D ffffffff81806240 0 18 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.854086] ffff880425fefab0 0000000000000046 ffff880425fe5bc8 0000000000000001
Mar 20 09:09:43 raynor kernel: [ 360.854088] ffff880425feffd8 ffff880425feffd8 ffff880425feffd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.854090] ffff8804258016e0 ffff880425fe5b80 0000000000000000 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.854092] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.854093] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.854095] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.854097] [<ffffffff8104ddb2>] ? complete+0x52/0x60
Mar 20 09:09:43 raynor kernel: [ 360.854098] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.854099] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.854101] [<ffffffff811772ab>] ? kfree+0x3b/0x140
Mar 20 09:09:43 raynor kernel: [ 360.854103] [<ffffffff814af640>] ? usb_free_urb+0x20/0x20
Mar 20 09:09:43 raynor kernel: [ 360.854104] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.854106] [<ffffffff81326146>] ? kref_put+0x36/0x70
Mar 20 09:09:43 raynor kernel: [ 360.854108] [<ffffffff814af63a>] ? usb_free_urb+0x1a/0x20
Mar 20 09:09:43 raynor kernel: [ 360.854109] [<ffffffff814b06b0>] ? usb_start_wait_urb+0xa0/0xf0
Mar 20 09:09:43 raynor kernel: [ 360.854111] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.854113] [<ffffffff810772a8>] ? lock_timer_base.isra.29+0x38/0x70
Mar 20 09:09:43 raynor kernel: [ 360.854114] [<ffffffff81052012>] ? ttwu_queue+0x92/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.854116] [<ffffffff8105fa4e>] ? try_to_wake_up+0x18e/0x200
Mar 20 09:09:43 raynor kernel: [ 360.854117] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.854118] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.854119] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.854121] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.854122] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.854123] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.854125] [<ffffffff810859e0>] ? manage_workers.isra.29+0x130/0x130
Mar 20 09:09:43 raynor kernel: [ 360.854126] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.854128] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.854129] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.854130] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.854131] INFO: task ksoftirqd/3:19 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.854589] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.855062] ksoftirqd/3 D 0000000000000000 0 19 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.855063] ffff880425ffdab0 0000000000000046 0b294557d0a8056f c965c1ced9e8c5f3
Mar 20 09:09:43 raynor kernel: [ 360.855065] ffff880425ffdfd8 ffff880425ffdfd8 ffff880425ffdfd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.855067] ffff880402618000 ffff880425800000 0000000000000001 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.855069] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.855070] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.855072] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.855073] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.855075] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.855076] [<ffffffff81322db6>] ? cpumask_next_and+0x36/0x50
Mar 20 09:09:43 raynor kernel: [ 360.855077] [<ffffffff8105a5a1>] ? find_busiest_group+0x171/0xbb0
Mar 20 09:09:43 raynor kernel: [ 360.855079] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.855081] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.855082] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.855083] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.855084] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.855086] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.855087] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.855088] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.855090] [<ffffffff8167609f>] ? schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.855092] [<ffffffff8106ec95>] ? run_ksoftirqd+0xe5/0x170
Mar 20 09:09:43 raynor kernel: [ 360.855093] [<ffffffff8106ebb0>] ? __do_softirq+0x210/0x210
Mar 20 09:09:43 raynor kernel: [ 360.855094] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.855096] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.855097] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.855099] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.855100] INFO: task watchdog/3:20 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.855580] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.856075] watchdog/3 D 0000000000000000 0 20 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.856076] ffff880425809ab0 0000000000000046 ffff880402618000 ffff88043fa13840
Mar 20 09:09:43 raynor kernel: [ 360.856078] ffff880425809fd8 ffff880425809fd8 ffff880425809fd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.856080] ffff880402618000 ffff880425802dc0 ffff880425809b00 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.856082] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.856083] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.856085] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.856086] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.856088] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.856089] [<ffffffff81322db6>] ? cpumask_next_and+0x36/0x50
Mar 20 09:09:43 raynor kernel: [ 360.856090] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.856092] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.856093] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.856095] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.856096] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.856097] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.856098] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.856100] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.856101] [<ffffffff810619c3>] ? sched_setscheduler+0x13/0x20
Mar 20 09:09:43 raynor kernel: [ 360.856103] [<ffffffff810ed650>] ? watchdog_enable+0x100/0x100
Mar 20 09:09:43 raynor kernel: [ 360.856104] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.856105] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.856107] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.856108] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.856109] INFO: task migration/4:21 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.856614] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.857134] migration/4 D 0000000000000000 0 21 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.857135] ffff88042580bab0 0000000000000046 0000000000000000 0000000000000000
Mar 20 09:09:43 raynor kernel: [ 360.857137] ffff88042580bfd8 ffff88042580bfd8 ffff88042580bfd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.857139] ffff88042581adc0 ffff8804258044a0 00000000000003fe ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.857141] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.857142] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.857144] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.857145] [<ffffffff81322db6>] ? cpumask_next_and+0x36/0x50
Mar 20 09:09:43 raynor kernel: [ 360.857147] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.857148] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.857150] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.857151] [<ffffffff81033b44>] ? __assign_irq_vector+0x234/0x290
Mar 20 09:09:43 raynor kernel: [ 360.857153] [<ffffffff81033b44>] ? __assign_irq_vector+0x234/0x290
Mar 20 09:09:43 raynor kernel: [ 360.857154] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.857155] [<ffffffff81090ffd>] ? sched_clock_cpu+0xbd/0x110
Mar 20 09:09:43 raynor kernel: [ 360.857157] [<ffffffff810126e5>] ? __switch_to+0xf5/0x360
Mar 20 09:09:43 raynor kernel: [ 360.857159] [<ffffffff81677fae>] ? _raw_spin_lock+0xe/0x20
Mar 20 09:09:43 raynor kernel: [ 360.857160] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.857161] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.857162] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.857165] [<ffffffff810d6801>] ? queue_stop_cpus_work+0x51/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.857167] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.857169] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.857172] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.857174] [<ffffffff810d69f0>] ? __stop_cpus+0x80/0x80
Mar 20 09:09:43 raynor kernel: [ 360.857176] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.857178] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.857180] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.857182] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:09:43 raynor kernel: [ 360.857184] INFO: task kworker/4:0:22 blocked for more than 120 seconds.
Mar 20 09:09:43 raynor kernel: [ 360.857712] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:09:43 raynor kernel: [ 360.858251] kworker/4:0 D ffffffff81806240 0 22 2 0x00000000
Mar 20 09:09:43 raynor kernel: [ 360.858253] ffff88042580dab0 0000000000000046 ffff880425805b80 ffffffffffffffff
Mar 20 09:09:43 raynor kernel: [ 360.858255] ffff88042580dfd8 ffff88042580dfd8 ffff88042580dfd8 0000000000013840
Mar 20 09:09:43 raynor kernel: [ 360.858256] ffff8804258196e0 ffff880425805b80 ffff88042580db68 ffff88041d42aa90
Mar 20 09:09:43 raynor kernel: [ 360.858258] Call Trace:
Mar 20 09:09:43 raynor kernel: [ 360.858260] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:09:43 raynor kernel: [ 360.858261] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:09:43 raynor kernel: [ 360.858263] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:09:43 raynor kernel: [ 360.858264] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.858266] [<ffffffff813088fa>] ? freed_request+0x4a/0x70
Mar 20 09:09:43 raynor kernel: [ 360.858267] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:09:43 raynor kernel: [ 360.858268] [<ffffffff81308c99>] ? blk_put_request+0x49/0x60
Mar 20 09:09:43 raynor kernel: [ 360.858270] [<ffffffff814434ef>] ? scsi_execute+0x11f/0x180
Mar 20 09:09:43 raynor kernel: [ 360.858271] [<ffffffff811772ab>] ? kfree+0x3b/0x140
Mar 20 09:09:43 raynor kernel: [ 360.858273] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:09:43 raynor kernel: [ 360.858274] [<ffffffff81052012>] ? ttwu_queue+0x92/0xd0
Mar 20 09:09:43 raynor kernel: [ 360.858276] [<ffffffff8105fa4e>] ? try_to_wake_up+0x18e/0x200
Mar 20 09:09:43 raynor kernel: [ 360.858277] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:09:43 raynor kernel: [ 360.858278] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:09:43 raynor kernel: [ 360.858279] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:09:43 raynor kernel: [ 360.858281] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:09:43 raynor kernel: [ 360.858282] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:09:43 raynor kernel: [ 360.858283] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:09:43 raynor kernel: [ 360.858285] [<ffffffff810859e0>] ? manage_workers.isra.29+0x130/0x130
Mar 20 09:09:43 raynor kernel: [ 360.858286] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.858287] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:09:43 raynor kernel: [ 360.858289] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:09:43 raynor kernel: [ 360.858290] [<ffffffff81682730>] ? gs_change+0x13/0x13
Mar 20 09:14:07 raynor kernel: [ 624.564436] INFO: task kworker/1:0:9 blocked for more than 60 seconds.
Mar 20 09:14:07 raynor kernel: [ 624.564926] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Mar 20 09:14:07 raynor kernel: [ 624.565423] kworker/1:0 D ffffffff81806240 0 9 2 0x00000000
Mar 20 09:14:07 raynor kernel: [ 624.565425] ffff880425f3dab0 0000000000000046 ffff880425f344e8 0000000000000001
Mar 20 09:14:07 raynor kernel: [ 624.565427] ffff880425f3dfd8 ffff880425f3dfd8 ffff880425f3dfd8 0000000000013840
Mar 20 09:14:07 raynor kernel: [ 624.565429] ffff880425fc96e0 ffff880425f344a0 ffff880425f3da90 ffff88041d42aa90
Mar 20 09:14:07 raynor kernel: [ 624.565431] Call Trace:
Mar 20 09:14:07 raynor kernel: [ 624.565436] [<ffffffff8167609f>] schedule+0x3f/0x60
Mar 20 09:14:07 raynor kernel: [ 624.565438] [<ffffffff81676ea7>] __mutex_lock_slowpath+0xd7/0x150
Mar 20 09:14:07 raynor kernel: [ 624.565440] [<ffffffff81676aba>] mutex_lock+0x2a/0x50
Mar 20 09:14:07 raynor kernel: [ 624.565442] [<ffffffff8112e3b6>] generic_file_aio_write+0x56/0xe0
Mar 20 09:14:07 raynor kernel: [ 624.565444] [<ffffffff8167609f>] ? schedule+0x3f/0x60
Mar 20 09:14:07 raynor kernel: [ 624.565446] [<ffffffff81225edf>] ext4_file_write+0xbf/0x260
Mar 20 09:14:07 raynor kernel: [ 624.565448] [<ffffffff8103dbb9>] ? default_spin_lock_flags+0x9/0x10
Mar 20 09:14:07 raynor kernel: [ 624.565449] [<ffffffff8167823e>] ? _raw_spin_lock_irqsave+0x2e/0x40
Mar 20 09:14:07 raynor kernel: [ 624.565452] [<ffffffff8118c572>] do_sync_write+0xd2/0x110
Mar 20 09:14:07 raynor kernel: [ 624.565454] [<ffffffff81052012>] ? ttwu_queue+0x92/0xd0
Mar 20 09:14:07 raynor kernel: [ 624.565456] [<ffffffff8105fa4e>] ? try_to_wake_up+0x18e/0x200
Mar 20 09:14:07 raynor kernel: [ 624.565457] [<ffffffff8101a779>] ? read_tsc+0x9/0x20
Mar 20 09:14:07 raynor kernel: [ 624.565459] [<ffffffff81094fad>] ? ktime_get_ts+0xad/0xe0
Mar 20 09:14:07 raynor kernel: [ 624.565461] [<ffffffff810c78f4>] do_acct_process+0x2f4/0x350
Mar 20 09:14:07 raynor kernel: [ 624.565463] [<ffffffff810c79b6>] acct_process_in_ns+0x66/0x90
Mar 20 09:14:07 raynor kernel: [ 624.565464] [<ffffffff810c80c0>] acct_process+0x30/0x50
Mar 20 09:14:07 raynor kernel: [ 624.565466] [<ffffffff8106bc76>] do_exit+0x2c6/0x420
Mar 20 09:14:07 raynor kernel: [ 624.565468] [<ffffffff810859e0>] ? manage_workers.isra.29+0x130/0x130
Mar 20 09:14:07 raynor kernel: [ 624.565470] [<ffffffff8108a396>] kthread+0x86/0xa0
Mar 20 09:14:07 raynor kernel: [ 624.565472] [<ffffffff81682734>] kernel_thread_helper+0x4/0x10
Mar 20 09:14:07 raynor kernel: [ 624.565473] [<ffffffff8108a310>] ? flush_kthread_worker+0xa0/0xa0
Mar 20 09:14:07 raynor kernel: [ 624.565474] [<ffffffff81682730>] ? gs_change+0x13/0x13
---
Seems like a bug, isn't it ? Is this caused by tuxonice or is this a bug from vanilla kernel? Thanks.
BR,
Nai Xia
</pre>nai.xia2012-03-20T01:30:21Back to BFS+TOI issue
http://comments.gmane.org/gmane.linux.swsusp.devel/14229
<pre>Hi all.
I mailed Con Kolivas about TOI+BFS issue and he answered that won't fix
it as BFS is written to get mainline hibernation work but not TOI. He is
surprised that BFS+TOI works *somehow*.
The only quote about technical reason is:
"I suspect that something to do with the way the
compression threads are woken up on resume is broken when run on BFS."
So the last hope is Nigel.
As BFS+TOI users community is large enough, I expect it to help solving
the issue at least by providing debug info. We really need these
3rd-party patches work together.
For now, I discovered that LZO fails as well as LZF does, but with
different error.
In case of LZF it fails at tuxonice_compress.c:257 (outlen != PAGE_SIZE).
In case of LZO it fails at tuxonice_compress.c:254 (ret), and also at
tuxonice_io.c:645 (io_pageset == 1).
So crypto_comp_decompress call at tuxonice_compress.c:245 fails. Why —
no idea. I cannot investigate it deeper because of lack of knowledge
about kernel internals.
Nigel, help us if you can. Hope you HDDs are up and spinning .
Regards,
Oleksandr "post-factum" Natalenko, B.S.
http://pf.natalenko.name/
_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel</pre>Oleksandr Natalenko2012-03-08T23:20:48TOI inactivity
http://comments.gmane.org/gmane.linux.swsusp.devel/14226
<pre>Hey!
What happened to TOI web-site? When we should expect git tree update?
Regards,
post-factum
_______________________________________________
TuxOnIce-devel mailing list
TuxOnIce-devel< at >lists.tuxonice.net
http://lists.tuxonice.net/listinfo/tuxonice-devel</pre>Oleksandr Natalenko2012-03-06T09:35:48[ARM hibernation ] How to deal with PMem in android during hibernation ?
http://comments.gmane.org/gmane.linux.swsusp.devel/14218
<pre>HI ,
I'm working on hibernation of android in i.MX53 platform.
And I add this patch into kernel source from this link:
http://www.spinics.net/lists/arm-kernel/msg108560.html
At last, I find that this patch can not resume all of alloced memory
form PMem after resume for disk.
As we know, android add the new driver PMem into kernel. And android's
MM(memory manager) can not find and control alloced memory of PMem.
Maybe TOI's patch can deal with this issue. is it really?
And how to implement ?
Thanks,
Ryan
</pre>wang leileis2012-02-13T16:01:09Hello to the list - and Ubuntu Lucid, 2 luks partitions, 2 VGs, resume fails with "resume: device not found"
http://comments.gmane.org/gmane.linux.swsusp.devel/14216
<pre>Hi. First post :-)
This is a laptop, a W500, and with a new client, I need it to
hibernate and resume quickly - which means TuxOnIce...... there's a
guy with a MBP who often sits next to me, and he's making me look bad :-D
I have Ubuntu Lucid, 32-bit. Two hard drives. There's a luks
partition on each drive - each of which has lvm on it. /etc/crypttab
reflects the second luks partition, which of course has a different
volume group on it --- vg #2 uses a key file, in /etc/ on root LV on
the first vg.
So, on boot, I see the prompt for the pass phrase for luks #1, for vg
#1. Then, immediately, I get an error from tuxonice:
Key slot 0 unlocked.
8 logical volume(s) in volume group "wallevg0" now active
udevd-work[611]: inotify_add_watch(6, /dev/dm-8, 10) failed: No such
file or directory
Done.
Begin: Running /scripts/local-premount ...
resume: libgcrypt version: 1.4.4
resume: Could not stat the resume device file '/dev/disk/by-uuid/UUID1'
Please type in the full path name to try again
Google comes back with a huge list of hits on this, but the ones I
checked are not even close to my 'advanced config'. It sure looks to
me like tuxonice is firing after the first entry in crypttab, but
it's not waiting for the others to be activated. Else the partition
with that UUID would be available.
FYI, on a fully-booted session:
0 root wall-e 78.00% /var/log # blkid | grep -i UUID1
/dev/mapper/vg0-lvswap: UUID="UUID1" TYPE="swap"
(vg0 is the VG on the second hard drive)
So, it sure looks like I 'simply' need to have tuxonice wait until
cryptsetup is 100% done. Has anyone figured this out?
Let me know if you require additional info. And TIA....
N.B. I'm prepared to create a file-based hibernate state file, but
wanted to ask the list first. I really, really need the ability to
open the lid and have my Linux session up in a few seconds -
aforementioned Mac user is a nice guy but I invariably take a hit
from such folks wherever I go.......it's only a matter of time...
Thanks.
/Bill
</pre>gurunixx2012-02-13T04:34:56Hello to the list - and Ubuntu Lucid, 2 luks partitions, 2 VGs, resume fails with "resume: device not found"
http://comments.gmane.org/gmane.linux.swsusp.devel/14215
<pre>
Hi. First post :-)
This is a laptop, a W500, and with a new client, I need it to
hibernate and resume quickly - which means TuxOnIce...... there's a
guy with a MBP who often sits next to me, and he's making me look bad :-D
I have Ubuntu Lucid, 32-bit. Two hard drives. There's a luks
partition on each drive - each of which has lvm on it. /etc/crypttab
reflects the second luks partition, which of course has a different
volume group on it --- vg #2 uses a key file, in /etc/ on root LV on
the first vg.
So, on boot, I see the prompt for the pass phrase for luks #1, for vg
#1. Then, immediately, I get an error from tuxonice:
Key slot 0 unlocked.
8 logical volume(s) in volume group "wallevg0" now active
udevd-work[611]: inotify_add_watch(6, /dev/dm-8, 10) failed: No such
file or directory
Done.
Begin: Running /scripts/local-premount ...
resume: libgcrypt version: 1.4.4
resume: Could not stat the resume device file '/dev/disk/by-uuid/UUID1'
Please type in the full path name to try again
Google comes back with a huge list of hits on this, but the ones I
checked are not even close to my 'advanced config'. It sure looks to
me like tuxonice is firing after the first entry in crypttab, but
it's not waiting for the others to be activated. Else the partition
with that UUID would be available.
FYI, on a fully-booted session:
0 root wall-e 78.00% /var/log # blkid | grep -i UUID1
/dev/mapper/vg0-lvswap: UUID="UUID1" TYPE="swap"
(vg0 is the VG on the second hard drive)
So, it sure looks like I 'simply' need to have tuxonice wait until
cryptsetup is 100% done. Has anyone figured this out?
Let me know if you require additional info. And TIA....
N.B. I'm prepared to create a file-based hibernate state file, but
wanted to ask the list first. I really, really need the ability to
open the lid and have my Linux session up in a few seconds -
aforementioned Mac user is a nice guy but I invariably take a hit
from such folks wherever I go.......it's only a matter of time...
Thanks.
/Bill
</pre>gurunixx2012-02-13T04:30:41Up to date trees.
http://comments.gmane.org/gmane.linux.swsusp.devel/14212
<pre>Hi all.
Just to let you know that there are now up-to-date trees on Github:
https://github.com/NigelCunningham/tuxonice-kernel/branches
What's more, I'm happy with the stability of them - I've found the cause
of file system corruption I was getting (threads calling try_to_freeze
but not having invoked set_freezable), and am now working on getting
updated patches being automatically generated again.
Thanks to everyone for your patience and encouragement. The wheels fell
off for a while there, but I think I'm getting back on track. (I'll
leave you to wonder about mixed metaphors!)
Nigel
</pre>Nigel Cunningham2012-02-11T10:24:58function thaw_kernel_threads introduced by newkernel stable patch
http://comments.gmane.org/gmane.linux.swsusp.devel/14209
<pre>Hi all,
the kernel stable patch
pm-hibernate-fix-s2disk-regression-related-to-freezing-workqueues
has introduced another version of the function "thaw_kernel_threads"
that conflicts with this one from TuxOnIce,
Regards,
Jordi Pujol
Live never ending Tale
GNU/Linux Live forever!
http://livenet.selfip.com
</pre>Jordi Pujol2012-02-07T10:18:56Proposed git tree changes.
http://comments.gmane.org/gmane.linux.swsusp.devel/14196
<pre>Hi all.
I'm considering making some changes to the way I arrange the git trees,
partly in fulfillment of suggestions posted on this list already and
would like your input. Proposed changes are:
- Make one big git tree instead of separate ones for each branch
- For each vanilla kernel version, have a upstream and a tuxonice
branch, hence upstream-3.0, tuxonice-3.0, upstream-3.1, tuxonice-3.1,
upstream-head, tuxonice-head and so on
- Tags for tuxonice branches will be in the format
tuxonice-<tuxonice-version>-for-<upstream-version> so that there will be
no namespace difficulties
- At any time, only the 2 most recent upstream releases will get
TuxOnIce updates. This will reduce the amount of testing I need to do
before releases. Until now, I've only tended to drop old releases when
more recent changes make backporting too much effort.
If these changes sound good to people, I'll start implementing them.
Hopefully I'll then be able to fix up my long neglected scripts and get
regular updates and patches going again.
Regards,
Nigel
</pre>Nigel Cunningham2012-01-26T02:35:59Web Git down?
http://comments.gmane.org/gmane.linux.swsusp.devel/14195
<pre>Hello list,
I was wondering if the gitweb interface is down or not, or is it just my
browser of choice (luakit) screwing around?
Cheers,
Ignas A.
</pre>Ignas Anikevicius2012-01-10T01:32:34Web Git down?
http://comments.gmane.org/gmane.linux.swsusp.devel/14195
<pre>Hello list,
I was wondering if the gitweb interface is down or not, or is it just my
browser of choice (luakit) screwing around?
Cheers,
Ignas A.
</pre>Ignas Anikevicius2012-01-10T01:32:34First cut of catch up patch... Still frozen onrestore...
http://comments.gmane.org/gmane.linux.swsusp.devel/14185
<pre>Nigel, Merry Christmas,
Thanks for updating the git tree - I could use TOI once again, now on
3.2 kernels...
I keep reading that it works for most of people, however on EeePC with
i915 it is crashing 100% on restore, the last messages are:
Reading kernel & process data...
Atomic restore.
Doing atomic copy/restore.
I have tried on 2 different devices, it is 100% repeatable.
I tried from normal X-session, then from a single mode, then even from
single mode with nomodeset, without text-gui - can not be simpler than
that - yet it still crashes... Tried to disable all
no-[flusher_thread/pageset2/readahead/multithreded_io] - not much help...
Is there a trick to debug it?
Thanks, Woody
</pre>Woody Suwalski2011-12-30T21:12:22Search EngineSearch the mailing list at Gmanequery
http://search.gmane.org/?group=$group=gmane.linux.swsusp.devel