* mmotm 2010-08-11-16-10 uploaded
@ 2010-08-11 23:10 akpm
2010-08-12 16:18 ` mmotm 2010-08-11 - RCU whinge during very early boot Valdis.Kletnieks
` (3 more replies)
0 siblings, 4 replies; 20+ messages in thread
From: akpm @ 2010-08-11 23:10 UTC (permalink / raw)
To: mm-commits, linux-kernel
The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
http://userweb.kernel.org/~akpm/mmotm/
and will soon be available at
git://zen-kernel.org/kernel/mmotm.git
It contains the following patches against 2.6.35:
origin.patch
kernel-kfifoc-add-handling-of-chained-scatterlists.patch
acpi-fix-bogus-preemption-logic.patch
mm-fix-fatal-kernel-doc-error.patch
pc8736x_gpio-depends-on-x86_32.patch
score-fix-dereference-of-null-pointer-in-local_flush_tlb_page.patch
parisc-fix-wrong-page-aligned-size-calculation-in-ioremapping-code.patch
fs-move-code-out-of-bufferc.patch
writeback-reduce-calls-to-global_page_state-in-balance_dirty_pages.patch
writeback-avoid-unnecessary-calculation-of-bdi-dirty-thresholds.patch
writeback-add-comment-to-the-dirty-limit-functions.patch
writeback-dont-redirty-tail-an-inode-with-dirty-pages.patch
writeback-fix-queue_io-ordering.patch
writeback-merge-for_kupdate-and-for_kupdate-cases.patch
mm-fix-writeback_in_progress.patch
mmc-add-erase-secure-erase-trim-and-secure-trim-operations.patch
mmc_block-add-discard-support.patch
omap_hsmmc-add-erase-capability.patch
block-add-secure-discard.patch
mmc_block-add-support-for-secure-discard.patch
mmc_test-add-performance-tests.patch
mmc_test-fix-large-memory-allocation.patch
memstick-init-sysfs-attributes.patch
memstick-fix-hangs-on-unexpected-device-removal-in-mspro_blk.patch
aio-always-reinitialize-iocb-ki_run_list-at-the-end-of-aio_run_iocb.patch
matroxfb-fix-incorrect-use-of-memcpy_toio.patch
linux-next.patch
linux-next-git-rejects.patch
next-remove-localversion.patch
fs-inodec-work-around-bug.patch
i-need-old-gcc.patch
mm-vmap-area-cache.patch
backlight-fix-88pm860x_bl-macro-collision.patch
drivers-power-ds2782_batteryc-fix-ds2782-battery-driver-units.patch
gcc-46-acpi-fix-unused-but-set-variables-in-acpi.patch
drivers-acpi-debugfsc-needs-uaccessh.patch
drivers-acpi-apei-erst-dbgc-get_useru64-doesnt-work-on-i386.patch
parport-prevent-arm-boards-frmo-crashing-when-cups-is-loaded.patch
parport-prevent-arm-boards-frmo-crashing-when-cups-is-loaded-fix.patch
fs-btrfs-use-memdup_user.patch
fs-btrfs-use-err_cast.patch
gcc-46-btrfs-clean-up-unused-variables-bugs.patch
gcc-46-btrfs-clean-up-unused-variables-nonbugs.patch
gcc-46-irq-move-alloc_desk_mask-variables-inside-ifdef.patch
hpet-factor-timer-allocate-from-open.patch
timer_list-remove-alignment-padding-on-64-bit-when-config_timer_stats.patch
kbuild-fix-config_cross_compile-issue-in-config.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
mtdpart-memory-accessor-interface-for-mtd-layer.patch
drivers-video-backlight-s6e63m0c-set-permissions-on-gamma_table-file-to-0444.patch
backlight-fix-blanking-for-lms283gf05-lcd.patch
backlight-fix-blanking-for-l4f00242t03-lcd.patch
backlight-s6e63m0-unregister-backlight-device-and-remove-sysfs-attribute-file-in-s6e63m0_remove.patch
backlight-s6e63m0-fix-section-mismatch.patch
btusb-patch-add_apple_macbookpro62.patch
drivers-serial-68328serialc-check-return-value-of-copy__user-instead-of-access_ok.patch
gcc-46-perf-fix-set-but-unused-variables-in-perf.patch
gcc-46-kernel-fix-unused-but-set-warnings.patch
security-add-const-to-security_task_setscheduler.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
percpu-fix-list_head-init-bug-in-__percpu_counter_init.patch
drivers-scsi-qla4xxx-fix-build.patch
fs-bio-integrityc-remove-dependency-on-__gfp_nofail.patch
fs-bio-integrityc-return-enomem-on-kmalloc-failure.patch
drivers-usb-serial-io_tic-dont-return-0-if-writing-the-download-record-failed.patch
scsi-sr-add-no_read_disc_info-scsi_device-flag.patch
usb-storage-add-new-no_read_disc_info-quirk.patch
usb-storage-add-new-no_read_disc_info-quirk-fix.patch
scsi-sd-add-a-no_read_capacity_16-scsi_device-flag.patch
usb-storage-add-new-no_read_capacity_16-quirk.patch
vfs-introduce-fmode_neg_offset-for-allowing-negative-f_pos.patch
mm.patch
define-madv_hugepage.patch
vmscan-do-not-writeback-filesystem-pages-in-direct-reclaim.patch
vmscan-kick-flusher-threads-to-clean-pages-when-reclaim-is-encountering-dirty-pages.patch
frv-duplicate-output_buffer-of-e03.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
lib-div64c-document-that-div64_u64-is-not-precise-on-32bit-platforms.patch
s5pc110-sdhci-s3c-can-override-host-capabilities.patch
s5pc110-sdhci-s3c-support-on-s5pc110.patch
sdhci-add-no-hi-speed-bit-quirk-support.patch
sdhci-turn-timeout-timer-into-delayed-work.patch
sdhci-use-work-structs-instead-of-tasklets.patch
sdhci-use-work-structs-instead-of-tasklets-fix.patch
sdhci-clear-interrupt-status-register-just-once.patch
sdhci-use-threaded-irq-handler.patch
sdhci-turn-host-lock-into-a-mutex.patch
sdhci-get-rid-of-card-detect-work.patch
sdhci-get-rid-of-card-detect-work-fix.patch
sdhci-get-rid-of-mdelays-where-it-is-safe-and-makes-sense.patch
sdhci-use-jiffies-instead-of-a-timeout-counter.patch
checkpatchpl-add-check-for-space-after-struct-or-union-definition.patch
jbd-remove-dependency-on-__gfp_nofail.patch
hfsplus-identify-journal-info-block-in-volume-header.patch
hfsplus-fix-journal-detection.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
delayacct-align-to-8-byte-boundary-on-64-bit-systems.patch
pps-trivial-fixes.patch
pps-declare-variables-where-they-are-used-in-switch.patch
pps-fix-race-in-pps_fetch-handler.patch
pps-unify-timestamp-gathering.patch
pps-access-pps-device-by-direct-pointer.patch
pps-convert-printk-pr_-to-dev_.patch
pps-move-idr-stuff-to-ppsc.patch
pps-add-async-pps-event-handler.patch
pps-add-async-pps-event-handler-fix.patch
pps-dont-disable-interrupts-when-using-spin-locks.patch
pps-use-bug_on-for-kernel-api-safety-checks.patch
pps-simplify-conditions-a-bit.patch
ntp-add-hardpps-implementation.patch
pps-capture-monotonic_raw-timestamps-as-well.patch
pps-add-kernel-consumer-support.patch
pps-add-parallel-port-pps-client.patch
pps-add-parallel-port-pps-signal-generator.patch
memstick-add-driver-for-ricoh-r5c592-card-reader.patch
memstick-add-driver-for-ricoh-r5c592-card-reader-cleanups.patch
aio-do-not-return-erestartsys-and-friends-from-aio.patch
vfs-add-super-operation-writeback_inodes.patch
vfs-add-super-operation-writeback_inodes-fix.patch
vfs-take-2add-set_page_dirty_notag.patch
vfs-change-writeback_inodes-signature.patch
reiser4-export-remove_from_page_cache.patch
reiser4-export-remove_from_page_cache-fix.patch
reiser4-export-find_get_pages.patch
reiser4.patch
reiser4-rename-quota-methods.patch
reiser4-remove-inode_setattr.patch
reiser4-change-fsync-signature.patch
reiser4-writeback_inodes-implementation.patch
reiser4-writeback_inodes-implementation-fix.patch
reiser4-writeback_inodes-implementation-adjust-to-writeback-changes.patch
reiser4-fixup-checkin-checkout-jnodes-for-entd.patch
reiser4-fixups.patch
reiser4-broke.patch
make-sure-nobodys-leaking-resources.patch
journal_add_journal_head-debug.patch
releasing-resources-with-children.patch
make-frame_pointer-default=y.patch
mutex-subsystem-synchro-test-module.patch
mutex-subsystem-synchro-test-module-add-missing-header-file.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
add-debugging-aid-for-memory-initialisation-problems.patch
workaround-for-a-pci-restoring-bug.patch
prio_tree-debugging-patch.patch
single_open-seq_release-leak-diagnostics.patch
add-a-refcount-check-in-dput.patch
getblk-handle-2tb-devices.patch
^ permalink raw reply [flat|nested] 20+ messages in thread
* mmotm 2010-08-11 - RCU whinge during very early boot
2010-08-11 23:10 mmotm 2010-08-11-16-10 uploaded akpm
@ 2010-08-12 16:18 ` Valdis.Kletnieks
2010-08-16 17:23 ` Paul E. McKenney
2010-10-05 10:05 ` Zdenek Kabelac
2010-08-12 16:36 ` [PATCH] mmc: fix for CONFIG_PM disabled Randy Dunlap
` (2 subsequent siblings)
3 siblings, 2 replies; 20+ messages in thread
From: Valdis.Kletnieks @ 2010-08-12 16:18 UTC (permalink / raw)
To: Andrew Morton, Ingo Molnar, Peter Zijlstra, Thomas Gleixner; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
[ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
[ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
[ 0.030019] lockdep: fixing up alternatives.
[ 0.031178]
[ 0.031179] ===================================================
[ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 0.031184] ---------------------------------------------------
[ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
[ 0.031189]
[ 0.031189] other info that might help us debug this:
[ 0.031190]
[ 0.031192]
[ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
[ 0.031195] 3 locks held by kworker/0:0/4:
[ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
[ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
[ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
[ 0.031225]
[ 0.031226] stack backtrace:
[ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
[ 0.031232] Call Trace:
[ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
[ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
[ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
[ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
[ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
[ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
[ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
[ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
[ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
[ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
[ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
[ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
[ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
[ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
[ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
[ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
[ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
[ 0.031333] Booting Node 0, Processors #1 Ok.
[ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
[ 0.104013] Brought up 2 CPUs
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] mmc: fix for CONFIG_PM disabled
2010-08-11 23:10 mmotm 2010-08-11-16-10 uploaded akpm
2010-08-12 16:18 ` mmotm 2010-08-11 - RCU whinge during very early boot Valdis.Kletnieks
@ 2010-08-12 16:36 ` Randy Dunlap
2010-08-18 9:10 ` Uwe Kleine-König
2010-08-12 16:37 ` mmotm 2010-08-11 - lockdep whinges at e1000e driver ifconfig up Valdis.Kletnieks
2010-08-12 18:59 ` Valdis.Kletnieks
3 siblings, 1 reply; 20+ messages in thread
From: Randy Dunlap @ 2010-08-12 16:36 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, linux-mmc
From: Randy Dunlap <randy.dunlap@oracle.com>
Minimal patch to fix mmc to build when CONFIG_PM is not enabled:
(.text+0x128fcd): undefined reference to `mmc_pm_notify'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/mmc/core/host.c | 2 ++
1 file changed, 2 insertions(+)
Seems to be needed in mainline also.
--- mmotm-2010-0811-1610.orig/drivers/mmc/core/host.c
+++ mmotm-2010-0811-1610/drivers/mmc/core/host.c
@@ -86,7 +86,9 @@ struct mmc_host *mmc_alloc_host(int extr
init_waitqueue_head(&host->wq);
INIT_DELAYED_WORK(&host->detect, mmc_rescan);
INIT_DELAYED_WORK_DEFERRABLE(&host->disable, mmc_host_deeper_disable);
+#ifdef CONFIG_PM
host->pm_notify.notifier_call = mmc_pm_notify;
+#endif
/*
* By default, hosts do not support SGIO or large requests.
^ permalink raw reply [flat|nested] 20+ messages in thread
* mmotm 2010-08-11 - lockdep whinges at e1000e driver ifconfig up
2010-08-11 23:10 mmotm 2010-08-11-16-10 uploaded akpm
2010-08-12 16:18 ` mmotm 2010-08-11 - RCU whinge during very early boot Valdis.Kletnieks
2010-08-12 16:36 ` [PATCH] mmc: fix for CONFIG_PM disabled Randy Dunlap
@ 2010-08-12 16:37 ` Valdis.Kletnieks
2010-08-12 18:59 ` Valdis.Kletnieks
3 siblings, 0 replies; 20+ messages in thread
From: Valdis.Kletnieks @ 2010-08-12 16:37 UTC (permalink / raw)
To: Andrew Morton, davem, jeffrey.t.kirsher, jesse.brandeburg, kaber,
jengelh, eric.dumazet
Cc: linux-kernel, netdev, e1000-devel, netfilter
[-- Attachment #1: Type: text/plain, Size: 6017 bytes --]
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Not sure if it's an e1000e bug, or an iptables bug that happened to trip on
like the first few packets accepted after the interface came up, so I'll cc:
everybody and let ya'll fight over it. :)
[ 431.011194] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
[ 431.062183] e1000e 0000:00:19.0: irq 46 for MSI/MSI-X
[ 431.064607] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 432.691161] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[ 432.691177] e1000e 0000:00:19.0: eth0: 10/100 speed: disabling TSO
[ 432.695461] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 432.697278]
[ 432.697279] =================================
[ 432.697477] [ INFO: inconsistent lock state ]
[ 432.697581] 2.6.35-mmotm0811 #1
[ 432.697682] ---------------------------------
[ 432.697785] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 432.697890] kworker/0:0/0 [HC0[0]:SC1[2]:HE1:SE0] takes:
[ 432.697994] (&(&lock->lock)->rlock){+.?...}, at: [<ffffffff814d39c8>] ip6t_do_table+0xc1/0x646
[ 432.698028] {SOFTIRQ-ON-W} state was registered at:
[ 432.698028] [<ffffffff8106762f>] __lock_acquire+0x3a3/0xd6a
[ 432.698028] [<ffffffff81068514>] lock_acquire+0x10a/0x130
[ 432.698028] [<ffffffff81557cd9>] _raw_spin_lock+0x36/0x45
[ 432.698028] [<ffffffff814d3375>] xt_info_wrlock+0x1c/0x1e
[ 432.698028] [<ffffffff814d48df>] get_counters+0x93/0x14a
[ 432.698028] [<ffffffff814d49c3>] alloc_counters.clone.3+0x2d/0x41
[ 432.698028] [<ffffffff814d4f98>] do_ip6t_get_ctl+0x110/0x367
[ 432.698028] [<ffffffff814402a7>] nf_sockopt+0x5c/0x88
[ 432.698028] [<ffffffff814402e6>] nf_getsockopt+0x13/0x15
[ 432.698028] [<ffffffff814ba05e>] ipv6_getsockopt+0x94/0xc3
[ 432.698028] [<ffffffff814c1175>] rawv6_getsockopt+0x48/0x54
[ 432.698028] [<ffffffff8141533a>] sock_common_getsockopt+0xf/0x11
[ 432.698028] [<ffffffff814147dd>] sys_getsockopt+0x75/0x93
[ 432.698028] [<ffffffff8100272b>] system_call_fastpath+0x16/0x1b
[ 432.698028] irq event stamp: 3554312
[ 432.698028] hardirqs last enabled at (3554312): [<ffffffff8103fcb9>] _local_bh_enable_ip+0x139/0x178
[ 432.698028] hardirqs last disabled at (3554311): [<ffffffff8103fc3a>] _local_bh_enable_ip+0xba/0x178
[ 432.698028] softirqs last enabled at (3554260): [<ffffffff81040282>] __do_softirq+0x273/0x289
[ 432.698028] softirqs last disabled at (3554277): [<ffffffff8100364c>] call_softirq+0x1c/0x28
[ 432.698028]
[ 432.698028] other info that might help us debug this:
[ 432.698028] 3 locks held by kworker/0:0/0:
[ 432.698028] #0: (&idev->mc_ifc_timer){+.-...}, at: [<ffffffff810468f9>] run_timer_softirq+0x1d2/0x442
[ 432.698028] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff814c3c2a>] rcu_read_lock+0x0/0x35
[ 432.698028] #2: (rcu_read_lock){.+.+..}, at: [<ffffffff8143e840>] rcu_read_lock+0x0/0x35
[ 432.698028]
[ 432.698028] stack backtrace:
[ 432.698028] Pid: 0, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
[ 432.698028] Call Trace:
[ 432.698028] <IRQ> [<ffffffff810670a2>] valid_state+0x17c/0x18e
[ 432.698028] [<ffffffff81066967>] ? check_usage_forwards+0x0/0x87
[ 432.698028] [<ffffffff81067193>] mark_lock+0xdf/0x1d8
[ 432.698028] [<ffffffff810675b1>] __lock_acquire+0x325/0xd6a
[ 432.698028] [<ffffffff8106768f>] ? __lock_acquire+0x403/0xd6a
[ 432.698028] [<ffffffff810687fc>] ? mark_held_locks+0x50/0x72
[ 432.698028] [<ffffffff814d39c8>] ? ip6t_do_table+0xc1/0x646
[ 432.698028] [<ffffffff81068514>] lock_acquire+0x10a/0x130
[ 432.698028] [<ffffffff814d39c8>] ? ip6t_do_table+0xc1/0x646
[ 432.698028] [<ffffffff8103fce6>] ? _local_bh_enable_ip+0x166/0x178
[ 432.698028] [<ffffffff81557cd9>] _raw_spin_lock+0x36/0x45
[ 432.698028] [<ffffffff814d39c8>] ? ip6t_do_table+0xc1/0x646
[ 432.698028] [<ffffffff814d39c8>] ip6t_do_table+0xc1/0x646
[ 432.698028] [<ffffffff8103fce6>] ? _local_bh_enable_ip+0x166/0x178
[ 432.698028] [<ffffffff8103fd10>] ? local_bh_enable+0xd/0xf
[ 432.698028] [<ffffffff8144234b>] ? nf_conntrack_in+0x4a9/0x5b9
[ 432.698028] [<ffffffff814d5ee7>] ip6table_filter_hook+0x17/0x1c
[ 432.698028] [<ffffffff8143ec43>] nf_iterate+0x41/0x84
[ 432.698028] [<ffffffff814c3ec5>] ? dst_output+0x0/0x70
[ 432.698028] [<ffffffff8143ecf9>] nf_hook_slow+0x73/0xde
[ 432.698028] [<ffffffff814c3ec5>] ? dst_output+0x0/0x70
[ 432.698028] [<ffffffff8104710a>] ? msleep_interruptible+0x5b/0x72
[ 432.698028] [<ffffffff814c508e>] NF_HOOK.clone.21+0x3e/0x52
[ 432.698028] [<ffffffff81499c6c>] ? xfrm_lookup+0x11/0x2e
[ 432.698028] [<ffffffff814c531f>] mld_sendpack+0x27d/0x3dd
[ 432.698028] [<ffffffff814c5ad6>] mld_ifc_timer_expire+0x1ca/0x207
[ 432.698028] [<ffffffff810469eb>] run_timer_softirq+0x2c4/0x442
[ 432.698028] [<ffffffff810468f9>] ? run_timer_softirq+0x1d2/0x442
[ 432.698028] [<ffffffff81059222>] ? __run_hrtimer+0x1ec/0x234
[ 432.698028] [<ffffffff814c590c>] ? mld_ifc_timer_expire+0x0/0x207
[ 432.698028] [<ffffffff81040080>] ? __do_softirq+0x71/0x289
[ 432.698028] [<ffffffff81040155>] __do_softirq+0x146/0x289
[ 432.698028] [<ffffffff810a29bc>] ? time_hardirqs_off+0x1b/0x2f
[ 432.698028] [<ffffffff8100364c>] call_softirq+0x1c/0x28
[ 432.698028] [<ffffffff81004bc3>] do_softirq+0x44/0xf1
[ 432.698028] [<ffffffff8104035a>] irq_exit+0x4a/0xb4
[ 432.698028] [<ffffffff8101a3dd>] smp_apic_timer_interrupt+0x79/0x87
[ 432.698028] [<ffffffff81003113>] apic_timer_interrupt+0x13/0x20
[ 432.698028] <EOI> [<ffffffff81277630>] ? acpi_idle_enter_simple+0x122/0x15a
[ 432.698028] [<ffffffff8127762b>] ? acpi_idle_enter_simple+0x11d/0x15a
[ 432.698028] [<ffffffff813b9c3c>] cpuidle_idle_call+0x9b/0x15d
[ 432.698028] [<ffffffff81000c73>] cpu_idle+0x85/0x169
[ 432.698028] [<ffffffff81b5e906>] start_secondary+0x1b1/0x1b5
[ 497.031095] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* mmotm 2010-08-11 - audio volume issues
2010-08-11 23:10 mmotm 2010-08-11-16-10 uploaded akpm
@ 2010-08-12 18:59 ` Valdis.Kletnieks
2010-08-12 16:36 ` [PATCH] mmc: fix for CONFIG_PM disabled Randy Dunlap
` (2 subsequent siblings)
3 siblings, 0 replies; 20+ messages in thread
From: Valdis.Kletnieks @ 2010-08-12 18:59 UTC (permalink / raw)
To: Andrew Morton, Takashi Iwai, Wu Fengguang; +Cc: linux-kernel, alsa-devel
[-- Attachment #1.1: Type: text/plain, Size: 719 bytes --]
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Something appears to be borked in the ALSA arena. There's no actual volume coming
out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
to 10% or so, no further. However, experimentation shows that the volume slider
in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
attaching one copy.
It may be the weekend before I find time to do a bisection of this.
[-- Attachment #1.2: alsa.0811 --]
[-- Type: text/plain , Size: 10766 bytes --]
upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.59
!!################################
!!Script ran on: Thu Aug 12 18:51:22 UTC 2010
!!Linux Distribution
!!------------------
Fedora release 15 (Finian) Fedora release 15 (Finian) Fedora release 15 (Finian) Fedora release 15 (Finian)
!!DMI Information
!!---------------
Manufacturer: Dell Inc.
Product Name: Latitude E6500
!!Kernel Information
!!------------------
Kernel release: 2.6.35-mmotm0811
Operating System: GNU/Linux
Architecture: x86_64
Processor: x86_64
SMP Enabled: Yes
!!ALSA Version
!!------------
Driver version: 1.0.23
Library version: 1.0.23
Utilities version: 1.0.23
!!Loaded ALSA modules
!!-------------------
!!Sound Servers on this system
!!----------------------------
Pulseaudio:
Installed - Yes (/usr/bin/pulseaudio)
Running - Yes
Jack:
Installed - Yes (/usr/bin/jackd)
Running - No
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xf6fdc000 irq 48
!!PCI Soundcards installed in the system
!!--------------------------------------
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
!!Advanced information - PCI Vendor/Device/Susbsystem ID's
!!--------------------------------------------------------
00:1b.0 0403: 8086:293e (rev 03)
Subsystem: 1028:024f
!!Loaded sound module options
!!--------------------------
!!HDA-Intel Codec information
!!---------------------------
--startcollapse--
Codec: IDT 92HD71B7X
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x111d76b2
Subsystem Id: 0x1028024f
Revision Id: 0x100302
No Modem Function Group found
Default PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=8, o=0, i=0, unsolicited=1, wake=1
IO[0]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[7]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Power-Map: 0x00
Analog Loopback: 0x00
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0000001c: OUT HP Detect
Pin Default 0x0421101f: [Jack] HP Out at Ext Right
Conn = 1/8, Color = Black
DefAssociation = 0x1, Sequence = 0xf
Pin-ctls: 0xc0: OUT HP
Unsolicited: tag=01, enabled=1
Connection: 3
0x10 0x11* 0x17
Node 0x0b [Pin Complex] wcaps 0x400081: Stereo
Control: name="Mic Jack Mode", index=0, device=0
ControlAmp: chs=0, dir=In, idx=0, ofs=0
Pincap 0x00001724: IN Detect
Vref caps: HIZ 50 GRD 80
Pin Default 0x04a11221: [Jack] Mic at Ext Right
Conn = 1/8, Color = Black
DefAssociation = 0x2, Sequence = 0x1
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=03, enabled=1
Node 0x0c [Pin Complex] wcaps 0x400081: Stereo
Pincap 0x00001724: IN Detect
Vref caps: HIZ 50 GRD 80
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00: VREF_HIZ
Unsolicited: tag=00, enabled=0
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x00000014: OUT Detect
Pin Default 0x90170110: [Fixed] Speaker at Int N/A
Conn = Analog, Color = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Unsolicited: tag=00, enabled=0
Connection: 3
0x10* 0x11 0x17
Node 0x0e [Pin Complex] wcaps 0x400081: Stereo
Control: name="Front Mic Jack Mode", index=0, device=0
ControlAmp: chs=0, dir=In, idx=0, ofs=0
Pincap 0x00001724: IN Detect
Vref caps: HIZ 50 GRD 80
Pin Default 0x23a1902e: [Jack] Mic at Sep Left
Conn = 1/8, Color = Pink
DefAssociation = 0x2, Sequence = 0xe
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=04, enabled=1
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x00000014: OUT Detect
Pin Default 0x23014250: [Jack] Line Out at Sep Left
Conn = 1/8, Color = Green
DefAssociation = 0x5, Sequence = 0x0
Pin-ctls: 0x00:
Unsolicited: tag=02, enabled=1
Connection: 3
0x10* 0x11 0x17
Node 0x10 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Control: name="Front Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=63
Control: name="Front Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Device: name="STAC92xx Analog", type="Audio", device=0
Amp-Out caps: N/A
Amp-Out vals: [0x63 0x63]
Converter: stream=0, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x11 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Control: name="Headphone Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=63
Control: name="Headphone Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: N/A
Amp-Out vals: [0x63 0x63]
Converter: stream=0, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x12 [Audio Input] wcaps 0x1d0541: Stereo
Device: name="STAC92xx Analog", type="Audio", device=0
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D3, actual=D3
Delay: 13 samples
Connection: 1
0x1c
Processing caps: benign=0, ncoeff=0
Node 0x13 [Audio Input] wcaps 0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D3, actual=D3
Delay: 13 samples
Connection: 1
0x1d
Processing caps: benign=0, ncoeff=0
Node 0x14 [Pin Complex] wcaps 0x400100: Mono
Pincap 0x00000010: OUT
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Connection: 1
0x16
Node 0x15 [Audio Selector] wcaps 0x300101: Stereo
Connection: 3
0x10* 0x11 0x17
Node 0x16 [Audio Mixer] wcaps 0x200100: Mono
Connection: 1
0x15
Node 0x17 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals: [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97]
Connection: 5
0x10 0x11 0x27 0x1a 0x1b
Node 0x18 [Pin Complex] wcaps 0x40000d: Stereo Amp-Out
Control: name="Digital Mic Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00000020: IN
Pin Default 0x90a000f0: [Fixed] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x20: IN
Node 0x19 [Pin Complex] wcaps 0x40000d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00000020: IN
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Control: name="Mux Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 3
0x0b* 0x0c 0x0e
Node 0x1b [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Control: name="Mux Capture Volume", index=1, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 3
0x0b* 0x0c 0x0e
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Control: name="Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Control: name="Capture Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1
Amp-Out vals: [0x08 0x08]
Connection: 4
0x1a* 0x17 0x18 0x19
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Control: name="Capture Volume", index=1, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Control: name="Capture Switch", index=1, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 4
0x1b* 0x17 0x18 0x19
Node 0x1e [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x4f0000f0: [N/A] Line Out at Ext UNKNOWN
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Connection: 1
0x24
Node 0x1f [Pin Complex] wcaps 0x400701: Stereo Digital
Pincap 0x00010010: OUT EAPD
EAPD 0x0:
Pin Default 0x4f0000f0: [N/A] Line Out at Ext UNKNOWN
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Power: setting=D0, actual=D0
Connection: 2
0x24* 0x25
Node 0x20 [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x40f000f7: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x7
Pin-ctls: 0x00:
Connection: 1
0x25
Node 0x21 [Audio Output] wcaps 0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Delay: 4 samples
Node 0x22 [Audio Output] wcaps 0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Delay: 4 samples
Node 0x23 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x24 [Audio Selector] wcaps 0x300101: Stereo
Connection: 3
0x21* 0x1c 0x1d
Node 0x25 [Audio Selector] wcaps 0x300101: Stereo
Connection: 3
0x22* 0x1c 0x1d
Node 0x26 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=1
Amp-Out vals: [0x00]
Node 0x27 [Pin Complex] wcaps 0x400000: Mono
Pincap 0x00000020: IN
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Node 0x28 [Volume Knob Widget] wcaps 0x600000: Mono
Volume-Knob: delta=1, steps=127, direct=1, val=127
Connection: 2
0x10 0x11
--endcollapse--
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* mmotm 2010-08-11 - audio volume issues
@ 2010-08-12 18:59 ` Valdis.Kletnieks
0 siblings, 0 replies; 20+ messages in thread
From: Valdis.Kletnieks @ 2010-08-12 18:59 UTC (permalink / raw)
To: Andrew Morton, Takashi Iwai, Wu Fengguang; +Cc: alsa-devel, linux-kernel
[-- Attachment #1.1.1: Type: text/plain, Size: 719 bytes --]
On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
Something appears to be borked in the ALSA arena. There's no actual volume coming
out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
to 10% or so, no further. However, experimentation shows that the volume slider
in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
what 'Amp-Out vals' lists.
A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
attaching one copy.
It may be the weekend before I find time to do a bisection of this.
[-- Attachment #1.1.2: alsa.0811 --]
[-- Type: text/plain , Size: 10766 bytes --]
upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.59
!!################################
!!Script ran on: Thu Aug 12 18:51:22 UTC 2010
!!Linux Distribution
!!------------------
Fedora release 15 (Finian) Fedora release 15 (Finian) Fedora release 15 (Finian) Fedora release 15 (Finian)
!!DMI Information
!!---------------
Manufacturer: Dell Inc.
Product Name: Latitude E6500
!!Kernel Information
!!------------------
Kernel release: 2.6.35-mmotm0811
Operating System: GNU/Linux
Architecture: x86_64
Processor: x86_64
SMP Enabled: Yes
!!ALSA Version
!!------------
Driver version: 1.0.23
Library version: 1.0.23
Utilities version: 1.0.23
!!Loaded ALSA modules
!!-------------------
!!Sound Servers on this system
!!----------------------------
Pulseaudio:
Installed - Yes (/usr/bin/pulseaudio)
Running - Yes
Jack:
Installed - Yes (/usr/bin/jackd)
Running - No
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xf6fdc000 irq 48
!!PCI Soundcards installed in the system
!!--------------------------------------
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
!!Advanced information - PCI Vendor/Device/Susbsystem ID's
!!--------------------------------------------------------
00:1b.0 0403: 8086:293e (rev 03)
Subsystem: 1028:024f
!!Loaded sound module options
!!--------------------------
!!HDA-Intel Codec information
!!---------------------------
--startcollapse--
Codec: IDT 92HD71B7X
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x111d76b2
Subsystem Id: 0x1028024f
Revision Id: 0x100302
No Modem Function Group found
Default PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=8, o=0, i=0, unsolicited=1, wake=1
IO[0]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[4]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[5]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[6]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
IO[7]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0
Power-Map: 0x00
Analog Loopback: 0x00
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0000001c: OUT HP Detect
Pin Default 0x0421101f: [Jack] HP Out at Ext Right
Conn = 1/8, Color = Black
DefAssociation = 0x1, Sequence = 0xf
Pin-ctls: 0xc0: OUT HP
Unsolicited: tag=01, enabled=1
Connection: 3
0x10 0x11* 0x17
Node 0x0b [Pin Complex] wcaps 0x400081: Stereo
Control: name="Mic Jack Mode", index=0, device=0
ControlAmp: chs=0, dir=In, idx=0, ofs=0
Pincap 0x00001724: IN Detect
Vref caps: HIZ 50 GRD 80
Pin Default 0x04a11221: [Jack] Mic at Ext Right
Conn = 1/8, Color = Black
DefAssociation = 0x2, Sequence = 0x1
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=03, enabled=1
Node 0x0c [Pin Complex] wcaps 0x400081: Stereo
Pincap 0x00001724: IN Detect
Vref caps: HIZ 50 GRD 80
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00: VREF_HIZ
Unsolicited: tag=00, enabled=0
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x00000014: OUT Detect
Pin Default 0x90170110: [Fixed] Speaker at Int N/A
Conn = Analog, Color = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Unsolicited: tag=00, enabled=0
Connection: 3
0x10* 0x11 0x17
Node 0x0e [Pin Complex] wcaps 0x400081: Stereo
Control: name="Front Mic Jack Mode", index=0, device=0
ControlAmp: chs=0, dir=In, idx=0, ofs=0
Pincap 0x00001724: IN Detect
Vref caps: HIZ 50 GRD 80
Pin Default 0x23a1902e: [Jack] Mic at Sep Left
Conn = 1/8, Color = Pink
DefAssociation = 0x2, Sequence = 0xe
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=04, enabled=1
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x00000014: OUT Detect
Pin Default 0x23014250: [Jack] Line Out at Sep Left
Conn = 1/8, Color = Green
DefAssociation = 0x5, Sequence = 0x0
Pin-ctls: 0x00:
Unsolicited: tag=02, enabled=1
Connection: 3
0x10* 0x11 0x17
Node 0x10 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Control: name="Front Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=63
Control: name="Front Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Device: name="STAC92xx Analog", type="Audio", device=0
Amp-Out caps: N/A
Amp-Out vals: [0x63 0x63]
Converter: stream=0, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x11 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Control: name="Headphone Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=63
Control: name="Headphone Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: N/A
Amp-Out vals: [0x63 0x63]
Converter: stream=0, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x12 [Audio Input] wcaps 0x1d0541: Stereo
Device: name="STAC92xx Analog", type="Audio", device=0
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D3, actual=D3
Delay: 13 samples
Connection: 1
0x1c
Processing caps: benign=0, ncoeff=0
Node 0x13 [Audio Input] wcaps 0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D3, actual=D3
Delay: 13 samples
Connection: 1
0x1d
Processing caps: benign=0, ncoeff=0
Node 0x14 [Pin Complex] wcaps 0x400100: Mono
Pincap 0x00000010: OUT
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Connection: 1
0x16
Node 0x15 [Audio Selector] wcaps 0x300101: Stereo
Connection: 3
0x10* 0x11 0x17
Node 0x16 [Audio Mixer] wcaps 0x200100: Mono
Connection: 1
0x15
Node 0x17 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1
Amp-In vals: [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97] [0x97 0x97]
Connection: 5
0x10 0x11 0x27 0x1a 0x1b
Node 0x18 [Pin Complex] wcaps 0x40000d: Stereo Amp-Out
Control: name="Digital Mic Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00000020: IN
Pin Default 0x90a000f0: [Fixed] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x20: IN
Node 0x19 [Pin Complex] wcaps 0x40000d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Pincap 0x00000020: IN
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Control: name="Mux Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 3
0x0b* 0x0c 0x0e
Node 0x1b [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Control: name="Mux Capture Volume", index=1, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-Out vals: [0x00 0x00]
Connection: 3
0x0b* 0x0c 0x0e
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Control: name="Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Control: name="Capture Switch", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1
Amp-Out vals: [0x08 0x08]
Connection: 4
0x1a* 0x17 0x18 0x19
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Control: name="Capture Volume", index=1, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Control: name="Capture Switch", index=1, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1
Amp-Out vals: [0x80 0x80]
Connection: 4
0x1b* 0x17 0x18 0x19
Node 0x1e [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x4f0000f0: [N/A] Line Out at Ext UNKNOWN
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Connection: 1
0x24
Node 0x1f [Pin Complex] wcaps 0x400701: Stereo Digital
Pincap 0x00010010: OUT EAPD
EAPD 0x0:
Pin Default 0x4f0000f0: [N/A] Line Out at Ext UNKNOWN
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Power: setting=D0, actual=D0
Connection: 2
0x24* 0x25
Node 0x20 [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x40f000f7: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x7
Pin-ctls: 0x00:
Connection: 1
0x25
Node 0x21 [Audio Output] wcaps 0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Delay: 4 samples
Node 0x22 [Audio Output] wcaps 0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Delay: 4 samples
Node 0x23 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x24 [Audio Selector] wcaps 0x300101: Stereo
Connection: 3
0x21* 0x1c 0x1d
Node 0x25 [Audio Selector] wcaps 0x300101: Stereo
Connection: 3
0x22* 0x1c 0x1d
Node 0x26 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=1
Amp-Out vals: [0x00]
Node 0x27 [Pin Complex] wcaps 0x400000: Mono
Pincap 0x00000020: IN
Pin Default 0x40f000f0: [N/A] Other at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Node 0x28 [Volume Knob Widget] wcaps 0x600000: Mono
Volume-Knob: delta=1, steps=127, direct=1, val=127
Connection: 2
0x10 0x11
--endcollapse--
[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
2010-08-12 18:59 ` Valdis.Kletnieks
(?)
@ 2010-08-12 19:37 ` Takashi Iwai
-1 siblings, 0 replies; 20+ messages in thread
From: Takashi Iwai @ 2010-08-12 19:37 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, Wu Fengguang, linux-kernel, alsa-devel
At Thu, 12 Aug 2010 14:59:32 -0400,
Valdis.Kletnieks@vt.edu wrote:
>
> On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Something appears to be borked in the ALSA arena. There's no actual volume coming
> out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> to 10% or so, no further. However, experimentation shows that the volume slider
> in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> what 'Amp-Out vals' lists.
>
> A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> attaching one copy.
Hm, there shouldn't be a change regarding the volume control.
There can be an issue about PCM stream, e.g. in commit
eb541337b7a43822fce7d0c9d967ee149b2d9a96
ALSA: hda - Make converter setups sticky
To be sure, could you try to revert it? If it doesn't help but still
you get strange volume behavior, please get alsa-info.sh output at
different volume levels for comparison.
thanks,
Takashi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
2010-08-12 18:59 ` Valdis.Kletnieks
@ 2010-08-12 21:06 ` Jiri Slaby
-1 siblings, 0 replies; 20+ messages in thread
From: Jiri Slaby @ 2010-08-12 21:06 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, Takashi Iwai, Wu Fengguang, linux-kernel, alsa-devel
On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
>> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>>
>> http://userweb.kernel.org/~akpm/mmotm/
>
> Something appears to be borked in the ALSA arena. There's no actual volume coming
> out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> to 10% or so, no further. However, experimentation shows that the volume slider
> in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> what 'Amp-Out vals' lists.
>
> A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> attaching one copy.
>
> It may be the weekend before I find time to do a bisection of this.
Didn't you (like some other people) get into the state where pulseaudio
doesn't work? It chooses as an output a dummy driver automatically, then
you can change volume, play sound, but actually it all goes to /dev/null.
It took me a while before I figured out that it's a "dummy" driver I
have in pulseaudio.
regards,
--
js
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
@ 2010-08-12 21:06 ` Jiri Slaby
0 siblings, 0 replies; 20+ messages in thread
From: Jiri Slaby @ 2010-08-12 21:06 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Takashi Iwai, Andrew Morton, Wu Fengguang, linux-kernel, alsa-devel
On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
>> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>>
>> http://userweb.kernel.org/~akpm/mmotm/
>
> Something appears to be borked in the ALSA arena. There's no actual volume coming
> out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> to 10% or so, no further. However, experimentation shows that the volume slider
> in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> what 'Amp-Out vals' lists.
>
> A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> attaching one copy.
>
> It may be the weekend before I find time to do a bisection of this.
Didn't you (like some other people) get into the state where pulseaudio
doesn't work? It chooses as an output a dummy driver automatically, then
you can change volume, play sound, but actually it all goes to /dev/null.
It took me a while before I figured out that it's a "dummy" driver I
have in pulseaudio.
regards,
--
js
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
2010-08-12 21:06 ` Jiri Slaby
@ 2010-08-12 21:11 ` Takashi Iwai
-1 siblings, 0 replies; 20+ messages in thread
From: Takashi Iwai @ 2010-08-12 21:11 UTC (permalink / raw)
To: Jiri Slaby
Cc: Valdis.Kletnieks, Andrew Morton, Wu Fengguang, linux-kernel, alsa-devel
At Thu, 12 Aug 2010 23:06:22 +0200,
Jiri Slaby wrote:
>
> On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> >>
> >> http://userweb.kernel.org/~akpm/mmotm/
> >
> > Something appears to be borked in the ALSA arena. There's no actual volume coming
> > out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> > to 10% or so, no further. However, experimentation shows that the volume slider
> > in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> > what 'Amp-Out vals' lists.
> >
> > A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> > attaching one copy.
> >
> > It may be the weekend before I find time to do a bisection of this.
>
> Didn't you (like some other people) get into the state where pulseaudio
> doesn't work? It chooses as an output a dummy driver automatically, then
> you can change volume, play sound, but actually it all goes to /dev/null.
>
> It took me a while before I figured out that it's a "dummy" driver I
> have in pulseaudio.
Looks like there is a breakage regarding open/close due to fs/notify/*
changes. I guess you can hear still sounds like:
% aplay -Dplughw foo.wav
Takashi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
@ 2010-08-12 21:11 ` Takashi Iwai
0 siblings, 0 replies; 20+ messages in thread
From: Takashi Iwai @ 2010-08-12 21:11 UTC (permalink / raw)
To: Jiri Slaby
Cc: Andrew Morton, Wu Fengguang, Valdis.Kletnieks, linux-kernel, alsa-devel
At Thu, 12 Aug 2010 23:06:22 +0200,
Jiri Slaby wrote:
>
> On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
> > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> >>
> >> http://userweb.kernel.org/~akpm/mmotm/
> >
> > Something appears to be borked in the ALSA arena. There's no actual volume coming
> > out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> > to 10% or so, no further. However, experimentation shows that the volume slider
> > in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> > what 'Amp-Out vals' lists.
> >
> > A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> > attaching one copy.
> >
> > It may be the weekend before I find time to do a bisection of this.
>
> Didn't you (like some other people) get into the state where pulseaudio
> doesn't work? It chooses as an output a dummy driver automatically, then
> you can change volume, play sound, but actually it all goes to /dev/null.
>
> It took me a while before I figured out that it's a "dummy" driver I
> have in pulseaudio.
Looks like there is a breakage regarding open/close due to fs/notify/*
changes. I guess you can hear still sounds like:
% aplay -Dplughw foo.wav
Takashi
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
2010-08-12 21:11 ` Takashi Iwai
@ 2010-08-13 2:13 ` Valdis.Kletnieks
-1 siblings, 0 replies; 20+ messages in thread
From: Valdis.Kletnieks @ 2010-08-13 2:13 UTC (permalink / raw)
To: Takashi Iwai, Linus Torvalds
Cc: Jiri Slaby, Andrew Morton, Wu Fengguang, linux-kernel, alsa-devel
[-- Attachment #1: Type: text/plain, Size: 1973 bytes --]
On Thu, 12 Aug 2010 23:11:42 +0200, Takashi Iwai said:
> At Thu, 12 Aug 2010 23:06:22 +0200,
> Jiri Slaby wrote:
> >
> > On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
> > > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> > >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> > >>
> > >> http://userweb.kernel.org/~akpm/mmotm/
> > >
> > > Something appears to be borked in the ALSA arena. There's no actual volume coming
> > > out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> > > to 10% or so, no further. However, experimentation shows that the volume slider
> > > in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> > > what 'Amp-Out vals' lists.
> > >
> > > A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> > > attaching one copy.
> > >
> > > It may be the weekend before I find time to do a bisection of this.
> >
> > Didn't you (like some other people) get into the state where pulseaudio
> > doesn't work? It chooses as an output a dummy driver automatically, then
> > you can change volume, play sound, but actually it all goes to /dev/null.
> >
> > It took me a while before I figured out that it's a "dummy" driver I
> > have in pulseaudio.
>
> Looks like there is a breakage regarding open/close due to fs/notify/*
> changes. I guess you can hear still sounds like:
>
> % aplay -Dplughw foo.wav
Confirming that Linus's patch fixes it for me:
commit 2069601b3f0ea38170d4b509b89f3ca0a373bdc1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Aug 12 14:23:04 2010 -0700
Revert "fsnotify: store struct file not struct path"
This reverts commit 3bcf3860a4ff9bbc522820b4b765e65e4deceb3e (and the
accompanying commit c1e5c954020e "vfs/fsnotify: fsnotify_close can delay
the final work in fput" that was a horribly ugly hack to make it work at
all).
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - audio volume issues
@ 2010-08-13 2:13 ` Valdis.Kletnieks
0 siblings, 0 replies; 20+ messages in thread
From: Valdis.Kletnieks @ 2010-08-13 2:13 UTC (permalink / raw)
To: Takashi Iwai, Linus Torvalds
Cc: Andrew Morton, Wu Fengguang, Jiri Slaby, alsa-devel, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1973 bytes --]
On Thu, 12 Aug 2010 23:11:42 +0200, Takashi Iwai said:
> At Thu, 12 Aug 2010 23:06:22 +0200,
> Jiri Slaby wrote:
> >
> > On 08/12/2010 08:59 PM, Valdis.Kletnieks@vt.edu wrote:
> > > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> > >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> > >>
> > >> http://userweb.kernel.org/~akpm/mmotm/
> > >
> > > Something appears to be borked in the ALSA arena. There's no actual volume coming
> > > out of the system, and 'alsamixer' is insisting that the volume slider only goes from 0
> > > to 10% or so, no further. However, experimentation shows that the volume slider
> > > in 'xine' *does* affect the 'Amp-Out vals' lines, and alsamixer has *no* effect on
> > > what 'Amp-Out vals' lists.
> > >
> > > A diff of alsa-info.sh for the two kernels shows them being identical, so I'm only
> > > attaching one copy.
> > >
> > > It may be the weekend before I find time to do a bisection of this.
> >
> > Didn't you (like some other people) get into the state where pulseaudio
> > doesn't work? It chooses as an output a dummy driver automatically, then
> > you can change volume, play sound, but actually it all goes to /dev/null.
> >
> > It took me a while before I figured out that it's a "dummy" driver I
> > have in pulseaudio.
>
> Looks like there is a breakage regarding open/close due to fs/notify/*
> changes. I guess you can hear still sounds like:
>
> % aplay -Dplughw foo.wav
Confirming that Linus's patch fixes it for me:
commit 2069601b3f0ea38170d4b509b89f3ca0a373bdc1
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Aug 12 14:23:04 2010 -0700
Revert "fsnotify: store struct file not struct path"
This reverts commit 3bcf3860a4ff9bbc522820b4b765e65e4deceb3e (and the
accompanying commit c1e5c954020e "vfs/fsnotify: fsnotify_close can delay
the final work in fput" that was a horribly ugly hack to make it work at
all).
[-- Attachment #1.2: Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - RCU whinge during very early boot
2010-08-12 16:18 ` mmotm 2010-08-11 - RCU whinge during very early boot Valdis.Kletnieks
@ 2010-08-16 17:23 ` Paul E. McKenney
2010-10-05 10:05 ` Zdenek Kabelac
1 sibling, 0 replies; 20+ messages in thread
From: Paul E. McKenney @ 2010-08-16 17:23 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, Ingo Molnar, Peter Zijlstra, Thomas Gleixner,
linux-kernel
On Thu, Aug 12, 2010 at 12:18:07PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> > The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
Hello, Valdis!
Thank you for finding this!
> [ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
> [ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
> [ 0.030019] lockdep: fixing up alternatives.
> [ 0.031178]
> [ 0.031179] ===================================================
> [ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 0.031184] ---------------------------------------------------
> [ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
> [ 0.031189]
> [ 0.031189] other info that might help us debug this:
> [ 0.031190]
> [ 0.031192]
> [ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
> [ 0.031195] 3 locks held by kworker/0:0/4:
> [ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> [ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> [ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
Interesting! My first thought was that this is a false positive, given
that lockdep_is_held(&task_rq(p)->lock) is one of the arguments to
task_subsys_state_check() and thus to rcu_dereference_check(). However...
Given the "lockdep: fixing up alternatives" above, we know that cpu==1,
and that the code is running on CPU 0.
So init_idle() acquires the specified CPU's runqueue lock:
struct rq *rq = cpu_rq(cpu);
...
raw_spin_lock_irqsave(&rq->lock, flags);
Then init_idle() goes on to initialize a number of fields in the
new idle task's task structure, then calls __set_task_cpu() to set
up the new idle task on the specified CPU.
Now, __set_task_cpu() invokes set_task_rq(), which invokes task_group(),
which as mentioned before specifies lockdep_is_held(&task_rq(p)->lock)
as one of the splat-avoiding conditions. But the new idle task does
not yet have its current CPU set to CPU 1 -- that doesn't happen until
the end of __set_task_cpu(). Therefore, task_rq(p) will return 0.
So, if I am reading the code correctly, task_group() will be checking
for CPU 0's runqueue, when we are instead holding CPU 1's runqueue lock.
The patch below fixes this by acquiring both locks, as is done during
task migration. Untested, probably does not even compile.
Thoughts?
> [ 0.031226] stack backtrace:
> [ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
> [ 0.031232] Call Trace:
> [ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
> [ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
> [ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
> [ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
> [ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
> [ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
> [ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
> [ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
> [ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
> [ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
> [ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
> [ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
> [ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
> [ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> [ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
> [ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
> [ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> [ 0.031333] Booting Node 0, Processors #1 Ok.
> [ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
> [ 0.104013] Brought up 2 CPUs
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
sched.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 70fa78d..81a6a0a 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5314,9 +5314,11 @@ void __cpuinit init_idle_bootup_task(struct task_struct *idle)
void __cpuinit init_idle(struct task_struct *idle, int cpu)
{
struct rq *rq = cpu_rq(cpu);
+ struct rq *oldrq = task_rq(idle);
unsigned long flags;
- raw_spin_lock_irqsave(&rq->lock, flags);
+ local_irq_save(flags);
+ double_rq_lock(oldrq, rq);
__sched_fork(idle);
idle->state = TASK_RUNNING;
@@ -5329,7 +5331,8 @@ void __cpuinit init_idle(struct task_struct *idle, int cpu)
#if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
idle->oncpu = 1;
#endif
- raw_spin_unlock_irqrestore(&rq->lock, flags);
+ double_rq_unlock(oldrq, rq);
+ local_irq_restore(flags);
/* Set the preempt count _outside_ the spinlocks! */
#if defined(CONFIG_PREEMPT)
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] mmc: fix for CONFIG_PM disabled
2010-08-12 16:36 ` [PATCH] mmc: fix for CONFIG_PM disabled Randy Dunlap
@ 2010-08-18 9:10 ` Uwe Kleine-König
0 siblings, 0 replies; 20+ messages in thread
From: Uwe Kleine-König @ 2010-08-18 9:10 UTC (permalink / raw)
To: Randy Dunlap; +Cc: linux-kernel, akpm, linux-mmc, Kukjin Kim, Maxim Levitsky
On Thu, Aug 12, 2010 at 09:36:43AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Minimal patch to fix mmc to build when CONFIG_PM is not enabled:
>
> (.text+0x128fcd): undefined reference to `mmc_pm_notify'
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
I sent the same patch[1] a few hours later than Randy, mine got
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Acked-by: Maxim Levitsky <maximlevitsky@gmail.com>
. I think it's fine to add these to Randy's patch, too, together with
my Ack. Maybe add a reference to the breaking commit as my patch did?
Thanks
Uwe
[1] http://mid.gmane.org/1281691473-15481-1-git-send-email-u.kleine-koenig@pengutronix.de
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - RCU whinge during very early boot
2010-08-12 16:18 ` mmotm 2010-08-11 - RCU whinge during very early boot Valdis.Kletnieks
2010-08-16 17:23 ` Paul E. McKenney
@ 2010-10-05 10:05 ` Zdenek Kabelac
2010-10-06 23:04 ` Paul E. McKenney
1 sibling, 1 reply; 20+ messages in thread
From: Zdenek Kabelac @ 2010-10-05 10:05 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Andrew Morton, Ingo Molnar, Peter Zijlstra, Thomas Gleixner,
linux-kernel
2010/8/12 <Valdis.Kletnieks@vt.edu>:
> On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
>> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>>
>> http://userweb.kernel.org/~akpm/mmotm/
>
> Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
>
> [ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
> [ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
> [ 0.030019] lockdep: fixing up alternatives.
> [ 0.031178]
> [ 0.031179] ===================================================
> [ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 0.031184] ---------------------------------------------------
> [ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
> [ 0.031189]
> [ 0.031189] other info that might help us debug this:
> [ 0.031190]
> [ 0.031192]
> [ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
> [ 0.031195] 3 locks held by kworker/0:0/4:
> [ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> [ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> [ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
> [ 0.031225]
> [ 0.031226] stack backtrace:
> [ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
> [ 0.031232] Call Trace:
> [ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
> [ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
> [ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
> [ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
> [ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
> [ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
> [ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
> [ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
> [ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
> [ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
> [ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
> [ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
> [ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
> [ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> [ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
> [ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
> [ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> [ 0.031333] Booting Node 0, Processors #1 Ok.
> [ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
> [ 0.104013] Brought up 2 CPUs
>
I'm still seeing this INFO message on my vanilla 2.6.36-rc kernel.
----------------------
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 16045 entries in 63 pages
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
CPU0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0a
NMI watchdog enabled, takes one hw-pmu counter.
lockdep: fixing up alternatives.
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
kernel/sched.c:618 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
3 locks held by kworker/0:0/4:
#0: (events){+.+.+.}, at: [<ffffffff8106e78e>] process_one_work+0x12e/0x560
#1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff8106e78e>]
process_one_work+0x12e/0x560
#2: (&rq->lock){......}, at: [<ffffffff814772c3>] init_idle+0x30/0x12c
stack backtrace:
Pid: 4, comm: kworker/0:0 Not tainted 2.6.36-rc6-00085-g6e34025 #1
Call Trace:
[<ffffffff81089c1b>] lockdep_rcu_dereference+0xbb/0xc0
[<ffffffff8103e7d5>] set_task_rq+0x2f5/0x300
[<ffffffff81477374>] init_idle+0xe1/0x12c
[<ffffffff81477769>] fork_idle+0x90/0x9f
[<ffffffff81048dfa>] ? enqueue_entity+0x13a/0x430
[<ffffffff81482789>] ? sub_preempt_count+0x59/0x60
[<ffffffff814752f5>] do_fork_idle+0x1c/0x2d
[<ffffffff8106e7fa>] process_one_work+0x19a/0x560
[<ffffffff8106e78e>] ? process_one_work+0x12e/0x560
[<ffffffff814752d9>] ? do_fork_idle+0x0/0x2d
[<ffffffff81070189>] worker_thread+0x169/0x340
[<ffffffff81070020>] ? worker_thread+0x0/0x340
[<ffffffff810752e6>] kthread+0xa6/0xb0
[<ffffffff81004014>] kernel_thread_helper+0x4/0x10
[<ffffffff8147efcb>] ? _raw_spin_unlock_irq+0x3b/0x60
[<ffffffff8147f600>] ? restore_args+0x0/0x30
[<ffffffff81075240>] ? kthread+0x0/0xb0
[<ffffffff81004010>] ? kernel_thread_helper+0x0/0x10
Booting Node 0, Processors #1 Ok.
TSC synchronization [CPU#0 -> CPU#1]:
Measured 399476 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to check_tsc_sync_source failed
NMI watchdog enabled, takes one hw-pmu counter.
Brought up 2 CPUs
Total of 2 processors activated (8781.86 BogoMIPS).
regulator: core version 0.5
regulator: dummy:
Time: 7:44:09 Date: 10/05/10
Zdenek
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - RCU whinge during very early boot
2010-10-05 10:05 ` Zdenek Kabelac
@ 2010-10-06 23:04 ` Paul E. McKenney
2010-10-06 23:18 ` Ben Greear
2010-10-18 12:26 ` Zdenek Kabelac
0 siblings, 2 replies; 20+ messages in thread
From: Paul E. McKenney @ 2010-10-06 23:04 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Valdis.Kletnieks, Andrew Morton, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, linux-kernel
On Tue, Oct 05, 2010 at 12:05:13PM +0200, Zdenek Kabelac wrote:
> 2010/8/12 <Valdis.Kletnieks@vt.edu>:
> > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> >>
> >> http://userweb.kernel.org/~akpm/mmotm/
> >
> > Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
> >
> > [ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
> > [ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
> > [ 0.030019] lockdep: fixing up alternatives.
> > [ 0.031178]
> > [ 0.031179] ===================================================
> > [ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
> > [ 0.031184] ---------------------------------------------------
> > [ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
> > [ 0.031189]
> > [ 0.031189] other info that might help us debug this:
> > [ 0.031190]
> > [ 0.031192]
> > [ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
> > [ 0.031195] 3 locks held by kworker/0:0/4:
> > [ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> > [ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> > [ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
> > [ 0.031225]
> > [ 0.031226] stack backtrace:
> > [ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
> > [ 0.031232] Call Trace:
> > [ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
> > [ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
> > [ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
> > [ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
> > [ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
> > [ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
> > [ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
> > [ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
> > [ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
> > [ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
> > [ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
> > [ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
> > [ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
> > [ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> > [ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
> > [ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
> > [ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> > [ 0.031333] Booting Node 0, Processors #1 Ok.
> > [ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
> > [ 0.104013] Brought up 2 CPUs
> >
>
> I'm still seeing this INFO message on my vanilla 2.6.36-rc kernel.
>
> ----------------------
>
> ftrace: converting mcount calls to 0f 1f 44 00 00
> ftrace: allocating 16045 entries in 63 pages
> Setting APIC routing to flat
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> CPU0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0a
> NMI watchdog enabled, takes one hw-pmu counter.
> lockdep: fixing up alternatives.
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 3 locks held by kworker/0:0/4:
> #0: (events){+.+.+.}, at: [<ffffffff8106e78e>] process_one_work+0x12e/0x560
> #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff8106e78e>]
> process_one_work+0x12e/0x560
> #2: (&rq->lock){......}, at: [<ffffffff814772c3>] init_idle+0x30/0x12c
>
> stack backtrace:
> Pid: 4, comm: kworker/0:0 Not tainted 2.6.36-rc6-00085-g6e34025 #1
> Call Trace:
> [<ffffffff81089c1b>] lockdep_rcu_dereference+0xbb/0xc0
> [<ffffffff8103e7d5>] set_task_rq+0x2f5/0x300
> [<ffffffff81477374>] init_idle+0xe1/0x12c
> [<ffffffff81477769>] fork_idle+0x90/0x9f
> [<ffffffff81048dfa>] ? enqueue_entity+0x13a/0x430
> [<ffffffff81482789>] ? sub_preempt_count+0x59/0x60
> [<ffffffff814752f5>] do_fork_idle+0x1c/0x2d
> [<ffffffff8106e7fa>] process_one_work+0x19a/0x560
> [<ffffffff8106e78e>] ? process_one_work+0x12e/0x560
> [<ffffffff814752d9>] ? do_fork_idle+0x0/0x2d
> [<ffffffff81070189>] worker_thread+0x169/0x340
> [<ffffffff81070020>] ? worker_thread+0x0/0x340
> [<ffffffff810752e6>] kthread+0xa6/0xb0
> [<ffffffff81004014>] kernel_thread_helper+0x4/0x10
> [<ffffffff8147efcb>] ? _raw_spin_unlock_irq+0x3b/0x60
> [<ffffffff8147f600>] ? restore_args+0x0/0x30
> [<ffffffff81075240>] ? kthread+0x0/0xb0
> [<ffffffff81004010>] ? kernel_thread_helper+0x0/0x10
> Booting Node 0, Processors #1 Ok.
> TSC synchronization [CPU#0 -> CPU#1]:
> Measured 399476 cycles TSC warp between CPUs, turning off TSC clock.
> Marking TSC unstable due to check_tsc_sync_source failed
> NMI watchdog enabled, takes one hw-pmu counter.
> Brought up 2 CPUs
> Total of 2 processors activated (8781.86 BogoMIPS).
> regulator: core version 0.5
> regulator: dummy:
> Time: 7:44:09 Date: 10/05/10
Hello, Zdenek,
I believe that the following patch from Peter Z. should address this.
Thanx, Paul
------------------------------------------------------------------------
commit e3dd67d97b3c2aad366b845c797745a78efaf90d
Author: Peter Zijlstra <peterz@infradead.org>
Date: Thu Sep 16 17:50:31 2010 +0200
sched: fix RCU lockdep splat from task_group()
This addresses the following RCU lockdep splat:
[0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
[0.052999] lockdep: fixing up alternatives.
[0.054105]
[0.054106] ===================================================
[0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
[0.054999] ---------------------------------------------------
[0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without protection!
[0.054999]
[0.054999] other info that might help us debug this:
[0.054999]
[0.054999]
[0.054999] rcu_scheduler_active = 1, debug_locks = 1
[0.054999] 3 locks held by swapper/1:
[0.054999] #0: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff814be933>] cpu_up+0x42/0x6a
[0.054999] #1: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff810400d8>] cpu_hotplug_begin+0x2a/0x51
[0.054999] #2: (&rq->lock){-.-...}, at: [<ffffffff814be2f7>] init_idle+0x2f/0x113
[0.054999]
[0.054999] stack backtrace:
[0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
[0.054999] Call Trace:
[0.054999] [<ffffffff81068054>] lockdep_rcu_dereference+0x9b/0xa3
[0.054999] [<ffffffff810325c3>] task_group+0x7b/0x8a
[0.054999] [<ffffffff810325e5>] set_task_rq+0x13/0x40
[0.054999] [<ffffffff814be39a>] init_idle+0xd2/0x113
[0.054999] [<ffffffff814be78a>] fork_idle+0xb8/0xc7
[0.054999] [<ffffffff81068717>] ? mark_held_locks+0x4d/0x6b
[0.054999] [<ffffffff814bcebd>] do_fork_idle+0x17/0x2b
[0.054999] [<ffffffff814bc89b>] native_cpu_up+0x1c1/0x724
[0.054999] [<ffffffff814bcea6>] ? do_fork_idle+0x0/0x2b
[0.054999] [<ffffffff814be876>] _cpu_up+0xac/0x127
[0.054999] [<ffffffff814be946>] cpu_up+0x55/0x6a
[0.054999] [<ffffffff81ab562a>] kernel_init+0xe1/0x1ff
[0.054999] [<ffffffff81003854>] kernel_thread_helper+0x4/0x10
[0.054999] [<ffffffff814c353c>] ? restore_args+0x0/0x30
[0.054999] [<ffffffff81ab5549>] ? kernel_init+0x0/0x1ff
[0.054999] [<ffffffff81003850>] ? kernel_thread_helper+0x0/0x10
[0.056074] Booting Node 0, Processors #1lockdep: fixing up alternatives.
[0.130045] #2lockdep: fixing up alternatives.
[0.203089] #3 Ok.
[0.275286] Brought up 4 CPUs
[0.276005] Total of 4 processors activated (16017.17 BogoMIPS).
The cgroup_subsys_state structures referenced by idle tasks are never
freed, because the idle tasks should be part of the root cgroup,
which is not removable.
The problem is that while we do in-fact hold rq->lock, the newly spawned
idle thread's cpu is not yet set to the correct cpu so the lockdep check
in task_group():
lockdep_is_held(&task_rq(p)->lock)
will fail.
But this is a chicken and egg problem. Setting the CPU's runqueue requires
that the CPU's runqueue already be set. ;-)
So insert an RCU read-side critical section to avoid the complaint.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/kernel/sched.c b/kernel/sched.c
index 09b574e..40e065e 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5331,7 +5331,19 @@ void __cpuinit init_idle(struct task_struct *idle, int cpu)
idle->se.exec_start = sched_clock();
cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
+ /*
+ * We're having a chicken and egg problem, even though we are
+ * holding rq->lock, the cpu isn't yet set to this cpu so the
+ * lockdep check in task_group() will fail.
+ *
+ * Similar case to sched_fork(). / Alternatively we could
+ * use task_rq_lock() here and obtain the other rq->lock.
+ *
+ * Silence PROVE_RCU
+ */
+ rcu_read_lock();
__set_task_cpu(idle, cpu);
+ rcu_read_unlock();
rq->curr = rq->idle = idle;
#if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - RCU whinge during very early boot
2010-10-06 23:04 ` Paul E. McKenney
@ 2010-10-06 23:18 ` Ben Greear
2010-10-18 12:26 ` Zdenek Kabelac
1 sibling, 0 replies; 20+ messages in thread
From: Ben Greear @ 2010-10-06 23:18 UTC (permalink / raw)
To: paulmck
Cc: Zdenek Kabelac, Valdis.Kletnieks, Andrew Morton, Ingo Molnar,
Peter Zijlstra, Thomas Gleixner, linux-kernel
On 10/06/2010 04:04 PM, Paul E. McKenney wrote:
> On Tue, Oct 05, 2010 at 12:05:13PM +0200, Zdenek Kabelac wrote:
>> 2010/8/12<Valdis.Kletnieks@vt.edu>:
>>> On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
>>>> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>>>>
>>>> http://userweb.kernel.org/~akpm/mmotm/
>>>
>>> Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
>>>
>>> [ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
>>> [ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
>>> [ 0.030019] lockdep: fixing up alternatives.
>>> [ 0.031178]
>>> [ 0.031179] ===================================================
>>> [ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
>>> [ 0.031184] ---------------------------------------------------
>>> [ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>>> [ 0.031189]
>>> [ 0.031189] other info that might help us debug this:
>>> [ 0.031190]
>>> [ 0.031192]
>>> [ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
>>> [ 0.031195] 3 locks held by kworker/0:0/4:
>>> [ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
>>> [ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
>>> [ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
>>> [ 0.031225]
>>> [ 0.031226] stack backtrace:
>>> [ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
>>> [ 0.031232] Call Trace:
>>> [ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
>>> [ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
>>> [ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
>>> [ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
>>> [ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
>>> [ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
>>> [ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
>>> [ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
>>> [ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
>>> [ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
>>> [ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
>>> [ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
>>> [ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
>>> [ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
>>> [ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
>>> [ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
>>> [ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
>>> [ 0.031333] Booting Node 0, Processors #1 Ok.
>>> [ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
>>> [ 0.104013] Brought up 2 CPUs
>>>
>>
>> I'm still seeing this INFO message on my vanilla 2.6.36-rc kernel.
>>
>> ----------------------
>>
>> ftrace: converting mcount calls to 0f 1f 44 00 00
>> ftrace: allocating 16045 entries in 63 pages
>> Setting APIC routing to flat
>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>> CPU0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0a
>> NMI watchdog enabled, takes one hw-pmu counter.
>> lockdep: fixing up alternatives.
>>
>> ===================================================
>> [ INFO: suspicious rcu_dereference_check() usage. ]
>> ---------------------------------------------------
>> kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>>
>> other info that might help us debug this:
>>
>>
>> rcu_scheduler_active = 1, debug_locks = 0
>> 3 locks held by kworker/0:0/4:
>> #0: (events){+.+.+.}, at: [<ffffffff8106e78e>] process_one_work+0x12e/0x560
>> #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff8106e78e>]
>> process_one_work+0x12e/0x560
>> #2: (&rq->lock){......}, at: [<ffffffff814772c3>] init_idle+0x30/0x12c
>>
>> stack backtrace:
>> Pid: 4, comm: kworker/0:0 Not tainted 2.6.36-rc6-00085-g6e34025 #1
>> Call Trace:
>> [<ffffffff81089c1b>] lockdep_rcu_dereference+0xbb/0xc0
>> [<ffffffff8103e7d5>] set_task_rq+0x2f5/0x300
>> [<ffffffff81477374>] init_idle+0xe1/0x12c
>> [<ffffffff81477769>] fork_idle+0x90/0x9f
>> [<ffffffff81048dfa>] ? enqueue_entity+0x13a/0x430
>> [<ffffffff81482789>] ? sub_preempt_count+0x59/0x60
>> [<ffffffff814752f5>] do_fork_idle+0x1c/0x2d
>> [<ffffffff8106e7fa>] process_one_work+0x19a/0x560
>> [<ffffffff8106e78e>] ? process_one_work+0x12e/0x560
>> [<ffffffff814752d9>] ? do_fork_idle+0x0/0x2d
>> [<ffffffff81070189>] worker_thread+0x169/0x340
>> [<ffffffff81070020>] ? worker_thread+0x0/0x340
>> [<ffffffff810752e6>] kthread+0xa6/0xb0
>> [<ffffffff81004014>] kernel_thread_helper+0x4/0x10
>> [<ffffffff8147efcb>] ? _raw_spin_unlock_irq+0x3b/0x60
>> [<ffffffff8147f600>] ? restore_args+0x0/0x30
>> [<ffffffff81075240>] ? kthread+0x0/0xb0
>> [<ffffffff81004010>] ? kernel_thread_helper+0x0/0x10
>> Booting Node 0, Processors #1 Ok.
>> TSC synchronization [CPU#0 -> CPU#1]:
>> Measured 399476 cycles TSC warp between CPUs, turning off TSC clock.
>> Marking TSC unstable due to check_tsc_sync_source failed
>> NMI watchdog enabled, takes one hw-pmu counter.
>> Brought up 2 CPUs
>> Total of 2 processors activated (8781.86 BogoMIPS).
>> regulator: core version 0.5
>> regulator: dummy:
>> Time: 7:44:09 Date: 10/05/10
>
> Hello, Zdenek,
>
> I believe that the following patch from Peter Z. should address this.
>
> Thanx, Paul
I get a similar lockdep splat, even with that patch applied,
so I think it is not completely fixed.
I'm using wireless-testing, which is based on 2.6.36-rc6.
See my previous email:
http://groups.google.com/group/linux.kernel/browse_thread/thread/fcef23494cfda353
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - RCU whinge during very early boot
2010-10-06 23:04 ` Paul E. McKenney
2010-10-06 23:18 ` Ben Greear
@ 2010-10-18 12:26 ` Zdenek Kabelac
2010-11-07 18:46 ` Paul E. McKenney
1 sibling, 1 reply; 20+ messages in thread
From: Zdenek Kabelac @ 2010-10-18 12:26 UTC (permalink / raw)
To: paulmck
Cc: Valdis.Kletnieks, Andrew Morton, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, linux-kernel
2010/10/7 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> On Tue, Oct 05, 2010 at 12:05:13PM +0200, Zdenek Kabelac wrote:
>> 2010/8/12 <Valdis.Kletnieks@vt.edu>:
>> > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
>> >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
>> >>
>> >> http://userweb.kernel.org/~akpm/mmotm/
>> >
>> > Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
>> >
>> > [ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
>> > [ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
>> > [ 0.030019] lockdep: fixing up alternatives.
>> > [ 0.031178]
>> > [ 0.031179] ===================================================
>> > [ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
>> > [ 0.031184] ---------------------------------------------------
>> > [ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>> > [ 0.031189]
>> > [ 0.031189] other info that might help us debug this:
>> > [ 0.031190]
>> > [ 0.031192]
>> > [ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
>> > [ 0.031195] 3 locks held by kworker/0:0/4:
>> > [ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
>> > [ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
>> > [ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
>> > [ 0.031225]
>> > [ 0.031226] stack backtrace:
>> > [ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
>> > [ 0.031232] Call Trace:
>> > [ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
>> > [ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
>> > [ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
>> > [ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
>> > [ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
>> > [ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
>> > [ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
>> > [ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
>> > [ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
>> > [ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
>> > [ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
>> > [ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
>> > [ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
>> > [ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
>> > [ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
>> > [ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
>> > [ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
>> > [ 0.031333] Booting Node 0, Processors #1 Ok.
>> > [ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
>> > [ 0.104013] Brought up 2 CPUs
>> >
>>
>> I'm still seeing this INFO message on my vanilla 2.6.36-rc kernel.
>>
>> ----------------------
>>
>> ftrace: converting mcount calls to 0f 1f 44 00 00
>> ftrace: allocating 16045 entries in 63 pages
>> Setting APIC routing to flat
>> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>> CPU0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0a
>> NMI watchdog enabled, takes one hw-pmu counter.
>> lockdep: fixing up alternatives.
>>
> Hello, Zdenek,
>
> I believe that the following patch from Peter Z. should address this.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit e3dd67d97b3c2aad366b845c797745a78efaf90d
> Author: Peter Zijlstra <peterz@infradead.org>
> Date: Thu Sep 16 17:50:31 2010 +0200
>
> sched: fix RCU lockdep splat from task_group()
>
> This addresses the following RCU lockdep splat:
...
> So insert an RCU read-side critical section to avoid the complaint.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 09b574e..40e065e 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -5331,7 +5331,19 @@ void __cpuinit init_idle(struct task_struct *idle, int cpu)
> idle->se.exec_start = sched_clock();
>
> cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
> + /*
> + * We're having a chicken and egg problem, even though we are
> + * holding rq->lock, the cpu isn't yet set to this cpu so the
> + * lockdep check in task_group() will fail.
> + *
> + * Similar case to sched_fork(). / Alternatively we could
> + * use task_rq_lock() here and obtain the other rq->lock.
> + *
> + * Silence PROVE_RCU
> + */
> + rcu_read_lock();
> __set_task_cpu(idle, cpu);
> + rcu_read_unlock();
>
> rq->curr = rq->idle = idle;
> #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
>
I'm using kernel patched with this patch - but I still get this error
- though at different place:
(not really sure how it is related - but of course the RCU complain
disappeared during boot).
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
kernel/sched.c:618 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by make/6137:
#0: (&rq->lock){......}, at: [<ffffffff810487d7>] task_fork_fair+0x67/0x180
stack backtrace:
Pid: 6137, comm: make Not tainted 2.6.36-rc8-00024-ga7ac73b #6
Call Trace:
[<ffffffff81089b7b>] lockdep_rcu_dereference+0xbb/0xc0
[<ffffffff8103e605>] set_task_rq+0x2f5/0x300
[<ffffffff810488db>] task_fork_fair+0x16b/0x180
[<ffffffff8104b634>] sched_fork+0xe4/0x280
[<ffffffff8104fa55>] copy_process+0x6e5/0x13d0
[<ffffffff81119809>] ? __do_fault+0x3b9/0x4b0
[<ffffffff810507fb>] do_fork+0x8b/0x490
[<ffffffff8111d6b6>] ? handle_mm_fault+0x196/0xa90
[<ffffffff8147dc2d>] ? retint_swapgs+0xe/0x13
[<ffffffff8147dc2d>] ? retint_swapgs+0xe/0x13
[<ffffffff8100c395>] sys_vfork+0x25/0x30
[<ffffffff81003583>] stub_vfork+0x13/0x20
[<ffffffff810031db>] ? system_call_fastpath+0x16/0x1b
loop: module loaded
Zdenek
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: mmotm 2010-08-11 - RCU whinge during very early boot
2010-10-18 12:26 ` Zdenek Kabelac
@ 2010-11-07 18:46 ` Paul E. McKenney
0 siblings, 0 replies; 20+ messages in thread
From: Paul E. McKenney @ 2010-11-07 18:46 UTC (permalink / raw)
To: Zdenek Kabelac
Cc: Valdis.Kletnieks, Andrew Morton, Ingo Molnar, Peter Zijlstra,
Thomas Gleixner, linux-kernel
On Mon, Oct 18, 2010 at 02:26:02PM +0200, Zdenek Kabelac wrote:
> 2010/10/7 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> > On Tue, Oct 05, 2010 at 12:05:13PM +0200, Zdenek Kabelac wrote:
> >> 2010/8/12 <Valdis.Kletnieks@vt.edu>:
> >> > On Wed, 11 Aug 2010 16:10:49 PDT, akpm@linux-foundation.org said:
> >> >> The mm-of-the-moment snapshot 2010-08-11-16-10 has been uploaded to
> >> >>
> >> >> http://userweb.kernel.org/~akpm/mmotm/
> >> >
> >> > Throws a RCU complaint. Hopefully somebody on the cc: list knows what it is about...
> >> >
> >> > [ 0.026136] CPU0: Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz stepping 0a
> >> > [ 0.028399] NMI watchdog enabled, takes one hw-pmu counter.
> >> > [ 0.030019] lockdep: fixing up alternatives.
> >> > [ 0.031178]
> >> > [ 0.031179] ===================================================
> >> > [ 0.031182] [ INFO: suspicious rcu_dereference_check() usage. ]
> >> > [ 0.031184] ---------------------------------------------------
> >> > [ 0.031187] kernel/sched.c:618 invoked rcu_dereference_check() without protection!
> >> > [ 0.031189]
> >> > [ 0.031189] other info that might help us debug this:
> >> > [ 0.031190]
> >> > [ 0.031192]
> >> > [ 0.031193] rcu_scheduler_active = 1, debug_locks = 1
> >> > [ 0.031195] 3 locks held by kworker/0:0/4:
> >> > [ 0.031197] #0: (events){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> >> > [ 0.031210] #1: ((&c_idle.work)){+.+.+.}, at: [<ffffffff810504ca>] process_one_work+0x1b6/0x37d
> >> > [ 0.031217] #2: (&rq->lock){-.-...}, at: [<ffffffff81b5f9b8>] init_idle+0x2b/0x114
> >> > [ 0.031225]
> >> > [ 0.031226] stack backtrace:
> >> > [ 0.031229] Pid: 4, comm: kworker/0:0 Not tainted 2.6.35-mmotm0811 #1
> >> > [ 0.031232] Call Trace:
> >> > [ 0.031237] [<ffffffff810661eb>] lockdep_rcu_dereference+0x9d/0xa5
> >> > [ 0.031242] [<ffffffff8102b751>] task_group+0x7b/0x8a
> >> > [ 0.031246] [<ffffffff81b5f9b8>] ? init_idle+0x2b/0x114
> >> > [ 0.031250] [<ffffffff8102b775>] set_task_rq+0x15/0x6e
> >> > [ 0.031253] [<ffffffff81b5fa5e>] init_idle+0xd1/0x114
> >> > [ 0.031257] [<ffffffff81b5fb44>] fork_idle+0x8e/0x9d
> >> > [ 0.031261] [<ffffffff81b5de6f>] do_fork_idle+0x17/0x28
> >> > [ 0.031265] [<ffffffff8105052b>] process_one_work+0x217/0x37d
> >> > [ 0.031269] [<ffffffff810504ca>] ? process_one_work+0x1b6/0x37d
> >> > [ 0.031273] [<ffffffff81b5de58>] ? do_fork_idle+0x0/0x28
> >> > [ 0.031277] [<ffffffff81051775>] worker_thread+0x17e/0x251
> >> > [ 0.031281] [<ffffffff810515f7>] ? worker_thread+0x0/0x251
> >> > [ 0.031285] [<ffffffff8105544a>] kthread+0x7d/0x85
> >> > [ 0.031290] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> >> > [ 0.031295] [<ffffffff81558d80>] ? restore_args+0x0/0x30
> >> > [ 0.031299] [<ffffffff810553cd>] ? kthread+0x0/0x85
> >> > [ 0.031303] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> >> > [ 0.031333] Booting Node 0, Processors #1 Ok.
> >> > [ 0.103111] NMI watchdog enabled, takes one hw-pmu counter.
> >> > [ 0.104013] Brought up 2 CPUs
> >> >
> >>
> >> I'm still seeing this INFO message on my vanilla 2.6.36-rc kernel.
> >>
> >> ----------------------
> >>
> >> ftrace: converting mcount calls to 0f 1f 44 00 00
> >> ftrace: allocating 16045 entries in 63 pages
> >> Setting APIC routing to flat
> >> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> >> CPU0: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping 0a
> >> NMI watchdog enabled, takes one hw-pmu counter.
> >> lockdep: fixing up alternatives.
> >>
>
>
> > Hello, Zdenek,
> >
> > I believe that the following patch from Peter Z. should address this.
> >
> > Thanx, Paul
> >
>
>
> > ------------------------------------------------------------------------
> >
> > commit e3dd67d97b3c2aad366b845c797745a78efaf90d
> > Author: Peter Zijlstra <peterz@infradead.org>
> > Date: Thu Sep 16 17:50:31 2010 +0200
> >
> > sched: fix RCU lockdep splat from task_group()
> >
> > This addresses the following RCU lockdep splat:
> ...
> > So insert an RCU read-side critical section to avoid the complaint.
> >
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > diff --git a/kernel/sched.c b/kernel/sched.c
> > index 09b574e..40e065e 100644
> > --- a/kernel/sched.c
> > +++ b/kernel/sched.c
> > @@ -5331,7 +5331,19 @@ void __cpuinit init_idle(struct task_struct *idle, int cpu)
> > idle->se.exec_start = sched_clock();
> >
> > cpumask_copy(&idle->cpus_allowed, cpumask_of(cpu));
> > + /*
> > + * We're having a chicken and egg problem, even though we are
> > + * holding rq->lock, the cpu isn't yet set to this cpu so the
> > + * lockdep check in task_group() will fail.
> > + *
> > + * Similar case to sched_fork(). / Alternatively we could
> > + * use task_rq_lock() here and obtain the other rq->lock.
> > + *
> > + * Silence PROVE_RCU
> > + */
> > + rcu_read_lock();
> > __set_task_cpu(idle, cpu);
> > + rcu_read_unlock();
> >
> > rq->curr = rq->idle = idle;
> > #if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
> >
>
>
>
> I'm using kernel patched with this patch - but I still get this error
> - though at different place:
> (not really sure how it is related - but of course the RCU complain
> disappeared during boot).
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 1 lock held by make/6137:
> #0: (&rq->lock){......}, at: [<ffffffff810487d7>] task_fork_fair+0x67/0x180
>
> stack backtrace:
> Pid: 6137, comm: make Not tainted 2.6.36-rc8-00024-ga7ac73b #6
> Call Trace:
> [<ffffffff81089b7b>] lockdep_rcu_dereference+0xbb/0xc0
> [<ffffffff8103e605>] set_task_rq+0x2f5/0x300
> [<ffffffff810488db>] task_fork_fair+0x16b/0x180
> [<ffffffff8104b634>] sched_fork+0xe4/0x280
> [<ffffffff8104fa55>] copy_process+0x6e5/0x13d0
> [<ffffffff81119809>] ? __do_fault+0x3b9/0x4b0
> [<ffffffff810507fb>] do_fork+0x8b/0x490
> [<ffffffff8111d6b6>] ? handle_mm_fault+0x196/0xa90
> [<ffffffff8147dc2d>] ? retint_swapgs+0xe/0x13
> [<ffffffff8147dc2d>] ? retint_swapgs+0xe/0x13
> [<ffffffff8100c395>] sys_vfork+0x25/0x30
> [<ffffffff81003583>] stub_vfork+0x13/0x20
> [<ffffffff810031db>] ? system_call_fastpath+0x16/0x1b
> loop: module loaded
OK, so this one requires that we either be in an rcu_read_lock()
critical section, that we hold the task's alloc_lock(), that the
cgroup_mutex is held, or that the runqueue lock for the CPU that
the task last ran on is held. Unfortunately, we are creating the
task, so there is no last CPU that it ran on, thus confusing the
check.
But this looks -really- familiar...
Could you please apply commit b0a0f667, which hit mainline after 2.6.36?
Thanx, Paul
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-11-07 18:46 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-11 23:10 mmotm 2010-08-11-16-10 uploaded akpm
2010-08-12 16:18 ` mmotm 2010-08-11 - RCU whinge during very early boot Valdis.Kletnieks
2010-08-16 17:23 ` Paul E. McKenney
2010-10-05 10:05 ` Zdenek Kabelac
2010-10-06 23:04 ` Paul E. McKenney
2010-10-06 23:18 ` Ben Greear
2010-10-18 12:26 ` Zdenek Kabelac
2010-11-07 18:46 ` Paul E. McKenney
2010-08-12 16:36 ` [PATCH] mmc: fix for CONFIG_PM disabled Randy Dunlap
2010-08-18 9:10 ` Uwe Kleine-König
2010-08-12 16:37 ` mmotm 2010-08-11 - lockdep whinges at e1000e driver ifconfig up Valdis.Kletnieks
2010-08-12 18:59 ` mmotm 2010-08-11 - audio volume issues Valdis.Kletnieks
2010-08-12 18:59 ` Valdis.Kletnieks
2010-08-12 19:37 ` Takashi Iwai
2010-08-12 21:06 ` Jiri Slaby
2010-08-12 21:06 ` Jiri Slaby
2010-08-12 21:11 ` Takashi Iwai
2010-08-12 21:11 ` Takashi Iwai
2010-08-13 2:13 ` Valdis.Kletnieks
2010-08-13 2:13 ` Valdis.Kletnieks
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.