Hi Pelle,

Per Olofsson wrote:

> Second time I hibernated my system, it froze. Kernel error messages
> were printed on the console, I attach a photo of my display.

Thanks. My only hints are to try narrowing this down using hints
from Documentation/basic-pm-debugging.txt[1] and that it might be
possible to get a fuller log using netconsole[2].

Can you reproduce this without the i915 driver loaded?

Hope that helps,
Jonathan

[1] http://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
or the corresponding file in the kernel source or linux-doc-3.2
[2] http://www.kernel.org/doc/Documentation/networking/netconsole.txt



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120210211833.GK19216@burratino">http://lists.debian.org/20120210211833.GK19216@burratino

Hi Jonathan,

2012-02-10 22:18, Jonathan Nieder skrev:
> Per Olofsson wrote:
>
>> Second time I hibernated my system, it froze. Kernel error messages
>> were printed on the console, I attach a photo of my display.
>
> Thanks. My only hints are to try narrowing this down using hints
> from Documentation/basic-pm-debugging.txt[1] and that it might be
> possible to get a fuller log using netconsole[2].

Thanks for the hints! It is a bit time-consuming to debug because the
problem does not happen every time I hibernate. However, it does happen
often enough.

I will try the debug steps and report back the results. Since suspend to
RAM works fine, I'm guessing that it has something to do with writing
the image to disk. Perhaps ACPI is interacting badly with the SATA
driver or so.

I also tried updating my BIOS, but it didn't change anything.

> Can you reproduce this without the i915 driver loaded?

Not really. It seems that the error only happens when I have a lot of
processes loaded in memory. Running from the console does not seem to
trigger it. I guess I could try running X with vesa for a while, but I'd
rather not if I don't have to.

--
Pelle



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F5E2330.5060505@debian.org">http://lists.debian.org/4F5E2330.5060505@debian.org

Hi again,

2012-03-12 17:24, Per Olofsson skrev:
> Thanks for the hints! It is a bit time-consuming to debug because the
> problem does not happen every time I hibernate. However, it does happen
> often enough.
>
> I will try the debug steps and report back the results. Since suspend to
> RAM works fine, I'm guessing that it has something to do with writing
> the image to disk. Perhaps ACPI is interacting badly with the SATA
> driver or so.

I have now tried some debugging steps, but I can't get the system to
freeze with the debugging modes. It probably needs to actually try to
write the image to disk in order to hit the bug.

Here is the same bug in Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=785384

Perhaps, as you said, it has something to do with i915 after all. I will
dig further.

--
Pelle



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F5F72E5.6060806@dsv.su.se">http://lists.debian.org/4F5F72E5.6060806@dsv.su.se

Hi Pelle,

Per Olofsson wrote:

> I have now tried some debugging steps, but I can't get the system to
> freeze with the debugging modes.

Thanks for checking. Could you spell this out a little more for me?

Do you mean, for example, that

echo platform >/sys/power/disk
echo disk >/sys/power/state

doesn't hang?



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120316180051.GF28004@burratino">http://lists.debian.org/20120316180051.GF28004@burratino

Hi Jonathan,

2012-03-16 19:00, Jonathan Nieder skrev:
>> I have now tried some debugging steps, but I can't get the system to
>> freeze with the debugging modes.
>
> Thanks for checking. Could you spell this out a little more for me?
>
> Do you mean, for example, that
>
> echo platform >/sys/power/disk
> echo disk >/sys/power/state
>
> doesn't hang?

What I mean is that I can't get it to hang when I write different values
to /sys/power/pm_test, as suggested in basic-pm-debugging.txt. It only
hangs with the default value "none".

Also, it doesn't matter if I put platform or shutdown in
/sys/power/disk. It hangs anyway.

I have noted, however, that it seems to hang much less frequently if I
unload the Virtualbox modules. But I am not certain, and it does hang
anyway after a while.

I am in contact with Bojan Smojver who made some changes in the
hibernate code for 3.2. He has given me further debugging hints, but he
thinks that my error is due to memory corruption by i915.

--
Pelle



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F64A2BE.8070700@dsv.su.se">http://lists.debian.org/4F64A2BE.8070700@dsv.su.se

tags 659363 + moreinfo
quit

Per Olofsson wrote:

> I am in contact with Bojan Smojver who made some changes in the
> hibernate code for 3.2. He has given me further debugging hints, but he
> thinks that my error is due to memory corruption by i915.

Yes, I would want to rule out an i915 problem, too.

Thanks and hope that helps,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120319183958.GA14753@burratino">http://lists.debian.org/20120319183958.GA14753@burratino

2012-03-19 19:39, Jonathan Nieder skrev:
>> I am in contact with Bojan Smojver who made some changes in the
>> hibernate code for 3.2. He has given me further debugging hints, but he
>> thinks that my error is due to memory corruption by i915.
>
> Yes, I would want to rule out an i915 problem, too.

I have ruled it out now. The bug occurs even if I never load i915 and
the vbox* modules. It has to do with the size of the image written to disk.

For more details see:
https://bugzilla.redhat.com/show_bug.cgi?id=785384

--
Pelle



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F679384.5050704@dsv.su.se">http://lists.debian.org/4F679384.5050704@dsv.su.se

forwarded 659363 https://bugzilla.redhat.com/show_bug.cgi?id=785384
# regression
severity 659363 important
tags 659363 + upstream patch moreinfo
quit

Per Olofsson wrote:

> I have ruled it out now. The bug occurs even if I never load i915 and
> the vbox* modules. It has to do with the size of the image written to disk.
>
> For more details see:
> https://bugzilla.redhat.com/show_bug.cgi?id=785384

Thanks.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120319202602.GC21963@burratino">http://lists.debian.org/20120319202602.GC21963@burratino

It seems I am seeing the same bug too, on
linux-image-3.2.0-0.bpo.1-686-pae, 3.2.4-1~bpo60+1. However, I'm on an
nVidia nForce 570 chipset (AMD A64-x2), esp. using the sata_nv driver.

About half of the hibernate-disk cycles do work, the other half starts
writing the image to some point just normally, but after a few seconds
the disk writer gets extremely slow (around 1% per minute), and after
some more minutes, the kernel throws page allocation failures:

> [16095.943147] echo: page allocation failure: order:0, mode:0x20
> [16095.945176] kthreadd: page allocation failure: order:0, mode:0x20
> [16095.945180] Pid: 2, comm: kthreadd Not tainted 3.2.0-0.bpo.1-686-pae #1
> [16095.945182] Call Trace:
> [16095.945189] [<c10a1284>] ? warn_alloc_failed+0xc0/0xd1
> [16095.945192] [<c10a236b>] ? __alloc_pages_nodemask+0x55e/0x5cb
> [16095.945195] [<c10a9959>] ? shrink_zone+0x440/0x44c
> [16095.945199] [<c10ca0aa>] ? ____cache_alloc+0x25d/0x406
> [16095.945201] [<c10ca343>] ? kmem_cache_alloc_trace+0x3c/0x7b
> [16095.945204] [<c10f019d>] ? __bdi_start_writeback+0x23/0x90
> [16095.945206] [<c10f0257>] ? wakeup_flusher_threads+0x4d/0x64
> [16095.945208] [<c10a9f52>] ? do_try_to_free_pages+0x2d4/0x403
> [16095.945210] [<c10aa28a>] ? try_to_free_pages+0x9f/0xcd
> [16095.945213] [<c10a21d0>] ? __alloc_pages_nodemask+0x3c3/0x5cb
> [16095.945217] [<c103a29b>] ? copy_process+0xc5/0xdf1
> [16095.945220] [<c100baa9>] ? __switch_to+0x6f/0xe2
> [16095.945223] [<c103b157>] ? do_fork+0xbb/0x1d0
> [16095.945226] [<c10514fc>] ? kthread_worker_fn+0x114/0x114
> [16095.945229] [<c101186f>] ? kernel_thread+0x7b/0x83
> [16095.945231] [<c10514fc>] ? kthread_worker_fn+0x114/0x114
> [16095.945234] [<c12d2c78>] ? common_interrupt+0x38/0x38
> [16095.945237] [<c105160e>] ? kthreadd+0xaa/0xdc
> [16095.945239] [<c1051564>] ? kthread+0x68/0x68
> [16095.945241] [<c12d2c7e>] ? kernel_thread_helper+0x6/0x10
> [16095.945242] Mem-Info:
> [16095.945243] DMA per-cpu:
> [16095.945245] CPU 0: hi: 0, btch: 1 usd: 0
> [16095.945246] CPU 1: hi: 0, btch: 1 usd: 0
> [16095.945247] Normal per-cpu:
> [16095.945249] CPU 0: hi: 186, btch: 31 usd: 21
> [16095.945250] CPU 1: hi: 186, btch: 31 usd: 1
> [16095.945251] HighMem per-cpu:
> [16095.945253] CPU 0: hi: 186, btch: 31 usd: 0
> [16095.945254] CPU 1: hi: 186, btch: 31 usd: 0
> [16095.945258] active_anon:30380 inactive_anon:864 isolated_anon:0
> [16095.945259] active_file:112988 inactive_file:128220 isolated_file:0
> [16095.945259] unevictable:0 dirty:0 writeback:0 unstable:0
> [16095.945260] free:226695 slab_reclaimable:11024 slab_unreclaimable:15456
> [16095.945261] mapped:13381 shmem:931 pagetables:959 bounce:0
> [16095.945266] DMA free:16kB min:784kB low:980kB high:1176kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15792kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:4220kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [16095.945270] lowmem_reserve[]: 0 867 4039 4039
> [16095.945275] Normal free:0kB min:44112kB low:55140kB high:66168kB active_anon:0kB inactive_anon:0kB active_file:1148kB inactive_file:1148kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:887976kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:44096kB slab_unreclaimable:57604kB kernel_stack:2000kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:220064075 all_unreclaimable? no
> [16095.945279] lowmem_reserve[]: 0 0 25378 25378
> [16095.945285] HighMem free:906764kB min:512kB low:40856kB high:81204kB active_anon:121520kB inactive_anon:3456kB active_file:450804kB inactive_file:511732kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3248468kB mlocked:0kB dirty:0kB writeback:0kB mapped:53520kB shmem:3724kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:3836kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
> [16095.945288] lowmem_reserve[]: 0 0 0 0
> [16095.945290] DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [16095.945295] Normal: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> [16095.945299] HighMem: 22355*4kB 16232*8kB 6812*16kB 2330*32kB 612*64kB 405*128kB 133*256kB 24*512kB 12*1024kB 7*2048kB 83*4096kB = 906764kB
> [16095.945305] 242139 total pagecache pages
> [16095.945306] 0 pages in swap cache
> [16095.945307] Swap cache stats: add 0, delete 0, find 0/0
> [16095.945308] Free swap = 3715540kB
> [16095.945309] Total swap = 4194300kB
> [16095.948007] 1318896 pages RAM
> [16095.948007] 1091074 pages HighMem
> [16095.948007] 282321 pages reserved
> [16095.948007] 156789 pages shared
> [16095.948007] 702774 pages non-shared

More netconsole output attached.

The output matches the screenshot that was posted to the redhat bug
tracker on 2012-03-28, so it looks like the same issue: Running out of
memory, maybe because hibernate buffers eated it.


Cheers,

Udo

Hi Udo,

Udo Richter wrote:

> It seems I am seeing the same bug too

Please test the attached patch[2], for example by following the following
instructions:

0. Prerequisites.

apt-get install git build-essential

1. Get a copy of the kernel history if you don't already have it.

git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

2. Fetch point releases.

cd linux
git remote add -f stable
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

3. Configure, build, and test.

cp /boot/config-$(uname -r) .config; # current configuration
make localmodconfig; # optional: minimize configuration
make deb-pkg; # optionally with -j<num> for parallel build
dpkg -i ../<name of package>; # as root
reboot
... test test test ...

4. Hopefully it reproduces the bug. Try the patch:

git am -3sc <path to patch>
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>; # as root
reboot
... test test test ...

An alternative method for testing patches is described at [1].

Hope that helps,
Jonathan

[1] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official
or the corresponding page from the debian-kernel-handbook package
[2] from http://thread.gmane.org/gmane.linux.kernel/1273425