2.6.23-rc7-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32
things, mainly (Kumar Gala <***@gate.crashing.org>)



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1
git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.

echo "subscribe mm-commits" | mail ***@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
email Subject: in some manner to reflect the nature of the bug. Some
developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
the mm-commits list.



Changes since 2.6.23-rc6-mm1:

origin.patch
git-acpi.patch
git-alsa.patch
git-arm.patch
git-audit-master.patch
git-avr32.patch
git-cifs.patch
git-cpufreq.patch
git-powerpc.patch
git-powerpc-galak.patch
git-drm.patch
git-dvb.patch
git-hwmon.patch
git-gfs2-nmw.patch
git-hid.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-jfs.patch
git-jg-misc.patch
git-kbuild.patch
git-kvm.patch
git-libata-all.patch
git-md-accel.patch
git-mips.patch
git-mmc.patch
git-mtd.patch
git-ubi.patch
git-net.patch
git-backlight.patch
git-battery.patch
git-nfs.patch
git-nfsd.patch
git-ocfs2.patch
git-r8169.patch
git-selinux.patch
git-s390.patch
git-sched.patch
git-sh.patch
git-scsi-misc.patch
git-scsi-rc-fixes.patch
git-block.patch
git-unionfs.patch
git-watchdog.patch
git-wireless.patch
git-ipwireless_cs.patch
git-newsetup.patch
git-xfs.patch
git-cryptodev.patch
git-kgdb.patch
git-block-vs-reiser4.patch
git-nfsd-broke-reiser4.patch

git trees

-fix-dac960-driver-on-machines-which-dont-support-64-bit-dma-fix.patch
-uml-use-correct-type-in-blkgetsize-ioctl.patch
-atyfb-force-29mhz-xtal-on-g3-powerbooks.patch
-fix-failure-to-resume-from-initrds.patch
-fix-uts-corruption-during-cloneclone_newuts.patch
-rtc-ds1742c-should-use-resource_size_t-for-base-address.patch
-rtc-rtc-ds1553c-should-use-resource_size_t-for-base.patch
-mspec-handle-shrinking-virtual-memory-areas.patch
-mspec-handle-shrinking-virtual-memory-areas-3.patch
-pci-fix-unterminated-pci_device_id-lists.patch
-pci-fix-unterminated-pci_device_id-lists-fix.patch
-xen-dont-bother-trying-to-set-cr4.patch
-intelfb-fix-bug-in-dpll-disable.patch
-intel-agp-fix-i830-mask-variable-that-changed-with-g33-support.patch
-dir_index-error-out-instead-of-bug-on-corrupt-dx-dirs.patch
-nfs-fix-oops-re-sysctls-and-v4-support.patch
-disable-sys_timerfd-for-2623.patch
-ext34-ensure-do_split-leaves-enough-free-space-in-both-blocks.patch
-kernel-userc-use-list_for_each_entry-instead-of-list_for_each.patch
-convert-uid-hash-to-hlist.patch
-fix-user-namespace-exiting-oops.patch
-fix-numa-memory-policy-reference-counting.patch
-git-alsa-sc6000-build-fix.patch
-ess-maestro-1-2-2e-sound-card-use-list_for_each_entry.patch
-routines-for-effect-processor-fx8010-use-list_for_each_entry.patch
-arm-unbalanced-parenthesis-fix.patch
-ppc-remove-apus-support.patch
-fix-gregkh-driver-sysfs-spit-a-warning-to-users-when-they-try-to-create-a-duplicate-sysfs-file.patch
-drivers-char-nozomic-__devexit_p-usage-build-fix.patch
-i2c-i801-documentation-patch-for-intel-tolapai.patch
-i2c-i801-smbus-patch-for-intel-tolapai.patch
-i2c-i801-smbus-patch-for-intel-tolapai-fix.patch
-ata-add-the-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61patch.patch
-ahci-raid-mode-sata-patch-for-intel-tolapai.patch
-st340823a-hpa-and-libata.patch
-ata-increase-allowed-config-flags.patch
-ata_piix-replace-spaces-with-tabs.patch
-ide-ide-remove-ide-rate-filter-from-speedproc.patch
-ide-ide-use-only-set-pio-mode-for-programming-pio-modes.patch
-ide-ide-remove-ide-dma-check.patch
-ide-ide-add-mwdma-mask-and-swdma-mask-to-ide-pci-device-t.patch
-git-net-fix-2.patch
-nit-net-skge-build-fix.patch
-git-net-af_iucv-fixes.patch
-git-net-sgiseeq-fix.patch
-git-net-fix-ibmveth.patch
-git-net-af_iucv-fixes.patch
-git-net-sgiseeq-fix.patch
-git-net-fix-ibmveth.patch
-sky2-118.patch
-sb1250-macc-de-typedef-de-volatile-de-etc.patch
-net_sb1250_mac-update-kconfig-entry.patch
-net_sb1250_mac-rename-to-sb1250_mac.patch
-ipg-add-ip1000a-driver-to-kernel-tree.patch
-git-net-broke-ipg-add-ip1000a-driver-to-kernel-tree.patch
-use-mutex-instead-of-semaphore-in-the-onstream-scsi-tape-driver.patch
-git-block-fix-u14-34f.patch
-ll_rw_blk-blk_cpu_notifier-should-be-__cpuinitdata.patch
-x86_64-mm-fix-section-mismatch-warnings.patch
-therm_throtc-fix-section-mismatch.patch
-i386-cpuid_count-fix-argument-signedness-warnings.patch
-i386-fix-section-mismatch-warning-in-intelc.patch
-x86-misc-constifications.patch
-x86-constify-wd_ops.patch
-x86-multi-byte-single-instruction-nops.patch
-enforce-noreplace-smp-in-alternative_instructions.patch
-i386-apic-fix-4-bit-apicid-assumption-of-mach-default.patch
-scsi-use-lock-per-host-instead-of-per-device-for-shared-queue-tag-host.patch
-x86_64-nx-bit-handling-in-change_page_attr.patch
-driver-core-fix-deprectated-sysfs-structure-for-nested-class-devices.patch
-pvrusb2-hdw-terminate-usb-device-id-table-differently.patch
-cpu-hotplug-cpuid-fix-cpu-hotplug-error-handling.patch

Merged into mainline or a subsystem tree

+ufs-fix-sun-state.patch
+fix-potential-oops-in-generic_setlease.patch
+fix-potential-oops-in-generic_setlease-v2.patch
+fix-mspec-handle-shrinking-virtual-memory-areas.patch
+missing-null-termination-in-one-wire-uevent.patch
+typo-fix-kernel-config-option.patch

2.6.23 queue

+fix-oops-in-platform-uevent.patch

Also 2.6.23 I guess

-git-acpi-fixup.patch

Unneeded

+acpi-sbs-fix-sbs-add-alarm-patch.patch

ACPI fix

+agk-dm-dm-ioctl-fix-compat-bounds-test.patch
+agk-dm-dm-tidy-bio_io_error-usage.patch
+agk-dm-dm-ioctl-remove-vmalloc-void-cast.patch
+agk-dm-dm-crypt-use-per-device-singlethread-workqueues.patch
+agk-dm-dm-crypt-add-post-processing-queue.patch

device mapped tree updates

+fix-3-gregkh-driver-kobject-remove-the-static-array-for-the-name.patch
+kobject-temporarily-save-k_name-on-cleanup-for-debug-message.patch

Fix Greg's driver core tree

+jdelvare-i2c-i2c-i801-tolapai-support.patch

i2c tree update

Dropped

+first-stab-at-elantech-touchpad-driver-for-26226-testers.patch
+first-stab-at-elantech-touchpad-driver-for-26226-testers-fix.patch
+make-wistron-btns-recognize-special-keys-on-medion-wim2160-notebooks.patch

Input stuff

+menuconfig-distinguish-between-selected-by-another-options-and-comments.patch

Kconfig

+pata_acpi-use-ata_sff_port_start.patch

pata update

+libata-add-a-horkage-entry-for-drq-mishandling-atapi.patch
+ahci-add-mcp79-support-to-ahci-driver.patch
+ahci-add-mcp79-support-to-ahci-driver-update.patch

ata updates

+ide-ide-call-udma_filter-before-resorting-to-the-ultradma-mask.patch
+ide-ide-remove-ide-rate-filter-from-speedproc-take-2.patch
+ide-ide-use-only-set-pio-mode-for-programming-pio-modes-take-2.patch
+ide-ide-remove-ide-dma-check-take-2.patch
+ide-ide-add-mwdma-mask-and-swdma-mask-to-ide-pci-device-t-take-2.patch
+ide-alim15x3-fix-cd_rom-dma-and-pio-fifo-settings-setup.patch
+ide-alim15x3-use-host-flags-and-udma-mask-fields-from-ide-pci-device-t.patch
+ide-aec62xx-remove-aec62xx-dma-lost-irq.patch
+ide-siimage-separate-pata-and-sata-methods.patch
+ide-ide-add-fixup-method-to-ide-hwif-t.patch
+ide-ide-add-ide-device-add.patch
+ide-maintainers-mark-ide-scsi-as-orhpan.patch
+ide-ide-add-ide-find-port-helper.patch
+ide-ide-remove-redundant-comments-from-ide-h.patch
+ide-ide-add-config-ide-arch-obsolete-init.patch

IDE tree updates

+git-mtd-vs-powerpc.patch

Fix mtd borkage

+git-net-fix-macec.patch
+git-net-sky2-fixups.patch
+git-net-fix-wireless-kconfig.patch
+git-net-fix-spidernet-build.patch
+spider_net_ethtool-keep-up-with-recent-netdev-stats-changes.patch
+pasemi_mac-build-fix-after-recent-netdev-stats.patch
+make-mv643xx_ethc-build-again.patch
+dgrs-remove-from-build-config-and-maintainer-list.patch

net fixes

+phylib-spinlock-fixes-for-softirqs.patch
+forcedeth-power-down-phy-when-interface-is-down.patch
+forcedeth-no-link-is-informational.patch
+phylib-irq-event-workqueue-handling-fixes.patch
+phylib-fix-an-interrupt-loop-potential-when-halting.patch

netdev updates

+git-battery.patch
+revert-git-battery.patch

Greg's driver tree breaks this git tree

-git-nfsd-fixup.patch

Unneeded

+provide-stubs-for-enable_irq_wake-and-disable_irq_wake.patch
+serial_txx9-use-upf_fixed_port.patch

serial stuff

+some-proc-entries-are-missed-in-sched_domain-sys_ctl-debug.patch

sched fix

+mpt-fusion-shut-up-uninitialized-variable.patch
+mptbase-reset-ioc-initiator-during-pci-resume.patch

scsi fixes

+usb-gadget-ether-prevent-oops-caused-by-error-interrupt-race.patch

USB fix

+9p-fix-compile-error-if-config_sysctl.patch

9pfs fix

-git-net-vs-git-wireless.patch
-git-net-vs-git-wireless-2.patch
-ath5k-panic-fix.patch
-git-net-vs-git-wireless-3.patch
-git-net-broke-git-wireless.patch
-more-wireless-borkage.patch
-more-wireless-borkage-2.patch
-more-wireless-borkage-3.patch
-git-wireless-fix-99.patch

more wireless churn, getting sorted out now. b44 is still disabled in -mm,
perhaps unjustly.

+x86_64-mm-misc_-constifications.patch
+x86_64-mm-constify-stacktrace_ops.patch
+x86_64-mm-unwinder-default.patch
+x86_64-mm-less-stack-alignment.patch
+x86_64-mm-fix-argument-signedness-warnings.patch
+x86_64-mm-cpu-hotplug-cpuid-fix-cpu-hotplug-error-handling.patch
+x86_64-mm-die-lock.patch
+x86_64-mm-mce-setup.patch
+x86_64-mm-fix-off-by-one-in-find_next_zero_string.patch
+x86_64-mm-fix-4-bit-apicid-assumption-of-mach-default.patch
+x86_64-mm-fix-section-mismatch.patch
+x86_64-mm-fix-section-mismatch-warning-in-intel_c.patch
+x86_64-mm-constify-wd_ops.patch
+x86_64-mm-multi-byte-single-instruction-nops.patch
+x86_64-mm-introduce-used_vectors-bitmap-which-can-be-used-to-reserve-vectors.patch
+x86_64-mm-configure-hpet_emulate_rtc-automatically.patch
+x86_64-mm-also-show-non-zero-irq-counts-for-vectors-that-currently-dont-have-a-handler.patch
+x86_64-mm-avoid-temporarily-inconsistent-pte-s.patch
+x86_64-mm-return-correct-error-code-from-child_rip-in-x86_64-entry_s.patch
+x86_64-mm-agp-flush.patch
+x86_64-mm-aout-regs.patch
+x86_64-mm-remove-fpu-port.patch

x86 tree updates

+agp-fix-race-condition-between-unmapping-and-freeing-pages.patch

AGP fix

+convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix-2.patch

Fix convert-cpu_sibling_map-to-a-per_cpu-data-array.patch even more

+x86_64-nx-bit-handling-in-change_page_attr.patch

x86 fix

+kgdb-fix-help-text.patch
+kgdb-fix-docbook-and-kernel-doc-typos.patch

kgdb updates

+usb-dont-propagate-freeze-or-prethaw-suspends.patch
+ppp_mppe-dont-put-interimkey-on-the-stack.patch

Maybe 2.6.23 material

+mm-use-pagevec-to-rotate-reclaimable-page.patch
+mm-use-pagevec-to-rotate-reclaimable-page-fix.patch
+git-nfs-vs-nfs-convert-to-new-aops-fix.patch
+slub-avoid-touching-page-struct-when-freeing-to-per-cpu-slab-fix.patch
+fix-memory-hot-remove-not-configured-case.patch
+fix-memory-hot-remove-not-configured-case-fix.patch
+mm-per-device-dirty-threshold-fix.patch

MM updates

+oom-move-prototypes-to-appropriate-header-file.patch
+oom-move-constraints-to-enum.patch
+oom-change-all_unreclaimable-zone-member-to-flags.patch
+oom-change-all_unreclaimable-zone-member-to-flags-fix.patch
+oom-add-per-zone-locking.patch
+oom-serialize-out-of-memory-calls.patch
+oom-add-oom_kill_allocating_task-sysctl.patch
+oom-suppress-extraneous-stack-and-memory-dump.patch
+oom-compare-cpuset-mems_allowed-instead-of-exclusive.patch
+oom-do-not-take-callback_mutex.patch
+oom-do-not-take-callback_mutex-fix.patch

oom-killer work

+alpha-beautify-vmlinuxlds.patch

alpha cleanup

+tty-bring-the-old-cris-driver-back-somewhere-into-the.patch

cris update

+uml-stop-saving-process-fp-state-fix.patch

Fix uml-stop-saving-process-fp-state.patch

+uml-rename-pt_regs-general-purpose-register-file-fix.patch

Fix uml-rename-pt_regs-general-purpose-register-file.patch

+uml-eliminate-hz.patch
+uml-fix-timer-switching.patch
+uml-simplify-interval-setting.patch
+uml-separate-timer-initialization.patch
+uml-generic_time-support.patch
+uml-generic_clockevents-support.patch
+uml-clocksource-support.patch
+uml-clocksource-support-fix.patch
+uml-tickless-support.patch
+uml-tickless-support-fix.patch
+uml-eliminate-interrupts-in-the-idle-loop.patch
+uml-eliminate-sigalrm.patch
+uml-use-sec_per_sec-constants.patch

UML updates

-remove-superfluous-definition-of-__setup_null_param-macro-and-broken-for-module-__setup_param.patch

Dropped

+keys-make-request_key-and-co-fundamentally-asynchronous-update.patch
+keys-missing-word-in-documentation.patch

Fix keys-make-request_key-and-co-fundamentally-asynchronous.patch

+jbd-slab-cleanups-2.patch
+jbd-slab-cleanups-3.patch

Fix jbd-slab-cleanups.patch

+shrink_dcache_sb-speedup.patch
+add-consts-where-appropriate-in-fs-nls.patch
+reiserfs-workaround-for-dead-loop-in-finish_unfinished.patch
+reiserfs-workaround-for-dead-loop-in-finish_unfinished-fix.patch
+unify-dma_bit_mask-definitions-v31.patch
+delete-gcc-295-compatible-structure-definition.patch
+fs-isofs-nameic-remove-uninitialized-local-vars-warning.patch
+ide-cd-is-unmaintained.patch
+tty-expose-new-methods-needed-for-drivers-to-get-termios.patch
+tty-expose-new-methods-needed-for-drivers-to-get-termios-fix.patch
+kernel-printkc-concerns-about-the-console-handover.patch
+atomic_opstxt-has-incorrect-misleading-and-insufficient-information.patch
+udf-code-style-fixup-v3.patch
+aio-dont-confuse-debug-define-location.patch
+userc-deinline.patch
+userc-ifdef-mq_bytes.patch
+userc-ifdef-mq_bytes-fix.patch

Misc

+isdn-hisax-hfc_usbc-fix-check-after-use.patch

ISDN fix

+ecryptfs-remove-header_extent_size.patch
+ecryptfs-remove-assignments-in-if-statements.patch
+ecryptfs-read_writec-routines.patch
+ecryptfs-replace-encrypt-decrypt-and-inode-size-write.patch
+ecryptfs-set-up-and-destroy-persistent-lower-file.patch
+ecryptfs-update-metadata-read-write-functions.patch
+ecryptfs-make-open-truncate-and-setattr-use-persistent-file.patch
+ecryptfs-convert-mmap-functions-to-use-persistent-file.patch
+ecryptfs-convert-mmap-functions-to-use-persistent-file-fix.patch
+ecryptfs-initialize-persistent-lower-file-on-inode-create.patch
+ecryptfs-remove-unused-functions-and-kmem_cache.patch
+ecryptfs-replace-magic-numbers.patch

ecryptfs update (ugly, can't think of a better way, needs better review)

+radeonfb-xpress-200m-rc410-support-patch.patch
+drivers-video-pmag-ba-fbc-improve-diagnostics.patch
+drivers-video-pmag-ba-fbc-improve-diagnostics-fix.patch

fbdev updates

+ext4-uninitialized-block-groups.patch
+ext4-uninitialized-block-groups-fix.patch
+introduce-ext4_find_next_bit.patch
+ext4-fix-sparse-warnings.patch
+ext4-flex_bg-kernel-support-v2.patch

ext4 stuff

+ecryptfs-allow-lower-fs-to-interpret-attr_kill_sid.patch
+knfsd-only-set-attr_kill_sid-if-attr_mode-isnt-being-explicitly-set.patch
+reiserfs-turn-of-attr_kill_sid-at-beginning-of-reiserfs_setattr.patch
+unionfs-fix-unionfs_setattr-to-handle-attr_kill_sid.patch
+vfs-make-notify_change-pass-attr_kill_sid-to-setattr-operations.patch
+nfs-if-attr_kill_sid-bits-are-set-then-skip-mode-change.patch
+cifs-ignore-mode-change-if-its-just-for-clearing-setuid-setgid-bits.patch

VFS attributes work

+r-o-bind-mounts-filesystem-helpers-for-custom-struct-files.patch
+r-o-bind-mounts-rearrange-may_open-to-be-r-o-friendly.patch
+r-o-bind-mounts-give-permission-a-local-mnt-variable.patch
+r-o-bind-mounts-create-cleanup-helper-svc_msnfs.patch
+r-o-bind-mounts-stub-functions.patch
+r-o-bind-mounts-elevate-write-count-opend-files.patch
+r-o-bind-mounts-elevate-write-count-for-some-ioctls.patch
+r-o-bind-mounts-elevate-writer-count-for-chown-and-friends.patch
+r-o-bind-mounts-make-access-use-mnt-check.patch
+r-o-bind-mounts-elevate-mnt-writers-for-callers-of-vfs_mkdir.patch
+r-o-bind-mounts-elevate-write-count-during-entire-ncp_ioctl.patch
+r-o-bind-mounts-elevate-write-count-during-entire-ncp_ioctl-fix.patch
+r-o-bind-mounts-elevate-write-count-for-link-and-symlink-calls.patch
+r-o-bind-mounts-elevate-mount-count-for-extended-attributes.patch
+r-o-bind-mounts-elevate-write-count-for-file_update_time.patch
+r-o-bind-mounts-unix_find_other-elevate-write-count-for-touch_atime.patch
+r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename.patch
+r-o-bind-mounts-nfs-check-mnt-instead-of-superblock-directly.patch
+r-o-bind-mounts-elevate-writer-count-for-do_sys_truncate.patch
+r-o-bind-mounts-elevate-write-count-for-do_utimes.patch
+r-o-bind-mounts-elevate-write-count-for-do_sys_utime-and-touch_atime.patch
+r-o-bind-mounts-sys_mknodat-elevate-write-count-for-vfs_mknod-create.patch
+r-o-bind-mounts-elevate-mnt-writers-for-vfs_unlink-callers.patch
+r-o-bind-mounts-do_rmdir-elevate-write-count.patch
+r-o-bind-mounts-track-number-of-mount-writers.patch
+r-o-bind-mounts-track-number-of-mount-writers-hack-hack-hack.patch
+r-o-bind-mounts-honor-r-w-changes-at-do_remount-time.patch

read-only bind mounts

+add-a-missing-00-index-file-for-documentation-vm-fix.patch

Fix add-a-missing-00-index-file-for-documentation-vm.patch

+remove-broken-netfilter-binary-sysctls-from-bridging-code.patch

sysctl fixes

+make-access-to-tasks-nsproxy-lighterpatch-breaks-unshare.patch

Fix make-access-to-tasks-nsproxy-lighter.patch

-isolate-some-explicit-usage-of-task-tgid-fix.patch
-isolate-some-explicit-usage-of-task-tgid-fix-fix.patch

Folded into isolate-some-explicit-usage-of-task-tgid.patch

+memory-controller-oom-handling-v7-vs-oom-killer-stuff.patch

Fix memory-controller-oom-handling-v7.patch

+mem-controller-gfp-mask-fix.patch

Fix memory-controller patches in -mm.

+ipc-integrate-ipc_checkid-into-ipc_lock-fix-2.patch
+ipc-integrate-ipc_checkid-into-ipc_lock-fix-3.patch

Fix ipc-integrate-ipc_checkid-into-ipc_lock-fix.patch

+ipc_fix_wrong_comments.patch

Fix ipc comments

+extended-crashkernel-command-line.patch
+use-extended-crashkernel-command-line-on-i386.patch
+use-extended-crashkernel-command-line-on-x86_64.patch
+use-extended-crashkernel-command-line-on-ia64.patch
+use-extended-crashkernel-command-line-on-ppc64.patch
+use-extended-crashkernel-command-line-on-sh.patch
+add-documentation-for-extended-crashkernel-syntax.patch

kdump stuff

+cleanup-macros-for-distinguishing-mandatory-locks.patch
+gfs2-cleanup-explicit-check-for-mandatory-locks.patch
+9pfs-cleanup-explicit-check-for-mandatory-locks.patch
+afs-cleanup-explicit-check-for-mandatory-locks.patch
+nfs-cleanup-explicit-check-for-mandatory-locks.patch
+rework-proc-locks-via-seq_files-and-seq_list-helpers.patch
+rework-proc-locks-via-seq_files-and-seq_list-helpers-fix.patch
+rework-proc-locks-via-seq_files-and-seq_list-helpers-fix-2.patch

file locking rework

+exportfs-add-fid-type.patch
+exportfs-add-new-methods.patch
+ext2-new-export-ops.patch
+ext3-new-export-ops.patch
+ext4-new-export-ops.patch
+efs-new-export-ops.patch
+jfs-new-export-ops.patch
+ntfs-new-export-ops.patch
+xfs-new-export-ops.patch
+fat-new-export-ops.patch
+isofs-new-export-ops.patch
+shmem-new-export-ops.patch
+reiserfs-new-export-ops.patch
+gfs2-new-export-ops.patch
+ocfs2-new-export-ops.patch
+exportfs-remove-old-methods.patch
+exportfs-make-struct-export_operations-const.patch
+exportfs-update-documentation.patch

nfsd export rework


5392 commits in 2031 patch files


All patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/patch-list


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kamalesh Babulal]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32

<snip>

Hi Andrew,

The link error for a PowerMac G5 (powerpc) is still seen with
2.6.23-rc7-mm1,
and was reported for 2.6.23-rc6-mm1 (http://lkml.org/lkml/2007/9/19/62).

KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sam Ravnborg]

Hi Kamalesh.

Post by Kamalesh Babulal
The link error for a PowerMac G5 (powerpc) is still seen with
2.6.23-rc7-mm1,
and was reported for 2.6.23-rc6-mm1 (http://lkml.org/lkml/2007/9/19/62).
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1

Can you try to narrow it down a bit further...
As this happens when building fs/built-in.o it should be
straightforward to do so.

First step would be to do:
rm fs/built-in.o
make fs/ V=1

Then copy the ld invocation and try to remove the input .o files one-by-one.
This should tell you which .o file is causing the bug.

Next step is to try to squeze down the offending file until the
errornous part remains.

Last time I did a
make fs/file.i

And then I used gcc & ld to compile and link.
Gradually removing stuff from file.i made me spot the problem
with the weak prototype in a header file.

I guess something else is making ld hit this error now.

PS. Just reinstalled my dev box so no crosscompiler atm.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Sam Ravnborg]

Post by Sam Ravnborg
Hi Kamalesh.

Post by Kamalesh Babulal
The link error for a PowerMac G5 (powerpc) is still seen with
2.6.23-rc7-mm1,
and was reported for 2.6.23-rc6-mm1 (http://lkml.org/lkml/2007/9/19/62).
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1

Can you try to narrow it down a bit further...
As this happens when building fs/built-in.o it should be
straightforward to do so.
rm fs/built-in.o
make fs/ V=1
Then copy the ld invocation and try to remove the input .o files one-by-one.
This should tell you which .o file is causing the bug.
Next step is to try to squeze down the offending file until the
errornous part remains.
Last time I did a
make fs/file.i
And then I used gcc & ld to compile and link.
Gradually removing stuff from file.i made me spot the problem
with the weak prototype in a header file.
I guess something else is making ld hit this error now.
PS. Just reinstalled my dev box so no crosscompiler atm.

Got powerpc toolchain running now but cannot reproduce.
What config do you use (I used g5_defconfig)?
And what ld version?

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kamalesh Babulal]

Post by Sam Ravnborg

Post by Sam Ravnborg
Hi Kamalesh.

Post by Kamalesh Babulal
The link error for a PowerMac G5 (powerpc) is still seen with
2.6.23-rc7-mm1,
and was reported for 2.6.23-rc6-mm1 (http://lkml.org/lkml/2007/9/19/62).
KSYM .tmp_kallsyms1.S
AS .tmp_kallsyms1.o
LD .tmp_vmlinux2
KSYM .tmp_kallsyms2.S
AS .tmp_kallsyms2.o
LD vmlinux.o
ld: dynreloc miscount for fs/built-in.o, section .opd
ld: can not edit opd Bad value
make: *** [vmlinux.o] Error 1

Can you try to narrow it down a bit further...
As this happens when building fs/built-in.o it should be
straightforward to do so.
rm fs/built-in.o
make fs/ V=1
Then copy the ld invocation and try to remove the input .o files one-by-one.
This should tell you which .o file is causing the bug.
Next step is to try to squeze down the offending file until the
errornous part remains.
Last time I did a
make fs/file.i
And then I used gcc & ld to compile and link.
Gradually removing stuff from file.i made me spot the problem
with the weak prototype in a header file.
I guess something else is making ld hit this error now.
PS. Just reinstalled my dev box so no crosscompiler atm.

Got powerpc toolchain running now but cannot reproduce.
What config do you use (I used g5_defconfig)?
And what ld version?
Sam

Hi Sam,

***@elm3b19:~# ld -v
GNU ld version 2.16.1 Debian GNU/Linux

***@elm3b19:~# gcc -v
Using built-in specs.
Target: powerpc-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --disable-werror --enable-checking=release powerpc-linux-gnu
Thread model: posix
gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)

and the .config file is a custom file which i have attached.

[V***@vt.edu]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

It lived fast, it died young, it didn't leave a pretty corpse...

Something in the startup scripts did a 'touch', and ker-blam.

[ 15.668000] Unable to handle kernel NULL pointer dereference at 0000000000000252 RIP:
[ 15.668000] [<ffffffff802a1dd1>] __mnt_is_readonly+0x9/0x1e
[ 15.668000] PGD 52be067 PUD 5645067 PMD 0
[ 15.668000] Oops: 0000 [1] PREEMPT SMP
[ 15.668000] last sysfs file: /block/dm-13/dev
[ 15.668000] CPU 0
[ 15.668000] Modules linked in: rtc
[ 15.668000] Pid: 528, comm: touch Not tainted 2.6.23-rc7-mm1 #1
[ 15.668000] RIP: 0010:[<ffffffff802a1dd1>] [<ffffffff802a1dd1>] __mnt_is_readonly+0x9/0x1e
[ 15.668000] RSP: 0018:ffff8100045fddd8 EFLAGS: 00010202
[ 15.668000] RAX: 0000000000000001 RBX: ffff810002c10680 RCX: 0000000000000001
[ 15.668000] RDX: ffff810082504000 RSI: ffff810005243168 RDI: 0000000000000202
[ 15.668000] RBP: ffff8100045fddd8 R08: 0000000000000001 R09: 0000000000000002
[ 15.668000] R10: 0000000000000000 R11: ffff8100045fde68 R12: 0000000000000202
[ 15.668000] R13: 00000000ffffffe2 R14: ffff8100052c1d80 R15: ffff8100039aa8a0
[ 15.668000] FS: 00007f9527f596f0(0000) GS:ffffffff806b6000(0000) knlGS:0000000000000000
[ 15.668000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 15.668000] CR2: 0000000000000252 CR3: 00000000052cb000 CR4: 00000000000006e0
[ 15.668000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 15.668000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 15.668000] Process touch (pid: 528, threadinfo ffff8100045fc000, task ffff8100047517e0)
[ 15.668000] last branch before last exception/interrupt
[ 15.668000] from [<ffffffff802a4d1b>] mnt_want_write+0x44/0xb5
[ 15.668000] to [<ffffffff802a1dc8>] __mnt_is_readonly+0x0/0x1e
[ 15.668000] Stack: ffff8100045fde08 ffffffff802a4d20 ffff8100045fddf8 0000000000000000
[ 15.668000] 00000000fffffff7 ffff810005243140 ffff8100045fdf28 ffffffff802ad288
[ 15.668000] ffff8100045fde58 0000000000000202 ffff8100045fde58 ffffffff8035437b
[ 15.668000] Call Trace:
[ 15.668000] [<ffffffff802a4d20>] mnt_want_write+0x49/0xb5
[ 15.668000] [<ffffffff802ad288>] do_utimes+0xd0/0x220
[ 15.668000] [<ffffffff8035437b>] __up_read+0x7a/0x83
[ 15.668000] [<ffffffff8024b1af>] up_read+0x9/0xb
[ 15.668000] [<ffffffff8051977c>] do_page_fault+0x421/0x7d0
[ 15.668000] [<ffffffff8028b370>] do_filp_open+0x36/0x46
[ 15.668000] [<ffffffff802ad519>] sys_utimensat+0x8b/0xa5
[ 15.668000] [<ffffffff80517a4d>] error_exit+0x0/0x84
[ 15.668000] [<ffffffff8020c10e>] system_call+0x7e/0x83
[ 15.668000]
[ 15.668000]
[ 15.668000] Code: f6 47 50 40 75 0d 48 8b 47 28 8a 40 58 83 e0 01 0f b6 c0 c9
[ 15.668000] RIP [<ffffffff802a1dd1>] __mnt_is_readonly+0x9/0x1e
[ 15.668000] RSP <ffff8100045fddd8>
[ 15.668000] CR2: 0000000000000252

[Balbir Singh]

Post by V***@vt.edu

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

It lived fast, it died young, it didn't leave a pretty corpse...
Something in the startup scripts did a 'touch', and ker-blam.
[ 15.668000] [<ffffffff802a1dd1>] __mnt_is_readonly+0x9/0x1e
[ 15.668000] PGD 52be067 PUD 5645067 PMD 0
[ 15.668000] Oops: 0000 [1] PREEMPT SMP
[ 15.668000] last sysfs file: /block/dm-13/dev
[ 15.668000] CPU 0
[ 15.668000] Modules linked in: rtc
[ 15.668000] Pid: 528, comm: touch Not tainted 2.6.23-rc7-mm1 #1
[ 15.668000] RIP: 0010:[<ffffffff802a1dd1>] [<ffffffff802a1dd1>] __mnt_is_readonly+0x9/0x1e
[ 15.668000] RSP: 0018:ffff8100045fddd8 EFLAGS: 00010202
[ 15.668000] RAX: 0000000000000001 RBX: ffff810002c10680 RCX: 0000000000000001
[ 15.668000] RDX: ffff810082504000 RSI: ffff810005243168 RDI: 0000000000000202
[ 15.668000] RBP: ffff8100045fddd8 R08: 0000000000000001 R09: 0000000000000002
[ 15.668000] R10: 0000000000000000 R11: ffff8100045fde68 R12: 0000000000000202
[ 15.668000] R13: 00000000ffffffe2 R14: ffff8100052c1d80 R15: ffff8100039aa8a0
[ 15.668000] FS: 00007f9527f596f0(0000) GS:ffffffff806b6000(0000) knlGS:0000000000000000
[ 15.668000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 15.668000] CR2: 0000000000000252 CR3: 00000000052cb000 CR4: 00000000000006e0
[ 15.668000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 15.668000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 15.668000] Process touch (pid: 528, threadinfo ffff8100045fc000, task ffff8100047517e0)
[ 15.668000] last branch before last exception/interrupt
[ 15.668000] from [<ffffffff802a4d1b>] mnt_want_write+0x44/0xb5
[ 15.668000] to [<ffffffff802a1dc8>] __mnt_is_readonly+0x0/0x1e
[ 15.668000] Stack: ffff8100045fde08 ffffffff802a4d20 ffff8100045fddf8 0000000000000000
[ 15.668000] 00000000fffffff7 ffff810005243140 ffff8100045fdf28 ffffffff802ad288
[ 15.668000] ffff8100045fde58 0000000000000202 ffff8100045fde58 ffffffff8035437b
[ 15.668000] [<ffffffff802a4d20>] mnt_want_write+0x49/0xb5
[ 15.668000] [<ffffffff802ad288>] do_utimes+0xd0/0x220
[ 15.668000] [<ffffffff8035437b>] __up_read+0x7a/0x83
[ 15.668000] [<ffffffff8024b1af>] up_read+0x9/0xb
[ 15.668000] [<ffffffff8051977c>] do_page_fault+0x421/0x7d0
[ 15.668000] [<ffffffff8028b370>] do_filp_open+0x36/0x46
[ 15.668000] [<ffffffff802ad519>] sys_utimensat+0x8b/0xa5
[ 15.668000] [<ffffffff80517a4d>] error_exit+0x0/0x84
[ 15.668000] [<ffffffff8020c10e>] system_call+0x7e/0x83
[ 15.668000]
[ 15.668000]
[ 15.668000] Code: f6 47 50 40 75 0d 48 8b 47 28 8a 40 58 83 e0 01 0f b6 c0 c9
[ 15.668000] RIP [<ffffffff802a1dd1>] __mnt_is_readonly+0x9/0x1e
[ 15.668000] RSP <ffff8100045fddd8>
[ 15.668000] CR2: 0000000000000252

CC'ing Dave, he might be interested in looking into this. Do you know
which file was touched. I suspect either mnt or mnt_sb is NULL in
__mnt_is_readonly(). mnt is extracted from the nameidata structure.
It's interesting to see utimenstat in the stack, I suspect that
the filename was probably NULL and dfd was something other than
AT_FDCWD (Just a wild guess). I'll try to reproduce your problem.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Christoph Hellwig]

Post by V***@vt.edu

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

It lived fast, it died young, it didn't leave a pretty corpse...
Something in the startup scripts did a 'touch', and ker-blam.
[ 15.668000] [<ffffffff802a4d20>] mnt_want_write+0x49/0xb5
[ 15.668000] [<ffffffff802ad288>] do_utimes+0xd0/0x220
[ 15.668000] [<ffffffff8035437b>] __up_read+0x7a/0x83
[ 15.668000] [<ffffffff8024b1af>] up_read+0x9/0xb
[ 15.668000] [<ffffffff8051977c>] do_page_fault+0x421/0x7d0
[ 15.668000] [<ffffffff8028b370>] do_filp_open+0x36/0x46
[ 15.668000] [<ffffffff802ad519>] sys_utimensat+0x8b/0xa5
[ 15.668000] [<ffffffff80517a4d>] error_exit+0x0/0x84
[ 15.668000] [<ffffffff8020c10e>] system_call+0x7e/0x83

do_times passes an unitialized vfsmount into mnt_want_write. Here's
the quick fix (untested), but the right fix is to restructure the complete
mess do_utimes is (never let a libc developer write your kernel code.. :)):


Index: linux-2.6.23-rc6/fs/utimes.c
===================================================================
--- linux-2.6.23-rc6.orig/fs/utimes.c 2007-09-24 14:02:24.000000000 +0200
+++ linux-2.6.23-rc6/fs/utimes.c 2007-09-24 14:03:57.000000000 +0200
@@ -59,6 +59,7 @@ long do_utimes(int dfd, char __user *fil
struct inode *inode;
struct iattr newattrs;
struct file *f = NULL;
+ struct vfsmount *mnt;

error = -EINVAL;
if (times && (!nsec_valid(times[0].tv_nsec) ||
@@ -79,17 +80,19 @@ long do_utimes(int dfd, char __user *fil
if (!f)
goto out;
dentry = f->f_path.dentry;
+ mnt = f->f_path.mnt;
} else {
error = __user_walk_fd(dfd, filename, (flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW, &nd);
if (error)
goto out;

dentry = nd.dentry;
+ mnt = nd.mnt;
}

inode = dentry->d_inode;

- error = mnt_want_write(nd.mnt);
+ error = mnt_want_write(mnt);
if (error)
goto dput_and_out;



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[V***@vt.edu]

Post by Christoph Hellwig

Post by V***@vt.edu

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

It lived fast, it died young, it didn't leave a pretty corpse...

(adding Dave Hansen to the cc: list, his patch added the mnt_want_write stuff)

Post by Christoph Hellwig
do_times passes an unitialized vfsmount into mnt_want_write. Here's
the quick fix (untested), but the right fix is to restructure the complete

Close - it still blew up, as one reference to nd.mnt remained. Fixed patch
is appended - system boots all the way with this applied.

--- linux-2.6.23-rc7-mm1/fs/utimes.c.dist 2007-09-24 05:57:38.000000000 -0400
+++ linux-2.6.23-rc7-mm1/fs/utimes.c 2007-09-24 08:48:34.000000000 -0400
@@ -59,6 +59,7 @@ long do_utimes(int dfd, char __user *fil
struct inode *inode;
struct iattr newattrs;
struct file *f = NULL;
+ struct vfsmount *mnt;

error = -EINVAL;
if (times && (!nsec_valid(times[0].tv_nsec) ||
@@ -79,17 +80,19 @@ long do_utimes(int dfd, char __user *fil
if (!f)
goto out;
dentry = f->f_path.dentry;
+ mnt = f->f_path.mnt;
} else {
error = __user_walk_fd(dfd, filename, (flags & AT_SYMLINK_NOFOLLOW) ? 0 : LOOKUP_FOLLOW, &nd);
if (error)
goto out;

dentry = nd.dentry;
+ mnt = nd.mnt;
}

inode = dentry->d_inode;

- error = mnt_want_write(nd.mnt);
+ error = mnt_want_write(mnt);
if (error)
goto dput_and_out;

@@ -135,7 +138,7 @@ long do_utimes(int dfd, char __user *fil
error = notify_change(dentry, &newattrs);
mutex_unlock(&inode->i_mutex);
mnt_drop_write_and_out:
- mnt_drop_write(nd.mnt);
+ mnt_drop_write(mnt);
dput_and_out:
if (f)
fput(f);

[Dave Hansen]

Post by V***@vt.edu

Post by Christoph Hellwig
do_times passes an unitialized vfsmount into mnt_want_write. Here's
the quick fix (untested), but the right fix is to restructure the complete

Close - it still blew up, as one reference to nd.mnt remained. Fixed patch
is appended - system boots all the way with this applied.

Any idea which fs and distro this was? I'd like to add it to my tests.

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[V***@vt.edu]

Post by Dave Hansen
Any idea which fs and distro this was? I'd like to add it to my tests.

initscripts-8.56-1, from Fedora Rawhide, /etc/rc.sysinit, line 325:

touch /dev/.in_sysinit >/dev/null 2>&1

Specific enough? :)

[WANG Cong]

This patch:
- makes hidp_setup_input() return int to indicate errors;
- checks its return value to handle errors.

And this time it is against -rc7-mm1 tree.

Thanks to roel and Marcel Holtmann for comments.

Signed-off-by: WANG Cong <***@gmail.com>

---
net/bluetooth/hidp/core.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)

Index: linux-2.6.23-rc7-mm1/net/bluetooth/hidp/core.c
===================================================================
--- linux-2.6.23-rc7-mm1.orig/net/bluetooth/hidp/core.c
+++ linux-2.6.23-rc7-mm1/net/bluetooth/hidp/core.c
@@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
return conn ? &conn->dev : NULL;
}

-static inline void hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
+static inline int hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
{
struct input_dev *input = session->input;
int i;
@@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru

input->event = hidp_input_event;

- input_register_device(input);
+ return input_register_device(input);
}

static int hidp_open(struct hid_device *hid)
@@ -822,8 +822,11 @@ int hidp_add_connection(struct hidp_conn
session->flags = req->flags & (1 << HIDP_BLUETOOTH_VENDOR_ID);
session->idle_to = req->idle_to;

- if (session->input)
- hidp_setup_input(session, req);
+ if (session->input) {
+ err = hidp_setup_input(session, req);
+ if (err < 0)
+ goto failed;
+ }

if (session->hid)
hidp_setup_hid(session, req);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Marcel Holtmann]

Hi Wang,

Post by WANG Cong
- makes hidp_setup_input() return int to indicate errors;
- checks its return value to handle errors.
And this time it is against -rc7-mm1 tree.
Thanks to roel and Marcel Holtmann for comments.

Signed-off-by: Marcel Holtmann <***@holtmann.org>

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[David Miller]

From: Marcel Holtmann <***@holtmann.org>
Date: Tue, 25 Sep 2007 00:18:07 +0200

Post by Marcel Holtmann
Hi Wang,

Post by WANG Cong
- makes hidp_setup_input() return int to indicate errors;
- checks its return value to handle errors.
And this time it is against -rc7-mm1 tree.
Thanks to roel and Marcel Holtmann for comments.

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kamalesh Babulal]

Hi Andrew,

The kernel build fails with

CC arch/ia64/kernel/efi.o
arch/ia64/kernel/efi.c: In function 'efi_memmap_init':
arch/ia64/kernel/efi.c:1088: error: 'total_memory' undeclared (first use in this function)
arch/ia64/kernel/efi.c:1088: error: (Each undeclared identifier is reported only once
arch/ia64/kernel/efi.c:1088: error: for each function it appears in.)
make[1]: *** [arch/ia64/kernel/efi.o] Error 1
make: *** [arch/ia64/kernel] Error 2

The use-extended-crashkernel-command-line-on-ia64.patch uses total_mem and
return total_memory.

Signed-off-by: Kamalesh Babulal <***@linux.vnet.ibm.com>
---
--- linux-2.6.23-rc7/arch/ia64/kernel/efi.c 2007-09-24 15:28:06.000000000 +0530
+++ linux-2.6.23-rc7/arch/ia64/kernel/~efi.c 2007-09-24 16:56:03.000000000 +0530
@@ -1085,7 +1085,7 @@ efi_memmap_init(unsigned long *s, unsign
*s = (u64)kern_memmap;
*e = (u64)++k;

- return total_memory;
+ return total_mem;
}

void
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andy Whitcroft]

Getting compile errors on S390:

CC arch/s390/mm/cmm.o
arch/s390/mm/cmm.c: In function `cmm_init':
arch/s390/mm/cmm.c:431: error: implicit declaration of function
`register_oom_notifier'
arch/s390/mm/cmm.c:443: error: implicit declaration of function
`unregister_oom_notifier'
make[1]: *** [arch/s390/mm/cmm.o] Error 1
make: *** [arch/s390/mm] Error 2

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Cedric Le Goater]

Post by Andy Whitcroft
CC arch/s390/mm/cmm.o
arch/s390/mm/cmm.c:431: error: implicit declaration of function
`register_oom_notifier'
arch/s390/mm/cmm.c:443: error: implicit declaration of function
`unregister_oom_notifier'
make[1]: *** [arch/s390/mm/cmm.o] Error 1
make: *** [arch/s390/mm] Error 2

yes. It's from oom-move-prototypes-to-appropriate-header-file.patch.

I think this patch fixes it.

C.

Signed-off-by: Cedric Le Goater <***@fr.ibm.com>
---
arch/s390/mm/cmm.c | 1 +
1 file changed, 1 insertion(+)

Index: 2.6.23-rc7-mm1/arch/s390/mm/cmm.c
===================================================================
--- 2.6.23-rc7-mm1.orig/arch/s390/mm/cmm.c
+++ 2.6.23-rc7-mm1/arch/s390/mm/cmm.c
@@ -17,6 +17,7 @@
#include <linux/ctype.h>
#include <linux/swap.h>
#include <linux/kthread.h>
+#include <linux/oom.h>

#include <asm/pgalloc.h>
#include <asm/uaccess.h>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jiri Slaby]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

Fine, but on some boots (I noticed this on rc6-mm1 too, but not before):
0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001

# lspci -vns 0000:00:1a.7
00:1a.7 0c03: 8086:293c (rev 02) (prog-if 20 [EHCI])
Subsystem: 8086:293c
Flags: bus master, medium devsel, latency 0, IRQ 19
Memory at ffa7b400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port
Capabilities: [98] Vendor Specific Information

# lspci -vns 0000:00:1d.7
00:1d.7 0c03: 8086:293a (rev 02) (prog-if 20 [EHCI])
Subsystem: 8086:293a
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at ffa7b000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port
Capabilities: [98] Vendor Specific Information

regards,

[Alan Stern]

Post by Jiri Slaby

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001

Any changes in your BIOS setup?

What about with vanilla 2.6.23-rc6? Or vanilla 2.6.23-rc7?

The USB part of the code here hasn't changed in quite a while. Any
difference in behavior must be the result of changes in some other part
of the kernel. Possibly ACPI.

This might be a good job for git-bisect.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jiri Slaby]

Post by Alan Stern

Post by Jiri Slaby

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001

Any changes in your BIOS setup?

unlikely, but still possible -- I've made some changes in BIOS recently when I
looking backwards. Which concrete changes would turn it in such behaviour?

Post by Alan Stern
What about with vanilla 2.6.23-rc6? Or vanilla 2.6.23-rc7?
The USB part of the code here hasn't changed in quite a while. Any
difference in behavior must be the result of changes in some other part
of the kernel. Possibly ACPI.
This might be a good job for git-bisect.

Ok, I'll play with that little bit.

thanks,

[Alan Stern]

Post by Jiri Slaby

Post by Alan Stern

Post by Jiri Slaby

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001

Any changes in your BIOS setup?

unlikely, but still possible -- I've made some changes in BIOS recently when I
looking backwards. Which concrete changes would turn it in such behaviour?

USB Legacy Support is about the only change which springs to mind. But
who knows... A buggy BIOS could do almost anything.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jiri Slaby]

Post by Alan Stern

Post by Jiri Slaby

Post by Alan Stern

Post by Jiri Slaby

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

0000:00:1a.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
0000:00:1d.7 EHCI: BIOS handoff failed (BIOS bug ?) 01010001

Any changes in your BIOS setup?

unlikely, but still possible -- I've made some changes in BIOS recently when I
looking backwards. Which concrete changes would turn it in such behaviour?

USB Legacy Support is about the only change which springs to mind. But
who knows... A buggy BIOS could do almost anything.

Hmm, I have usb legacy keyboard switched on because of grub and bios to allow me
typing.

I booted 23-rc7 4 times, and the latest -mm 3 times just now and can't reproduce
it, I just wonder by what is this conditioned.

regards,

[Alan Stern]

Post by Jiri Slaby
Hmm, I have usb legacy keyboard switched on because of grub and bios to allow me
typing.
I booted 23-rc7 4 times, and the latest -mm 3 times just now and can't reproduce
it, I just wonder by what is this conditioned.

Warm boot vs. cold boot, maybe.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jiri Slaby]

Post by Alan Stern

Post by Jiri Slaby
Hmm, I have usb legacy keyboard switched on because of grub and bios to allow me
typing.
I booted 23-rc7 4 times, and the latest -mm 3 times just now and can't reproduce
it, I just wonder by what is this conditioned.

Warm boot vs. cold boot, maybe.

Hmm, no. I don't know, I can't see it anymore so far (using rc8-mm2). I'll keep
eyes on it, anyways.

thanks,

[Andy Whitcroft]

Seeing the following from an older power LPAR, pretty sure we had
this in the previous -mm also:

Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000047ac8
cpu 0x0: Vector: 300 (Data Access) at [c00000000058f750]
pc: c000000000047ac8: .pSeries_log_error+0x364/0x420
lr: c000000000047a4c: .pSeries_log_error+0x2e8/0x420
sp: c00000000058f9d0
msr: 8000000000001032
dar: 0
dsisr: 42000000
current = 0xc0000000004a9b30
paca = 0xc0000000004aa700
pid = 0, comm = swapper
enter ? for help
[c00000000058faf0] c000000000021164 .rtas_call+0x200/0x250
[c00000000058fba0] c000000000049cd0 .early_enable_eeh+0x168/0x360
[c00000000058fc70] c00000000002f674 .traverse_pci_devices+0x8c/0x138
[c00000000058fd10] c000000000460ce8 .eeh_init+0x1a8/0x200
[c00000000058fdb0] c00000000045fb70 .pSeries_setup_arch+0x128/0x234
[c00000000058fe40] c00000000044f830 .setup_arch+0x214/0x24c
[c00000000058fee0] c000000000446a38 .start_kernel+0xd4/0x3e4
[c00000000058ff90] c000000000373194 .start_here_common+0x54/0x58

This machine is a:

processor : 0
cpu : POWER4+ (gq)
clock : 1703.965296MHz
revision : 19.0

[...]

timebase : 212995662
machine : CHRP IBM,7040-681

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Linas Vepstas]

Post by Andy Whitcroft
Seeing the following from an older power LPAR, pretty sure we had

I haven't forgetten about this ... and am looking at it now.
Seems that whenever I go to reserve the machine pSeries-102,
someone else is using it :-)

--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Tony Breeds]

Post by Linas Vepstas

Post by Andy Whitcroft
Seeing the following from an older power LPAR, pretty sure we had

I haven't forgetten about this ... and am looking at it now.
Seems that whenever I go to reserve the machine pSeries-102,
someone else is using it :-)

This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
(79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
branch. It looks to me that we have logging enabled too early now.

I think the following is a reasonable fix?

---
Explicitly enable RTAS error logging, when it should be ready.


Signed-off-by: Tony Breeds <***@bakeyournoodle.com>

---

arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..0df5d0d 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;

/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
+static int no_more_logging = 1; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
+

static int error_log_cnt;

@@ -414,6 +417,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ no_more_logging = 0;

if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {

Yours Tony

linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Michael Ellerman]

Post by Tony Breeds

Post by Linas Vepstas

Post by Andy Whitcroft
Seeing the following from an older power LPAR, pretty sure we had

I haven't forgetten about this ... and am looking at it now.
Seems that whenever I go to reserve the machine pSeries-102,
someone else is using it :-)

This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
(79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
branch. It looks to me that we have logging enabled too early now.
I think the following is a reasonable fix?
---
Explicitly enable RTAS error logging, when it should be ready.
---
arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..0df5d0d 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
+static int no_more_logging = 1; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
+

I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.

cheers

[Tony Breeds]

Post by Michael Ellerman
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.

Sure, what about?

Clarify when RTAS logging is enabled.

Signed-off-by: Tony Breeds <***@bakeyournoodle.com>

---
arch/powerpc/platforms/pseries/rtasd.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..73401c8 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;

/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
-
+static int logging_enabled; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
static int error_log_cnt;

/*
@@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
}

/* Write error to NVRAM */
- if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
+ if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
nvram_write_error_log(buf, len, err_type, error_log_cnt);

/*
@@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
printk_log_rtas(buf, len);

/* Check to see if we need to or have stopped logging */
- if (fatal || no_more_logging) {
- no_more_logging = 1;
+ if (fatal || !logging_enabled) {
+ logging_enabled = 0;
spin_unlock_irqrestore(&rtasd_log_lock, s);
return;
}
@@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,

spin_lock_irqsave(&rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 && !no_more_logging)
+ if (rtas_log_size == 0 && logging_enabled)
nvram_clear_error_log();
spin_unlock_irqrestore(&rtasd_log_lock, s);

@@ -414,6 +415,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ logging_enabled = 1;

if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {

Yours Tony

linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Michael Ellerman]

Post by Tony Breeds

Post by Michael Ellerman
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.

Sure, what about?

Better .. but .. :D

Post by Tony Breeds
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..73401c8 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
-
+static int logging_enabled; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */

Until we initialise what exactly?

Post by Tony Breeds
static int error_log_cnt;
/*
@@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
}
/* Write error to NVRAM */
- if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
+ if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
nvram_write_error_log(buf, len, err_type, error_log_cnt);
/*
@@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
printk_log_rtas(buf, len);
/* Check to see if we need to or have stopped logging */
- if (fatal || no_more_logging) {
- no_more_logging = 1;
+ if (fatal || !logging_enabled) {
+ logging_enabled = 0;
spin_unlock_irqrestore(&rtasd_log_lock, s);
return;
}

Hmmm, this routine has 4 separate lock-dropping exit paths ..

Post by Tony Breeds
@@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
spin_lock_irqsave(&rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 && !no_more_logging)
+ if (rtas_log_size == 0 && logging_enabled)
nvram_clear_error_log();
spin_unlock_irqrestore(&rtasd_log_lock, s);
@@ -414,6 +415,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ logging_enabled = 1;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {

What exactly happens that allows us to do logging? I don't see any
ordering between anything else and the setting of the flag, and AFAICT
we're not inside a spinlock or anything here.

cheers

[Linas Vepstas]

Post by Michael Ellerman
Until we initialise what exactly?

Until we allocate the error log buffer. The original crash was
for a null-pointer deref of the unallocated buffer. I just sent
out a patch to fix this; its a bit simpler than the below.

In that email, I remarked:

Andy Whitcroft's crash was appearently due to firmware complaining
about lost power, (actually, lost power supply redundancy!), which
occurred very early during boot.

Type 00000040 (EPOW)
Status: bypassed new
Residual error from previous boot.
EPOW Sensor Value: 00000002
EPOW warning due to loss of redundancy.
EPOW general power fault.

I've no clue why firmware thought it was OK to report this
during one of the earliest calls to RTAS; I'm still investiigating
that.

--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Nish Aravamudan]

Post by Tony Breeds

Post by Michael Ellerman
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.

Sure, what about?
Clarify when RTAS logging is enabled.

For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.

Tested-by: Nishanth Aravamudan <***@us.ibm.com>

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Linas Vepstas]

Post by Nish Aravamudan

Post by Tony Breeds

Post by Michael Ellerman
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.

Sure, what about?
Clarify when RTAS logging is enabled.

For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.

For the reasons explained, I'd really like to nack Tony's patch.

--linas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Nish Aravamudan]

Post by Linas Vepstas

Post by Nish Aravamudan

Post by Tony Breeds

Post by Michael Ellerman
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.

Sure, what about?
Clarify when RTAS logging is enabled.

For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.

For the reasons explained, I'd really like to nack Tony's patch.

I see. Can you reply in this thread with the patch you mentioned in
your other reply? (or point me to a copy of it)

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Cedric Le Goater]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c: In function `dasd_eckd_build_cp':
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1181: error: syntax error before "struct"
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: `iter' undeclared (first use in this function)
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: (Each undeclared identifier is reported only once
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: for each function it appears in.)
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: `bv' undeclared (first use in this function)
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: statement with no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: statement with no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: statement with no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: statement with no effect
make[3]: *** [drivers/s390/block/dasd_eckd.o] Error 1
make[2]: *** [drivers/s390/block] Error 2

Signed-off-by: Cedric Le Goater <***@fr.ibm.com>
---
drivers/s390/block/dasd_eckd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: 2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c
===================================================================
--- 2.6.23-rc7-mm1.orig/drivers/s390/block/dasd_eckd.c
+++ 2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c
@@ -1176,7 +1176,7 @@ dasd_eckd_build_cp(struct dasd_device *
struct LO_eckd_data *LO_data;
struct dasd_ccw_req *cqr;
struct ccw1 *ccw;
- struct req_iterator iter
+ struct req_iterator iter;
struct bio_vec *bv;
char *dst;
unsigned int blksize, blk_per_trk, off;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jens Axboe]

Post by Cedric Le Goater

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1181: error: syntax error before "struct"
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: `iter' undeclared (first use in this function)
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: (Each undeclared identifier is reported only once
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: for each function it appears in.)
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: error: `bv' undeclared (first use in this function)
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: left-hand operand of comma expression has no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: statement with no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1209: warning: statement with no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: statement with no effect
/home/clg/linux/2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c:1257: warning: statement with no effect
make[3]: *** [drivers/s390/block/dasd_eckd.o] Error 1
make[2]: *** [drivers/s390/block] Error 2
---
drivers/s390/block/dasd_eckd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: 2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c
===================================================================
--- 2.6.23-rc7-mm1.orig/drivers/s390/block/dasd_eckd.c
+++ 2.6.23-rc7-mm1/drivers/s390/block/dasd_eckd.c
@@ -1176,7 +1176,7 @@ dasd_eckd_build_cp(struct dasd_device *
struct LO_eckd_data *LO_data;
struct dasd_ccw_req *cqr;
struct ccw1 *ccw;
- struct req_iterator iter
+ struct req_iterator iter;
struct bio_vec *bv;
char *dst;
unsigned int blksize, blk_per_trk, off;

Oops, looks like neither Neil nor I cross compiled this on s390. Thanks,
I'll apply it.

[Kamalesh Babulal]

Hi Andrew,

Kernel oops over x86_64 (AMD Opteron(tm) Processor 844)

Unable to handle kernel NULL pointer dereference at 0000000000000070 RIP:
[<ffffffff80290630>] fasync_helper+0x6b/0xe4
PGD 181949067 PUD 182228067 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /devices/system/node/possible
CPU 3
Modules linked in:
Pid: 18156, comm: fcntl23 Not tainted 2.6.23-rc7-mm1-autokern1 #1
RIP: 0010:[<ffffffff80290630>] [<ffffffff80290630>] fasync_helper+0x6b/0xe4
RSP: 0000:ffff810082bdfdb8 EFLAGS: 00010046
RAX: 00000000fffffff4 RBX: ffff8101821a9000 RCX: 0000000000000000
RDX: ffff8101821a9000 RSI: ffff810180026900 RDI: ffffffff806286b8
RBP: ffff810082bdfde8 R08: 0000000000000002 R09: ffff81018072124b
R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000070
R13: 0000000000000001 R14: 0000000000000000 R15: ffff810181875cc0
FS: 0000000000000000(0000) GS:ffff810180721380(0063) knlGS:00000000556aa2a0
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000000000070 CR3: 00000001818c4000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process fcntl23 (pid: 18156, threadinfo ffff810082bde000, task ffff810082309530)
last branch before last exception/interrupt
from [<ffffffff804ad9e0>] _write_lock_irq+0x14/0x15
to [<ffffffff80290630>] fasync_helper+0x6b/0xe4
Stack: 0000000400000004 0000000000000000 0000000000000000 ffff810181875cc0
0000000000000004 ffff810182b3d238 ffff810082bdfee8 ffffffff802939cc
ffff810082bdfe18 0000000000000000 0000000000000000 ffff810082bdfe10
Call Trace:
[<ffffffff802939cc>] fcntl_setlease+0x99/0x101
[<ffffffff80290370>] sys_fcntl+0x2a3/0x2ce
[<ffffffff802b14cf>] compat_sys_fcntl64+0x2ee/0x2ff
[<ffffffff80224292>] ia32_sysret+0x0/0xa
DWARF2 unwinder stuck at ia32_sysret+0x0/0xa
Leftover inexact backtrace:
Code: 49 8b 34 24 4c 89 e2 48 85 f6 74 2a 4c 39 7e 10 75 1a 45 85
RIP [<ffffffff80290630>] fasync_helper+0x6b/0xe4
RSP <ffff810082bdfdb8>
CR2: 0000000000000070
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Pavel Emelyanov]

Please, try with this patch too:

diff --git a/fs/locks.c b/fs/locks.c
index c0fe71a..f599508 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp,
locks_copy_lock(new_fl, lease);
locks_insert_lock(before, new_fl);

- *flp = fl;
+ *flp = new_fl;
return 0;

out:

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Balbir Singh]

Post by Pavel Emelyanov
diff --git a/fs/locks.c b/fs/locks.c
index c0fe71a..f599508 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp,
locks_copy_lock(new_fl, lease);
locks_insert_lock(before, new_fl);
- *flp = fl;
+ *flp = new_fl;
return 0;

Hi, Pavel,

You did not signoff on the patch.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Pavel Emelyanov]

Post by Balbir Singh

Post by Pavel Emelyanov
diff --git a/fs/locks.c b/fs/locks.c
index c0fe71a..f599508 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp,
locks_copy_lock(new_fl, lease);
locks_insert_lock(before, new_fl);
- *flp = fl;
+ *flp = new_fl;
return 0;

Hi, Pavel,
You did not signoff on the patch.

I did not, but this is just a patch to test. I know, that it
most likely fixes the problem, but since Kamalesh didn't tell
us how he had triggered it, I'd like him to Ack it :)

Thanks,
Pavel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Balbir Singh]

Post by Pavel Emelyanov

Post by Balbir Singh

Post by Pavel Emelyanov
diff --git a/fs/locks.c b/fs/locks.c
index c0fe71a..f599508 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1423,7 +1423,7 @@ int generic_setlease(struct file *filp,
locks_copy_lock(new_fl, lease);
locks_insert_lock(before, new_fl);
- *flp = fl;
+ *flp = new_fl;
return 0;

Hi, Pavel,
You did not signoff on the patch.

I did not, but this is just a patch to test. I know, that it
most likely fixes the problem, but since Kamalesh didn't tell
us how he had triggered it, I'd like him to Ack it :)
Thanks,
Pavel

Ok, just wanted to let you know in case you missed it out.
In case Andrew picked it up. That's all!
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Cedric Le Goater]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

I also get this compile error on s390. 'linux/scatterlist.h' has disappeared
from the #include pile but where ?

/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c: In function `sctp_auth_calculate_hmac':
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: error: storage size of 'sg' isn't known
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: warning: unused variable `sg'

Cheers,

C.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Cedric Le Goater]

Post by Cedric Le Goater

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

I also get this compile error on s390. 'linux/scatterlist.h' has disappeared
from the #include pile but where ?
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: error: storage size of 'sg' isn't known
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: warning: unused variable `sg'

The following patch works of course but it seems to simplistic for s390.

Cheers,

C.


Signed-off-by: Cedric Le Goater <***@fr.ibm.com>
---
net/sctp/auth.c | 1 +
1 file changed, 1 insertion(+)

Index: 2.6.23-rc7-mm1/net/sctp/auth.c
===================================================================
--- 2.6.23-rc7-mm1.orig/net/sctp/auth.c
+++ 2.6.23-rc7-mm1/net/sctp/auth.c
@@ -36,6 +36,7 @@

#include <linux/types.h>
#include <linux/crypto.h>
+#include <linux/scatterlist.h>
#include <net/sctp/sctp.h>
#include <net/sctp/auth.h>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Vlad Yasevich]

Post by Cedric Le Goater

Post by Cedric Le Goater

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

I also get this compile error on s390. 'linux/scatterlist.h' has disappeared
from the #include pile but where ?
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: error: storage size of 'sg' isn't known
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: warning: unused variable `sg'

The following patch works of course but it seems to simplistic for s390.

Odd that it didn't show up on x86 or ia64, but simple enough.

ACK.

-vlad

Post by Cedric Le Goater
Cheers,
C.
---
net/sctp/auth.c | 1 +
1 file changed, 1 insertion(+)
Index: 2.6.23-rc7-mm1/net/sctp/auth.c
===================================================================
--- 2.6.23-rc7-mm1.orig/net/sctp/auth.c
+++ 2.6.23-rc7-mm1/net/sctp/auth.c
@@ -36,6 +36,7 @@
#include <linux/types.h>
#include <linux/crypto.h>
+#include <linux/scatterlist.h>
#include <net/sctp/sctp.h>
#include <net/sctp/auth.h>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jens Axboe]

Post by Vlad Yasevich

Post by Cedric Le Goater

Post by Cedric Le Goater

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

I also get this compile error on s390. 'linux/scatterlist.h' has disappeared
from the #include pile but where ?
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: error: storage size of 'sg' isn't known
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: warning: unused variable `sg'

The following patch works of course but it seems to simplistic for s390.

Odd that it didn't show up on x86 or ia64, but simple enough.

Most likely those archs end up pulling in scatterlist.h through some
other maze of includes.

[Jens Axboe]

Post by Cedric Le Goater

Post by Cedric Le Goater

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

I also get this compile error on s390. 'linux/scatterlist.h' has disappeared
from the #include pile but where ?
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: error: storage size of 'sg' isn't known
/home/clg/linux/2.6.23-rc7-mm1/net/sctp/auth.c:695: warning: unused variable `sg'

The following patch works of course but it seems to simplistic for s390.
Cheers,
C.
---
net/sctp/auth.c | 1 +
1 file changed, 1 insertion(+)
Index: 2.6.23-rc7-mm1/net/sctp/auth.c
===================================================================
--- 2.6.23-rc7-mm1.orig/net/sctp/auth.c
+++ 2.6.23-rc7-mm1/net/sctp/auth.c
@@ -36,6 +36,7 @@
#include <linux/types.h>
#include <linux/crypto.h>
+#include <linux/scatterlist.h>
#include <net/sctp/sctp.h>
#include <net/sctp/auth.h>

Thanks, applied.

[Kamalesh Babulal]

Hi Andrew,

Kernel BUG over x86_64 (AMD Opteron(tm) Processor 844).

Similar kernel Bug was reported for 2.6.23-rc2-mm1
at http://lkml.org/lkml/2007/8/10/20 and the
mm-dirty-balancing-for-tasks.patch was dropped from 2.6.23-rc2-mm2.
And the same patch is in this -mm version, suspect whether is it the
same patch triggering this Bug.

BUG: soft lockup - CPU#0 stuck for 11s! [events/0:15]
CPU 0:
Modules linked in:
Pid: 15, comm: events/0 Tainted: G D 2.6.23-rc7-mm1-autokern1 #1
RIP: 0010:[<ffffffff8021be46>] [<ffffffff8021be46>] __smp_call_function_mask+0x9a/0xc4
RSP: 0000:ffff8100017add80 EFLAGS: 00000297
RAX: 00000000000000fc RBX: ffff8100017adde0 RCX: 0000000000000001
RDX: 00000000000008fc RSI: 00000000000000fc RDI: 000000000000000e
RBP: ffffc20002d11000 R08: ffff8100017ac000 R09: ffffffff80675e38
R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000f
R13: ffffffff8021bcfe R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff8065a000(0000) knlGS:00000000556aa2a0
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffc20002d11008 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

Call Trace:
Inexact backtrace:
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021becf>] smp_call_function_mask+0x5f/0x72
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021bf82>] smp_call_function+0x19/0x1b
[<ffffffff8023a773>] on_each_cpu+0x16/0x2b
[<ffffffff802158a2>] mcheck_timer+0x0/0x7c
[<ffffffff802158c0>] mcheck_timer+0x1e/0x7c
[<ffffffff802444b9>] run_workqueue+0x88/0x109
[<ffffffff8024453a>] worker_thread+0x0/0xf4
[<ffffffff80244623>] worker_thread+0xe9/0xf4
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff80247e5c>] kthread+0x44/0x6d
[<ffffffff8020c5a8>] child_rip+0xa/0x12
[<ffffffff80247e18>] kthread+0x0/0x6d
[<ffffffff8020c59e>] child_rip+0x0/0x12
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

Post by Kamalesh Babulal
Hi Andrew,
Kernel BUG over x86_64 (AMD Opteron(tm) Processor 844).
Similar kernel Bug was reported for 2.6.23-rc2-mm1
at http://lkml.org/lkml/2007/8/10/20 and the
mm-dirty-balancing-for-tasks.patch was dropped from 2.6.23-rc2-mm2.
And the same patch is in this -mm version, suspect whether is it the
same patch triggering this Bug.
BUG: soft lockup - CPU#0 stuck for 11s! [events/0:15]
Pid: 15, comm: events/0 Tainted: G D 2.6.23-rc7-mm1-autokern1 #1
RIP: 0010:[<ffffffff8021be46>] [<ffffffff8021be46>] __smp_call_function_mask+0x9a/0xc4
RSP: 0000:ffff8100017add80 EFLAGS: 00000297
RAX: 00000000000000fc RBX: ffff8100017adde0 RCX: 0000000000000001
RDX: 00000000000008fc RSI: 00000000000000fc RDI: 000000000000000e
RBP: ffffc20002d11000 R08: ffff8100017ac000 R09: ffffffff80675e38
R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000f
R13: ffffffff8021bcfe R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff8065a000(0000) knlGS:00000000556aa2a0
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffc20002d11008 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021becf>] smp_call_function_mask+0x5f/0x72
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021bf82>] smp_call_function+0x19/0x1b
[<ffffffff8023a773>] on_each_cpu+0x16/0x2b
[<ffffffff802158a2>] mcheck_timer+0x0/0x7c
[<ffffffff802158c0>] mcheck_timer+0x1e/0x7c
[<ffffffff802444b9>] run_workqueue+0x88/0x109
[<ffffffff8024453a>] worker_thread+0x0/0xf4
[<ffffffff80244623>] worker_thread+0xe9/0xf4
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff80247e5c>] kthread+0x44/0x6d
[<ffffffff8020c5a8>] child_rip+0xa/0x12
[<ffffffff80247e18>] kthread+0x0/0x6d
[<ffffffff8020c59e>] child_rip+0x0/0x12

hm, I thought we'd fixed the problems in that patchset. Peter, were
you aware of this one?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Peter Zijlstra]

On Mon, 24 Sep 2007 09:44:48 -0700 Andrew Morton

Post by Andrew Morton

Post by Kamalesh Babulal
Hi Andrew,
Kernel BUG over x86_64 (AMD Opteron(tm) Processor 844).
Similar kernel Bug was reported for 2.6.23-rc2-mm1
at http://lkml.org/lkml/2007/8/10/20 and the
mm-dirty-balancing-for-tasks.patch was dropped from 2.6.23-rc2-mm2.
And the same patch is in this -mm version, suspect whether is it the
same patch triggering this Bug.
BUG: soft lockup - CPU#0 stuck for 11s! [events/0:15]
Pid: 15, comm: events/0 Tainted: G D 2.6.23-rc7-mm1-autokern1 #1
RIP: 0010:[<ffffffff8021be46>] [<ffffffff8021be46>] __smp_call_function_mask+0x9a/0xc4
RSP: 0000:ffff8100017add80 EFLAGS: 00000297
RAX: 00000000000000fc RBX: ffff8100017adde0 RCX: 0000000000000001
RDX: 00000000000008fc RSI: 00000000000000fc RDI: 000000000000000e
RBP: ffffc20002d11000 R08: ffff8100017ac000 R09: ffffffff80675e38
R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000f
R13: ffffffff8021bcfe R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff8065a000(0000) knlGS:00000000556aa2a0
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffc20002d11008 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021becf>] smp_call_function_mask+0x5f/0x72
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021bf82>] smp_call_function+0x19/0x1b
[<ffffffff8023a773>] on_each_cpu+0x16/0x2b
[<ffffffff802158a2>] mcheck_timer+0x0/0x7c
[<ffffffff802158c0>] mcheck_timer+0x1e/0x7c
[<ffffffff802444b9>] run_workqueue+0x88/0x109
[<ffffffff8024453a>] worker_thread+0x0/0xf4
[<ffffffff80244623>] worker_thread+0xe9/0xf4
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff80247e5c>] kthread+0x44/0x6d
[<ffffffff8020c5a8>] child_rip+0xa/0x12
[<ffffffff80247e18>] kthread+0x0/0x6d
[<ffffffff8020c59e>] child_rip+0x0/0x12

hm, I thought we'd fixed the problems in that patchset. Peter, were
you aware of this one?

Nope, and the stacktrace is utterly puzzling.

/me goes read the lkml.org link

Kamalesh Babulal: do you still get:
BUG: spinlock bad magic on

msgs?

Because those I could reproduce using fsx, and I fixed all that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kamalesh Babulal]

Post by Peter Zijlstra
On Mon, 24 Sep 2007 09:44:48 -0700 Andrew Morton

Post by Andrew Morton

Post by Kamalesh Babulal
Hi Andrew,
Kernel BUG over x86_64 (AMD Opteron(tm) Processor 844).
Similar kernel Bug was reported for 2.6.23-rc2-mm1
at http://lkml.org/lkml/2007/8/10/20 and the
mm-dirty-balancing-for-tasks.patch was dropped from 2.6.23-rc2-mm2.
And the same patch is in this -mm version, suspect whether is it the
same patch triggering this Bug.
BUG: soft lockup - CPU#0 stuck for 11s! [events/0:15]
Pid: 15, comm: events/0 Tainted: G D 2.6.23-rc7-mm1-autokern1 #1
RIP: 0010:[<ffffffff8021be46>] [<ffffffff8021be46>] __smp_call_function_mask+0x9a/0xc4
RSP: 0000:ffff8100017add80 EFLAGS: 00000297
RAX: 00000000000000fc RBX: ffff8100017adde0 RCX: 0000000000000001
RDX: 00000000000008fc RSI: 00000000000000fc RDI: 000000000000000e
RBP: ffffc20002d11000 R08: ffff8100017ac000 R09: ffffffff80675e38
R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000f
R13: ffffffff8021bcfe R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff8065a000(0000) knlGS:00000000556aa2a0
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffc20002d11008 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021becf>] smp_call_function_mask+0x5f/0x72
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021bf82>] smp_call_function+0x19/0x1b
[<ffffffff8023a773>] on_each_cpu+0x16/0x2b
[<ffffffff802158a2>] mcheck_timer+0x0/0x7c
[<ffffffff802158c0>] mcheck_timer+0x1e/0x7c
[<ffffffff802444b9>] run_workqueue+0x88/0x109
[<ffffffff8024453a>] worker_thread+0x0/0xf4
[<ffffffff80244623>] worker_thread+0xe9/0xf4
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff80247e5c>] kthread+0x44/0x6d
[<ffffffff8020c5a8>] child_rip+0xa/0x12
[<ffffffff80247e18>] kthread+0x0/0x6d
[<ffffffff8020c59e>] child_rip+0x0/0x12

hm, I thought we'd fixed the problems in that patchset. Peter, were
you aware of this one?

Nope, and the stacktrace is utterly puzzling.
/me goes read the lkml.org link
BUG: spinlock bad magic on
msgs?
Because those I could reproduce using fsx, and I fixed all that.

Hi Peter,

I do not get BUG: spinlock bad magic messages any more, but the softlock message is
thrown more than 30 time, while running the ltp runall.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Peter Zijlstra]

On Mon, 24 Sep 2007 22:38:03 +0530 Kamalesh Babulal

Post by Kamalesh Babulal

Post by Peter Zijlstra
On Mon, 24 Sep 2007 09:44:48 -0700 Andrew Morton

Post by Andrew Morton

Post by Kamalesh Babulal
Hi Andrew,
Kernel BUG over x86_64 (AMD Opteron(tm) Processor 844).
Similar kernel Bug was reported for 2.6.23-rc2-mm1
at http://lkml.org/lkml/2007/8/10/20 and the
mm-dirty-balancing-for-tasks.patch was dropped from 2.6.23-rc2-mm2.
And the same patch is in this -mm version, suspect whether is it the
same patch triggering this Bug.
BUG: soft lockup - CPU#0 stuck for 11s! [events/0:15]
Pid: 15, comm: events/0 Tainted: G D 2.6.23-rc7-mm1-autokern1 #1
RIP: 0010:[<ffffffff8021be46>] [<ffffffff8021be46>] __smp_call_function_mask+0x9a/0xc4
RSP: 0000:ffff8100017add80 EFLAGS: 00000297
RAX: 00000000000000fc RBX: ffff8100017adde0 RCX: 0000000000000001
RDX: 00000000000008fc RSI: 00000000000000fc RDI: 000000000000000e
RBP: ffffc20002d11000 R08: ffff8100017ac000 R09: ffffffff80675e38
R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000f
R13: ffffffff8021bcfe R14: 0000000000000000 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffffffff8065a000(0000) knlGS:00000000556aa2a0
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffffc20002d11008 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021becf>] smp_call_function_mask+0x5f/0x72
[<ffffffff802157a4>] mcheck_check_cpu+0x0/0x31
[<ffffffff8021bf82>] smp_call_function+0x19/0x1b
[<ffffffff8023a773>] on_each_cpu+0x16/0x2b
[<ffffffff802158a2>] mcheck_timer+0x0/0x7c
[<ffffffff802158c0>] mcheck_timer+0x1e/0x7c
[<ffffffff802444b9>] run_workqueue+0x88/0x109
[<ffffffff8024453a>] worker_thread+0x0/0xf4
[<ffffffff80244623>] worker_thread+0xe9/0xf4
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff8024841d>] autoremove_wake_function+0x0/0x37
[<ffffffff80247e5c>] kthread+0x44/0x6d
[<ffffffff8020c5a8>] child_rip+0xa/0x12
[<ffffffff80247e18>] kthread+0x0/0x6d
[<ffffffff8020c59e>] child_rip+0x0/0x12

hm, I thought we'd fixed the problems in that patchset. Peter, were
you aware of this one?

Nope, and the stacktrace is utterly puzzling.
/me goes read the lkml.org link
BUG: spinlock bad magic on
msgs?
Because those I could reproduce using fsx, and I fixed all that.

Hi Peter,
I do not get BUG: spinlock bad magic messages any more, but the softlock message is
thrown more than 30 time, while running the ltp runall.

It would be good to know what function on_each_cpu is executing, could
you try something like:

---
kernel/softirq.c | 5 +++++
kernel/softlockup.c | 7 +++++++
2 files changed, 12 insertions(+)

Index: linux-2.6/kernel/softirq.c
===================================================================
--- linux-2.6.orig/kernel/softirq.c
+++ linux-2.6/kernel/softirq.c
@@ -645,6 +645,8 @@ __init int spawn_ksoftirqd(void)
}

#ifdef CONFIG_SMP
+
+DEFINE_PER_CPU(void (*)(void *info), last_on_each_cpu);
/*
* Call a function on all processors
*/
@@ -653,6 +655,9 @@ int on_each_cpu(void (*func) (void *info
int ret = 0;

preempt_disable();
+
+ per_cpu(last_on_each_cpu, smp_processor_id()) = func;
+
ret = smp_call_function(func, info, retry, wait);
local_irq_disable();
func(info);
Index: linux-2.6/kernel/softlockup.c
===================================================================
--- linux-2.6.orig/kernel/softlockup.c
+++ linux-2.6/kernel/softlockup.c
@@ -15,6 +15,8 @@
#include <linux/notifier.h>
#include <linux/module.h>
#include <linux/kgdb.h>
+#include <linux/percpu.h>
+#include <linux/kallsyms.h>

#include <asm/irq_regs.h>

@@ -71,6 +73,8 @@ void touch_all_softlockup_watchdogs(void
}
EXPORT_SYMBOL(touch_all_softlockup_watchdogs);

+DECLARE_PER_CPU(void (*)(void *), last_on_each_cpu);
+
/*
* This callback runs from the timer interrupt, and checks
* whether the watchdog thread has hung or not:
@@ -122,6 +126,9 @@ void softlockup_tick(void)
printk(KERN_ERR "BUG: soft lockup - CPU#%d stuck for %lus! [%s:%d]\n",
this_cpu, now - touch_timestamp,
current->comm, task_pid_nr(current));
+ printk(KERN_ERR " last_on_each_cpu: [<%p>] ",
+ per_cpu(last_on_each_cpu, this_cpu));
+ print_symbol("%s\n", (unsigned long)per_cpu(last_on_each_cpu, this_cpu));
if (regs)
show_regs(regs);
else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Peter Zijlstra]

On Mon, 24 Sep 2007 21:20:58 +0200 Peter Zijlstra

Post by Peter Zijlstra

Post by Kamalesh Babulal

Post by Peter Zijlstra
Nope, and the stacktrace is utterly puzzling.
/me goes read the lkml.org link
BUG: spinlock bad magic on
msgs?
Because those I could reproduce using fsx, and I fixed all that.

Hi Peter,
I do not get BUG: spinlock bad magic messages any more, but the softlock message is
thrown more than 30 time, while running the ltp runall.

It would be good to know what function on_each_cpu is executing, could

I've just completed 2 full ltp runs on a dual-core opteron machine but
could not reproduce this problem.

Kamalesh, would it be possible for you to reproduce with that patch, so
we can see what function is holding up the cpu?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kamalesh Babulal]

Post by Peter Zijlstra
On Mon, 24 Sep 2007 21:20:58 +0200 Peter Zijlstra

Post by Peter Zijlstra

Post by Kamalesh Babulal

Post by Peter Zijlstra
Nope, and the stacktrace is utterly puzzling.
/me goes read the lkml.org link
BUG: spinlock bad magic on
msgs?
Because those I could reproduce using fsx, and I fixed all that.

Hi Peter,
I do not get BUG: spinlock bad magic messages any more, but the softlock message is
thrown more than 30 time, while running the ltp runall.

It would be good to know what function on_each_cpu is executing, could

I've just completed 2 full ltp runs on a dual-core opteron machine but
could not reproduce this problem.
Kamalesh, would it be possible for you to reproduce with that patch, so
we can see what function is holding up the cpu?

Hi Peter,

After running the test with the patch you provided, i observed an oops message
which was at the top of the these soft lockup message and the oops is the same as
the oops reported at http://lkml.org/lkml/2007/9/24/107.

And when i applied the patch for the oops proposed at
http://lkml.org/lkml/2007/9/25/57 the oops as well as the soft lockup's are not seen.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Hugh Dickins]

a.k.a. mm-use-pagevec-to-rotate-reclaimable-page-fix-2.patch

rotate_reclaimable_page() is not necessarily called with IRQ disabled:
it must do so when calling the helpfully commented pagevec_move_tail().

Hmm, if pagevec_move_tail() is assuming IRQ disabled, why should it
bother with irqsave/irqrestore variants of spin_lock? Because we like
to see them on lru_lock? But vmscan.c already has one bare spin_lock().

Signed-off-by: Hugh Dickins <***@veritas.com>
---

mm/swap.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

--- 2.6.23-rc7-mm1/mm/swap.c 2007-09-24 11:05:55.000000000 +0100
+++ linux/mm/swap.c 2007-09-24 13:08:12.000000000 +0100
@@ -102,7 +102,6 @@ static void pagevec_move_tail(struct pag
int i;
int pgmoved = 0;
struct zone *zone = NULL;
- unsigned long uninitialized_var(flags);

for (i = 0; i < pagevec_count(pvec); i++) {
struct page *page = pvec->pages[i];
@@ -110,9 +109,9 @@ static void pagevec_move_tail(struct pag

if (pagezone != zone) {
if (zone)
- spin_unlock_irqrestore(&zone->lru_lock, flags);
+ spin_unlock(&zone->lru_lock);
zone = pagezone;
- spin_lock_irqsave(&zone->lru_lock, flags);
+ spin_lock(&zone->lru_lock);
}
if (PageLRU(page) && !PageActive(page)) {
list_move_tail(&page->lru, &zone->inactive_list);
@@ -120,7 +119,7 @@ static void pagevec_move_tail(struct pag
}
}
if (zone)
- spin_unlock_irqrestore(&zone->lru_lock, flags);
+ spin_unlock(&zone->lru_lock);
__count_vm_events(PGROTATED, pgmoved);
release_pages(pvec->pages, pvec->nr, pvec->cold);
pagevec_reinit(pvec);
@@ -150,6 +149,7 @@ void move_tail_pages()
int rotate_reclaimable_page(struct page *page)
{
struct pagevec *pvec;
+ unsigned long flags;

if (PageLocked(page))
return 1;
@@ -162,9 +162,11 @@ int rotate_reclaimable_page(struct page

if (PageLRU(page) && !PageActive(page)) {
page_cache_get(page);
+ local_irq_save(flags);
pvec = &__get_cpu_var(rotate_pvecs);
if (!pagevec_add(pvec, page))
pagevec_move_tail(pvec);
+ local_irq_restore(flags);
}
if (!test_clear_page_writeback(page))
BUG();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Reuben Farrelly]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32

I'm observing a problem with this kernel (as well as 2.6.23-rc6-mm1) which
manifests itself only in my Postfix/application mail.logs:

Sep 25 00:25:40 tornado postfix/smtp[12520]: fatal: select lock: Cannot allocate
memory
Sep 25 00:25:41 tornado postfix/master[8002]: warning: process
/usr/lib64/postfix/smtp pid 12520 exit status 1

This is happening frequently with processes started via 'master' (smtp, smtpd
and cleanup), but it does not appear to have any noticeable operational impact
apart from logging a lot of copies of this message.

The corresponding code in Postfix which triggers this is (choice of 3 files in
src/master are all possibilities which all have much the same code)

/*
* The event loop, at last.
*/
while (var_use_limit == 0 || use_count < var_use_limit || client_count > 0) {
if (multi_server_lock != 0) {
watchdog_stop(watchdog);
if (myflock(vstream_fileno(multi_server_lock), INTERNAL_LOCK,
MYFLOCK_OP_EXCLUSIVE) < 0)
msg_fatal("select lock: %m");
}
watchdog_start(watchdog);
delay = loop ? loop(multi_server_name, multi_server_argv) : -1;
event_loop(delay);
}
multi_server_exit();
}


Now I'm not convinced this is an application problem, because I'm only seeing
this after running up kernel 2.6.23-rc6-mm1 or 2.6.23-rc7-mm1 and with NO
changes to the application itself. Using the same application binaries it does
not occur with 2.6.22 mainline. [I didn't get a lot of testing with the -mm
release prior to that unfortunately due to some other breakage.]

Is there anything new in the last two or so -mm kernels which could have caused
this?

I've put my .config up at http://www.reub.net/files/kernel/2.6.23-rc7-mm1.config

Thanks,
Reuben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

Post by Reuben Farrelly

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32

I'm observing a problem with this kernel (as well as 2.6.23-rc6-mm1) which
Sep 25 00:25:40 tornado postfix/smtp[12520]: fatal: select lock: Cannot allocate
memory
Sep 25 00:25:41 tornado postfix/master[8002]: warning: process
/usr/lib64/postfix/smtp pid 12520 exit status 1
This is happening frequently with processes started via 'master' (smtp, smtpd
and cleanup), but it does not appear to have any noticeable operational impact
apart from logging a lot of copies of this message.
The corresponding code in Postfix which triggers this is (choice of 3 files in
src/master are all possibilities which all have much the same code)
/*
* The event loop, at last.
*/
while (var_use_limit == 0 || use_count < var_use_limit || client_count > 0) {
if (multi_server_lock != 0) {
watchdog_stop(watchdog);
if (myflock(vstream_fileno(multi_server_lock), INTERNAL_LOCK,
MYFLOCK_OP_EXCLUSIVE) < 0)
msg_fatal("select lock: %m");
}
watchdog_start(watchdog);
delay = loop ? loop(multi_server_name, multi_server_argv) : -1;
event_loop(delay);
}
multi_server_exit();
}
Now I'm not convinced this is an application problem, because I'm only seeing
this after running up kernel 2.6.23-rc6-mm1 or 2.6.23-rc7-mm1 and with NO
changes to the application itself. Using the same application binaries it does
not occur with 2.6.22 mainline. [I didn't get a lot of testing with the -mm
release prior to that unfortunately due to some other breakage.]
Is there anything new in the last two or so -mm kernels which could have caused
this?
I've put my .config up at http://www.reub.net/files/kernel/2.6.23-rc7-mm1.config

ug.

Lots of people have been futzing with the fs/locks.c code:

cleanup-macros-for-distinguishing-mandatory-locks.patch
fix-potential-oops-in-generic_setlease-v2.patch
fix-potential-oops-in-generic_setlease.patch
fs-locksc-use-list_for_each_entry-instead-of-list_for_each.patch
git-nfs.patch
git-nfsd.pc
rework-proc-locks-via-seq_files-and-seq_list-helpers-fix-2.patch
rework-proc-locks-via-seq_files-and-seq_list-helpers.patch
slab-api-remove-useless-ctor-parameter-and-reorder-parameters.patch



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[J. Bruce Fields]

Post by Reuben Farrelly

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32

I'm observing a problem with this kernel (as well as 2.6.23-rc6-mm1) which
Sep 25 00:25:40 tornado postfix/smtp[12520]: fatal: select lock: Cannot allocate
memory
Sep 25 00:25:41 tornado postfix/master[8002]: warning: process
/usr/lib64/postfix/smtp pid 12520 exit status 1
This is happening frequently with processes started via 'master' (smtp, smtpd
and cleanup), but it does not appear to have any noticeable operational impact
apart from logging a lot of copies of this message.
The corresponding code in Postfix which triggers this is (choice of 3 files in
src/master are all possibilities which all have much the same code)

Oog. Looks like it's the "Memory shortage can result in inconsistent
flocks state" patch--the error variable is being set in some cases when
it shouldn't be. Does the following fix it?

That's in my git tree, not in mainline. I'll fix up my copy.

And I'll spend some time today figuring out what to do about regression
testing for the posix lock, flock, and lease code.

Thanks for the bug report!

--b.

diff --git a/fs/locks.c b/fs/locks.c
index a6c5917..3e8bfd2 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -740,6 +740,7 @@ static int flock_lock_file(struct file *filp, struct file_lock *request)
new_fl = locks_alloc_lock();
if (new_fl == NULL)
goto out;
+ error = 0;
}

for_each_lock(inode, before) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Reuben Farrelly]

Post by J. Bruce Fields

Post by Reuben Farrelly

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/
- New git tree git-powerpc-galak.patch added to the -mm lineup: ppc32

I'm observing a problem with this kernel (as well as 2.6.23-rc6-mm1) which
Sep 25 00:25:40 tornado postfix/smtp[12520]: fatal: select lock: Cannot allocate
memory
Sep 25 00:25:41 tornado postfix/master[8002]: warning: process
/usr/lib64/postfix/smtp pid 12520 exit status 1
This is happening frequently with processes started via 'master' (smtp, smtpd
and cleanup), but it does not appear to have any noticeable operational impact
apart from logging a lot of copies of this message.
The corresponding code in Postfix which triggers this is (choice of 3 files in
src/master are all possibilities which all have much the same code)

Oog. Looks like it's the "Memory shortage can result in inconsistent
flocks state" patch--the error variable is being set in some cases when
it shouldn't be. Does the following fix it?
That's in my git tree, not in mainline. I'll fix up my copy.
And I'll spend some time today figuring out what to do about regression
testing for the posix lock, flock, and lease code.
Thanks for the bug report!
--b.
diff --git a/fs/locks.c b/fs/locks.c
index a6c5917..3e8bfd2 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -740,6 +740,7 @@ static int flock_lock_file(struct file *filp, struct file_lock *request)
new_fl = locks_alloc_lock();
if (new_fl == NULL)
goto out;
+ error = 0;
}
for_each_lock(inode, before) {

Yes that has fixed it, thanks!

Reuben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Bob Picco]

There isn't a total_memory identifier within this function's scope. The
patch was compile/link tested.

Signed-off-by: Bob Picco <***@hp.com>

arch/ia64/kernel/efi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.23-rc7-mm1/arch/ia64/kernel/efi.c
===================================================================
--- linux-2.6.23-rc7-mm1.orig/arch/ia64/kernel/efi.c 2007-09-24 09:54:40.000000000 -0400
+++ linux-2.6.23-rc7-mm1/arch/ia64/kernel/efi.c 2007-09-24 10:50:51.000000000 -0400
@@ -1085,7 +1085,7 @@ efi_memmap_init(unsigned long *s, unsign
*s = (u64)kern_memmap;
*e = (u64)++k;

- return total_memory;
+ return total_mem;
}

void
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Torsten Kaiser]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

With the five hotfixes applied it works for me.

But it fails to power down my system when shutting down.

It prints twice 'System halted' and blinks the keyboard leds, but does
not switch off. On all other kernel version I only see one keyboard
blink before the power goes out.

I compared its dmesg to vanilla-rc7 and -rc4-mm1, but expect that rc-4
assigns different IRQs I can't see any differences except the normal
variation in BogoMips etc.

As the system still responded to SysRq I got the following informations:
[ 415.770000] SysRq : Show Regs
[ 415.770000] CPU 3:
[ 415.780000] Modules linked in: radeon drm nfsd exportfs ipv6 tuner
tea5767 tda8290 tuner_simple mt20xx tvaudio msp3400 bttv video_buf
ir_common compat_ioctl32 btcx_risc tveeprom videodev v4l2_common
v4l1_compat pata_amd usbhid hid sg
[ 415.780000] Pid: 0, comm: swapper Not tainted 2.6.23-rc7-mm1 #1
[ 415.780000] RIP: 0010:[<ffffffff8020ac79>] [<ffffffff8020ac79>]
default_idle+0x29/0x40
[ 415.780000] RSP: 0018:ffff81010038bf30 EFLAGS: 00000246
[ 415.780000] RAX: 0000000000000400 RBX: ffffffff80810040 RCX: 0000000000000000
[ 415.780000] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000005
[ 415.780000] RBP: 0000000000030400 R08: 0000000000000000 R09: ffff81010038be68
[ 415.950000] R10: 000000000100002c R11: ffffffff80219be0 R12: 0000000000000000
[ 415.950000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 415.950000] FS: 00007f35c69726f0(0000) GS:ffff810100319700(0000)
knlGS:0000000000000000
[ 415.950000] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 415.950000] CR2: 00007fe432928c40 CR3: 0000000000201000 CR4: 00000000000006e0
[ 416.070000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 416.070000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 416.070000]
[ 416.070000] Call Trace:
[ 416.070000] [<ffffffff8020acea>] cpu_idle+0x5a/0x90
[ 416.070000]

No blocked tasks were shown with SysRq+W.
Last lines before I used SysRq+B (That worked, a normal reboot started):

[ 450.780000] SysRq : Emergency Remount R/O
[ 450.790000] Emergency Remount complete
[ 453.650000] SysRq : Emergency Sync
[ 453.660000] Emergency Sync complete
[ 455.910000] SysRq : Power Off
[ 455.920000] md: stopping all md devices.
[ 455.930000] md: md1 still in use.
[ 456.940000] sd 8:0:1:0: [sdd] Synchronizing SCSI cache
[ 456.960000] sd 8:0:1:0: [sdd] Stopping disk
[ 457.480000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
[ 457.490000] sd 2:0:0:0: [sdc] Stopping disk
[ 457.500000] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[ 457.520000] sd 1:0:0:0: [sdb] Stopping disk
[ 457.530000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 457.550000] sd 0:0:0:0: [sda] Stopping disk
[ 457.560000] Power down.
[ 479.090000] SysRq : Power Off
[ 479.100000] md: stopping all md devices.
[ 479.110000] md: md1 still in use.
[ 480.120000] sd 8:0:1:0: [sdd] Synchronizing SCSI cache
[ 480.140000] sd 8:0:1:0: [sdd] Stopping disk
[ 480.660000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
[ 480.670000] sd 2:0:0:0: [sdc] Stopping disk
[ 480.680000] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[ 480.700000] sd 1:0:0:0: [sdb] Stopping disk
[ 480.710000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 480.730000] sd 0:0:0:0: [sda] Stopping disk
[ 480.740000] Power down.
[ 489.030000] SysRq : Resetting

Torsten
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

On Mon, 24 Sep 2007 21:07:19 +0200

Post by Torsten Kaiser

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

With the five hotfixes applied it works for me.
But it fails to power down my system when shutting down.
It prints twice 'System halted' and blinks the keyboard leds, but does
not switch off. On all other kernel version I only see one keyboard
blink before the power goes out.

ok...

Post by Torsten Kaiser
I compared its dmesg to vanilla-rc7 and -rc4-mm1, but expect that rc-4
assigns different IRQs I can't see any differences except the normal
variation in BogoMips etc.

good move.

Post by Torsten Kaiser
[ 415.770000] SysRq : Show Regs
[ 415.780000] Modules linked in: radeon drm nfsd exportfs ipv6 tuner
tea5767 tda8290 tuner_simple mt20xx tvaudio msp3400 bttv video_buf
ir_common compat_ioctl32 btcx_risc tveeprom videodev v4l2_common
v4l1_compat pata_amd usbhid hid sg
[ 415.780000] Pid: 0, comm: swapper Not tainted 2.6.23-rc7-mm1 #1
[ 415.780000] RIP: 0010:[<ffffffff8020ac79>] [<ffffffff8020ac79>]
default_idle+0x29/0x40
[ 415.780000] RSP: 0018:ffff81010038bf30 EFLAGS: 00000246
[ 415.780000] RAX: 0000000000000400 RBX: ffffffff80810040 RCX: 0000000000000000
[ 415.780000] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000005
[ 415.780000] RBP: 0000000000030400 R08: 0000000000000000 R09: ffff81010038be68
[ 415.950000] R10: 000000000100002c R11: ffffffff80219be0 R12: 0000000000000000
[ 415.950000] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 415.950000] FS: 00007f35c69726f0(0000) GS:ffff810100319700(0000)
knlGS:0000000000000000
[ 415.950000] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 415.950000] CR2: 00007fe432928c40 CR3: 0000000000201000 CR4: 00000000000006e0
[ 416.070000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 416.070000] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 416.070000]
[ 416.070000] [<ffffffff8020acea>] cpu_idle+0x5a/0x90
[ 416.070000]
No blocked tasks were shown with SysRq+W.
[ 450.780000] SysRq : Emergency Remount R/O
[ 450.790000] Emergency Remount complete
[ 453.650000] SysRq : Emergency Sync
[ 453.660000] Emergency Sync complete
[ 455.910000] SysRq : Power Off
[ 455.920000] md: stopping all md devices.
[ 455.930000] md: md1 still in use.
[ 456.940000] sd 8:0:1:0: [sdd] Synchronizing SCSI cache
[ 456.960000] sd 8:0:1:0: [sdd] Stopping disk
[ 457.480000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
[ 457.490000] sd 2:0:0:0: [sdc] Stopping disk
[ 457.500000] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[ 457.520000] sd 1:0:0:0: [sdb] Stopping disk
[ 457.530000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 457.550000] sd 0:0:0:0: [sda] Stopping disk
[ 457.560000] Power down.
[ 479.090000] SysRq : Power Off
[ 479.100000] md: stopping all md devices.
[ 479.110000] md: md1 still in use.
[ 480.120000] sd 8:0:1:0: [sdd] Synchronizing SCSI cache
[ 480.140000] sd 8:0:1:0: [sdd] Stopping disk
[ 480.660000] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
[ 480.670000] sd 2:0:0:0: [sdc] Stopping disk
[ 480.680000] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[ 480.700000] sd 1:0:0:0: [sdb] Stopping disk
[ 480.710000] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 480.730000] sd 0:0:0:0: [sda] Stopping disk
[ 480.740000] Power down.
[ 489.030000] SysRq : Resetting

hm, dunno. The only substantial patch which touches
arch/x86_64/kernel/process.c (which is where cpu_idle lives) is
x86_64-prep-idle-loop-for-dynticks.patch.

The problem is, 2.6.23-rc6-mm1's git-acpi patch had all the new cpuidle
code in it. Len dropped all that code over the weekend (which is when I
picked this copy of his tree), so 2.6.23-rc7-mm1 doesn't have the cpuidle
code. Len will be reapplying the cpuidle patches today(ish) so next -mm
_will_ have the cpuidle code.

So what we have in rc7-mm1 is this transient no-cpuidle state. It could be
that the x86_64 dynticks code (which was developed previously tested in
conjunction with the cpuidle patches) has some dependency on cpuidle.

So it's all a bit of a mess :(

I think I'll basically stop applying things which don't look like bugfixes
for a while and try to get more -mm's out, as we seriously need to get this
lot stabilised asap.

Len, would it be possible to restore cpuidle sometime today please?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Thomas Gleixner]

Post by Andrew Morton

Post by Torsten Kaiser
It prints twice 'System halted' and blinks the keyboard leds, but does
not switch off. On all other kernel version I only see one keyboard
blink before the power goes out.

ok...

Post by Torsten Kaiser
I compared its dmesg to vanilla-rc7 and -rc4-mm1, but expect that rc-4
assigns different IRQs I can't see any differences except the normal
variation in BogoMips etc.

Can your check whether 2.6.23-rc7 +
http://tglx.de/projects/hrtimers/2.6.23-rc7/patch-2.6.23-rc7-hrt1.patch

works for you ?

Post by Andrew Morton
hm, dunno. The only substantial patch which touches
arch/x86_64/kernel/process.c (which is where cpu_idle lives) is
x86_64-prep-idle-loop-for-dynticks.patch.
The problem is, 2.6.23-rc6-mm1's git-acpi patch had all the new cpuidle
code in it. Len dropped all that code over the weekend (which is when I
picked this copy of his tree), so 2.6.23-rc7-mm1 doesn't have the cpuidle
code. Len will be reapplying the cpuidle patches today(ish) so next -mm
_will_ have the cpuidle code.
So what we have in rc7-mm1 is this transient no-cpuidle state. It could be
that the x86_64 dynticks code (which was developed previously tested in
conjunction with the cpuidle patches) has some dependency on cpuidle.

It should not. cpuidle makes use of dynticks not the other way round.

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Torsten Kaiser]

Post by Thomas Gleixner
Can your check whether 2.6.23-rc7 +
http://tglx.de/projects/hrtimers/2.6.23-rc7/patch-2.6.23-rc7-hrt1.patch
works for you ?

Yes, powers off normally.

Torsten
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Thomas Gleixner]

Post by Torsten Kaiser

Post by Thomas Gleixner
Can your check whether 2.6.23-rc7 +
http://tglx.de/projects/hrtimers/2.6.23-rc7/patch-2.6.23-rc7-hrt1.patch
works for you ?

Yes, powers off normally.

Ok, so it's probably some merge artifact in -mm. We'll get this sorted
out once Len has his new tree available.

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Kamalesh Babulal]

Hi Andrew,

The build fails with following error

CC drivers/block/ps3disk.o
drivers/block/ps3disk.c: In function ‘ps3disk_scatter_gather’:
drivers/block/ps3disk.c:115: error: ‘bio’ undeclared (first use in this
function)
drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
reported only once
drivers/block/ps3disk.c:115: error: for each function it appears in.)
drivers/block/ps3disk.c:115: error: ‘j’ undeclared (first use in this
function)
drivers/block/ps3disk.c:116: error: implicit declaration of function
‘bio_kunmap_bvec’
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2

The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
find this function.

Previously this function was replaced by __bio_kunmap_atomic();
This patch does not solves the implicit "declaration of function
‘bio_kunmap_bvec’"

Signed-off-by: Kamalesh Babulal <***@linux.vnet.ibm.com
<mailto:***@linux.vnet.ibm.com>>
---

--- linux-2.6.23-rc7/drivers/block/ps3disk.c 2007-09-24 20:50:41.000000000 +0530
+++ linux-2.6.23-rc7/drivers/block/~ps3disk.c 2007-09-24 20:50:59.000000000 +0530
@@ -112,7 +112,7 @@ static void ps3disk_scatter_gather(struc
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
+ flush_kernel_dcache_page(bio_iovec_idx(iter.bio, iter.i)->bv_page);
bio_kunmap_bvec(bvec, flags);
i++;
}
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Mel Gorman]

On (25/09/07 01:11), Kamalesh Babulal didst pronounce:

Hi Kamalesh,

Post by Kamalesh Babulal
The build fails with following error
CC drivers/block/ps3disk.o
drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in this
function)
drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
reported only once
drivers/block/ps3disk.c:115: error: for each function it appears in.)
drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
function)
drivers/block/ps3disk.c:116: error: implicit declaration of function
???bio_kunmap_bvec???
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
find this function.
Previously this function was replaced by __bio_kunmap_atomic();
This patch does not solves the implicit "declaration of function
???bio_kunmap_bvec???"

Your mailer appears to have mangled both your signoff and the whitespace in
the patch and it does not apply. However, fixing it does not solve the problem
because of this mysterious bio_kunmap_bvec() that is only referenced by this
driver. Was it accidently added during the addition of sg chaining support?

Post by Kamalesh Babulal
---
--- linux-2.6.23-rc7/drivers/block/ps3disk.c 2007-09-24 20:50:41.000000000 +0530
+++ linux-2.6.23-rc7/drivers/block/~ps3disk.c 2007-09-24 20:50:59.000000000 +0530
@@ -112,7 +112,7 @@ static void ps3disk_scatter_gather(struc
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
+ flush_kernel_dcache_page(bio_iovec_idx(iter.bio, iter.i)->bv_page);
bio_kunmap_bvec(bvec, flags);
i++;
}
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--

[Jens Axboe]

Post by Mel Gorman
Hi Kamalesh,

Post by Kamalesh Babulal
The build fails with following error
CC drivers/block/ps3disk.o
drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in this
function)
drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
reported only once
drivers/block/ps3disk.c:115: error: for each function it appears in.)
drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
function)
drivers/block/ps3disk.c:116: error: implicit declaration of function
???bio_kunmap_bvec???
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
find this function.
Previously this function was replaced by __bio_kunmap_atomic();
This patch does not solves the implicit "declaration of function
???bio_kunmap_bvec???"

Your mailer appears to have mangled both your signoff and the whitespace in
the patch and it does not apply. However, fixing it does not solve the problem
because of this mysterious bio_kunmap_bvec() that is only referenced by this
driver. Was it accidently added during the addition of sg chaining support?

This should fix things up.

diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 8e05ba7..a7fd66a 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -106,14 +106,14 @@ static void ps3disk_scatter_gather(struct ps3_storage_device *dev,
(unsigned long)iter.bio->bi_sector);

size = bvec->bv_len;
- buf = bvec_kmap_irq(bvec, flags);
+ buf = bvec_kmap_irq(bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bio_iovec_idx(bio, j)->bv_page);
- bio_kunmap_bvec(bvec, flags);
+ flush_kernel_dcache_page(bvec->bv_page);
+ bvec_kunmap_irq(buf, &flags);
i++;
}
}

[Mel Gorman]

Post by Jens Axboe

Post by Mel Gorman
Hi Kamalesh,

Post by Kamalesh Babulal
The build fails with following error
CC drivers/block/ps3disk.o
drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in this
function)
drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
reported only once
drivers/block/ps3disk.c:115: error: for each function it appears in.)
drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
function)
drivers/block/ps3disk.c:116: error: implicit declaration of function
???bio_kunmap_bvec???
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
find this function.
Previously this function was replaced by __bio_kunmap_atomic();
This patch does not solves the implicit "declaration of function
???bio_kunmap_bvec???"

Your mailer appears to have mangled both your signoff and the whitespace in
the patch and it does not apply. However, fixing it does not solve the problem
because of this mysterious bio_kunmap_bvec() that is only referenced by this
driver. Was it accidently added during the addition of sg chaining support?

This should fix things up.

This builds although I lack the hardware to really test it. However, in
2.6.23-rc8-mm1 it collides with git-block-ps3disk-fix.patch. This is a
version on top of that stack but I guess the best thing to do is replace
git-block-ps3disk-fix.patch with Jens patch once it is signed off.

Not signing off because this is just a rebase. Assuming the other one
gets signed off, consider it;

Acked-by: Mel Gorman <***@csn.ul.ie>

---

diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc8-mm1-clean/drivers/block/ps3disk.c linux-2.6.23-rc8-mm1-fix-ps3disk/drivers/block/ps3disk.c
--- linux-2.6.23-rc8-mm1-clean/drivers/block/ps3disk.c 2007-09-25 12:05:40.000000000 +0100
+++ linux-2.6.23-rc8-mm1-fix-ps3disk/drivers/block/ps3disk.c 2007-09-25 12:09:19.000000000 +0100
@@ -106,14 +106,14 @@ static void ps3disk_scatter_gather(struc
(unsigned long)iter.bio->bi_sector);

size = bvec->bv_len;
- buf = bvec_kmap_irq(bvec, flags);
+ buf = bvec_kmap_irq(bvec, &flags);
if (gather)
memcpy(dev->bounce_buf+offset, buf, size);
else
memcpy(buf, dev->bounce_buf+offset, size);
offset += size;
- flush_kernel_dcache_page(bio_iovec_idx(iter.bio, iter.i)->bv_page);
- bio_kunmap_bvec(bvec, flags);
+ flush_kernel_dcache_page(bvec->bv_page);
+ bvec_kunmap_irq(buf, &flags);
i++;
}
}

[Jens Axboe]

Post by Mel Gorman

Post by Jens Axboe

Post by Mel Gorman
Hi Kamalesh,

Post by Kamalesh Babulal
The build fails with following error
CC drivers/block/ps3disk.o
drivers/block/ps3disk.c:115: error: ???bio??? undeclared (first use in this
function)
drivers/block/ps3disk.c:115: error: (Each undeclared identifier is
reported only once
drivers/block/ps3disk.c:115: error: for each function it appears in.)
drivers/block/ps3disk.c:115: error: ???j??? undeclared (first use in this
function)
drivers/block/ps3disk.c:116: error: implicit declaration of function
???bio_kunmap_bvec???
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
The function bio_kunmap_bvec is missing.I tried checking the git-block.patch
as well as the linux/kernel/git/axboe/linux-2.6-block.git and did not
find this function.
Previously this function was replaced by __bio_kunmap_atomic();
This patch does not solves the implicit "declaration of function
???bio_kunmap_bvec???"

Your mailer appears to have mangled both your signoff and the whitespace in
the patch and it does not apply. However, fixing it does not solve the problem
because of this mysterious bio_kunmap_bvec() that is only referenced by this
driver. Was it accidently added during the addition of sg chaining support?

This should fix things up.

This builds although I lack the hardware to really test it. However, in
2.6.23-rc8-mm1 it collides with git-block-ps3disk-fix.patch. This is a
version on top of that stack but I guess the best thing to do is replace
git-block-ps3disk-fix.patch with Jens patch once it is signed off.
Not signing off because this is just a rebase. Assuming the other one
gets signed off, consider it;

Thanks, but I already integrated the fix into the existing patch, so
that bisect will work.

[Kamalesh Babulal]

Hi Andrew,

The drivers/net/pasemi_mac seems to be broken and build fails with

CC [M] drivers/net/pasemi_mac.o
drivers/net/pasemi_mac.c: In function ‘pasemi_mac_probe’:
drivers/net/pasemi_mac.c:1153: error: conflicting types for ‘mac’
drivers/net/pasemi_mac.c:1151: error: previous declaration of ‘mac’ was here
drivers/net/pasemi_mac.c:1170: error: incompatible types in assignment
drivers/net/pasemi_mac.c:1172: error: request for member ‘pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1173: error: request for member ‘netdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1175: error: request for member ‘napi’ in
something not a structure or union
drivers/net/pasemi_mac.c:1180: error: request for member ‘dma_txch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1181: error: request for member ‘dma_rxch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1187: error: request for member ‘dma_if’ in
something not a structure or union
drivers/net/pasemi_mac.c:1189: error: request for member ‘dma_if’ in
something not a structure or union
drivers/net/pasemi_mac.c:1194: error: request for member ‘type’ in
something not a structure or union
drivers/net/pasemi_mac.c:1197: error: request for member ‘type’ in
something not a structure or union
drivers/net/pasemi_mac.c:1205: warning: passing argument 1 of
‘pasemi_get_mac_addr’ from incompatible pointer type
drivers/net/pasemi_mac.c:1205: error: request for member ‘mac_addr’ in
something not a structure or union
drivers/net/pasemi_mac.c:1209: error: request for member ‘mac_addr’ in
something not a structure or union
drivers/net/pasemi_mac.c:1209: error: request for member ‘mac_addr’ in
something not a structure or union
drivers/net/pasemi_mac.c:1216: warning: passing argument 1 of
‘pasemi_mac_map_regs’ from incompatible pointer type
drivers/net/pasemi_mac.c:1220: error: request for member ‘rx_status’ in
something not a structure or union
drivers/net/pasemi_mac.c:1220: error: request for member ‘dma_rxch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1221: error: request for member ‘tx_status’ in
something not a structure or union
drivers/net/pasemi_mac.c:1221: error: request for member ‘dma_txch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1223: error: request for member ‘msg_enable’ in
something not a structure or union
drivers/net/pasemi_mac.c:1226: error: request for member ‘msg_enable’ in
something not a structure or union
drivers/net/pasemi_mac.c:1231: error: request for member ‘pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1231: error: request for member ‘pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1237: error: request for member ‘type’ in
something not a structure or union
drivers/net/pasemi_mac.c:1238: error: request for member ‘dma_if’ in
something not a structure or union
drivers/net/pasemi_mac.c:1238: error: request for member ‘dma_txch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1238: error: request for member ‘dma_rxch’ in
something not a structure or union
drivers/net/pasemi_mac.c:1244: error: request for member ‘iob_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1245: error: request for member ‘iob_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1246: error: request for member ‘dma_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1247: error: request for member ‘dma_pdev’ in
something not a structure or union
drivers/net/pasemi_mac.c:1248: error: request for member ‘dma_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1249: error: request for member ‘dma_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1250: error: request for member ‘iob_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1251: error: request for member ‘iob_regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1252: error: request for member ‘regs’ in
something not a structure or union
drivers/net/pasemi_mac.c:1253: error: request for member ‘regs’ in
something not a structure or union
make[2]: *** [drivers/net/pasemi_mac.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2

In the function
static int __devinit
pasemi_mac_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
<snip>
struct pasemi_mac *mac;
int err;
DECLARE_MAC_BUF(mac);

introduction of mac as var [18] triggers the build failure, so in the
below patch
renaming mac as mac_buf is done, because it is used to print the mac
address using
the newly introduced print_mac function.

Signed-off-by: Kamalesh Babulal <***@linux.vnet.ibm.com>
---

--- linux-2.6.23-rc7/drivers/net/pasemi_mac.c 2007-09-25 03:27:45.000000000 +0530
+++ linux-2.6.23-rc7/drivers/net/~pasemi_mac.c 2007-09-25 03:27:27.000000000 +0530
@@ -1150,7 +1150,7 @@ pasemi_mac_probe(struct pci_dev *pdev, c
struct net_device *dev;
struct pasemi_mac *mac;
int err;
- DECLARE_MAC_BUF(mac);
+ DECLARE_MAC_BUF(mac_buf);

err = pci_enable_device(pdev);
if (err)
@@ -1236,7 +1236,7 @@ pasemi_mac_probe(struct pci_dev *pdev, c
"hw addr %s\n",
dev->name, mac->type == MAC_TYPE_GMAC ? "GMAC" : "XAUI",
mac->dma_if, mac->dma_txch, mac->dma_rxch,
- print_mac(mac, dev->dev_addr));
+ print_mac(mac_buf, dev->dev_addr));

return err;
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Laurent Riffard]

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

I've got this compilation when CONFIG_KEXEC=y and CCONFIG_NOHIGHMEM=y:

linux-2.6-mm$ LANG=C make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CC arch/i386/kernel/setup.o
arch/i386/kernel/setup.c: In function 'reserve_crashkernel':
arch/i386/kernel/setup.c:391: error: 'highend_pfn' undeclared (first use in this function)
arch/i386/kernel/setup.c:391: error: (Each undeclared identifier is reported only once
arch/i386/kernel/setup.c:391: error: for each function it appears in.)
arch/i386/kernel/setup.c:391: error: 'highstart_pfn' undeclared (first use in this function)
make[1]: *** [arch/i386/kernel/setup.o] Error 1
make: *** [arch/i386/kernel] Error 2


config attached.
~~
laurent

[Randy Dunlap]

[adding kexec m-l]

Post by Laurent Riffard

Post by Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc7/2.6.23-rc7-mm1/

linux-2.6-mm$ LANG=C make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
CC arch/i386/kernel/setup.o
arch/i386/kernel/setup.c:391: error: 'highend_pfn' undeclared (first use in this function)
arch/i386/kernel/setup.c:391: error: (Each undeclared identifier is reported only once
arch/i386/kernel/setup.c:391: error: for each function it appears in.)
arch/i386/kernel/setup.c:391: error: 'highstart_pfn' undeclared (first use in this function)
make[1]: *** [arch/i386/kernel/setup.o] Error 1
make: *** [arch/i386/kernel] Error 2
.config attached.
~~
laurent

---
~Randy
Phaedrus says that Quality is about caring.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/