[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#589558: marked as done (Miscalculation of used/available pages on kernel suspend to disk (not suspending))



Your message dated Sun, 2 Dec 2012 13:39:13 -0800
with message-id <20121202213913.GA16181@elie.Belkin>
and subject line Re: Miscalculation of used/available pages on kernel suspend to disk (not suspending)
has caused the Debian Bug report #589558,
regarding Miscalculation of used/available pages on kernel suspend to disk (not  suspending)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
589558: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589558
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: linux-image-2.6.32-5-686
Version: 2.6.32-17
Severity: important

I have debian unstable installed on a laptop Dell Inspiron 600m,
with pentium M processor at 1.6 GHz:

% cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1600MHz
stepping        : 5
cpu MHz         : 1600.000
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov
clflush dts acpi mmx fxsr sse sse2 tm pbe up bts est tm2
bogomips        : 3189.09
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:

The laptop includes 512 MB of RAM, and a partition with 2 GB of swap:

% cat /proc/meminfo
MemTotal:         514432 kB
MemFree:          100192 kB
Buffers:           21396 kB
Cached:           152088 kB
SwapCached:            0 kB
Active:           240888 kB
Inactive:         141424 kB
Active(anon):     162184 kB
Inactive(anon):    47256 kB
Active(file):      78704 kB
Inactive(file):    94168 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         514432 kB
LowFree:          100192 kB
SwapTotal:       2096408 kB
SwapFree:        2096396 kB
Dirty:                 4 kB
Writeback:             0 kB
AnonPages:        208828 kB
Mapped:            40536 kB
Shmem:               612 kB
Slab:              10976 kB
SReclaimable:       4584 kB
SUnreclaim:         6392 kB
KernelStack:         984 kB
PageTables:         1464 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2353624 kB
Committed_AS:     362324 kB
VmallocTotal:     504128 kB
VmallocUsed:       18188 kB
VmallocChunk:     473956 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       4096 kB
DirectMap4k:      290488 kB
DirectMap4M:      233472 kB

A brief from the meminfo:

MemTotal:         514432 kB
SwapTotal:       2096408 kB

Most of the time when trying to perform a kernel suspend to disk,
whether by using "acpitool -S", which is my preferred method, or
by directly writing "disk" into "/sys/power/state", the suspend is
attempted, but it fails and the machine returns to state priot to
attempt...

When looking at dmesg:

[   90.737713] Freezing user space processes ... (elapsed 0.00 seconds) done.
[   90.752182] Freezing remaining freezable tasks ... (elapsed 0.00
seconds) done.
[   90.766427] PM: Preallocating image memory... done (allocated 61556 pages)
[   90.817030] PM: Allocated 246224 kbytes in 0.03 seconds (8207.46 MB/s)
[   90.831363] Suspending console(s) (use no_console_suspend to debug)
[   90.847537] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   90.849254] parport_pc 00:0c: disabled
[   90.850417] serial 00:0b: disabled
[   90.972175] ipw2100 0000:02:03.0: PCI INT A disabled
[   92.656557] tg3 0000:02:00.0: PME# enabled
[   92.656568] pci 0000:00:1e.0: wake-up capability enabled by ACPI
[   92.779840] Intel ICH Modem 0000:00:1f.6: PCI INT B disabled
[   92.792231] Intel ICH 0000:00:1f.5: PCI INT B disabled
[   92.792380] ata_piix 0000:00:1f.1: PCI INT A disabled
[   92.795306] ACPI: Preparing to enter system sleep state S4
[   92.795583] PM: Saving platform NVS memory
[   92.795672] Disabling non-boot CPUs ...
[   92.795783] PM: Creating hibernation image:
[   92.796017] PM: Need to copy 66237 pages
[   92.796017] PM: Normal pages needed: 66237 + 1024, available pages: 64647
[   92.796017] PM: Not enough free memory
[   92.796017] PM: Error -12 creating hibernation image
[   92.796716] ACPI: Waking up from system sleep state S4

The important part of the dmesg section above is:

[   92.796017] PM: Need to copy 66237 pages
[   92.796017] PM: Normal pages needed: 66237 + 1024, available pages: 64647
[   92.796017] PM: Not enough free memory
[   92.796017] PM: Error -12 creating hibernation image

According to the kernel, there's a need of 67261 pages, when there are
available only 64647.  This is pretty weird, given that RAM size is
only 512 MB, while swap partition is 2 GB, 4 times bigger, so there should
be no issue.

This kernel suspend to disk has always worked for me on this laptop, under
debian unstable, and under other distros, like arch gnu/linux.  I stopped
using debian for a while and then recently installed debian unstable again,
which came with linux-image-2.6.32-5-686, and since then it hasn't worked.

There's an exception...  Prior to current version (2.6.32-17) there was one
which after which current one came after upgrade, which seemde to have fixed
the issue, but as soon as I performed an upgrade and got current one, the
issue cam back again.  So there was a particular version which I'm not sure
which one it is (perhaps previous to current one) which was issue free, but
current one, and previous to that I mentioned, all exposed the same problem.

To mitigate the issue, I do "swapoff -a && swapon -a" prior to suspending to
disk, and that doesn't seem to help a bit.  I've also set a swappiness of 10
(vm.swappiness=10 under /etc/sysctl.d/swappiness.conf) so that I try keeping
the swap area as unused as possible, and that hadn't helped much either.

I think the problem might be some configuration inhibiting the proper
calculation of pages...  As a side note, when I was using arch, with kernel
verison from 2.6.32.* to 2.6.34.*, I didn't have any problem suspending to
disk.  Also, I'm using same kernel suspend to disk on a amd64 laptop, and
on 2 non laptop old boxes, and on them the method works OK, so it might be
some configuration specific to this laptop?

-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-17) (ben@decadent.org.uk)
(gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Sun Jul 11 02:12:03 UTC
2010

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-5-686
root=UUID=b093a899-8278-406a-8698-343dbfdfca4b ro resume=/dev/sda5

-- System Information:
Debian Release: unstable/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

% uname -a
Linux m0 2.6.32-5-686 #1 SMP Sun Jul 11 02:12:03 UTC 2010 i686 GNU/Linux

Thanks,

-- 
Javier.



--- End Message ---
--- Begin Message ---
Jonathan Nieder wrote:
> Javier Vasquez wrote:

>> I don't have access to the laptop.  I hoped I could set my hands on it,
>> but I haven't...
>>
>> So, if later on I face the same problems, and you close this one, I'll
>> file a different one, :-)  BTW, if I recall correctly setting to 0
>> /sys/power/image_size helped prevent the issue...
>
> Thanks, Javier.  Maybe that hint will ring a bell for someone. :)
> Otherwise, we'll probably close this in a month or so and hope it gets
> reported again.

Closing.  Sorry we didn't take care of this in time.

--- End Message ---

Reply to: