* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Ari Savolainen @ 2011-11-22 5:27 UTC (permalink / raw)
To: Linus Torvalds, Rafael J. Wysocki
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <CA+55aFyceMKgS-YRv=r=FrHQ1P9=z7=2PC5gvZcCHoYKnzn_Aw@mail.gmail.com>
2011/11/22 Linus Torvalds <torvalds@linux-foundation.org>:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> Subject : lockdep warning after aa6afca5bcab: "proc: fix races against execve() of /proc/PID/fd**"
>> Submitter : Ari Savolainen <ari.m.savolainen@gmail.com>
>> Date : 2011-11-08 3:47
>> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw@mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
>
> Commit aa6afca5bcab was reverted by commit 5e442a493fc5, so this one
> is presumably stale.
>
> Linus
Yes, this went away after the reversion.
Ari
^ permalink raw reply
* Re: [PATCHSET] cgroup: stable threadgroup during attach & subsys methods consolidation
From: Li Zefan @ 2011-11-22 2:27 UTC (permalink / raw)
To: Tejun Heo
Cc: akpm, fweisbec, containers, linux-kernel, oleg, linux-pm, paul,
kamezawa.hiroyu
In-Reply-To: <20111121220719.GP25776@google.com>
Tejun Heo wrote:
> On Tue, Nov 01, 2011 at 04:46:23PM -0700, Tejun Heo wrote:
>> This patchset is combination of the following two patchsets.
>>
>> [1] cgroup: extend threadgroup locking
>> [2] cgroup: introduce cgroup_taskset and consolidate subsys methods, take#2
>
> Li, do you agree with the proposed patches? If so, I'll wait for
> Frederic's response, repost updated series and merge it into the
> cgroup tree.
>
I remember I've acked both patchsets in your earlier post. :)
--
Li Zefan
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Andy Lutomirski @ 2011-11-21 22:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <CA+55aFwAELQieN=qR7Gz_MT5rHPp90H10uTMS+DOJjefk7q3ng@mail.gmail.com>
On Mon, Nov 21, 2011 at 2:11 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> Subject : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
>> Submitter : Nix <nix@esperi.org.uk>
>> Date : 2011-11-14 0:40
>> Message-ID : 8762inleno.fsf@spindle.srvr.nix
>> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
>
> So this should be fixed by commit 2b666859ec32 ("x86: Default to
> vsyscall=native for now"), since we disabled the vsyscall emulation
> because it broken UML too.
I don't think so. I think the issue is that the chromium sandbox is
trying to use getcpu, time, or gettimeofday from seccomp mode and the
kernel is (IMO correctly) sending it SIGKILL. Nix can trigger the bug
in vsyscall=native mode, so it's not the emulation. (If it's
gettimeofday, then it's definitely not a regression. vgettimeofday
would SIGKILL in seccomp mode with any timing source other than rdtsc
or hpet even on old kernels.)
I sent a patch to show which syscall is causing SIGKILL and haven't
heard back. Meanwhile, I'm downloading the 1.1GB (!) tarball to see
if I can reproduce it here. Fedora's build didn't trigger it for me,
probably because the sandbox was disabled.
To try to reduce the incidence of this stuff in the future, and to
make vsyscall=none and UML more useful, I filed this bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=13425
--Andy
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Alex Deucher @ 2011-11-21 22:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux SCSI List, Florian Mickler, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
In-Reply-To: <201111212249.31196.rjw@sisk.pl>
On Mon, Nov 21, 2011 at 4:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message contains a list of some regressions from 3.0 and 3.1
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 3.0 and 3.1, please let us
> know either and we'll add them to the list. Also, please let us know if any of
> the entries below are invalid.
>
> The entries below are simplified and the statistics are not present due to the
> continuing Bugzilla outage.
>
> Subject : iwlagn is getting very shaky
> Submitter : Norbert Preining <preining@logic.at>
> Date : 2011-10-19 6:01
> Message-ID : 20111019060108.GA11588@gamma.logic.tuwien.ac.at
> References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2
>
> Subject : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
> Submitter : Edward Donovan <edward.donovan@numble.net>
> Date : 2011-10-19 22:09
> Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
>
> Subject : Regression in 3.1 causes Xen to use wrong idle routine
> Submitter : Stefan Bader <stefan.bader@canonical.com>
> Date : 2011-10-26 10:24
> Message-ID : 4EA7DFD1.9060608@canonical.com
> References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
>
> Subject : 3.1+ iwlwifi lockup
> Submitter : Dave Jones <davej@redhat.com>
> Date : 2011-10-31 14:34
> Message-ID : 20111031143408.GA17152@redhat.com
> References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
>
> Subject : hugetlb oops on 3.1.0-rc8-devel
> Submitter : Andy Lutomirski <luto@amacapital.net>
> Date : 2011-11-01 22:20
> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
>
> Subject : Simultaneous cat and external keyboard input causing kernel panic
> Submitter : Timo Jyrinki <timo.jyrinki@gmail.com>
> Date : 2011-11-03 12:14
> Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2
>
> Subject : Linus GIT - INFO: possible circular locking dependency detected
> Submitter : Miles Lane <miles.lane@gmail.com>
> Date : 2011-11-03 15:57
> Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
>
> Subject : lockdep warning after aa6afca5bcab: "proc: fix races against execve() of /proc/PID/fd**"
> Submitter : Ari Savolainen <ari.m.savolainen@gmail.com>
> Date : 2011-11-08 3:47
> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
>
> Subject : DMA-API check_sync errors with 3.2
> Submitter : Josh Boyer <jwboyer@redhat.com>
> Date : 2011-11-08 17:31
> Message-ID : 20111108173153.GE14216@zod.bos.redhat.com
> References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2
>
> Subject : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or suspending
> Submitter : Rafał Miłecki <zajec5@gmail.com>
> Date : 2011-11-09 11:46
> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=132083922228088&w=4
>
> Subject : 3.2-rc1 doesn't boot on dual socket opteron without swap
> Submitter : Niklas Schnelle <niklas@komani.de>
> Date : 2011-11-10 20:09
> Message-ID : 1320955769.1718.8.camel@jupiter
> References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
>
> Subject : Sparc-32 doesn't work in 3.1.
> Submitter : Rob Landley <rob@landley.net>
> Date : 2011-11-12 11:22
> Message-ID : 4EBEAB5A.5020809@landley.net
> References : http://www.spinics.net/lists/kernel/msg1260383.html
>
> Subject : khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
> Submitter : Sergei Trofimovich <slyich@gmail.com>
> Date : 2011-11-12 10:48
> Message-ID : 20111112104859.7744b282@sf.home
> References : https://lkml.org/lkml/2011/11/12/11
>
> Subject : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
> Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
> Date : 2011-11-13 19:24
> Message-ID : 20111113192417.GA1659@x4.trippels.de
> References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2
>
> Subject : PROBLEM: Radeon display connector : No monitor connected or invalid EDID
> Submitter : Treeve Jelbert <treeve@scarlet.be>
> Date : 2011-11-13 17:27
> Message-ID : 2407026.akcTO2Ggic@gemini-64
> References : http://marc.info/?l=linux-kernel&m=132120530920139&w=2
Treeve replied to me directly saying the it was a problem with his
config file and everything is working fine now.
Alex
>
> Subject : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
> Submitter : Nix <nix@esperi.org.uk>
> Date : 2011-11-14 0:40
> Message-ID : 8762inleno.fsf@spindle.srvr.nix
> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
>
> Subject : max PWM is zero
> Submitter : Marcos Paulo de Souza <marcos.mage@gmail.com>
> Date : 2011-11-15 15:14
> Message-ID : alpine.LNX.2.00.1111151301410.2693@darkstar.example.net
> References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2
>
> Subject : Oops on suspend with libertas SDIO (Linux 3.2-rc2)
> Submitter : Sven Neumann <s.neumann@raumfeld.com>
> Date : 2011-11-17 15:36
> Message-ID : 1321544210.31090.6.camel@sven
> References : http://marc.info/?l=linux-kernel&m=132154527715807&w=2
>
> Subject : Impossible high cpu-time values for migration threads
> Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
> Date : 2011-11-17 22:17
> Message-ID : 20111117221731.GA9229@x4.trippels.de
> References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2
>
> Subject : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
> Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
> Date : 2011-11-18 7:25
> Message-ID : 20111118072519.GA1615@x4.trippels.de
> References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2
>
> Subject : [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)
> Submitter : Tomáš Janoušek <tomi@nomi.cz>
> Date : 2011-11-18 18:40
> Message-ID : 20111118184017.GA5052@nomi.cz
> References : http://marc.info/?l=linux-kernel&m=132164169511416&w=2
>
> Subject : [REGRESSION] sudden cpu hogging in kernel 3.2 rc-series
> Submitter : "Nicolas Kalkhof" <nkalkhof@web.de>
> Date : 2011-11-18 20:33
> Message-ID : 506786689.810044.1321648395265.JavaMail.fmail@mwmweb010
> References : http://marc.info/?l=linux-kernel&m=132164909313594&w=2
>
> Thanks!
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Andy Lutomirski @ 2011-11-21 22:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <CA+55aFygSFt+O5KLoiE_0V+o45eKfsoDDV5ML8EF=J0n9z_D-Q@mail.gmail.com>
On Mon, Nov 21, 2011 at 2:18 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> Subject : hugetlb oops on 3.1.0-rc8-devel
>> Submitter : Andy Lutomirski <luto@amacapital.net>
>> Date : 2011-11-01 22:20
>> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw@mail.gmail.com
>> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
>
> Despite the subject line, that's not an oops, it's a BUG_ON().
>
> And it *should* be fixed by commit ea4039a34c4c ("hugetlb: release
> pages in the error path of hugetlb_cow()") although I don't think Andy
> ever confirmed that (since it was hard to trigger).
I haven't seen it again, but that probably doesn't mean anything.
I've also fixed a bug in some userspace software I was running, and
that fix means I'm probably not stressing that part of the kernel
anymore. (Even without the fix, it took two weeks to hit this.)
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Linus Torvalds @ 2011-11-21 22:22 UTC (permalink / raw)
To: Rafael J. Wysocki, Rafał Miłecki
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <201111212249.31196.rjw@sisk.pl>
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Subject : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or suspending
> Submitter : Rafał Miłecki <zajec5@gmail.com>
> Date : 2011-11-09 11:46
> Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw@mail.gmail.com
> References : http://marc.info/?l=linux-netdev&m=132083922228088&w=4
This should be fixed by commit 1401a8008a09 ("sky2: fix hang on
shutdown (and other irq issues)") in current -git.
Linus
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Linus Torvalds @ 2011-11-21 22:20 UTC (permalink / raw)
To: Rafael J. Wysocki, Ari Savolainen
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <201111212249.31196.rjw@sisk.pl>
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Subject : lockdep warning after aa6afca5bcab: "proc: fix races against execve() of /proc/PID/fd**"
> Submitter : Ari Savolainen <ari.m.savolainen@gmail.com>
> Date : 2011-11-08 3:47
> Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
Commit aa6afca5bcab was reverted by commit 5e442a493fc5, so this one
is presumably stale.
Linus
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Linus Torvalds @ 2011-11-21 22:18 UTC (permalink / raw)
To: Rafael J. Wysocki, Andy Lutomirski
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <201111212249.31196.rjw@sisk.pl>
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Subject : hugetlb oops on 3.1.0-rc8-devel
> Submitter : Andy Lutomirski <luto@amacapital.net>
> Date : 2011-11-01 22:20
> Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
Despite the subject line, that's not an oops, it's a BUG_ON().
And it *should* be fixed by commit ea4039a34c4c ("hugetlb: release
pages in the error path of hugetlb_cow()") although I don't think Andy
ever confirmed that (since it was hard to trigger).
Linus
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Linus Torvalds @ 2011-11-21 22:11 UTC (permalink / raw)
To: Rafael J. Wysocki, Andy Lutomirski
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <201111212249.31196.rjw@sisk.pl>
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Subject : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
> Submitter : Nix <nix@esperi.org.uk>
> Date : 2011-11-14 0:40
> Message-ID : 8762inleno.fsf@spindle.srvr.nix
> References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
So this should be fixed by commit 2b666859ec32 ("x86: Default to
vsyscall=native for now"), since we disabled the vsyscall emulation
because it broken UML too.
Of course, the chromium seccomp thing might re-surface with the
patches that enable the emulation (with better emulation), which Andy
is still working on, and that I was planning on merging for 3.3.
Andy, it migth be worth contacting Nix and having him test whether
your fixed emulation works for chromium too.
Linus
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Linus Torvalds @ 2011-11-21 22:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, Linux Kernel Mailing List, DRI,
Florian Mickler, Andrew Morton, Kernel Testers List,
Linux PM List, Maciej Rutecki
In-Reply-To: <201111212249.31196.rjw@sisk.pl>
On Mon, Nov 21, 2011 at 1:49 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> Subject : Simultaneous cat and external keyboard input causing kernel panic
> Submitter : Timo Jyrinki <timo.jyrinki@gmail.com>
> Date : 2011-11-03 12:14
> Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ@mail.gmail.com
> References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2
So while funny, I doubt this is actually a bug. It's a feature, as
pointed out by Clemens Ladisch in that thread.
It's simply sysrq-c: "perform a system crash by a NULL pointer dereference".
Now, I'm perfectly willing to consider that feature to be a
mis-feature, and that this should be considered a bug to be fixed. But
it is not a regression.
Keeping it on the regression list just because it is amusing is
understandable, though ;)
Linus
^ permalink raw reply
* Re: [PATCHSET] cgroup: stable threadgroup during attach & subsys methods consolidation
From: Tejun Heo @ 2011-11-21 22:07 UTC (permalink / raw)
To: paul, rjw, lizf
Cc: fweisbec, containers, linux-kernel, oleg, linux-pm, akpm,
kamezawa.hiroyu
In-Reply-To: <1320191193-8110-1-git-send-email-tj@kernel.org>
On Tue, Nov 01, 2011 at 04:46:23PM -0700, Tejun Heo wrote:
> This patchset is combination of the following two patchsets.
>
> [1] cgroup: extend threadgroup locking
> [2] cgroup: introduce cgroup_taskset and consolidate subsys methods, take#2
Li, do you agree with the proposed patches? If so, I'll wait for
Frederic's response, repost updated series and merge it into the
cgroup tree.
Thank you.
--
tejun
^ permalink raw reply
* Re: [PATCH 04/10] cgroup: always lock threadgroup during migration
From: Tejun Heo @ 2011-11-21 22:05 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: akpm, containers, lizf, linux-kernel, oleg, linux-pm, paul,
kamezawa.hiroyu
In-Reply-To: <20111114185242.GF9446@somewhere>
On Mon, Nov 14, 2011 at 07:52:43PM +0100, Frederic Weisbecker wrote:
> On Mon, Nov 14, 2011 at 07:46:34PM +0100, Frederic Weisbecker wrote:
> > I have the feeling the task_lock is now useless given that we are synchronized
> > against cgroup_exit() with the threadgroup_lock.
> >
> > It's probably also useless in cgroup_exit(). But that's something for a further
> > patch...
> >
> > Thanks.
>
> Oops, I missed what Kamezawa said and your answer, sorry.
Yeap, I'll see how removing it for put looks.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 05/10] cgroup: subsys->attach_task() should be called after migration
From: Tejun Heo @ 2011-11-21 22:04 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: akpm, containers, lizf, linux-kernel, oleg, linux-pm, paul,
kamezawa.hiroyu
In-Reply-To: <20111114200553.GG9446@somewhere>
On Mon, Nov 14, 2011 at 09:06:08PM +0100, Frederic Weisbecker wrote:
> On Tue, Nov 01, 2011 at 04:46:28PM -0700, Tejun Heo wrote:
> > cgroup_attach_task() calls subsys->attach_task() after
> > cgroup_task_migrate(); however, cgroup_attach_proc() calls it before
> > migration. This actually affects some of the users. Update
> > cgroup_attach_proc() such that ->attach_task() is called after
> > migration.
>
> That's already upstream.
Yeap, just dropped this one while rebasing.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec
From: Tejun Heo @ 2011-11-21 22:03 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: akpm, containers, lizf, linux-kernel, oleg, linux-pm, paul,
kamezawa.hiroyu
In-Reply-To: <20111114135404.GD9446@somewhere>
On Mon, Nov 14, 2011 at 02:54:08PM +0100, Frederic Weisbecker wrote:
> > Also note this is currently protected by the tasklist readlock. Cred guard mutex is
> > certainly better, I just don't remember if you remove the tasklist lock in a
> > further patch.
>
> Ah recalling what Ben Blum said, we also need the leader to stay stable because it
> is excpected to be passed in ->can_attach(), ->attach(), ->cancel_attach(), ...
> Although that's going to change after your patches that pass a flex array.
Not really without locking out exec. The thing is whoever is exec'ing
will be the leader and we can't guarantee that the first in the flex
array is always the leader. One method may see it as the leader, the
next one might not.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 03/10] threadgroup: extend threadgroup_lock() to cover exit and exec
From: Tejun Heo @ 2011-11-21 21:58 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: akpm, containers, lizf, linux-kernel, oleg, linux-pm, paul,
kamezawa.hiroyu
In-Reply-To: <20111113164426.GB9446@somewhere>
Hello, Frederic.
On Sun, Nov 13, 2011 at 05:44:32PM +0100, Frederic Weisbecker wrote:
> > The next patch will update cgroup so that it can take full advantage
> > of this change.
>
> I don't want to nitpick really,
Heh, please go ahead and nitpick. That's one of the main purposes of
LKML after all. :)
> but IMHO the races involved in exit and exec
> are too different, specific and complicated on their own to be solved in a
> single one patch. This should be split in two things.
>
> The specific problems and their fix need to be described more in detail
> in the changelog because the issues are very tricky.
>
> The exec case:
>
> IIUC, the race in exec is about the group leader that can be changed
> to become the exec'ing thread, making while_each_thread() unsafe.
Not only that, pid changes, sighand struct may get swapped, and other
weird things which aren't usually expected for a live task happen.
It's basically semi-killed and then resurrected.
> We also have other things happening there like all the other threads
> in the group that get killed, but that should be handled by the threadgroup_change_begin()
> you put in the exit path.
> The old leader is also killed but release_task() -> __unhash_process() is called
> for it manually from the exec path. However this thread too should be covered by your
> synchronisation in exit().
>
> So after your protection in the exit path, the only thing to protect against in exec
> is that group_leader that can change concurrently. But I may be missing something in the picture.
Hmm... an exec'ing task goes through transitions which usually aren't
allowed to happen. It assumes exclusive access to group-shared data
structures and may ditch the current one and create a new one.
Sure, it's possible to make every cgroup method correct w.r.t. all
those via explicit locking or by being more careful but I don't see
much point in such excercise. If the code is sitting in some hot path
and the added exclusion is gonna add significant amount of contention,
sure, we should trade off easiness for better performance /
scalability but this is for cgroup modifications, a fundamentally cold
path, and the added locking is per-task or per-threadgroup. I don't
see any reason not to be easy here.
Please read on.
> Also note this is currently protected by the tasklist readlock. Cred
> guard mutex is certainly better, I just don't remember if you remove
> the tasklist lock in a further patch.
I don't remove tasklist_lock.
> The exit case:
>
> There the issue is about racing against cgroup_exit() where the task can be
> assigned to the root cgroup. Is this really a problem in fact? I don't know
> if subsystems care about that. Perhaps some of them are buggy in that
> regard. At least the task counter handles that and it needs a
> ->cancel_attach_task() for this purpose in the case the migration fails due to exit.
> Not sure about others. A real synchronization against exit is less error prone for sure.
> In the end that's probably a win.
This is the same story. Yes, we can narrow the locking and try to
make sure everyone handles partially destroyed tasks properly in all
methods, but for what? If we can give stable threadgroups to all
cgroup methods without introducing performance or scalability
bottleneck, that's the right thing to do. Please also note that bugs
stemming from failure to handle those corner cases properly will be
subtle, difficult to reproduce and track down.
In general, for any subsystem with pluggable interface, I think it's
best to put as much complexity as possible into the core layer to make
things eaiser for its customers. It becomes excruciatingly painful if
the API invites subtle corner case bugs and the subsystem grows
several dozen clients down the road.
So, to me, what seems more important is how to make it easier for each
cgroup client instead of what's the minimal that's necessary right
now.
Heh, did I make any sense? :)
Thanks.
--
tejun
^ permalink raw reply
* 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Rafael J. Wysocki @ 2011-11-21 21:49 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
In-Reply-To: <lx6sezwGldO.A.IhF.UBpWOB@chimera>
This message contains a list of some regressions from 3.0 and 3.1
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 3.0 and 3.1, please let us
know either and we'll add them to the list. Also, please let us know if any of
the entries below are invalid.
The entries below are simplified and the statistics are not present due to the
continuing Bugzilla outage.
Subject : iwlagn is getting very shaky
Submitter : Norbert Preining <preining@logic.at>
Date : 2011-10-19 6:01
Message-ID : 20111019060108.GA11588@gamma.logic.tuwien.ac.at
References : http://marc.info/?l=linux-kernel&m=131914553920614&w=2
Subject : Regression: "irqpoll" hasn't been working for me since March 16 IRQ
Submitter : Edward Donovan <edward.donovan@numble.net>
Date : 2011-10-19 22:09
Message-ID : CADdbW+HXdCPfJu2RTF6zz+ujCmiu_dmZwL2iScuF53p=AaZ1Uw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=131914554220679&w=2
Subject : Regression in 3.1 causes Xen to use wrong idle routine
Submitter : Stefan Bader <stefan.bader@canonical.com>
Date : 2011-10-26 10:24
Message-ID : 4EA7DFD1.9060608@canonical.com
References : http://marc.info/?l=linux-acpi&m=131962467924564&w=2
Subject : 3.1+ iwlwifi lockup
Submitter : Dave Jones <davej@redhat.com>
Date : 2011-10-31 14:34
Message-ID : 20111031143408.GA17152@redhat.com
References : http://marc.info/?l=linux-kernel&m=132007169420160&w=2
Subject : hugetlb oops on 3.1.0-rc8-devel
Submitter : Andy Lutomirski <luto@amacapital.net>
Date : 2011-11-01 22:20
Message-ID : CALCETrW1mpVCz2tO5roaz1r6vnno+srHR-dHA6_pkRi2qiCfdw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132018604426692&w=2
Subject : Simultaneous cat and external keyboard input causing kernel panic
Submitter : Timo Jyrinki <timo.jyrinki@gmail.com>
Date : 2011-11-03 12:14
Message-ID : CAJtFfxmovJHspHHKbvBVc4pw+u5mjGmUejCXEzdV+GqE=jVSOQ@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132032253903074&w=2
Subject : Linus GIT - INFO: possible circular locking dependency detected
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2011-11-03 15:57
Message-ID : CAHFgRy8S0xLfhZxTUOEH5A0PL_Fb79-0-gmbQ=9h2D-xMqt1hA@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132033587908426&w=2
Subject : lockdep warning after aa6afca5bcab: "proc: fix races against execve() of /proc/PID/fd**"
Submitter : Ari Savolainen <ari.m.savolainen@gmail.com>
Date : 2011-11-08 3:47
Message-ID : CAEbykaXYZEFhTgWMm2AfaWQ2SaXYuO_ypTnw+6AVWScOYSCuuw@mail.gmail.com
References : http://marc.info/?l=linux-kernel&m=132072413125099&w=2
Subject : DMA-API check_sync errors with 3.2
Submitter : Josh Boyer <jwboyer@redhat.com>
Date : 2011-11-08 17:31
Message-ID : 20111108173153.GE14216@zod.bos.redhat.com
References : http://marc.info/?l=linux-kernel&m=132077357608797&w=2
Subject : [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or suspending
Submitter : Rafał Miłecki <zajec5@gmail.com>
Date : 2011-11-09 11:46
Message-ID : CACna6ryTdLcWVYgHu=_mRFga1sFivpE_DyZOY-HMmKggkWAJAw@mail.gmail.com
References : http://marc.info/?l=linux-netdev&m=132083922228088&w=4
Subject : 3.2-rc1 doesn't boot on dual socket opteron without swap
Submitter : Niklas Schnelle <niklas@komani.de>
Date : 2011-11-10 20:09
Message-ID : 1320955769.1718.8.camel@jupiter
References : http://marc.info/?l=linux-kernel&m=132095583501767&w=2
Subject : Sparc-32 doesn't work in 3.1.
Submitter : Rob Landley <rob@landley.net>
Date : 2011-11-12 11:22
Message-ID : 4EBEAB5A.5020809@landley.net
References : http://www.spinics.net/lists/kernel/msg1260383.html
Subject : khugepaged blocks suspend2ram (3.2.0-rc1-00252-g8f042aa)
Submitter : Sergei Trofimovich <slyich@gmail.com>
Date : 2011-11-12 10:48
Message-ID : 20111112104859.7744b282@sf.home
References : https://lkml.org/lkml/2011/11/12/11
Subject : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2011-11-13 19:24
Message-ID : 20111113192417.GA1659@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2
Subject : PROBLEM: Radeon display connector : No monitor connected or invalid EDID
Submitter : Treeve Jelbert <treeve@scarlet.be>
Date : 2011-11-13 17:27
Message-ID : 2407026.akcTO2Ggic@gemini-64
References : http://marc.info/?l=linux-kernel&m=132120530920139&w=2
Subject : [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
Submitter : Nix <nix@esperi.org.uk>
Date : 2011-11-14 0:40
Message-ID : 8762inleno.fsf@spindle.srvr.nix
References : http://marc.info/?l=linux-kernel&m=132123396226377&w=2
Subject : max PWM is zero
Submitter : Marcos Paulo de Souza <marcos.mage@gmail.com>
Date : 2011-11-15 15:14
Message-ID : alpine.LNX.2.00.1111151301410.2693@darkstar.example.net
References : http://marc.info/?l=linux-kernel&m=132137019330548&w=2
Subject : Oops on suspend with libertas SDIO (Linux 3.2-rc2)
Submitter : Sven Neumann <s.neumann@raumfeld.com>
Date : 2011-11-17 15:36
Message-ID : 1321544210.31090.6.camel@sven
References : http://marc.info/?l=linux-kernel&m=132154527715807&w=2
Subject : Impossible high cpu-time values for migration threads
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2011-11-17 22:17
Message-ID : 20111117221731.GA9229@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2
Subject : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2011-11-18 7:25
Message-ID : 20111118072519.GA1615@x4.trippels.de
References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2
Subject : [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)
Submitter : Tomáš Janoušek <tomi@nomi.cz>
Date : 2011-11-18 18:40
Message-ID : 20111118184017.GA5052@nomi.cz
References : http://marc.info/?l=linux-kernel&m=132164169511416&w=2
Subject : [REGRESSION] sudden cpu hogging in kernel 3.2 rc-series
Submitter : "Nicolas Kalkhof" <nkalkhof@web.de>
Date : 2011-11-18 20:33
Message-ID : 506786689.810044.1321648395265.JavaMail.fmail@mwmweb010
References : http://marc.info/?l=linux-kernel&m=132164909313594&w=2
Thanks!
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Jerome Glisse @ 2011-11-21 21:29 UTC (permalink / raw)
To: Tejun Heo
Cc: Dmitry Torokhov, David Airlie, Andrew Watts, linux-kernel,
dri-devel, linux-pm
In-Reply-To: <20111121210908.GJ25776@google.com>
On Mon, Nov 21, 2011 at 4:09 PM, Tejun Heo <tj@kernel.org> wrote:
> On Fri, Nov 04, 2011 at 06:08:20PM -0500, Andrew Watts wrote:
>> On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
>> >
>> > I need full dmesg
>> >
>> > Cheers,
>> > Jerome
>>
>> Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
>>
>> Here goes as text/plain.
>
> Out of curiosity, did it get somewhere?
>
> Thanks.
>
> --
> tejun
>
Yeah i am pretty sure i know what's going wrong but there is no easy
fix, there is a deadlock in the kernel when gem wait ioctl is call on
scanout buffer and that a gpu reset happen
Cheers,
Jerome
^ permalink raw reply
* Re: [REGRESSION]: hibernate/sleep regression w/ bisection
From: Tejun Heo @ 2011-11-21 21:09 UTC (permalink / raw)
To: Andrew Watts
Cc: David Airlie, Dmitry Torokhov, linux-kernel, dri-devel,
Jerome Glisse, linux-pm
In-Reply-To: <20111104230758.GA7332@zeus>
On Fri, Nov 04, 2011 at 06:08:20PM -0500, Andrew Watts wrote:
> On Fri, Nov 04, 2011 at 01:35:53PM -0400, Jerome Glisse wrote:
> >
> > I need full dmesg
> >
> > Cheers,
> > Jerome
>
> Hi. Just noticed I attached a gzip of my dmesg last time by mistake.
>
> Here goes as text/plain.
Out of curiosity, did it get somewhere?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
From: Barry Song @ 2011-11-19 11:17 UTC (permalink / raw)
To: Pavel Machek
Cc: Xiangzhen Ye, linux-kernel, DL-SHA-WorkGroupLinux, Barry Song,
linux-pm, linux-arm-kernel
In-Reply-To: <20111118190233.GA16136@elf.ucw.cz>
2011/11/19 Pavel Machek <pavel@ucw.cz>:
> On Mon 2011-11-07 09:31:10, Barry Song wrote:
>> 2011/11/6 Barry Song <21cnbao@gmail.com>:
>> > 2011/11/6 Pavel Machek <pavel@ucw.cz>:
>> >> Hi!
>> >>
>> >>> From: Barry Song <Baohua.Song@csr.com>
>> >>>
>> >>> Current swsusp requires swap partitions even larger than real saved pages
>> >>> due to the worst compress ratio:
>> >>> but for an embedded system, which has limited storage space, then it might
>> >>> can't give the big size partition to save snapshot.
>> >>> In the another way, some embedded systems can definitely know the most size
>> >>> needed for snapshot since they run some specific application lists.
>> >>> So this patch provides the possibility for bootloader to tell kernel even
>> >>> the system has a little snapshot partition, but it is still enough.
>> >>> For example, if the system need to save 120MB memory, origin swsusp will require
>> >>> a 130MB partition to save snapshot. but if users know 30MB is enough for them(
>> >>> compressed image will be less than 30MB), they just make a 30MB
>> >>> partition.
>> >>
>> >> Would it be better to have /sys/power/... entry which would allow
>> >> configuring expected compression ratio at runtime?
>> >
>> > i think it is better to have a sys node than add another kernel param.
>> > but the point is i only care about the final image size but not
>> > compression ratio. i don't care how well lzo will do for me since i
>> > only have limited disk space and know how many pages want to be saved.
>> > there has been a image_size node, will we have a expected_image_size node?
>>
>> or will we have just a node named /sys/power/check_size, if
>> 1(default), check, otherwise(0 set by users), skip checking?
>
> Or just avoid the check at all, since it no longer makes sense with
> compression?
current early check just makes the failure happen earier. in the
check, it requires more space than uncompressed data due to the worst
compress ratio. some users might have big space and complex scenerios,
they might want the earlier check. but it is really a big waste
considering text, data sections of programs are actually data which
can be compressed in a big ratio.
but for some other embedded system users, they have limited storage
and known sw list, then they know their little space is enough for
compressed image.
i think we can make the function as a option for users. provide a node
/sys/power/check_swap_size, if users set it to 0, ignore the check.
otherwise, check by the worst compress ratio.
>
> What is the failure scenario? Hibernation still fails, but it takes
> longer to fail?
it will fail some later. but i still expect the system can restore to
be normal even it fails in the saving stage. i can give a test.
>
> Pavel
> --
-barry
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
^ permalink raw reply
* [PATCH v2] ahci: platform support for suspend/resume
From: Brian Norris @ 2011-11-18 19:10 UTC (permalink / raw)
To: Jeff Garzik
Cc: Brian Norris, Linux Kernel, Felipe Balbi, linux-ide, Tejun Heo,
linux-pm, Anton Vorontsov
Add platform hooks for custom suspend() and resume() functions. The
generic suspend/resume code in drivers/ata/ahci_platform.c is adapted
from the PCI version in drivers/ata/ahci.c.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
Based on:
git://github.com/jgarzik/libata-dev.git ALL
v2: * supports AHCI suspend/resume even when pdata, pdata->suspend, or
pdata->resume are not supplied
* use dev_get_platdata() consistently
drivers/ata/ahci_platform.c | 68 +++++++++++++++++++++++++++++++++++++++++
include/linux/ahci_platform.h | 2 +
2 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 43b8758..48be4e1 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -202,6 +202,71 @@ static int __devexit ahci_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int ahci_suspend(struct device *dev)
+{
+ struct ahci_platform_data *pdata = dev_get_platdata(dev);
+ struct ata_host *host = dev_get_drvdata(dev);
+ struct ahci_host_priv *hpriv = host->private_data;
+ void __iomem *mmio = hpriv->mmio;
+ u32 ctl;
+ int rc;
+
+ if (hpriv->flags & AHCI_HFLAG_NO_SUSPEND) {
+ dev_err(dev, "firmware update required for suspend/resume\n");
+ return -EIO;
+ }
+
+ /*
+ * AHCI spec rev1.1 section 8.3.3:
+ * Software must disable interrupts prior to requesting a
+ * transition of the HBA to D3 state.
+ */
+ ctl = readl(mmio + HOST_CTL);
+ ctl &= ~HOST_IRQ_EN;
+ writel(ctl, mmio + HOST_CTL);
+ readl(mmio + HOST_CTL); /* flush */
+
+ rc = ata_host_suspend(host, PMSG_SUSPEND);
+ if (rc)
+ return rc;
+
+ if (pdata && pdata->suspend)
+ return pdata->suspend(dev);
+ return 0;
+}
+
+static int ahci_resume(struct device *dev)
+{
+ struct ahci_platform_data *pdata = dev_get_platdata(dev);
+ struct ata_host *host = dev_get_drvdata(dev);
+ int rc;
+
+ if (pdata && pdata->resume) {
+ rc = pdata->resume(dev);
+ if (rc)
+ return rc;
+ }
+
+ if (dev->power.power_state.event == PM_EVENT_SUSPEND) {
+ rc = ahci_reset_controller(host);
+ if (rc)
+ return rc;
+
+ ahci_init_controller(host);
+ }
+
+ ata_host_resume(host);
+
+ return 0;
+}
+
+static struct dev_pm_ops ahci_pm_ops = {
+ .suspend = &ahci_suspend,
+ .resume = &ahci_resume,
+};
+#endif
+
static const struct of_device_id ahci_of_match[] = {
{ .compatible = "calxeda,hb-ahci", },
{},
@@ -214,6 +279,9 @@ static struct platform_driver ahci_driver = {
.name = "ahci",
.owner = THIS_MODULE,
.of_match_table = ahci_of_match,
+#ifdef CONFIG_PM
+ .pm = &ahci_pm_ops,
+#endif
},
.id_table = ahci_devtype,
};
diff --git a/include/linux/ahci_platform.h b/include/linux/ahci_platform.h
index be3d9a7..73a2500 100644
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -23,6 +23,8 @@ struct ata_port_info;
struct ahci_platform_data {
int (*init)(struct device *dev, void __iomem *addr);
void (*exit)(struct device *dev);
+ int (*suspend)(struct device *dev);
+ int (*resume)(struct device *dev);
const struct ata_port_info *ata_port_info;
unsigned int force_port_map;
unsigned int mask_port_map;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] PM: HIBERNATION: skip the swap size check if the snapshot image size is anticipative
From: Pavel Machek @ 2011-11-18 19:02 UTC (permalink / raw)
To: Barry Song
Cc: Xiangzhen Ye, linux-kernel, DL-SHA-WorkGroupLinux, Barry Song,
linux-pm, linux-arm-kernel
In-Reply-To: <CAGsJ_4xm05N4UZ94kvUtUGLGkcDnxesojV0fL9hQQnZBOFvohg@mail.gmail.com>
On Mon 2011-11-07 09:31:10, Barry Song wrote:
> 2011/11/6 Barry Song <21cnbao@gmail.com>:
> > 2011/11/6 Pavel Machek <pavel@ucw.cz>:
> >> Hi!
> >>
> >>> From: Barry Song <Baohua.Song@csr.com>
> >>>
> >>> Current swsusp requires swap partitions even larger than real saved pages
> >>> due to the worst compress ratio:
> >>> but for an embedded system, which has limited storage space, then it might
> >>> can't give the big size partition to save snapshot.
> >>> In the another way, some embedded systems can definitely know the most size
> >>> needed for snapshot since they run some specific application lists.
> >>> So this patch provides the possibility for bootloader to tell kernel even
> >>> the system has a little snapshot partition, but it is still enough.
> >>> For example, if the system need to save 120MB memory, origin swsusp will require
> >>> a 130MB partition to save snapshot. but if users know 30MB is enough for them(
> >>> compressed image will be less than 30MB), they just make a 30MB
> >>> partition.
> >>
> >> Would it be better to have /sys/power/... entry which would allow
> >> configuring expected compression ratio at runtime?
> >
> > i think it is better to have a sys node than add another kernel param.
> > but the point is i only care about the final image size but not
> > compression ratio. i don't care how well lzo will do for me since i
> > only have limited disk space and know how many pages want to be saved.
> > there has been a image_size node, will we have a expected_image_size node?
>
> or will we have just a node named /sys/power/check_size, if
> 1(default), check, otherwise(0 set by users), skip checking?
Or just avoid the check at all, since it no longer makes sense with
compression?
What is the failure scenario? Hibernation still fails, but it takes
longer to fail?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] ahci: platform support for suspend/resume
From: Felipe Balbi @ 2011-11-18 9:17 UTC (permalink / raw)
To: Brian Norris
Cc: Linux Kernel, balbi, linux-ide, Tejun Heo, linux-pm,
Anton Vorontsov, Jeff Garzik
In-Reply-To: <CAN8TOE9T8YJ8Kbz=cuQ_CYPQozxU--yskZuBcXwe_emVVNQqDg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]
On Thu, Nov 17, 2011 at 04:31:32PM -0800, Brian Norris wrote:
> +linux-pm mailing list
>
> Hi Felipe,
>
> On Wed, Nov 16, 2011 at 12:34 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Wed, Nov 16, 2011 at 12:27:59PM -0800, Brian Norris wrote:
> >> + /* Does platform support suspend/resume? */
> >> + if (!pdata->suspend || !pdata->resume)
> >> + return -EINVAL;
> >
> > should you really prevent suspend is platform doesn't provide
> > ->suspend() ?
>
> No, we shouldn't prevent suspend entirely; that would just be my
> accidental side effect.
>
> > I mean, we could some platform where all clocks are autogated and
> > there's no need for platform to do anything. Would it be better to only
> > call pdata->suspend if it exists but still let the AHCI-specific part go
> > through ?
>
> Perhaps. But would this have any unintended effects on systems that
> don't implement AHCI power management at all? My intention was just to
> provide an 'opt-in' interface for platform developers. I probably got
> this wrong.
I guess you could add a flag for that, but until we know that the AHCI
powermanagement is broken somewhere should we really care ? :-)
--
balbi
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH] ahci: platform support for suspend/resume
From: Brian Norris @ 2011-11-18 0:31 UTC (permalink / raw)
To: balbi
Cc: Linux Kernel, linux-ide, Tejun Heo, linux-pm, Anton Vorontsov,
Jeff Garzik
In-Reply-To: <20111116203422.GA29581@legolas.emea.dhcp.ti.com>
+linux-pm mailing list
Hi Felipe,
On Wed, Nov 16, 2011 at 12:34 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Wed, Nov 16, 2011 at 12:27:59PM -0800, Brian Norris wrote:
>> + /* Does platform support suspend/resume? */
>> + if (!pdata->suspend || !pdata->resume)
>> + return -EINVAL;
>
> should you really prevent suspend is platform doesn't provide
> ->suspend() ?
No, we shouldn't prevent suspend entirely; that would just be my
accidental side effect.
> I mean, we could some platform where all clocks are autogated and
> there's no need for platform to do anything. Would it be better to only
> call pdata->suspend if it exists but still let the AHCI-specific part go
> through ?
Perhaps. But would this have any unintended effects on systems that
don't implement AHCI power management at all? My intention was just to
provide an 'opt-in' interface for platform developers. I probably got
this wrong.
Brian
^ permalink raw reply
* Re: [PATCH 4/6] OMAP3: cpuidle: next C-state decision depends on the PM QoS MPU and CORE constraints
From: Kevin Hilman @ 2011-11-17 21:29 UTC (permalink / raw)
To: jean.pihet; +Cc: linux-omap, Linux PM mailing list, Jean Pihet
In-Reply-To: <1319032263-22699-5-git-send-email-j-pihet@ti.com>
jean.pihet@newoldbits.com writes:
> From: Jean Pihet <j-pihet@ti.com>
>
> The MPU latency figures for cpuidle include the MPU itself and also
> the peripherals needed for the MPU to execute instructions (e.g.
> main memory, caches, IRQ controller, MMU etc). On OMAP3 those
> peripherals belong to the MPU and CORE power domains and so the
> cpuidle C-states are a combination of MPU and CORE states.
>
> This patch implements the relation between the cpuidle and per-
> device PM QoS frameworks in the OMAP3 specific idle callbacks.
>
> The chosen C-state shall satisfy the following conditions:
> . the 'valid' field is enabled,
> . it satisfies the enable_off_mode flag,
Not directly related to this patch, but is there any reason to keep the
'enable_off_mode' flag after this series?
Kevin
^ permalink raw reply
* Re: [PATCH 3/6] OMAP: PM: register to the per-device PM QoS framework
From: Kevin Hilman @ 2011-11-17 21:24 UTC (permalink / raw)
To: jean.pihet; +Cc: linux-omap, Linux PM mailing list, Jean Pihet
In-Reply-To: <1319032263-22699-4-git-send-email-j-pihet@ti.com>
jean.pihet@newoldbits.com writes:
> From: Jean Pihet <j-pihet@ti.com>
>
> Implement the devices wake-up latency constraints using the global
> device PM QoS notification handler which applies the constraints to the
> underlying layer by calling the corresponding function at hwmod level.
>
> Tested on OMAP3 Beagleboard and OMAP4 Pandaboard in RET/OFF using wake-up
> latency constraints on MPU, CORE and PER.
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
> ---
> arch/arm/mach-omap2/pm.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 63 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 3feb359..58b4b76 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -11,13 +11,16 @@
>
> #include <linux/kernel.h>
> #include <linux/init.h>
> +#include <linux/notifier.h>
> #include <linux/io.h>
> #include <linux/err.h>
> #include <linux/opp.h>
> +#include <linux/pm_qos.h>
>
> #include <plat/omap-pm.h>
> #include <plat/omap_device.h>
> #include <plat/common.h>
> +#include <plat/omap_hwmod.h>
>
> #include "voltage.h"
> #include "powerdomain.h"
> @@ -242,11 +245,71 @@ static void __init omap4_init_voltages(void)
> omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", iva_dev);
> }
>
> +/* Interface to the per-device PM QoS framework */
> +static int omap2_dev_pm_qos_handler(struct notifier_block *nb,
> + unsigned long new_value,
> + void *req)
> +{
> + struct omap_device *od;
> + struct omap_hwmod *oh;
> + struct platform_device *pdev;
> + struct dev_pm_qos_request *dev_pm_qos_req = req;
> +
> + pr_debug("OMAP PM CONSTRAINTS: req@0x%p, new_value=%lu\n",
s/CONSTRAINTS/constraints/
another one below.
> + req, new_value);
> +
> + /* Look for the platform device for the constraint target device */
> + pdev = to_platform_device(dev_pm_qos_req->dev);
> +
> + /* Try to catch non platform devices */
why?
> + if (pdev->name == NULL) {
> + pr_err("%s: Error: platform device for device %s not valid\n",
> + __func__, dev_name(dev_pm_qos_req->dev));
> + return -EINVAL;
> + }
> +
> + /* Find the associated omap_device for dev */
> + od = container_of(pdev, struct omap_device, pdev);
What about devices that are valid platform_devices, but not omap_devices?
> + if (od->hwmods_cnt != 1) {
> + pr_err("%s: Error: No unique hwmod for device %s\n",
> + __func__, dev_name(dev_pm_qos_req->dev));
> + return -EINVAL;
> + }
> +
> + /* Find the primary omap_hwmod for dev */
> + oh = od->hwmods[0];
> +
> + pr_debug("OMAP PM CONSTRAINTS: req@0x%p, dev=0x%p, new_value=%lu\n",
> + req, dev_pm_qos_req->dev, new_value);
> +
> + /* Apply the constraint */
> + return omap_hwmod_set_wkup_lat_constraint(oh, dev_pm_qos_req,
> + new_value);
> +}
> +
> +static struct notifier_block omap2_dev_pm_qos_notifier = {
> + .notifier_call = omap2_dev_pm_qos_handler,
> +};
> +
> +static int __init omap2_dev_pm_qos_init(void)
> +{
> + int ret;
> +
> + ret = dev_pm_qos_add_global_notifier(&omap2_dev_pm_qos_notifier);
> + if (ret)
> + WARN(1, KERN_ERR "Cannot add global notifier for dev PM QoS\n");
minor: could use WARN_ON()
> + return ret;
> +}
> +
> static int __init omap2_common_pm_init(void)
> {
> omap2_init_processor_devices();
> omap_pm_if_init();
>
> + /* Register to the per-device PM QoS framework */
> + omap2_dev_pm_qos_init();
> +
> return 0;
> }
> postcore_initcall(omap2_common_pm_init);
Kevin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox