public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Romit Dasgupta <romit@ti.com>
Cc: linux-pm <linux-pm@lists.linux-foundation.org>
Subject: Re: Memory allocations in .suspend became very unreliable
Date: Fri, 15 Jan 2010 12:34:08 +0200	[thread overview]
Message-ID: <1263551648.4581.2.camel@maxim-laptop> (raw)
In-Reply-To: <4B50425B.4050605@ti.com>

On Fri, 2010-01-15 at 15:54 +0530, Romit Dasgupta wrote: 
> Maxim Levitsky wrote:
> > Hi,
> > 
> > I know that this is very controversial, because here I want to describe
> > a problem in a proprietary driver that happens now in 2.6.33-rc3
> > I am taking about nvidia driver.
> > 
> > Some time ago I did very long hibernate test and found no errors after
> > more that 200 cycles.
> > 
> > Now I update to 2.6.33 and notice that system will hand when nvidia
> > driver allocates memory is their .suspend functions.
> > This could fail in 2.6.32 if I would run many memory hungry
> > applications, but now this happens with most of memory free.
> > 
> > I added some printks to function used to allocate memory in nvidia
> > driver and found out that contrary to my belief, they don't allocate
> > much memory there.
> Hello Maxim,
>                Do you hit the error early if you reduce your memory (by passing
> 'mem=  ' bootargs)? The hibernation routine allocates memory for creating its
> own bitmaps, so I was wondering if it is really a memory issue or bug in the
> nvidia driver.

I know that kmalloc is to blame here, here is the backtrace:

<6>[ 3775.469811] pm-hibernate  D 0000000000000000     0  6890   5630 0x00000000
<4>[ 3775.469811]  ffff880037c7b4f8 0000000000000046 0000000000000000 ffffffff812db456
<4>[ 3775.469811]  ffff880037c7b438 0000000000000000 00000001000525fc ffff880004214e58
<4>[ 3775.469811]  ffff88000420f008 ffff880037c7a000 ffff88006fbec1f8 ffff880037c7bfd8
<4>[ 3775.469811] Call Trace:
<4>[ 3775.469811]  [<ffffffff812db456>] ? scsi_request_fn+0xb6/0x400
<4>[ 3775.469811]  [<ffffffff8122fc69>] ? __up_read+0x99/0xc0
<4>[ 3775.469811]  [<ffffffff810c7790>] ? sync_page+0x0/0x60
<4>[ 3775.469811]  [<ffffffff81400923>] io_schedule+0x73/0xc0
<4>[ 3775.469811]  [<ffffffff810c77d5>] sync_page+0x45/0x60
<4>[ 3775.469811]  [<ffffffff814010bf>] __wait_on_bit+0x5f/0x90
<4>[ 3775.469811]  [<ffffffff810c7a23>] wait_on_page_bit+0x73/0x80
<4>[ 3775.469811]  [<ffffffff81065e10>] ? wake_bit_function+0x0/0x40
<4>[ 3775.469811]  [<ffffffff810d40dc>] shrink_page_list+0x18c/0x600
<4>[ 3775.469811]  [<ffffffff81078c4d>] ? trace_hardirqs_on+0xd/0x10
<4>[ 3775.469811]  [<ffffffff81403c52>] ? _raw_spin_unlock_irqrestore+0x42/0x80
<4>[ 3775.469811]  [<ffffffff81065f67>] ? finish_wait+0x67/0x90
<4>[ 3775.469811]  [<ffffffff810d2d0a>] ? isolate_pages_global+0x15a/0x230
<4>[ 3775.469811]  [<ffffffff810df6fd>] ? congestion_wait+0x7d/0x90
<4>[ 3775.469811]  [<ffffffff81065dd0>] ? autoremove_wake_function+0x0/0x40
<4>[ 3775.469811]  [<ffffffff810d4bd9>] shrink_inactive_list+0x689/0x710
<4>[ 3775.469811]  [<ffffffff8122fbf3>] ? __up_read+0x23/0xc0
<4>[ 3775.469811]  [<ffffffff810d4edf>] shrink_zone+0x27f/0x490
<4>[ 3775.469811]  [<ffffffff810d525a>] ? shrink_slab+0x16a/0x1a0
<4>[ 3775.469811]  [<ffffffff810d5dbf>] do_try_to_free_pages+0x1bf/0x310
<4>[ 3775.469811]  [<ffffffff810d6040>] try_to_free_pages+0x70/0x80
<4>[ 3775.469811]  [<ffffffff810d2bb0>] ? isolate_pages_global+0x0/0x230
<4>[ 3775.469811]  [<ffffffff810ce480>] __alloc_pages_nodemask+0x3e0/0x740
<4>[ 3775.469811]  [<ffffffff810ce7f7>] __get_free_pages+0x17/0x60
<4>[ 3775.469811]  [<ffffffff810ff759>] __kmalloc+0x1d9/0x270
<4>[ 3775.469811]  [<ffffffffa05a1ff0>] os_alloc_mem+0xa0/0xf0 [nvidia]
<4>[ 3775.469811]  [<ffffffffa04b70e4>] _nv005422rm+0x12/0x21 [nvidia]
<4>[ 3775.469811]  [<ffffffffa029bc39>] ? _nv014333rm+0xac8/0xc0a [nvidia]
<4>[ 3775.469811]  [<ffffffffa04f18e6>] ? _nv012492rm+0x12e/0x217 [nvidia]
<4>[ 3775.469811]  [<ffffffffa04b9e0e>] ? _nv003813rm+0x176/0x372 [nvidia]
<4>[ 3775.469811]  [<ffffffffa04bf115>] ? rm_power_management+0x170/0x209 [nvidia]
<4>[ 3775.469811]  [<ffffffffa059bb9c>] ? nv_power_management+0x1fc/0x250 [nvidia]
<4>[ 3775.469811]  [<ffffffffa059bcbc>] ? nv_kern_suspend+0x2c/0xb0 [nvidia]
<4>[ 3775.469811]  [<ffffffff81246856>] ? pci_legacy_suspend+0x46/0xe0
<4>[ 3775.469811]  [<ffffffff812ce526>] ? dpm_suspend_start+0x446/0x4b0
<4>[ 3775.469811]  [<ffffffff8124712d>] ? pci_pm_freeze+0x9d/0xb0
<4>[ 3775.469811]  [<ffffffff812cdf6e>] ? pm_op+0x14e/0x1c0
<4>[ 3775.469811]  [<ffffffff812ce446>] ? dpm_suspend_start+0x366/0x4b0
<4>[ 3775.469811]  [<ffffffff8108bb1f>] ? hibernation_snapshot+0x7f/0x280
<4>[ 3775.469811]  [<ffffffff8108be1d>] ? hibernate+0xfd/0x200
<4>[ 3775.469811]  [<ffffffff8108a70c>] ? state_store+0xec/0x100
<4>[ 3775.469811]  [<ffffffff811710b7>] ? sysfs_get_active_two+0x27/0x60
<4>[ 3775.469811]  [<ffffffff8122ba27>] ? kobj_attr_store+0x17/0x20
<4>[ 3775.469811]  [<ffffffff8116f3c6>] ? sysfs_write_file+0xe6/0x170
<4>[ 3775.469811]  [<ffffffff81107da8>] ? vfs_write+0xb8/0x1a0
<4>[ 3775.469811]  [<ffffffff814030e5>] ? lockdep_sys_exit_thunk+0x35/0x67
<4>[ 3775.469811]  [<ffffffff81107f81>] ? sys_write+0x51/0x90
<4>[ 3775.469811]  [<ffffffff8100305b>] ? system_call_fastpath+0x16/0x1b



