* mmotm 2010-12-23-16-58 uploaded @ 2010-12-24 0:58 ` akpm 0 siblings, 0 replies; 45+ messages in thread From: akpm @ 2010-12-24 0:58 UTC (permalink / raw) To: mm-commits, linux-kernel, linux-mm, linux-fsdevel The mm-of-the-moment snapshot 2010-12-23-16-58 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.37-rc7: origin.patch linux-next.patch linux-next-git-rejects.patch next-remove-localversion.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch ima-fix-add-lsm-rule-bug.patch keys-dont-call-up_write-if-__key_link_begin-returns-an-error.patch arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch memblock-fix-memblock_is_region_memory.patch mm-vmap-area-cache.patch pata_mpc52xx-driver-needs-bmdma.patch backlight-fix-88pm860x_bl-macro-collision.patch cciss-fix-botched-tag-masking-for-scsi-tape-commands.patch arch-x86-oprofile-op_model_amdc-perform-initialisation-on-a-single-cpu.patch acerhdf-add-support-for-aspire-1410-bios-v13314.patch arm-translate-delays-into-mostly-c.patch arm-allow-machines-to-override-__delay.patch arm-implement-a-timer-based-__delay-loop.patch msm-timer-migrate-to-timer-based-__delay.patch fs-btrfs-inodec-eliminate-memory-leak.patch btrfs-dont-dereference-extent_mapping-if-null.patch cpufreq-fix-ondemand-governor-powersave_bias-execution-time-misuse.patch debugfs-remove-module_exit.patch drivers-gpu-drm-radeon-atomc-fix-warning.patch irq-use-per_cpu-kstat_irqs.patch modpost-fix-address-calculation-in-reloc_location.patch drivers-leds-leds-lp5521c-fix-potential-buffer-overflow.patch leds-leds-pca9532-cleanups.patch leds-route-kbd-leds-through-the-generic-leds-layer.patch mips-enable-arch_dma_addr_t_64bit-with-highmem-64bit_phys_addr-64bit.patch isdn-capi-unregister-capictr-notifier-after-init-failure.patch isdn-capi-make-kcapi-use-a-separate-workqueue.patch drivers-video-backlight-l4f00242t03c-make-1-bit-signed-field-unsigned.patch drivers-video-backlight-l4f00242t03c-full-implement-fb-power-states-for-this-lcd.patch drivers-video-backlight-l4f00242t03c-prevent-unbalanced-calls-to-regulator-enable-disable.patch btusb-patch-add_apple_macbookpro62.patch atmel_serial-fix-rts-high-after-initialization-in-rs485-mode.patch atmel_serial-fix-rts-high-after-initialization-in-rs485-mode-fix.patch drivers-message-fusion-mptsasc-fix-warning.patch scsi-fix-a-header-to-include-linux-typesh.patch drivers-block-makefile-replace-the-use-of-module-objs-with-module-y.patch drivers-block-aoe-makefile-replace-the-use-of-module-objs-with-module-y.patch vfs-remove-a-warning-on-open_fmode.patch vfs-add-__fmode_exec.patch fs-make-block-fiemap-mapping-length-at-least-blocksize-long.patch n_hdlc-fix-read-and-write-locking.patch n_hdlc-fix-read-and-write-locking-update.patch mm.patch mm-page-allocator-adjust-the-per-cpu-counter-threshold-when-memory-is-low.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds-fix.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds-update.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds-fix-set_pgdat_percpu_threshold-dont-use-for_each_online_cpu.patch writeback-integrated-background-writeback-work.patch writeback-trace-wakeup-event-for-background-writeback.patch writeback-stop-background-kupdate-works-from-livelocking-other-works.patch writeback-stop-background-kupdate-works-from-livelocking-other-works-update.patch writeback-avoid-livelocking-wb_sync_all-writeback.patch writeback-avoid-livelocking-wb_sync_all-writeback-update.patch writeback-check-skipped-pages-on-wb_sync_all.patch writeback-check-skipped-pages-on-wb_sync_all-update.patch writeback-check-skipped-pages-on-wb_sync_all-update-fix.patch writeback-io-less-balance_dirty_pages.patch writeback-consolidate-variable-names-in-balance_dirty_pages.patch writeback-per-task-rate-limit-on-balance_dirty_pages.patch writeback-per-task-rate-limit-on-balance_dirty_pages-fix.patch writeback-prevent-duplicate-balance_dirty_pages_ratelimited-calls.patch writeback-account-per-bdi-accumulated-written-pages.patch writeback-bdi-write-bandwidth-estimation.patch writeback-bdi-write-bandwidth-estimation-fix.patch writeback-show-bdi-write-bandwidth-in-debugfs.patch writeback-quit-throttling-when-bdi-dirty-pages-dropped-low.patch writeback-reduce-per-bdi-dirty-threshold-ramp-up-time.patch writeback-make-reasonable-gap-between-the-dirty-background-thresholds.patch writeback-scale-down-max-throttle-bandwidth-on-concurrent-dirtiers.patch writeback-add-trace-event-for-balance_dirty_pages.patch writeback-make-nr_to_write-a-per-file-limit.patch writeback-make-nr_to_write-a-per-file-limit-fix.patch sync_inode_metadata-fix-comment.patch mm-page-writebackc-fix-__set_page_dirty_no_writeback-return-value.patch vmscan-factor-out-kswapd-sleeping-logic-from-kswapd.patch mm-find_get_pages_contig-fixlet.patch fs-mpagec-consolidate-code.patch fs-mpagec-consolidate-code-checkpatch-fixes.patch mm-convert-sprintf_symbol-to-%ps.patch mm-smaps-export-mlock-information.patch mm-compaction-add-trace-events-for-memory-compaction-activity.patch mm-vmscan-convert-lumpy_mode-into-a-bitmask.patch mm-vmscan-reclaim-order-0-and-use-compaction-instead-of-lumpy-reclaim.patch mm-vmscan-reclaim-order-0-and-use-compaction-instead-of-lumpy-reclaim-fix.patch mm-migration-allow-migration-to-operate-asynchronously-and-avoid-synchronous-compaction-in-the-faster-path.patch mm-migration-allow-migration-to-operate-asynchronously-and-avoid-synchronous-compaction-in-the-faster-path-fix.patch mm-migration-cleanup-migrate_pages-api-by-matching-types-for-offlining-and-sync.patch mm-compaction-perform-a-faster-migration-scan-when-migrating-asynchronously.patch mm-vmscan-rename-lumpy_mode-to-reclaim_mode.patch mm-vmscan-rename-lumpy_mode-to-reclaim_mode-fix.patch mm-deactivate-invalidated-pages.patch mm-deactivate-invalidated-pages-fix.patch mm-remove-unused-get_vm_area_node.patch mm-remove-gfp-mask-from-pcpu_get_vm_areas.patch mm-unify-module_alloc-code-for-vmalloc.patch oom-allow-a-non-cap_sys_resource-proces-to-oom_score_adj-down.patch mm-clear-pageerror-bit-in-msync-fsync.patch do_wp_page-remove-the-reuse-flag.patch do_wp_page-clarify-dirty_page-handling.patch mlock-avoid-dirtying-pages-and-triggering-writeback.patch mlock-only-hold-mmap_sem-in-shared-mode-when-faulting-in-pages.patch mlock-only-hold-mmap_sem-in-shared-mode-when-faulting-in-pages-fix.patch mm-add-foll_mlock-follow_page-flag.patch mm-move-vm_locked-check-to-__mlock_vma_pages_range.patch mlock-do-not-hold-mmap_sem-for-extended-periods-of-time.patch mlock-do-not-hold-mmap_sem-for-extended-periods-of-time-fix.patch mlock-do-not-hold-mmap_sem-for-extended-periods-of-time-fix2.patch mempolicy-remove-tasklist_lock-from-migrate_pages.patch vmalloc-remove-redundant-unlikely.patch mm-remove-likely-from-mapping_unevictable.patch mm-remove-unlikely-from-page_mapping.patch mm-remove-likely-from-grab_cache_page_write_begin.patch mm-kswapd-stop-high-order-balancing-when-any-suitable-zone-is-balanced.patch mm-kswapd-keep-kswapd-awake-for-high-order-allocations-until-a-percentage-of-the-node-is-balanced.patch mm-kswapd-use-the-order-that-kswapd-was-reclaiming-at-for-sleeping_prematurely.patch mm-kswapd-reset-kswapd_max_order-and-classzone_idx-after-reading.patch mm-kswapd-treat-zone-all_unreclaimable-in-sleeping_prematurely-similar-to-balance_pgdat.patch mm-kswapd-use-the-classzone-idx-that-kswapd-was-using-for-sleeping_prematurely.patch mm-set-correct-numa_zonelist_order-string-when-configured-on-the-kernel-command-line.patch thp-ksm-free-swap-when-swapcache-page-is-replaced.patch thp-fix-bad_page-to-show-the-real-reason-the-page-is-bad.patch thp-transparent-hugepage-support-documentation.patch thp-mm-define-madv_hugepage.patch thp-compound_lock.patch thp-alter-compound-get_page-put_page.patch thp-put_page-recheck-pagehead-after-releasing-the-compound_lock.patch thp-update-futex-compound-knowledge.patch thp-clear-compound-mapping.patch thp-add-native_set_pmd_at.patch thp-add-pmd-paravirt-ops.patch thp-no-paravirt-version-of-pmd-ops.patch thp-export-maybe_mkwrite.patch thp-comment-reminder-in-destroy_compound_page.patch thp-config_transparent_hugepage.patch thp-config_transparent_hugepage-fix.patch thp-special-pmd_trans_-functions.patch thp-add-pmd-mangling-generic-functions.patch thp-add-pmd-mangling-generic-functions-fix-pgtableh-build-for-um.patch thp-add-pmd-mangling-functions-to-x86.patch thp-bail-out-gup_fast-on-splitting-pmd.patch thp-pte-alloc-trans-splitting.patch thp-pte-alloc-trans-splitting-fix.patch thp-pte-alloc-trans-splitting-fix-checkpatch-fixes.patch thp-add-pmd-mmu_notifier-helpers.patch thp-clear-page-compound.patch thp-add-pmd_huge_pte-to-mm_struct.patch thp-split_huge_page_mm-vma.patch thp-split_huge_page-paging.patch thp-clear_copy_huge_page.patch thp-kvm-mmu-transparent-hugepage-support.patch thp-_gfp_no_kswapd.patch thp-dont-alloc-harder-for-gfp-nomemalloc-even-if-nowait.patch thp-transparent-hugepage-core.patch thp-split_huge_page-anon_vma-ordering-dependency.patch thp-verify-pmd_trans_huge-isnt-leaking.patch thp-madvisemadv_hugepage.patch thp-add-pagetranscompound.patch thp-pmd_trans_huge-migrate-bugcheck.patch thp-memcg-compound.patch thp-transhuge-memcg-commit-tail-pages-at-charge.patch thp-memcg-huge-memory.patch thp-transparent-hugepage-vmstat.patch thp-khugepaged.patch thp-khugepaged-vma-merge.patch thp-skip-transhuge-pages-in-ksm-for-now.patch thp-remove-pg_buddy.patch thp-add-x86-32bit-support.patch thp-mincore-transparent-hugepage-support.patch thp-add-pmd_modify.patch thp-mprotect-pass-vma-down-to-page-table-walkers.patch thp-mprotect-transparent-huge-page-support.patch thp-set-recommended-min-free-kbytes.patch thp-enable-direct-defrag.patch thp-add-numa-awareness-to-hugepage-allocations.patch thp-allocate-memory-in-khugepaged-outside-of-mmap_sem-write-mode.patch thp-allocate-memory-in-khugepaged-outside-of-mmap_sem-write-mode-fix.patch thp-transparent-hugepage-config-choice.patch thp-select-config_compaction-if-transparent_hugepage-enabled.patch thp-transhuge-isolate_migratepages.patch thp-avoid-breaking-huge-pmd-invariants-in-case-of-vma_adjust-failures.patch thp-dont-allow-transparent-hugepage-support-without-pse.patch thp-mmu_notifier_test_young.patch thp-freeze-khugepaged-and-ksmd.patch thp-use-compaction-in-kswapd-for-gfp_atomic-order-0.patch thp-use-compaction-for-all-allocation-orders.patch thp-disable-transparent-hugepages-by-default-on-small-systems.patch thp-fix-anon-memory-statistics-with-transparent-hugepages.patch thp-scale-nr_rotated-to-balance-memory-pressure.patch thp-transparent-hugepage-sysfs-meminfo.patch thp-add-debug-checks-for-mapcount-related-invariants.patch thp-fix-memory-failure-hugetlbfs-vs-thp-collision.patch thp-compound_trans_order.patch thp-compound_trans_order-fix.patch thp-mm-define-madv_nohugepage.patch thp-madvisemadv_nohugepage.patch thp-khugepaged-make-khugepaged-aware-of-madvise.patch thp-khugepaged-make-khugepaged-aware-of-madvise-fix.patch mm-migration-use-rcu_dereference_protected-when-dereferencing-the-radix-tree-slot-during-file-page-migration.patch mm-migration-use-rcu_dereference_protected-when-dereferencing-the-radix-tree-slot-during-file-page-migration-fix.patch mm-hugetlbc-fix-error-path-memory-leak-in-nr_hugepages_store_common.patch mm-hugetlbc-fix-error-path-memory-leak-in-nr_hugepages_store_common-fix.patch frv-duplicate-output_buffer-of-e03.patch frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch hpet-factor-timer-allocate-from-open.patch um-mark-config_highmem-as-broken.patch arch-um-drivers-linec-safely-iterate-over-list-of-winch-handlers.patch uml-mmapper_kern-needs-module_license.patch kmsg_dump-constrain-mtdoops-and-ramoops-to-perform-their-actions-only-for-kmsg_dump_panic.patch kmsg_dump-add-kmsg_dump-calls-to-the-reboot-halt-poweroff-and-emergency_restart-paths.patch set_rtc_mmss-show-warning-message-only-once.patch include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit-fix.patch add-the-common-dma_addr_t-typedef-to-include-linux-typesh.patch toshibah-hide-a-function-prototypes-behind-__kernel__-macro.patch include-linux-unaligned-packed_structh-use-__packed.patch kernel-clean-up-use_generic_smp_helpers.patch mm-numa-aware-alloc_task_struct_node.patch mm-numa-aware-alloc_thread_info_node.patch kthread-numa-aware-kthread_create_on_cpu.patch kthread-use-kthread_create_on_cpu.patch kptr_restrict-for-hiding-kernel-pointers-from-unprivileged-users.patch kptr_restrict-for-hiding-kernel-pointers-from-unprivileged-users-fix.patch kptr_restrict-for-hiding-kernel-pointers-v4.patch kptr_restrict-for-hiding-kernel-pointers-v6.patch kptr_restrict-for-hiding-kernel-pointers-v7.patch kptr_restrict-for-hiding-kernel-pointers-v7-fix.patch net-convert-%p-usage-to-%pk.patch dca-remove-unneeded-null-check.patch include-asm-generic-vmlinuxldsh-make-readmostly-section-correctly-align.patch percpu-add-new-macros-to-make-percpu-readmostly-section-correctly-align.patch printk-use-rcu-to-prevent-potential-lock-contention-in-kmsg_dump.patch include-linux-printkh-move-console-functions-and-variables-together.patch include-linux-printkh-use-space-after-define.patch include-linux-printkh-use-and-neaten-no_printk.patch include-linux-printkh-add-pr_level_once-macros.patch include-linux-printkh-lib-hexdumpc-neatening-and-add-config_printk-guard.patch include-linux-printkh-organize-printk_ratelimited-macros.patch include-linux-printkh-use-tab-not-spaces-for-indent.patch vfs-remove-unlikely-from-fput_light.patch vfs-remove-unlikely-from-fget_light.patch scripts-get_maintainerpl-make-rolestats-the-default.patch scripts-get_maintainerpl-use-git-fallback-more-often.patch maintainers-openwrt-devel-is-subscribers-only.patch flex_array-export-symbols-to-modules.patch drivers-mmc-host-omapc-use-resource_size.patch drivers-mmc-host-omap_hsmmcc-use-resource_size.patch scripts-checkpatchpl-add-check-for-multiple-terminating-semicolons-and-casts-of-vmalloc.patch checkpatchpl-fix-cast-detection.patch checkpatch-check-for-world-writeable-sysfs-debugfs-files.patch fs-select-fix-information-leak-to-userspace.patch fs-select-fix-information-leak-to-userspace-fix.patch epoll-convert-max_user_watches-to-long.patch binfmt_elf-cleanups.patch drivers-rtc-rtc-omapc-fix-a-memory-leak.patch rtc-cmos-fix-suspend-resume.patch rtc-add-real-time-clock-driver-for-nvidia-tegra.patch drivers-gpio-cs5535-gpioc-add-some-additional-cs5535-specific-gpio-functionality.patch drivers-staging-olpc_dcon-convert-to-new-cs5535-gpio-api.patch cs5535-deprecate-older-cs5535_gpio-driver.patch gpio-adp5588-gpio-irq_data-conversion.patch gpio-langwell_gpio-irq_data-conversion.patch gpio-max732x-irq_data-conversion.patch gpio-pca953x-irq_data-conversion.patch gpio-pl061-irq_data-conversion.patch gpio-stmpe-gpio-irq_data-conversion.patch gpio-sx150x-irq_data-conversion.patch gpio-tc35892-gpio-irq_data-conversion.patch gpio-timbgpio-irq_data-conversion.patch gpio-vr41xx_giu-irq_data-conversion.patch gpio_rdc321x-select-mfd_support-to-squelch-kconfig-warning.patch gpio_vx855-eliminate-kconfig-dependency-warning.patch drivers-power-gpio-chargerc-check-for-kzalloc-failure.patch cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch drivers-telephony-ixjc-fix-warning.patch ext2-speed-up-file-creates-by-optimizing-rec_len-functions.patch ext3-speed-up-file-creates-by-optimizing-rec_len-functions.patch ext3-remove-redundant-unlikely.patch jbd-remove-dependency-on-__gfp_nofail.patch cgroups-remove-deprecated-subsystem-from-examples.patch memcg-add-page_cgroup-flags-for-dirty-page-tracking.patch memcg-document-cgroup-dirty-memory-interfaces.patch memcg-document-cgroup-dirty-memory-interfaces-fix.patch memcg-create-extensible-page-stat-update-routines.patch memcg-add-lock-to-synchronize-page-accounting-and-migration.patch memcg-fix-unit-mismatch-in-memcg-oom-limit-calculation.patch memcg-remove-unnecessary-return-from-void-returning-mem_cgroup_del_lru_list.patch memcg-use-zalloc-rather-than-mallocmemset.patch fs-proc-basec-kernel-latencytopc-convert-sprintf_symbol-to-%ps.patch fs-proc-basec-kernel-latencytopc-convert-sprintf_symbol-to-%ps-checkpatch-fixes.patch proc-use-unsigned-long-inside-proc-statm.patch proc-use-seq_puts-seq_putc-where-possible.patch proc-low_ino-cleanup.patch proc-use-single_open-correctly.patch exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch rapidio-use-common-destid-storage-for-endpoints-and-switches.patch rapidio-integrate-rio_switch-into-rio_dev.patch rapidio-add-definitions-of-component-tag-fields.patch rapidio-add-device-object-linking-into-discovery.patch rapidio-use-component-tag-for-unified-switch-identification.patch rapidio-add-new-idt-srio-switches.patch rapidio-add-new-sysfs-attributes.patch sysctl-fix-ifdef-guard-comment.patch sysctl-remove-obsolete-comments.patch sysctl-remove-obsolete-comments-fix.patch user_ns-improve-the-user_ns-on-the-slab-packaging.patch user_ns-improve-the-user_ns-on-the-slab-packaging-fix.patch fs-execc-provide-the-correct-process-pid-to-the-pipe-helper.patch nfc-driver-for-nxp-semiconductors-pn544-nfc-chip.patch nfc-driver-for-nxp-semiconductors-pn544-nfc-chip-update.patch remove-dma64_addr_t.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-make-idr-lock-a-mutex-and-protect-idr_pre_get.patch pps-use-bug_on-for-kernel-api-safety-checks.patch pps-simplify-conditions-a-bit.patch pps-timestamp-is-always-passed-to-dcd_change.patch ntp-add-hardpps-implementation.patch ntp-add-hardpps-implementation-update-v7.patch pps-capture-monotonic_raw-timestamps-as-well.patch pps-capture-monotonic_raw-timestamps-as-well-v7.patch pps-add-kernel-consumer-support.patch pps-add-kernel-consumer-support-v7.patch pps-add-parallel-port-pps-client.patch pps-add-parallel-port-pps-client-v7.patch pps-add-parallel-port-pps-signal-generator.patch pps-add-parallel-port-pps-signal-generator-fix.patch pps-add-parallel-port-pps-signal-generator-v7.patch memstick-core-fix-device_register-error-handling.patch memstick-fix-setup-for-jmicron-38x-controllers.patch memstick-set-pmos-values-propery-for-jmicron-38x-controllers.patch memstick-add-support-for-jmicron-jmb-385-and-390-controllers.patch memstick-avert-possible-race-condition-between-idr_pre_get-and-idr_get_new.patch memstick-remove-mspro_block_mutex.patch memstick-factor-out-transfer-initiating-functionality-in-mspro_blockc.patch memstick-add-support-for-mspro-specific-data-transfer-method.patch w1-ds2423-counter-driver-and-documentation.patch w1-ds2423-counter-driver-and-documentation-fix.patch vmware-balloon-stop-locking-pages-when-hypervisor-tells-us-enough.patch cramfs-hide-function-prototypes-behind-__kernel__-macro.patch romfs-have-romfs_fsh-pull-in-necessary-headers.patch decompressors-add-missing-init-ie-__init.patch decompressors-get-rid-of-set_error_fn-macro.patch decompressors-include-linux-slabh-in-linux-decompress-mmh.patch decompressors-remove-unused-function-from-lib-decompress_unlzmac.patch decompressors-fix-header-validation-in-decompress_unlzmac.patch decompressors-check-for-read-errors-in-decompress_unlzmac.patch decompressors-check-for-write-errors-in-decompress_unlzmac.patch decompressors-validate-match-distance-in-decompress_unlzmac.patch decompressors-check-for-write-errors-in-decompress_unlzoc.patch decompressors-check-input-size-in-decompress_unlzoc.patch decompressors-fix-callback-to-callback-mode-in-decompress_unlzoc.patch decompressors-add-xz-decompressor-module.patch decompressors-add-boot-time-xz-support.patch decompressors-add-boot-time-xz-support-update.patch x86-support-xz-compressed-kernel.patch bitops-merge-little-and-big-endian-definisions-in-asm-generic-bitops-leh.patch bitops-rename-generic-little-endian-bitops-functions.patch s390-introduce-little-endian-bitops.patch arm-introduce-little-endian-bitops.patch m68k-introduce-little-endian-bitops.patch bitops-introduce-config_generic_find_le_bit.patch m68knommu-introduce-little-endian-bitops.patch m68knommu-introduce-little-endian-bitops-build-fix.patch bitops-introduce-little-endian-bitops-for-most-architectures.patch rds-stop-including-asm-generic-bitops-leh.patch kvm-stop-including-asm-generic-bitops-leh.patch asm-generic-use-little-endian-bitops.patch ext3-use-little-endian-bitops.patch ext4-use-little-endian-bitops.patch ocfs2-use-little-endian-bitops.patch nilfs2-use-little-endian-bitops.patch reiserfs-use-little-endian-bitops.patch udf-use-little-endian-bitops.patch ufs-use-little-endian-bitops.patch md-use-little-endian-bit-operations.patch dm-use-little-endian-bit-operations.patch bitops-remove-ext2-non-atomic-bitops-from-asm-bitopsh.patch m68k-remove-inline-asm-from-minix_find_first_zero_bit.patch bitops-remove-minix-bitops-from-asm-bitopsh.patch bitops-use-find_first_zero_bit-instead-of-find_next_zero_bitaddr-size-0.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 memblock-add-input-size-checking-to-memblock_find_region.patch memblock-add-input-size-checking-to-memblock_find_region-fix.patch ^ permalink raw reply [flat|nested] 45+ messages in thread
* mmotm 2010-12-23-16-58 uploaded @ 2010-12-24 0:58 ` akpm 0 siblings, 0 replies; 45+ messages in thread From: akpm @ 2010-12-24 0:58 UTC (permalink / raw) To: mm-commits, linux-kernel, linux-mm, linux-fsdevel The mm-of-the-moment snapshot 2010-12-23-16-58 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.37-rc7: origin.patch linux-next.patch linux-next-git-rejects.patch next-remove-localversion.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch ima-fix-add-lsm-rule-bug.patch keys-dont-call-up_write-if-__key_link_begin-returns-an-error.patch arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch memblock-fix-memblock_is_region_memory.patch mm-vmap-area-cache.patch pata_mpc52xx-driver-needs-bmdma.patch backlight-fix-88pm860x_bl-macro-collision.patch cciss-fix-botched-tag-masking-for-scsi-tape-commands.patch arch-x86-oprofile-op_model_amdc-perform-initialisation-on-a-single-cpu.patch acerhdf-add-support-for-aspire-1410-bios-v13314.patch arm-translate-delays-into-mostly-c.patch arm-allow-machines-to-override-__delay.patch arm-implement-a-timer-based-__delay-loop.patch msm-timer-migrate-to-timer-based-__delay.patch fs-btrfs-inodec-eliminate-memory-leak.patch btrfs-dont-dereference-extent_mapping-if-null.patch cpufreq-fix-ondemand-governor-powersave_bias-execution-time-misuse.patch debugfs-remove-module_exit.patch drivers-gpu-drm-radeon-atomc-fix-warning.patch irq-use-per_cpu-kstat_irqs.patch modpost-fix-address-calculation-in-reloc_location.patch drivers-leds-leds-lp5521c-fix-potential-buffer-overflow.patch leds-leds-pca9532-cleanups.patch leds-route-kbd-leds-through-the-generic-leds-layer.patch mips-enable-arch_dma_addr_t_64bit-with-highmem-64bit_phys_addr-64bit.patch isdn-capi-unregister-capictr-notifier-after-init-failure.patch isdn-capi-make-kcapi-use-a-separate-workqueue.patch drivers-video-backlight-l4f00242t03c-make-1-bit-signed-field-unsigned.patch drivers-video-backlight-l4f00242t03c-full-implement-fb-power-states-for-this-lcd.patch drivers-video-backlight-l4f00242t03c-prevent-unbalanced-calls-to-regulator-enable-disable.patch btusb-patch-add_apple_macbookpro62.patch atmel_serial-fix-rts-high-after-initialization-in-rs485-mode.patch atmel_serial-fix-rts-high-after-initialization-in-rs485-mode-fix.patch drivers-message-fusion-mptsasc-fix-warning.patch scsi-fix-a-header-to-include-linux-typesh.patch drivers-block-makefile-replace-the-use-of-module-objs-with-module-y.patch drivers-block-aoe-makefile-replace-the-use-of-module-objs-with-module-y.patch vfs-remove-a-warning-on-open_fmode.patch vfs-add-__fmode_exec.patch fs-make-block-fiemap-mapping-length-at-least-blocksize-long.patch n_hdlc-fix-read-and-write-locking.patch n_hdlc-fix-read-and-write-locking-update.patch mm.patch mm-page-allocator-adjust-the-per-cpu-counter-threshold-when-memory-is-low.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds-fix.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds-update.patch mm-vmstat-use-a-single-setter-function-and-callback-for-adjusting-percpu-thresholds-fix-set_pgdat_percpu_threshold-dont-use-for_each_online_cpu.patch writeback-integrated-background-writeback-work.patch writeback-trace-wakeup-event-for-background-writeback.patch writeback-stop-background-kupdate-works-from-livelocking-other-works.patch writeback-stop-background-kupdate-works-from-livelocking-other-works-update.patch writeback-avoid-livelocking-wb_sync_all-writeback.patch writeback-avoid-livelocking-wb_sync_all-writeback-update.patch writeback-check-skipped-pages-on-wb_sync_all.patch writeback-check-skipped-pages-on-wb_sync_all-update.patch writeback-check-skipped-pages-on-wb_sync_all-update-fix.patch writeback-io-less-balance_dirty_pages.patch writeback-consolidate-variable-names-in-balance_dirty_pages.patch writeback-per-task-rate-limit-on-balance_dirty_pages.patch writeback-per-task-rate-limit-on-balance_dirty_pages-fix.patch writeback-prevent-duplicate-balance_dirty_pages_ratelimited-calls.patch writeback-account-per-bdi-accumulated-written-pages.patch writeback-bdi-write-bandwidth-estimation.patch writeback-bdi-write-bandwidth-estimation-fix.patch writeback-show-bdi-write-bandwidth-in-debugfs.patch writeback-quit-throttling-when-bdi-dirty-pages-dropped-low.patch writeback-reduce-per-bdi-dirty-threshold-ramp-up-time.patch writeback-make-reasonable-gap-between-the-dirty-background-thresholds.patch writeback-scale-down-max-throttle-bandwidth-on-concurrent-dirtiers.patch writeback-add-trace-event-for-balance_dirty_pages.patch writeback-make-nr_to_write-a-per-file-limit.patch writeback-make-nr_to_write-a-per-file-limit-fix.patch sync_inode_metadata-fix-comment.patch mm-page-writebackc-fix-__set_page_dirty_no_writeback-return-value.patch vmscan-factor-out-kswapd-sleeping-logic-from-kswapd.patch mm-find_get_pages_contig-fixlet.patch fs-mpagec-consolidate-code.patch fs-mpagec-consolidate-code-checkpatch-fixes.patch mm-convert-sprintf_symbol-to-%ps.patch mm-smaps-export-mlock-information.patch mm-compaction-add-trace-events-for-memory-compaction-activity.patch mm-vmscan-convert-lumpy_mode-into-a-bitmask.patch mm-vmscan-reclaim-order-0-and-use-compaction-instead-of-lumpy-reclaim.patch mm-vmscan-reclaim-order-0-and-use-compaction-instead-of-lumpy-reclaim-fix.patch mm-migration-allow-migration-to-operate-asynchronously-and-avoid-synchronous-compaction-in-the-faster-path.patch mm-migration-allow-migration-to-operate-asynchronously-and-avoid-synchronous-compaction-in-the-faster-path-fix.patch mm-migration-cleanup-migrate_pages-api-by-matching-types-for-offlining-and-sync.patch mm-compaction-perform-a-faster-migration-scan-when-migrating-asynchronously.patch mm-vmscan-rename-lumpy_mode-to-reclaim_mode.patch mm-vmscan-rename-lumpy_mode-to-reclaim_mode-fix.patch mm-deactivate-invalidated-pages.patch mm-deactivate-invalidated-pages-fix.patch mm-remove-unused-get_vm_area_node.patch mm-remove-gfp-mask-from-pcpu_get_vm_areas.patch mm-unify-module_alloc-code-for-vmalloc.patch oom-allow-a-non-cap_sys_resource-proces-to-oom_score_adj-down.patch mm-clear-pageerror-bit-in-msync-fsync.patch do_wp_page-remove-the-reuse-flag.patch do_wp_page-clarify-dirty_page-handling.patch mlock-avoid-dirtying-pages-and-triggering-writeback.patch mlock-only-hold-mmap_sem-in-shared-mode-when-faulting-in-pages.patch mlock-only-hold-mmap_sem-in-shared-mode-when-faulting-in-pages-fix.patch mm-add-foll_mlock-follow_page-flag.patch mm-move-vm_locked-check-to-__mlock_vma_pages_range.patch mlock-do-not-hold-mmap_sem-for-extended-periods-of-time.patch mlock-do-not-hold-mmap_sem-for-extended-periods-of-time-fix.patch mlock-do-not-hold-mmap_sem-for-extended-periods-of-time-fix2.patch mempolicy-remove-tasklist_lock-from-migrate_pages.patch vmalloc-remove-redundant-unlikely.patch mm-remove-likely-from-mapping_unevictable.patch mm-remove-unlikely-from-page_mapping.patch mm-remove-likely-from-grab_cache_page_write_begin.patch mm-kswapd-stop-high-order-balancing-when-any-suitable-zone-is-balanced.patch mm-kswapd-keep-kswapd-awake-for-high-order-allocations-until-a-percentage-of-the-node-is-balanced.patch mm-kswapd-use-the-order-that-kswapd-was-reclaiming-at-for-sleeping_prematurely.patch mm-kswapd-reset-kswapd_max_order-and-classzone_idx-after-reading.patch mm-kswapd-treat-zone-all_unreclaimable-in-sleeping_prematurely-similar-to-balance_pgdat.patch mm-kswapd-use-the-classzone-idx-that-kswapd-was-using-for-sleeping_prematurely.patch mm-set-correct-numa_zonelist_order-string-when-configured-on-the-kernel-command-line.patch thp-ksm-free-swap-when-swapcache-page-is-replaced.patch thp-fix-bad_page-to-show-the-real-reason-the-page-is-bad.patch thp-transparent-hugepage-support-documentation.patch thp-mm-define-madv_hugepage.patch thp-compound_lock.patch thp-alter-compound-get_page-put_page.patch thp-put_page-recheck-pagehead-after-releasing-the-compound_lock.patch thp-update-futex-compound-knowledge.patch thp-clear-compound-mapping.patch thp-add-native_set_pmd_at.patch thp-add-pmd-paravirt-ops.patch thp-no-paravirt-version-of-pmd-ops.patch thp-export-maybe_mkwrite.patch thp-comment-reminder-in-destroy_compound_page.patch thp-config_transparent_hugepage.patch thp-config_transparent_hugepage-fix.patch thp-special-pmd_trans_-functions.patch thp-add-pmd-mangling-generic-functions.patch thp-add-pmd-mangling-generic-functions-fix-pgtableh-build-for-um.patch thp-add-pmd-mangling-functions-to-x86.patch thp-bail-out-gup_fast-on-splitting-pmd.patch thp-pte-alloc-trans-splitting.patch thp-pte-alloc-trans-splitting-fix.patch thp-pte-alloc-trans-splitting-fix-checkpatch-fixes.patch thp-add-pmd-mmu_notifier-helpers.patch thp-clear-page-compound.patch thp-add-pmd_huge_pte-to-mm_struct.patch thp-split_huge_page_mm-vma.patch thp-split_huge_page-paging.patch thp-clear_copy_huge_page.patch thp-kvm-mmu-transparent-hugepage-support.patch thp-_gfp_no_kswapd.patch thp-dont-alloc-harder-for-gfp-nomemalloc-even-if-nowait.patch thp-transparent-hugepage-core.patch thp-split_huge_page-anon_vma-ordering-dependency.patch thp-verify-pmd_trans_huge-isnt-leaking.patch thp-madvisemadv_hugepage.patch thp-add-pagetranscompound.patch thp-pmd_trans_huge-migrate-bugcheck.patch thp-memcg-compound.patch thp-transhuge-memcg-commit-tail-pages-at-charge.patch thp-memcg-huge-memory.patch thp-transparent-hugepage-vmstat.patch thp-khugepaged.patch thp-khugepaged-vma-merge.patch thp-skip-transhuge-pages-in-ksm-for-now.patch thp-remove-pg_buddy.patch thp-add-x86-32bit-support.patch thp-mincore-transparent-hugepage-support.patch thp-add-pmd_modify.patch thp-mprotect-pass-vma-down-to-page-table-walkers.patch thp-mprotect-transparent-huge-page-support.patch thp-set-recommended-min-free-kbytes.patch thp-enable-direct-defrag.patch thp-add-numa-awareness-to-hugepage-allocations.patch thp-allocate-memory-in-khugepaged-outside-of-mmap_sem-write-mode.patch thp-allocate-memory-in-khugepaged-outside-of-mmap_sem-write-mode-fix.patch thp-transparent-hugepage-config-choice.patch thp-select-config_compaction-if-transparent_hugepage-enabled.patch thp-transhuge-isolate_migratepages.patch thp-avoid-breaking-huge-pmd-invariants-in-case-of-vma_adjust-failures.patch thp-dont-allow-transparent-hugepage-support-without-pse.patch thp-mmu_notifier_test_young.patch thp-freeze-khugepaged-and-ksmd.patch thp-use-compaction-in-kswapd-for-gfp_atomic-order-0.patch thp-use-compaction-for-all-allocation-orders.patch thp-disable-transparent-hugepages-by-default-on-small-systems.patch thp-fix-anon-memory-statistics-with-transparent-hugepages.patch thp-scale-nr_rotated-to-balance-memory-pressure.patch thp-transparent-hugepage-sysfs-meminfo.patch thp-add-debug-checks-for-mapcount-related-invariants.patch thp-fix-memory-failure-hugetlbfs-vs-thp-collision.patch thp-compound_trans_order.patch thp-compound_trans_order-fix.patch thp-mm-define-madv_nohugepage.patch thp-madvisemadv_nohugepage.patch thp-khugepaged-make-khugepaged-aware-of-madvise.patch thp-khugepaged-make-khugepaged-aware-of-madvise-fix.patch mm-migration-use-rcu_dereference_protected-when-dereferencing-the-radix-tree-slot-during-file-page-migration.patch mm-migration-use-rcu_dereference_protected-when-dereferencing-the-radix-tree-slot-during-file-page-migration-fix.patch mm-hugetlbc-fix-error-path-memory-leak-in-nr_hugepages_store_common.patch mm-hugetlbc-fix-error-path-memory-leak-in-nr_hugepages_store_common-fix.patch frv-duplicate-output_buffer-of-e03.patch frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch hpet-factor-timer-allocate-from-open.patch um-mark-config_highmem-as-broken.patch arch-um-drivers-linec-safely-iterate-over-list-of-winch-handlers.patch uml-mmapper_kern-needs-module_license.patch kmsg_dump-constrain-mtdoops-and-ramoops-to-perform-their-actions-only-for-kmsg_dump_panic.patch kmsg_dump-add-kmsg_dump-calls-to-the-reboot-halt-poweroff-and-emergency_restart-paths.patch set_rtc_mmss-show-warning-message-only-once.patch include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit.patch include-linux-kernelh-abs-fix-handling-of-32-bit-unsigneds-on-64-bit-fix.patch add-the-common-dma_addr_t-typedef-to-include-linux-typesh.patch toshibah-hide-a-function-prototypes-behind-__kernel__-macro.patch include-linux-unaligned-packed_structh-use-__packed.patch kernel-clean-up-use_generic_smp_helpers.patch mm-numa-aware-alloc_task_struct_node.patch mm-numa-aware-alloc_thread_info_node.patch kthread-numa-aware-kthread_create_on_cpu.patch kthread-use-kthread_create_on_cpu.patch kptr_restrict-for-hiding-kernel-pointers-from-unprivileged-users.patch kptr_restrict-for-hiding-kernel-pointers-from-unprivileged-users-fix.patch kptr_restrict-for-hiding-kernel-pointers-v4.patch kptr_restrict-for-hiding-kernel-pointers-v6.patch kptr_restrict-for-hiding-kernel-pointers-v7.patch kptr_restrict-for-hiding-kernel-pointers-v7-fix.patch net-convert-%p-usage-to-%pk.patch dca-remove-unneeded-null-check.patch include-asm-generic-vmlinuxldsh-make-readmostly-section-correctly-align.patch percpu-add-new-macros-to-make-percpu-readmostly-section-correctly-align.patch printk-use-rcu-to-prevent-potential-lock-contention-in-kmsg_dump.patch include-linux-printkh-move-console-functions-and-variables-together.patch include-linux-printkh-use-space-after-define.patch include-linux-printkh-use-and-neaten-no_printk.patch include-linux-printkh-add-pr_level_once-macros.patch include-linux-printkh-lib-hexdumpc-neatening-and-add-config_printk-guard.patch include-linux-printkh-organize-printk_ratelimited-macros.patch include-linux-printkh-use-tab-not-spaces-for-indent.patch vfs-remove-unlikely-from-fput_light.patch vfs-remove-unlikely-from-fget_light.patch scripts-get_maintainerpl-make-rolestats-the-default.patch scripts-get_maintainerpl-use-git-fallback-more-often.patch maintainers-openwrt-devel-is-subscribers-only.patch flex_array-export-symbols-to-modules.patch drivers-mmc-host-omapc-use-resource_size.patch drivers-mmc-host-omap_hsmmcc-use-resource_size.patch scripts-checkpatchpl-add-check-for-multiple-terminating-semicolons-and-casts-of-vmalloc.patch checkpatchpl-fix-cast-detection.patch checkpatch-check-for-world-writeable-sysfs-debugfs-files.patch fs-select-fix-information-leak-to-userspace.patch fs-select-fix-information-leak-to-userspace-fix.patch epoll-convert-max_user_watches-to-long.patch binfmt_elf-cleanups.patch drivers-rtc-rtc-omapc-fix-a-memory-leak.patch rtc-cmos-fix-suspend-resume.patch rtc-add-real-time-clock-driver-for-nvidia-tegra.patch drivers-gpio-cs5535-gpioc-add-some-additional-cs5535-specific-gpio-functionality.patch drivers-staging-olpc_dcon-convert-to-new-cs5535-gpio-api.patch cs5535-deprecate-older-cs5535_gpio-driver.patch gpio-adp5588-gpio-irq_data-conversion.patch gpio-langwell_gpio-irq_data-conversion.patch gpio-max732x-irq_data-conversion.patch gpio-pca953x-irq_data-conversion.patch gpio-pl061-irq_data-conversion.patch gpio-stmpe-gpio-irq_data-conversion.patch gpio-sx150x-irq_data-conversion.patch gpio-tc35892-gpio-irq_data-conversion.patch gpio-timbgpio-irq_data-conversion.patch gpio-vr41xx_giu-irq_data-conversion.patch gpio_rdc321x-select-mfd_support-to-squelch-kconfig-warning.patch gpio_vx855-eliminate-kconfig-dependency-warning.patch drivers-power-gpio-chargerc-check-for-kzalloc-failure.patch cyber2000fb-avoid-palette-corruption-at-higher-clocks.patch drivers-telephony-ixjc-fix-warning.patch ext2-speed-up-file-creates-by-optimizing-rec_len-functions.patch ext3-speed-up-file-creates-by-optimizing-rec_len-functions.patch ext3-remove-redundant-unlikely.patch jbd-remove-dependency-on-__gfp_nofail.patch cgroups-remove-deprecated-subsystem-from-examples.patch memcg-add-page_cgroup-flags-for-dirty-page-tracking.patch memcg-document-cgroup-dirty-memory-interfaces.patch memcg-document-cgroup-dirty-memory-interfaces-fix.patch memcg-create-extensible-page-stat-update-routines.patch memcg-add-lock-to-synchronize-page-accounting-and-migration.patch memcg-fix-unit-mismatch-in-memcg-oom-limit-calculation.patch memcg-remove-unnecessary-return-from-void-returning-mem_cgroup_del_lru_list.patch memcg-use-zalloc-rather-than-mallocmemset.patch fs-proc-basec-kernel-latencytopc-convert-sprintf_symbol-to-%ps.patch fs-proc-basec-kernel-latencytopc-convert-sprintf_symbol-to-%ps-checkpatch-fixes.patch proc-use-unsigned-long-inside-proc-statm.patch proc-use-seq_puts-seq_putc-where-possible.patch proc-low_ino-cleanup.patch proc-use-single_open-correctly.patch exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch rapidio-use-common-destid-storage-for-endpoints-and-switches.patch rapidio-integrate-rio_switch-into-rio_dev.patch rapidio-add-definitions-of-component-tag-fields.patch rapidio-add-device-object-linking-into-discovery.patch rapidio-use-component-tag-for-unified-switch-identification.patch rapidio-add-new-idt-srio-switches.patch rapidio-add-new-sysfs-attributes.patch sysctl-fix-ifdef-guard-comment.patch sysctl-remove-obsolete-comments.patch sysctl-remove-obsolete-comments-fix.patch user_ns-improve-the-user_ns-on-the-slab-packaging.patch user_ns-improve-the-user_ns-on-the-slab-packaging-fix.patch fs-execc-provide-the-correct-process-pid-to-the-pipe-helper.patch nfc-driver-for-nxp-semiconductors-pn544-nfc-chip.patch nfc-driver-for-nxp-semiconductors-pn544-nfc-chip-update.patch remove-dma64_addr_t.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-make-idr-lock-a-mutex-and-protect-idr_pre_get.patch pps-use-bug_on-for-kernel-api-safety-checks.patch pps-simplify-conditions-a-bit.patch pps-timestamp-is-always-passed-to-dcd_change.patch ntp-add-hardpps-implementation.patch ntp-add-hardpps-implementation-update-v7.patch pps-capture-monotonic_raw-timestamps-as-well.patch pps-capture-monotonic_raw-timestamps-as-well-v7.patch pps-add-kernel-consumer-support.patch pps-add-kernel-consumer-support-v7.patch pps-add-parallel-port-pps-client.patch pps-add-parallel-port-pps-client-v7.patch pps-add-parallel-port-pps-signal-generator.patch pps-add-parallel-port-pps-signal-generator-fix.patch pps-add-parallel-port-pps-signal-generator-v7.patch memstick-core-fix-device_register-error-handling.patch memstick-fix-setup-for-jmicron-38x-controllers.patch memstick-set-pmos-values-propery-for-jmicron-38x-controllers.patch memstick-add-support-for-jmicron-jmb-385-and-390-controllers.patch memstick-avert-possible-race-condition-between-idr_pre_get-and-idr_get_new.patch memstick-remove-mspro_block_mutex.patch memstick-factor-out-transfer-initiating-functionality-in-mspro_blockc.patch memstick-add-support-for-mspro-specific-data-transfer-method.patch w1-ds2423-counter-driver-and-documentation.patch w1-ds2423-counter-driver-and-documentation-fix.patch vmware-balloon-stop-locking-pages-when-hypervisor-tells-us-enough.patch cramfs-hide-function-prototypes-behind-__kernel__-macro.patch romfs-have-romfs_fsh-pull-in-necessary-headers.patch decompressors-add-missing-init-ie-__init.patch decompressors-get-rid-of-set_error_fn-macro.patch decompressors-include-linux-slabh-in-linux-decompress-mmh.patch decompressors-remove-unused-function-from-lib-decompress_unlzmac.patch decompressors-fix-header-validation-in-decompress_unlzmac.patch decompressors-check-for-read-errors-in-decompress_unlzmac.patch decompressors-check-for-write-errors-in-decompress_unlzmac.patch decompressors-validate-match-distance-in-decompress_unlzmac.patch decompressors-check-for-write-errors-in-decompress_unlzoc.patch decompressors-check-input-size-in-decompress_unlzoc.patch decompressors-fix-callback-to-callback-mode-in-decompress_unlzoc.patch decompressors-add-xz-decompressor-module.patch decompressors-add-boot-time-xz-support.patch decompressors-add-boot-time-xz-support-update.patch x86-support-xz-compressed-kernel.patch bitops-merge-little-and-big-endian-definisions-in-asm-generic-bitops-leh.patch bitops-rename-generic-little-endian-bitops-functions.patch s390-introduce-little-endian-bitops.patch arm-introduce-little-endian-bitops.patch m68k-introduce-little-endian-bitops.patch bitops-introduce-config_generic_find_le_bit.patch m68knommu-introduce-little-endian-bitops.patch m68knommu-introduce-little-endian-bitops-build-fix.patch bitops-introduce-little-endian-bitops-for-most-architectures.patch rds-stop-including-asm-generic-bitops-leh.patch kvm-stop-including-asm-generic-bitops-leh.patch asm-generic-use-little-endian-bitops.patch ext3-use-little-endian-bitops.patch ext4-use-little-endian-bitops.patch ocfs2-use-little-endian-bitops.patch nilfs2-use-little-endian-bitops.patch reiserfs-use-little-endian-bitops.patch udf-use-little-endian-bitops.patch ufs-use-little-endian-bitops.patch md-use-little-endian-bit-operations.patch dm-use-little-endian-bit-operations.patch bitops-remove-ext2-non-atomic-bitops-from-asm-bitopsh.patch m68k-remove-inline-asm-from-minix_find_first_zero_bit.patch bitops-remove-minix-bitops-from-asm-bitopsh.patch bitops-use-find_first_zero_bit-instead-of-find_next_zero_bitaddr-size-0.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 memblock-add-input-size-checking-to-memblock_find_region.patch memblock-add-input-size-checking-to-memblock_find_region-fix.patch -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: mmotm 2010-12-23-16-58 uploaded 2010-12-24 0:58 ` akpm @ 2010-12-24 12:15 ` Sedat Dilek -1 siblings, 0 replies; 45+ messages in thread From: Sedat Dilek @ 2010-12-24 12:15 UTC (permalink / raw) To: akpm; +Cc: mm-commits, linux-kernel, linux-mm, linux-fsdevel On Fri, Dec 24, 2010 at 1:58 AM, <akpm@linux-foundation.org> wrote: > The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > http://userweb.kernel.org/~akpm/mmotm/ > > and will soon be available at > > git://zen-kernel.org/kernel/mmotm.git > The readme in [1] lists a wrong browseable GIT-repo URL: "Alternatively, these patches are available in a git repository at git: git://zen-kernel.org/kernel/mmotm.git gitweb: http://git.zen-kernel.org/?p=kernel/mmotm.git;a=summary" Correct would be [2]: gitweb: http://git.zen-kernel.org/mmotm/ > It contains the following patches against 2.6.37-rc7: > [...] > linux-next-git-rejects.patch Hm, the content of this patch looks a bit strange. Is that a post-cleanup patch to linux-next merge? - Sedat - [1] http://userweb.kernel.org/~akpm/mmotm/mmotm-readme.txt [2] http://git.zen-kernel.org/mmotm/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: mmotm 2010-12-23-16-58 uploaded @ 2010-12-24 12:15 ` Sedat Dilek 0 siblings, 0 replies; 45+ messages in thread From: Sedat Dilek @ 2010-12-24 12:15 UTC (permalink / raw) To: akpm; +Cc: mm-commits, linux-kernel, linux-mm, linux-fsdevel On Fri, Dec 24, 2010 at 1:58 AM, <akpm@linux-foundation.org> wrote: > The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > http://userweb.kernel.org/~akpm/mmotm/ > > and will soon be available at > > git://zen-kernel.org/kernel/mmotm.git > The readme in [1] lists a wrong browseable GIT-repo URL: "Alternatively, these patches are available in a git repository at git: git://zen-kernel.org/kernel/mmotm.git gitweb: http://git.zen-kernel.org/?p=kernel/mmotm.git;a=summary" Correct would be [2]: gitweb: http://git.zen-kernel.org/mmotm/ > It contains the following patches against 2.6.37-rc7: > [...] > linux-next-git-rejects.patch Hm, the content of this patch looks a bit strange. Is that a post-cleanup patch to linux-next merge? - Sedat - [1] http://userweb.kernel.org/~akpm/mmotm/mmotm-readme.txt [2] http://git.zen-kernel.org/mmotm/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: mmotm 2010-12-23-16-58 uploaded 2010-12-24 12:15 ` Sedat Dilek @ 2010-12-24 13:04 ` Andrew Morton -1 siblings, 0 replies; 45+ messages in thread From: Andrew Morton @ 2010-12-24 13:04 UTC (permalink / raw) To: sedat.dilek; +Cc: Sedat Dilek, linux-kernel, linux-mm, linux-fsdevel On Fri, 24 Dec 2010 13:15:26 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Fri, Dec 24, 2010 at 1:58 AM, <akpm@linux-foundation.org> wrote: > > The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > > > __ http://userweb.kernel.org/~akpm/mmotm/ > > > > and will soon be available at > > > > __ git://zen-kernel.org/kernel/mmotm.git > > > > The readme in [1] lists a wrong browseable GIT-repo URL: > > "Alternatively, these patches are available in a git repository at > > git: git://zen-kernel.org/kernel/mmotm.git > gitweb: http://git.zen-kernel.org/?p=kernel/mmotm.git;a=summary" > > Correct would be [2]: > > gitweb: http://git.zen-kernel.org/mmotm/ hm, thanks. The darn thing keeps moving around. > > It contains the following patches against 2.6.37-rc7: > > > [...] > > linux-next-git-rejects.patch > > Hm, the content of this patch looks a bit strange. > Is that a post-cleanup patch to linux-next merge? Yes. It's caused by skew between Linus's tree and linux-next. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: mmotm 2010-12-23-16-58 uploaded @ 2010-12-24 13:04 ` Andrew Morton 0 siblings, 0 replies; 45+ messages in thread From: Andrew Morton @ 2010-12-24 13:04 UTC (permalink / raw) To: sedat.dilek; +Cc: Sedat Dilek, linux-kernel, linux-mm, linux-fsdevel On Fri, 24 Dec 2010 13:15:26 +0100 Sedat Dilek <sedat.dilek@googlemail.com> wrote: > On Fri, Dec 24, 2010 at 1:58 AM, <akpm@linux-foundation.org> wrote: > > The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > > > __ http://userweb.kernel.org/~akpm/mmotm/ > > > > and will soon be available at > > > > __ git://zen-kernel.org/kernel/mmotm.git > > > > The readme in [1] lists a wrong browseable GIT-repo URL: > > "Alternatively, these patches are available in a git repository at > > git: git://zen-kernel.org/kernel/mmotm.git > gitweb: http://git.zen-kernel.org/?p=kernel/mmotm.git;a=summary" > > Correct would be [2]: > > gitweb: http://git.zen-kernel.org/mmotm/ hm, thanks. The darn thing keeps moving around. > > It contains the following patches against 2.6.37-rc7: > > > [...] > > linux-next-git-rejects.patch > > Hm, the content of this patch looks a bit strange. > Is that a post-cleanup patch to linux-next merge? Yes. It's caused by skew between Linus's tree and linux-next. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH -mmotm] kptr_restrict: fix build when PRINTK not enabled 2010-12-24 0:58 ` akpm @ 2010-12-24 17:52 ` Randy Dunlap -1 siblings, 0 replies; 45+ messages in thread From: Randy Dunlap @ 2010-12-24 17:52 UTC (permalink / raw) To: akpm, Dan Rosenberg; +Cc: linux-kernel, linux-mm, linux-fsdevel From: Randy Dunlap <randy.dunlap@oracle.com> #include <linux/printk.h> since that is where kptr_restrict is externed. Put kptr_restrict inside #ifdef CONFIG_PRINTK block to fix build error when CONFIG_PRINTK is not enabled: kernel/sysctl.c:712: error: 'kptr_restrict' undeclared here (not in a function) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Dan Rosenberg <drosenberg@vsecurity.com> --- kernel/sysctl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- mmotm-2010-1223-1658.orig/kernel/sysctl.c +++ mmotm-2010-1223-1658/kernel/sysctl.c @@ -24,6 +24,7 @@ #include <linux/slab.h> #include <linux/sysctl.h> #include <linux/signal.h> +#include <linux/printk.h> #include <linux/proc_fs.h> #include <linux/security.h> #include <linux/ctype.h> @@ -706,7 +707,6 @@ static struct ctl_table kern_table[] = { .extra1 = &zero, .extra2 = &one, }, -#endif { .procname = "kptr_restrict", .data = &kptr_restrict, @@ -716,6 +716,7 @@ static struct ctl_table kern_table[] = { .extra1 = &zero, .extra2 = &two, }, +#endif { .procname = "ngroups_max", .data = &ngroups_max, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH -mmotm] kptr_restrict: fix build when PRINTK not enabled @ 2010-12-24 17:52 ` Randy Dunlap 0 siblings, 0 replies; 45+ messages in thread From: Randy Dunlap @ 2010-12-24 17:52 UTC (permalink / raw) To: akpm, Dan Rosenberg; +Cc: linux-kernel, linux-mm, linux-fsdevel From: Randy Dunlap <randy.dunlap@oracle.com> #include <linux/printk.h> since that is where kptr_restrict is externed. Put kptr_restrict inside #ifdef CONFIG_PRINTK block to fix build error when CONFIG_PRINTK is not enabled: kernel/sysctl.c:712: error: 'kptr_restrict' undeclared here (not in a function) Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Dan Rosenberg <drosenberg@vsecurity.com> --- kernel/sysctl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- mmotm-2010-1223-1658.orig/kernel/sysctl.c +++ mmotm-2010-1223-1658/kernel/sysctl.c @@ -24,6 +24,7 @@ #include <linux/slab.h> #include <linux/sysctl.h> #include <linux/signal.h> +#include <linux/printk.h> #include <linux/proc_fs.h> #include <linux/security.h> #include <linux/ctype.h> @@ -706,7 +707,6 @@ static struct ctl_table kern_table[] = { .extra1 = &zero, .extra2 = &one, }, -#endif { .procname = "kptr_restrict", .data = &kptr_restrict, @@ -716,6 +716,7 @@ static struct ctl_table kern_table[] = { .extra1 = &zero, .extra2 = &two, }, +#endif { .procname = "ngroups_max", .data = &ngroups_max, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: mmotm 2010-12-23-16-58 uploaded 2010-12-24 0:58 ` akpm @ 2010-12-27 2:13 ` Randy Dunlap -1 siblings, 0 replies; 45+ messages in thread From: Randy Dunlap @ 2010-12-27 2:13 UTC (permalink / raw) To: linux-kernel, Alex Dubov; +Cc: akpm, linux-mm, linux-fsdevel On Thu, 23 Dec 2010 16:58:58 -0800 akpm@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2010-12-23-16-58 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.37-rc7: > memstick-factor-out-transfer-initiating-functionality-in-mspro_blockc.patch drivers/memstick/core/mspro_block.c:1090: warning: format '%x' expects type 'unsigned int', but argument 7 has type 'size_t' change "size %x" to "size %zx" --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/ ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: mmotm 2010-12-23-16-58 uploaded @ 2010-12-27 2:13 ` Randy Dunlap 0 siblings, 0 replies; 45+ messages in thread From: Randy Dunlap @ 2010-12-27 2:13 UTC (permalink / raw) To: linux-kernel, Alex Dubov; +Cc: akpm, linux-mm, linux-fsdevel On Thu, 23 Dec 2010 16:58:58 -0800 akpm@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2010-12-23-16-58 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.37-rc7: > memstick-factor-out-transfer-initiating-functionality-in-mspro_blockc.patch drivers/memstick/core/mspro_block.c:1090: warning: format '%x' expects type 'unsigned int', but argument 7 has type 'size_t' change "size %x" to "size %zx" --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** desserts: http://www.xenotime.net/linux/recipes/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 45+ messages in thread
* suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2010-12-24 0:58 ` akpm ` (3 preceding siblings ...) (?) @ 2011-01-04 13:40 ` Jiri Slaby -1 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-04 13:40 UTC (permalink / raw) To: akpm; +Cc: Linux-pm mailing list, mm-commits, LKML On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to Hi, this kernel regresses with respect to suspend to ram in comparison with mmotm 2010-12-16-14-56. This is OK: echo devices > /sys/power/pm_test pm-suspend This hangs at suspend phase: echo platform > /sys/power/pm_test pm-suspend Note that this kernel is based on next-20101221. Should I try newer (and clean) -next? regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2010-12-24 0:58 ` akpm ` (4 preceding siblings ...) (?) @ 2011-01-04 13:40 ` Jiri Slaby 2011-01-04 16:49 ` Jiri Slaby 2011-01-04 16:49 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby -1 siblings, 2 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-04 13:40 UTC (permalink / raw) To: akpm; +Cc: mm-commits, LKML, Rafael J. Wysocki, Linux-pm mailing list On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to Hi, this kernel regresses with respect to suspend to ram in comparison with mmotm 2010-12-16-14-56. This is OK: echo devices > /sys/power/pm_test pm-suspend This hangs at suspend phase: echo platform > /sys/power/pm_test pm-suspend Note that this kernel is based on next-20101221. Should I try newer (and clean) -next? regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 13:40 ` Jiri Slaby @ 2011-01-04 16:49 ` Jiri Slaby 2011-01-04 22:57 ` Rafael J. Wysocki ` (3 more replies) 2011-01-04 16:49 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby 1 sibling, 4 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-04 16:49 UTC (permalink / raw) To: akpm Cc: mm-commits, LKML, Rafael J. Wysocki, Linux-pm mailing list, Brown, Len, steiner On 01/04/2011 02:40 PM, Jiri Slaby wrote: > On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: >> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > Hi, this kernel regresses with respect to suspend to ram in comparison > with mmotm 2010-12-16-14-56. > > This is OK: > echo devices > /sys/power/pm_test > pm-suspend > This hangs at suspend phase: > echo platform > /sys/power/pm_test > pm-suspend > > Note that this kernel is based on next-20101221. Should I try newer (and > clean) -next? Ok, bisected down to: 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e Author: Len Brown <len.brown@intel.com> Date: Thu Dec 16 23:12:23 2010 -0500 ACPI: use ioremap_cache() Although the temporary boot-time ACPI table mappings were set up with CPU caching enabled, the permanent table mappings and AML run-time region memory accesses were set up with ioremap(), which on x86 is a synonym for ioremap_nocache(). Changing this to ioremap_cache() improves performance as seen when accessing the tables via acpidump, or /sys/firmware/acpi/tables. It should also improve AML run-time performance. No change on ia64. Reported-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Len Brown <len.brown@intel.com> :040000 040000 be35c5e8f214f10f94688c1a27f33ecfb8505220 52581222d0edf190f160f3e5aa5d2c1af8e76988 M arch :040000 040000 ccdca0d41938b8312e946cde3c01c59b32d1c17c 96ccf2357f2ac4a31d19cc41f5728d9f87b6cac0 M drivers Revert of that patch fixes the problem. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 16:49 ` Jiri Slaby @ 2011-01-04 22:57 ` Rafael J. Wysocki 2011-01-05 21:36 ` Jiri Slaby 2011-01-05 21:36 ` Jiri Slaby 2011-01-04 22:57 ` Rafael J. Wysocki ` (2 subsequent siblings) 3 siblings, 2 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-04 22:57 UTC (permalink / raw) To: Jiri Slaby Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On Tuesday, January 04, 2011, Jiri Slaby wrote: > On 01/04/2011 02:40 PM, Jiri Slaby wrote: > > On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > >> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > > > Hi, this kernel regresses with respect to suspend to ram in comparison > > with mmotm 2010-12-16-14-56. > > > > This is OK: > > echo devices > /sys/power/pm_test > > pm-suspend > > This hangs at suspend phase: > > echo platform > /sys/power/pm_test > > pm-suspend Hmm. So it looks like _PTS hangs? > > Note that this kernel is based on next-20101221. Should I try newer (and > > clean) -next? > > Ok, bisected down to: > 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit > commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e > Author: Len Brown <len.brown@intel.com> > Date: Thu Dec 16 23:12:23 2010 -0500 > > ACPI: use ioremap_cache() > > Although the temporary boot-time ACPI table mappings > were set up with CPU caching enabled, the permanent table > mappings and AML run-time region memory accesses were > set up with ioremap(), which on x86 is a synonym for > ioremap_nocache(). > > Changing this to ioremap_cache() improves performance as > seen when accessing the tables via acpidump, > or /sys/firmware/acpi/tables. It should also improve > AML run-time performance. > > No change on ia64. > > Reported-by: Jack Steiner <steiner@sgi.com> > Signed-off-by: Len Brown <len.brown@intel.com> > > :040000 040000 be35c5e8f214f10f94688c1a27f33ecfb8505220 > 52581222d0edf190f160f3e5aa5d2c1af8e76988 M arch > :040000 040000 ccdca0d41938b8312e946cde3c01c59b32d1c17c > 96ccf2357f2ac4a31d19cc41f5728d9f87b6cac0 M drivers > > Revert of that patch fixes the problem. Can you send a dmesg output and acpidump output from the failing system, please? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 22:57 ` Rafael J. Wysocki @ 2011-01-05 21:36 ` Jiri Slaby 2011-01-05 21:36 ` Jiri Slaby 1 sibling, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-05 21:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > On Tuesday, January 04, 2011, Jiri Slaby wrote: >> On 01/04/2011 02:40 PM, Jiri Slaby wrote: >>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: >>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to >>> >>> Hi, this kernel regresses with respect to suspend to ram in comparison >>> with mmotm 2010-12-16-14-56. >>> >>> This is OK: >>> echo devices > /sys/power/pm_test >>> pm-suspend >>> This hangs at suspend phase: >>> echo platform > /sys/power/pm_test >>> pm-suspend > > Hmm. So it looks like _PTS hangs? No _PST here :). >>> Note that this kernel is based on next-20101221. Should I try newer (and >>> clean) -next? >> >> Ok, bisected down to: >> 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit >> commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e ... >> Revert of that patch fixes the problem. > > Can you send a dmesg output and acpidump output from the failing system, please? Here they are: http://www.fi.muni.cz/~xslaby/sklad/panics/dmesg-no-susp.txt http://www.fi.muni.cz/~xslaby/sklad/adump.txt They are captured from the mmotm minus 16dc39c98a6ca56 if that's OK? Ignore the BUG there, it's caused by qemu and fixed in later -next. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 22:57 ` Rafael J. Wysocki 2011-01-05 21:36 ` Jiri Slaby @ 2011-01-05 21:36 ` Jiri Slaby 2011-01-05 22:39 ` Rafael J. Wysocki 2011-01-05 22:39 ` Rafael J. Wysocki 1 sibling, 2 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-05 21:36 UTC (permalink / raw) To: Rafael J. Wysocki Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > On Tuesday, January 04, 2011, Jiri Slaby wrote: >> On 01/04/2011 02:40 PM, Jiri Slaby wrote: >>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: >>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to >>> >>> Hi, this kernel regresses with respect to suspend to ram in comparison >>> with mmotm 2010-12-16-14-56. >>> >>> This is OK: >>> echo devices > /sys/power/pm_test >>> pm-suspend >>> This hangs at suspend phase: >>> echo platform > /sys/power/pm_test >>> pm-suspend > > Hmm. So it looks like _PTS hangs? No _PST here :). >>> Note that this kernel is based on next-20101221. Should I try newer (and >>> clean) -next? >> >> Ok, bisected down to: >> 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit >> commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e ... >> Revert of that patch fixes the problem. > > Can you send a dmesg output and acpidump output from the failing system, please? Here they are: http://www.fi.muni.cz/~xslaby/sklad/panics/dmesg-no-susp.txt http://www.fi.muni.cz/~xslaby/sklad/adump.txt They are captured from the mmotm minus 16dc39c98a6ca56 if that's OK? Ignore the BUG there, it's caused by qemu and fixed in later -next. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 21:36 ` Jiri Slaby @ 2011-01-05 22:39 ` Rafael J. Wysocki 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 22:39 ` Rafael J. Wysocki 1 sibling, 2 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-05 22:39 UTC (permalink / raw) To: Jiri Slaby Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On Wednesday, January 05, 2011, Jiri Slaby wrote: > On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > > On Tuesday, January 04, 2011, Jiri Slaby wrote: > >> On 01/04/2011 02:40 PM, Jiri Slaby wrote: > >>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > >>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > >>> > >>> Hi, this kernel regresses with respect to suspend to ram in comparison > >>> with mmotm 2010-12-16-14-56. > >>> > >>> This is OK: > >>> echo devices > /sys/power/pm_test > >>> pm-suspend > >>> This hangs at suspend phase: > >>> echo platform > /sys/power/pm_test > >>> pm-suspend > > > > Hmm. So it looks like _PTS hangs? > > No _PST here :). I really meant _PTS and yes, there is one and it does quite a lot of interesting stuff. Are you able to collect serial console (or equivalent) logs from that machine? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 22:39 ` Rafael J. Wysocki @ 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 22:46 ` Jiri Slaby 1 sibling, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-05 22:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On 01/05/2011 11:39 PM, Rafael J. Wysocki wrote: > On Wednesday, January 05, 2011, Jiri Slaby wrote: >> On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: >>> On Tuesday, January 04, 2011, Jiri Slaby wrote: >>>> On 01/04/2011 02:40 PM, Jiri Slaby wrote: >>>>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: >>>>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to >>>>> >>>>> Hi, this kernel regresses with respect to suspend to ram in comparison >>>>> with mmotm 2010-12-16-14-56. >>>>> >>>>> This is OK: >>>>> echo devices > /sys/power/pm_test >>>>> pm-suspend >>>>> This hangs at suspend phase: >>>>> echo platform > /sys/power/pm_test >>>>> pm-suspend >>> >>> Hmm. So it looks like _PTS hangs? >> >> No _PST here :). > > I really meant _PTS and yes, there is one and it does quite a lot of > interesting stuff. Yeah, I grepped for _PTS, but in a wrong file. My bad. > Are you able to collect serial console (or equivalent) logs from that machine? Unfortunately I don't have a second machine with serial port. What exactly you want to dig out of the logs? Will netconsole work at that phase? regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 22:39 ` Rafael J. Wysocki 2011-01-05 22:46 ` Jiri Slaby @ 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-05 23:28 ` Rafael J. Wysocki 1 sibling, 2 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-05 22:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On 01/05/2011 11:39 PM, Rafael J. Wysocki wrote: > On Wednesday, January 05, 2011, Jiri Slaby wrote: >> On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: >>> On Tuesday, January 04, 2011, Jiri Slaby wrote: >>>> On 01/04/2011 02:40 PM, Jiri Slaby wrote: >>>>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: >>>>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to >>>>> >>>>> Hi, this kernel regresses with respect to suspend to ram in comparison >>>>> with mmotm 2010-12-16-14-56. >>>>> >>>>> This is OK: >>>>> echo devices > /sys/power/pm_test >>>>> pm-suspend >>>>> This hangs at suspend phase: >>>>> echo platform > /sys/power/pm_test >>>>> pm-suspend >>> >>> Hmm. So it looks like _PTS hangs? >> >> No _PST here :). > > I really meant _PTS and yes, there is one and it does quite a lot of > interesting stuff. Yeah, I grepped for _PTS, but in a wrong file. My bad. > Are you able to collect serial console (or equivalent) logs from that machine? Unfortunately I don't have a second machine with serial port. What exactly you want to dig out of the logs? Will netconsole work at that phase? regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 22:46 ` Jiri Slaby @ 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-05 23:28 ` Rafael J. Wysocki 1 sibling, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-05 23:28 UTC (permalink / raw) To: Jiri Slaby Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On Wednesday, January 05, 2011, Jiri Slaby wrote: > On 01/05/2011 11:39 PM, Rafael J. Wysocki wrote: > > On Wednesday, January 05, 2011, Jiri Slaby wrote: > >> On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > >>> On Tuesday, January 04, 2011, Jiri Slaby wrote: > >>>> On 01/04/2011 02:40 PM, Jiri Slaby wrote: > >>>>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > >>>>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > >>>>> > >>>>> Hi, this kernel regresses with respect to suspend to ram in comparison > >>>>> with mmotm 2010-12-16-14-56. > >>>>> > >>>>> This is OK: > >>>>> echo devices > /sys/power/pm_test > >>>>> pm-suspend > >>>>> This hangs at suspend phase: > >>>>> echo platform > /sys/power/pm_test > >>>>> pm-suspend > >>> > >>> Hmm. So it looks like _PTS hangs? > >> > >> No _PST here :). > > > > I really meant _PTS and yes, there is one and it does quite a lot of > > interesting stuff. > > Yeah, I grepped for _PTS, but in a wrong file. My bad. > > > Are you able to collect serial console (or equivalent) logs from that machine? > > Unfortunately I don't have a second machine with serial port. What > exactly you want to dig out of the logs? Will netconsole work at that phase? I don't think so, the adapter will have been already suspended. Hmm. I guess you can boot with no_console_suspend in the kernel command line and use the video console to get some debug info. At this point we would like to know where exactly it hangs, so you'd need to enable AML tracing in the kernel and basically see what's printed last. :-) Two more questions: (1) Does the failing machine power off correctly with the kernel that fails to suspend? (2) Is the failing suspend behavior reproducible if you run "echo disk > /sys/power/state" instead of "pm-suspend" in the platform test? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 23:28 ` Rafael J. Wysocki @ 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby ` (2 more replies) 1 sibling, 3 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-05 23:28 UTC (permalink / raw) To: Jiri Slaby Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On Wednesday, January 05, 2011, Jiri Slaby wrote: > On 01/05/2011 11:39 PM, Rafael J. Wysocki wrote: > > On Wednesday, January 05, 2011, Jiri Slaby wrote: > >> On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > >>> On Tuesday, January 04, 2011, Jiri Slaby wrote: > >>>> On 01/04/2011 02:40 PM, Jiri Slaby wrote: > >>>>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > >>>>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > >>>>> > >>>>> Hi, this kernel regresses with respect to suspend to ram in comparison > >>>>> with mmotm 2010-12-16-14-56. > >>>>> > >>>>> This is OK: > >>>>> echo devices > /sys/power/pm_test > >>>>> pm-suspend > >>>>> This hangs at suspend phase: > >>>>> echo platform > /sys/power/pm_test > >>>>> pm-suspend > >>> > >>> Hmm. So it looks like _PTS hangs? > >> > >> No _PST here :). > > > > I really meant _PTS and yes, there is one and it does quite a lot of > > interesting stuff. > > Yeah, I grepped for _PTS, but in a wrong file. My bad. > > > Are you able to collect serial console (or equivalent) logs from that machine? > > Unfortunately I don't have a second machine with serial port. What > exactly you want to dig out of the logs? Will netconsole work at that phase? I don't think so, the adapter will have been already suspended. Hmm. I guess you can boot with no_console_suspend in the kernel command line and use the video console to get some debug info. At this point we would like to know where exactly it hangs, so you'd need to enable AML tracing in the kernel and basically see what's printed last. :-) Two more questions: (1) Does the failing machine power off correctly with the kernel that fails to suspend? (2) Is the failing suspend behavior reproducible if you run "echo disk > /sys/power/state" instead of "pm-suspend" in the platform test? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-05 23:28 ` Rafael J. Wysocki @ 2011-01-06 9:18 ` Jiri Slaby 2011-01-06 9:31 ` Jiri Slaby ` (2 more replies) 2011-01-06 9:24 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby 2011-01-06 9:24 ` Jiri Slaby 2 siblings, 3 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 9:18 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: akpm, linux-kernel, jirislaby When ioremap fails (which might happen for some reason), we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in there. Fail gracefully instead. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> --- drivers/acpi/sleep.c | 5 ++--- include/linux/suspend.h | 4 ++-- kernel/power/nvs.c | 8 +++++++- 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c index c423231..f94c9a9 100644 --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) static int acpi_pm_pre_suspend(void) { acpi_pm_freeze(); - suspend_nvs_save(); - return 0; + return suspend_nvs_save(); } /** @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) { int error = __acpi_pm_prepare(); if (!error) - acpi_pm_pre_suspend(); + error = acpi_pm_pre_suspend(); return error; } diff --git a/include/linux/suspend.h b/include/linux/suspend.h index c1f4998..3ac2551 100644 --- a/include/linux/suspend.h +++ b/include/linux/suspend.h @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } extern int suspend_nvs_register(unsigned long start, unsigned long size); extern int suspend_nvs_alloc(void); extern void suspend_nvs_free(void); -extern void suspend_nvs_save(void); +extern int suspend_nvs_save(void); extern void suspend_nvs_restore(void); #else /* CONFIG_SUSPEND_NVS */ static inline int suspend_nvs_register(unsigned long a, unsigned long b) @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) } static inline int suspend_nvs_alloc(void) { return 0; } static inline void suspend_nvs_free(void) {} -static inline void suspend_nvs_save(void) {} +static inline int suspend_nvs_save(void) {} static inline void suspend_nvs_restore(void) {} #endif /* CONFIG_SUSPEND_NVS */ diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c index 1836db6..57c6fab 100644 --- a/kernel/power/nvs.c +++ b/kernel/power/nvs.c @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) /** * suspend_nvs_save - save NVS memory regions */ -void suspend_nvs_save(void) +int suspend_nvs_save(void) { struct nvs_page *entry; @@ -114,8 +114,14 @@ void suspend_nvs_save(void) list_for_each_entry(entry, &nvs_list, node) if (entry->data) { entry->kaddr = ioremap(entry->phys_start, entry->size); + if (!entry->kaddr) { + suspend_nvs_free(); + return -ENOMEM; + } memcpy(entry->data, entry->kaddr, entry->size); } + + return 0; } /** -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby @ 2011-01-06 9:31 ` Jiri Slaby 2011-01-06 15:57 ` Rafael J. Wysocki 2011-01-06 15:57 ` Rafael J. Wysocki 2 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 9:31 UTC (permalink / raw) To: Jiri Slaby; +Cc: Rafael J. Wysocki, akpm, linux-kernel On 01/06/2011 10:18 AM, Jiri Slaby wrote: > When ioremap fails (which might happen for some reason), we nicely > oops in suspend_nvs_save due to NULL dereference by memcpy in there. > Fail gracefully instead. > > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > Cc: "Rafael J. Wysocki" <rjw@sisk.pl> > --- Just to note, I'm not 100% sure whether the fail paths are OK with this patch. But it works for me. So it needs an ACK from Rafael or whoever wrote/understand the code. > drivers/acpi/sleep.c | 5 ++--- > include/linux/suspend.h | 4 ++-- > kernel/power/nvs.c | 8 +++++++- > 3 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > index c423231..f94c9a9 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) > static int acpi_pm_pre_suspend(void) > { > acpi_pm_freeze(); > - suspend_nvs_save(); > - return 0; > + return suspend_nvs_save(); > } > > /** > @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) > { > int error = __acpi_pm_prepare(); > if (!error) > - acpi_pm_pre_suspend(); > + error = acpi_pm_pre_suspend(); > > return error; > } > diff --git a/include/linux/suspend.h b/include/linux/suspend.h > index c1f4998..3ac2551 100644 > --- a/include/linux/suspend.h > +++ b/include/linux/suspend.h > @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } > extern int suspend_nvs_register(unsigned long start, unsigned long size); > extern int suspend_nvs_alloc(void); > extern void suspend_nvs_free(void); > -extern void suspend_nvs_save(void); > +extern int suspend_nvs_save(void); > extern void suspend_nvs_restore(void); > #else /* CONFIG_SUSPEND_NVS */ > static inline int suspend_nvs_register(unsigned long a, unsigned long b) > @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) > } > static inline int suspend_nvs_alloc(void) { return 0; } > static inline void suspend_nvs_free(void) {} > -static inline void suspend_nvs_save(void) {} > +static inline int suspend_nvs_save(void) {} > static inline void suspend_nvs_restore(void) {} > #endif /* CONFIG_SUSPEND_NVS */ > > diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c > index 1836db6..57c6fab 100644 > --- a/kernel/power/nvs.c > +++ b/kernel/power/nvs.c > @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) > /** > * suspend_nvs_save - save NVS memory regions > */ > -void suspend_nvs_save(void) > +int suspend_nvs_save(void) > { > struct nvs_page *entry; > > @@ -114,8 +114,14 @@ void suspend_nvs_save(void) > list_for_each_entry(entry, &nvs_list, node) > if (entry->data) { > entry->kaddr = ioremap(entry->phys_start, entry->size); > + if (!entry->kaddr) { > + suspend_nvs_free(); > + return -ENOMEM; > + } > memcpy(entry->data, entry->kaddr, entry->size); > } > + > + return 0; > } > > /** -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby 2011-01-06 9:31 ` Jiri Slaby @ 2011-01-06 15:57 ` Rafael J. Wysocki 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 15:57 ` Rafael J. Wysocki 2 siblings, 2 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-06 15:57 UTC (permalink / raw) To: Jiri Slaby Cc: akpm, linux-kernel, jirislaby, ACPI Devel Maling List, Linux-pm mailing list, Matthew Garrett, Len Brown On Thursday, January 06, 2011, Jiri Slaby wrote: > When ioremap fails (which might happen for some reason), If it happens, something is seriously wrong (see below). BTW, to keep things in context, please post fixes like this in the same thread in which you reported the problem. At lease please retain the CC list from there. > we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in > there. Fail gracefully instead. > > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > Cc: "Rafael J. Wysocki" <rjw@sisk.pl> > --- > drivers/acpi/sleep.c | 5 ++--- > include/linux/suspend.h | 4 ++-- > kernel/power/nvs.c | 8 +++++++- > 3 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > index c423231..f94c9a9 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) > static int acpi_pm_pre_suspend(void) > { > acpi_pm_freeze(); > - suspend_nvs_save(); > - return 0; > + return suspend_nvs_save(); > } > > /** > @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) > { > int error = __acpi_pm_prepare(); > if (!error) > - acpi_pm_pre_suspend(); > + error = acpi_pm_pre_suspend(); > > return error; > } > diff --git a/include/linux/suspend.h b/include/linux/suspend.h > index c1f4998..3ac2551 100644 > --- a/include/linux/suspend.h > +++ b/include/linux/suspend.h > @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } > extern int suspend_nvs_register(unsigned long start, unsigned long size); > extern int suspend_nvs_alloc(void); > extern void suspend_nvs_free(void); > -extern void suspend_nvs_save(void); > +extern int suspend_nvs_save(void); > extern void suspend_nvs_restore(void); > #else /* CONFIG_SUSPEND_NVS */ > static inline int suspend_nvs_register(unsigned long a, unsigned long b) > @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) > } > static inline int suspend_nvs_alloc(void) { return 0; } > static inline void suspend_nvs_free(void) {} > -static inline void suspend_nvs_save(void) {} > +static inline int suspend_nvs_save(void) {} > static inline void suspend_nvs_restore(void) {} > #endif /* CONFIG_SUSPEND_NVS */ > > diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c > index 1836db6..57c6fab 100644 > --- a/kernel/power/nvs.c > +++ b/kernel/power/nvs.c > @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) > /** > * suspend_nvs_save - save NVS memory regions > */ > -void suspend_nvs_save(void) > +int suspend_nvs_save(void) > { > struct nvs_page *entry; > > @@ -114,8 +114,14 @@ void suspend_nvs_save(void) > list_for_each_entry(entry, &nvs_list, node) > if (entry->data) { > entry->kaddr = ioremap(entry->phys_start, entry->size); I wonder what happens if you simply change the ioremap() here to ioremap_nocache() without any other modifications? It _really_ shouldn't fail here, because the NVS pages are known to be present. > + if (!entry->kaddr) { > + suspend_nvs_free(); > + return -ENOMEM; > + } > memcpy(entry->data, entry->kaddr, entry->size); > } > + > + return 0; > } > > /** > Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 15:57 ` Rafael J. Wysocki @ 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby ` (3 more replies) 2011-01-06 16:09 ` Jiri Slaby 1 sibling, 4 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 16:09 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jiri Slaby, akpm, linux-kernel, ACPI Devel Maling List, Linux-pm mailing list, Matthew Garrett, Len Brown On 01/06/2011 04:57 PM, Rafael J. Wysocki wrote: > On Thursday, January 06, 2011, Jiri Slaby wrote: >> When ioremap fails (which might happen for some reason), > > If it happens, something is seriously wrong (see below). I agree that something is broken, however ioremap may fail for dozen of reasons. Ignoring the retval is a *bad* idea and it took me a while to sort out what is wrong. Especially if one has no console like throughout suspend. If it was handled properly, I would know immediately. (There should be a message printed out which I forgot to add.) > BTW, to keep things in context, please post fixes like this in the same thread > in which you reported the problem. At lease please retain the CC list from > there. I actually did, there is: In-Reply-To: <201101060028.43342.rjw@sisk.pl> and it successfully threaded to the conversation for me in TB. >> we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in >> there. Fail gracefully instead. >> >> Signed-off-by: Jiri Slaby <jslaby@suse.cz> >> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> >> --- >> drivers/acpi/sleep.c | 5 ++--- >> include/linux/suspend.h | 4 ++-- >> kernel/power/nvs.c | 8 +++++++- >> 3 files changed, 11 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c >> index c423231..f94c9a9 100644 >> --- a/drivers/acpi/sleep.c >> +++ b/drivers/acpi/sleep.c >> @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) >> static int acpi_pm_pre_suspend(void) >> { >> acpi_pm_freeze(); >> - suspend_nvs_save(); >> - return 0; >> + return suspend_nvs_save(); >> } >> >> /** >> @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) >> { >> int error = __acpi_pm_prepare(); >> if (!error) >> - acpi_pm_pre_suspend(); >> + error = acpi_pm_pre_suspend(); >> >> return error; >> } >> diff --git a/include/linux/suspend.h b/include/linux/suspend.h >> index c1f4998..3ac2551 100644 >> --- a/include/linux/suspend.h >> +++ b/include/linux/suspend.h >> @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } >> extern int suspend_nvs_register(unsigned long start, unsigned long size); >> extern int suspend_nvs_alloc(void); >> extern void suspend_nvs_free(void); >> -extern void suspend_nvs_save(void); >> +extern int suspend_nvs_save(void); >> extern void suspend_nvs_restore(void); >> #else /* CONFIG_SUSPEND_NVS */ >> static inline int suspend_nvs_register(unsigned long a, unsigned long b) >> @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) >> } >> static inline int suspend_nvs_alloc(void) { return 0; } >> static inline void suspend_nvs_free(void) {} >> -static inline void suspend_nvs_save(void) {} >> +static inline int suspend_nvs_save(void) {} >> static inline void suspend_nvs_restore(void) {} >> #endif /* CONFIG_SUSPEND_NVS */ >> >> diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c >> index 1836db6..57c6fab 100644 >> --- a/kernel/power/nvs.c >> +++ b/kernel/power/nvs.c >> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) >> /** >> * suspend_nvs_save - save NVS memory regions >> */ >> -void suspend_nvs_save(void) >> +int suspend_nvs_save(void) >> { >> struct nvs_page *entry; >> >> @@ -114,8 +114,14 @@ void suspend_nvs_save(void) >> list_for_each_entry(entry, &nvs_list, node) >> if (entry->data) { >> entry->kaddr = ioremap(entry->phys_start, entry->size); > > I wonder what happens if you simply change the ioremap() here to > ioremap_nocache() without any other modifications? ioremap *is* ioremap_nocache on x86. And that's the conflict it complains about I guess? Don't you mean ioremap_cache? > It _really_ shouldn't fail here, because the NVS pages are known to be present. It fails because of conflicting maps as can be seen in the photo. At least I think so. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 16:09 ` Jiri Slaby @ 2011-01-06 16:31 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby ` (2 subsequent siblings) 3 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 16:31 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jiri Slaby, akpm, linux-kernel, ACPI Devel Maling List, Linux-pm mailing list, Matthew Garrett, Len Brown On 01/06/2011 05:09 PM, Jiri Slaby wrote: >>> --- a/kernel/power/nvs.c >>> +++ b/kernel/power/nvs.c >>> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) >>> /** >>> * suspend_nvs_save - save NVS memory regions >>> */ >>> -void suspend_nvs_save(void) >>> +int suspend_nvs_save(void) >>> { >>> struct nvs_page *entry; >>> >>> @@ -114,8 +114,14 @@ void suspend_nvs_save(void) >>> list_for_each_entry(entry, &nvs_list, node) >>> if (entry->data) { >>> entry->kaddr = ioremap(entry->phys_start, entry->size); >> >> I wonder what happens if you simply change the ioremap() here to >> ioremap_nocache() without any other modifications? > > ioremap *is* ioremap_nocache on x86. And that's the conflict it > complains about I guess? Don't you mean ioremap_cache? Using ioremap_cache indeed fixes the problem... thanks, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby @ 2011-01-06 16:31 ` Jiri Slaby 2011-01-06 16:38 ` Rafael J. Wysocki 2011-01-06 16:38 ` Rafael J. Wysocki 3 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 16:31 UTC (permalink / raw) To: Rafael J. Wysocki Cc: linux-kernel, ACPI Devel Maling List, akpm, Jiri Slaby, Linux-pm mailing list On 01/06/2011 05:09 PM, Jiri Slaby wrote: >>> --- a/kernel/power/nvs.c >>> +++ b/kernel/power/nvs.c >>> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) >>> /** >>> * suspend_nvs_save - save NVS memory regions >>> */ >>> -void suspend_nvs_save(void) >>> +int suspend_nvs_save(void) >>> { >>> struct nvs_page *entry; >>> >>> @@ -114,8 +114,14 @@ void suspend_nvs_save(void) >>> list_for_each_entry(entry, &nvs_list, node) >>> if (entry->data) { >>> entry->kaddr = ioremap(entry->phys_start, entry->size); >> >> I wonder what happens if you simply change the ioremap() here to >> ioremap_nocache() without any other modifications? > > ioremap *is* ioremap_nocache on x86. And that's the conflict it > complains about I guess? Don't you mean ioremap_cache? Using ioremap_cache indeed fixes the problem... thanks, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby @ 2011-01-06 16:38 ` Rafael J. Wysocki 2011-01-06 21:01 ` Len Brown 2011-01-06 21:01 ` Len Brown 2011-01-06 16:38 ` Rafael J. Wysocki 3 siblings, 2 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-06 16:38 UTC (permalink / raw) To: Jiri Slaby Cc: Jiri Slaby, akpm, linux-kernel, ACPI Devel Maling List, Linux-pm mailing list, Matthew Garrett, Len Brown On Thursday, January 06, 2011, Jiri Slaby wrote: > On 01/06/2011 04:57 PM, Rafael J. Wysocki wrote: > > On Thursday, January 06, 2011, Jiri Slaby wrote: > >> When ioremap fails (which might happen for some reason), > > > > If it happens, something is seriously wrong (see below). > > I agree that something is broken, however ioremap may fail for dozen of > reasons. Ignoring the retval is a *bad* idea and it took me a while to > sort out what is wrong. Especially if one has no console like throughout > suspend. If it was handled properly, I would know immediately. (There > should be a message printed out which I forgot to add.) It wasn't handled, because it _never_ failed previously. The ACPI mapping change apparently revealed a deeper problem. I'm not saying the patch isn't useful, though, and I'm going to take it for 2.6.38 (perhaps with minor modifications). > > BTW, to keep things in context, please post fixes like this in the same thread > > in which you reported the problem. At lease please retain the CC list from > > there. > > I actually did, there is: > In-Reply-To: <201101060028.43342.rjw@sisk.pl> > and it successfully threaded to the conversation for me in TB. But you trimmed the CC line, didn't you? Which caused my filter to put the patch into a different folder. :-) > >> we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in > >> there. Fail gracefully instead. > >> > >> Signed-off-by: Jiri Slaby <jslaby@suse.cz> > >> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> > >> --- > >> drivers/acpi/sleep.c | 5 ++--- > >> include/linux/suspend.h | 4 ++-- > >> kernel/power/nvs.c | 8 +++++++- > >> 3 files changed, 11 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > >> index c423231..f94c9a9 100644 > >> --- a/drivers/acpi/sleep.c > >> +++ b/drivers/acpi/sleep.c > >> @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) > >> static int acpi_pm_pre_suspend(void) > >> { > >> acpi_pm_freeze(); > >> - suspend_nvs_save(); > >> - return 0; > >> + return suspend_nvs_save(); > >> } > >> > >> /** > >> @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) > >> { > >> int error = __acpi_pm_prepare(); > >> if (!error) > >> - acpi_pm_pre_suspend(); > >> + error = acpi_pm_pre_suspend(); > >> > >> return error; > >> } > >> diff --git a/include/linux/suspend.h b/include/linux/suspend.h > >> index c1f4998..3ac2551 100644 > >> --- a/include/linux/suspend.h > >> +++ b/include/linux/suspend.h > >> @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } > >> extern int suspend_nvs_register(unsigned long start, unsigned long size); > >> extern int suspend_nvs_alloc(void); > >> extern void suspend_nvs_free(void); > >> -extern void suspend_nvs_save(void); > >> +extern int suspend_nvs_save(void); > >> extern void suspend_nvs_restore(void); > >> #else /* CONFIG_SUSPEND_NVS */ > >> static inline int suspend_nvs_register(unsigned long a, unsigned long b) > >> @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) > >> } > >> static inline int suspend_nvs_alloc(void) { return 0; } > >> static inline void suspend_nvs_free(void) {} > >> -static inline void suspend_nvs_save(void) {} > >> +static inline int suspend_nvs_save(void) {} > >> static inline void suspend_nvs_restore(void) {} > >> #endif /* CONFIG_SUSPEND_NVS */ > >> > >> diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c > >> index 1836db6..57c6fab 100644 > >> --- a/kernel/power/nvs.c > >> +++ b/kernel/power/nvs.c > >> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) > >> /** > >> * suspend_nvs_save - save NVS memory regions > >> */ > >> -void suspend_nvs_save(void) > >> +int suspend_nvs_save(void) > >> { > >> struct nvs_page *entry; > >> > >> @@ -114,8 +114,14 @@ void suspend_nvs_save(void) > >> list_for_each_entry(entry, &nvs_list, node) > >> if (entry->data) { > >> entry->kaddr = ioremap(entry->phys_start, entry->size); > > > > I wonder what happens if you simply change the ioremap() here to > > ioremap_nocache() without any other modifications? > > ioremap *is* ioremap_nocache on x86. And that's the conflict it > complains about I guess? Don't you mean ioremap_cache? Yes, I meant ioremap_cache(), sorry. Using ioremap_cache() here fixes the problem for Len (he's seeing the same issue on his test machine). The question is why it helps, though. My theory is that we have mapped the same area already using ioremap_cache() and now we're trying to map it again using ioremap_nocache(), hence the conflict. I need to confirm this. > > It _really_ shouldn't fail here, because the NVS pages are known to be present. > > It fails because of conflicting maps as can be seen in the photo. At > least I think so. Yes, I think so too. Which is _suspicious_. Thanks, Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 16:38 ` Rafael J. Wysocki @ 2011-01-06 21:01 ` Len Brown 2011-01-06 21:01 ` Len Brown 1 sibling, 0 replies; 45+ messages in thread From: Len Brown @ 2011-01-06 21:01 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jiri Slaby, Jiri Slaby, akpm, linux-kernel, ACPI Devel Maling List, Linux-pm mailing list, Matthew Garrett > ... My theory is that we have mapped the > same area already using ioremap_cache() and now we're trying to map it again > using ioremap_nocache(), hence the conflict. I need to confirm this. On my test box. BIOS-e820: 0000000077626000 - 0000000077632000 (ACPI NVS) yet there are at least two tables (FACS and SSDT) that live in that region, and there are several run-time AML memory opregions residing in that range too. So the region has already been mapped by acpi_os_map_memory() (now using ioremap_cache()) before suspend_nvs_save() runs. Is there a reason that suspend_nvs_save() requires a non-cached mapping? cheers, Len Brown, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 16:38 ` Rafael J. Wysocki 2011-01-06 21:01 ` Len Brown @ 2011-01-06 21:01 ` Len Brown 1 sibling, 0 replies; 45+ messages in thread From: Len Brown @ 2011-01-06 21:01 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jiri Slaby, linux-kernel, ACPI Devel Maling List, akpm, Jiri Slaby, Linux-pm mailing list > ... My theory is that we have mapped the > same area already using ioremap_cache() and now we're trying to map it again > using ioremap_nocache(), hence the conflict. I need to confirm this. On my test box. BIOS-e820: 0000000077626000 - 0000000077632000 (ACPI NVS) yet there are at least two tables (FACS and SSDT) that live in that region, and there are several run-time AML memory opregions residing in that range too. So the region has already been mapped by acpi_os_map_memory() (now using ioremap_cache()) before suspend_nvs_save() runs. Is there a reason that suspend_nvs_save() requires a non-cached mapping? cheers, Len Brown, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 16:09 ` Jiri Slaby ` (2 preceding siblings ...) 2011-01-06 16:38 ` Rafael J. Wysocki @ 2011-01-06 16:38 ` Rafael J. Wysocki 3 siblings, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-06 16:38 UTC (permalink / raw) To: Jiri Slaby Cc: linux-kernel, ACPI Devel Maling List, akpm, Jiri Slaby, Linux-pm mailing list On Thursday, January 06, 2011, Jiri Slaby wrote: > On 01/06/2011 04:57 PM, Rafael J. Wysocki wrote: > > On Thursday, January 06, 2011, Jiri Slaby wrote: > >> When ioremap fails (which might happen for some reason), > > > > If it happens, something is seriously wrong (see below). > > I agree that something is broken, however ioremap may fail for dozen of > reasons. Ignoring the retval is a *bad* idea and it took me a while to > sort out what is wrong. Especially if one has no console like throughout > suspend. If it was handled properly, I would know immediately. (There > should be a message printed out which I forgot to add.) It wasn't handled, because it _never_ failed previously. The ACPI mapping change apparently revealed a deeper problem. I'm not saying the patch isn't useful, though, and I'm going to take it for 2.6.38 (perhaps with minor modifications). > > BTW, to keep things in context, please post fixes like this in the same thread > > in which you reported the problem. At lease please retain the CC list from > > there. > > I actually did, there is: > In-Reply-To: <201101060028.43342.rjw@sisk.pl> > and it successfully threaded to the conversation for me in TB. But you trimmed the CC line, didn't you? Which caused my filter to put the patch into a different folder. :-) > >> we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in > >> there. Fail gracefully instead. > >> > >> Signed-off-by: Jiri Slaby <jslaby@suse.cz> > >> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> > >> --- > >> drivers/acpi/sleep.c | 5 ++--- > >> include/linux/suspend.h | 4 ++-- > >> kernel/power/nvs.c | 8 +++++++- > >> 3 files changed, 11 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > >> index c423231..f94c9a9 100644 > >> --- a/drivers/acpi/sleep.c > >> +++ b/drivers/acpi/sleep.c > >> @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) > >> static int acpi_pm_pre_suspend(void) > >> { > >> acpi_pm_freeze(); > >> - suspend_nvs_save(); > >> - return 0; > >> + return suspend_nvs_save(); > >> } > >> > >> /** > >> @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) > >> { > >> int error = __acpi_pm_prepare(); > >> if (!error) > >> - acpi_pm_pre_suspend(); > >> + error = acpi_pm_pre_suspend(); > >> > >> return error; > >> } > >> diff --git a/include/linux/suspend.h b/include/linux/suspend.h > >> index c1f4998..3ac2551 100644 > >> --- a/include/linux/suspend.h > >> +++ b/include/linux/suspend.h > >> @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } > >> extern int suspend_nvs_register(unsigned long start, unsigned long size); > >> extern int suspend_nvs_alloc(void); > >> extern void suspend_nvs_free(void); > >> -extern void suspend_nvs_save(void); > >> +extern int suspend_nvs_save(void); > >> extern void suspend_nvs_restore(void); > >> #else /* CONFIG_SUSPEND_NVS */ > >> static inline int suspend_nvs_register(unsigned long a, unsigned long b) > >> @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) > >> } > >> static inline int suspend_nvs_alloc(void) { return 0; } > >> static inline void suspend_nvs_free(void) {} > >> -static inline void suspend_nvs_save(void) {} > >> +static inline int suspend_nvs_save(void) {} > >> static inline void suspend_nvs_restore(void) {} > >> #endif /* CONFIG_SUSPEND_NVS */ > >> > >> diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c > >> index 1836db6..57c6fab 100644 > >> --- a/kernel/power/nvs.c > >> +++ b/kernel/power/nvs.c > >> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) > >> /** > >> * suspend_nvs_save - save NVS memory regions > >> */ > >> -void suspend_nvs_save(void) > >> +int suspend_nvs_save(void) > >> { > >> struct nvs_page *entry; > >> > >> @@ -114,8 +114,14 @@ void suspend_nvs_save(void) > >> list_for_each_entry(entry, &nvs_list, node) > >> if (entry->data) { > >> entry->kaddr = ioremap(entry->phys_start, entry->size); > > > > I wonder what happens if you simply change the ioremap() here to > > ioremap_nocache() without any other modifications? > > ioremap *is* ioremap_nocache on x86. And that's the conflict it > complains about I guess? Don't you mean ioremap_cache? Yes, I meant ioremap_cache(), sorry. Using ioremap_cache() here fixes the problem for Len (he's seeing the same issue on his test machine). The question is why it helps, though. My theory is that we have mapped the same area already using ioremap_cache() and now we're trying to map it again using ioremap_nocache(), hence the conflict. I need to confirm this. > > It _really_ shouldn't fail here, because the NVS pages are known to be present. > > It fails because of conflicting maps as can be seen in the photo. At > least I think so. Yes, I think so too. Which is _suspicious_. Thanks, Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 15:57 ` Rafael J. Wysocki 2011-01-06 16:09 ` Jiri Slaby @ 2011-01-06 16:09 ` Jiri Slaby 1 sibling, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 16:09 UTC (permalink / raw) To: Rafael J. Wysocki Cc: linux-kernel, ACPI Devel Maling List, akpm, Jiri Slaby, Linux-pm mailing list On 01/06/2011 04:57 PM, Rafael J. Wysocki wrote: > On Thursday, January 06, 2011, Jiri Slaby wrote: >> When ioremap fails (which might happen for some reason), > > If it happens, something is seriously wrong (see below). I agree that something is broken, however ioremap may fail for dozen of reasons. Ignoring the retval is a *bad* idea and it took me a while to sort out what is wrong. Especially if one has no console like throughout suspend. If it was handled properly, I would know immediately. (There should be a message printed out which I forgot to add.) > BTW, to keep things in context, please post fixes like this in the same thread > in which you reported the problem. At lease please retain the CC list from > there. I actually did, there is: In-Reply-To: <201101060028.43342.rjw@sisk.pl> and it successfully threaded to the conversation for me in TB. >> we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in >> there. Fail gracefully instead. >> >> Signed-off-by: Jiri Slaby <jslaby@suse.cz> >> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> >> --- >> drivers/acpi/sleep.c | 5 ++--- >> include/linux/suspend.h | 4 ++-- >> kernel/power/nvs.c | 8 +++++++- >> 3 files changed, 11 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c >> index c423231..f94c9a9 100644 >> --- a/drivers/acpi/sleep.c >> +++ b/drivers/acpi/sleep.c >> @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) >> static int acpi_pm_pre_suspend(void) >> { >> acpi_pm_freeze(); >> - suspend_nvs_save(); >> - return 0; >> + return suspend_nvs_save(); >> } >> >> /** >> @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) >> { >> int error = __acpi_pm_prepare(); >> if (!error) >> - acpi_pm_pre_suspend(); >> + error = acpi_pm_pre_suspend(); >> >> return error; >> } >> diff --git a/include/linux/suspend.h b/include/linux/suspend.h >> index c1f4998..3ac2551 100644 >> --- a/include/linux/suspend.h >> +++ b/include/linux/suspend.h >> @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } >> extern int suspend_nvs_register(unsigned long start, unsigned long size); >> extern int suspend_nvs_alloc(void); >> extern void suspend_nvs_free(void); >> -extern void suspend_nvs_save(void); >> +extern int suspend_nvs_save(void); >> extern void suspend_nvs_restore(void); >> #else /* CONFIG_SUSPEND_NVS */ >> static inline int suspend_nvs_register(unsigned long a, unsigned long b) >> @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) >> } >> static inline int suspend_nvs_alloc(void) { return 0; } >> static inline void suspend_nvs_free(void) {} >> -static inline void suspend_nvs_save(void) {} >> +static inline int suspend_nvs_save(void) {} >> static inline void suspend_nvs_restore(void) {} >> #endif /* CONFIG_SUSPEND_NVS */ >> >> diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c >> index 1836db6..57c6fab 100644 >> --- a/kernel/power/nvs.c >> +++ b/kernel/power/nvs.c >> @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) >> /** >> * suspend_nvs_save - save NVS memory regions >> */ >> -void suspend_nvs_save(void) >> +int suspend_nvs_save(void) >> { >> struct nvs_page *entry; >> >> @@ -114,8 +114,14 @@ void suspend_nvs_save(void) >> list_for_each_entry(entry, &nvs_list, node) >> if (entry->data) { >> entry->kaddr = ioremap(entry->phys_start, entry->size); > > I wonder what happens if you simply change the ioremap() here to > ioremap_nocache() without any other modifications? ioremap *is* ioremap_nocache on x86. And that's the conflict it complains about I guess? Don't you mean ioremap_cache? > It _really_ shouldn't fail here, because the NVS pages are known to be present. It fails because of conflicting maps as can be seen in the photo. At least I think so. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] PM: fix oops in suspend/hibernate code 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby 2011-01-06 9:31 ` Jiri Slaby 2011-01-06 15:57 ` Rafael J. Wysocki @ 2011-01-06 15:57 ` Rafael J. Wysocki 2 siblings, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-06 15:57 UTC (permalink / raw) To: Jiri Slaby Cc: jirislaby, linux-kernel, ACPI Devel Maling List, akpm, Linux-pm mailing list On Thursday, January 06, 2011, Jiri Slaby wrote: > When ioremap fails (which might happen for some reason), If it happens, something is seriously wrong (see below). BTW, to keep things in context, please post fixes like this in the same thread in which you reported the problem. At lease please retain the CC list from there. > we nicely oops in suspend_nvs_save due to NULL dereference by memcpy in > there. Fail gracefully instead. > > Signed-off-by: Jiri Slaby <jslaby@suse.cz> > Cc: "Rafael J. Wysocki" <rjw@sisk.pl> > --- > drivers/acpi/sleep.c | 5 ++--- > include/linux/suspend.h | 4 ++-- > kernel/power/nvs.c | 8 +++++++- > 3 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c > index c423231..f94c9a9 100644 > --- a/drivers/acpi/sleep.c > +++ b/drivers/acpi/sleep.c > @@ -124,8 +124,7 @@ static int acpi_pm_freeze(void) > static int acpi_pm_pre_suspend(void) > { > acpi_pm_freeze(); > - suspend_nvs_save(); > - return 0; > + return suspend_nvs_save(); > } > > /** > @@ -151,7 +150,7 @@ static int acpi_pm_prepare(void) > { > int error = __acpi_pm_prepare(); > if (!error) > - acpi_pm_pre_suspend(); > + error = acpi_pm_pre_suspend(); > > return error; > } > diff --git a/include/linux/suspend.h b/include/linux/suspend.h > index c1f4998..3ac2551 100644 > --- a/include/linux/suspend.h > +++ b/include/linux/suspend.h > @@ -262,7 +262,7 @@ static inline bool system_entering_hibernation(void) { return false; } > extern int suspend_nvs_register(unsigned long start, unsigned long size); > extern int suspend_nvs_alloc(void); > extern void suspend_nvs_free(void); > -extern void suspend_nvs_save(void); > +extern int suspend_nvs_save(void); > extern void suspend_nvs_restore(void); > #else /* CONFIG_SUSPEND_NVS */ > static inline int suspend_nvs_register(unsigned long a, unsigned long b) > @@ -271,7 +271,7 @@ static inline int suspend_nvs_register(unsigned long a, unsigned long b) > } > static inline int suspend_nvs_alloc(void) { return 0; } > static inline void suspend_nvs_free(void) {} > -static inline void suspend_nvs_save(void) {} > +static inline int suspend_nvs_save(void) {} > static inline void suspend_nvs_restore(void) {} > #endif /* CONFIG_SUSPEND_NVS */ > > diff --git a/kernel/power/nvs.c b/kernel/power/nvs.c > index 1836db6..57c6fab 100644 > --- a/kernel/power/nvs.c > +++ b/kernel/power/nvs.c > @@ -105,7 +105,7 @@ int suspend_nvs_alloc(void) > /** > * suspend_nvs_save - save NVS memory regions > */ > -void suspend_nvs_save(void) > +int suspend_nvs_save(void) > { > struct nvs_page *entry; > > @@ -114,8 +114,14 @@ void suspend_nvs_save(void) > list_for_each_entry(entry, &nvs_list, node) > if (entry->data) { > entry->kaddr = ioremap(entry->phys_start, entry->size); I wonder what happens if you simply change the ioremap() here to ioremap_nocache() without any other modifications? It _really_ shouldn't fail here, because the NVS pages are known to be present. > + if (!entry->kaddr) { > + suspend_nvs_free(); > + return -ENOMEM; > + } > memcpy(entry->data, entry->kaddr, entry->size); > } > + > + return 0; > } > > /** > Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby @ 2011-01-06 9:24 ` Jiri Slaby 2011-01-06 9:24 ` Jiri Slaby 2 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 9:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On 01/06/2011 12:28 AM, Rafael J. Wysocki wrote: > Two more questions: > (1) Does the failing machine power off correctly with the kernel that fails to > suspend? Poweroff is OK. > (2) Is the failing suspend behavior reproducible if you run > "echo disk > /sys/power/state" instead of "pm-suspend" in the platform test? Thanks for the hint no_console_suspend with hibernate shows somwthing (opposing to suspend). I've sent a patch for the oops which occured due to ioremap change. The ioremap change still needs to be reverted, obviously. The oops in question: http://www.fi.muni.cz/~xslaby/sklad/panics/suspend-oops.png /proc/mtrr: reg00: base=0x0b0000000 ( 2816MB), size= 256MB, count=1: uncachable reg01: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg02: base=0x000000000 ( 0MB), size= 4096MB, count=1: write-back reg03: base=0x100000000 ( 4096MB), size= 2048MB, count=1: write-back reg04: base=0x180000000 ( 6144MB), size= 1024MB, count=1: write-back reg05: base=0x1c0000000 ( 7168MB), size= 128MB, count=1: write-back reg06: base=0x1c8000000 ( 7296MB), size= 64MB, count=1: write-back reg07: base=0x0af600000 ( 2806MB), size= 2MB, count=1: uncachable /debug/x86/pat_memtype_list: PAT memtype list: uncached-minus @ 0xaf5b0000-0xaf5b7000 uncached-minus @ 0xaf5be000-0xaf5c1000 uncached-minus @ 0xaf5be000-0xaf5c1000 uncached-minus @ 0xaf5be000-0xaf5bf000 uncached-minus @ 0xb0200000-0xb0201000 write-combining @ 0xd0000000-0xe0000000 write-combining @ 0xd0001000-0xd0021000 write-combining @ 0xd0030000-0xd0530000 uncached-minus @ 0xe0000000-0xf0000000 uncached-minus @ 0xfe6ff000-0xfe700000 uncached-minus @ 0xfe7e0000-0xfe800000 uncached-minus @ 0xfea00000-0xfea80000 uncached-minus @ 0xfeb40000-0xfeb60000 uncached-minus @ 0xfeb78000-0xfeb7c000 uncached-minus @ 0xfeb7c000-0xfeb7d000 uncached-minus @ 0xfeb7d000-0xfeb7e000 uncached-minus @ 0xfeb7f000-0xfeb80000 uncached-minus @ 0xfeb7f000-0xfeb80000 uncached-minus @ 0xfeb80000-0xfec00000 uncached-minus @ 0xfeb80000-0xfec00000 uncached-minus @ 0xfed00000-0xfed01000 uncached-minus @ 0xfed1f000-0xfed20000 uncached-minus @ 0xffff0000-0xffff1000 regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby 2011-01-06 9:24 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby @ 2011-01-06 9:24 ` Jiri Slaby 2011-01-06 15:45 ` Rafael J. Wysocki 2011-01-06 15:45 ` Rafael J. Wysocki 2 siblings, 2 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 9:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On 01/06/2011 12:28 AM, Rafael J. Wysocki wrote: > Two more questions: > (1) Does the failing machine power off correctly with the kernel that fails to > suspend? Poweroff is OK. > (2) Is the failing suspend behavior reproducible if you run > "echo disk > /sys/power/state" instead of "pm-suspend" in the platform test? Thanks for the hint no_console_suspend with hibernate shows somwthing (opposing to suspend). I've sent a patch for the oops which occured due to ioremap change. The ioremap change still needs to be reverted, obviously. The oops in question: http://www.fi.muni.cz/~xslaby/sklad/panics/suspend-oops.png /proc/mtrr: reg00: base=0x0b0000000 ( 2816MB), size= 256MB, count=1: uncachable reg01: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg02: base=0x000000000 ( 0MB), size= 4096MB, count=1: write-back reg03: base=0x100000000 ( 4096MB), size= 2048MB, count=1: write-back reg04: base=0x180000000 ( 6144MB), size= 1024MB, count=1: write-back reg05: base=0x1c0000000 ( 7168MB), size= 128MB, count=1: write-back reg06: base=0x1c8000000 ( 7296MB), size= 64MB, count=1: write-back reg07: base=0x0af600000 ( 2806MB), size= 2MB, count=1: uncachable /debug/x86/pat_memtype_list: PAT memtype list: uncached-minus @ 0xaf5b0000-0xaf5b7000 uncached-minus @ 0xaf5be000-0xaf5c1000 uncached-minus @ 0xaf5be000-0xaf5c1000 uncached-minus @ 0xaf5be000-0xaf5bf000 uncached-minus @ 0xb0200000-0xb0201000 write-combining @ 0xd0000000-0xe0000000 write-combining @ 0xd0001000-0xd0021000 write-combining @ 0xd0030000-0xd0530000 uncached-minus @ 0xe0000000-0xf0000000 uncached-minus @ 0xfe6ff000-0xfe700000 uncached-minus @ 0xfe7e0000-0xfe800000 uncached-minus @ 0xfea00000-0xfea80000 uncached-minus @ 0xfeb40000-0xfeb60000 uncached-minus @ 0xfeb78000-0xfeb7c000 uncached-minus @ 0xfeb7c000-0xfeb7d000 uncached-minus @ 0xfeb7d000-0xfeb7e000 uncached-minus @ 0xfeb7f000-0xfeb80000 uncached-minus @ 0xfeb7f000-0xfeb80000 uncached-minus @ 0xfeb80000-0xfec00000 uncached-minus @ 0xfeb80000-0xfec00000 uncached-minus @ 0xfed00000-0xfed01000 uncached-minus @ 0xfed1f000-0xfed20000 uncached-minus @ 0xffff0000-0xffff1000 regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-06 9:24 ` Jiri Slaby @ 2011-01-06 15:45 ` Rafael J. Wysocki 2011-01-06 15:45 ` Rafael J. Wysocki 1 sibling, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-06 15:45 UTC (permalink / raw) To: Jiri Slaby Cc: akpm, mm-commits, LKML, Linux-pm mailing list, Brown, Len, steiner, ACPI Devel Maling List, Len Brown On Thursday, January 06, 2011, Jiri Slaby wrote: > On 01/06/2011 12:28 AM, Rafael J. Wysocki wrote: > > Two more questions: > > (1) Does the failing machine power off correctly with the kernel that fails to > > suspend? > > Poweroff is OK. > > > (2) Is the failing suspend behavior reproducible if you run > > "echo disk > /sys/power/state" instead of "pm-suspend" in the platform test? > > Thanks for the hint no_console_suspend with hibernate shows somwthing > (opposing to suspend). I've sent a patch for the oops which occured due > to ioremap change. Can you send a link to the patch, please? > The ioremap change still needs to be reverted, obviously. Does it need to be reverted with your patch applied too? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-06 9:24 ` Jiri Slaby 2011-01-06 15:45 ` Rafael J. Wysocki @ 2011-01-06 15:45 ` Rafael J. Wysocki 1 sibling, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-06 15:45 UTC (permalink / raw) To: Jiri Slaby Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On Thursday, January 06, 2011, Jiri Slaby wrote: > On 01/06/2011 12:28 AM, Rafael J. Wysocki wrote: > > Two more questions: > > (1) Does the failing machine power off correctly with the kernel that fails to > > suspend? > > Poweroff is OK. > > > (2) Is the failing suspend behavior reproducible if you run > > "echo disk > /sys/power/state" instead of "pm-suspend" in the platform test? > > Thanks for the hint no_console_suspend with hibernate shows somwthing > (opposing to suspend). I've sent a patch for the oops which occured due > to ioremap change. Can you send a link to the patch, please? > The ioremap change still needs to be reverted, obviously. Does it need to be reverted with your patch applied too? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-05 21:36 ` Jiri Slaby 2011-01-05 22:39 ` Rafael J. Wysocki @ 2011-01-05 22:39 ` Rafael J. Wysocki 1 sibling, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-05 22:39 UTC (permalink / raw) To: Jiri Slaby Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On Wednesday, January 05, 2011, Jiri Slaby wrote: > On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > > On Tuesday, January 04, 2011, Jiri Slaby wrote: > >> On 01/04/2011 02:40 PM, Jiri Slaby wrote: > >>> On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > >>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > >>> > >>> Hi, this kernel regresses with respect to suspend to ram in comparison > >>> with mmotm 2010-12-16-14-56. > >>> > >>> This is OK: > >>> echo devices > /sys/power/pm_test > >>> pm-suspend > >>> This hangs at suspend phase: > >>> echo platform > /sys/power/pm_test > >>> pm-suspend > > > > Hmm. So it looks like _PTS hangs? > > No _PST here :). I really meant _PTS and yes, there is one and it does quite a lot of interesting stuff. Are you able to collect serial console (or equivalent) logs from that machine? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 16:49 ` Jiri Slaby 2011-01-04 22:57 ` Rafael J. Wysocki @ 2011-01-04 22:57 ` Rafael J. Wysocki 2011-01-06 8:27 ` ia64 build broken " Jiri Slaby 2011-01-06 8:27 ` Jiri Slaby 3 siblings, 0 replies; 45+ messages in thread From: Rafael J. Wysocki @ 2011-01-04 22:57 UTC (permalink / raw) To: Jiri Slaby Cc: Brown, Len, mm-commits, steiner, LKML, ACPI Devel Maling List, akpm, Linux-pm mailing list On Tuesday, January 04, 2011, Jiri Slaby wrote: > On 01/04/2011 02:40 PM, Jiri Slaby wrote: > > On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: > >> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > > > Hi, this kernel regresses with respect to suspend to ram in comparison > > with mmotm 2010-12-16-14-56. > > > > This is OK: > > echo devices > /sys/power/pm_test > > pm-suspend > > This hangs at suspend phase: > > echo platform > /sys/power/pm_test > > pm-suspend Hmm. So it looks like _PTS hangs? > > Note that this kernel is based on next-20101221. Should I try newer (and > > clean) -next? > > Ok, bisected down to: > 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit > commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e > Author: Len Brown <len.brown@intel.com> > Date: Thu Dec 16 23:12:23 2010 -0500 > > ACPI: use ioremap_cache() > > Although the temporary boot-time ACPI table mappings > were set up with CPU caching enabled, the permanent table > mappings and AML run-time region memory accesses were > set up with ioremap(), which on x86 is a synonym for > ioremap_nocache(). > > Changing this to ioremap_cache() improves performance as > seen when accessing the tables via acpidump, > or /sys/firmware/acpi/tables. It should also improve > AML run-time performance. > > No change on ia64. > > Reported-by: Jack Steiner <steiner@sgi.com> > Signed-off-by: Len Brown <len.brown@intel.com> > > :040000 040000 be35c5e8f214f10f94688c1a27f33ecfb8505220 > 52581222d0edf190f160f3e5aa5d2c1af8e76988 M arch > :040000 040000 ccdca0d41938b8312e946cde3c01c59b32d1c17c > 96ccf2357f2ac4a31d19cc41f5728d9f87b6cac0 M drivers > > Revert of that patch fixes the problem. Can you send a dmesg output and acpidump output from the failing system, please? Rafael ^ permalink raw reply [flat|nested] 45+ messages in thread
* ia64 build broken [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 16:49 ` Jiri Slaby 2011-01-04 22:57 ` Rafael J. Wysocki 2011-01-04 22:57 ` Rafael J. Wysocki @ 2011-01-06 8:27 ` Jiri Slaby 2011-01-06 8:27 ` Jiri Slaby 3 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 8:27 UTC (permalink / raw) To: Brown, Len; +Cc: mm-commits, steiner, LKML, akpm, Linux-pm mailing list On 01/04/2011 05:49 PM, Jiri Slaby wrote: > 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit > commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e > Author: Len Brown <len.brown@intel.com> > Date: Thu Dec 16 23:12:23 2010 -0500 > > ACPI: use ioremap_cache() > > Although the temporary boot-time ACPI table mappings > were set up with CPU caching enabled, the permanent table > mappings and AML run-time region memory accesses were > set up with ioremap(), which on x86 is a synonym for > ioremap_nocache(). > > Changing this to ioremap_cache() improves performance as > seen when accessing the tables via acpidump, > or /sys/firmware/acpi/tables. It should also improve > AML run-time performance. > > No change on ia64. BTW I've just noted, you actually broke ia64. The code reads like: return ioremap(unsigned long phys_addr, unsigned long size); regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* ia64 build broken [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 16:49 ` Jiri Slaby ` (2 preceding siblings ...) 2011-01-06 8:27 ` ia64 build broken " Jiri Slaby @ 2011-01-06 8:27 ` Jiri Slaby 2011-01-06 8:31 ` [PATCH 1/1] ia64: fix build of ioremap_cache Jiri Slaby 3 siblings, 1 reply; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 8:27 UTC (permalink / raw) To: Brown, Len Cc: akpm, mm-commits, LKML, Rafael J. Wysocki, Linux-pm mailing list, steiner On 01/04/2011 05:49 PM, Jiri Slaby wrote: > 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit > commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e > Author: Len Brown <len.brown@intel.com> > Date: Thu Dec 16 23:12:23 2010 -0500 > > ACPI: use ioremap_cache() > > Although the temporary boot-time ACPI table mappings > were set up with CPU caching enabled, the permanent table > mappings and AML run-time region memory accesses were > set up with ioremap(), which on x86 is a synonym for > ioremap_nocache(). > > Changing this to ioremap_cache() improves performance as > seen when accessing the tables via acpidump, > or /sys/firmware/acpi/tables. It should also improve > AML run-time performance. > > No change on ia64. BTW I've just noted, you actually broke ia64. The code reads like: return ioremap(unsigned long phys_addr, unsigned long size); regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH 1/1] ia64: fix build of ioremap_cache 2011-01-06 8:27 ` Jiri Slaby @ 2011-01-06 8:31 ` Jiri Slaby 2011-01-06 16:03 ` Len Brown 0 siblings, 1 reply; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 8:31 UTC (permalink / raw) To: len.brown; +Cc: akpm, linux-kernel, jirislaby Commit "ACPI: use ioremap_cache()" introduced ioremap_cache which causes build failures. Remove "unsigned long" from parameters of called ioremap. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Len Brown <len.brown@intel.com> --- arch/ia64/include/asm/io.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h index 009a7e0..e5a6c35 100644 --- a/arch/ia64/include/asm/io.h +++ b/arch/ia64/include/asm/io.h @@ -428,7 +428,7 @@ extern void __iomem * early_ioremap (unsigned long phys_addr, unsigned long size extern void early_iounmap (volatile void __iomem *addr, unsigned long size); static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned long size) { - return ioremap(unsigned long phys_addr, unsigned long size); + return ioremap(phys_addr, size); } -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] ia64: fix build of ioremap_cache 2011-01-06 8:31 ` [PATCH 1/1] ia64: fix build of ioremap_cache Jiri Slaby @ 2011-01-06 16:03 ` Len Brown 2011-01-06 16:21 ` Jiri Slaby 0 siblings, 1 reply; 45+ messages in thread From: Len Brown @ 2011-01-06 16:03 UTC (permalink / raw) To: Jiri Slaby; +Cc: len.brown, akpm, linux-kernel, jirislaby > diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h > index 009a7e0..e5a6c35 100644 > --- a/arch/ia64/include/asm/io.h > +++ b/arch/ia64/include/asm/io.h > @@ -428,7 +428,7 @@ extern void __iomem * early_ioremap (unsigned long phys_addr, unsigned long size > extern void early_iounmap (volatile void __iomem *addr, unsigned long size); > static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned long size) > { > - return ioremap(unsigned long phys_addr, unsigned long size); > + return ioremap(phys_addr, size); > } I pushed this fix 9 days ago, what tree are you running? thanks, Len Brown, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH 1/1] ia64: fix build of ioremap_cache 2011-01-06 16:03 ` Len Brown @ 2011-01-06 16:21 ` Jiri Slaby 0 siblings, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-06 16:21 UTC (permalink / raw) To: Len Brown; +Cc: Jiri Slaby, len.brown, akpm, linux-kernel On 01/06/2011 05:03 PM, Len Brown wrote: > >> diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h >> index 009a7e0..e5a6c35 100644 >> --- a/arch/ia64/include/asm/io.h >> +++ b/arch/ia64/include/asm/io.h >> @@ -428,7 +428,7 @@ extern void __iomem * early_ioremap (unsigned long phys_addr, unsigned long size >> extern void early_iounmap (volatile void __iomem *addr, unsigned long size); >> static inline void __iomem * ioremap_cache (unsigned long phys_addr, unsigned long size) >> { >> - return ioremap(unsigned long phys_addr, unsigned long size); >> + return ioremap(phys_addr, size); >> } > > I pushed this fix 9 days ago, what tree are you running? Aha, you melded the fix into the original patch. I only checked whether there was a change on the top of that commit. So ignore this patch and sorry for the noise. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] 2011-01-04 13:40 ` Jiri Slaby 2011-01-04 16:49 ` Jiri Slaby @ 2011-01-04 16:49 ` Jiri Slaby 1 sibling, 0 replies; 45+ messages in thread From: Jiri Slaby @ 2011-01-04 16:49 UTC (permalink / raw) To: akpm; +Cc: Brown, Len, mm-commits, steiner, LKML, Linux-pm mailing list On 01/04/2011 02:40 PM, Jiri Slaby wrote: > On 12/24/2010 01:58 AM, akpm@linux-foundation.org wrote: >> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to > > Hi, this kernel regresses with respect to suspend to ram in comparison > with mmotm 2010-12-16-14-56. > > This is OK: > echo devices > /sys/power/pm_test > pm-suspend > This hangs at suspend phase: > echo platform > /sys/power/pm_test > pm-suspend > > Note that this kernel is based on next-20101221. Should I try newer (and > clean) -next? Ok, bisected down to: 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e Author: Len Brown <len.brown@intel.com> Date: Thu Dec 16 23:12:23 2010 -0500 ACPI: use ioremap_cache() Although the temporary boot-time ACPI table mappings were set up with CPU caching enabled, the permanent table mappings and AML run-time region memory accesses were set up with ioremap(), which on x86 is a synonym for ioremap_nocache(). Changing this to ioremap_cache() improves performance as seen when accessing the tables via acpidump, or /sys/firmware/acpi/tables. It should also improve AML run-time performance. No change on ia64. Reported-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Len Brown <len.brown@intel.com> :040000 040000 be35c5e8f214f10f94688c1a27f33ecfb8505220 52581222d0edf190f160f3e5aa5d2c1af8e76988 M arch :040000 040000 ccdca0d41938b8312e946cde3c01c59b32d1c17c 96ccf2357f2ac4a31d19cc41f5728d9f87b6cac0 M drivers Revert of that patch fixes the problem. regards, -- js ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2011-01-06 21:01 UTC | newest] Thread overview: 45+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-24 0:58 mmotm 2010-12-23-16-58 uploaded akpm 2010-12-24 0:58 ` akpm 2010-12-24 12:15 ` Sedat Dilek 2010-12-24 12:15 ` Sedat Dilek 2010-12-24 13:04 ` Andrew Morton 2010-12-24 13:04 ` Andrew Morton 2010-12-24 17:52 ` [PATCH -mmotm] kptr_restrict: fix build when PRINTK not enabled Randy Dunlap 2010-12-24 17:52 ` Randy Dunlap 2010-12-27 2:13 ` mmotm 2010-12-23-16-58 uploaded Randy Dunlap 2010-12-27 2:13 ` Randy Dunlap 2011-01-04 13:40 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby 2011-01-04 13:40 ` Jiri Slaby 2011-01-04 16:49 ` Jiri Slaby 2011-01-04 22:57 ` Rafael J. Wysocki 2011-01-05 21:36 ` Jiri Slaby 2011-01-05 21:36 ` Jiri Slaby 2011-01-05 22:39 ` Rafael J. Wysocki 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 22:46 ` Jiri Slaby 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-05 23:28 ` Rafael J. Wysocki 2011-01-06 9:18 ` [PATCH 1/1] PM: fix oops in suspend/hibernate code Jiri Slaby 2011-01-06 9:31 ` Jiri Slaby 2011-01-06 15:57 ` Rafael J. Wysocki 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby 2011-01-06 16:31 ` Jiri Slaby 2011-01-06 16:38 ` Rafael J. Wysocki 2011-01-06 21:01 ` Len Brown 2011-01-06 21:01 ` Len Brown 2011-01-06 16:38 ` Rafael J. Wysocki 2011-01-06 16:09 ` Jiri Slaby 2011-01-06 15:57 ` Rafael J. Wysocki 2011-01-06 9:24 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby 2011-01-06 9:24 ` Jiri Slaby 2011-01-06 15:45 ` Rafael J. Wysocki 2011-01-06 15:45 ` Rafael J. Wysocki 2011-01-05 22:39 ` Rafael J. Wysocki 2011-01-04 22:57 ` Rafael J. Wysocki 2011-01-06 8:27 ` ia64 build broken " Jiri Slaby 2011-01-06 8:27 ` Jiri Slaby 2011-01-06 8:31 ` [PATCH 1/1] ia64: fix build of ioremap_cache Jiri Slaby 2011-01-06 16:03 ` Len Brown 2011-01-06 16:21 ` Jiri Slaby 2011-01-04 16:49 ` suspend hangs at platform phase [was: mmotm 2010-12-23-16-58 uploaded] Jiri Slaby
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.