2.6.35-rc2-git2: Reported regressions from 2.6.34

2.6.35-rc2-git2: Reported regressions from 2.6.34

[Rafael J. Wysocki]

[NOTES:
 * This by no means is a complete list, but we only put e-mail reports that
   are at least 1 week old into the Bugzilla.
 * Quite a few of the already reported regressions may be related to the bug
   fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
   bug in scrup, vt.c"), so reporters please retest with this commit applied.]

This message contains a list of some regressions from 2.6.34,
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 2.6.34, 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
  ----------------------------------------
  2010-06-09       15       13          10


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16163
Subject		: [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
Submitter	: David John <davidjon@xenontk.org>
Date		: 2010-06-02 12:52 (7 days old)
Message-ID	: <4C065423.3000202@xenontk.org>
References	: http://marc.info/?l=linux-kernel&m=127548313828613&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16161
Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
Submitter	: Mikael Pettersson <mikpe@it.uu.se>
Date		: 2010-06-01 19:57 (8 days old)
Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
References	: http://marc.info/?l=linux-kernel&m=127542227511925&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16160
Subject		: 2.6.35 Radeon KMS power management regression?
Submitter	: Nigel Cunningham <ncunningham@crca.org.au>
Date		: 2010-06-01 6:23 (8 days old)
Message-ID	: <4C04A767.8000209@crca.org.au>
References	: http://marc.info/?l=linux-kernel&m=127537343722290&w=2


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16145
Subject		: Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
Submitter	: Tom Gundersen <teg@jklm.no>
Date		: 2010-06-07 13:11 (2 days old)
Handled-By	: Venkatesh Pallipadi <venki@google.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
Subject		: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
Submitter	: Jan Kreuzer <kontrollator@gmx.de>
Date		: 2010-06-05 06:15 (4 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16122
Subject		: 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2010-06-04 13:18 (5 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16120
Subject		: Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
Submitter	: Alex Zhavnerchik <alex.vizor@gmail.com>
Date		: 2010-06-04 09:25 (5 days old)
Handled-By	: Eric Dumazet <eric.dumazet@gmail.com>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16104
Subject		: Radeon KMS does not start after merge of the new PM-Code
Submitter	: Jan Kreuzer <kontrollator@gmx.de>
Date		: 2010-06-02 07:47 (7 days old)


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16090
Subject		: sysfs: cannot create duplicate filename
Submitter	: Tobias <devnull@plzk.org>
Date		: 2010-06-01 15:59 (8 days old)
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16037
Subject		: NULL Pointer dereference in __ir_input_register/budget_ci_attach
Submitter	: Sean Finney <seanius@debian.org>
Date		: 2010-05-23 19:52 (17 days old)


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

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16131
Subject		: kernel BUG at fs/btrfs/extent-tree.c:4363 (btrfs_free_tree_block)
Submitter	: Chow Loong Jin <hyperair@ubuntu.com>
Date		: 2010-06-05 18:53 (4 days old)
Handled-By	: Yan Zheng <zheng.yan@oracle.com>
Patch		: https://patchwork.kernel.org/patch/103235/


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16127
Subject		: Boot freeze on HP Compaq nx6325 (RS482) with Radeon KMS
Submitter	: Jure Repinc <jlp.bugs@gmail.com>
Date		: 2010-06-04 21:14 (5 days old)
Handled-By	: Dave Airlie <airlied@linux.ie>
Patch		: https://bugzilla.kernel.org/attachment.cgi?id=26677


Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16092
Subject		: Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2010-06-01 18:08 (8 days old)
Handled-By	: Venki <venki@google.com>
Patch		: https://bugzilla.kernel.org/show_bug.cgi?id=16092#c2


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 2.6.34,
unresolved as well as resolved, at:

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

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

Thanks!

[Bug #16037] NULL Pointer dereference in __ir_input_register/budget_ci_attach

[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 2.6.34.  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=16037
Subject		: NULL Pointer dereference in __ir_input_register/budget_ci_attach
Submitter	: Sean Finney <seanius@debian.org>
Date		: 2010-05-23 19:52 (17 days old)

[Bug #16092] Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb

[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 2.6.34.  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=16092
Subject		: Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb
Submitter	: Christian Casteyde <casteyde.christian@free.fr>
Date		: 2010-06-01 18:08 (8 days old)
Handled-By	: Venki <venki@google.com>
Patch		: https://bugzilla.kernel.org/show_bug.cgi?id=16092#c2

[Bug #16120] Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)

[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 2.6.34.  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=16120
Subject		: Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
Submitter	: Alex Zhavnerchik <alex.vizor@gmail.com>
Date		: 2010-06-04 09:25 (5 days old)
Handled-By	: Eric Dumazet <eric.dumazet@gmail.com>

[Bug #16090] sysfs: cannot create duplicate filename

[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 2.6.34.  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=16090
Subject		: sysfs: cannot create duplicate filename
Submitter	: Tobias <devnull@plzk.org>
Date		: 2010-06-01 15:59 (8 days old)
Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>

[Bug #16127] Boot freeze on HP Compaq nx6325 (RS482) with Radeon KMS

[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 2.6.34.  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=16127
Subject		: Boot freeze on HP Compaq nx6325 (RS482) with Radeon KMS
Submitter	: Jure Repinc <jlp.bugs@gmail.com>
Date		: 2010-06-04 21:14 (5 days old)
Handled-By	: Dave Airlie <airlied@linux.ie>
Patch		: https://bugzilla.kernel.org/attachment.cgi?id=26677

[Bug #16129] BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2

[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 2.6.34.  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=16129
Subject		: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
Submitter	: Jan Kreuzer <kontrollator@gmx.de>
Date		: 2010-06-05 06:15 (4 days old)

[Bug #16104] Radeon KMS does not start after merge of the new PM-Code

[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 2.6.34.  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=16104
Subject		: Radeon KMS does not start after merge of the new PM-Code
Submitter	: Jan Kreuzer <kontrollator@gmx.de>
Date		: 2010-06-02 07:47 (7 days old)

[Bug #16122] 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170

[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 2.6.34.  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=16122
Subject		: 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
Date		: 2010-06-04 13:18 (5 days old)

Re: [Bug #16122] 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170

[Larry Finger]

On 06/08/2010 05:10 PM, Rafael J. Wysocki wrote:
> 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 2.6.34.  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=16122
> Subject		: 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
> Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
> Date		: 2010-06-04 13:18 (5 days old)

Still present in 2.6.35-rc2.

Larry

Re: [Bug #16122] 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170

[Rafael J. Wysocki]

On Wednesday 09 June 2010, Larry Finger wrote:
> On 06/08/2010 05:10 PM, Rafael J. Wysocki wrote:
> > 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 2.6.34.  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=16122
> > Subject		: 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
> > Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
> > Date		: 2010-06-04 13:18 (5 days old)
> 
> Still present in 2.6.35-rc2.

Thanks for the update.

Rafael

[Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[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 2.6.34.  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=16161
Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
Submitter	: Mikael Pettersson <mikpe@it.uu.se>
Date		: 2010-06-01 19:57 (8 days old)
Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
References	: http://marc.info/?l=linux-kernel&m=127542227511925&w=2

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Mikael Pettersson]

Rafael J. Wysocki wrote:
> 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 2.6.34.  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=3D16161
> Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
> ... XVR-600 related?
> Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> Date		: 2010-06-01 19:57 (8 days old)
> Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
> References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2

The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Rafael J. Wysocki]

On Wednesday, June 09, 2010, Mikael Pettersson wrote:
> Rafael J. Wysocki wrote:
> > 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 2.6.34.  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=3D16161
> > Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
> > ... XVR-600 related?
> > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> > Date		: 2010-06-01 19:57 (8 days old)
> > Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
> > References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2
> 
> The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.

Please test post-rc2 too.

Rafael

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Mikael Pettersson]

Rafael J. Wysocki writes:
 > On Wednesday, June 09, 2010, Mikael Pettersson wrote:
 > > Rafael J. Wysocki wrote:
 > > > 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 2.6.34.  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=3D16161
 > > > Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
 > > > ... XVR-600 related?
 > > > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
 > > > Date		: 2010-06-01 19:57 (8 days old)
 > > > Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
 > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2
 > > 
 > > The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.
 > 
 > Please test post-rc2 too.

The bug is still there in 2.6.35-rc2-git4.

/Mikael

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Rafael J. Wysocki]

On Thursday, June 10, 2010, Mikael Pettersson wrote:
> Rafael J. Wysocki writes:
>  > On Wednesday, June 09, 2010, Mikael Pettersson wrote:
>  > > Rafael J. Wysocki wrote:
>  > > > 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 2.6.34.  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=3D16161
>  > > > Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
>  > > > ... XVR-600 related?
>  > > > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
>  > > > Date		: 2010-06-01 19:57 (8 days old)
>  > > > Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
>  > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2
>  > > 
>  > > The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.
>  > 
>  > Please test post-rc2 too.
> 
> The bug is still there in 2.6.35-rc2-git4.

Thanks for the confirmation.

Rafael

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Mikael Pettersson]

Mikael Pettersson writes:
 > Rafael J. Wysocki writes:
 >  > On Wednesday, June 09, 2010, Mikael Pettersson wrote:
 >  > > Rafael J. Wysocki wrote:
 >  > > > 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 2.6.34.  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=3D16161
 >  > > > Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
 >  > > > ... XVR-600 related?
 >  > > > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
 >  > > > Date		: 2010-06-01 19:57 (8 days old)
 >  > > > Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
 >  > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2
 >  > > 
 >  > > The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.
 >  > 
 >  > Please test post-rc2 too.
 > 
 > The bug is still there in 2.6.35-rc2-git4.

The bug appears to be gone in 2.6.35-rc3.  I don't know which
commit actually fixed it.

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Rafael J. Wysocki]

On Saturday, June 12, 2010, Mikael Pettersson wrote:
> Mikael Pettersson writes:
>  > Rafael J. Wysocki writes:
>  >  > On Wednesday, June 09, 2010, Mikael Pettersson wrote:
>  >  > > Rafael J. Wysocki wrote:
>  >  > > > 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 2.6.34.  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=3D16161
>  >  > > > Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
>  >  > > > ... XVR-600 related?
>  >  > > > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
>  >  > > > Date		: 2010-06-01 19:57 (8 days old)
>  >  > > > Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
>  >  > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2
>  >  > > 
>  >  > > The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.
>  >  > 
>  >  > Please test post-rc2 too.
>  > 
>  > The bug is still there in 2.6.35-rc2-git4.
> 
> The bug appears to be gone in 2.6.35-rc3.

Good.

> I don't know which commit actually fixed it.

Well, it would be useful information, but it's much more important it's not
there anymore.

Rafael

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Jesse Barnes]

On Sat, 12 Jun 2010 20:52:25 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Saturday, June 12, 2010, Mikael Pettersson wrote:
> > Mikael Pettersson writes:
> >  > Rafael J. Wysocki writes:
> >  >  > On Wednesday, June 09, 2010, Mikael Pettersson wrote:
> >  >  > > Rafael J. Wysocki wrote:
> >  >  > > > 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 2.6.34.  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=3D16161
> >  >  > > > Subject		: [2.6.35-rc1 regression] sysfs: cannot create duplicate filename =
> >  >  > > > ... XVR-600 related?
> >  >  > > > Submitter	: Mikael Pettersson <mikpe@it.uu.se>
> >  >  > > > Date		: 2010-06-01 19:57 (8 days old)
> >  >  > > > Message-ID	: <19461.26166.427857.612983@pilspetsen.it.uu.se>
> >  >  > > > References	: http://marc.info/?l=3Dlinux-kernel&m=3D127542227511925&w=3D2
> >  >  > > 
> >  >  > > The bug is still there in 2.6.35-rc2. I haven't checked post-rc2 git snapshots.
> >  >  > 
> >  >  > Please test post-rc2 too.
> >  > 
> >  > The bug is still there in 2.6.35-rc2-git4.
> > 
> > The bug appears to be gone in 2.6.35-rc3.
> 
> Good.
> 
> > I don't know which commit actually fixed it.
> 
> Well, it would be useful information, but it's much more important it's not
> there anymore.

I reverted the symlink patch that was causing the trouble.  The root
cause is elsewhere though; it seems some firmwares report duplicate PCI
slot numbers...

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[David Miller]

From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri, 18 Jun 2010 13:10:49 -0700

> I reverted the symlink patch that was causing the trouble.  The root
> cause is elsewhere though; it seems some firmwares report duplicate PCI
> slot numbers...

Instead of postulating, you can confirm or deny such a theory
by taking a look at the repository of sparc openfirmware tree
dumps maintained at:

	master.kernel.org:/pub/scm/linux/kernel/git/davem/prtconfs.git

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Brian Bloniarz]

On 06/18/2010 04:26 PM, David Miller wrote:
> From: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date: Fri, 18 Jun 2010 13:10:49 -0700
> 
>> I reverted the symlink patch that was causing the trouble.  The root
>> cause is elsewhere though; it seems some firmwares report duplicate PCI
>> slot numbers...
> 
> Instead of postulating, you can confirm or deny such a theory
> by taking a look at the repository of sparc openfirmware tree
> dumps maintained at:
> 
> 	master.kernel.org:/pub/scm/linux/kernel/git/davem/prtconfs.git

(Adding Alex Chiang to the cc list)

I was actually under the impression that it was just an 
issue with the reverted patch, not an actual problem with
hardware.

In the patch, 2 individual code paths were trying to
create the same symlinks:
pci-sysfs.c:pci_create_slot_links(struct pci_dev *dev)
and
slot.c:create_sysfs_files(struct pci_slot *slot).
I think some archs managed to call those both during
initialization, and some not.

commit 75568f8094eb0333e9c2109b23cbc8b82d318a3c
Author: Alex Chiang <achiang@hp.com>
Date:   Mon Mar 8 10:24:29 2010 -0700

    PCI: create function symlinks in /sys/bus/pci/slots/N/
    
    Create convenience symlinks in sysfs, linking slots to device
    functions, and vice versa. These links make it easier for users to
    figure out which devices actually live in what slots.
    
    For example:
    
    sapphire:/sys/bus/pci/slots # ls
    1  10  2  3  4  5  6  7  8  9
    
    sapphire:/sys/bus/pci/slots # ls -l 3
    total 0
    -r--r--r-- 1 root root 65536 Aug 18 14:10 address
    lrwxrwxrwx 1 root root     0 Aug 18 14:10 function0 ->
    ../../../../devices/pci0000:23/0000:23:01.0
    lrwxrwxrwx 1 root root     0 Aug 18 14:10 function1 ->
    ../../../../devices/pci0000:23/0000:23:01.1
    
    sapphire:/sys/bus/pci/slots # ls -l 3/function0/slot
    lrwxrwxrwx 1 root root 0 Aug 18 14:13 3/function0/slot ->
    ../../../bus/pci/slots/3
    
    The original form of this patch was written by Matthew Wilcox,
    and was enhanced to include links from the sysfs slots/ directory
    pointing back at the device functions.
    
    Cc: willy@linux.intel.com
    Signed-off-by: Alex Chiang <achiang@hp.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>

diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 25be325..428676c 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -133,6 +133,46 @@ Description:
 		The symbolic link points to the PCI device sysfs entry of the
 		Physical Function this device associates with.
 
+
+What:		/sys/bus/pci/slots/...
+Date:		April 2005 (possibly older)
+KernelVersion:	2.6.12 (possibly older)
+Contact:	linux-pci@vger.kernel.org
+Description:
+		When the appropriate driver is loaded, it will create a
+		directory per claimed physical PCI slot in
+		/sys/bus/pci/slots/.  The names of these directories are
+		specific to the driver, which in turn, are specific to the
+		platform, but in general, should match the label on the
+		machine's physical chassis.
+
+		The drivers that can create slot directories include the
+		PCI hotplug drivers, and as of 2.6.27, the pci_slot driver.
+
+		The slot directories contain, at a minimum, a file named
+		'address' which contains the PCI bus:device:function tuple.
+		Other files may appear as well, but are specific to the
+		driver.
+
+What:		/sys/bus/pci/slots/.../function[0-7]
+Date:		March 2010
+KernelVersion:	2.6.35
+Contact:	linux-pci@vger.kernel.org
+Description:
+		If PCI slot directories (as described above) are created,
+		and the physical slot is actually populated with a device,
+		symbolic links in the slot directory pointing to the
+		device's PCI functions are created as well.
+
+What:		/sys/bus/pci/devices/.../slot
+Date:		March 2010
+KernelVersion:	2.6.35
+Contact:	linux-pci@vger.kernel.org
+Description:
+		If PCI slot directories (as described above) are created,
+		a symbolic link pointing to the slot directory will be
+		created as well.
+
 What:		/sys/bus/pci/slots/.../module
 Date:		June 2009
 Contact:	linux-pci@vger.kernel.org
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index fad9398..941e939 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1011,6 +1011,39 @@ error:
 	return retval;
 }
 
+static void pci_remove_slot_links(struct pci_dev *dev)
+{
+	char func[10];
+	struct pci_slot *slot;
+
+	sysfs_remove_link(&dev->dev.kobj, "slot");
+	list_for_each_entry(slot, &dev->bus->slots, list) {
+		if (slot->number != PCI_SLOT(dev->devfn))
+			continue;
+		snprintf(func, 10, "function%d", PCI_FUNC(dev->devfn));
+		sysfs_remove_link(&slot->kobj, func);
+	}
+}
+
+static int pci_create_slot_links(struct pci_dev *dev)
+{
+	int result = 0;
+	char func[10];
+	struct pci_slot *slot;
+
+	list_for_each_entry(slot, &dev->bus->slots, list) {
+		if (slot->number != PCI_SLOT(dev->devfn))
+			continue;
+		result = sysfs_create_link(&dev->dev.kobj, &slot->kobj, "slot");
+		if (result)
+			goto out;
+		snprintf(func, 10, "function%d", PCI_FUNC(dev->devfn));
+		result = sysfs_create_link(&slot->kobj, &dev->dev.kobj, func);
+	}
+out:
+	return result;
+}
+
 int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
 {
 	int retval;
@@ -1073,6 +1106,8 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
 	if (retval)
 		goto err_vga_file;
 
+	pci_create_slot_links(pdev);
+
 	return 0;
 
 err_vga_file:
@@ -1122,6 +1157,8 @@ void pci_remove_sysfs_dev_files(struct pci_dev *pdev)
 	if (!sysfs_initialized)
 		return;
 
+	pci_remove_slot_links(pdev);
+
 	pci_remove_capabilities_sysfs(pdev);
 
 	if (pdev->cfg_size < PCI_CFG_SPACE_EXP_SIZE)
diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 659eaa0..e0189cf 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -97,6 +97,50 @@ static ssize_t cur_speed_read_file(struct pci_slot *slot, char *buf)
 	return bus_speed_read(slot->bus->cur_bus_speed, buf);
 }
 
+static void remove_sysfs_files(struct pci_slot *slot)
+{
+	char func[10];
+	struct list_head *tmp;
+
+	list_for_each(tmp, &slot->bus->devices) {
+		struct pci_dev *dev = pci_dev_b(tmp);
+		if (PCI_SLOT(dev->devfn) != slot->number)
+			continue;
+		sysfs_remove_link(&dev->dev.kobj, "slot");
+
+		snprintf(func, 10, "function%d", PCI_FUNC(dev->devfn));
+		sysfs_remove_link(&slot->kobj, func);
+	}
+}
+
+static int create_sysfs_files(struct pci_slot *slot)
+{
+	int result;
+	char func[10];
+	struct list_head *tmp;
+
+	list_for_each(tmp, &slot->bus->devices) {
+		struct pci_dev *dev = pci_dev_b(tmp);
+		if (PCI_SLOT(dev->devfn) != slot->number)
+			continue;
+
+		result = sysfs_create_link(&dev->dev.kobj, &slot->kobj, "slot");
+		if (result)
+			goto fail;
+
+		snprintf(func, 10, "function%d", PCI_FUNC(dev->devfn));
+		result = sysfs_create_link(&slot->kobj, &dev->dev.kobj, func);
+		if (result)
+			goto fail;
+	}
+
+	return 0;
+
+fail:
+	remove_sysfs_files(slot);
+	return result;
+}
+
 static void pci_slot_release(struct kobject *kobj)
 {
 	struct pci_dev *dev;
@@ -109,6 +153,8 @@ static void pci_slot_release(struct kobject *kobj)
 		if (PCI_SLOT(dev->devfn) == slot->number)
 			dev->slot = NULL;
 
+	remove_sysfs_files(slot);
+
 	list_del(&slot->list);
 
 	kfree(slot);
@@ -300,6 +346,8 @@ placeholder:
 	INIT_LIST_HEAD(&slot->list);
 	list_add(&slot->list, &parent->slots);
 
+	create_sysfs_files(slot);
+
 	list_for_each_entry(dev, &parent->devices, bus_list)
 		if (PCI_SLOT(dev->devfn) == slot_nr)
 			dev->slot = slot;

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Jesse Barnes]

On Fri, 18 Jun 2010 16:40:44 -0400
Brian Bloniarz <bmb@athenacr.com> wrote:

> On 06/18/2010 04:26 PM, David Miller wrote:
> > From: Jesse Barnes <jbarnes@virtuousgeek.org>
> > Date: Fri, 18 Jun 2010 13:10:49 -0700
> > 
> >> I reverted the symlink patch that was causing the trouble.  The root
> >> cause is elsewhere though; it seems some firmwares report duplicate PCI
> >> slot numbers...
> > 
> > Instead of postulating, you can confirm or deny such a theory
> > by taking a look at the repository of sparc openfirmware tree
> > dumps maintained at:
> > 
> > 	master.kernel.org:/pub/scm/linux/kernel/git/davem/prtconfs.git
> 
> (Adding Alex Chiang to the cc list)
> 
> I was actually under the impression that it was just an 
> issue with the reverted patch, not an actual problem with
> hardware.

Yeah, I think you're right.  I reverted it at Alex's request and
assumed it was a firmware or configuration problem.  Looking at the
thread again I see that was a bad assumption.

> In the patch, 2 individual code paths were trying to
> create the same symlinks:
> pci-sysfs.c:pci_create_slot_links(struct pci_dev *dev)
> and
> slot.c:create_sysfs_files(struct pci_slot *slot).
> I think some archs managed to call those both during
> initialization, and some not.

Well that would explain it too.  I'm happy to take a fixed up patch if
there's demand.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[David Miller]

From: Brian Bloniarz <bmb@athenacr.com>
Date: Fri, 18 Jun 2010 16:40:44 -0400

> In the patch, 2 individual code paths were trying to
> create the same symlinks:
> pci-sysfs.c:pci_create_slot_links(struct pci_dev *dev)
> and
> slot.c:create_sysfs_files(struct pci_slot *slot).
> I think some archs managed to call those both during
> initialization, and some not.

Right, and if I recall correctly when adding sparc64 support for
the sysfs slot stuff if you wanted to create the slots in a
non-hotplug situation (which all of the sparc64 cases are) you
had to defer the sysfs node creation to later in the boot than
when the PCI buses are actually probed and populated.

Re: [Bug #16161] [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?

[Alex Chiang]

* David Miller <davem@davemloft.net>:
> From: Brian Bloniarz <bmb@athenacr.com>
> Date: Fri, 18 Jun 2010 16:40:44 -0400
> 
> > In the patch, 2 individual code paths were trying to
> > create the same symlinks:
> > pci-sysfs.c:pci_create_slot_links(struct pci_dev *dev)
> > and
> > slot.c:create_sysfs_files(struct pci_slot *slot).
> > I think some archs managed to call those both during
> > initialization, and some not.
> 
> Right, and if I recall correctly when adding sparc64 support for
> the sysfs slot stuff if you wanted to create the slots in a
> non-hotplug situation (which all of the sparc64 cases are) you
> had to defer the sysfs node creation to later in the boot than
> when the PCI buses are actually probed and populated.

Yeah, we call pci_create_sysfs_dev_files() from pci_sysfs_init()
and from pci_bus_add_device().

I haven't figured out why it is that creating other sysfs files,
e.g. rom files, capabilities, etc. don't also result in duplicate
entries while the slots do.

Clearly my expectation was incorrect for the cases when
pci_create_sysfs_dev_files() gets called on the different
architectures.

Anyhow, thanks for the revert Jesse. I wish I had more
time/energy to dig into this right now, but I really don't.
Sorry.

/ac

[Bug #16160] 2.6.35 Radeon KMS power management 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 2.6.34.  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=16160
Subject		: 2.6.35 Radeon KMS power management regression?
Submitter	: Nigel Cunningham <ncunningham@crca.org.au>
Date		: 2010-06-01 6:23 (8 days old)
Message-ID	: <4C04A767.8000209@crca.org.au>
References	: http://marc.info/?l=linux-kernel&m=127537343722290&w=2

[Bug #16131] kernel BUG at fs/btrfs/extent-tree.c:4363 (btrfs_free_tree_block)

[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 2.6.34.  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=16131
Subject		: kernel BUG at fs/btrfs/extent-tree.c:4363 (btrfs_free_tree_block)
Submitter	: Chow Loong Jin <hyperair@ubuntu.com>
Date		: 2010-06-05 18:53 (4 days old)
Handled-By	: Yan Zheng <zheng.yan@oracle.com>
Patch		: https://patchwork.kernel.org/patch/103235/

[Bug #16145] Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"

[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 2.6.34.  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=16145
Subject		: Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
Submitter	: Tom Gundersen <teg@jklm.no>
Date		: 2010-06-07 13:11 (2 days old)
Handled-By	: Venkatesh Pallipadi <venki@google.com>

[Bug #16163] [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off

[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 2.6.34.  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=16163
Subject		: [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
Submitter	: David John <davidjon@xenontk.org>
Date		: 2010-06-02 12:52 (7 days old)
Message-ID	: <4C065423.3000202@xenontk.org>
References	: http://marc.info/?l=linux-kernel&m=127548313828613&w=2

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Linus Torvalds]

[ Added lots of cc's to direct specific people to look at the regressions 
  that may or may not be theirs... ]

On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
>
>  * Quite a few of the already reported regressions may be related to the bug
>    fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
>    bug in scrup, vt.c"), so reporters please retest with this commit applied.]

>From a quick look, most of them look unrelated to that unfortunate bug. 
It's hard to tell for sure, of course (memory corruption can do pretty 
much anything), but I'm not seeing the 07200720.. pattern at least.

And some of them do seem to be bisected to likely culprits and/or have 
patches that are claimed to have fixed them.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16163
> Subject	: [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> Submitter	: David John <davidjon@xenontk.org>
> Date		: 2010-06-02 12:52 (7 days old)
> Message-ID	: <4C065423.3000202@xenontk.org>
> References	: http://marc.info/?l=linux-kernel&m=127548313828613&w=2

That has a "reverting the commit fixes it", and a confirmation from Nick 
Bowler.

Eric, Carl: should I just revert that commit? Or do you have a fix?

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16145
> Subject	: Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
> Submitter	: Tom Gundersen <teg@jklm.no>
> Date		: 2010-06-07 13:11 (2 days old)
> Handled-By	: Venkatesh Pallipadi <venki@google.com>

Hmm. This does seem to be a properly bisected commit, but at the same time 
it looks from the bugzilla like it's just pure luck on that machine that 
the acpi_pad driver happened to mark TSC unstable - so while the commit 
bisected is the real one, it's not the "deeper reason" for the problem.

Venki, any updates?

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> Date		: 2010-06-05 06:15 (4 days old)

This seems to have been introduced by

	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
	Author: Ingo Molnar <mingo@elte.hu>
	Date:   Sat Nov 8 17:05:38 2008 +0100

	    sched: optimize sched_clock() a bit
    
	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
	    variant of __cycles_2_ns().
    
	    Most of the time sched_clock() is called with irqs disabled already.
	    The few places that call it with irqs enabled need to be updated.
    
	    Signed-off-by: Ingo Molnar <mingo@elte.hu>

and this seems to be one of those calling cases that need to be updated.

Ingo? The call trace is:

	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
	caller is native_sched_clock+0x3c/0x68
	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
	Call Trace:
	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
	[<ffffffff8101043d>] sched_clock+0x9/0xd
	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
	[<ffffffff81215537>] __make_request+0x338/0x45b
	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
	[<ffffffff81214909>] submit_bio+0xd2/0xef
	[<ffffffff811413cb>] submit_bh+0xf4/0x116
	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
	[<ffffffff81144875>] block_write_full_page+0x15/0x17
	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
	[<ffffffff810e1f91>] __writepage+0x1a/0x39
	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
	[<ffffffff810e3406>] generic_writepages+0x27/0x29
	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
	[<ffffffff811d0cba>] kjournald2+0x147/0x37a

(from the bugzilla thing)

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16122
> Subject	: 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
> Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
> Date		: 2010-06-04 13:18 (5 days old)

Jens?

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16120
> Subject	: Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
> Submitter	: Alex Zhavnerchik <alex.vizor@gmail.com>
> Date		: 2010-06-04 09:25 (5 days old)
> Handled-By	: Eric Dumazet <eric.dumazet@gmail.com>

This one seems to have a patch in bugzilla.

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16104
> Subject	: Radeon KMS does not start after merge of the new PM-Code
> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> Date		: 2010-06-02 07:47 (7 days old)

This one also has a patch in Bugzilla, I think Airlie is just waiting to 
calm down his queue and already removed the dependency on the temperature 
code. DaveA?

> Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=16161
> Subject       : [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
> Submitter     : Mikael Pettersson <mikpe@it.uu.se>
> Date          : 2010-06-01 19:57 (8 days old)
> Message-ID    : <19461.26166.427857.612983@pilspetsen.it.uu.se>
> References    : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
>
> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16090
> Subject	: sysfs: cannot create duplicate filename
> Submitter	: Tobias <devnull@plzk.org>
> Date		: 2010-06-01 15:59 (8 days old)
> Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>

These two look related. Both are related to that "slot" thing in sysfs 
PCI, but only one of them is marked as Jesse's. Jesse?

> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16037
> Subject	: NULL Pointer dereference in __ir_input_register/budget_ci_attach
> Submitter	: Sean Finney <seanius@debian.org>
> Date		: 2010-05-23 19:52 (17 days old)

Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?

David Härdeman, Mauro Carvalho Chehab added to cc.

				Linus

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Mauro Carvalho Chehab]

Em 08-06-2010 22:53, Linus Torvalds escreveu:

> 
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16037
>> Subject	: NULL Pointer dereference in __ir_input_register/budget_ci_attach
>> Submitter	: Sean Finney <seanius@debian.org>
>> Date		: 2010-05-23 19:52 (17 days old)
> 
> Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?
> 
> David Härdeman, Mauro Carvalho Chehab added to cc.

This patch probably solves the issue:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=84b14f181a36eea6591779156ef356f8d198bbfd

The patch were already applied upstream. I've already asked the reporter to test it, via BZ.

Cheers,
Mauro

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Rafael J. Wysocki]

On Wednesday 09 June 2010, Mauro Carvalho Chehab wrote:
> Em 08-06-2010 22:53, Linus Torvalds escreveu:
> 
> > 
> >> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16037
> >> Subject	: NULL Pointer dereference in __ir_input_register/budget_ci_attach
> >> Submitter	: Sean Finney <seanius@debian.org>
> >> Date		: 2010-05-23 19:52 (17 days old)
> > 
> > Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?
> > 
> > David Härdeman, Mauro Carvalho Chehab added to cc.
> 
> This patch probably solves the issue:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=84b14f181a36eea6591779156ef356f8d198bbfd
> 
> The patch were already applied upstream. I've already asked the reporter to test it, via BZ.

Confirmed fixed, so closing.

Thanks,
Rafael

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Tue, 8 Jun 2010 18:53:55 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And some of them do seem to be bisected to likely culprits and/or have 
> patches that are claimed to have fixed them.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16163
> > Subject	: [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> > Submitter	: David John <davidjon@xenontk.org>
> > Date		: 2010-06-02 12:52 (7 days old)
> > Message-ID	: <4C065423.3000202@xenontk.org>
> > References	: http://marc.info/?l=linux-kernel&m=127548313828613&w=2
> 
> That has a "reverting the commit fixes it", and a confirmation from Nick 
> Bowler.
> 
> Eric, Carl: should I just revert that commit? Or do you have a fix?

I'm not aware of any real fix here. That commit isn't supposed to change
much, but it clearly unmasks some broken driver code.

So reverting it for now to hide the broken code from poor users does
seem a good plan to me, (unless Eric has any updates or alternate
suggestions).

-Carl

-- 
carl.d.worth@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
> > Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> > Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> > Date		: 2010-06-05 06:15 (4 days old)
> 
> This seems to have been introduced by
> 
> 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> 	Author: Ingo Molnar <mingo@elte.hu>
> 	Date:   Sat Nov 8 17:05:38 2008 +0100
> 
> 	    sched: optimize sched_clock() a bit
>     
> 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> 	    variant of __cycles_2_ns().
>     
> 	    Most of the time sched_clock() is called with irqs disabled already.
> 	    The few places that call it with irqs enabled need to be updated.
>     
> 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> and this seems to be one of those calling cases that need to be updated.

That's a commit from 2008.

> Ingo? The call trace is:
> 
> 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> 	caller is native_sched_clock+0x3c/0x68
> 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> 	Call Trace:
> 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> 	[<ffffffff8101043d>] sched_clock+0x9/0xd
> 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
> 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> 	[<ffffffff81215537>] __make_request+0x338/0x45b
> 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> 	[<ffffffff81214909>] submit_bio+0xd2/0xef
> 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
> 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
> 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
> 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
> 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
> 
> (from the bugzilla thing)

The warning was introduced by this fresh commit (and a followup commit) merged 
in the .35 merge window:

 | commit 9195291e5f05e01d67f9a09c756b8aca8f009089
 | Author: Divyesh Shah <dpshah@google.com>
 | Date:   Thu Apr 1 15:01:41 2010 -0700
 | 
 |     blkio: Increment the blkio cgroup stats for real now

IIRC Jens posted a fix for the regression. Jens, what's the status of that?

As the code there started using a raw sched_clock() call for block statistics 
purposes, which was a poorly thought out (and buggy) approach:

 - it takes timestamps on different cpus and then compares then, but doesnt 
   consider that sched_clock() is not comparable between CPUs without extra 
   care

 - it doesnt consider the possibility for the sched_clock() result going
   backwards on certain platforms (such as x86)

 - it doesnt consider preemptability

(There's work ongoing to add a clock variant that can be used for such 
purposes, but that's .36 fodder.)

Thanks,

	Ingo

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Eric Dumazet]

Le mardi 08 juin 2010 à 18:53 -0700, Linus Torvalds a écrit :

> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16120
> > Subject	: Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
> > Submitter	: Alex Zhavnerchik <alex.vizor@gmail.com>
> > Date		: 2010-06-04 09:25 (5 days old)
> > Handled-By	: Eric Dumazet <eric.dumazet@gmail.com>
> 
> This one seems to have a patch in bugzilla.

Yep, commit 035320d54758e21227987e3aae0d46e7a04f4ddc in David net-2.6
tree, i'll be included in its next pull request.

http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=035320d54758e21227987e3aae0d46e7a04f4ddc

Thanks

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 2010-06-09 03:53, Linus Torvalds wrote:
>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
>> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
>> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
>> Date		: 2010-06-05 06:15 (4 days old)
> 
> This seems to have been introduced by
> 
> 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> 	Author: Ingo Molnar <mingo@elte.hu>
> 	Date:   Sat Nov 8 17:05:38 2008 +0100
> 
> 	    sched: optimize sched_clock() a bit
>     
> 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> 	    variant of __cycles_2_ns().
>     
> 	    Most of the time sched_clock() is called with irqs disabled already.
> 	    The few places that call it with irqs enabled need to be updated.
>     
> 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> and this seems to be one of those calling cases that need to be updated.
> 
> Ingo? The call trace is:
> 
> 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> 	caller is native_sched_clock+0x3c/0x68
> 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> 	Call Trace:
> 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> 	[<ffffffff8101043d>] sched_clock+0x9/0xd
> 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
> 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> 	[<ffffffff81215537>] __make_request+0x338/0x45b
> 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> 	[<ffffffff81214909>] submit_bio+0xd2/0xef
> 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
> 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
> 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
> 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
> 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
> 
> (from the bugzilla thing)

This should be fixed by commit 28f4197e which was merged on friday.

>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16122
>> Subject	: 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
>> Submitter	: Larry Finger <Larry.Finger@lwfinger.net>
>> Date		: 2010-06-04 13:18 (5 days old)
> 
> Jens?

Looking into this one.

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Rafael J. Wysocki]

On Wednesday 09 June 2010, Jens Axboe wrote:
> On 2010-06-09 03:53, Linus Torvalds wrote:
> >> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
> >> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> >> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> >> Date		: 2010-06-05 06:15 (4 days old)
> > 
> > This seems to have been introduced by
> > 
> > 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> > 	Author: Ingo Molnar <mingo@elte.hu>
> > 	Date:   Sat Nov 8 17:05:38 2008 +0100
> > 
> > 	    sched: optimize sched_clock() a bit
> >     
> > 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> > 	    variant of __cycles_2_ns().
> >     
> > 	    Most of the time sched_clock() is called with irqs disabled already.
> > 	    The few places that call it with irqs enabled need to be updated.
> >     
> > 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > 
> > and this seems to be one of those calling cases that need to be updated.
> > 
> > Ingo? The call trace is:
> > 
> > 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> > 	caller is native_sched_clock+0x3c/0x68
> > 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> > 	Call Trace:
> > 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> > 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> > 	[<ffffffff8101043d>] sched_clock+0x9/0xd
> > 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> > 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
> > 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> > 	[<ffffffff81215537>] __make_request+0x338/0x45b
> > 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> > 	[<ffffffff81214909>] submit_bio+0xd2/0xef
> > 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
> > 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> > 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
> > 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> > 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
> > 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> > 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
> > 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> > 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> > 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
> > 
> > (from the bugzilla thing)
> 
> This should be fixed by commit 28f4197e which was merged on friday.

Thanks, closed.

Rafael

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Ingo Molnar]

* Jens Axboe <jaxboe@fusionio.com> wrote:

> On 2010-06-09 03:53, Linus Torvalds wrote:
> >> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
> >> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> >> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> >> Date		: 2010-06-05 06:15 (4 days old)
> > 
> > This seems to have been introduced by
> > 
> > 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> > 	Author: Ingo Molnar <mingo@elte.hu>
> > 	Date:   Sat Nov 8 17:05:38 2008 +0100
> > 
> > 	    sched: optimize sched_clock() a bit
> >     
> > 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> > 	    variant of __cycles_2_ns().
> >     
> > 	    Most of the time sched_clock() is called with irqs disabled already.
> > 	    The few places that call it with irqs enabled need to be updated.
> >     
> > 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > 
> > and this seems to be one of those calling cases that need to be updated.
> > 
> > Ingo? The call trace is:
> > 
> > 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> > 	caller is native_sched_clock+0x3c/0x68
> > 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> > 	Call Trace:
> > 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> > 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> > 	[<ffffffff8101043d>] sched_clock+0x9/0xd
> > 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> > 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
> > 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> > 	[<ffffffff81215537>] __make_request+0x338/0x45b
> > 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> > 	[<ffffffff81214909>] submit_bio+0xd2/0xef
> > 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
> > 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> > 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
> > 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> > 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
> > 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> > 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
> > 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> > 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> > 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
> > 
> > (from the bugzilla thing)
> 
> This should be fixed by commit 28f4197e which was merged on friday.

The scheduler commit adding local_clock() (for .36) is:

  c676329: sched_clock: Add local_clock() API and improve documentation

So once that is upstream the block IO statistics code can use that.

Thanks,

	Ingo

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 2010-06-09 11:32, Ingo Molnar wrote:
>> This should be fixed by commit 28f4197e which was merged on friday.
> 
> The scheduler commit adding local_clock() (for .36) is:
> 
>   c676329: sched_clock: Add local_clock() API and improve documentation
> 
> So once that is upstream the block IO statistics code can use that.

Thanks, I'll have to make a note of that.

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 2010-06-11 10:32, Ingo Molnar wrote:
> 
> * Jens Axboe <jaxboe@fusionio.com> wrote:
> 
>> On 2010-06-09 03:53, Linus Torvalds wrote:
>>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
>>>> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
>>>> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
>>>> Date		: 2010-06-05 06:15 (4 days old)
>>>
>>> This seems to have been introduced by
>>>
>>> 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
>>> 	Author: Ingo Molnar <mingo@elte.hu>
>>> 	Date:   Sat Nov 8 17:05:38 2008 +0100
>>>
>>> 	    sched: optimize sched_clock() a bit
>>>     
>>> 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
>>> 	    variant of __cycles_2_ns().
>>>     
>>> 	    Most of the time sched_clock() is called with irqs disabled already.
>>> 	    The few places that call it with irqs enabled need to be updated.
>>>     
>>> 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>>
>>> and this seems to be one of those calling cases that need to be updated..
>>>
>>> Ingo? The call trace is:
>>>
>>> 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
>>> 	caller is native_sched_clock+0x3c/0x68
>>> 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
>>> 	Call Trace:
>>> 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
>>> 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
>>> 	[<ffffffff8101043d>] sched_clock+0x9/0xd
>>> 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
>>> 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
>>> 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
>>> 	[<ffffffff81215537>] __make_request+0x338/0x45b
>>> 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
>>> 	[<ffffffff81214909>] submit_bio+0xd2/0xef
>>> 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
>>> 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
>>> 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
>>> 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
>>> 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
>>> 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
>>> 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
>>> 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
>>> 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
>>> 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
>>>
>>> (from the bugzilla thing)
>>
>> This should be fixed by commit 28f4197e which was merged on friday.
> 
> Hm, it's still not entirely fixed, as of 2.6.35-rc2-00131-g7908a9e. With some 
> configs i get bad spinlock warnings during bootup:
> 
> [   28.968013] initcall net_olddevs_init+0x0/0x82 returned 0 after 93750 usecs
> [   28.972003] calling  b44_init+0x0/0x55 @ 1
> [   28.976009] bus: 'pci': add driver b44
> [   28.976374]  sda:
> [   28.978157] BUG: spinlock bad magic on CPU#1, async/0/117
> [   28.980000]  lock: 7e1c5bbc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> [   28.980000] Pid: 117, comm: async/0 Not tainted 2.6.35-rc2-tip-01092-g010e7ef-dirty #8183
> [   28.980000] Call Trace:
> [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
> [   28.980000]  [<4134b7b7>] spin_bug+0x7c/0x87
> [   28.980000]  [<4134b853>] do_raw_spin_lock+0x1e/0x123
> [   28.980000]  [<41ba92ca>] ? _raw_spin_lock_irqsave+0x12/0x20
> [   28.980000]  [<41ba92d2>] _raw_spin_lock_irqsave+0x1a/0x20
> [   28.980000]  [<4133476f>] blkiocg_update_io_add_stats+0x25/0xfb
> [   28.980000]  [<41335dae>] ? cfq_prio_tree_add+0xb1/0xc1
> [   28.980000]  [<41337bc7>] cfq_insert_request+0x8c/0x425
> [   28.980000]  [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
> [   28.980000]  [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
> [   28.980000]  [<41329225>] elv_insert+0x107/0x1a0
> [   28.980000]  [<41329354>] __elv_add_request+0x96/0x9d
> [   28.980000]  [<4132bb8c>] ? drive_stat_acct+0x9d/0xc6
> [   28.980000]  [<4132dd64>] __make_request+0x335/0x376
> [   28.980000]  [<4132c726>] generic_make_request+0x336/0x39d
> [   28.980000]  [<410ad422>] ? kmem_cache_alloc+0xa1/0x105
> [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
> [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
> [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
> [   28.980000]  [<41089347>] ? mempool_alloc+0x57/0xe2
> [   28.980000]  [<4132c804>] submit_bio+0x77/0x8f
> [   28.980000]  [<410d2cbc>] ? bio_alloc_bioset+0x37/0x94
> [   28.980000]  [<410ceb90>] submit_bh+0xc3/0xe2
> [   28.980000]  [<410d1474>] block_read_full_page+0x249/0x259
> [   28.980000]  [<410d31fb>] ? blkdev_get_block+0x0/0xc6
> [   28.980000]  [<41087bfa>] ? add_to_page_cache_locked+0x94/0xb5
> [   28.980000]  [<410d3d92>] blkdev_readpage+0xf/0x11
> [   28.980000]  [<41088823>] do_read_cache_page+0x7d/0x11a
> [   28.980000]  [<410d3d83>] ? blkdev_readpage+0x0/0x11
> [   28.980000]  [<410888f4>] read_cache_page_async+0x16/0x1b
> [   28.980000]  [<41088904>] read_cache_page+0xb/0x12
> [   28.980000]  [<410e80e1>] read_dev_sector+0x2a/0x63
> [   28.980000]  [<410e92e8>] adfspart_check_ICS+0x2e/0x166
> [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
> [   28.980000]  [<410e8d23>] rescan_partitions+0x196/0x3e4
> [   28.980000]  [<41ba7dc7>] ? __mutex_unlock_slowpath+0x98/0x9f
> [   28.980000]  [<410e92ba>] ? adfspart_check_ICS+0x0/0x166
> [   28.980000]  [<410d4277>] __blkdev_get+0x1e7/0x292
> [   28.980000]  [<4133a201>] ? kobject_put+0x14/0x16
> [   28.980000]  [<410d432c>] blkdev_get+0xa/0xc
> [   28.980000]  [<410e81fb>] register_disk+0x94/0xe5
> [   28.980000]  [<413326c6>] ? blk_register_region+0x1b/0x20
> [   28.980000]  [<41332815>] add_disk+0x57/0x95
> [   28.980000]  [<41331fc6>] ? exact_match+0x0/0x8
> [   28.980000]  [<4133233f>] ? exact_lock+0x0/0x11
> [   28.980000]  [<41643848>] sd_probe_async+0x108/0x1be
> [   28.980000]  [<41048865>] async_thread+0xf5/0x1e6
> [   28.980000]  [<4102cbcb>] ? default_wake_function+0x0/0xd
> [   28.980000]  [<41048770>] ? async_thread+0x0/0x1e6
> [   28.980000]  [<410433df>] kthread+0x5f/0x64
> [   28.980000]  [<41043380>] ? kthread+0x0/0x64
> [   28.980000]  [<41002cc6>] kernel_thread_helper+0x6/0x10
> [   29.264071] async/1 used greatest stack depth: 2336 bytes left
> [   29.267020] bus: 'ssb': add driver b44
> [   29.267072] initcall b44_init+0x0/0x55 returned 0 after 281250 usecs
> [   29.267076] calling  init_nic+0x0/0x16 @ 1
> 
> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
> attached. Reproducible on that sha1 and with that config.

I think I see it, the internal CFQ blkg groups are not properly
initialized... Will send a patch shortly.

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Ingo Molnar]

* Jens Axboe <jaxboe@fusionio.com> wrote:

> On 2010-06-11 10:32, Ingo Molnar wrote:
> > 
> > * Jens Axboe <jaxboe@fusionio.com> wrote:
> > 
> >> On 2010-06-09 03:53, Linus Torvalds wrote:
> >>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
> >>>> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> >>>> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> >>>> Date		: 2010-06-05 06:15 (4 days old)
> >>>
> >>> This seems to have been introduced by
> >>>
> >>> 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> >>> 	Author: Ingo Molnar <mingo@elte.hu>
> >>> 	Date:   Sat Nov 8 17:05:38 2008 +0100
> >>>
> >>> 	    sched: optimize sched_clock() a bit
> >>>     
> >>> 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
> >>> 	    variant of __cycles_2_ns().
> >>>     
> >>> 	    Most of the time sched_clock() is called with irqs disabled already.
> >>> 	    The few places that call it with irqs enabled need to be updated.
> >>>     
> >>> 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
> >>>
> >>> and this seems to be one of those calling cases that need to be updated..
> >>>
> >>> Ingo? The call trace is:
> >>>
> >>> 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
> >>> 	caller is native_sched_clock+0x3c/0x68
> >>> 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
> >>> 	Call Trace:
> >>> 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
> >>> 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
> >>> 	[<ffffffff8101043d>] sched_clock+0x9/0xd
> >>> 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
> >>> 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
> >>> 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
> >>> 	[<ffffffff81215537>] __make_request+0x338/0x45b
> >>> 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
> >>> 	[<ffffffff81214909>] submit_bio+0xd2/0xef
> >>> 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
> >>> 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
> >>> 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
> >>> 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
> >>> 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
> >>> 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
> >>> 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
> >>> 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
> >>> 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
> >>> 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
> >>>
> >>> (from the bugzilla thing)
> >>
> >> This should be fixed by commit 28f4197e which was merged on friday.
> > 
> > Hm, it's still not entirely fixed, as of 2.6.35-rc2-00131-g7908a9e. With some 
> > configs i get bad spinlock warnings during bootup:
> > 
> > [   28.968013] initcall net_olddevs_init+0x0/0x82 returned 0 after 93750 usecs
> > [   28.972003] calling  b44_init+0x0/0x55 @ 1
> > [   28.976009] bus: 'pci': add driver b44
> > [   28.976374]  sda:
> > [   28.978157] BUG: spinlock bad magic on CPU#1, async/0/117
> > [   28.980000]  lock: 7e1c5bbc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> > [   28.980000] Pid: 117, comm: async/0 Not tainted 2.6.35-rc2-tip-01092-g010e7ef-dirty #8183
> > [   28.980000] Call Trace:
> > [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
> > [   28.980000]  [<4134b7b7>] spin_bug+0x7c/0x87
> > [   28.980000]  [<4134b853>] do_raw_spin_lock+0x1e/0x123
> > [   28.980000]  [<41ba92ca>] ? _raw_spin_lock_irqsave+0x12/0x20
> > [   28.980000]  [<41ba92d2>] _raw_spin_lock_irqsave+0x1a/0x20
> > [   28.980000]  [<4133476f>] blkiocg_update_io_add_stats+0x25/0xfb
> > [   28.980000]  [<41335dae>] ? cfq_prio_tree_add+0xb1/0xc1
> > [   28.980000]  [<41337bc7>] cfq_insert_request+0x8c/0x425
> > [   28.980000]  [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
> > [   28.980000]  [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
> > [   28.980000]  [<41329225>] elv_insert+0x107/0x1a0
> > [   28.980000]  [<41329354>] __elv_add_request+0x96/0x9d
> > [   28.980000]  [<4132bb8c>] ? drive_stat_acct+0x9d/0xc6
> > [   28.980000]  [<4132dd64>] __make_request+0x335/0x376
> > [   28.980000]  [<4132c726>] generic_make_request+0x336/0x39d
> > [   28.980000]  [<410ad422>] ? kmem_cache_alloc+0xa1/0x105
> > [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
> > [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
> > [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
> > [   28.980000]  [<41089347>] ? mempool_alloc+0x57/0xe2
> > [   28.980000]  [<4132c804>] submit_bio+0x77/0x8f
> > [   28.980000]  [<410d2cbc>] ? bio_alloc_bioset+0x37/0x94
> > [   28.980000]  [<410ceb90>] submit_bh+0xc3/0xe2
> > [   28.980000]  [<410d1474>] block_read_full_page+0x249/0x259
> > [   28.980000]  [<410d31fb>] ? blkdev_get_block+0x0/0xc6
> > [   28.980000]  [<41087bfa>] ? add_to_page_cache_locked+0x94/0xb5
> > [   28.980000]  [<410d3d92>] blkdev_readpage+0xf/0x11
> > [   28.980000]  [<41088823>] do_read_cache_page+0x7d/0x11a
> > [   28.980000]  [<410d3d83>] ? blkdev_readpage+0x0/0x11
> > [   28.980000]  [<410888f4>] read_cache_page_async+0x16/0x1b
> > [   28.980000]  [<41088904>] read_cache_page+0xb/0x12
> > [   28.980000]  [<410e80e1>] read_dev_sector+0x2a/0x63
> > [   28.980000]  [<410e92e8>] adfspart_check_ICS+0x2e/0x166
> > [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
> > [   28.980000]  [<410e8d23>] rescan_partitions+0x196/0x3e4
> > [   28.980000]  [<41ba7dc7>] ? __mutex_unlock_slowpath+0x98/0x9f
> > [   28.980000]  [<410e92ba>] ? adfspart_check_ICS+0x0/0x166
> > [   28.980000]  [<410d4277>] __blkdev_get+0x1e7/0x292
> > [   28.980000]  [<4133a201>] ? kobject_put+0x14/0x16
> > [   28.980000]  [<410d432c>] blkdev_get+0xa/0xc
> > [   28.980000]  [<410e81fb>] register_disk+0x94/0xe5
> > [   28.980000]  [<413326c6>] ? blk_register_region+0x1b/0x20
> > [   28.980000]  [<41332815>] add_disk+0x57/0x95
> > [   28.980000]  [<41331fc6>] ? exact_match+0x0/0x8
> > [   28.980000]  [<4133233f>] ? exact_lock+0x0/0x11
> > [   28.980000]  [<41643848>] sd_probe_async+0x108/0x1be
> > [   28.980000]  [<41048865>] async_thread+0xf5/0x1e6
> > [   28.980000]  [<4102cbcb>] ? default_wake_function+0x0/0xd
> > [   28.980000]  [<41048770>] ? async_thread+0x0/0x1e6
> > [   28.980000]  [<410433df>] kthread+0x5f/0x64
> > [   28.980000]  [<41043380>] ? kthread+0x0/0x64
> > [   28.980000]  [<41002cc6>] kernel_thread_helper+0x6/0x10
> > [   29.264071] async/1 used greatest stack depth: 2336 bytes left
> > [   29.267020] bus: 'ssb': add driver b44
> > [   29.267072] initcall b44_init+0x0/0x55 returned 0 after 281250 usecs
> > [   29.267076] calling  init_nic+0x0/0x16 @ 1
> > 
> > Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
> > attached. Reproducible on that sha1 and with that config.
> 
> I think I see it, the internal CFQ blkg groups are not properly
> initialized... Will send a patch shortly.

Cool - can test it with a short turnaround, the bug is easy to reproduce.

Thanks,

	Ingo

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 2010-06-11 10:55, Ingo Molnar wrote:
> 
> * Jens Axboe <jaxboe@fusionio.com> wrote:
> 
>> On 2010-06-11 10:32, Ingo Molnar wrote:
>>>
>>> * Jens Axboe <jaxboe@fusionio.com> wrote:
>>>
>>>> On 2010-06-09 03:53, Linus Torvalds wrote:
>>>>>> Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16129
>>>>>> Subject	: BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
>>>>>> Submitter	: Jan Kreuzer <kontrollator@gmx.de>
>>>>>> Date		: 2010-06-05 06:15 (4 days old)
>>>>>
>>>>> This seems to have been introduced by
>>>>>
>>>>> 	commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
>>>>> 	Author: Ingo Molnar <mingo@elte.hu>
>>>>> 	Date:   Sat Nov 8 17:05:38 2008 +0100
>>>>>
>>>>> 	    sched: optimize sched_clock() a bit
>>>>>     
>>>>> 	    sched_clock() uses cycles_2_ns() needlessly - which is an irq-disabling
>>>>> 	    variant of __cycles_2_ns().
>>>>>     
>>>>> 	    Most of the time sched_clock() is called with irqs disabled already.
>>>>> 	    The few places that call it with irqs enabled need to be updated..
>>>>>     
>>>>> 	    Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>>>>
>>>>> and this seems to be one of those calling cases that need to be updated..
>>>>>
>>>>> Ingo? The call trace is:
>>>>>
>>>>> 	BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2-8/337
>>>>> 	caller is native_sched_clock+0x3c/0x68
>>>>> 	Pid: 337, comm: jbd2/sda2-8 Not tainted 2.6.35-rc1jan+ #4
>>>>> 	Call Trace:
>>>>> 	[<ffffffff812362c5>] debug_smp_processor_id+0xc9/0xe4
>>>>> 	[<ffffffff8101059d>] native_sched_clock+0x3c/0x68
>>>>> 	[<ffffffff8101043d>] sched_clock+0x9/0xd
>>>>> 	[<ffffffff81212d7a>] blk_rq_init+0x97/0xa3
>>>>> 	[<ffffffff81214d71>] get_request+0x1c4/0x2d0
>>>>> 	[<ffffffff81214ea6>] get_request_wait+0x29/0x1a6
>>>>> 	[<ffffffff81215537>] __make_request+0x338/0x45b
>>>>> 	[<ffffffff812147c2>] generic_make_request+0x2bb/0x330
>>>>> 	[<ffffffff81214909>] submit_bio+0xd2/0xef
>>>>> 	[<ffffffff811413cb>] submit_bh+0xf4/0x116
>>>>> 	[<ffffffff81144853>] block_write_full_page_endio+0x89/0x96
>>>>> 	[<ffffffff81144875>] block_write_full_page+0x15/0x17
>>>>> 	[<ffffffff8119b00a>] ext4_writepage+0x356/0x36b
>>>>> 	[<ffffffff810e1f91>] __writepage+0x1a/0x39
>>>>> 	[<ffffffff810e32a6>] write_cache_pages+0x20d/0x346
>>>>> 	[<ffffffff810e3406>] generic_writepages+0x27/0x29
>>>>> 	[<ffffffff811ca279>] journal_submit_data_buffers+0x110/0x17d
>>>>> 	[<ffffffff811ca986>] jbd2_journal_commit_transaction+0x4cb/0x156d
>>>>> 	[<ffffffff811d0cba>] kjournald2+0x147/0x37a
>>>>>
>>>>> (from the bugzilla thing)
>>>>
>>>> This should be fixed by commit 28f4197e which was merged on friday.
>>>
>>> Hm, it's still not entirely fixed, as of 2.6.35-rc2-00131-g7908a9e. With some 
>>> configs i get bad spinlock warnings during bootup:
>>>
>>> [   28.968013] initcall net_olddevs_init+0x0/0x82 returned 0 after 93750 usecs
>>> [   28.972003] calling  b44_init+0x0/0x55 @ 1
>>> [   28.976009] bus: 'pci': add driver b44
>>> [   28.976374]  sda:
>>> [   28.978157] BUG: spinlock bad magic on CPU#1, async/0/117
>>> [   28.980000]  lock: 7e1c5bbc, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
>>> [   28.980000] Pid: 117, comm: async/0 Not tainted 2.6.35-rc2-tip-01092-g010e7ef-dirty #8183
>>> [   28.980000] Call Trace:
>>> [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
>>> [   28.980000]  [<4134b7b7>] spin_bug+0x7c/0x87
>>> [   28.980000]  [<4134b853>] do_raw_spin_lock+0x1e/0x123
>>> [   28.980000]  [<41ba92ca>] ? _raw_spin_lock_irqsave+0x12/0x20
>>> [   28.980000]  [<41ba92d2>] _raw_spin_lock_irqsave+0x1a/0x20
>>> [   28.980000]  [<4133476f>] blkiocg_update_io_add_stats+0x25/0xfb
>>> [   28.980000]  [<41335dae>] ? cfq_prio_tree_add+0xb1/0xc1
>>> [   28.980000]  [<41337bc7>] cfq_insert_request+0x8c/0x425
>>> [   28.980000]  [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
>>> [   28.980000]  [<41ba9271>] ? _raw_spin_unlock_irqrestore+0x17/0x23
>>> [   28.980000]  [<41329225>] elv_insert+0x107/0x1a0
>>> [   28.980000]  [<41329354>] __elv_add_request+0x96/0x9d
>>> [   28.980000]  [<4132bb8c>] ? drive_stat_acct+0x9d/0xc6
>>> [   28.980000]  [<4132dd64>] __make_request+0x335/0x376
>>> [   28.980000]  [<4132c726>] generic_make_request+0x336/0x39d
>>> [   28.980000]  [<410ad422>] ? kmem_cache_alloc+0xa1/0x105
>>> [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
>>> [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
>>> [   28.980000]  [<41089285>] ? mempool_alloc_slab+0xe/0x10
>>> [   28.980000]  [<41089347>] ? mempool_alloc+0x57/0xe2
>>> [   28.980000]  [<4132c804>] submit_bio+0x77/0x8f
>>> [   28.980000]  [<410d2cbc>] ? bio_alloc_bioset+0x37/0x94
>>> [   28.980000]  [<410ceb90>] submit_bh+0xc3/0xe2
>>> [   28.980000]  [<410d1474>] block_read_full_page+0x249/0x259
>>> [   28.980000]  [<410d31fb>] ? blkdev_get_block+0x0/0xc6
>>> [   28.980000]  [<41087bfa>] ? add_to_page_cache_locked+0x94/0xb5
>>> [   28.980000]  [<410d3d92>] blkdev_readpage+0xf/0x11
>>> [   28.980000]  [<41088823>] do_read_cache_page+0x7d/0x11a
>>> [   28.980000]  [<410d3d83>] ? blkdev_readpage+0x0/0x11
>>> [   28.980000]  [<410888f4>] read_cache_page_async+0x16/0x1b
>>> [   28.980000]  [<41088904>] read_cache_page+0xb/0x12
>>> [   28.980000]  [<410e80e1>] read_dev_sector+0x2a/0x63
>>> [   28.980000]  [<410e92e8>] adfspart_check_ICS+0x2e/0x166
>>> [   28.980000]  [<41ba6d55>] ? printk+0x20/0x24
>>> [   28.980000]  [<410e8d23>] rescan_partitions+0x196/0x3e4
>>> [   28.980000]  [<41ba7dc7>] ? __mutex_unlock_slowpath+0x98/0x9f
>>> [   28.980000]  [<410e92ba>] ? adfspart_check_ICS+0x0/0x166
>>> [   28.980000]  [<410d4277>] __blkdev_get+0x1e7/0x292
>>> [   28.980000]  [<4133a201>] ? kobject_put+0x14/0x16
>>> [   28.980000]  [<410d432c>] blkdev_get+0xa/0xc
>>> [   28.980000]  [<410e81fb>] register_disk+0x94/0xe5
>>> [   28.980000]  [<413326c6>] ? blk_register_region+0x1b/0x20
>>> [   28.980000]  [<41332815>] add_disk+0x57/0x95
>>> [   28.980000]  [<41331fc6>] ? exact_match+0x0/0x8
>>> [   28.980000]  [<4133233f>] ? exact_lock+0x0/0x11
>>> [   28.980000]  [<41643848>] sd_probe_async+0x108/0x1be
>>> [   28.980000]  [<41048865>] async_thread+0xf5/0x1e6
>>> [   28.980000]  [<4102cbcb>] ? default_wake_function+0x0/0xd
>>> [   28.980000]  [<41048770>] ? async_thread+0x0/0x1e6
>>> [   28.980000]  [<410433df>] kthread+0x5f/0x64
>>> [   28.980000]  [<41043380>] ? kthread+0x0/0x64
>>> [   28.980000]  [<41002cc6>] kernel_thread_helper+0x6/0x10
>>> [   29.264071] async/1 used greatest stack depth: 2336 bytes left
>>> [   29.267020] bus: 'ssb': add driver b44
>>> [   29.267072] initcall b44_init+0x0/0x55 returned 0 after 281250 usecs
>>> [   29.267076] calling  init_nic+0x0/0x16 @ 1
>>>
>>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
>>> attached. Reproducible on that sha1 and with that config.
>>
>> I think I see it, the internal CFQ blkg groups are not properly
>> initialized... Will send a patch shortly.
> 
> Cool - can test it with a short turnaround, the bug is easy to reproduce.

Thanks, I need to ensure what the best way to solve it is. The problem
is that if you have BLK_CGROUP set but don't enable the CFQ cgroup
stuff, then you end up calling the real update functions but CFQ has not
initialized them.

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 2010-06-11 10:55, Ingo Molnar wrote:
>>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
>>> attached. Reproducible on that sha1 and with that config.
>>
>> I think I see it, the internal CFQ blkg groups are not properly
>> initialized... Will send a patch shortly.
> 
> Cool - can test it with a short turnaround, the bug is easy to reproduce.

Here's a nasty patch that should fix it. Not optimal, since we really
just want empty functions for these when cfq group scheduling is not
defined.

CC'ing the guilty parties to come up with a better patch that does NOT
involve ifdefs in cfq-iosched.c. We want blk-cgroup.[ch] fixed up.
And trimming the CC list a bit.


diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 5ff4f48..7067c97 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -879,7 +879,9 @@ cfq_group_service_tree_del(struct cfq_data *cfqd, struct cfq_group *cfqg)
 	if (!RB_EMPTY_NODE(&cfqg->rb_node))
 		cfq_rb_erase(&cfqg->rb_node, st);
 	cfqg->saved_workload_slice = 0;
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_dequeue_stats(&cfqg->blkg, 1);
+#endif
 }
 
 static inline unsigned int cfq_cfqq_slice_usage(struct cfq_queue *cfqq)
@@ -939,8 +941,10 @@ static void cfq_group_served(struct cfq_data *cfqd, struct cfq_group *cfqg,
 
 	cfq_log_cfqg(cfqd, cfqg, "served: vt=%llu min_vt=%llu", cfqg->vdisktime,
 					st->min_vdisktime);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_timeslice_used(&cfqg->blkg, used_sl);
 	blkiocg_set_start_empty_time(&cfqg->blkg);
+#endif
 }
 
 #ifdef CONFIG_CFQ_GROUP_IOSCHED
@@ -1421,12 +1425,17 @@ static void cfq_reposition_rq_rb(struct cfq_queue *cfqq, struct request *rq)
 {
 	elv_rb_del(&cfqq->sort_list, rq);
 	cfqq->queued[rq_is_sync(rq)]--;
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(rq),
 						rq_is_sync(rq));
+#endif
 	cfq_add_rq_rb(rq);
+
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
 			&cfqq->cfqd->serving_group->blkg, rq_data_dir(rq),
 			rq_is_sync(rq));
+#endif
 }
 
 static struct request *
@@ -1482,8 +1491,10 @@ static void cfq_remove_request(struct request *rq)
 	cfq_del_rq_rb(rq);
 
 	cfqq->cfqd->rq_queued--;
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(rq),
 						rq_is_sync(rq));
+#endif
 	if (rq_is_meta(rq)) {
 		WARN_ON(!cfqq->meta_pending);
 		cfqq->meta_pending--;
@@ -1518,8 +1529,10 @@ static void cfq_merged_request(struct request_queue *q, struct request *req,
 static void cfq_bio_merged(struct request_queue *q, struct request *req,
 				struct bio *bio)
 {
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_io_merged_stats(&(RQ_CFQG(req))->blkg, bio_data_dir(bio),
 					cfq_bio_sync(bio));
+#endif
 }
 
 static void
@@ -1539,8 +1552,10 @@ cfq_merged_requests(struct request_queue *q, struct request *rq,
 	if (cfqq->next_rq == next)
 		cfqq->next_rq = rq;
 	cfq_remove_request(next);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_io_merged_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(next),
 					rq_is_sync(next));
+#endif
 }
 
 static int cfq_allow_merge(struct request_queue *q, struct request *rq,
@@ -1571,7 +1586,9 @@ static int cfq_allow_merge(struct request_queue *q, struct request *rq,
 static inline void cfq_del_timer(struct cfq_data *cfqd, struct cfq_queue *cfqq)
 {
 	del_timer(&cfqd->idle_slice_timer);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_idle_time_stats(&cfqq->cfqg->blkg);
+#endif
 }
 
 static void __cfq_set_active_queue(struct cfq_data *cfqd,
@@ -1580,7 +1597,9 @@ static void __cfq_set_active_queue(struct cfq_data *cfqd,
 	if (cfqq) {
 		cfq_log_cfqq(cfqd, cfqq, "set_active wl_prio:%d wl_type:%d",
 				cfqd->serving_prio, cfqd->serving_type);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 		blkiocg_update_avg_queue_size_stats(&cfqq->cfqg->blkg);
+#endif
 		cfqq->slice_start = 0;
 		cfqq->dispatch_start = jiffies;
 		cfqq->allocated_slice = 0;
@@ -1911,7 +1930,9 @@ static void cfq_arm_slice_timer(struct cfq_data *cfqd)
 	sl = cfqd->cfq_slice_idle;
 
 	mod_timer(&cfqd->idle_slice_timer, jiffies + sl);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_set_idle_time_stats(&cfqq->cfqg->blkg);
+#endif
 	cfq_log_cfqq(cfqd, cfqq, "arm_idle: %lu", sl);
 }
 
@@ -1931,8 +1952,10 @@ static void cfq_dispatch_insert(struct request_queue *q, struct request *rq)
 	elv_dispatch_sort(q, rq);
 
 	cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]++;
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_dispatch_stats(&cfqq->cfqg->blkg, blk_rq_bytes(rq),
 					rq_data_dir(rq), rq_is_sync(rq));
+#endif
 }
 
 /*
@@ -3248,8 +3271,10 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
 				cfq_clear_cfqq_wait_request(cfqq);
 				__blk_run_queue(cfqd->queue);
 			} else {
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 				blkiocg_update_idle_time_stats(
 						&cfqq->cfqg->blkg);
+#endif
 				cfq_mark_cfqq_must_dispatch(cfqq);
 			}
 		}
@@ -3276,9 +3301,11 @@ static void cfq_insert_request(struct request_queue *q, struct request *rq)
 	rq_set_fifo_time(rq, jiffies + cfqd->cfq_fifo_expire[rq_is_sync(rq)]);
 	list_add_tail(&rq->queuelist, &cfqq->fifo);
 	cfq_add_rq_rb(rq);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
 			&cfqd->serving_group->blkg, rq_data_dir(rq),
 			rq_is_sync(rq));
+#endif
 	cfq_rq_enqueued(cfqd, cfqq, rq);
 }
 
@@ -3364,9 +3391,11 @@ static void cfq_completed_request(struct request_queue *q, struct request *rq)
 	WARN_ON(!cfqq->dispatched);
 	cfqd->rq_in_driver--;
 	cfqq->dispatched--;
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_update_completion_stats(&cfqq->cfqg->blkg, rq_start_time_ns(rq),
 			rq_io_start_time_ns(rq), rq_data_dir(rq),
 			rq_is_sync(rq));
+#endif
 
 	cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]--;
 
@@ -3730,7 +3759,9 @@ static void cfq_exit_queue(struct elevator_queue *e)
 
 	cfq_put_async_queues(cfqd);
 	cfq_release_cfq_groups(cfqd);
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	blkiocg_del_blkio_group(&cfqd->root_group.blkg);
+#endif
 
 	spin_unlock_irq(q->queue_lock);
 

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Vivek Goyal]

On Fri, Jun 11, 2010 at 11:18:47AM +0200, Jens Axboe wrote:
> On 2010-06-11 10:55, Ingo Molnar wrote:
> >>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
> >>> attached. Reproducible on that sha1 and with that config.
> >>
> >> I think I see it, the internal CFQ blkg groups are not properly
> >> initialized... Will send a patch shortly.
> > 
> > Cool - can test it with a short turnaround, the bug is easy to reproduce.
> 
> Here's a nasty patch that should fix it. Not optimal, since we really
> just want empty functions for these when cfq group scheduling is not
> defined.
> 
> CC'ing the guilty parties to come up with a better patch that does NOT
> involve ifdefs in cfq-iosched.c. We want blk-cgroup.[ch] fixed up.
> And trimming the CC list a bit.

Jens, Ingo, I am sorry for this mess.

Jens,

How about introducing "block/cfq.h" and declaring additional set of wrapper
functions to update blkiocg stats and make these do nothing if
CFQ_GROUP_IOSCHED=n.

For example, in linux-2.6/block/cfq.h, we can define functions as follows.

#ifdef CONFIG_CFQ_GROUP_IOSCHED
cfq_blkiocg_update_dequeue_stats () {
	blkiocg_update_dequeue_stats()
}
#else
cfq_blkiocg_update_dequeue_stats () {}
#endif

Fixing it blk-cgroup.[ch] might not be best as BLK_CGROUP is set.
Secondly, if there are other IO control policies later, they might
want to make use of BLK_CGROUP while cfq has disabled the group io 
scheduling.

I will prepare a patch and see how does it look.

Thanks
Vivek

> 
> 
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 5ff4f48..7067c97 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -879,7 +879,9 @@ cfq_group_service_tree_del(struct cfq_data *cfqd, struct cfq_group *cfqg)
>  	if (!RB_EMPTY_NODE(&cfqg->rb_node))
>  		cfq_rb_erase(&cfqg->rb_node, st);
>  	cfqg->saved_workload_slice = 0;
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_dequeue_stats(&cfqg->blkg, 1);
> +#endif
>  }
>  
>  static inline unsigned int cfq_cfqq_slice_usage(struct cfq_queue *cfqq)
> @@ -939,8 +941,10 @@ static void cfq_group_served(struct cfq_data *cfqd, struct cfq_group *cfqg,
>  
>  	cfq_log_cfqg(cfqd, cfqg, "served: vt=%llu min_vt=%llu", cfqg->vdisktime,
>  					st->min_vdisktime);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_timeslice_used(&cfqg->blkg, used_sl);
>  	blkiocg_set_start_empty_time(&cfqg->blkg);
> +#endif
>  }
>  
>  #ifdef CONFIG_CFQ_GROUP_IOSCHED
> @@ -1421,12 +1425,17 @@ static void cfq_reposition_rq_rb(struct cfq_queue *cfqq, struct request *rq)
>  {
>  	elv_rb_del(&cfqq->sort_list, rq);
>  	cfqq->queued[rq_is_sync(rq)]--;
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(rq),
>  						rq_is_sync(rq));
> +#endif
>  	cfq_add_rq_rb(rq);
> +
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
>  			&cfqq->cfqd->serving_group->blkg, rq_data_dir(rq),
>  			rq_is_sync(rq));
> +#endif
>  }
>  
>  static struct request *
> @@ -1482,8 +1491,10 @@ static void cfq_remove_request(struct request *rq)
>  	cfq_del_rq_rb(rq);
>  
>  	cfqq->cfqd->rq_queued--;
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(rq),
>  						rq_is_sync(rq));
> +#endif
>  	if (rq_is_meta(rq)) {
>  		WARN_ON(!cfqq->meta_pending);
>  		cfqq->meta_pending--;
> @@ -1518,8 +1529,10 @@ static void cfq_merged_request(struct request_queue *q, struct request *req,
>  static void cfq_bio_merged(struct request_queue *q, struct request *req,
>  				struct bio *bio)
>  {
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_io_merged_stats(&(RQ_CFQG(req))->blkg, bio_data_dir(bio),
>  					cfq_bio_sync(bio));
> +#endif
>  }
>  
>  static void
> @@ -1539,8 +1552,10 @@ cfq_merged_requests(struct request_queue *q, struct request *rq,
>  	if (cfqq->next_rq == next)
>  		cfqq->next_rq = rq;
>  	cfq_remove_request(next);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_io_merged_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(next),
>  					rq_is_sync(next));
> +#endif
>  }
>  
>  static int cfq_allow_merge(struct request_queue *q, struct request *rq,
> @@ -1571,7 +1586,9 @@ static int cfq_allow_merge(struct request_queue *q, struct request *rq,
>  static inline void cfq_del_timer(struct cfq_data *cfqd, struct cfq_queue *cfqq)
>  {
>  	del_timer(&cfqd->idle_slice_timer);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_idle_time_stats(&cfqq->cfqg->blkg);
> +#endif
>  }
>  
>  static void __cfq_set_active_queue(struct cfq_data *cfqd,
> @@ -1580,7 +1597,9 @@ static void __cfq_set_active_queue(struct cfq_data *cfqd,
>  	if (cfqq) {
>  		cfq_log_cfqq(cfqd, cfqq, "set_active wl_prio:%d wl_type:%d",
>  				cfqd->serving_prio, cfqd->serving_type);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  		blkiocg_update_avg_queue_size_stats(&cfqq->cfqg->blkg);
> +#endif
>  		cfqq->slice_start = 0;
>  		cfqq->dispatch_start = jiffies;
>  		cfqq->allocated_slice = 0;
> @@ -1911,7 +1930,9 @@ static void cfq_arm_slice_timer(struct cfq_data *cfqd)
>  	sl = cfqd->cfq_slice_idle;
>  
>  	mod_timer(&cfqd->idle_slice_timer, jiffies + sl);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_set_idle_time_stats(&cfqq->cfqg->blkg);
> +#endif
>  	cfq_log_cfqq(cfqd, cfqq, "arm_idle: %lu", sl);
>  }
>  
> @@ -1931,8 +1952,10 @@ static void cfq_dispatch_insert(struct request_queue *q, struct request *rq)
>  	elv_dispatch_sort(q, rq);
>  
>  	cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]++;
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_dispatch_stats(&cfqq->cfqg->blkg, blk_rq_bytes(rq),
>  					rq_data_dir(rq), rq_is_sync(rq));
> +#endif
>  }
>  
>  /*
> @@ -3248,8 +3271,10 @@ cfq_rq_enqueued(struct cfq_data *cfqd, struct cfq_queue *cfqq,
>  				cfq_clear_cfqq_wait_request(cfqq);
>  				__blk_run_queue(cfqd->queue);
>  			} else {
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  				blkiocg_update_idle_time_stats(
>  						&cfqq->cfqg->blkg);
> +#endif
>  				cfq_mark_cfqq_must_dispatch(cfqq);
>  			}
>  		}
> @@ -3276,9 +3301,11 @@ static void cfq_insert_request(struct request_queue *q, struct request *rq)
>  	rq_set_fifo_time(rq, jiffies + cfqd->cfq_fifo_expire[rq_is_sync(rq)]);
>  	list_add_tail(&rq->queuelist, &cfqq->fifo);
>  	cfq_add_rq_rb(rq);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
>  			&cfqd->serving_group->blkg, rq_data_dir(rq),
>  			rq_is_sync(rq));
> +#endif
>  	cfq_rq_enqueued(cfqd, cfqq, rq);
>  }
>  
> @@ -3364,9 +3391,11 @@ static void cfq_completed_request(struct request_queue *q, struct request *rq)
>  	WARN_ON(!cfqq->dispatched);
>  	cfqd->rq_in_driver--;
>  	cfqq->dispatched--;
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_update_completion_stats(&cfqq->cfqg->blkg, rq_start_time_ns(rq),
>  			rq_io_start_time_ns(rq), rq_data_dir(rq),
>  			rq_is_sync(rq));
> +#endif
>  
>  	cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]--;
>  
> @@ -3730,7 +3759,9 @@ static void cfq_exit_queue(struct elevator_queue *e)
>  
>  	cfq_put_async_queues(cfqd);
>  	cfq_release_cfq_groups(cfqd);
> +#ifdef CONFIG_CFQ_GROUP_IOSCHED
>  	blkiocg_del_blkio_group(&cfqd->root_group.blkg);
> +#endif
>  
>  	spin_unlock_irq(q->queue_lock);
>  
> 
> -- 
> Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 11/06/10 21.07, Vivek Goyal wrote:
> On Fri, Jun 11, 2010 at 11:18:47AM +0200, Jens Axboe wrote:
>> On 2010-06-11 10:55, Ingo Molnar wrote:
>>>>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
>>>>> attached. Reproducible on that sha1 and with that config.
>>>>
>>>> I think I see it, the internal CFQ blkg groups are not properly
>>>> initialized... Will send a patch shortly.
>>>
>>> Cool - can test it with a short turnaround, the bug is easy to reproduce.
>>
>> Here's a nasty patch that should fix it. Not optimal, since we really
>> just want empty functions for these when cfq group scheduling is not
>> defined.
>>
>> CC'ing the guilty parties to come up with a better patch that does NOT
>> involve ifdefs in cfq-iosched.c. We want blk-cgroup.[ch] fixed up.
>> And trimming the CC list a bit.
> 
> Jens, Ingo, I am sorry for this mess.
> 
> Jens,
> 
> How about introducing "block/cfq.h" and declaring additional set of wrapper
> functions to update blkiocg stats and make these do nothing if
> CFQ_GROUP_IOSCHED=n.
> 
> For example, in linux-2.6/block/cfq.h, we can define functions as follows.
> 
> #ifdef CONFIG_CFQ_GROUP_IOSCHED
> cfq_blkiocg_update_dequeue_stats () {
> 	blkiocg_update_dequeue_stats()
> }
> #else
> cfq_blkiocg_update_dequeue_stats () {}
> #endif
> 
> Fixing it blk-cgroup.[ch] might not be best as BLK_CGROUP is set.
> Secondly, if there are other IO control policies later, they might
> want to make use of BLK_CGROUP while cfq has disabled the group io 
> scheduling.

I already tried such a patch, but it's not exactly pretty. How about
splitting blk-cgroup.c into two parts, one that is built for
BLK_CGROUP and an additional one that is also built for
CFQ_GROUP_SCHED? Lets try and improve on the ifdef mess, not extend
it.

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Vivek Goyal]

On Fri, Jun 11, 2010 at 09:11:49PM +0200, Jens Axboe wrote:
> On 11/06/10 21.07, Vivek Goyal wrote:
> > On Fri, Jun 11, 2010 at 11:18:47AM +0200, Jens Axboe wrote:
> >> On 2010-06-11 10:55, Ingo Molnar wrote:
> >>>>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
> >>>>> attached. Reproducible on that sha1 and with that config.
> >>>>
> >>>> I think I see it, the internal CFQ blkg groups are not properly
> >>>> initialized... Will send a patch shortly.
> >>>
> >>> Cool - can test it with a short turnaround, the bug is easy to reproduce.
> >>
> >> Here's a nasty patch that should fix it. Not optimal, since we really
> >> just want empty functions for these when cfq group scheduling is not
> >> defined.
> >>
> >> CC'ing the guilty parties to come up with a better patch that does NOT
> >> involve ifdefs in cfq-iosched.c. We want blk-cgroup.[ch] fixed up.
> >> And trimming the CC list a bit.
> > 
> > Jens, Ingo, I am sorry for this mess.
> > 
> > Jens,
> > 
> > How about introducing "block/cfq.h" and declaring additional set of wrapper
> > functions to update blkiocg stats and make these do nothing if
> > CFQ_GROUP_IOSCHED=n.
> > 
> > For example, in linux-2.6/block/cfq.h, we can define functions as follows.
> > 
> > #ifdef CONFIG_CFQ_GROUP_IOSCHED
> > cfq_blkiocg_update_dequeue_stats () {
> > 	blkiocg_update_dequeue_stats()
> > }
> > #else
> > cfq_blkiocg_update_dequeue_stats () {}
> > #endif
> > 
> > Fixing it blk-cgroup.[ch] might not be best as BLK_CGROUP is set.
> > Secondly, if there are other IO control policies later, they might
> > want to make use of BLK_CGROUP while cfq has disabled the group io 
> > scheduling.
> 
> I already tried such a patch, but it's not exactly pretty. How about
> splitting blk-cgroup.c into two parts, one that is built for
> BLK_CGROUP and an additional one that is also built for
> CFQ_GROUP_SCHED? Lets try and improve on the ifdef mess, not extend
> it.

Sorry, I did not understand your suggestion. Can you please throw some more
light on it.

blk-cgroup.c does not have any cfq specific parts. So I can't split it
out and build part of it based on CFQ_GROUP_SCHED.

Thanks
Vivek

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Jens Axboe]

On 11/06/10 21.48, Vivek Goyal wrote:
> On Fri, Jun 11, 2010 at 09:11:49PM +0200, Jens Axboe wrote:
>> On 11/06/10 21.07, Vivek Goyal wrote:
>>> On Fri, Jun 11, 2010 at 11:18:47AM +0200, Jens Axboe wrote:
>>>> On 2010-06-11 10:55, Ingo Molnar wrote:
>>>>>>> Caused by the same blkiocg_update_io_add_stats() function. Bootlog and config 
>>>>>>> attached. Reproducible on that sha1 and with that config.
>>>>>>
>>>>>> I think I see it, the internal CFQ blkg groups are not properly
>>>>>> initialized... Will send a patch shortly.
>>>>>
>>>>> Cool - can test it with a short turnaround, the bug is easy to reproduce.
>>>>
>>>> Here's a nasty patch that should fix it. Not optimal, since we really
>>>> just want empty functions for these when cfq group scheduling is not
>>>> defined.
>>>>
>>>> CC'ing the guilty parties to come up with a better patch that does NOT
>>>> involve ifdefs in cfq-iosched.c. We want blk-cgroup.[ch] fixed up.
>>>> And trimming the CC list a bit.
>>>
>>> Jens, Ingo, I am sorry for this mess.
>>>
>>> Jens,
>>>
>>> How about introducing "block/cfq.h" and declaring additional set of wrapper
>>> functions to update blkiocg stats and make these do nothing if
>>> CFQ_GROUP_IOSCHED=n.
>>>
>>> For example, in linux-2.6/block/cfq.h, we can define functions as follows.
>>>
>>> #ifdef CONFIG_CFQ_GROUP_IOSCHED
>>> cfq_blkiocg_update_dequeue_stats () {
>>> 	blkiocg_update_dequeue_stats()
>>> }
>>> #else
>>> cfq_blkiocg_update_dequeue_stats () {}
>>> #endif
>>>
>>> Fixing it blk-cgroup.[ch] might not be best as BLK_CGROUP is set.
>>> Secondly, if there are other IO control policies later, they might
>>> want to make use of BLK_CGROUP while cfq has disabled the group io 
>>> scheduling.
>>
>> I already tried such a patch, but it's not exactly pretty. How about
>> splitting blk-cgroup.c into two parts, one that is built for
>> BLK_CGROUP and an additional one that is also built for
>> CFQ_GROUP_SCHED? Lets try and improve on the ifdef mess, not extend
>> it.
> 
> Sorry, I did not understand your suggestion. Can you please throw some more
> light on it.
> 
> blk-cgroup.c does not have any cfq specific parts. So I can't split it
> out and build part of it based on CFQ_GROUP_SCHED.

I know they are not cfq specific, but cfq is the only one that calls
them currently. If others depend on them later on, then let that other
blk-cgroup-iosched.o be built for them as well.

-- 
Jens Axboe

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Vivek Goyal]

On Fri, Jun 11, 2010 at 09:53:06PM +0200, Jens Axboe wrote:
[..]
> >>> How about introducing "block/cfq.h" and declaring additional set of wrapper
> >>> functions to update blkiocg stats and make these do nothing if
> >>> CFQ_GROUP_IOSCHED=n.
> >>>
> >>> For example, in linux-2.6/block/cfq.h, we can define functions as follows.
> >>>
> >>> #ifdef CONFIG_CFQ_GROUP_IOSCHED
> >>> cfq_blkiocg_update_dequeue_stats () {
> >>> 	blkiocg_update_dequeue_stats()
> >>> }
> >>> #else
> >>> cfq_blkiocg_update_dequeue_stats () {}
> >>> #endif
> >>>
> >>> Fixing it blk-cgroup.[ch] might not be best as BLK_CGROUP is set.
> >>> Secondly, if there are other IO control policies later, they might
> >>> want to make use of BLK_CGROUP while cfq has disabled the group io 
> >>> scheduling.
> >>
> >> I already tried such a patch, but it's not exactly pretty. How about
> >> splitting blk-cgroup.c into two parts, one that is built for
> >> BLK_CGROUP and an additional one that is also built for
> >> CFQ_GROUP_SCHED? Lets try and improve on the ifdef mess, not extend
> >> it.
> > 
> > Sorry, I did not understand your suggestion. Can you please throw some more
> > light on it.
> > 
> > blk-cgroup.c does not have any cfq specific parts. So I can't split it
> > out and build part of it based on CFQ_GROUP_SCHED.
> 
> I know they are not cfq specific, but cfq is the only one that calls
> them currently. If others depend on them later on, then let that other
> blk-cgroup-iosched.o be built for them as well.

Hi Jens,

IIUC, you are suggesting that all the blkiocg interfaces used by CFQ, pull
these out in a separate file say, blk-cgroup-iosched.c and build this
file only if CFQ_GROUP_IOSCHED is enabled.

Two things come to mind.

- If CFQ_GROUP_IOSCHED=n, then nothing much is left in blk-cgroup.c. IOW, 
  what good a blkio controller interface is without blk-cgroup-iosched.c

- More importantly, when a new policy is implemented, then it will force
  building blk-cgroup-iosched.o (even if CFQ_GROUP_IOSCHED=n) and then
  we will be face the same issue that CFQ_GROUP_IOSCHED=n but CFQ is
  calling all the stat update functions and spin lock warning triggers.

  If we create two binaries, one for cfq and for new policy, say 
  blk-cgroup-cfq.o and blk-cgroup-dm-ioband.o, that is also not a very
  pleasant situation because many of the stats interface in these two
  binaries are common and we will be unnecessary creating two binary
  copies of same functions having different name.
	cfq_blkiocg_update_completion_stats()
	dm_ioband_blkiocg_update_completion_stats()

I am still trying to implement what you suggested. Breaking apart
blk-cgroup.c and blk-cgroup.h is making it ugly. In the mean time, I 
would request you to reconsider the providing another wrapper approach
by implementing the "cfq.h".

I am attaching a patch for that approach. I have done some basic compile
testing on it. I can do more testing on it in case you decide to change your
mind.

Thanks
Vivek


---
 block/cfq-iosched.c |   56 ++++++++++++-------------
 block/cfq.h         |  115 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 143 insertions(+), 28 deletions(-)

Index: linux-2.6/block/cfq-iosched.c
===================================================================
--- linux-2.6.orig/block/cfq-iosched.c	2010-06-12 09:11:39.548160746 -0400
+++ linux-2.6/block/cfq-iosched.c	2010-06-12 09:16:32.364816205 -0400
@@ -14,7 +14,7 @@
 #include <linux/rbtree.h>
 #include <linux/ioprio.h>
 #include <linux/blktrace_api.h>
-#include "blk-cgroup.h"
+#include "cfq.h"
 
 /*
  * tunables
@@ -879,7 +879,7 @@
 	if (!RB_EMPTY_NODE(&cfqg->rb_node))
 		cfq_rb_erase(&cfqg->rb_node, st);
 	cfqg->saved_workload_slice = 0;
-	blkiocg_update_dequeue_stats(&cfqg->blkg, 1);
+	cfq_blkiocg_update_dequeue_stats(&cfqg->blkg, 1);
 }
 
 static inline unsigned int cfq_cfqq_slice_usage(struct cfq_queue *cfqq)
@@ -939,8 +939,8 @@
 
 	cfq_log_cfqg(cfqd, cfqg, "served: vt=%llu min_vt=%llu", cfqg->vdisktime,
 					st->min_vdisktime);
-	blkiocg_update_timeslice_used(&cfqg->blkg, used_sl);
-	blkiocg_set_start_empty_time(&cfqg->blkg);
+	cfq_blkiocg_update_timeslice_used(&cfqg->blkg, used_sl);
+	cfq_blkiocg_set_start_empty_time(&cfqg->blkg);
 }
 
 #ifdef CONFIG_CFQ_GROUP_IOSCHED
@@ -995,7 +995,7 @@
 
 	/* Add group onto cgroup list */
 	sscanf(dev_name(bdi->dev), "%u:%u", &major, &minor);
-	blkiocg_add_blkio_group(blkcg, &cfqg->blkg, (void *)cfqd,
+	cfq_blkiocg_add_blkio_group(blkcg, &cfqg->blkg, (void *)cfqd,
 					MKDEV(major, minor));
 	cfqg->weight = blkcg_get_weight(blkcg, cfqg->blkg.dev);
 
@@ -1079,7 +1079,7 @@
 		 * it from cgroup list, then it will take care of destroying
 		 * cfqg also.
 		 */
-		if (!blkiocg_del_blkio_group(&cfqg->blkg))
+		if (!cfq_blkiocg_del_blkio_group(&cfqg->blkg))
 			cfq_destroy_cfqg(cfqd, cfqg);
 	}
 }
@@ -1421,10 +1421,10 @@
 {
 	elv_rb_del(&cfqq->sort_list, rq);
 	cfqq->queued[rq_is_sync(rq)]--;
-	blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(rq),
-						rq_is_sync(rq));
+	cfq_blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg,
+					rq_data_dir(rq), rq_is_sync(rq));
 	cfq_add_rq_rb(rq);
-	blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
+	cfq_blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
 			&cfqq->cfqd->serving_group->blkg, rq_data_dir(rq),
 			rq_is_sync(rq));
 }
@@ -1482,8 +1482,8 @@
 	cfq_del_rq_rb(rq);
 
 	cfqq->cfqd->rq_queued--;
-	blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(rq),
-						rq_is_sync(rq));
+	cfq_blkiocg_update_io_remove_stats(&(RQ_CFQG(rq))->blkg,
+					rq_data_dir(rq), rq_is_sync(rq));
 	if (rq_is_meta(rq)) {
 		WARN_ON(!cfqq->meta_pending);
 		cfqq->meta_pending--;
@@ -1518,8 +1518,8 @@
 static void cfq_bio_merged(struct request_queue *q, struct request *req,
 				struct bio *bio)
 {
-	blkiocg_update_io_merged_stats(&(RQ_CFQG(req))->blkg, bio_data_dir(bio),
-					cfq_bio_sync(bio));
+	cfq_blkiocg_update_io_merged_stats(&(RQ_CFQG(req))->blkg,
+					bio_data_dir(bio), cfq_bio_sync(bio));
 }
 
 static void
@@ -1539,8 +1539,8 @@
 	if (cfqq->next_rq == next)
 		cfqq->next_rq = rq;
 	cfq_remove_request(next);
-	blkiocg_update_io_merged_stats(&(RQ_CFQG(rq))->blkg, rq_data_dir(next),
-					rq_is_sync(next));
+	cfq_blkiocg_update_io_merged_stats(&(RQ_CFQG(rq))->blkg,
+					rq_data_dir(next), rq_is_sync(next));
 }
 
 static int cfq_allow_merge(struct request_queue *q, struct request *rq,
@@ -1571,7 +1571,7 @@
 static inline void cfq_del_timer(struct cfq_data *cfqd, struct cfq_queue *cfqq)
 {
 	del_timer(&cfqd->idle_slice_timer);
-	blkiocg_update_idle_time_stats(&cfqq->cfqg->blkg);
+	cfq_blkiocg_update_idle_time_stats(&cfqq->cfqg->blkg);
 }
 
 static void __cfq_set_active_queue(struct cfq_data *cfqd,
@@ -1580,7 +1580,7 @@
 	if (cfqq) {
 		cfq_log_cfqq(cfqd, cfqq, "set_active wl_prio:%d wl_type:%d",
 				cfqd->serving_prio, cfqd->serving_type);
-		blkiocg_update_avg_queue_size_stats(&cfqq->cfqg->blkg);
+		cfq_blkiocg_update_avg_queue_size_stats(&cfqq->cfqg->blkg);
 		cfqq->slice_start = 0;
 		cfqq->dispatch_start = jiffies;
 		cfqq->allocated_slice = 0;
@@ -1911,7 +1911,7 @@
 	sl = cfqd->cfq_slice_idle;
 
 	mod_timer(&cfqd->idle_slice_timer, jiffies + sl);
-	blkiocg_update_set_idle_time_stats(&cfqq->cfqg->blkg);
+	cfq_blkiocg_update_set_idle_time_stats(&cfqq->cfqg->blkg);
 	cfq_log_cfqq(cfqd, cfqq, "arm_idle: %lu", sl);
 }
 
@@ -1931,7 +1931,7 @@
 	elv_dispatch_sort(q, rq);
 
 	cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]++;
-	blkiocg_update_dispatch_stats(&cfqq->cfqg->blkg, blk_rq_bytes(rq),
+	cfq_blkiocg_update_dispatch_stats(&cfqq->cfqg->blkg, blk_rq_bytes(rq),
 					rq_data_dir(rq), rq_is_sync(rq));
 }
 
@@ -3248,7 +3248,7 @@
 				cfq_clear_cfqq_wait_request(cfqq);
 				__blk_run_queue(cfqd->queue);
 			} else {
-				blkiocg_update_idle_time_stats(
+				cfq_blkiocg_update_idle_time_stats(
 						&cfqq->cfqg->blkg);
 				cfq_mark_cfqq_must_dispatch(cfqq);
 			}
@@ -3276,7 +3276,7 @@
 	rq_set_fifo_time(rq, jiffies + cfqd->cfq_fifo_expire[rq_is_sync(rq)]);
 	list_add_tail(&rq->queuelist, &cfqq->fifo);
 	cfq_add_rq_rb(rq);
-	blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
+	cfq_blkiocg_update_io_add_stats(&(RQ_CFQG(rq))->blkg,
 			&cfqd->serving_group->blkg, rq_data_dir(rq),
 			rq_is_sync(rq));
 	cfq_rq_enqueued(cfqd, cfqq, rq);
@@ -3364,9 +3364,9 @@
 	WARN_ON(!cfqq->dispatched);
 	cfqd->rq_in_driver--;
 	cfqq->dispatched--;
-	blkiocg_update_completion_stats(&cfqq->cfqg->blkg, rq_start_time_ns(rq),
-			rq_io_start_time_ns(rq), rq_data_dir(rq),
-			rq_is_sync(rq));
+	cfq_blkiocg_update_completion_stats(&cfqq->cfqg->blkg,
+			rq_start_time_ns(rq), rq_io_start_time_ns(rq),
+			rq_data_dir(rq), rq_is_sync(rq));
 
 	cfqd->rq_in_flight[cfq_cfqq_sync(cfqq)]--;
 
@@ -3730,7 +3730,7 @@
 
 	cfq_put_async_queues(cfqd);
 	cfq_release_cfq_groups(cfqd);
-	blkiocg_del_blkio_group(&cfqd->root_group.blkg);
+	cfq_blkiocg_del_blkio_group(&cfqd->root_group.blkg);
 
 	spin_unlock_irq(q->queue_lock);
 
@@ -3791,15 +3791,15 @@
 	/* Give preference to root group over other groups */
 	cfqg->weight = 2*BLKIO_WEIGHT_DEFAULT;
 
-#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	/*
 	 * Take a reference to root group which we never drop. This is just
 	 * to make sure that cfq_put_cfqg() does not try to kfree root group
 	 */
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
 	atomic_set(&cfqg->ref, 1);
 	rcu_read_lock();
-	blkiocg_add_blkio_group(&blkio_root_cgroup, &cfqg->blkg, (void *)cfqd,
-					0);
+	cfq_blkiocg_add_blkio_group(&blkio_root_cgroup, &cfqg->blkg,
+					(void *)cfqd, 0);
 	rcu_read_unlock();
 #endif
 	/*
Index: linux-2.6/block/cfq.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6/block/cfq.h	2010-06-12 09:12:42.497044544 -0400
@@ -0,0 +1,115 @@
+#ifndef _CFQ_H
+#define _CFQ_H
+#include "blk-cgroup.h"
+
+#ifdef CONFIG_CFQ_GROUP_IOSCHED
+static inline void cfq_blkiocg_update_io_add_stats(struct blkio_group *blkg,
+	struct blkio_group *curr_blkg, bool direction, bool sync)
+{
+	blkiocg_update_io_add_stats(blkg, curr_blkg, direction, sync);
+}
+
+static inline void cfq_blkiocg_update_dequeue_stats(struct blkio_group *blkg,
+			unsigned long dequeue)
+{
+	blkiocg_update_dequeue_stats(blkg, dequeue);
+}
+
+static inline void cfq_blkiocg_update_timeslice_used(struct blkio_group *blkg,
+			unsigned long time)
+{
+	blkiocg_update_timeslice_used(blkg, time);
+}
+
+static inline void cfq_blkiocg_set_start_empty_time(struct blkio_group *blkg)
+{
+	blkiocg_set_start_empty_time(blkg);
+}
+
+static inline void cfq_blkiocg_update_io_remove_stats(struct blkio_group *blkg,
+				bool direction, bool sync)
+{
+	blkiocg_update_io_remove_stats(blkg, direction, sync);
+}
+
+static inline void cfq_blkiocg_update_io_merged_stats(struct blkio_group *blkg,
+		bool direction, bool sync)
+{
+	blkiocg_update_io_merged_stats(blkg, direction, sync);
+}
+
+static inline void cfq_blkiocg_update_idle_time_stats(struct blkio_group *blkg)
+{
+	blkiocg_update_idle_time_stats(blkg);
+}
+
+static inline void
+cfq_blkiocg_update_avg_queue_size_stats(struct blkio_group *blkg)
+{
+	blkiocg_update_avg_queue_size_stats(blkg);
+}
+
+static inline void
+cfq_blkiocg_update_set_idle_time_stats(struct blkio_group *blkg)
+{
+	blkiocg_update_set_idle_time_stats(blkg);
+}
+
+static inline void cfq_blkiocg_update_dispatch_stats(struct blkio_group *blkg,
+				uint64_t bytes, bool direction, bool sync)
+{
+	blkiocg_update_dispatch_stats(blkg, bytes, direction, sync);
+}
+
+static inline void cfq_blkiocg_update_completion_stats(struct blkio_group *blkg, uint64_t start_time, uint64_t io_start_time, bool direction, bool sync)
+{
+	cfq_blkiocg_update_completion_stats(blkg, start_time, io_start_time,
+				direction, sync);
+}
+
+static inline void cfq_blkiocg_add_blkio_group(struct blkio_cgroup *blkcg,
+			struct blkio_group *blkg, void *key, dev_t dev) {
+	blkiocg_add_blkio_group(blkcg, blkg, key, dev);
+}
+
+static inline int cfq_blkiocg_del_blkio_group(struct blkio_group *blkg)
+{
+	return blkiocg_del_blkio_group(blkg);
+}
+
+#else /* CFQ_GROUP_IOSCHED */
+static inline void cfq_blkiocg_update_io_add_stats(struct blkio_group *blkg,
+	struct blkio_group *curr_blkg, bool direction, bool sync) {}
+
+static inline void cfq_blkiocg_update_dequeue_stats(struct blkio_group *blkg,
+			unsigned long dequeue) {}
+
+static inline void cfq_blkiocg_update_timeslice_used(struct blkio_group *blkg,
+			unsigned long time) {}
+static inline void cfq_blkiocg_set_start_empty_time(struct blkio_group *blkg) {}
+static inline void cfq_blkiocg_update_io_remove_stats(struct blkio_group *blkg,
+				bool direction, bool sync) {}
+static inline void cfq_blkiocg_update_io_merged_stats(struct blkio_group *blkg,
+		bool direction, bool sync) {}
+static inline void cfq_blkiocg_update_idle_time_stats(struct blkio_group *blkg)
+{
+}
+static inline void
+cfq_blkiocg_update_avg_queue_size_stats(struct blkio_group *blkg) {}
+
+static inline void
+cfq_blkiocg_update_set_idle_time_stats(struct blkio_group *blkg) {}
+
+static inline void cfq_blkiocg_update_dispatch_stats(struct blkio_group *blkg,
+				uint64_t bytes, bool direction, bool sync) {}
+static inline void cfq_blkiocg_update_completion_stats(struct blkio_group *blkg, uint64_t start_time, uint64_t io_start_time, bool direction, bool sync) {}
+
+static inline void cfq_blkiocg_add_blkio_group(struct blkio_cgroup *blkcg,
+			struct blkio_group *blkg, void *key, dev_t dev) {}
+static inline int cfq_blkiocg_del_blkio_group(struct blkio_group *blkg)
+{
+	return 0;
+}
+
+#endif /* CFQ_GROUP_IOSCHED */
+#endif

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Rafael J. Wysocki]

On Wednesday 09 June 2010, Linus Torvalds wrote:
> 
> [ Added lots of cc's to direct specific people to look at the regressions 
>   that may or may not be theirs... ]
> 
> On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
> >
> >  * Quite a few of the already reported regressions may be related to the bug
> >    fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
> >    bug in scrup, vt.c"), so reporters please retest with this commit applied.]
> 
> From a quick look, most of them look unrelated to that unfortunate bug. 
> It's hard to tell for sure, of course (memory corruption can do pretty 
> much anything), but I'm not seeing the 07200720.. pattern at least.
> 
> And some of them do seem to be bisected to likely culprits and/or have 
> patches that are claimed to have fixed them.
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16163
> > Subject	: [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> > Submitter	: David John <davidjon@xenontk.org>
> > Date		: 2010-06-02 12:52 (7 days old)
> > Message-ID	: <4C065423.3000202@xenontk.org>
> > References	: http://marc.info/?l=linux-kernel&m=127548313828613&w=2
> 
> That has a "reverting the commit fixes it", and a confirmation from Nick 
> Bowler.
> 
> Eric, Carl: should I just revert that commit? Or do you have a fix?

This one is reported to have been fixed already.  Closed now.

...
> 
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16104
> > Subject	: Radeon KMS does not start after merge of the new PM-Code
> > Submitter	: Jan Kreuzer <kontrollator@gmx.de>
> > Date		: 2010-06-02 07:47 (7 days old)
> 
> This one also has a patch in Bugzilla, I think Airlie is just waiting to 
> calm down his queue and already removed the dependency on the temperature 
> code. DaveA?

This should be fixed by commit f8ed8b4c5d30b5214f185997131b06e35f6f7113, so
closing now.

Rafael

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Linus Torvalds]

On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
> > 
> > That has a "reverting the commit fixes it", and a confirmation from Nick 
> > Bowler.
> > 
> > Eric, Carl: should I just revert that commit? Or do you have a fix?
> 
> This one is reported to have been fixed already.  Closed now.

Heh. That "fixed already" is actually the revert. Carl acked it.

> This should be fixed by commit f8ed8b4c5d30b5214f185997131b06e35f6f7113, so
> closing now.

Good, that was in yesterday's drm pull.

		Linus

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Alex Chiang]

* Linus Torvalds <torvalds@linux-foundation.org>:
> On Wed, 9 Jun 2010, Rafael J. Wysocki wrote:
> > Bug-Entry     : http://bugzilla.kernel.org/show_bug.cgi?id=16161
> > Subject       : [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
> > Submitter     : Mikael Pettersson <mikpe@it.uu.se>
> > Date          : 2010-06-01 19:57 (8 days old)
> > Message-ID    : <19461.26166.427857.612983@pilspetsen.it.uu.se>
> > References    : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
> >
> > Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16090
> > Subject	: sysfs: cannot create duplicate filename
> > Submitter	: Tobias <devnull@plzk.org>
> > Date		: 2010-06-01 15:59 (8 days old)
> > Handled-By	: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> These two look related. Both are related to that "slot" thing in sysfs 
> PCI, but only one of them is marked as Jesse's. Jesse?

Both related, yes.

I asked Jesse to revert the patch, so expect that to come
shortly.

Thanks,
/ac

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Sedat Dilek]

The patch from [1] is still missing.

   "cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
Dmitry Monakhoc

Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>

I have already reported this issue on LKML [2] and cpufreq ML [3].

- Sedat -

[1] http://www.spinics.net/lists/cpufreq/msg01631.html
[2] http://lkml.org/lkml/2010/5/31/77
[3] http://www.spinics.net/lists/cpufreq/msg01637.html

On Wed, Jun 9, 2010 at 12:06 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> [NOTES:
>  * This by no means is a complete list, but we only put e-mail reports that
>   are at least 1 week old into the Bugzilla.
>  * Quite a few of the already reported regressions may be related to the bug
>   fixed by 386f40c86d6c8d5b717ef20620af1a750d0dacb4 (Revert "tty: fix a little
>   bug in scrup, vt.c"), so reporters please retest with this commit applied.]
>
> This message contains a list of some regressions from 2.6.34,
> 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 2.6.34, 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
>  ----------------------------------------
>  2010-06-09       15       13          10
>
>
> Unresolved regressions
> ----------------------
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16163
> Subject         : [2.6.35-rc1 Regression] i915: Commit cfecde causes VGA to stay off
> Submitter       : David John <davidjon@xenontk.org>
> Date            : 2010-06-02 12:52 (7 days old)
> Message-ID      : <4C065423.3000202@xenontk.org>
> References      : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16161
> Subject         : [2.6.35-rc1 regression] sysfs: cannot create duplicate filename ... XVR-600 related?
> Submitter       : Mikael Pettersson <mikpe@it.uu.se>
> Date            : 2010-06-01 19:57 (8 days old)
> Message-ID      : <19461.26166.427857.612983@pilspetsen.it.uu.se>
> References      : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16160
> Subject         : 2.6.35 Radeon KMS power management regression?
> Submitter       : Nigel Cunningham <ncunningham@crca.org.au>
> Date            : 2010-06-01 6:23 (8 days old)
> Message-ID      : <4C04A767.8000209@crca.org.au>
> References      : http://marc.info/?l=linux-kernel&m=127537343722290&w=2
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16145
> Subject         : Unable to boot after "ACPI: Don't let acpi_pad needlessly mark TSC unstable"
> Submitter       : Tom Gundersen <teg@jklm.no>
> Date            : 2010-06-07 13:11 (2 days old)
> Handled-By      : Venkatesh Pallipadi <venki@google.com>
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16129
> Subject         : BUG: using smp_processor_id() in preemptible [00000000] code: jbd2/sda2
> Submitter       : Jan Kreuzer <kontrollator@gmx.de>
> Date            : 2010-06-05 06:15 (4 days old)
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16122
> Subject         : 2.6.35-rc1: WARNING at fs/fs-writeback.c:1142 __mark_inode_dirty+0x103/0x170
> Submitter       : Larry Finger <Larry.Finger@lwfinger.net>
> Date            : 2010-06-04 13:18 (5 days old)
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16120
> Subject         : Oops: 0000 [#1] SMP, unable to handle kernel NULL pointer dereference at (null)
> Submitter       : Alex Zhavnerchik <alex.vizor@gmail.com>
> Date            : 2010-06-04 09:25 (5 days old)
> Handled-By      : Eric Dumazet <eric.dumazet@gmail.com>
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16104
> Subject         : Radeon KMS does not start after merge of the new PM-Code
> Submitter       : Jan Kreuzer <kontrollator@gmx.de>
> Date            : 2010-06-02 07:47 (7 days old)
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16090
> Subject         : sysfs: cannot create duplicate filename
> Submitter       : Tobias <devnull@plzk.org>
> Date            : 2010-06-01 15:59 (8 days old)
> Handled-By      : Jesse Barnes <jbarnes@virtuousgeek.org>
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16037
> Subject         : NULL Pointer dereference in __ir_input_register/budget_ci_attach
> Submitter       : Sean Finney <seanius@debian.org>
> Date            : 2010-05-23 19:52 (17 days old)
>
>
> Regressions with patches
> ------------------------
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16131
> Subject         : kernel BUG at fs/btrfs/extent-tree.c:4363 (btrfs_free_tree_block)
> Submitter       : Chow Loong Jin <hyperair@ubuntu.com>
> Date            : 2010-06-05 18:53 (4 days old)
> Handled-By      : Yan Zheng <zheng.yan@oracle.com>
> Patch           : https://patchwork.kernel.org/patch/103235/
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16127
> Subject         : Boot freeze on HP Compaq nx6325 (RS482) with Radeon KMS
> Submitter       : Jure Repinc <jlp.bugs@gmail.com>
> Date            : 2010-06-04 21:14 (5 days old)
> Handled-By      : Dave Airlie <airlied@linux.ie>
> Patch           : https://bugzilla.kernel.org/attachment.cgi?id=26677
>
>
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16092
> Subject         : Caught 64-bit read from uninitialized memory in memtype_rb_augment_cb
> Submitter       : Christian Casteyde <casteyde.christian@free.fr>
> Date            : 2010-06-01 18:08 (8 days old)
> Handled-By      : Venki <venki@google.com>
> Patch           : https://bugzilla.kernel.org/show_bug.cgi?id=16092#c2
>
>
> 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 2.6.34,
> unresolved as well as resolved, at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=16055
>
> Please let the tracking team know if there are any Bugzilla entries that
> should be added to the list in there.
>
> Thanks!
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Rafael J. Wysocki]

On Wednesday 09 June 2010, Sedat Dilek wrote:
> The patch from [1] is still missing.
> 
>    "cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
> Dmitry Monakhoc
> 
> Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
> 
> I have already reported this issue on LKML [2] and cpufreq ML [3].
> 
> - Sedat -
> 
> [1] http://www.spinics.net/lists/cpufreq/msg01631.html
> [2] http://lkml.org/lkml/2010/5/31/77
> [3] http://www.spinics.net/lists/cpufreq/msg01637.html

Thanks, added.

Rafael

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Andrew Morton]

On Wed, 9 Jun 2010 11:22:35 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> On Wednesday 09 June 2010, Sedat Dilek wrote:
> > The patch from [1] is still missing.
> > 
> >    "cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
> > Dmitry Monakhoc
> > 
> > Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> > Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
> > 
> > I have already reported this issue on LKML [2] and cpufreq ML [3].
> > 
> > - Sedat -
> > 
> > [1] http://www.spinics.net/lists/cpufreq/msg01631.html
> > [2] http://lkml.org/lkml/2010/5/31/77
> > [3] http://www.spinics.net/lists/cpufreq/msg01637.html
> 
> Thanks, added.

I just merged a different patch whcih should address this:


From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

Fix

 BUG: using smp_processor_id() in preemptible [00000000] code: s2disk/3392
 caller is nr_iowait_cpu+0xe/0x1e
 Pid: 3392, comm: s2disk Not tainted 2.6.35-rc3-dbg-00106-ga75e02b #2
 Call Trace:
 [<c1184c55>] debug_smp_processor_id+0xa5/0xbc
 [<c10282a5>] nr_iowait_cpu+0xe/0x1e
 [<c104ab7c>] update_ts_time_stats+0x32/0x6c
 [<c104ac73>] get_cpu_idle_time_us+0x36/0x58
 [<c124229b>] get_cpu_idle_time+0x12/0x74
 [<c1242963>] cpufreq_governor_dbs+0xc3/0x2dc
 [<c1240437>] __cpufreq_governor+0x51/0x85
 [<c1241190>] __cpufreq_set_policy+0x10c/0x13d
 [<c12413d3>] cpufreq_add_dev_interface+0x212/0x233
 [<c1241b1e>] ? handle_update+0x0/0xd
 [<c1241a18>] cpufreq_add_dev+0x34b/0x35a
 [<c103c973>] ? schedule_delayed_work_on+0x11/0x13
 [<c12c14db>] cpufreq_cpu_callback+0x59/0x63
 [<c1042f39>] notifier_call_chain+0x26/0x48
 [<c1042f7d>] __raw_notifier_call_chain+0xe/0x10
 [<c102efb9>] __cpu_notify+0x15/0x29
 [<c102efda>] cpu_notify+0xd/0xf
 [<c12bfb30>] _cpu_up+0xaf/0xd2
 [<c12b3ad4>] enable_nonboot_cpus+0x3d/0x94
 [<c1055eef>] hibernation_snapshot+0x104/0x1a2
 [<c1058b49>] snapshot_ioctl+0x24b/0x53e
 [<c1028ad1>] ? sub_preempt_count+0x7c/0x89
 [<c10ab91d>] vfs_ioctl+0x2e/0x8c
 [<c10588fe>] ? snapshot_ioctl+0x0/0x53e
 [<c10ac2c7>] do_vfs_ioctl+0x42f/0x45a
 [<c10a0ba5>] ? fsnotify_modify+0x4f/0x5a
 [<c11e9dc3>] ? tty_write+0x0/0x1d0
 [<c10a12d6>] ? vfs_write+0xa2/0xda
 [<c10ac333>] sys_ioctl+0x41/0x62
 [<c10027d3>] sysenter_do_call+0x12/0x2d

The initial fix was to use get_cpu/put_cpu in nr_iowait_cpu.  However,
Arjan stated that "the bug is that it needs to be nr_iowait_cpu(int cpu)".

This patch introduces nr_iowait_cpu(int cpu) and changes to it callers.

akpm: addresses about 30,000,000 different bug reports.

Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/cpuidle/governors/menu.c |   10 ++++++++--
 include/linux/sched.h            |    2 +-
 kernel/sched.c                   |    4 ++--
 kernel/time/tick-sched.c         |    4 +++-
 4 files changed, 14 insertions(+), 6 deletions(-)

diff -puN drivers/cpuidle/governors/menu.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu drivers/cpuidle/governors/menu.c
--- a/drivers/cpuidle/governors/menu.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
+++ a/drivers/cpuidle/governors/menu.c
@@ -137,15 +137,18 @@ static inline int which_bucket(unsigned 
 {
 	int bucket = 0;
 
+	int cpu = get_cpu();
 	/*
 	 * We keep two groups of stats; one with no
 	 * IO pending, one without.
 	 * This allows us to calculate
 	 * E(duration)|iowait
 	 */
-	if (nr_iowait_cpu())
+	if (nr_iowait_cpu(cpu))
 		bucket = BUCKETS/2;
 
+	put_cpu();
+
 	if (duration < 10)
 		return bucket;
 	if (duration < 100)
@@ -169,13 +172,16 @@ static inline int which_bucket(unsigned 
 static inline int performance_multiplier(void)
 {
 	int mult = 1;
+	int cpu = get_cpu();
 
 	/* for higher loadavg, we are more reluctant */
 
 	mult += 2 * get_loadavg();
 
 	/* for IO wait tasks (per cpu!) we add 5x each */
-	mult += 10 * nr_iowait_cpu();
+	mult += 10 * nr_iowait_cpu(cpu);
+
+	put_cpu();
 
 	return mult;
 }
diff -puN include/linux/sched.h~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu include/linux/sched.h
--- a/include/linux/sched.h~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
+++ a/include/linux/sched.h
@@ -139,7 +139,7 @@ extern int nr_processes(void);
 extern unsigned long nr_running(void);
 extern unsigned long nr_uninterruptible(void);
 extern unsigned long nr_iowait(void);
-extern unsigned long nr_iowait_cpu(void);
+extern unsigned long nr_iowait_cpu(int cpu);
 extern unsigned long this_cpu_load(void);
 
 
diff -puN kernel/sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu kernel/sched.c
--- a/kernel/sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
+++ a/kernel/sched.c
@@ -2864,9 +2864,9 @@ unsigned long nr_iowait(void)
 	return sum;
 }
 
-unsigned long nr_iowait_cpu(void)
+unsigned long nr_iowait_cpu(int cpu)
 {
-	struct rq *this = this_rq();
+	struct rq *this = cpu_rq(cpu);
 	return atomic_read(&this->nr_iowait);
 }
 
diff -puN kernel/time/tick-sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu kernel/time/tick-sched.c
--- a/kernel/time/tick-sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
+++ a/kernel/time/tick-sched.c
@@ -159,10 +159,12 @@ update_ts_time_stats(struct tick_sched *
 	ktime_t delta;
 
 	if (ts->idle_active) {
+		int cpu = get_cpu();
 		delta = ktime_sub(now, ts->idle_entrytime);
 		ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
-		if (nr_iowait_cpu() > 0)
+		if (nr_iowait_cpu(cpu) > 0)
 			ts->iowait_sleeptime = ktime_add(ts->iowait_sleeptime, delta);
+		put_cpu();
 		ts->idle_entrytime = now;
 	}
 
_

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Sedat Dilek]

How do cpu-freq related stuff find its way into mainline?
Is there a GIT repository/branch on <git.kernel.org> where you can pull from?

- Sedat -

On Wed, Jun 16, 2010 at 10:42 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Wed, 9 Jun 2010 11:22:35 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
>> On Wednesday 09 June 2010, Sedat Dilek wrote:
>> > The patch from [1] is still missing.
>> >
>> >    "cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
>> > Dmitry Monakhoc
>> >
>> > Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
>> > Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
>> >
>> > I have already reported this issue on LKML [2] and cpufreq ML [3].
>> >
>> > - Sedat -
>> >
>> > [1] http://www.spinics.net/lists/cpufreq/msg01631.html
>> > [2] http://lkml.org/lkml/2010/5/31/77
>> > [3] http://www.spinics.net/lists/cpufreq/msg01637.html
>>
>> Thanks, added.
>
> I just merged a different patch whcih should address this:
>
>
> From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>
> Fix
>
>  BUG: using smp_processor_id() in preemptible [00000000] code: s2disk/3392
>  caller is nr_iowait_cpu+0xe/0x1e
>  Pid: 3392, comm: s2disk Not tainted 2.6.35-rc3-dbg-00106-ga75e02b #2
>  Call Trace:
>  [<c1184c55>] debug_smp_processor_id+0xa5/0xbc
>  [<c10282a5>] nr_iowait_cpu+0xe/0x1e
>  [<c104ab7c>] update_ts_time_stats+0x32/0x6c
>  [<c104ac73>] get_cpu_idle_time_us+0x36/0x58
>  [<c124229b>] get_cpu_idle_time+0x12/0x74
>  [<c1242963>] cpufreq_governor_dbs+0xc3/0x2dc
>  [<c1240437>] __cpufreq_governor+0x51/0x85
>  [<c1241190>] __cpufreq_set_policy+0x10c/0x13d
>  [<c12413d3>] cpufreq_add_dev_interface+0x212/0x233
>  [<c1241b1e>] ? handle_update+0x0/0xd
>  [<c1241a18>] cpufreq_add_dev+0x34b/0x35a
>  [<c103c973>] ? schedule_delayed_work_on+0x11/0x13
>  [<c12c14db>] cpufreq_cpu_callback+0x59/0x63
>  [<c1042f39>] notifier_call_chain+0x26/0x48
>  [<c1042f7d>] __raw_notifier_call_chain+0xe/0x10
>  [<c102efb9>] __cpu_notify+0x15/0x29
>  [<c102efda>] cpu_notify+0xd/0xf
>  [<c12bfb30>] _cpu_up+0xaf/0xd2
>  [<c12b3ad4>] enable_nonboot_cpus+0x3d/0x94
>  [<c1055eef>] hibernation_snapshot+0x104/0x1a2
>  [<c1058b49>] snapshot_ioctl+0x24b/0x53e
>  [<c1028ad1>] ? sub_preempt_count+0x7c/0x89
>  [<c10ab91d>] vfs_ioctl+0x2e/0x8c
>  [<c10588fe>] ? snapshot_ioctl+0x0/0x53e
>  [<c10ac2c7>] do_vfs_ioctl+0x42f/0x45a
>  [<c10a0ba5>] ? fsnotify_modify+0x4f/0x5a
>  [<c11e9dc3>] ? tty_write+0x0/0x1d0
>  [<c10a12d6>] ? vfs_write+0xa2/0xda
>  [<c10ac333>] sys_ioctl+0x41/0x62
>  [<c10027d3>] sysenter_do_call+0x12/0x2d
>
> The initial fix was to use get_cpu/put_cpu in nr_iowait_cpu.  However,
> Arjan stated that "the bug is that it needs to be nr_iowait_cpu(int cpu)".
>
> This patch introduces nr_iowait_cpu(int cpu) and changes to it callers.
>
> akpm: addresses about 30,000,000 different bug reports.
>
> Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Cc: Arjan van de Ven <arjan@infradead.org>
> Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
> Cc: Maxim Levitsky <maximlevitsky@gmail.com>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Jiri Slaby <jslaby@suse.cz>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
>  drivers/cpuidle/governors/menu.c |   10 ++++++++--
>  include/linux/sched.h            |    2 +-
>  kernel/sched.c                   |    4 ++--
>  kernel/time/tick-sched.c         |    4 +++-
>  4 files changed, 14 insertions(+), 6 deletions(-)
>
> diff -puN drivers/cpuidle/governors/menu.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu drivers/cpuidle/governors/menu.c
> --- a/drivers/cpuidle/governors/menu.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
> +++ a/drivers/cpuidle/governors/menu.c
> @@ -137,15 +137,18 @@ static inline int which_bucket(unsigned
>  {
>        int bucket = 0;
>
> +       int cpu = get_cpu();
>        /*
>         * We keep two groups of stats; one with no
>         * IO pending, one without.
>         * This allows us to calculate
>         * E(duration)|iowait
>         */
> -       if (nr_iowait_cpu())
> +       if (nr_iowait_cpu(cpu))
>                bucket = BUCKETS/2;
>
> +       put_cpu();
> +
>        if (duration < 10)
>                return bucket;
>        if (duration < 100)
> @@ -169,13 +172,16 @@ static inline int which_bucket(unsigned
>  static inline int performance_multiplier(void)
>  {
>        int mult = 1;
> +       int cpu = get_cpu();
>
>        /* for higher loadavg, we are more reluctant */
>
>        mult += 2 * get_loadavg();
>
>        /* for IO wait tasks (per cpu!) we add 5x each */
> -       mult += 10 * nr_iowait_cpu();
> +       mult += 10 * nr_iowait_cpu(cpu);
> +
> +       put_cpu();
>
>        return mult;
>  }
> diff -puN include/linux/sched.h~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu include/linux/sched.h
> --- a/include/linux/sched.h~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
> +++ a/include/linux/sched.h
> @@ -139,7 +139,7 @@ extern int nr_processes(void);
>  extern unsigned long nr_running(void);
>  extern unsigned long nr_uninterruptible(void);
>  extern unsigned long nr_iowait(void);
> -extern unsigned long nr_iowait_cpu(void);
> +extern unsigned long nr_iowait_cpu(int cpu);
>  extern unsigned long this_cpu_load(void);
>
>
> diff -puN kernel/sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu kernel/sched.c
> --- a/kernel/sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
> +++ a/kernel/sched.c
> @@ -2864,9 +2864,9 @@ unsigned long nr_iowait(void)
>        return sum;
>  }
>
> -unsigned long nr_iowait_cpu(void)
> +unsigned long nr_iowait_cpu(int cpu)
>  {
> -       struct rq *this = this_rq();
> +       struct rq *this = cpu_rq(cpu);
>        return atomic_read(&this->nr_iowait);
>  }
>
> diff -puN kernel/time/tick-sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu kernel/time/tick-sched.c
> --- a/kernel/time/tick-sched.c~cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu
> +++ a/kernel/time/tick-sched.c
> @@ -159,10 +159,12 @@ update_ts_time_stats(struct tick_sched *
>        ktime_t delta;
>
>        if (ts->idle_active) {
> +               int cpu = get_cpu();
>                delta = ktime_sub(now, ts->idle_entrytime);
>                ts->idle_sleeptime = ktime_add(ts->idle_sleeptime, delta);
> -               if (nr_iowait_cpu() > 0)
> +               if (nr_iowait_cpu(cpu) > 0)
>                        ts->iowait_sleeptime = ktime_add(ts->iowait_sleeptime, delta);
> +               put_cpu();
>                ts->idle_entrytime = now;
>        }
>
> _
>
>

Re: 2.6.35-rc2-git2: Reported regressions from 2.6.34

[Andrew Morton]

On Wed, 16 Jun 2010 23:00:37 +0200
Sedat Dilek <sedat.dilek@googlemail.com> wrote:

> On Wed, Jun 16, 2010 at 10:42 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 9 Jun 2010 11:22:35 +0200
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> >> On Wednesday 09 June 2010, Sedat Dilek wrote:
> >> > The patch from [1] is still missing.
> >> >
> >> > __ __"cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
> >> > Dmitry Monakhoc
> >> >
> >> > Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
> >> > Tested-by Maciej Rutecki <maciej.rutecki@gmail.com>
> >> >
> >> > I have already reported this issue on LKML [2] and cpufreq ML [3].
> >> >
> >> > - Sedat -
> >> >
> >> > [1] http://www.spinics.net/lists/cpufreq/msg01631.html
> >> > [2] http://lkml.org/lkml/2010/5/31/77
> >> > [3] http://www.spinics.net/lists/cpufreq/msg01637.html
> >>
> >> Thanks, added.
> >
> > I just merged a different patch whcih should address this:
>
> How do cpu-freq related stuff find its way into mainline?
> Is there a GIT repository/branch on <git.kernel.org> where you can pull from?
> 

(top-posting repaired.  Please don't)

Usually via the cpufreq git tree, mailing list and maintainer, as
described in ./MAINTAINERS.

But for a patch like this one, I'll just scoot it into mainline unless
Dave happens to grab it before I do that.