* 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
* 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: 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
* [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
* 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
* 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
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.