Best regards,
Maxim Levitsky

  reply	other threads:[~2010-01-15 10:34 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-15  9:59 Memory allocations in .suspend became very unreliable Maxim Levitsky
2010-01-15 10:24 ` Romit Dasgupta
2010-01-15 10:34   ` Maxim Levitsky [this message]
2010-01-15 22:03 ` Rafael J. Wysocki
2010-01-15 23:56   ` Maxim Levitsky
2010-01-16  0:57     ` Rafael J. Wysocki
2010-01-16 21:44       ` Maxim Levitsky
2010-01-16 22:17         ` Rafael J. Wysocki
2010-01-17  0:38           ` [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: Memory allocations in .suspend became very unreliable) Rafael J. Wysocki
     [not found]           ` <201001170138.37283.rjw@sisk.pl>
2010-01-17  1:24             ` Oliver Neukum
     [not found]             ` <201001170224.36267.oliver@neukum.org>
2010-01-17 13:27               ` Rafael J. Wysocki
     [not found]               ` <201001171427.27954.rjw@sisk.pl>
2010-01-17 13:36                 ` Rafael J. Wysocki
2010-01-17 18:58                 ` Benjamin Herrenschmidt
     [not found]                 ` <1263754684.724.444.camel@pasglop>
2010-01-17 23:00                   ` Rafael J. Wysocki
     [not found]                   ` <201001180000.23376.rjw@sisk.pl>
2010-01-18  7:53                     ` Oliver Neukum
     [not found]                     ` <201001180853.31446.oliver@neukum.org>
2010-01-18 16:17                       ` Alan Stern
2010-01-18 20:56                       ` Rafael J. Wysocki
2010-01-18 21:55                     ` Benjamin Herrenschmidt
     [not found]                     ` <1263851757.724.500.camel@pasglop>
2010-01-18 23:33                       ` Rafael J. Wysocki
2010-01-17 13:55             ` Rafael J. Wysocki
2010-01-18  2:16             ` KOSAKI Motohiro
     [not found]             ` <201001171455.55909.rjw@sisk.pl>
2010-01-17 16:21               ` Minchan Kim
     [not found]               ` <1263745267.2162.42.camel@barrios-desktop>
2010-01-17 16:23                 ` Minchan Kim
2010-01-18  0:25                 ` Rafael J. Wysocki
     [not found]                 ` <201001180125.59413.rjw@sisk.pl>
2010-01-18  2:20                   ` KOSAKI Motohiro
     [not found]                   ` <20100118111703.AE36.A69D9226@jp.fujitsu.com>
2010-01-18 21:06                     ` Rafael J. Wysocki
     [not found]                     ` <201001182206.36365.rjw@sisk.pl>
2010-01-19  9:15                       ` Oliver Neukum
     [not found]                       ` <201001191015.00470.oliver@neukum.org>
2010-01-19 20:34                         ` Rafael J. Wysocki
2010-01-18 17:00               ` Oliver Neukum
     [not found]               ` <201001181800.38574.oliver@neukum.org>
2010-01-18 20:41                 ` Rafael J. Wysocki
     [not found]                 ` <201001182141.49907.rjw@sisk.pl>
2010-01-19  9:25                   ` Oliver Neukum
     [not found]                   ` <201001191025.37579.oliver@neukum.org>
2010-01-19 20:37                     ` Rafael J. Wysocki
     [not found]                     ` <201001192137.35232.rjw@sisk.pl>
2010-01-20 14:05                       ` Oliver Neukum
     [not found]                       ` <201001201505.41167.oliver@neukum.org>
2010-01-20 21:13                         ` Rafael J. Wysocki
     [not found]             ` <20100118110324.AE30.A69D9226@jp.fujitsu.com>
2010-01-18 20:55               ` Rafael J. Wysocki
     [not found]               ` <201001182155.09727.rjw@sisk.pl>
2010-01-19  1:19                 ` KOSAKI Motohiro
     [not found]                 ` <20100119101101.5F2E.A69D9226@jp.fujitsu.com>
2010-01-19  3:19                   ` Benjamin Herrenschmidt
     [not found]                   ` <1263871194.724.520.camel@pasglop>
2010-01-19  9:04                     ` Bastien ROUCARIES
2010-01-19 20:47                     ` Rafael J. Wysocki
     [not found]                     ` <195c7a901001190104x164381f9v4a58d1fce70b17b6@mail.gmail.com>
2010-01-19 23:17                       ` Benjamin Herrenschmidt
     [not found]                       ` <1263943071.724.540.camel@pasglop>
2010-01-20 11:31                         ` Oliver Neukum
     [not found]                         ` <201001201231.17540.oliver@neukum.org>
2010-01-20 21:11                           ` Benjamin Herrenschmidt
2010-01-20 21:12                           ` Rafael J. Wysocki
     [not found]                     ` <201001192147.58185.rjw@sisk.pl>
2010-01-20  0:33                       ` KOSAKI Motohiro
     [not found]                       ` <20100120085053.405A.A69D9226@jp.fujitsu.com>
2010-01-20 21:21                         ` Rafael J. Wysocki
2010-01-20 21:21                         ` Rafael J. Wysocki
     [not found]                         ` <201001202221.34804.rjw@sisk.pl>
2010-01-21  0:47                           ` KOSAKI Motohiro
     [not found]                           ` <20100121091023.3775.A69D9226@jp.fujitsu.com>
2010-01-21 20:21                             ` Rafael J. Wysocki
     [not found]                             ` <201001212121.50272.rjw@sisk.pl>
2010-01-21 20:42                               ` Nigel Cunningham
     [not found]                               ` <4B58BC31.1040406@crca.org.au>
2010-01-21 21:38                                 ` Rafael J. Wysocki
2010-01-22  1:31                               ` KOSAKI Motohiro
     [not found]                               ` <20100122100155.6C03.A69D9226@jp.fujitsu.com>
2010-01-22  1:42                                 ` KOSAKI Motohiro
     [not found]                                 ` <20100122103830.6C09.A69D9226@jp.fujitsu.com>
2010-01-22 10:11                                   ` Maxim Levitsky
     [not found]                                   ` <1264155067.15930.4.camel@maxim-laptop>
2010-01-22 21:19                                     ` [Update][PATCH] MM / PM: Force GFP_NOIO during suspend/hibernation and resume Rafael J. Wysocki
     [not found]                                     ` <201001222219.15958.rjw@sisk.pl>
2010-01-23  9:29                                       ` Maxim Levitsky
     [not found]                                       ` <1264238962.16031.4.camel@maxim-laptop>
2010-01-25 21:49                                         ` Rafael J. Wysocki
     [not found]                                         ` <201001252249.18690.rjw@sisk.pl>
2010-01-25 21:52                                           ` Alexey Starikovskiy
     [not found]                                           ` <4B5E1281.7090700@suse.de>
2010-01-30 18:56                                             ` Rafael J. Wysocki
     [not found]                                             ` <201001301956.41372.rjw@sisk.pl>
2010-01-30 20:42                                               ` Maxim Levitsky
     [not found]                                               ` <1264884140.13861.7.camel@maxim-laptop>
2010-01-30 20:53                                                 ` Rafael J. Wysocki
2010-01-22 20:58                                 ` [RFC][PATCH] PM: Force GFP_NOIO during suspend/resume (was: Re: Memory allocations in .suspend became very unreliable) Rafael J. Wysocki
2010-01-30 15:46             ` Maxim Levitsky
     [not found]             ` <1264866419.27933.0.camel@maxim-laptop>
2010-01-30 18:47               ` Rafael J. Wysocki
     [not found]               ` <201001301947.10453.rjw@sisk.pl>
2010-01-30 20:37                 ` Maxim Levitsky
     [not found]                 ` <1264883863.13861.3.camel@maxim-laptop>
2010-02-01 19:51                   ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1263551648.4581.2.camel@maxim-laptop \
    --to=maximlevitsky@gmail.com \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=romit@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox