3.1-rc3-git6: Reported regressions from 3.0

3.1-rc3-git6: Reported regressions from 3.0

[Rafael J. Wysocki]

This message contains a list of some regressions from 3.0,
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, 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.

Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.


Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2011-08-28        8        4           4


Unresolved regressions
----------------------

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41742
Subject		: duplicate filename  for intel_backlight with the i915 driver
Submitter	: François Valenduc <francois.valenduc@tvcablenet.be>
Date		: 2011-08-25 18:51 (4 days old)
First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41512
Subject		: 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds
Submitter	: Carlos R. Mafra <crmafra2@gmail.com>
Date		: 2011-08-16 9:42 (13 days old)
Message-ID	: <20110816094245.GA2042@Pilar.site>
References	: http://marc.info/?l=linux-kernel&m=131348782017435&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41502
Subject		: cfq-iosched: a regression
Submitter	: Shaohua Li <shaohua.li@intel.com>
Date		: 2011-08-16 2:47 (13 days old)
Message-ID	: <1313462826.27321.22.camel@sli10-conroe>
References	: http://marc.info/?l=linux-kernel&m=131346279329911&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41442
Subject		: rcu_sched_state detected stall on CPU 0, when booting on Xen
Submitter	: Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Date		: 2011-08-21 04:06 (8 days old)


Regressions with patches
------------------------

For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 3.0,
unresolved as well as resolved, at:

http://bugzilla.kernel.org/show_bug.cgi?id=40982

Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.

Thanks!

[Bug #41442] rcu_sched_state detected stall on CPU 0, when booting on Xen

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 3.0.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41442
Subject		: rcu_sched_state detected stall on CPU 0, when booting on Xen
Submitter	: Witold Baryluk <baryluk@smp.if.uj.edu.pl>
Date		: 2011-08-21 04:06 (8 days old)

[Bug #41742] duplicate filename for intel_backlight with the i915 driver

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 3.0.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41742
Subject		: duplicate filename  for intel_backlight with the i915 driver
Submitter	: François Valenduc <francois.valenduc@tvcablenet.be>
Date		: 2011-08-25 18:51 (4 days old)
First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9

[Bug #41512] 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 3.0.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41512
Subject		: 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds
Submitter	: Carlos R. Mafra <crmafra2@gmail.com>
Date		: 2011-08-16 9:42 (13 days old)
Message-ID	: <20110816094245.GA2042@Pilar.site>
References	: http://marc.info/?l=linux-kernel&m=131348782017435&w=2

[Bug #41502] cfq-iosched: a regression

[Rafael J. Wysocki]

This message has been generated automatically as a part of a summary report
of recent regressions.

The following bug entry is on the current list of known regressions
from 3.0.  Please verify if it still should be listed and let the tracking team
know (either way).


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41502
Subject		: cfq-iosched: a regression
Submitter	: Shaohua Li <shaohua.li@intel.com>
Date		: 2011-08-16 2:47 (13 days old)
Message-ID	: <1313462826.27321.22.camel@sli10-conroe>
References	: http://marc.info/?l=linux-kernel&m=131346279329911&w=2

Re: 3.1-rc3-git6: Reported regressions from 3.0

[Dave Jones]

On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
 
 > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41742
 > Subject		: duplicate filename  for intel_backlight with the i915 driver
 > Submitter	: François Valenduc <francois.valenduc@tvcablenet.be>
 > Date		: 2011-08-25 18:51 (4 days old)
 > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
 
this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23
 
	Dave

Re: 3.1-rc3-git6: Reported regressions from 3.0

[Rafael J. Wysocki]

On Sunday, August 28, 2011, Dave Jones wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>  
>  > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41742
>  > Subject		: duplicate filename  for intel_backlight with the i915 driver
>  > Submitter	: François Valenduc <francois.valenduc@tvcablenet.be>
>  > Date		: 2011-08-25 18:51 (4 days old)
>  > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
>  
> this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23

Thanks, closing.

Rafael

Re: 3.1-rc3-git6: Reported regressions from 3.0

[Linus Torvalds]

On Sun, Aug 28, 2011 at 12:35 PM, Dave Jones <davej@redhat.com> wrote:
> On Sun, Aug 28, 2011 at 08:22:05PM +0200, Rafael J. Wysocki wrote:
>
>  > Bug-Entry    : http://bugzilla.kernel.org/show_bug.cgi?id=41742
>  > Subject              : duplicate filename  for intel_backlight with the i915 driver
>  > Submitter    : François Valenduc <francois.valenduc@tvcablenet.be>
>  > Date         : 2011-08-25 18:51 (4 days old)
>  > First-Bad-Commit: http://git.kernel.org/linus/aaa6fd2a004147bf32fce05720938236de3361d9
>
> this should be fixed by b727d20269e8ef1de002bfea8099f5e9db9e9f23

Actually, by a2cc797d2d1a ("i915: do not setup intel_backlight ").

That b727d20269e is just my merge commit that brings in the fix (and
the bogus initialization of 'locked') into mainline.

                   Linus

Re: [Bug #41512] 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds

[Carlos R. Mafra]

On Sun, 28 Aug 2011 at 20:30:51 +0200, Rafael J. Wysocki wrote:
> 
> The following bug entry is on the current list of known regressions
> from 3.0.  Please verify if it still should be listed and let the tracking team
> know (either way).

It didn't happen again since then (with post -rc2 kernels).


> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=41512
> Subject		: 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds
> Submitter	: Carlos R. Mafra <crmafra2@gmail.com>
> Date		: 2011-08-16 9:42 (13 days old)
> Message-ID	: <20110816094245.GA2042@Pilar.site>
> References	: http://marc.info/?l=linux-kernel&m=131348782017435&w=2
> 

Re: [Bug #41512] 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds

[Rafael J. Wysocki]

On Monday, August 29, 2011, Carlos R. Mafra wrote:
> On Sun, 28 Aug 2011 at 20:30:51 +0200, Rafael J. Wysocki wrote:
> > 
> > The following bug entry is on the current list of known regressions
> > from 3.0.  Please verify if it still should be listed and let the tracking team
> > know (either way).
> 
> It didn't happen again since then (with post -rc2 kernels).

Thanks, closing.

Rafael

Re: [Bug #41512] 3.1-rc2 failed s2ram: Freezing of tasks failed after 20.00 seconds

[Carlos R. Mafra]

On Mon, 29 Aug 2011 at 22:38:01 +0200, Rafael J. Wysocki wrote:
> On Monday, August 29, 2011, Carlos R. Mafra wrote:
> > On Sun, 28 Aug 2011 at 20:30:51 +0200, Rafael J. Wysocki wrote:
> > > 
> > > The following bug entry is on the current list of known regressions
> > > from 3.0.  Please verify if it still should be listed and let the tracking team
> > > know (either way).
> > 
> > It didn't happen again since then (with post -rc2 kernels).
> 
> Thanks, closing.

Unfortunately it happened again with the kernel 3.1-rc4, after an uptime
of 3 days and 15 hours with ~10 suspend to RAM in between (so I can't bisect).

The symptom is that when I close the lid to suspend, I notice that the power
led indicator does not switch from green to 'blinking red', and stays green all
the time. The fan seems to be on.

In fact, the first time I reported this issue I hadn't noticed that the suspend
failed and put the laptop inside my backpack and went to work. When I arrived 
the laptop was almost frying and it had been turned off automatically somehow.

>From 'dmesg' I see some messages from the USB surfstick ~120 secs before the
traces. I did not disconnect from the surfstick internet before closing the lid
as I usually do (will check later if that's a way to reproduce).

[69489.551533] PM: resume of devices complete after 1365.354 msecs
[69489.551625] PM: Finishing wakeup.
[69489.551626] Restarting tasks ... done.
[69489.554183] video LNXVIDEO:01: Restoring backlight state
[69489.555548] usb 2-1.6: USB disconnect, device number 34
[69489.556046] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
[69489.556055] option 2-1.6:1.0: device disconnected
[69489.556183] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
[69489.556191] option 2-1.6:1.1: device disconnected
[69614.122681] INFO: task udisks-daemon:2945 blocked for more than 120 seconds.
[69614.122686] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[69614.122691] udisks-daemon   D ffff8800d908e510     0  2945   2944 0x00000000
[69614.122699]  ffff8800a9d27928 0000000000000082 ffff8800a9d27928 00000000000105c0
[69614.122705]  ffff8800d908e140 00000000000105c0 ffff8800a9d27fd8 00000000000105c0
[69614.122711]  00000000000105c0 ffff8800a9d26000 ffff8800a9d27fd8 00000000000105c0
[69614.122717] Call Trace:
[69614.122731]  [<ffffffff814ca825>] schedule_timeout+0x1c5/0x230
[69614.122739]  [<ffffffff81030364>] ? check_preempt_curr+0x84/0xa0
[69614.122744]  [<ffffffff81030392>] ? ttwu_do_wakeup+0x12/0x90
[69614.122750]  [<ffffffff814c98b0>] wait_for_common+0xc0/0x160
[69614.122757]  [<ffffffff8103ec60>] ? try_to_wake_up+0x290/0x290
[69614.122762]  [<ffffffff81059a5d>] ? insert_work+0x6d/0x80
[69614.122768]  [<ffffffff814c99f8>] wait_for_completion+0x18/0x20
[69614.122772]  [<ffffffff81059c0b>] flush_work+0x2b/0x40
[69614.122779]  [<ffffffff810590e0>] ? do_work_for_cpu+0x30/0x30
[69614.122784]  [<ffffffff8105a186>] flush_delayed_work+0x46/0x50
[69614.122792]  [<ffffffff812190d6>] disk_clear_events+0x76/0x110
[69614.122798]  [<ffffffff811061c2>] check_disk_change+0x32/0x80
[69614.122804]  [<ffffffff812e9919>] sd_open+0xb9/0x190
[69614.122809]  [<ffffffff811070f1>] __blkdev_get+0x91/0x3d0
[69614.122814]  [<ffffffff81107770>] ? blkdev_get+0x340/0x340
[69614.122818]  [<ffffffff8110747e>] blkdev_get+0x4e/0x340
[69614.122825]  [<ffffffff810e1c87>] ? do_lookup+0xb7/0x380
[69614.122829]  [<ffffffff81107770>] ? blkdev_get+0x340/0x340
[69614.122834]  [<ffffffff811077cd>] blkdev_open+0x5d/0x80
[69614.122839]  [<ffffffff810d3ef0>] __dentry_open+0x130/0x320
[69614.122844]  [<ffffffff810d5191>] nameidata_to_filp+0x71/0x80
[69614.122849]  [<ffffffff810e2c21>] do_last+0xb1/0x800
[69614.122854]  [<ffffffff810e4773>] path_openat+0xd3/0x3f0
[69614.122860]  [<ffffffff81223b27>] ? kobject_put+0x27/0x60
[69614.122868]  [<ffffffff812ca032>] ? put_device+0x12/0x20
[69614.122873]  [<ffffffff810e4af4>] do_filp_open+0x44/0xa0
[69614.122880]  [<ffffffff810f0bb4>] ? alloc_fd+0xf4/0x150
[69614.122884]  [<ffffffff810d529c>] do_sys_open+0xfc/0x1e0
[69614.122889]  [<ffffffff810d3bf6>] ? filp_close+0x56/0x80
[69614.122893]  [<ffffffff810d539b>] sys_open+0x1b/0x20
[69614.122899]  [<ffffffff814cd0fb>] system_call_fastpath+0x16/0x1b
[69734.141207] INFO: task udisks-daemon:2945 blocked for more than 120 seconds.


Is there something else I could do to help finding out what's going on?
I will stop using the surfstick next month, so after that I won't be able
to check if it happens again.

3.2-rc2+: Reported regressions from 3.0 and 3.1

[Rafael J. Wysocki]

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!

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Linus Torvalds]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

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.)

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Alex Deucher]

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
>

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Ari Savolainen]

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

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Srivatsa S. Bhat]

On 11/22/2011 03:19 AM, Rafael J. Wysocki 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
> 

Andrea's patch already fixes this issue, which was reported first by
Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
I remember Andrew Morton taking this patch in his -mm tree. But it is
not in mainline yet. So can we consider this closed or not?

Thanks,
Srivatsa S. Bhat

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andrew Morton]

On Tue, 22 Nov 2011 11:19:24 +0530 "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com> wrote:

> > 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
> > 
> 
> Andrea's patch already fixes this issue, which was reported first by
> Jiri Slaby. https://lkml.org/lkml/2011/11/11/93
> I remember Andrew Morton taking this patch in his -mm tree. But it is
> not in mainline yet. So can we consider this closed or not?

grr, nothing in that patch's changelog indicates that it fixed a
regression nor that it fixed an infinite blockage of suspend.

I moved it to my 3.2 queue, thanks.

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andy Lutomirski]

On Mon, Nov 21, 2011 at 2:34 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> 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
>>

This is apparently fixed in seccompsandbox.  See:

https://code.google.com/p/seccompsandbox/issues/detail?id=17
https://code.google.com/p/seccompsandbox/source/detail?r=178

Unless someone objects, I'll consider this to not be a kernel
regression worth fixing.

--Andy

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Andrea Arcangeli]

On Mon, Nov 21, 2011 at 09:59:18PM -0800, Andrew Morton wrote:
> grr, nothing in that patch's changelog indicates that it fixed a
> regression nor that it fixed an infinite blockage of suspend.

Well it's not a recent thing so I didn't flag it as a regression. It
doesn't infinite block it, suspend works fine almost all the time (or
it would have been noticed before), and if you've bad luck and it
doesn't suspend the first time around like someone experienced, if you
try again a bit later it'll work.

> I moved it to my 3.2 queue, thanks.

Thanks!

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

> 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

The patch mentioned in http://mid.gmane.org/20111115144004.GE22675@phenom.dumpdata.com 
should do it. But the patch needs an Ack from ACPI/x86 folks.

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Rafał Miłecki]

W dniu 21 listopada 2011 23:22 użytkownik Linus Torvalds
<torvalds@linux-foundation.org> napisał:
> 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.

This patch doesn't fix my hang.

However git contains also:
sky2: fix hang in napi_disable
This is the one fixing my case.

So the bug is resolved, however I'm a little disappointed noone
ping-ed me about that patches. I've spent some time on bisecting this
issue, expected to get some response :/

-- 
Rafał

[PATCH] hugetlb: release pages in the error path of hugetlb_cow() (was: Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1)

[Michal Hocko]

On Mon 21-11-11 14:18:29, Linus Torvalds 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).

AFAICS the issue has been introduced by 0fe6e20b (hugetlb, rmap:
add reverse mapping for hugepage) in 2.6.36-rc1 so this is a stable
material. I do not see the patch in any stable branch so here we go.
The patch is on top of 3.0.y branch and it applies as is to 3.1.y
as well.
---
>From fdaa4aaa008cce149a5fd60934112acd8988e0b6 Mon Sep 17 00:00:00 2001
From: Hillf Danton <dhillf@gmail.com>
Date: Tue, 15 Nov 2011 14:36:12 -0800
Subject: [PATCH] hugetlb: release pages in the error path of hugetlb_cow()

commit ea4039a34c4c206d015d34a49d0b00868e37db1d upstream.

If we fail to prepare an anon_vma, the {new, old}_page should be released,
or they will leak.

Signed-off-by: Hillf Danton <dhillf@gmail.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Johannes Weiner <jweiner@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
 mm/hugetlb.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index bfcf153..2b57cd9 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2415,6 +2415,8 @@ retry_avoidcopy:
 	 * anon_vma prepared.
 	 */
 	if (unlikely(anon_vma_prepare(vma))) {
+		page_cache_release(new_page);
+		page_cache_release(old_page);
 		/* Caller expects lock to be held */
 		spin_lock(&mm->page_table_lock);
 		return VM_FAULT_OOM;
-- 
1.7.7.3


-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

On Tue, Nov 22, 2011 at 08:54:12AM -0500, Konrad Rzeszutek Wilk wrote:
> > 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
> 
> The patch mentioned in http://mid.gmane.org/20111115144004.GE22675@phenom.dumpdata.com 
> should do it. But the patch needs an Ack from ACPI/x86 folks.

This patch (mentioned in the URL above) fixes the issue. Could it be
applied to the x86 tree for 3.2 or get an Ack, please?

>From 4f10ec7a7b9ff24657696aa98f25bcecde247373 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 21 Nov 2011 18:02:02 -0500
Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.

This patch:

commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown <len.brown@intel.com>
Date:   Fri Apr 1 18:28:35 2011 -0400

    cpuidle: replace xen access to x86 pm_idle and default_idle

    ..scribble on pm_idle and access default_idle,
   have it simply disable_cpuidle() so acpi_idle will not load and
   architecture default HLT will be used.

idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
and acpi_idle_call to not set pm_idle (which is excellent). But the
amd_e400_idle and mwait_idle can still setup pm_idle which we really
do not want. In case of mwait_idle we can hit some instances where:

Brought up 2 CPUs
invalid opcode: 0000 [#1] SMP
CPU 1
Modules linked in:

Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[<ffffffff81015d1d>]  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
RSP: e02b:ffff8801d28ddf10  EFLAGS: 00010082
RAX: ffff8801d28dc010 RBX: ffff8801d28ddfd8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff8801d28ddf10 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: ffff8801d28ddfd8 R12: ffffffff81b590d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8801dff81000(0000) knlGS:0000000000000000
CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
Process swapper (pid: 0, threadinfo ffff8801d28dc000, task ffff8801d28cae60)
Stack:
 ffff8801d28ddf40 ffffffff8100e2ed ffff8801dff8e390 c136dfe72feab515
 0000000000000000 0000000000000000 ffff8801d28ddf50 ffffffff8149ee78
 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
 [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
 [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
RIP  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
 RSP <ffff8801d28ddf10>

RH BZ #739499 and Ubuntu #881076

In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.

Lets make pm_idle be default_idle to take care of that.

Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/system.h |    1 +
 arch/x86/kernel/process.c     |    8 ++++++++
 arch/x86/xen/setup.c          |    2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
 
 void default_idle(void);
+bool set_pm_idle_to_default(void);
 
 void stop_this_cpu(void *dummy);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..336b299 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif
 
+bool set_pm_idle_to_default()
+{
+	if (!pm_idle) {
+		pm_idle = default_idle;
+		return true;
+	}
+	return false;
+}
 void stop_this_cpu(void *dummy)
 {
 	local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..7506181 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
 #endif
 	disable_cpuidle();
 	boot_option_idle_override = IDLE_HALT;
-
+	WARN_ON(!set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.7.3

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Borislav Petkov]

On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> This patch:
> 
> commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> Author: Len Brown <len.brown@intel.com>
> Date:   Fri Apr 1 18:28:35 2011 -0400
> 
>     cpuidle: replace xen access to x86 pm_idle and default_idle
> 
>     ..scribble on pm_idle and access default_idle,
>    have it simply disable_cpuidle() so acpi_idle will not load and
>    architecture default HLT will be used.
> 
> idea was to have one call - disable_cpuidle() which would make
> pm_idle not be molested by other code. It disallows cpuidle_idle_call
> and acpi_idle_call to not set pm_idle (which is excellent). But the

what is acpi_idle_call, I can't find it anywhere.

> amd_e400_idle and mwait_idle can still setup pm_idle which we really
> do not want.

This is not the case: rather select_idle_routine()/idle_setup() sets
pm_idle.

[..]

> +bool set_pm_idle_to_default()
> +{
> +	if (!pm_idle) {
> +		pm_idle = default_idle;
> +		return true;
> +	}
> +	return false;
> +}

I don't understand what you're trying to achieve here? Do you want
default_idle to be always the pm_idle for xen or what is the deal here?

If yes, then simply do:

bool set_pm_idle_to_default(void)	// remember to add "void" for no function args
{
	bool ret = !!pm_idle;

	pm_idle = default_idle;

	return ret;

}

...

>  void stop_this_cpu(void *dummy)
>  {
>  	local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..7506181 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
>  #endif
>  	disable_cpuidle();
>  	boot_option_idle_override = IDLE_HALT;
> -
> +	WARN_ON(!set_pm_idle_to_default());

and then do

	WARN_ON(set_pm_idle_to_default());

instead of having arbitrary confusing logic. This way you can warn
whether something else set pm_idle already. Or?

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > This patch:
> > 
> > commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> > Author: Len Brown <len.brown@intel.com>
> > Date:   Fri Apr 1 18:28:35 2011 -0400
> > 
> >     cpuidle: replace xen access to x86 pm_idle and default_idle
> > 
> >     ..scribble on pm_idle and access default_idle,
> >    have it simply disable_cpuidle() so acpi_idle will not load and
> >    architecture default HLT will be used.
> > 
> > idea was to have one call - disable_cpuidle() which would make
> > pm_idle not be molested by other code. It disallows cpuidle_idle_call
> > and acpi_idle_call to not set pm_idle (which is excellent). But the
> 
> what is acpi_idle_call, I can't find it anywhere.

You are right. I had "acpi_idle_enter_*" and its friend in mind. Which
are called from the cpuidle_idle_call.

Let me fix that comment up.
> 
> > amd_e400_idle and mwait_idle can still setup pm_idle which we really
> > do not want.
> 
> This is not the case: rather select_idle_routine()/idle_setup() sets
> pm_idle.

Yes. Let me fix up the comment.
> 
> [..]
> 
> > +bool set_pm_idle_to_default()
> > +{
> > +	if (!pm_idle) {
> > +		pm_idle = default_idle;
> > +		return true;
> > +	}
> > +	return false;
> > +}
> 
> I don't understand what you're trying to achieve here? Do you want
> default_idle to be always the pm_idle for xen or what is the deal here?

Yes (always want default_idle).
> 
> If yes, then simply do:
> 
> bool set_pm_idle_to_default(void)	// remember to add "void" for no function args
> {
> 	bool ret = !!pm_idle;
> 
> 	pm_idle = default_idle;

That would work too.
> 
> 	return ret;
> 
> }
> 
> ...
> 
> >  void stop_this_cpu(void *dummy) 
> >  {
> >  	local_irq_disable();
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 46d6d21..7506181 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> > @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
> >  #endif
> >  	disable_cpuidle();
> >  	boot_option_idle_override = IDLE_HALT;
> > -
> > +	WARN_ON(!set_pm_idle_to_default());
> 
> and then do
> 
> 	WARN_ON(set_pm_idle_to_default());
> 
> instead of having arbitrary confusing logic. This way you can warn
> whether something else set pm_idle already. Or?

That would work as well.

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > This patch:


Borislav,

Thanks for your review comments. How does this patch look? I believe
I touched upon all of the things you mentioned.

>From eb6dbd80078312c428dde69e9313606b7513a2e6 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 21 Nov 2011 18:02:02 -0500
Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.

This patch:

commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
Author: Len Brown <len.brown@intel.com>
Date:   Fri Apr 1 18:28:35 2011 -0400

    cpuidle: replace xen access to x86 pm_idle and default_idle

    ..scribble on pm_idle and access default_idle,
   have it simply disable_cpuidle() so acpi_idle will not load and
   architecture default HLT will be used.

idea was to have one call - disable_cpuidle() which would make
pm_idle not be molested by other code. It disallows cpuidle_idle_call
to be set to pm_idle (which is excellent). But in the select_idle_routine()
and idle_setup(), the pm_idle can still be set to either:
amd_e400_idle, mwait_idle or default_idle. This depends on some
CPU flags (MWAIT) and in AMD case on the type of CPU.

In case of mwait_idle we can hit some instances where the hypervisor
(Amazon EC2 specifically) sets the MWAIT and we get:

Brought up 2 CPUs
invalid opcode: 0000 [#1] SMP
CPU 1
Modules linked in:

Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
RIP: e030:[<ffffffff81015d1d>]  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
RSP: e02b:ffff8801d28ddf10  EFLAGS: 00010082
RAX: ffff8801d28dc010 RBX: ffff8801d28ddfd8 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffff8801d28ddf10 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: ffff8801d28ddfd8 R12: ffffffff81b590d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8801dff81000(0000) knlGS:0000000000000000
CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
Process swapper (pid: 0, threadinfo ffff8801d28dc000, task ffff8801d28cae60)
Stack:
 ffff8801d28ddf40 ffffffff8100e2ed ffff8801dff8e390 c136dfe72feab515
 0000000000000000 0000000000000000 ffff8801d28ddf50 ffffffff8149ee78
 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Call Trace:
 [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
 [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
RIP  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
 RSP <ffff8801d28ddf10>

In case of amd_e400_idle we don't get so spectacular crashes, but
we do end up making an MSR which is trapped in the hypervisor,
and then follow it up with a yield hypercall. Meaning we end up
going to hypervisor twice instead of just once.

The previous behavior before v3.0 was that pm_idle was set
to default_idle irregardless of select_idle_routine/idle_setup.

We want to do that, but only for one specific case: Xen.
This patch does that.

Fixes RH BZ #739499 and Ubuntu #881076
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
 arch/x86/include/asm/system.h |    1 +
 arch/x86/kernel/process.c     |    8 ++++++++
 arch/x86/xen/setup.c          |    2 +-
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2d2f01c 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
 extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
 
 void default_idle(void);
+bool set_pm_idle_to_default(void);
 
 void stop_this_cpu(void *dummy);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1f7f8c8..31f47ba 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -404,6 +404,14 @@ void default_idle(void)
 EXPORT_SYMBOL(default_idle);
 #endif
 
+bool set_pm_idle_to_default(void)
+{
+	bool ret = !!pm_idle;
+
+	pm_idle = default_idle;
+
+	return ret;
+}
 void stop_this_cpu(void *dummy)
 {
 	local_irq_disable();
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 46d6d21..79dfb57 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
 #endif
 	disable_cpuidle();
 	boot_option_idle_override = IDLE_HALT;
-
+	WARN_ON(set_pm_idle_to_default());
 	fiddle_vdso();
 }
-- 
1.7.7.3

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Borislav Petkov]

On Wed, Nov 30, 2011 at 12:59:36PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> > On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > > This patch:
> 
> 
> Borislav,
> 
> Thanks for your review comments. How does this patch look? I believe
> I touched upon all of the things you mentioned.
> 
> From eb6dbd80078312c428dde69e9313606b7513a2e6 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Mon, 21 Nov 2011 18:02:02 -0500
> Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.
> 
> This patch:
> 
> commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> Author: Len Brown <len.brown@intel.com>
> Date:   Fri Apr 1 18:28:35 2011 -0400
> 
>     cpuidle: replace xen access to x86 pm_idle and default_idle
> 
>     ..scribble on pm_idle and access default_idle,
>    have it simply disable_cpuidle() so acpi_idle will not load and
>    architecture default HLT will be used.
> 
> idea was to have one call - disable_cpuidle() which would make
> pm_idle not be molested by other code. It disallows cpuidle_idle_call
> to be set to pm_idle (which is excellent). But in the select_idle_routine()
> and idle_setup(), the pm_idle can still be set to either:
> amd_e400_idle, mwait_idle or default_idle. This depends on some
> CPU flags (MWAIT) and in AMD case on the type of CPU.
> 
> In case of mwait_idle we can hit some instances where the hypervisor
> (Amazon EC2 specifically) sets the MWAIT and we get:
> 
> Brought up 2 CPUs
> invalid opcode: 0000 [#1] SMP
> CPU 1
> Modules linked in:
> 
> Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
> RIP: e030:[<ffffffff81015d1d>]  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
> RSP: e02b:ffff8801d28ddf10  EFLAGS: 00010082
> RAX: ffff8801d28dc010 RBX: ffff8801d28ddfd8 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> RBP: ffff8801d28ddf10 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000000001 R11: ffff8801d28ddfd8 R12: ffffffff81b590d0
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> FS:  0000000000000000(0000) GS:ffff8801dff81000(0000) knlGS:0000000000000000
> CS:  e033 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
> Process swapper (pid: 0, threadinfo ffff8801d28dc000, task ffff8801d28cae60)
> Stack:
>  ffff8801d28ddf40 ffffffff8100e2ed ffff8801dff8e390 c136dfe72feab515
>  0000000000000000 0000000000000000 ffff8801d28ddf50 ffffffff8149ee78
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> Call Trace:
>  [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
>  [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
> RIP  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
>  RSP <ffff8801d28ddf10>
> 
> In case of amd_e400_idle we don't get so spectacular crashes, but
> we do end up making an MSR which is trapped in the hypervisor,
> and then follow it up with a yield hypercall. Meaning we end up
> going to hypervisor twice instead of just once.
> 
> The previous behavior before v3.0 was that pm_idle was set
> to default_idle irregardless of select_idle_routine/idle_setup.
> 
> We want to do that, but only for one specific case: Xen.
> This patch does that.
> 
> Fixes RH BZ #739499 and Ubuntu #881076
> Reported-by: Stefan Bader <stefan.bader@canonical.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
>  arch/x86/include/asm/system.h |    1 +
>  arch/x86/kernel/process.c     |    8 ++++++++
>  arch/x86/xen/setup.c          |    2 +-
>  3 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
> index c2ff2a1..2d2f01c 100644
> --- a/arch/x86/include/asm/system.h
> +++ b/arch/x86/include/asm/system.h
> @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>  
>  void default_idle(void);
> +bool set_pm_idle_to_default(void);
>  
>  void stop_this_cpu(void *dummy);
>  
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 1f7f8c8..31f47ba 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -404,6 +404,14 @@ void default_idle(void)
>  EXPORT_SYMBOL(default_idle);
>  #endif
>  
> +bool set_pm_idle_to_default(void)
> +{
> +	bool ret = !!pm_idle;
> +
> +	pm_idle = default_idle;
> +
> +	return ret;
> +}
>  void stop_this_cpu(void *dummy)
>  {
>  	local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..79dfb57 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
>  #endif
>  	disable_cpuidle();
>  	boot_option_idle_override = IDLE_HALT;
> -
> +	WARN_ON(set_pm_idle_to_default());
>  	fiddle_vdso();
>  }

>From what I can see, you get the following callchain:

start_kernel
|-> setup_arch
    |-> x86_init.oem.arch_setup = xen_arch_setup
    ....
    |-> check_bugs
        |-> identify_boot_cpu
	    |-> identify_cpu
	        |-> select_idle_routine


so xen_arch_setup will set pm_idle and select_idle_routine will honour
it. I'm being told this is run either in the dom0 or the paravirt guest
and if so, I don't see any issue with this for baremetal. So you can
have my ACK provided this is tested on baremetal too.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1

[Konrad Rzeszutek Wilk]

> >From what I can see, you get the following callchain:
> 
> start_kernel
> |-> setup_arch
>     |-> x86_init.oem.arch_setup = xen_arch_setup
>     ....
>     |-> check_bugs
>         |-> identify_boot_cpu
> 	    |-> identify_cpu
> 	        |-> select_idle_routine
> 
> 
> so xen_arch_setup will set pm_idle and select_idle_routine will honour
> it. I'm being told this is run either in the dom0 or the paravirt guest
> and if so, I don't see any issue with this for baremetal. So you can
> have my ACK provided this is tested on baremetal too.

Tested on baremetal and there were no abnormalities. Thanks!

Re: 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Markus Trippelsdorf]

On 2011.12.21 at 00:54 +0100, Rafael J. Wysocki wrote:
> Subject    : WARNING: at fs/sysfs/sysfs.h:195 (during boot)
> Submitter  : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
> Date       : 2011-11-13 19:24
> Message-ID : 20111113192417.GA1659-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132121231921932&w=2
> 
> Subject    : WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
> Submitter  : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
> Date       : 2011-11-18 7:25
> Message-ID : 20111118072519.GA1615-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132160119031794&w=2

Both entries were caused by the same Radeon kexec writeback bug. This issue
will hopefully be fixed in the next release.

> Subject    : Impossible high cpu-time values for migration threads
> Submitter  : Markus Trippelsdorf <markus-xp2qqqlHh3xzoYq+O6RWwA@public.gmane.org>
> Date       : 2011-11-17 22:17
> Message-ID : 20111117221731.GA9229-tLCgZGx+iJ+kxVt8IV0GqQ@public.gmane.org
> References : http://marc.info/?l=linux-kernel&m=132156832124314&w=2

This is a cosmetic issue, but I'm still seeing this after bursts of high
CPU usage:

 % ps afx -F
UID        PID  PPID  C    SZ   RSS PSR STIME TTY      STAT   TIME CMD
root         2     0  0     0     0   1 Dec20 ?        S      0:00 [kthreadd]
root         3     2  0     0     0   0 Dec20 ?        S      0:01  \_ [ksoftirqd/0]
root         6     2  0     0     0   0 Dec20 ?        S      0:00  \_ [migration/0]
root         7     2  0     0     0   1 Dec20 ?        S      0:00  \_ [migration/1]
root         8     2  0     0     0   1 Dec20 ?        S      0:05  \_ [kworker/1:0]
root         9     2  0     0     0   1 Dec20 ?        S      0:01  \_ [ksoftirqd/1]
root        11     2  0     0     0   2 Dec20 ?        S      0:00  \_ [migration/2]
root        13     2  0     0     0   2 Dec20 ?        S      0:01  \_ [ksoftirqd/2]
root        14     2 22     0     0   3 Dec20 ?        S    192:21  \_ [migration/3]
root        16     2  0     0     0   3 Dec20 ?        S      0:01  \_ [ksoftirqd/3]
root        17     2  0     0     0   2 Dec20 ?        S<     0:00  \_ [khelper]
...

-- 
Markus

Re: 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Michel Dänzer]

On Mit, 2011-12-21 at 00:39 +0100, Rafael J. Wysocki wrote: 
> 
> Subject    : [BUG] 3.2-rcX radeon KMS system freeze
> Submitter  : Bob Tracy <rct@gherkin.frus.com>
> Date       : 2011-11-25 20:33
> Message-ID : 20111125203351.GA3651@gherkin.frus.com
> References : http://marc.info/?l=linux-kernel&m=132225331312019&w=2

Is that really a (recent) regression? It sounds like Bob's only getting
things working for the first time, and I can't see any mention of a
previous working kernel version.

Anyway, might be worth following up on this on the dri-devel list with
more information, e.g. the dmesg output and Xorg.0.log corresponding to
the freeze.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: 3.2-rc6+: Reported regressions from 3.0 and 3.1

[Alex Deucher]

2011/12/21 Michel Dänzer <michel@daenzer.net>:
> On Mit, 2011-12-21 at 00:39 +0100, Rafael J. Wysocki wrote:
>>
>> Subject    : [BUG] 3.2-rcX radeon KMS system freeze
>> Submitter  : Bob Tracy <rct@gherkin.frus.com>
>> Date       : 2011-11-25 20:33
>> Message-ID : 20111125203351.GA3651@gherkin.frus.com
>> References : http://marc.info/?l=linux-kernel&m=132225331312019&w=2
>
> Is that really a (recent) regression? It sounds like Bob's only getting
> things working for the first time, and I can't see any mention of a
> previous working kernel version.
>
> Anyway, might be worth following up on this on the dri-devel list with
> more information, e.g. the dmesg output and Xorg.0.log corresponding to
> the freeze.

Has KMS or recent mesa even been tested on Alpha?  If anything it
seems like it's probably a mesa bug rather than a kernel bug as it
seems to lock up when the desktop effects are loaded.

Alex