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
On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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
From: Randy Dunlap <[email protected]>
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 <[email protected]>
---
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.
On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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
On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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.
At Thu, 12 Aug 2010 14:59:32 -0400,
[email protected] wrote:
>
> On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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
On 08/12/2010 08:59 PM, [email protected] wrote:
> On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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
At Thu, 12 Aug 2010 23:06:22 +0200,
Jiri Slaby wrote:
>
> On 08/12/2010 08:59 PM, [email protected] wrote:
> > On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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
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, [email protected] wrote:
> > > On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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 <[email protected]>
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).
On Thu, Aug 12, 2010 at 12:18:07PM -0400, [email protected] wrote:
> On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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 <[email protected]>
---
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)
On Thu, Aug 12, 2010 at 09:36:43AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> 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 <[email protected]>
I sent the same patch[1] a few hours later than Randy, mine got
Acked-by: Kukjin Kim <[email protected]>
Acked-by: Maxim Levitsky <[email protected]>
. 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/[email protected]
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Mon, Oct 18, 2010 at 02:26:02PM +0200, Zdenek Kabelac wrote:
> 2010/10/7 Paul E. McKenney <[email protected]>:
> > On Tue, Oct 05, 2010 at 12:05:13PM +0200, Zdenek Kabelac wrote:
> >> 2010/8/12 ?<[email protected]>:
> >> > On Wed, 11 Aug 2010 16:10:49 PDT, [email protected] 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 <[email protected]>
> > 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 <[email protected]>
> > ? ?Signed-off-by: Paul E. McKenney <[email protected]>
> >
> > 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