Re: Activity!

Hello Nigel,

Am 16.12.2011 10:39, schrieb Nigel Cunningham:
> Hi.
>
> On 16/12/11 20:26, Harald Judt wrote:
>> Am 16.12.2011 06:15, schrieb Nigel Cunningham:
>>> Hi.
>>>
>>> On 15/12/11 09:23, Harald Judt wrote:
>>>> Here are some drawbacks of tuxonice:
>>>>
>>>> * Cannot apply Con Koliva's bfs patch, they break compression. This
>>>> really sucks. I've applied bfs and bfq patches to mainline head, and
>>>> they are quite an improvement, especially on the laptop. The only
>>>> solution would be to not use image compression which is not an option.
>>>
>>> I'll see what I can do about that.
>>
>> For your convenience, I've already gathered the following information:
>>
>> It seems the following commit which causes the problem:
>> c2a116d1236344e6ce2556bbc674489ee5d2f703: Start/stop I/O worker threads
>> outside of freezer
>>
>> However, without it I think tuxonice doesn't work reliably.
>
> Yeah - I'm not going to revert that change at this stage - I don't see
> anything wrong with it itself.
>
>> I've adapted BFS-0.415 to compile with 3.2-rc5, there was just a small
>> change necessary because some variable was not used anymore, which
>> causes a compilation error. I'll attach it as a bzip and hope the mail
>> gets through. Alternatively, you can find the original patch for 3.1
>> here: http://ck-hack.blogspot.com. Older kernels with the patch applied
>> show the same problem.
>
> Thanks.

I hope you enjoy(ed) Christmas.

I still have the problem with current tuxonice git. Now I found that as 
soon as I change both ProcSetting no_multithreaded_io and 
no_flusher_thread from 0 to 1, Tuxonice resumes successfully even with 
the BFS patch compiled in. This makes sense because of the git bisect 
from above. Hibernating and resuming is a bit slower now, but I can live 
with that.

Additionally, these problems do not occur on the thinkpad t400, maybe 
because I forgot to set "ProcSetting late_cpu_hotplug 1". Besides that I 
have applied additional patches and got many of the following call 
traces there which may or may not be related (actually these additional 
patches may very well be causing these call traces):
PM: restore of devices complete after 2516.744 msecs
caller is toi_compress_read_page+0x26/0x1c7
Pid: 13898, comm: ktoi_io/1 Tainted: G           O 3.2.0-rc6+ #5
Call Trace:
  [<ffffffff812086b2>] debug_smp_processor_id+0xc2/0xdc
  [<ffffffff81060e9b>] toi_compress_read_page+0x26/0x1c7
  [<ffffffff8102867c>] ? sub_preempt_count+0x8f/0xa2
  [<ffffffff81468cb0>] ? _raw_spin_unlock_irqrestore+0x27/0x32
  [<ffffffff8105af9e>] worker_rw_loop+0x2d2/0xa45
  [<ffffffff81042c0b>] ? add_wait_queue+0x44/0x44
  [<ffffffff8105accc>] ? fs_info_load_and_check_one+0x22d/0x22d
  [<ffffffff810425ef>] kthread+0x7f/0x87
  [<ffffffff8146a714>] kernel_thread_helper+0x4/0x10
  [<ffffffff81042570>] ? kthread_worker_fn+0x141/0x141
  [<ffffffff8146a710>] ? gs_change+0xb/0xb
BUG: using smp_processor_id() in preemptible [00000000] code: 
ktoi_io/1/13898
caller is worker_rw_loop+0x41f/0xa45
Pid: 13898, comm: ktoi_io/1 Tainted: G           O 3.2.0-rc6+ #5
Call Trace:
  [<ffffffff812086b2>] debug_smp_processor_id+0xc2/0xdc
  [<ffffffff8105b0eb>] worker_rw_loop+0x41f/0xa45
  [<ffffffff81042c0b>] ? add_wait_queue+0x44/0x44
  [<ffffffff8105accc>] ? fs_info_load_and_check_one+0x22d/0x22d
  [<ffffffff810425ef>] kthread+0x7f/0x87
  [<ffffffff8146a714>] kernel_thread_helper+0x4/0x10
  [<ffffffff81042570>] ? kthread_worker_fn+0x141/0x141
  [<ffffffff8146a710>] ? gs_change+0xb/0xb
[... many of these follow here ...]
...20%...40%...60%...80%
Waited for i/o due to readahead not ready 575 times.
Restarting all filesystems ...
Restarting tasks ...

Maybe this gives any clue?

Regards,
Harald

-- 
`Experience is the best teacher.'