[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 <[email protected]>
Date : 2010-06-02 12:52 (7 days old)
Message-ID : <[email protected]>
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 <[email protected]>
Date : 2010-06-01 19:57 (8 days old)
Message-ID : <[email protected]>
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 <[email protected]>
Date : 2010-06-01 6:23 (8 days old)
Message-ID : <[email protected]>
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 <[email protected]>
Date : 2010-06-07 13:11 (2 days old)
Handled-By : Venkatesh Pallipadi <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2010-06-04 09:25 (5 days old)
Handled-By : Eric Dumazet <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2010-06-01 15:59 (8 days old)
Handled-By : Jesse Barnes <[email protected]>
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 <[email protected]>
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 <[email protected]>
Date : 2010-06-05 18:53 (4 days old)
Handled-By : Yan Zheng <[email protected]>
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 <[email protected]>
Date : 2010-06-04 21:14 (5 days old)
Handled-By : Dave Airlie <[email protected]>
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 <[email protected]>
Date : 2010-06-01 18:08 (8 days old)
Handled-By : Venki <[email protected]>
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!
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 <[email protected]>
Date : 2010-06-01 19:57 (8 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127542227511925&w=2
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 <[email protected]>
Date : 2010-06-05 06:15 (4 days old)
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 <[email protected]>
Date : 2010-06-07 13:11 (2 days old)
Handled-By : Venkatesh Pallipadi <[email protected]>
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 <[email protected]>
Date : 2010-06-04 21:14 (5 days old)
Handled-By : Dave Airlie <[email protected]>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=26677
[ 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 <[email protected]>
> Date : 2010-06-02 12:52 (7 days old)
> Message-ID : <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-07 13:11 (2 days old)
> Handled-By : Venkatesh Pallipadi <[email protected]>
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 <[email protected]>
> Date : 2010-06-05 06:15 (4 days old)
This seems to have been introduced by
commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
Author: Ingo Molnar <[email protected]>
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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-04 09:25 (5 days old)
> Handled-By : Eric Dumazet <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-01 19:57 (8 days old)
> Message-ID : <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-01 15:59 (8 days old)
> Handled-By : Jesse Barnes <[email protected]>
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 <[email protected]>
> Date : 2010-05-23 19:52 (17 days old)
Perhaps related to commit 13c24497086418010bf4f76378bcae241d7f59cd?
David H?rdeman, Mauro Carvalho Chehab added to cc.
Linus
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 <[email protected]>
> Date : 2010-06-04 13:18 (5 days old)
Still present in 2.6.35-rc2.
Larry
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 <[email protected]>
Date : 2010-06-04 09:25 (5 days old)
Handled-By : Eric Dumazet <[email protected]>
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 <[email protected]>
Date : 2010-06-01 6:23 (8 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127537343722290&w=2
* Linus Torvalds <[email protected]> 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 <[email protected]>
> > Date : 2010-06-05 06:15 (4 days old)
>
> This seems to have been introduced by
>
> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> Author: Ingo Molnar <[email protected]>
> 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 <[email protected]>
>
> 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 <[email protected]>
| 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
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 <[email protected]>
Date : 2010-06-01 15:59 (8 days old)
Handled-By : Jesse Barnes <[email protected]>
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 <[email protected]>
Date : 2010-06-02 07:47 (7 days old)
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 <[email protected]>
Date : 2010-05-23 19:52 (17 days old)
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 <[email protected]>
>> 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
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 <[email protected]>
Date : 2010-06-01 18:08 (8 days old)
Handled-By : Venki <[email protected]>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=16092#c2
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 <[email protected]>
Date : 2010-06-05 18:53 (4 days old)
Handled-By : Yan Zheng <[email protected]>
Patch : https://patchwork.kernel.org/patch/103235/
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 <[email protected]>
Date : 2010-06-02 12:52 (7 days old)
Message-ID : <[email protected]>
References : http://marc.info/?l=linux-kernel&m=127548313828613&w=2
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 <[email protected]>
Date : 2010-06-04 13:18 (5 days old)
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 <[email protected]>
> > Date : 2010-06-04 09:25 (5 days old)
> > Handled-By : Eric Dumazet <[email protected]>
>
> 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
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 <[email protected]>
>> Date : 2010-06-05 06:15 (4 days old)
>
> This seems to have been introduced by
>
> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> Author: Ingo Molnar <[email protected]>
> 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 <[email protected]>
>
> 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 <[email protected]>
>> Date : 2010-06-04 13:18 (5 days old)
>
> Jens?
Looking into this one.
--
Jens Axboe
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 <[email protected]>
> > Date : 2010-06-04 13:18 (5 days old)
>
> Still present in 2.6.35-rc2.
Thanks for the update.
Rafael
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 <[email protected]>
> >> Date : 2010-06-05 06:15 (4 days old)
> >
> > This seems to have been introduced by
> >
> > commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> > Author: Ingo Molnar <[email protected]>
> > 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 <[email protected]>
> >
> > 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
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 <[email protected]>
> >> 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
The patch from [1] is still missing.
"cpufreq-call-nr_iowait_cpu-with-disabled-preemption.patch" from
Dmitry Monakhoc
Tested-by: Sedat Dilek <[email protected]>
Tested-by Maciej Rutecki <[email protected]>
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 <[email protected]> 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 <[email protected]>
> Date : 2010-06-02 12:52 (7 days old)
> Message-ID : <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-01 19:57 (8 days old)
> Message-ID : <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-01 6:23 (8 days old)
> Message-ID : <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-07 13:11 (2 days old)
> Handled-By : Venkatesh Pallipadi <[email protected]>
>
>
> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-04 09:25 (5 days old)
> Handled-By : Eric Dumazet <[email protected]>
>
>
> 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 <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-01 15:59 (8 days old)
> Handled-By : Jesse Barnes <[email protected]>
>
>
> 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 <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-05 18:53 (4 days old)
> Handled-By : Yan Zheng <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-04 21:14 (5 days old)
> Handled-By : Dave Airlie <[email protected]>
> 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 <[email protected]>
> Date : 2010-06-01 18:08 (8 days old)
> Handled-By : Venki <[email protected]>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 <[email protected]>
> > Date : 2010-06-02 12:52 (7 days old)
> > Message-ID : <[email protected]>
> > 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 <[email protected]>
> > 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
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 <[email protected]>
> Tested-by Maciej Rutecki <[email protected]>
>
> 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
* Jens Axboe <[email protected]> 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 <[email protected]>
> >> Date : 2010-06-05 06:15 (4 days old)
> >
> > This seems to have been introduced by
> >
> > commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> > Author: Ingo Molnar <[email protected]>
> > 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 <[email protected]>
> >
> > 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
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
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 <[email protected]>
> Date : 2010-06-01 19:57 (8 days old)
> Message-ID : <[email protected]>
> 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.
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
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 <[email protected]>
> > Date : 2010-06-01 19:57 (8 days old)
> > Message-ID : <[email protected]>
> > 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
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 <[email protected]>
> > > Date : 2010-06-01 19:57 (8 days old)
> > > Message-ID : <[email protected]>
> > > 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
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 <[email protected]>
> > > > Date : 2010-06-01 19:57 (8 days old)
> > > > Message-ID : <[email protected]>
> > > > 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
* Linus Torvalds <[email protected]>:
> 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 <[email protected]>
> > Date : 2010-06-01 19:57 (8 days old)
> > Message-ID : <[email protected]>
> > 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 <[email protected]>
> > Date : 2010-06-01 15:59 (8 days old)
> > Handled-By : Jesse Barnes <[email protected]>
>
> 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
On 2010-06-11 10:32, Ingo Molnar wrote:
>
> * Jens Axboe <[email protected]> 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 <[email protected]>
>>>> Date : 2010-06-05 06:15 (4 days old)
>>>
>>> This seems to have been introduced by
>>>
>>> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
>>> Author: Ingo Molnar <[email protected]>
>>> 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 <[email protected]>
>>>
>>> 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
* Jens Axboe <[email protected]> wrote:
> On 2010-06-11 10:32, Ingo Molnar wrote:
> >
> > * Jens Axboe <[email protected]> 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 <[email protected]>
> >>>> Date : 2010-06-05 06:15 (4 days old)
> >>>
> >>> This seems to have been introduced by
> >>>
> >>> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
> >>> Author: Ingo Molnar <[email protected]>
> >>> 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 <[email protected]>
> >>>
> >>> 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
On 2010-06-11 10:55, Ingo Molnar wrote:
>
> * Jens Axboe <[email protected]> wrote:
>
>> On 2010-06-11 10:32, Ingo Molnar wrote:
>>>
>>> * Jens Axboe <[email protected]> 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 <[email protected]>
>>>>>> Date : 2010-06-05 06:15 (4 days old)
>>>>>
>>>>> This seems to have been introduced by
>>>>>
>>>>> commit 7cbaef9c83e58bbd4bdd534b09052b6c5ec457d5
>>>>> Author: Ingo Molnar <[email protected]>
>>>>> 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 <[email protected]>
>>>>>
>>>>> 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
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
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
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
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
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
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
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 <[email protected]>
> > > > Date : 2010-06-01 19:57 (8 days old)
> > > > Message-ID : <[email protected]>
> > > > 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.
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 <[email protected]>
> > > > > Date : 2010-06-01 19:57 (8 days old)
> > > > > Message-ID : <[email protected]>
> > > > > 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
On Wed, 9 Jun 2010 11:22:35 +0200
"Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
> > Tested-by Maciej Rutecki <[email protected]>
> >
> > 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 <[email protected]>
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 <[email protected]>
Cc: Arjan van de Ven <[email protected]>
Cc: "Rafael J. Wysocki" <[email protected]>
Cc: Maxim Levitsky <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Jiri Slaby <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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;
}
_
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
<[email protected]> wrote:
> On Wed, 9 Jun 2010 11:22:35 +0200
> "Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
>> > Tested-by Maciej Rutecki <[email protected]>
>> >
>> > 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 <[email protected]>
>
> 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 <[email protected]>
> Cc: Arjan van de Ven <[email protected]>
> Cc: "Rafael J. Wysocki" <[email protected]>
> Cc: Maxim Levitsky <[email protected]>
> Cc: Len Brown <[email protected]>
> Cc: Pavel Machek <[email protected]>
> Cc: Jiri Slaby <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> 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;
> }
>
> _
>
>
On Wed, 16 Jun 2010 23:00:37 +0200
Sedat Dilek <[email protected]> wrote:
> On Wed, Jun 16, 2010 at 10:42 PM, Andrew Morton
> <[email protected]> wrote:
> > On Wed, 9 Jun 2010 11:22:35 +0200
> > "Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
> >> > Tested-by Maciej Rutecki <[email protected]>
> >> >
> >> > 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.
On Sat, 12 Jun 2010 20:52:25 +0200
"Rafael J. Wysocki" <[email protected]> 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 <[email protected]>
> > > > > > Date : 2010-06-01 19:57 (8 days old)
> > > > > > Message-ID : <[email protected]>
> > > > > > 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
From: Jesse Barnes <[email protected]>
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
On 06/18/2010 04:26 PM, David Miller wrote:
> From: Jesse Barnes <[email protected]>
> 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 <[email protected]>
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: [email protected]
Signed-off-by: Alex Chiang <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
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: [email protected]
+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: [email protected]
+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: [email protected]
+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: [email protected]
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;
On Fri, 18 Jun 2010 16:40:44 -0400
Brian Bloniarz <[email protected]> wrote:
> On 06/18/2010 04:26 PM, David Miller wrote:
> > From: Jesse Barnes <[email protected]>
> > 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
From: Brian Bloniarz <[email protected]>
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.
* David Miller <[email protected]>:
> From: Brian Bloniarz <[email protected]>
> 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