2.6.17-rc4-mm1

2.6.17-rc4-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/

- This tree contains a large number of new bugs^H^H^H^Hpatches.

  - klibc (Kernel libc), as git-klibc.patch (Peter Anvin)

  - Header cleanups for compatibility-with-userspace feasibility and for
    the addition of the `make hdrinstall' target, as git-hdrcleanup.patch and
    git-hdrinstall.patch (David Woodhouse)

  - The cachefs patches are back (local-disk-based caching of network
    filesystem files) (David Howells)

  - Added the ecryptfs filesystem

  - per-task delay accounting patches: more advanced process accounting,
    plus an extensible interface for extended accounting.  

  - Many memory-management updates

  - Plenty of other things

  So if problems are found, please put extra effort into Cc:ing the correct
  mailing list and/or developer on any reports, thanks.




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 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 majordomo@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.



Changes since 2.6.17-rc3-mm1:


 origin.patch
 git-acpi.patch
 git-agpgart.patch
 git-alsa.patch
 git-block.patch
 git-cfq.patch
 git-cifs.patch
 git-dvb.patch
 git-gfs2.patch
 git-ia64.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-intelfb.patch
 git-klibc.patch
 git-hdrcleanup.patch
 git-hdrinstall.patch
 git-libata-all.patch
 git-mips.patch
 git-mtd.patch
 git-netdev-all.patch
 git-nfs.patch
 git-ocfs2.patch
 git-powerpc.patch
 git-rbtree.patch
 git-sas.patch
 git-pcmcia.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-cryptodev.patch
 git-viro-bird-m32r.patch
 git-viro-bird-m68k.patch
 git-viro-bird-frv.patch
 git-viro-bird-upf.patch
 git-viro-bird-volatile.patch
 git-klibc-build-hacks.patch

 git trees

-s390-make-qeth-buildable.patch
-md-avoid-oops-when-attempting-to-fix-read-errors-on-raid10.patch
-md-fixed-refcounting-locking-when-attempting-read-error-correction-in-raid10.patch
-md-change-enotsupp-to-eopnotsupp.patch
-md-improve-detection-of-lack-of-barrier-support-in-raid1.patch
-md-fix-rdev-nr_pending-count-when-retrying-barrier-requests.patch
-x86_64-add-compat_sys_vmsplice-and-use-it-in.patch
-i386-x86-64-fix-acpi-disabled-lapic-handling.patch
-i386-fix-overflow-in-e820_all_mapped.patch
-i386-remove-apic=-warning.patch
-silence-initcall-warnings.patch
-uml-fix-iomem-list-traversal.patch
-uml-skas0-support-for-2g-2g-hosts.patch
-uml-remove-null-checks-and-add-some-codingstyle.patch
-uml-clean-up-after-madvise_remove.patch
-uml-update-defconfig.patch
-uml-error-handling-fixes.patch
-page-migration-fix-fallback-behavior-for-dirty-pages.patch
-altix-correct-ioc3-port-order.patch
-sparsemem-interaction-with-memory-add-bug-fixes.patch
-spufs-fix-for-config_numa.patch
-powerpc-allow-devices-to-register-with-numa-topology.patch
-powerpc-cell-add-numa-id-to-struct-spu.patch
-s390-fix-ipd-handling.patch
-s390-bug-in-setup_rt_frame.patch
-rtc-rtc-dev-tweak-for-64-bit-kernel.patch
-genrtc-fix-read-on-64-bit-platforms.patch
-amd-alchemy-uart-claim-memory-range.patch
-make-pc-speaker-driver-work-on-x86-64.patch
-timer-tsc-check-suspend-notifier-change.patch
-acpi-memory-leakages-in-drivers-acpi-thermalc.patch
-audit-deal-with-deadlocks-in-audit_free.patch
-audit-sockaddr-patch.patch
-audit-move-call-of-audit_free-into-do_exit.patch
-audit-drop-gfp_mask-in-audit_log_exit.patch
-audit-drop-task-argument-of-audit_syscall_entryexit.patch
-audit-no-need-to-wank-with-task_lock-and-pinning-task-down-in-audit_syscall_exit.patch
-audit-support-for-context-based-audit-filtering.patch
-audit-support-for-context-based-audit-filtering-2.patch
-audit-audit-inode-patch.patch
-audit-change-lspp-ipc-auditing.patch
-audit-reworked-patch-for-labels-on-user-space-messages.patch
-audit-more-user-space-subject-labels.patch
-audit-rework-of-ipc-auditing.patch
-audit-audit-filter-performance.patch
-gregkh-driver-class-device-add-attribute_group-creation.patch
-gregkh-driver-netdev-create-attribute_groups-with-class_device_add.patch
-netdev-hotplug-napi-race-cleanup.patch
-dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616.patch
-pwc-dec23-oops-fix.patch
-scx200_acb-fix-for-cs5535-eratta.patch
-sem2mutex-drivers-ieee1394.patch
-drivers-ieee1394-ohci1394c-function-calls-without-effect.patch
-forcedeth-fix-multi-irq-issues.patch
-via-rhine-zero-pad-short-packets-on-rhine-i-ethernet-cards.patch
-mv643xx_eth-provide-sysfs-class-device-symlink.patch
-powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up.patch
-git-rbtree-uml-fix.patch
-serial-locking-cleanup.patch
-ieee80211_wxc-remove-dead-code.patch
-x86_64-mm-avoid-irq0-ioapic-pin-collision.patch
-x86_64-mm-fix-die_lock-nesting.patch
-x86_64-mm-add-nmi_exit-to-die_nmi.patch
-x86_64-mm-compat-printk-fix.patch
-x86_64-mm-new-northbridge-fix.patch
-uml-fix-patch-mismerge.patch
-uml-search-from-uml_net-in-a-more-reasonable-path.patch
-uml-use-kbuild-tracking-for-all-files-and-fix-compilation-output.patch
-uml-fix-compilation-and-execution-with-hardened-gcc.patch
-uml-cleanup-unprofile-expression-and-build-infrastructure.patch
-uml-export-symbols-added-by-gcc-hardened.patch
-reduce-nr-of-ptr-derefs-in-fs-jffs2-summaryc.patch
-remove-fs-jffs2-histoh.patch
-cleanup-default-value-of-mtd_pcmcia_anonymous.patch
-rcu-introduce-rcu_needs_cpu-interface.patch
-rcu-introduce-rcu_needs_cpu-interface-fix.patch
-s390-exploit-rcu_needs_cpu-interface.patch
-handle-config_lbd-and-config_lsf-in-one-place.patch

 Merged into mainline or a subsystem tree

+selinux-check-for-failed-kmalloc-in-security_sid_to_context.patch
+fs-openc-unexport-sys_openat.patch
+autofs4-nfy_none-wait-race-fix.patch
+autofs4-nfy_none-wait-race-fix-tidy.patch
+fix-capi-reload-by-unregistering-the-correct-major.patch
+tpm-update-module-dependencies.patch
+pcmcia-oopses-fixes.patch
+via-quirk-fixup-additional-pci-ids.patch
+smbfs-chroot-issue-cve-2006-1864.patch
+rcu-introduce-rcu_needs_cpu-interface.patch
+rcu-introduce-rcu_needs_cpu-interface-fix.patch
+s390-exploit-rcu_needs_cpu-interface.patch
+setup_per_zone_pages_min-overflow-fix.patch
+s390-lcs-incorrect-test.patch
+initramfs-fix-cpio-hardlink-check.patch
+s390-add-vmsplice-system-call.patch
+symbol_put_addr-locks-kernel.patch
+contact-info-update.patch
+smbfs-fix-slab-corruption-in-samba-error-path.patch
+add-slab_is_available-routine-for-boot-code.patch
+led-improve-kconfig-information.patch
+backlight-lcd-class-fix-sysfs-_store-error-handling.patch
+led-add-maintainer-entry-for-the-led-subsystem.patch
+led-fix-sysfs-store-function-error-handling.patch
+v9fs-twalk-memory-leak.patch
+v9fs-signal-handling-fixes.patch
+fix-can_share_swap_page-when-config_swap.patch
+add-core-solo-and-core-duo-support-to-oprofile.patch
+tpm-fix-constant.patch
+final-rio-polish.patch
+final-rio-polish-fix.patch
+tpm_register_hardware-gcc-41-warning-fix.patch
+fs-compatc-fix-if-a-=-b-typo.patch
+root-mount-failure-emit-filesystems-attempted.patch
+revert-vfs-propagate-mnt_flags-into-do_loopback-vfsmount.patch
+smbus-unhiding-kills-thermal-management.patch
+fix-hotplug-kconfig-help.patch
+zone-init-check-and-report-unaligned-zone-boundaries.patch
+x86-align-highmem-zone-boundaries-with-numa.patch
+zone-allow-unaligned-zone-boundaries.patch
+gigaset-endian-fix.patch
+fix-typos-in-documentation-memory-barrierstxt.patch
+ide_cs-add-ibm-microdrive-to-known-ids.patch
+nfs-fix-error-handling-on-access_ok-in-compat_sys_nfsservctl.patch
+devices-txt-remove-pktcdvd-entry.patch
+jffs2-warning-fixes.patch
+dl2k-build-fix.patch

 2.6.17 queue

+acpi-dock-driver-v4.patch
+acpi-dock-driver-interface-fixups.patch

 Updates and fixes against acpi-dock-driver.patch

+asus_acpi-w3000-support.patch

 Asus ACPI driver update

+uninorth-agp-warning-fixes.patch
+alpha-agp-warning-fix.patch

 AGP fixes

+blk_start_queue-must-be-called-with-irq-disabled-add-warning.patch

 block layer debug check

+cifs-do-not-overwrite-aops-elements.patch

 CIFS was being bad.

+dprintk-adjustments-to-cpufreq-nforce2.patch
+dprintk-adjustments-to-cpufreq-speedstep-centrino.patch
+cpufreq-dprintk-adjustments.patch

 cpufreq driover cleanups and fixes

+gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
+gregkh-driver-driver-core-config_debug_pm-covers-drivers-base-power-too.patch
+gregkh-driver-platform_bus-learns-about-modalias.patch
+gregkh-driver-driver-core-remove-exports.patch
+gregkh-driver-kevent-add-new-uevent.patch
+gregkh-driver-driver-core-allow-sysdev_class-have-attributes.patch
+gregkh-driver-driver-core-fix-platform_device_add-to-use-device_add.patch
+gregkh-driver-driver-core-add-sys-hypervisor-when-needed.patch
+gregkh-driver-kobject-warn.patch
+gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch

 Driver tree updates

+gregkh-driver-platform_bus-learns-about-modalias-warning-fix.patch
+gregkh-driver-warn-when-statically-allocated-kobjects-are-used-fix.patch

 Fix them.

+drivers-base-firmware_classc-cleanups.patch
+s3c24xx-gpio-based-spi-driver.patch
+s3c24xx-hardware-spi-driver.patch
+s3c24xx-hardware-spi-driver-tidy.patch

 Other driver tree things.

+scx200_acb-use-pci-i-o-resource-when-appropriate-fix.patch

 Fix scx200_acb-use-pci-i-o-resource-when-appropriate.patch

+w1-warning-fix.patch

 Fix warning

-disable-atykb-warning.patch
+remove-silly-messages-from-input-layer.patch

 New version

+via-pmu-add-input-device.patch
+via-pmu-add-input-device-tidy.patch
+fix-mem-leak-in-sidewinder-driver.patch

 Input things.

+add-dependency-on-kernelrelease-to-the-package-targets.patch

 kbuild feature

+kbuild-export-type-enhancement-to-modpostc.patch
+kbuild-prevent-building-modules-that-wont-load.patch
+kbuild-export-symbol-usage-report-generator.patch

 More kbuild work

+git-klibc-alpha-fixes.patch
+git-klibc-ident-fix.patch
+git-klibc-build-hacks.patch

+git-hdrcleanup-fixup.patch
+git-hdrcleanup-vs-git-klibc-on-ia64.patch
+git-hdrcleanup-vs-git-klibc-on-ia64-2.patch

+git-hdrinstall-fixup.patch

 Various fixes against the new git trees

+sdhci-truncated-pointer-fix.patch

 MMC fix

+nand_base-modular-fix.patch
+git-mtd-non-arm-fix.patch
+git-mtd-isnt-arm-only.patch

 MTD fixes

+drivers-char-hw_randomc-remove-asserts.patch

 hw_random cleanup

+fix-phy-id-for-lxt971a-lxt972a.patch

 net driver fix

+clean-up-initcall-warning-for-netconsole.patch
+remove-dead-entry-in-net-wan-kconfig.patch
+ppp_async-hang-fix.patch
+selinux-add-security-class-for-appletalk-sockets.patch
+fix-mem-leak-in-netfilter.patch
+neighbourc-pneigh_get_next-skips-published-entry.patch

 networking

+nfs-permit-filesystem-to-override-root-dentry-on-mount.patch
+nfs-permit-filesystem-to-perform-statfs-with-a-known-root-dentry.patch
+ipath-vs-nfs-permit-filesystem-to-override-root-dentry-on-mount.patch
+git-gfs2-vs-nfs-permit-filesystem-to-override-root-dentry-on-mount.patch
+nfs-abstract-out-namespace-initialisation.patch
+nfs-add-dentry-materialisation-op.patch
+nfs-split-fs-nfs-inodec-into-inode-superblock-and-namespace-bits.patch
+nfs-share-nfs-superblocks-per-protocol-per-server-per-fsid.patch
+nfs-share-nfs-superblocks-per-protocol-per-server-per-fsid-fix.patch
+nfs-share-nfs-superblocks-per-protocol-per-server-per-fsid-warning-fixes.patch
+fs-cache-provide-a-filesystem-specific-syncable-page-bit.patch
+fs-cache-add-notification-of-page-becoming-writable-to-vma-ops.patch
+fs-cache-avoid-enfile-checking-for-kernel-specific-open-files.patch
+fs-cache-generic-filesystem-caching-facility.patch
+fs-cache-make-kafs-use-fs-cache.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-export-__audit_inode_child.patch
+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-warning-fixes.patch
+fs-cache-vs-vfs-add-lock-owner-argument-to-flush-operation.patch
+fs-cache-release-page-private-in-failed-readahead.patch
+fs-cache-release-page-private-in-failed-readahead-uninlining.patch
+fs-cache-release-page-private-in-failed-readahead-uninlining-2.patch
+nfs-use-local-caching.patch
+nfs-use-local-caching-fix.patch

 cachefs

+powerpc-pseries-increment-fail-counter-in-pci-recovery.patch
+powerpc-kbuild-warning-fix.patch

 powerpc fixes

+fix-pciehp-compile-issue-when-config_acpi-is-not.patch
+i386-export-memory-more-than-4g-through-proc-iomem.patch
+fix-recovery-path-from-errors-during-pcie_init.patch
+move-various-pci-ids-to-header-file.patch

 PCI fixes

-pci-add-pci_assign_resource_fixed-allow-fixed-address-fix.patch

 Folded into pci-add-pci_assign_resource_fixed-allow-fixed-address.patch

+kconfigurable-resources-core-changes.patch
+kconfigurable-resources-core-changes-i386-fix.patch
+kconfigurable-resources-core-changes-fix.patch
+kconfigurable-resources-driver-pci-changes.patch
+kconfigurable-resources-driver-others-changes.patch
+kconfigurable-resources-arch-dependent-changes-arch-a-i.patch
+kconfigurable-resources-arch-dependent-changes-arch-a-i-fix.patch
+kconfigurable-resources-arch-dependent-changes-arch-j-p.patch
+kconfigurable-resources-arch-dependent-changes-arch-q-z.patch
+typesh-sector_t-and-blkcnt_t-arent-for-userspace.patch

 Make the newly-64-bit resource.start and resource.end Kconfigurably 32-bit.

+ti-pcixx12-cardbus-controller-support.patch

 Cardbus controller device support

+drivers-scsi-use-array_size-macro.patch
+lpfc-sparse-null-warnings.patch
+mpt_interrupt-should-return-irq_none-when.patch
+aic7-cleanup-module_parm_desc-strings.patch
+qla2xxx-lock-ordering-fix.patch
+qla2xxx-lock-ordering-fix-warning-fix.patch
+random-remove-redundant-sa_sample_random-from-ninjascsi.patch
+megaraid-gcc-41-warning-fix.patch
+buslogic-gcc-41-warning-fixes.patch
+add-scsi_add_host-failure-handling-for-nsp32.patch

 scsi things

+gregkh-usb-usb-console-fix-disconnection-issues.patch
+gregkh-usb-usb-clean-out-an-unnecessary-null-check-from-ub.patch
+gregkh-usb-usbatm-remove-pointless-inline.patch
+gregkh-usb-usbatm-remove-no-longer-needed-include.patch
+gregkh-usb-usb-phidget-interfacekit-make-inputs-pollable-and-new-device-support.patch
+gregkh-usb-usb-shuttle_usbat-fix-handling-of-scatter-gather-buffers.patch
+gregkh-usb-usb-shuttle_usbat-hardcode-detection-of-hp-cdrw-devices.patch
+gregkh-usb-usb-shuttle_usbat-hardcode-flash-detection-for-now.patch
+gregkh-usb-usb-usb-storage-alauda-fix-transport-info-mismerge.patch
+gregkh-usb-usb-net2280-add-a-shutdown-routine.patch
+gregkh-usb-usb-uhci-store-the-endpoint-type-in-the-qh-structure.patch
+gregkh-usb-usb-uhci-fix-obscure-bug-in-enqueue.patch
+gregkh-usb-usb-hid-hidbp-input-drivers-fix-various-usb-input-hid-input.c-bugs-that-make-apple-mighty-mouse-work-poorly.patch

 USB tree updates

-fix-sco-on-some-bluetooth-adapters.patch
+fix-sco-on-some-bluetooth-adapters-2.patch

 New version

+x86_64-mm-add-end-endproc-annotations-to-entrys.patch
+x86_64-mm-i386-numa-summit-check.patch
+x86_64-mm-fix-unlikely-profiling--vsyscalls-on-x86_64.patch
+x86_64-mm-fix-b44-checks.patch
+x86_64-mm-nommu-warning.patch
+x86_64-mm-nmi-watchdog-header-cleanup.patch
+x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch
+x86_64-mm-utilize-performance-counter-reservation-framework-in-oprofile.patch
+x86_64-mm-add-smp-support-on-x86_64-to-reservation-framework.patch
+x86_64-mm-add-smp-support-on-i386-to-reservation-framework.patch
+x86_64-mm-cleanup-nmi-interrupt-path.patch
+x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions.patch
+x86_64-mm-add-abilty-to-enable-disable-nmi-watchdog-from-sysfs.patch

 x86_64 tree updates

+x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix.patch
+x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix-fix.patch
+x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86_64-fix.patch
+x86_64-mm-serialize-assign_irq_vector-use-of-static-variables-fix.patch
+add-abilty-to-enable-disable-nmi-watchdog-from-procfs.patch

 Fix them.

-gregkh-devfs-devfs-die-die-die.patch
-gregkh-devfs-devfs-remove-documentation.patch
-gregkh-devfs-devfs-scrub-partitions.patch
-gregkh-devfs-devfs-scrub-init.patch
-gregkh-devfs-devfs-remove-serial-subsystem.patch
-gregkh-devfs-devfs-remove-ide-subsystem.patch
-gregkh-devfs-devfs-remove-sound-subsystem.patch
-gregkh-devfs-devfs-remove-devfs-tape.patch
-gregkh-devfs-devfs-remove-devfs_mk_dir.patch
-gregkh-devfs-devfs-remove-devfs_mk_symlink.patch
-gregkh-devfs-devfs-remove-devfs_mk_bdev.patch
-gregkh-devfs-devfs-remove-devfs_mk_cdev.patch
-gregkh-devfs-devfs-remove-devfs_remove.patch
-gregkh-devfs-devfs-remove-devfs_fs_kernel.h.patch
-gregkh-devfs-devfs-remove-misc-devfs_name.patch
-gregkh-devfs-devfs-remove-genhd-devfs_name.patch
-gregkh-devfs-devfs-remove-videodev-devfs_name.patch
-gregkh-devfs-devfs-remove-line-devfs_name.patch
-gregkh-devfs-devfs-remove-tty-devfs_name.patch
-gregkh-devfs-devfs-tty_driver_no_devfs.patch
-gregkh-devfs-devfs-minor-cleanups.patch
-gregkh-devfs-devfs-feature-removal.patch

 Dropped - too much overlap with the klibc work

+pgdat-allocation-for-new-node-add-specify-node-id-tidy-cleanup.patch
+fix-compile-error-undefined-reference-for-sparc64.patch

 Fix pgdat-allocation-for-new-node-add-specify-node-id.patch some more

+pgdat-allocation-and-update-for-ia64-of-memory-hotplughold-pgdat-address-at-system-running.patch
+pgdat-allocation-and-update-for-ia64-of-memory-hotplug-update-pgdat-address-array.patch
+pgdat-allocation-and-update-for-ia64-of-memory-hotplugallocate-pgdat-and-per-node-data.patch
+page-migration-cleanup-extract-try_to_unmap-from-migration-functions-update-comments-7.patch
+page-migration-cleanup-move-fallback-handling-into-special-function-update-comments-9.patch
+swapless-pm-add-r-w-migration-entries-fix.patch
+swapless-pm-add-r-w-migration-entries-ifdefs.patch
+swapless-pm-add-r-w-migration-entries-update-comments.patch
+swapless-pm-add-r-w-migration-entries-update-comments-4.patch
+swapless-pm-add-r-w-migration-entries-update-comments-6.patch
+swapless-page-migration-modify-core-logic-remove-useless-mapping-checks.patch
+more-page-migration-use-migration-entries-for-file-pages-fix.patch
+more-page-migration-use-migration-entries-for-file-pages-update-comments-5.patch
+more-page-migration-use-migration-entries-for-file-pages-update-comments-8.patch
+more-page-migration-use-migration-entries-for-file-pages-remove_migration_ptes.patch
+more-page-migration-use-migration-entries-for-file-pages-replace-call-to-pageout-with-writepage-2.patch
+page-migration-update-documentation.patch
+aop_truncated_page-victims-in-read_pages-belong-in-the-lru.patch
+introduce-mechanism-for-registering-active-regions-of-memory.patch
+have-power-use-add_active_range-and-free_area_init_nodes.patch
+have-x86-use-add_active_range-and-free_area_init_nodes.patch
+have-x86_64-use-add_active_range-and-free_area_init_nodes.patch
+#have-ia64-use-add_active_range-and-free_area_init_nodes.patch
+tracking-dirty-pages-in-shared-mappings-v4.patch
+tracking-dirty-pages-in-shared-mappings-v4-fix2.patch
+tracking-dirty-pages-in-shared-mappings-v4-fix3.patch
+throttle-writers-of-shared-mappings.patch
+throttle-writers-of-shared-mappings-tidy.patch
+optimize-follow_pages.patch
+slab-verify-pointers-before-free.patch
+sparsemem-record-nid-during-memory-present.patch

 Memory management updates

+fix-x86-microcode-driver-handling-of-multiple-matching.patch
+i386-break-out-of-recursion-in-stackframe-walk.patch
+dont-trigger-full-rebuild-via-config_x86_mce.patch

 x86 updates

-x86_64-disable-tsc-with-seccomp.patch

 Dropped

+remove-duplicate-symbol-exports-on-alpha.patch

 Cleanup

+swsusp-documentation-updates.patch
+swsusp-fix-typo-in-cr0-handling.patch

 swsusp updates

-s390-hypervisor-file-system.patch
-s390-hypervisor-file-system-fixes.patch

 Dropped (what I had was out of date and it got all confusing.  Need a resend)

+add-raw-driver-kconfig-entry-for-s390.patch

 Enable raw driver on s390

+percpu-counter-data-type-changes-to-suppport-fix-fix-fix.patch

 Fix percpu-counter-data-type-changes-to-suppport.patch some more

+make-rcu-api-inaccessible-to-non-gpl-linux-kernel-modules.patch
+doc-add-audit-acct-to-docbook.patch
+ip2-fix-sections.patch
+sgi-ioc4-detect-io-card-variant.patch
+two-additions-to-linux-documentation-ioctl-numbertxt.patch
+when-config_base_samll=1-the-kernel-261611-cascade-in-kernel-timerc-may-enter-the-infinite-loop.patch
+codingstyle-add-typedefs-chapter.patch
+fs-bufferc-possible-cleanups.patch
+rtc-rtc-dev-uie-emulation.patch
+drivers-md-raid6algosc-fix-a-null-dereference.patch
+adjust-handle_irr_event-return-type.patch
+sparse-fixes-for-synclink_cs.patch
+jbd-split-checkpoint-lists.patch
+jbd-split-checkpoint-lists-tidy.patch
+add-__iowrite64_copy.patch
+add-pci_cap_id_vndr.patch
+mark-address_space_operations-const.patch
+mark-address_space_operations-const-fix.patch
+mark-address_space_operations-const-fix-2.patch
+more-bug_on-conversion.patch
+make-kernel-ignore-bogus-partitions.patch
+drivers-block-loopc-dont-return-garbage-if-loop_set_status-not-called.patch
+docs-update-sparsetxt-with-check_endian.patch
+drivers-acorn-char-pcf8583-vs-rtc-subsystem.patch
+rewritten-backlight-infrastructure-for-portable-apple-computers.patch
+ensure-null-deref-cant-possibly-happen-in-is_exported.patch
+bluetooth-fix-potential-null-ptr-deref-in-dtl1_cscdtl1_hci_send_frame.patch
+bloat-o-meter-gcc-4-fix.patch
+random-remove-sa_sample_random-from-floppy-driver.patch
+random-make-cciss-use-add_disk_randomness.patch
+random-change-cpqarray-to-use-add_disk_randomness.patch
+random-remove-bogus-sa_sample_random-from-at91-compact-flash-driver.patch
+random-remove-redundant-sa_sample_random-from-touchscreen-drivers.patch
+define-__raw_get_cpu_var-and-use-it.patch
+allow-for-per-cpu-data-being-in-tdata-and-tbss-sections.patch
+allow-for-per-cpu-data-being-in-tdata-and-tbss-sections-fix.patch
+allow-for-per-cpu-data-being-in-tdata-and-tbss-sections-tidy.patch
+deprecate-smbfs-in-favour-of-cifs.patch
+allow-raw_notifier-callouts-to-unregister-themselves.patch
+hptiop-highpoint-rocketraid-3xxx-controller-driver.patch
+hptiop-highpoint-rocketraid-3xxx-controller-driver-list-locking.patch
+hptiop-highpoint-rocketraid-3xxx-controller-driver-list-locking-updates.patch
+hptiop-highpoint-rocketraid-3xxx-controller-driver-list-locking-updates-updates-2.patch
+fix-kbuild-dependencies-for-synclink-drivers.patch
+fs-freevxfs-cleanup-of-spelling-errors.patch
+pnp-card_probe-fix-memory-leak.patch
+fix-unlikely-memory-leak-in-dac960-driver.patch
+ufs-ufs_trunc_indirect-infinite-cycle.patch
+ufs-right-block-allocation.patch
+ufs-right-block-allocation-fixes.patch
+sunsu-license-fix.patch

 Patches ;)

+per-task-delay-accounting-setup.patch
+per-task-delay-accounting-setup-fix-1.patch
+per-task-delay-accounting-setup-fix-2.patch
+per-task-delay-accounting-sync-block-i-o-and-swapin-delay-collection.patch
+per-task-delay-accounting-sync-block-i-o-and-swapin-delay-collection-fix-1.patch
+per-task-delay-accounting-cpu-delay-collection-via-schedstats.patch
+per-task-delay-accounting-cpu-delay-collection-via-schedstats-fix-1.patch
+per-task-delay-accounting-utilities-for-genetlink-usage.patch
+per-task-delay-accounting-taskstats-interface.patch
+per-task-delay-accounting-taskstats-interface-fix-1.patch
+per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface.patch
+per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface-use-portable-cputime-api-in-__delayacct_add_tsk.patch
+per-task-delay-accounting-documentation.patch
+per-task-delay-accounting-proc-export-of-aggregated-block-i-o-delays.patch
+per-task-delay-accounting-proc-export-of-aggregated-block-i-o-delays-warning-fix.patch

 per-task delay accounting

+time-use-clocksource-abstraction-for-ntp-adjustments-optimize-out-some-mults-since-gcc-cant-avoid-them.patch
+time-i386-clocksource-drivers-fix-spelling-typos.patch
+generic-time-add-macro-to-simplify-hide-mask.patch

 Updates to the x86 time management patches

-mmc-multi-sector-writes.patch

 Dropped

+capi-crash--race-condition.patch

 i4l semifix

+kconfig-select-things-at-the-closest-tristate-instead-of-bool.patch

 nfsd Kconfig fix

+sched-comment-bitmap-size-accounting.patch
+unnecessary-long-index-i-in-sched.patch

 CPU scheduler work

+mm-implement-swap-prefetching-fix.patch
+mm-implement-swap-prefetching-sched-batch.patch

 swap-prefetch fixes

+pi-futex-patchset-v4-fix.patch
+document-futex-pi-design.patch
+document-futex-pi-design-fix.patch
+document-futex-pi-design-fix-fix.patch
+futex_requeue-optimization.patch

 pi-futex updates

+de_thread-fix-lockless-do_each_thread.patch

 task maangment fix

+coredump-kill-ptrace-related-stuff-fix.patch

 Fix coredump-kill-ptrace-related-stuff.patch

+ecryptfs-fs-makefile-and-fs-kconfig.patch
+ecryptfs-documentation.patch
+ecryptfs-makefile.patch
+ecryptfs-main-module-functions.patch
+ecryptfs-main-module-functions-vs-nfs-permit-filesystem-to-override-root-dentry-on-mount.patch
+ecryptfs-header-declarations.patch
+ecryptfs-superblock-operations.patch
+ecryptfs-dentry-operations.patch
+ecryptfs-file-operations.patch
+ecryptfs-inode-operations.patch
+ecryptfs-mmap-operations.patch
+mark-address_space_operations-const-vs-ecryptfs-mmap-operations.patch
+ecryptfs-keystore.patch
+ecryptfs-crypto-functions.patch
+ecryptfs-debug-functions.patch
+ecryptfs-alpha-build-fix.patch

 ecryptfs

+reiser4-add-missing-txn_restart-before-get_nonexclusive_access-calls.patch
+reiser4-check-radix-tree-emptiness-properly.patch
+reiser4-check-radix-tree-emptiness-properly-2.patch

 reiser4 updates

+reiser4-vs-nfs-permit-filesystem-to-override-root-dentry-on-mount.patch
+reiser4-vs-nfs-permit-filesystem-to-perform-statfs-with-a-known-root-dentry.patch

 Fix reiser4 damage due to other patches

+ide-fix-hpt37x-timing-tables.patch
+ide-optimize-hpt37x-timing-tables.patch
+ide-fix-hpt3xx-hotswap-support.patch
+ide-fix-the-case-of-multiple-hpt3xx-chips-present.patch
+ide-hpt3xx-fix-pci-clock-detection.patch
+ide-pdc202xx_old-remove-the-obsolete-busproc.patch
+piix-fix-82371mx-enablebits.patch
+piix-remove-check-for-broken-mw-dma-mode-0.patch
+piix-slc90e66-pio-mode-fallback-fix.patch
+make-number-of-ide-interfaces-configurable.patch

 IDE driver fixes

+nvidiafb-add-support-for-geforce-6100-and-related-chipsets.patch
+fbdev-add-1366x768-wxga-mode-to-mode-database.patch
+intelfb-use-firmware-edid-for-mode-database.patch
+vesafb-fix-return-code-of-vesafb_setcolreg.patch
+vesafb-prefer-vga-registers-over-pmi.patch
+vt-delay-the-update-of-the-visible-console.patch
+atyfb-fix-dead-code.patch
+fbdev-coverity-bug-85.patch
+fbdev-coverity-bug-90.patch

 fbdev driver updates

+md-bitmap-fix-online-removal-of-file-backed-bitmaps.patch
+md-bitmap-remove-bitmap-writeback-daemon.patch
+md-bitmap-cleaner-separation-of-page-attribute-handlers-in-md-bitmap.patch
+md-bitmap-use-set_bit-etc-for-bitmap-page-attributes.patch
+md-bitmap-remove-unnecessary-page-reference-manipulations-from-md-bitmap-code.patch
+md-bitmap-remove-dead-code-from-md-bitmap.patch
+md-bitmap-tidy-up-i_writecount-handling-in-md-bitmap.patch
+md-bitmap-change-md-bitmap-file-handling-to-use-bmap-to-file-blocks.patch

 RAID updates

-nmi-lockup-and-altsysrq-p-dumping-calltraces-on-_all_-cpus.patch
-x86_64-ipi-calltraces.patch

 Dropped due to rejects

-exit-dont-call-sleeping-things-when-oopsing.patch

 Dropped due to lack of interest



All 992 patches:

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

Re: 2.6.17-rc4-mm1

[Eric Dumazet]

Hi Andrew

It seems latest kernels have a problem in kmem_cache_destroy()

On a dual opteron machine (NUMA), its quite easy do trigger the bug : 
doing a oprofile session like :

opcontrol --setup --event=CPU_CLK_UNHALTED:100000 
--vmlinux=/usr/src/linux-2.6.17-rc4-mm1/vmlinux
...
opcontrol --dump
...
opcontrol --deinit    <<<-- Triggers the bug

slab error in kmem_cache_destroy(): cache `dcookie_cache': Can't free 
all objects

Call Trace: <ffffffff80278aa4>{kmem_cache_destroy+212}
       <ffffffff802bc559>{dcookie_unregister+345} 
<ffffffff803bbe7a>{event_buffer_release+26}
       <ffffffff8027cee2>{__fput+98} <ffffffff80279ecd>{filp_close+93}
       <ffffffff8023003e>{put_files_struct+110} 
<ffffffff8023143a>{do_exit+650}
       <ffffffff802f58f1>{__up_write+33} 
<ffffffff80231bb8>{do_group_exit+200}
       <ffffffff802097ce>{system_call+126}

# grep dcookie_cache /proc/slabinfo
dcookie_cache          0      0     32  101    1 : tunables  120   60    
8 : slabdata      0      0      0


This problem is annoying, because in the oprofile case, we must reboot 
the machine to be able to start a new profile session.

Eric

Re: 2.6.17-rc4-mm1

[Andrew Morton]

Eric Dumazet <dada1@cosmosbay.com> wrote:
>
> Hi Andrew
> 
> It seems latest kernels have a problem in kmem_cache_destroy()

Mainline, or just -mm?

> On a dual opteron machine (NUMA), its quite easy do trigger the bug : 
> doing a oprofile session like :
> 
> opcontrol --setup --event=CPU_CLK_UNHALTED:100000 
> --vmlinux=/usr/src/linux-2.6.17-rc4-mm1/vmlinux
> ...
> opcontrol --dump
> ...
> opcontrol --deinit    <<<-- Triggers the bug
> 
> slab error in kmem_cache_destroy(): cache `dcookie_cache': Can't free 
> all objects
> 
> Call Trace: <ffffffff80278aa4>{kmem_cache_destroy+212}
>        <ffffffff802bc559>{dcookie_unregister+345} 
> <ffffffff803bbe7a>{event_buffer_release+26}
>        <ffffffff8027cee2>{__fput+98} <ffffffff80279ecd>{filp_close+93}
>        <ffffffff8023003e>{put_files_struct+110} 
> <ffffffff8023143a>{do_exit+650}
>        <ffffffff802f58f1>{__up_write+33} 
> <ffffffff80231bb8>{do_group_exit+200}
>        <ffffffff802097ce>{system_call+126}
> 
> # grep dcookie_cache /proc/slabinfo
> dcookie_cache          0      0     32  101    1 : tunables  120   60    
> 8 : slabdata      0      0      0
> 
> 
> This problem is annoying, because in the oprofile case, we must reboot 
> the machine to be able to start a new profile session.
> 

sony:/home/akpm# opcontrol --setup --event=CPU_CLK_UNHALTED:100000  --vmlinux=/boot/vmlinux-2.6.17-rc4-mm1
sony:/home/akpm# opcontrol --start
Using 2.6+ OProfile kernel interface.
Reading module info.
Using log file /var/lib/oprofile/oprofiled.log
Daemon started.
Profiler running.
sony:/home/akpm# opcontrol --dump 
sony:/home/akpm# opcontrol --stop
Stopping profiling.
sony:/home/akpm# opcontrol --deinit
Stopping profiling.
Killing daemon.
Unloading oprofile module
sony:/home/akpm# dmesg

   <nothing>

Can you provide a more detailed method for reproducing this?

Re: 2.6.17-rc4-mm1

[Pekka Enberg]

Hi Andrew,

Eric Dumazet <dada1@cosmosbay.com> wrote:
> > It seems latest kernels have a problem in kmem_cache_destroy()

On 5/15/06, Andrew Morton <akpm@osdl.org> wrote:
> Mainline, or just -mm?

Could be in mainline. See the following thread:
http://lkml.org/lkml/2006/4/27/69. Can't reproduce locally so waiting
for git bisect results from the original reporter...

                                     Pekka

Re: 2.6.17-rc4-mm1

[Reuben Farrelly]

On 15/05/2006 7:56 p.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> 
> - This tree contains a large number of new bugs^H^H^H^Hpatches.

Indeed.  This is the first -mm in a fair while that has crapped itself on boot 
on my box.

NeilB - is this yours?

usbcore: registered new driver libusual
usbcore: registered new driver hiddev
input: Belkin Components Belkin OmniView KVM Switch as /class/input/input0
input: USB HID v1.00 Keyboard [Belkin Components Belkin OmniView KVM Switch] on 
usb-0000:00:1d.0-1.1
input: Belkin Components Belkin OmniView KVM Switch as /class/input/input1
input: USB HID v1.00 Mouse [Belkin Components Belkin OmniView KVM Switch] on 
usb-0000:00:1d.0-1.1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EDAC MC: Ver: 2.0.0 May 15 2006
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing unused kernel memory: 208k freed
Red Hat nash version 5.0.39 starting
Mounting proc filesystem
Mounting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug.
Creating block device nodes.
Loading ide-disk.ko module
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdc11 ...
md:  adding sdc11 ...
md: sdc10 has different UUID to sdc11
md: sdc7 has different UUID to sdc11
md: sdc6 has different UUID to sdc11
md: sdc5 has different UUID to sdc11
md: sdc3 has different UUID to sdc11
md: sdc2 has different UUID to sdc11
md:  adding sda11 ...
md: sda10 has different UUID to sdc11
md: sda7 has different UUID to sdc11
md: sda6 has different UUID to sdc11
md: sda5 has different UUID to sdc11
md: sda3 has different UUID to sdc11
md: sda2 has different UUID to sdc11
md: created md5
md: bind<sda11>
md: bind<sdc11>
md: running: <sdc11><sda11>
raid1: raid set md5 active with 0 out of 2 mirrors
md: considering sdc10 ...
md:  adding sdc10 ...
md: sdc7 has different UUID to sdc10
md: sdc6 has different UUID to sdc10
md: sdc5 has different UUID to sdc10
md: sdc3 has different UUID to sdc10
md: sdc2 has different UUID to sdc10
md:  adding sda10 ...
md: sda7 has different UUID to sdc10
md: sda6 has different UUID to sdc10
md: sda5 has different UUID to sdc10
md: sda3 has different UUID to sdc10
md: sda2 has different UUID to sdc10
md: created md6
md: bind<sda10>
md: bind<sdc10>
md: running: <sdc10><sda10>
raid1: raid set md6 active with 0 out of 2 mirrors
md: considering sdc7 ...
md:  adding sdc7 ...
md: sdc6 has different UUID to sdc7
md: sdc5 has different UUID to sdc7
md: sdc3 has different UUID to sdc7
md: sdc2 has different UUID to sdc7
md:  adding sda7 ...
md: sda6 has different UUID to sdc7
md: sda5 has different UUID to sdc7
md: sda3 has different UUID to sdc7
md: sda2 has different UUID to sdc7
md: created md4
md: bind<sda7>
md: bind<sdc7>
md: running: <sdc7><sda7>
raid1: raid set md4 active with 0 out of 2 mirrors
Unable to handle kernel NULL pointer dereference at 0000000000000010 RIP:
<ffffffff8040e828>{bitmap_create+152}
PGD 3ed90067 PUD 3ed91067 PMD 0
Oops: 0000 [1] SMP
last sysfs file: /block/fd0/removable
CPU 0
Modules linked in: ide_disk
Pid: 1, comm: init Not tainted 2.6.17-rc4-mm1 #1
RIP: 0010:[<ffffffff8040e828>] <ffffffff8040e828>{bitmap_create+152}
RSP: 0000:ffff81003f603ad8  EFLAGS: 00010246
RAX: 0000000000000008 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810037d424c0
RBP: ffff810037d423c0 R08: 0000000000005d7a R09: 0000000000000000
R10: ffff810037d423c0 R11: 0000000000000100 R12: 00000000fffffff4
R13: ffff81003ed65000 R14: 00000000000f3180 R15: ffff81003ed650d0
FS:  000000000066e890(0063) GS:ffffffff8060e000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000010 CR3: 000000003ed89000 CR4: 00000000000006e0
Process init (pid: 1, threadinfo ffff81003f602000, task ffff81003f601530)
Stack: ffff810037d94fc0 ffffffff80406ee6 0000000100000001 000000013edb40c0
        ffff81003edb40c0 ffff81003ed65018 ffff810037d44f40 ffff810037d427c0
        ffff81003ed65000 ffffffff80404a16
Call Trace: <ffffffff80406ee6>{md_register_thread+167}
        <ffffffff80404a16>{run+942} <ffffffff804080c8>{do_md_run+1208}
        <ffffffff804067ae>{bind_rdev_to_array+494} 
<ffffffff8034d826>{kobject_register+51}
        <ffffffff804069c4>{mddev_find+122} <ffffffff8040865d>{autorun_devices+731}
        <ffffffff80224627>{alloc_inode+246} <ffffffff8040b445>{md_ioctl+165}
        <ffffffff802d641d>{sysfs_make_dirent+27} 
<ffffffff80259cac>{kobject_uevent+220}
        <ffffffff802d5cc4>{sysfs_add_file+118} 
<ffffffff8034690c>{blkdev_driver_ioctl+92}
        <ffffffff80346fd8>{blkdev_ioctl+1704} 
<ffffffff802b536f>{check_disk_change+31}
        <ffffffff8040c84b>{md_open+92} <ffffffff802b5df6>{blkdev_open+0}
        <ffffffff802b5df6>{blkdev_open+0} <ffffffff802b5adb>{do_open+651}
        <ffffffff802b583d>{bdget+277} <ffffffff802b5df6>{blkdev_open+0}
        <ffffffff802b5e17>{blkdev_open+33} <ffffffff8021d712>{__dentry_open+258}
        <ffffffff802b51a8>{block_ioctl+27} <ffffffff802429a1>{do_ioctl+33}
        <ffffffff8022fb0c>{vfs_ioctl+636} <ffffffff8024d8b8>{sys_ioctl+91}
        <ffffffff8025ea72>{system_call+126}

Code: 48 8b 43 10 48 8b 40 10 48 8b b8 10 01 00 00 e8 cf cd e4 ff
RIP <ffffffff8040e828>{bitmap_create+152} RSP <ffff81003f603ad8>
CR2: 0000000000000010
  <0>Kernel panic - not syncing: Attempted to kill init!
  <0>Rebooting in 60 seconds..


-rc3-mm1 doesn't have this problem, but rc4-mm1 does.  It seems like the right 
devices are found and added but no md is created for them.

Here's some output with -rc3-mm1 which is ok:

[root@tornado ~]# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdc3[1] sda3[0]
       4891712 blocks [2/2] [UU]
       bitmap: 2/150 pages [8KB], 16KB chunk

md2 : active raid1 sdc5[1] sda5[0]
       4891648 blocks [2/2] [UU]
       bitmap: 19/150 pages [76KB], 16KB chunk

md3 : active raid1 sdc6[1] sda6[0]
       104320 blocks [2/2] [UU]
       bitmap: 1/13 pages [4KB], 4KB chunk

md4 : active raid1 sdc7[1] sda7[0]
       497856 blocks [2/2] [UU]
       bitmap: 3/61 pages [12KB], 4KB chunk

md6 : active raid1 sdc10[1] sda10[0]
       20008832 blocks [2/2] [UU]

md5 : active raid1 sdc11[1] sda11[0]
       20008832 blocks [2/2] [UU]

md0 : active raid1 sdc2[1] sda2[0]
       24410688 blocks [2/2] [UU]
       bitmap: 16/187 pages [64KB], 64KB chunk

unused devices: <none>
[root@tornado ~]#

Box is an x86_64 with raid-1/SATA.

Thanks,
Reuben

Re: 2.6.17-rc4-mm1

[Eric Dumazet]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

Andrew Morton a écrit :
> Eric Dumazet <dada1@cosmosbay.com> wrote:
>   
>> Hi Andrew
>>
>> It seems latest kernels have a problem in kmem_cache_destroy()
>>     
>
> Mainline, or just -mm?
>
>   
Mainline and mm it seems, only if NUMA is ON, on 2.6.17 only (2.6.16.XX 
is OK)

I added some printks and it seems slab_partials is not empty in 
__node_shrink() for node 0

I am not a mm/slab.c expert but the following patch cures the problem 
for me :

[PATCH] slab : NUMA may need __cache_shrink() doing two loops.

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>





[-- Attachment #2: __cache_shrink.patch --]
[-- Type: text/plain, Size: 1096 bytes --]

--- linux-2.6.17-rc4/mm/slab.c	2006-05-15 14:58:09.000000000 +0200
+++ linux-2.6.17-rc4-ed/mm/slab.c	2006-05-15 15:23:07.000000000 +0200
@@ -2225,25 +2225,32 @@
 		spin_lock_irq(&l3->list_lock);
 	}
 	ret = !list_empty(&l3->slabs_full) || !list_empty(&l3->slabs_partial);
+	if (ret)
+		printk(KERN_ERR "__node_shrink(name=%s,node=%d) ret=%d\n",
+			cachep->name, node, ret);
 	return ret;
 }
 
 static int __cache_shrink(struct kmem_cache *cachep)
 {
-	int ret = 0, i = 0;
+	int ret, i;
 	struct kmem_list3 *l3;
+	int loopcount = 0;
 
-	drain_cpu_caches(cachep);
+	do {
+		ret = 0;
+		drain_cpu_caches(cachep);
 
-	check_irq_on();
-	for_each_online_node(i) {
-		l3 = cachep->nodelists[i];
-		if (l3) {
-			spin_lock_irq(&l3->list_lock);
-			ret += __node_shrink(cachep, i);
-			spin_unlock_irq(&l3->list_lock);
+		check_irq_on();
+		for_each_online_node(i) {
+			l3 = cachep->nodelists[i];
+			if (l3) {
+				spin_lock_irq(&l3->list_lock);
+				ret += __node_shrink(cachep, i);
+				spin_unlock_irq(&l3->list_lock);
+			}
 		}
-	}
+	} while (ret && ++loopcount < 2);
 	return (ret ? 1 : 0);
 }
 

[PATCH] x86 NUMA panic compile error

[Andy Whitcroft]

Is this check now needed given we have the zone alignment patches in
this -mm also?  I think we want to make it at least possible to
boot such a kernel on a 'flat' machine.

-apw

=== 8< ===
x86 NUMA panic compile error

Seem we have a syntax error rising from the the new panic added
to let people know NUMA didn't work on physically non-numa hardware.

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
 srat.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)
diff -upN reference/arch/i386/kernel/srat.c current/arch/i386/kernel/srat.c
--- reference/arch/i386/kernel/srat.c
+++ current/arch/i386/kernel/srat.c
@@ -269,7 +269,7 @@ int __init get_memcfg_from_srat(void)
 	extern int use_cyclone;
 	if (use_cyclone == 0) {
 		/* Make sure user sees something */
-		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
+		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else.";
 		early_printk(s);
 		panic(s);
 	}

Re: 2.6.17-rc4-mm1

[Michal Piotrowski]

Hi,

On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
>
> - This tree contains a large number of new bugs^H^H^H^Hpatches.
[snip]
>  git-alsa.patch

BUG: sleeping function called from invalid context at
/usr/src/linux-mm/sound/core/info.c:117
in_atomic():1, irqs_disabled():0
 <c1003ef9> show_trace+0xd/0xf   <c100440c> dump_stack+0x17/0x19
  <c10178ce> __might_sleep+0x93/0x9d   <f988eeb5> snd_iprintf+0x1b/0x84 [snd]
  <f988d808> snd_card_module_info_read+0x34/0x4e [snd]   <f988f197>
snd_info_entry_open+0x20f/0x2cc [snd]
 <c1067a17> __dentry_open+0x133/0x260   <c1067bb7> nameidata_to_filp+0x1c/0x2e
 <c1067bf7> do_filp_open+0x2e/0x35   <c1068bf2> do_sys_open+0x54/0xd7
 <c1068ca1> sys_open+0x16/0x18   <c11dab67> sysenter_past_esp+0x54/0x75
Non-volatile memory driver v1.2

Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg
Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc4-mm1

[Alexey Dobriyan]

>   - Added the ecryptfs filesystem

  CC [M]  fs/ecryptfs/super.o
fs/ecryptfs/super.c: In function `ecryptfs_statfs':
fs/ecryptfs/super.c:129: warning: passing arg 1 of `vfs_statfs' from incompatible pointer type
fs/ecryptfs/super.c: At top level:
fs/ecryptfs/super.c:207: warning: initialization from incompatible pointer type

* ->statfs wants vfsmount as first argument
* ecryptfs_statfs() is inlined

Re: 2.6.17-rc4-mm1

[Andrew Morton]

Alexey Dobriyan <adobriyan@gmail.com> wrote:
>
> >   - Added the ecryptfs filesystem
> 
>   CC [M]  fs/ecryptfs/super.o
> fs/ecryptfs/super.c: In function `ecryptfs_statfs':
> fs/ecryptfs/super.c:129: warning: passing arg 1 of `vfs_statfs' from incompatible pointer type
> fs/ecryptfs/super.c: At top level:
> fs/ecryptfs/super.c:207: warning: initialization from incompatible pointer type

hm, I wonder why I didn't notice that.

> * ->statfs wants vfsmount as first argument
> * ecryptfs_statfs() is inlined

yup.  Fixed a bunch of those, let one slip through.

I don't immediately see how to fix this one, actually:

static inline int ecryptfs_statfs(struct super_block *sb, struct kstatfs *buf)
{
	return vfs_statfs(ecryptfs_superblock_to_lower(sb), buf);
}

Once we've run ecryptfs_superblock_to_lower() to get the "lower
superblock", we need to turn that back into a vfsmount for vfs_statfs()..

(and that function needn't have been inlined - it's only ever called
indirectly)

I think I'll be dropping the fs-cache patches (again) fairly soon.  They're
intrusive, quite some effort to carry, they're not getting adequate review
(afaict) and there doesn't seem to be a lot of demand for them, sorry.

Re: 2.6.17-rc4-mm1

[Andrew Morton]

"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> Hi,
> 
> On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> >
> > - This tree contains a large number of new bugs^H^H^H^Hpatches.
> [snip]
> >  git-alsa.patch
> 
> BUG: sleeping function called from invalid context at
> /usr/src/linux-mm/sound/core/info.c:117
> in_atomic():1, irqs_disabled():0
>  <c1003ef9> show_trace+0xd/0xf   <c100440c> dump_stack+0x17/0x19
>   <c10178ce> __might_sleep+0x93/0x9d   <f988eeb5> snd_iprintf+0x1b/0x84 [snd]
>   <f988d808> snd_card_module_info_read+0x34/0x4e [snd]   <f988f197>
> snd_info_entry_open+0x20f/0x2cc [snd]
>  <c1067a17> __dentry_open+0x133/0x260   <c1067bb7> nameidata_to_filp+0x1c/0x2e
>  <c1067bf7> do_filp_open+0x2e/0x35   <c1068bf2> do_sys_open+0x54/0xd7
>  <c1068ca1> sys_open+0x16/0x18   <c11dab67> sysenter_past_esp+0x54/0x75
> Non-volatile memory driver v1.2
> 
> Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg
> Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config

heh, yes, Takashi baited his hook and pulled in a big one.

snd_card_module_info_read() calls snd_iprintf() under read_lock()..

Re: 2.6.17-rc4-mm1

[Takashi Iwai]

At Mon, 15 May 2006 10:04:29 -0700,
Andrew Morton wrote:
> 
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >
> > Hi,
> > 
> > On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> > >
> > > - This tree contains a large number of new bugs^H^H^H^Hpatches.
> > [snip]
> > >  git-alsa.patch
> > 
> > BUG: sleeping function called from invalid context at
> > /usr/src/linux-mm/sound/core/info.c:117
> > in_atomic():1, irqs_disabled():0
> >  <c1003ef9> show_trace+0xd/0xf   <c100440c> dump_stack+0x17/0x19
> >   <c10178ce> __might_sleep+0x93/0x9d   <f988eeb5> snd_iprintf+0x1b/0x84 [snd]
> >   <f988d808> snd_card_module_info_read+0x34/0x4e [snd]   <f988f197>
> > snd_info_entry_open+0x20f/0x2cc [snd]
> >  <c1067a17> __dentry_open+0x133/0x260   <c1067bb7> nameidata_to_filp+0x1c/0x2e
> >  <c1067bf7> do_filp_open+0x2e/0x35   <c1068bf2> do_sys_open+0x54/0xd7
> >  <c1068ca1> sys_open+0x16/0x18   <c11dab67> sysenter_past_esp+0x54/0x75
> > Non-volatile memory driver v1.2
> > 
> > Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg
> > Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config
> 
> heh, yes, Takashi baited his hook and pulled in a big one.
> 
> snd_card_module_info_read() calls snd_iprintf() under read_lock()..

Ouch, I checked only spinlocks but forgot rwlocks.  Will fix them.


Thanks.

Takashi

Re: 2.6.17-rc4-mm1

[Michal Piotrowski]

Hi,

On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
>
> - This tree contains a large number of new bugs^H^H^H^Hpatches.
>
[snip]
> +kbuild-export-symbol-usage-report-generator.patch

When I try make exportcheck with O=/dir I get this error
[michal@ltg01-fedora linux-mm]$ make O=../linux-mm-obj/ exportcheck
EXPORTFILE=../linux-mm-obj/export.dat
  Using /usr/src/linux-mm as source for kernel
[..]
Can't open perl script
"/usr/src/linux-mm-obj/scripts/export_report.pl": No such file or
directory
make[2]: *** [__modpost] Error 2
make[1]: *** [modules] Error 2
make: *** [exportcheck] Error 2

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andy Whitcroft <apw@shadowen.org> wrote:

>  	if (use_cyclone == 0) {
>  		/* Make sure user sees something */
> -		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
> +		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else.";
>  		early_printk(s);
>  		panic(s);
>  	}

i still strongly oppose the original Andi hack... numerous reasons were 
given not to apply it (it's nice to simulate/trigger rarer features on 
mainstream hardware too, and this ability to boot NUMA on my flat x86 
testbox found at least one other NUMA bug already). Furthermore, the 
crash i reported was fixed by the NUMA patchset. Andrew, please drop:

  x86_64-mm-i386-numa-summit-check.patch

(which has nothing to do with x86_64 anyway)

	Ingo

Re: 2.6.17-rc4-mm1

[Takashi Iwai]

At Mon, 15 May 2006 19:30:24 +0200,
I wrote:
> 
> At Mon, 15 May 2006 10:04:29 -0700,
> Andrew Morton wrote:
> > 
> > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > >
> > > Hi,
> > > 
> > > On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> > > >
> > > > - This tree contains a large number of new bugs^H^H^H^Hpatches.
> > > [snip]
> > > >  git-alsa.patch
> > > 
> > > BUG: sleeping function called from invalid context at
> > > /usr/src/linux-mm/sound/core/info.c:117
> > > in_atomic():1, irqs_disabled():0
> > >  <c1003ef9> show_trace+0xd/0xf   <c100440c> dump_stack+0x17/0x19
> > >   <c10178ce> __might_sleep+0x93/0x9d   <f988eeb5> snd_iprintf+0x1b/0x84 [snd]
> > >   <f988d808> snd_card_module_info_read+0x34/0x4e [snd]   <f988f197>
> > > snd_info_entry_open+0x20f/0x2cc [snd]
> > >  <c1067a17> __dentry_open+0x133/0x260   <c1067bb7> nameidata_to_filp+0x1c/0x2e
> > >  <c1067bf7> do_filp_open+0x2e/0x35   <c1068bf2> do_sys_open+0x54/0xd7
> > >  <c1068ca1> sys_open+0x16/0x18   <c11dab67> sysenter_past_esp+0x54/0x75
> > > Non-volatile memory driver v1.2
> > > 
> > > Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg
> > > Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config
> > 
> > heh, yes, Takashi baited his hook and pulled in a big one.
> > 
> > snd_card_module_info_read() calls snd_iprintf() under read_lock()..
> 
> Ouch, I checked only spinlocks but forgot rwlocks.  Will fix them.

The patch below should fix them (already merged in ALSA HG repo).


[ALSA] Fix rwlock around snd_iprintf() in sound core

Fixed rwlock around snd_iprintf() in sound core part.
Replaced with mutex.

Also, make mutex and flags static variables with addition of
snd_card_locked() function (just for sound.c).

Signed-off-by: Takashi Iwai <tiwai@suse.de>

---
commit f4e4b6a7b3b404edb1acd72ae3cb26e6246b04bb
tree 6e529ed077718299bf7dff400cedc62767d7bdbe
parent 3a5be5e3bc2d702b9f8428465729895b691c9059
author Takashi Iwai <tiwai@suse.de> Mon, 15 May 2006 00:00:00 +0200
committer Takashi Iwai <tiwai@suse.de> Mon, 15 May 2006 19:51:18 +0200

 include/sound/core.h |    3 +--
 sound/core/init.c    |   51 ++++++++++++++++++++++++++++++--------------------
 sound/core/sound.c   |    7 +------
 3 files changed, 33 insertions(+), 28 deletions(-)

diff --git a/include/sound/core.h b/include/sound/core.h
index 5135147..5d184be 100644
--- a/include/sound/core.h
+++ b/include/sound/core.h
@@ -233,9 +233,8 @@ int copy_from_user_toio(volatile void __
 
 /* init.c */
 
-extern unsigned int snd_cards_lock;
 extern struct snd_card *snd_cards[SNDRV_CARDS];
-extern rwlock_t snd_card_rwlock;
+int snd_card_locked(int card);
 #if defined(CONFIG_SND_MIXER_OSS) || defined(CONFIG_SND_MIXER_OSS_MODULE)
 #define SND_MIXER_OSS_NOTIFY_REGISTER	0
 #define SND_MIXER_OSS_NOTIFY_DISCONNECT	1
diff --git a/sound/core/init.c b/sound/core/init.c
index 2ff0e5e..38b2d4a 100644
--- a/sound/core/init.c
+++ b/sound/core/init.c
@@ -38,11 +38,11 @@ struct snd_shutdown_f_ops {
 	struct snd_shutdown_f_ops *next;
 };
 
-unsigned int snd_cards_lock = 0;	/* locked for registering/using */
+static unsigned int snd_cards_lock = 0;	/* locked for registering/using */
 struct snd_card *snd_cards[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = NULL};
 EXPORT_SYMBOL(snd_cards);
 
-DEFINE_RWLOCK(snd_card_rwlock);
+static DEFINE_MUTEX(snd_card_mutex);
 
 #if defined(CONFIG_SND_MIXER_OSS) || defined(CONFIG_SND_MIXER_OSS_MODULE)
 int (*snd_mixer_oss_notify_callback)(struct snd_card *card, int free_flag);
@@ -112,7 +112,7 @@ struct snd_card *snd_card_new(int idx, c
 		strlcpy(card->id, xid, sizeof(card->id));
 	}
 	err = 0;
-	write_lock(&snd_card_rwlock);
+	mutex_lock(&snd_card_mutex);
 	if (idx < 0) {
 		int idx2;
 		for (idx2 = 0; idx2 < SNDRV_CARDS; idx2++)
@@ -130,12 +130,12 @@ struct snd_card *snd_card_new(int idx, c
 	else
 		err = -ENODEV;
 	if (idx < 0 || err < 0) {
-		write_unlock(&snd_card_rwlock);
+		mutex_unlock(&snd_card_mutex);
 		snd_printk(KERN_ERR "cannot find the slot for index %d (range 0-%i)\n", idx, snd_ecards_limit - 1);
 		goto __error;
 	}
 	snd_cards_lock |= 1 << idx;		/* lock it */
-	write_unlock(&snd_card_rwlock);
+	mutex_unlock(&snd_card_mutex);
 	card->number = idx;
 	card->module = module;
 	INIT_LIST_HEAD(&card->devices);
@@ -173,6 +173,17 @@ struct snd_card *snd_card_new(int idx, c
 
 EXPORT_SYMBOL(snd_card_new);
 
+/* return non-zero if a card is already locked */
+int snd_card_locked(int card)
+{
+	int locked;
+
+	mutex_lock(&snd_card_mutex);
+	locked = snd_cards_lock & (1 << card);
+	mutex_unlock(&snd_card_mutex);
+	return locked;
+}
+
 static loff_t snd_disconnect_llseek(struct file *file, loff_t offset, int orig)
 {
 	return -ENODEV;
@@ -240,9 +251,9 @@ int snd_card_disconnect(struct snd_card 
 	spin_unlock(&card->files_lock);
 
 	/* phase 1: disable fops (user space) operations for ALSA API */
-	write_lock(&snd_card_rwlock);
+	mutex_lock(&snd_card_mutex);
 	snd_cards[card->number] = NULL;
-	write_unlock(&snd_card_rwlock);
+	mutex_unlock(&snd_card_mutex);
 	
 	/* phase 2: replace file->f_op with special dummy operations */
 	
@@ -321,9 +332,9 @@ int snd_card_free(struct snd_card *card)
 
 	if (card == NULL)
 		return -EINVAL;
-	write_lock(&snd_card_rwlock);
+	mutex_lock(&snd_card_mutex);
 	snd_cards[card->number] = NULL;
-	write_unlock(&snd_card_rwlock);
+	mutex_unlock(&snd_card_mutex);
 
 #ifdef CONFIG_PM
 	wake_up(&card->power_sleep);
@@ -359,9 +370,9 @@ int snd_card_free(struct snd_card *card)
 		card->s_f_ops = s_f_ops->next;
 		kfree(s_f_ops);
 	}
-	write_lock(&snd_card_rwlock);
+	mutex_lock(&snd_card_mutex);
 	snd_cards_lock &= ~(1 << card->number);
-	write_unlock(&snd_card_rwlock);
+	mutex_unlock(&snd_card_mutex);
 	kfree(card);
 	return 0;
 }
@@ -497,16 +508,16 @@ int snd_card_register(struct snd_card *c
 	snd_assert(card != NULL, return -EINVAL);
 	if ((err = snd_device_register_all(card)) < 0)
 		return err;
-	write_lock(&snd_card_rwlock);
+	mutex_lock(&snd_card_mutex);
 	if (snd_cards[card->number]) {
 		/* already registered */
-		write_unlock(&snd_card_rwlock);
+		mutex_unlock(&snd_card_mutex);
 		return 0;
 	}
 	if (card->id[0] == '\0')
 		choose_default_id(card);
 	snd_cards[card->number] = card;
-	write_unlock(&snd_card_rwlock);
+	mutex_unlock(&snd_card_mutex);
 	init_info_for_card(card);
 #if defined(CONFIG_SND_MIXER_OSS) || defined(CONFIG_SND_MIXER_OSS_MODULE)
 	if (snd_mixer_oss_notify_callback)
@@ -527,7 +538,7 @@ static void snd_card_info_read(struct sn
 	struct snd_card *card;
 
 	for (idx = count = 0; idx < SNDRV_CARDS; idx++) {
-		read_lock(&snd_card_rwlock);
+		mutex_lock(&snd_card_mutex);
 		if ((card = snd_cards[idx]) != NULL) {
 			count++;
 			snd_iprintf(buffer, "%2i [%-15s]: %s - %s\n",
@@ -538,7 +549,7 @@ static void snd_card_info_read(struct sn
 			snd_iprintf(buffer, "                      %s\n",
 					card->longname);
 		}
-		read_unlock(&snd_card_rwlock);
+		mutex_unlock(&snd_card_mutex);
 	}
 	if (!count)
 		snd_iprintf(buffer, "--- no soundcards ---\n");
@@ -552,12 +563,12 @@ void snd_card_info_read_oss(struct snd_i
 	struct snd_card *card;
 
 	for (idx = count = 0; idx < SNDRV_CARDS; idx++) {
-		read_lock(&snd_card_rwlock);
+		mutex_lock(&snd_card_mutex);
 		if ((card = snd_cards[idx]) != NULL) {
 			count++;
 			snd_iprintf(buffer, "%s\n", card->longname);
 		}
-		read_unlock(&snd_card_rwlock);
+		mutex_unlock(&snd_card_mutex);
 	}
 	if (!count) {
 		snd_iprintf(buffer, "--- no soundcards ---\n");
@@ -575,11 +586,11 @@ static void snd_card_module_info_read(st
 	struct snd_card *card;
 
 	for (idx = 0; idx < SNDRV_CARDS; idx++) {
-		read_lock(&snd_card_rwlock);
+		mutex_lock(&snd_card_mutex);
 		if ((card = snd_cards[idx]) != NULL)
 			snd_iprintf(buffer, "%2i %s\n",
 				    idx, card->module->name);
-		read_unlock(&snd_card_rwlock);
+		mutex_unlock(&snd_card_mutex);
 	}
 }
 #endif
diff --git a/sound/core/sound.c b/sound/core/sound.c
index 8313f97..02c8cc4 100644
--- a/sound/core/sound.c
+++ b/sound/core/sound.c
@@ -81,14 +81,9 @@ extern struct class *sound_class;
  */
 void snd_request_card(int card)
 {
-	int locked;
-
 	if (! current->fs->root)
 		return;
-	read_lock(&snd_card_rwlock);
-	locked = snd_cards_lock & (1 << card);
-	read_unlock(&snd_card_rwlock);
-	if (locked)
+	if (snd_card_locked(card))
 		return;
 	if (card < 0 || card >= cards_limit)
 		return;

Re: 2.6.17-rc4-mm1

[Andrew Morton]

"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> Hi,
> 
> On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> >
> > - This tree contains a large number of new bugs^H^H^H^Hpatches.
> >
> [snip]
> > +kbuild-export-symbol-usage-report-generator.patch
> 
> When I try make exportcheck with O=/dir I get this error
> [michal@ltg01-fedora linux-mm]$ make O=../linux-mm-obj/ exportcheck
> EXPORTFILE=../linux-mm-obj/export.dat
>   Using /usr/src/linux-mm as source for kernel
> [..]
> Can't open perl script
> "/usr/src/linux-mm-obj/scripts/export_report.pl": No such file or
> directory
> make[2]: *** [__modpost] Error 2
> make[1]: *** [modules] Error 2
> make: *** [exportcheck] Error 2
> 
> Regards,
> Michal
> 

cc added.

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

On Monday 15 May 2006 19:53, Ingo Molnar wrote:
> 
> * Andy Whitcroft <apw@shadowen.org> wrote:
> 
> >  	if (use_cyclone == 0) {
> >  		/* Make sure user sees something */
> > -		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
> > +		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else.";
> >  		early_printk(s);
> >  		panic(s);
> >  	}
> 
> i still strongly oppose the original Andi hack... numerous reasons were 
> given not to apply it (it's nice to simulate/trigger rarer features on 
> mainstream hardware too, and this ability to boot NUMA on my flat x86 
> testbox found at least one other NUMA bug already). Furthermore, the 
> crash i reported was fixed by the NUMA patchset. Andrew, please drop:

The problem is that it's not regularly used on a wide range
of boxes so it will eventually break again. We had this cycle several
times already.

It's also missing a lot of the workarounds for broken SRATs that
are needed for many of the existing NUMA systems.

If there's consensus i386 NUMA is useful I can drop it, but I predict
it will just eventually break again.

>   x86_64-mm-i386-numa-summit-check.patch
> 
> (which has nothing to do with x86_64 anyway)

I have a lot of i386 or combined i386/x86-64 patches in my tree - just Andrew's 
merge script doesn't pick that up.

-Andi

Re: 2.6.17-rc4-mm1

[Alexey Dobriyan]

On Mon, May 15, 2006 at 10:01:44AM -0700, Andrew Morton wrote:
> Alexey Dobriyan <adobriyan@gmail.com> wrote:
> >
> > >   - Added the ecryptfs filesystem
> > 
> >   CC [M]  fs/ecryptfs/super.o
> > fs/ecryptfs/super.c: In function `ecryptfs_statfs':
> > fs/ecryptfs/super.c:129: warning: passing arg 1 of `vfs_statfs' from incompatible pointer type
> > fs/ecryptfs/super.c: At top level:
> > fs/ecryptfs/super.c:207: warning: initialization from incompatible pointer type
> 
> hm, I wonder why I didn't notice that.
> 
> > * ->statfs wants vfsmount as first argument
> > * ecryptfs_statfs() is inlined
> 
> yup.  Fixed a bunch of those, let one slip through.
> 
> I don't immediately see how to fix this one, actually:
> 
> static inline int ecryptfs_statfs(struct super_block *sb, struct kstatfs *buf)
> {
> 	return vfs_statfs(ecryptfs_superblock_to_lower(sb), buf);
> }
> 
> Once we've run ecryptfs_superblock_to_lower() to get the "lower
> superblock", we need to turn that back into a vfsmount for vfs_statfs()..
> 
> (and that function needn't have been inlined - it's only ever called
> indirectly)
> 
> I think I'll be dropping the fs-cache patches (again) fairly soon.  They're
> intrusive, quite some effort to carry, they're not getting adequate review
> (afaict) and there doesn't seem to be a lot of demand for them, sorry.

Silly me. GFS2 is guilty too

fs/gfs2/ops_super.c:371: warning: initialization from incompatible pointer type

	static int gfs2_statfs(struct super_block *sb, struct kstatfs *buf)

Re: 2.6.17-rc4-mm1

[Jesper Juhl]

On Monday 15 May 2006 09:56, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> 
Hi Andrew,

While going through my patches currently in -mm I noticed a problem.
I have to hang my head i shame and admit to introducing a bug in what should 
have been a bugFIX patch :-(

In the 
isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub.patch 
patch, which is currently in -mm there's a bug.

This bit :
 -       copy_from_user(skb_put(skb, len), buf, len);
 +       if (!copy_from_user(skb_put(skb, len), buf, len))
should really be :
 -       copy_from_user(skb_put(skb, len), buf, len);
 +       if (copy_from_user(skb_put(skb, len), buf, len))
Somehow a stray "!" crept in there.

Sorry about that. Here's a tiny fix-it-up patch to be applied on top : 


Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>

--- linux-2.6.17-rc4-mm1-orig/drivers/isdn/i4l/isdn_common.c	2006-05-15 19:43:06.000000000 +0200
+++ linux-2.6.17-rc4-mm1/drivers/isdn/i4l/isdn_common.c	2006-05-15 19:58:26.000000000 +0200
@@ -1952,7 +1952,7 @@ isdn_writebuf_stub(int drvidx, int chan,
 	if (!skb)
 		return -ENOMEM;
 	skb_reserve(skb, hl);
-	if (!copy_from_user(skb_put(skb, len), buf, len))
+	if (copy_from_user(skb_put(skb, len), buf, len))
 		return -EFAULT;
 	ret = dev->drv[drvidx]->interface->writebuf_skb(drvidx, chan, 1, skb);
 	if (ret <= 0)

Re: [PATCH] x86 NUMA panic compile error

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Andy Whitcroft <apw@shadowen.org> wrote:
> 
> >  	if (use_cyclone == 0) {
> >  		/* Make sure user sees something */
> > -		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
> > +		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else.";
> >  		early_printk(s);
> >  		panic(s);
> >  	}
> 
> i still strongly oppose the original Andi hack... numerous reasons were 
> given not to apply it (it's nice to simulate/trigger rarer features on 
> mainstream hardware too, and this ability to boot NUMA on my flat x86 
> testbox found at least one other NUMA bug already). Furthermore, the 
> crash i reported was fixed by the NUMA patchset.

I'll be darned.  I never knew it was even possible to run x86 numa kernels
on non-numa boxen.  I'd have tested about 1000000 of Christoph Lameter's
patches if someone had told me.  Yes, it's useful.

> Andrew, please drop:
> 
>   x86_64-mm-i386-numa-summit-check.patch

bang.

> (which has nothing to do with x86_64 anyway)

True.

I guess the concern here is that we don't want people building these
frankenkernels and then sending us bug reports against them.

So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? 
(It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS
or something).

Re: [PATCH] x86 NUMA panic compile error

[Andy Whitcroft]

Andrew Morton wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> 
>>
>>* Andy Whitcroft <apw@shadowen.org> wrote:
>>
>>
>>> 	if (use_cyclone == 0) {
>>> 		/* Make sure user sees something */
>>>-		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
>>>+		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else.";
>>> 		early_printk(s);
>>> 		panic(s);
>>> 	}
>>
>>i still strongly oppose the original Andi hack... numerous reasons were 
>>given not to apply it (it's nice to simulate/trigger rarer features on 
>>mainstream hardware too, and this ability to boot NUMA on my flat x86 
>>testbox found at least one other NUMA bug already). Furthermore, the 
>>crash i reported was fixed by the NUMA patchset.
> 
> 
> I'll be darned.  I never knew it was even possible to run x86 numa kernels
> on non-numa boxen.  I'd have tested about 1000000 of Christoph Lameter's
> patches if someone had told me.  Yes, it's useful.
>

We always assumed it might be reasonable for a distro to want a single
installer kernel for all machines.  So having a combined numa not numa
capable kernel always seemed like a good idea.

>>Andrew, please drop:
>>
>>  x86_64-mm-i386-numa-summit-check.patch
> 
> 
> bang.
> 
> 
>>(which has nothing to do with x86_64 anyway)
> 
> 
> True.
> 
> I guess the concern here is that we don't want people building these
> frankenkernels and then sending us bug reports against them.
> 
> So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? 
> (It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS
> or something).

How about CONFIG_EXPERIMENTAL?

-apw

Re: 2.6.17-rc4-mm1

[Andrew Morton]

Takashi Iwai <tiwai@suse.de> wrote:
>
> -unsigned int snd_cards_lock = 0;	/* locked for registering/using */
> +static unsigned int snd_cards_lock = 0;	/* locked for registering/using */

May as well remove the `= 0' while you're there.  It adds four bytes to the
module unnecessarily.

>  void snd_request_card(int card)
>  {
> -	int locked;
> -
>  	if (! current->fs->root)
>  		return;

I wonder what that's there for.

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

On Monday 15 May 2006 20:08, Andrew Morton wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> >
> > 
> > * Andy Whitcroft <apw@shadowen.org> wrote:
> > 
> > >  	if (use_cyclone == 0) {
> > >  		/* Make sure user sees something */
> > > -		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
> > > +		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else.";
> > >  		early_printk(s);
> > >  		panic(s);
> > >  	}
> > 
> > i still strongly oppose the original Andi hack... numerous reasons were 
> > given not to apply it (it's nice to simulate/trigger rarer features on 
> > mainstream hardware too, and this ability to boot NUMA on my flat x86 
> > testbox found at least one other NUMA bug already). Furthermore, the 
> > crash i reported was fixed by the NUMA patchset.
> 
> I'll be darned.  I never knew it was even possible to run x86 numa kernels
> on non-numa boxen.  I'd have tested about 1000000 of Christoph Lameter's
> patches if someone had told me.  Yes, it's useful.

If you want to use it for that I would suggest to port the numa emulation
code at least - two or four nodes tends to find more problems than a single
node.

But testing on a 64bit box - even with numa emulation - would be much
better because on 32bit ZONE_NORMAL often is node 0 only and you won't 
get much numaness for kernel objects.
 
> 
> > Andrew, please drop:
> > 
> >   x86_64-mm-i386-numa-summit-check.patch
> 
> bang.

Ok.

> 
> > (which has nothing to do with x86_64 anyway)
> 
> True.
> 
> I guess the concern here is that we don't want people building these
> frankenkernels and then sending us bug reports against them.

Well it will still increase the bug numbers you care so much about.

Another reason I don't like it is that it's ugly and reimplements
parts of ACPI on its own for no reason.

If people use it regularly for debugging maybe it won't bit rot
as quickly as it used to be, but there is a big difference between
theory and practice so we'll see.

 
> So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? 
> (It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS
> or something).

Fine.

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> > i still strongly oppose the original Andi hack... numerous reasons were 
> > given not to apply it (it's nice to simulate/trigger rarer features on 
> > mainstream hardware too, and this ability to boot NUMA on my flat x86 
> > testbox found at least one other NUMA bug already). Furthermore, the 
> > crash i reported was fixed by the NUMA patchset. Andrew, please drop:
> 
> The problem is that it's not regularly used on a wide range of boxes 
> so it will eventually break again. We had this cycle several times 
> already.

so it will find new bugs. Since you wrote that patch the ability to try 
numa on 'flat' x86 hardware has found two bugs, one of which (the zone 
alignment thing) could very well affect non-obsolete hardware too.

Andi, triggering bugs as widely as possible is the _whole point_ of QA 
and diversity of testing! Do you disable the compilation of the floppy 
driver just because it's obsolete hardware? Will you remove NUMA 
emulation from x86_64 just because it regularly broke in the past?

Fact is, the more hardware a given feature can be tried on, the better 
tested that feature becomes. I find it quite extreme that this point has 
to even be argued...

	Ingo

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

On Monday 15 May 2006 20:24, Andrew Morton wrote:
> Andy Whitcroft <apw@shadowen.org> wrote:
> >
> > > So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? 
> > > (It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS
> > > or something).
> > 
> > How about CONFIG_EXPERIMENTAL?
> 
> Probably CONFIG_ADVANCED would be closer.

Most people who recompile kernels probably think of themselves as advanced.
This doesn't mean they will get these things right.

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Andrew Morton]

Andy Whitcroft <apw@shadowen.org> wrote:
>
> > So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? 
> > (It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS
> > or something).
> 
> How about CONFIG_EXPERIMENTAL?

Probably CONFIG_ADVANCED would be closer.

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > (which has nothing to do with x86_64 anyway)
> 
> True.
> 
> I guess the concern here is that we don't want people building these 
> frankenkernels and then sending us bug reports against them.

sure - lets simply turn it into a printk, as per the patch below.

it's not like we are being swamped with these bugreports, it seems i was 
the only one who tried. So lets not over-react it. (and the panic was 
the worst possible thing we could do.)

	Ingo

---

warn users that running CONFIG_NUMA on non-x440 boxes is barely tested.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

 arch/i386/kernel/srat.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

Index: linux/arch/i386/kernel/srat.c
===================================================================
--- linux.orig/arch/i386/kernel/srat.c
+++ linux/arch/i386/kernel/srat.c
@@ -267,12 +267,9 @@ int __init get_memcfg_from_srat(void)
 	int i = 0;
 
 	extern int use_cyclone;
-	if (use_cyclone == 0) {
-		/* Make sure user sees something */
-		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
-		early_printk(s);
-		panic(s);
-	}
+	/* Make sure user sees something */
+	if (use_cyclone == 0)
+		printk(KERN_WARN "WARNING: Not an IBM x440/NUMAQ and CONFIG_NUMA enabled!\n");
 
 	if (ACPI_FAILURE(acpi_find_root_pointer(ACPI_PHYSICAL_ADDRESSING,
 						rsdp_address))) {

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> > > (which has nothing to do with x86_64 anyway)
> > 
> > True.
> > 
> > I guess the concern here is that we don't want people building these
> > frankenkernels and then sending us bug reports against them.
> 
> Well it will still increase the bug numbers you care so much about.

so lets ... hide them? ahem? Unaligned NUMA zones were a bug waiting to 
hit us on some other platform.

	Ingo

Re: [PATCH] x86 NUMA panic compile error

[Andrew Morton]

Andi Kleen <ak@suse.de> wrote:
>
> > 
> > I'll be darned.  I never knew it was even possible to run x86 numa kernels
> > on non-numa boxen.  I'd have tested about 1000000 of Christoph Lameter's
> > patches if someone had told me.  Yes, it's useful.
> 
> If you want to use it for that I would suggest to port the numa emulation
> code at least - two or four nodes tends to find more problems than a single
> node.
> 
> But testing on a 64bit box - even with numa emulation - would be much
> better because on 32bit ZONE_NORMAL often is node 0 only and you won't 
> get much numaness for kernel objects.

That's an excellent point - most developers who are likely to want to test
NUMA have x86_64 boxes and x86_64 has NUMA-emulation-on-SMP.  I'd
semi-forgotten that it existed.

This rather weakens the reasons for retaining support for
NUMA-on-non-summit-x86.  Ingo?

> > I guess the concern here is that we don't want people building these
> > frankenkernels and then sending us bug reports against them.
> 
> Well it will still increase the bug numbers you care so much about.

Not really.  If a bug affects something we don't care about (like this)
I'll just ignore it.  I care about the number of busted machines out there,
not the bug counts...

> Another reason I don't like it is that it's ugly and reimplements
> parts of ACPI on its own for no reason.

So shouldn't such a patch remove that code rather than panicing?

Re: 2.6.17-rc4-mm1

[Michal Piotrowski]

Hi,

On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
>

When I try to "modprobe -r i2c_i801" modprobe hangs

[michal@ltg01-fedora ~]$ ps aux | grep mod
root      5943  0.0  0.0   1648   432 tty1     D+   20:15   0:00
modprobe -r i2c_i801
michal   15499  0.0  0.0   1836   496 pts/4    S+   20:33   0:00 grep mod

Here is strace log
http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/strace.txt
Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config

2.6.17-rc3-mm1 was fine. I don't see nothing abnormal in dmesg.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

> 
> > Another reason I don't like it is that it's ugly and reimplements
> > parts of ACPI on its own for no reason.
> 
> So shouldn't such a patch remove that code rather than panicing?

I would be for remove, but apparently we have one or two users in
IBM that run their x440s (32bit only) with CONFIG_NUMA. No distributions
do so though and I would expect x440s to usually run distributions
because they are quite expensive machines.

My arguments for remove:
- The code is very hackish - it was written before the proper ACPI
infrastructure is in place - and NUMA on 32bit in general needs a lot
of hacks because of the limited ZONE_NORMAL.
- NUMA on 32bit is kind of broken by design.
- It isn't used much.
- It breaks often
- It tends to not work on Opterons and hits the users who try it there.

Short of remove I would settle on the panic on non Summit.

Also if you only wanted NUMA emulation for testing it could be also
done much much simpler removing near all of i386/*/srat.c. But with
the inherent 32bit NUMA limitations I have my doubts on its great
usefulness.

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> > But testing on a 64bit box - even with numa emulation - would be much
> > better because on 32bit ZONE_NORMAL often is node 0 only and you won't 
> > get much numaness for kernel objects.
> 
> That's an excellent point - most developers who are likely to want to 
> test NUMA have x86_64 boxes and x86_64 has NUMA-emulation-on-SMP.  I'd 
> semi-forgotten that it existed.
> 
> This rather weakens the reasons for retaining support for 
> NUMA-on-non-summit-x86.  Ingo?

my 64-bit boxes (half of the testbed) are busy ones used for daily 
testing that i just cannot keep running for days doing stress-tests. 
Neither can they wait 10 minutes to boot up an allyesconfig kernel. So 
at least as long as my testconfig is concerned, 32-bit boxes and i386 
NUMA still has some place.

(and i'm not at all arguing it's a big thing - it's a minor thing. But i 
absolutely resist Andi's approach on conceptual grounds. It's backwards, 
for the reasons i outlined before. Had Andi's patch been in place the 
zone alignment bug had probably not been found - simple as that. 
Reducing choice artificially is the kind of thing that decreases the 
kernel's quality. Improving the quality of the kernel starts with making 
sure everyone understands how to achieve it - and Andi is one of the 
largest and most important contributors so i'd really like to make sure 
he understands my point :-)

	Ingo

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> > So shouldn't such a patch remove that code rather than panicing?
> 
> I would be for remove, but apparently we have one or two users in IBM 
> that run their x440s (32bit only) with CONFIG_NUMA. No distributions 
> do so though and I would expect x440s to usually run distributions 
> because they are quite expensive machines.
> 
> My arguments for remove:
> - The code is very hackish - it was written before the proper ACPI
> infrastructure is in place - and NUMA on 32bit in general needs a lot
> of hacks because of the limited ZONE_NORMAL.

works fine here now. The whole NUMA code is still quite hackish in 
general, (including most of arch/x86_64/*/*.c), so i'd not judge based 
on that.

> - NUMA on 32bit is kind of broken by design.

well. 32bit itself is broken by design, if you consider RAM larger than 
say 1GB.

> - It isn't used much.

it's an enabler of a feature-set that i couldnt test on these boxes 
otherwise. Look at it like the highmem= boot option. Or consider it a 
primitive form of NUMA emulation.

> - It breaks often

Martin says he's daily testing it in his grid.

> - It tends to not work on Opterons and hits the users who try it 
> there.

maybe due to the zone alignment problem?

	Ingo

Re: 2.6.17-rc4-mm1

[Michal Piotrowski]

Hi,

On 15/05/06, Takashi Iwai <tiwai@suse.de> wrote:
> At Mon, 15 May 2006 19:30:24 +0200,
> I wrote:
> >
> > At Mon, 15 May 2006 10:04:29 -0700,
> > Andrew Morton wrote:
> > >
> > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> > > > >
> > > > > - This tree contains a large number of new bugs^H^H^H^Hpatches.
> > > > [snip]
> > > > >  git-alsa.patch
> > > >
> > > > BUG: sleeping function called from invalid context at
> > > > /usr/src/linux-mm/sound/core/info.c:117
> > > > in_atomic():1, irqs_disabled():0
> > > >  <c1003ef9> show_trace+0xd/0xf   <c100440c> dump_stack+0x17/0x19
> > > >   <c10178ce> __might_sleep+0x93/0x9d   <f988eeb5> snd_iprintf+0x1b/0x84 [snd]
> > > >   <f988d808> snd_card_module_info_read+0x34/0x4e [snd]   <f988f197>
> > > > snd_info_entry_open+0x20f/0x2cc [snd]
> > > >  <c1067a17> __dentry_open+0x133/0x260   <c1067bb7> nameidata_to_filp+0x1c/0x2e
> > > >  <c1067bf7> do_filp_open+0x2e/0x35   <c1068bf2> do_sys_open+0x54/0xd7
> > > >  <c1068ca1> sys_open+0x16/0x18   <c11dab67> sysenter_past_esp+0x54/0x75
> > > > Non-volatile memory driver v1.2
> > > >
> > > > Here is dmesg http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg
> > > > Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config
> > >
> > > heh, yes, Takashi baited his hook and pulled in a big one.
> > >
> > > snd_card_module_info_read() calls snd_iprintf() under read_lock()..
> >
> > Ouch, I checked only spinlocks but forgot rwlocks.  Will fix them.
>
> The patch below should fix them (already merged in ALSA HG repo).
>
>

Problem fixed. Thanks!

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: [PATCH] x86 NUMA panic compile error

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Andrew Morton <akpm@osdl.org> wrote:
> 
> > > (which has nothing to do with x86_64 anyway)
> > 
> > True.
> > 
> > I guess the concern here is that we don't want people building these 
> > frankenkernels and then sending us bug reports against them.
> 
> sure - lets simply turn it into a printk, as per the patch below.
> 
> it's not like we are being swamped with these bugreports, it seems i was 
> the only one who tried. So lets not over-react it. (and the panic was 
> the worst possible thing we could do.)
> 
> 	Ingo
> 
> ---
> 
> warn users that running CONFIG_NUMA on non-x440 boxes is barely tested.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
>  arch/i386/kernel/srat.c |    9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> Index: linux/arch/i386/kernel/srat.c
> ===================================================================
> --- linux.orig/arch/i386/kernel/srat.c
> +++ linux/arch/i386/kernel/srat.c
> @@ -267,12 +267,9 @@ int __init get_memcfg_from_srat(void)
>  	int i = 0;
>  
>  	extern int use_cyclone;

argh.

If we didn't do this lazy-ass put-the-declaration-in-the-C-file thing, we'd
have noticed that the declaration of use_cyclone is in
include/asm-i386/mach-summit/mach_mpparse.h.

use_cyclone isn't defined if !CONFIG_X86_CYCLONE_TIMER.
arch/i386/kernel/srat.c is only compiled if X86_SUMMIT || X86_GENERICARCH.

<tries to break it>

I have a config here which has NUMA=y, ACPI_SRAT=y, X86_SUMMIT=n (and
X86_SUMMIT_NUMA=y!!) and, for some reason it set X86_CYCLONE_TIMER=y, which
is dumb.  But it will manage to link with this patch applied.

But still, referencing a variable which is implemented in
arch/i386/kernel/timers/timer_cyclone.c from within arch/i386/kernel/srat.c
is asking for trouble, no?

Re: 2.6.17-rc4-mm1

[Andrew Morton]

"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> Hi,
> 
> On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> >
> 
> When I try to "modprobe -r i2c_i801" modprobe hangs
> 
> [michal@ltg01-fedora ~]$ ps aux | grep mod
> root      5943  0.0  0.0   1648   432 tty1     D+   20:15   0:00
> modprobe -r i2c_i801
> michal   15499  0.0  0.0   1836   496 pts/4    S+   20:33   0:00 grep mod
> 
> Here is strace log
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/strace.txt
> Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config
> 
> 2.6.17-rc3-mm1 was fine. I don't see nothing abnormal in dmesg.
> 

Are you able to get a sysrq-P and/or sysrq-T trace out of it?

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

> But still, referencing a variable which is implemented in
> arch/i386/kernel/timers/timer_cyclone.c from within arch/i386/kernel/srat.c
> is asking for trouble, no?

Probably, but where would you define it instead? It kind of belongs
into timer_cyclone.c

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

> If we didn't do this lazy-ass put-the-declaration-in-the-C-file thing, 
> we'd have noticed that the declaration of use_cyclone is in 
> include/asm-i386/mach-summit/mach_mpparse.h.

updated patch below. Or lets drop the original patch that adds the 
panic?

	Ingo

---

Signed-off-by: Ingo Molnar <mingo@elte.hu>

 arch/i386/kernel/srat.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Index: linux/arch/i386/kernel/srat.c
===================================================================
--- linux.orig/arch/i386/kernel/srat.c
+++ linux/arch/i386/kernel/srat.c
@@ -266,13 +266,12 @@ int __init get_memcfg_from_srat(void)
 	int tables = 0;
 	int i = 0;
 
+#ifdef CONFIG_X86_CYCLONE_TIMER
 	extern int use_cyclone;
-	if (use_cyclone == 0) {
-		/* Make sure user sees something */
-		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
-		early_printk(s);
-		panic(s);
-	}
+	/* Make sure user sees something */
+	if (use_cyclone == 0)
+#endif
+		printk(KERN_WARN "WARNING: Not an IBM x440/NUMAQ and CONFIG_NUMA enabled!\n");
 
 	if (ACPI_FAILURE(acpi_find_root_pointer(ACPI_PHYSICAL_ADDRESSING,
 						rsdp_address))) {

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> 
> > But still, referencing a variable which is implemented in
> > arch/i386/kernel/timers/timer_cyclone.c from within arch/i386/kernel/srat.c
> > is asking for trouble, no?
> 
> Probably, but where would you define it instead? It kind of belongs 
> into timer_cyclone.c

there should be a asm-i386/cyclone.h that properly defines this. (and to 
make things more consistent, it could make it 0 even if 
!CONFIG_X86_CYCLONE_TIMER)

	Ingo

Re: [PATCH] x86 NUMA panic compile error

[Dave Hansen]

On Mon, 2006-05-15 at 20:37 +0200, Andi Kleen wrote:
> My arguments for remove:
> - The code is very hackish - it was written before the proper ACPI
> infrastructure is in place - and NUMA on 32bit in general needs a lot
> of hacks because of the limited ZONE_NORMAL.
> - NUMA on 32bit is kind of broken by design.
> - It isn't used much.
> - It breaks often
> - It tends to not work on Opterons and hits the users who try it
> there.

I think you are right: there are very few end users running with
CONFIG_NUMA on normal x86.  But, there is a disproportionately large
number of developers who do it.  There are quite a few IBM (and maybe
more via OSDL) developers who's only access to real NUMA hardware is x86
NUMAQs and Summit machines.  When somebody says "foo is broken on NUMA",
I go right to an x86 box.

Anyway, I'd like to think that we've contributed enough to the generic
NUMA code to have earned our keep and allow our little x86 NUMA "hacks"
to remain.  x86 is a legacy architecture now anyway, right? ;)

-- Dave

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> updated patch below. Or lets drop the original patch that adds the 
> panic?

another update: s/KERN_WARN/KERN_WARNING ...

	Ingo

---

re-enable dummy NUMA on i386.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

 arch/i386/kernel/srat.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Index: linux/arch/i386/kernel/srat.c
===================================================================
--- linux.orig/arch/i386/kernel/srat.c
+++ linux/arch/i386/kernel/srat.c
@@ -266,13 +266,12 @@ int __init get_memcfg_from_srat(void)
 	int tables = 0;
 	int i = 0;
 
+#ifdef CONFIG_X86_CYCLONE_TIMER
 	extern int use_cyclone;
-	if (use_cyclone == 0) {
-		/* Make sure user sees something */
-		static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."
-		early_printk(s);
-		panic(s);
-	}
+	/* Make sure user sees something */
+	if (use_cyclone == 0)
+#endif
+		printk(KERN_WARNING "WARNING: Not an IBM x440/NUMAQ and CONFIG_NUMA enabled!\n");
 
 	if (ACPI_FAILURE(acpi_find_root_pointer(ACPI_PHYSICAL_ADDRESSING,
 						rsdp_address))) {

Re: 2.6.17-rc4-mm1

[Michal Piotrowski]

On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> >
> > Hi,
> >
> > On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> > >
> >
> > When I try to "modprobe -r i2c_i801" modprobe hangs
> >
> > [michal@ltg01-fedora ~]$ ps aux | grep mod
> > root      5943  0.0  0.0   1648   432 tty1     D+   20:15   0:00
> > modprobe -r i2c_i801
> > michal   15499  0.0  0.0   1836   496 pts/4    S+   20:33   0:00 grep mod
> >
> > Here is strace log
> > http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/strace.txt
> > Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config
> >
> > 2.6.17-rc3-mm1 was fine. I don't see nothing abnormal in dmesg.
> >
>
> Are you able to get a sysrq-P and/or sysrq-T trace out of it?
>

Something like
echo "t" > /proc/sysrq-trigger
modprobe -r i2c_i801
echo "t" > /proc/sysrq-trigger
?
http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg2

I'm not sure why when I do "echo "p" > /proc/sysrq-trigger" I get only this
[root@ltg01-fedora ~]# echo "p" > /proc/sysrq-trigger
SysRq : Show Regs

selinux?

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

> I think you are right: there are very few end users running with
> CONFIG_NUMA on normal x86.  But, there is a disproportionately large
> number of developers who do it.  There are quite a few IBM (and maybe
> more via OSDL) developers who's only access to real NUMA hardware is x86
> NUMAQs and Summit machines.  When somebody says "foo is broken on NUMA",
> I go right to an x86 box.
> Anyway, I'd like to think that we've contributed enough to the generic
> NUMA code to have earned our keep and allow our little x86 NUMA "hacks"
> to remain.  

Yes that is why i did the "only work on Summit" patch as compromise.
With that you can have your hacks, but it won't impact anybody else.

> x86 is a legacy architecture now anyway, right? ;)
I wish everybody would agree on that @)

-Andi

Re: 2.6.17-rc4-mm1

[Andrew Morton]

"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> > > >
> > >
> > > When I try to "modprobe -r i2c_i801" modprobe hangs
> > >
> > > [michal@ltg01-fedora ~]$ ps aux | grep mod
> > > root      5943  0.0  0.0   1648   432 tty1     D+   20:15   0:00
> > > modprobe -r i2c_i801
> > > michal   15499  0.0  0.0   1836   496 pts/4    S+   20:33   0:00 grep mod
> > >
> > > Here is strace log
> > > http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/strace.txt
> > > Here is config http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-config
> > >
> > > 2.6.17-rc3-mm1 was fine. I don't see nothing abnormal in dmesg.
> > >
> >
> > Are you able to get a sysrq-P and/or sysrq-T trace out of it?
> >
> 
> Something like
> echo "t" > /proc/sysrq-trigger
> modprobe -r i2c_i801
> echo "t" > /proc/sysrq-trigger
> ?
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc4-mm1/mm-dmesg2

Great, thanks.   Here's the relevant part:

modprobe      D 00000019  2740  2163   2129                     (NOTLB)
       f0915e60 f1d7b694 8422805f 00000019 f0915e08 c10819a3 f1d7b694 f0915e18 
       00000007 f7e5f374 f7e5f250 f7f0f110 c741cf00 8429b934 00000019 000738d5 
       00000001 f1e6ac54 c101732e f0915e48 c10168d4 f887dba0 00000246 00000001 
Call Trace:
 <c11d768e> wait_for_completion+0x8e/0x108   <c1180fae> i2c_del_adapter_nolock+0x255/0x277
 <c1180fe7> i2c_del_adapter+0x17/0x28   <f887c023> i801_remove+0xd/0x2f [i2c_i801]
 <c10eeb69> pci_device_remove+0x19/0x2c   <c11395a7> __device_release_driver+0x63/0x79
 <c1139889> driver_detach+0x94/0xc4   <c1138d58> bus_remove_driver+0x5d/0x79
 <c11399a2> driver_unregister+0xb/0x18   <c10eecd4> pci_unregister_driver+0x13/0xa5
 <f887c9a5> i2c_i801_exit+0xd/0xf [i2c_i801]   <c103d3a8> sys_delete_module+0x19e/0x1d6
 <c11dab67> sysenter_past_esp+0x54/0x75  

I'd assume that Kumar's i2c-add-support-for-virtual-i2c-adapters.patch is
the culprit.

> I'm not sure why when I do "echo "p" > /proc/sysrq-trigger" I get only this
> [root@ltg01-fedora ~]# echo "p" > /proc/sysrq-trigger
> SysRq : Show Regs
> 
> selinux?

The `p' command isn't effective when using /proc/sysrq-trigger.  `p' will
show the backtrace of the currently-running process (on the current cpu). 
That task is always "echo".  Boring.  So `p' is really only useful when
invoked from interrupt context, via sysrq-p.

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> > x86 is a legacy architecture now anyway, right? ;)
> I wish everybody would agree on that @)

as far as i'm concerned x86 is obsolete: my main devel and testboxes are 
64-bit throughout, and i develop for 64-bit by default.

Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
and debugged on 32-bit too, because x86_64 debugging is still quite a 
PITA and wastes alot of time: for example it has no support for exact 
kernel stacktraces. Also, the printout of the backtrace is butt-ugly and 
as un-ergonomic to the human eye as it gets - who came up with that 
"two-maybe-one function entries per-line" nonsense? [Whoever did it he 
never had to look at (and make sense of) hundreds of stacktraces in a 
row.]

Also, the majority of kernel bugs still get reported on 32-bit and most 
of the testers are on 32-bit. So x86_64 is nice but it still needs some 
work, mainly in terms of debuggability.

	Ingo

Re: 2.6.17-rc4-mm1

[Ingo Molnar]

* Andrew Morton <akpm@osdl.org> wrote:

>   - The cachefs patches are back (local-disk-based caching of network
>     filesystem files) (David Howells)

the blind hacks below are needed to make CONFIG_CACHEFILES build.

	Ingo

Index: linux/fs/cachefiles/cf-namei.c
===================================================================
--- linux.orig/fs/cachefiles/cf-namei.c
+++ linux/fs/cachefiles/cf-namei.c
@@ -124,31 +124,31 @@ try_again:
 	}
 
 	/* do the multiway lock magic */
-	trap = lock_rename(cache->graveyard, dir);
+	trap = lock_rename(cache->graveyard, dir, 0);
 
 	/* do some checks before getting the grave dentry */
 	if (rep->d_parent != dir) {
 		/* the entry was probably culled when we dropped the parent dir
 		 * lock */
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		_leave(" = 0 [culled?]");
 		return 0;
 	}
 
 	if (!S_ISDIR(cache->graveyard->d_inode->i_mode)) {
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		cachefiles_io_error(cache, "Graveyard no longer a directory");
 		return -EIO;
 	}
 
 	if (trap == rep) {
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		cachefiles_io_error(cache, "May not make directory loop");
 		return -EIO;
 	}
 
 	if (d_mountpoint(rep)) {
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		cachefiles_io_error(cache, "Mountpoint in cache");
 		return -EIO;
 	}
@@ -160,7 +160,7 @@ try_again:
 
 		grave = d_alloc(cache->graveyard, &name);
 		if (!grave) {
-			unlock_rename(cache->graveyard, dir);
+			unlock_rename(cache->graveyard, dir, 0);
 			_leave(" = -ENOMEM");
 			return -ENOMEM;
 		}
@@ -168,7 +168,7 @@ try_again:
 		alt = cache->graveyard->d_inode->i_op->lookup(
 			cache->graveyard->d_inode, grave, NULL);
 		if (IS_ERR(alt)) {
-			unlock_rename(cache->graveyard, dir);
+			unlock_rename(cache->graveyard, dir, 0);
 			dput(grave);
 
 			if (PTR_ERR(alt) == -ENOMEM) {
@@ -188,7 +188,7 @@ try_again:
 	}
 
 	if (grave->d_inode) {
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		dput(grave);
 		grave = NULL;
 		cond_resched();
@@ -196,7 +196,7 @@ try_again:
 	}
 
 	if (d_mountpoint(grave)) {
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		dput(grave);
 		cachefiles_io_error(cache, "Mountpoint in graveyard");
 		return -EIO;
@@ -204,7 +204,7 @@ try_again:
 
 	/* target should not be an ancestor of source */
 	if (trap == grave) {
-		unlock_rename(cache->graveyard, dir);
+		unlock_rename(cache->graveyard, dir, 0);
 		dput(grave);
 		cachefiles_io_error(cache, "May not make directory loop");
 		return -EIO;
@@ -231,7 +231,7 @@ try_again:
 
 	fsnotify_oldname_free(old_name);
 
-	unlock_rename(cache->graveyard, dir);
+	unlock_rename(cache->graveyard, dir, 0);
 	dput(grave);
 	_leave(" = 0");
 	return 0;

Re: 2.6.17-rc4-mm1

[Michael Halcrow]

On Mon, May 15, 2006 at 10:01:44AM -0700, Andrew Morton wrote:
> I don't immediately see how to fix this one, actually:
> 
> static inline int ecryptfs_statfs(struct super_block *sb, struct kstatfs *buf)
> {
> 	return vfs_statfs(ecryptfs_superblock_to_lower(sb), buf);
> }
> 
> Once we've run ecryptfs_superblock_to_lower() to get the "lower
> superblock", we need to turn that back into a vfsmount for
> vfs_statfs()..

Assuming we have all our other ducks in a row, this should work. I
still need to finish the build and run my tests to say for certain,
but here is a tentative fix.

Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>

---

Index: linux-2.6.17-rc4-mm1-ecryptfs/fs/ecryptfs/super.c
===================================================================
--- linux-2.6.17-rc4-mm1-ecryptfs.orig/fs/ecryptfs/super.c      2006-05-15 14:16:15.000000000 -0500
+++ linux-2.6.17-rc4-mm1-ecryptfs/fs/ecryptfs/super.c   2006-05-15 14:27:45.000000000 -0500
@@ -124,9 +124,12 @@
  * Get the filesystem statistics. Currently, we let this pass right through
  * to the lower filesystem and take no action ourselves.
  */
-static inline int ecryptfs_statfs(struct super_block *sb, struct kstatfs *buf)
+static int ecryptfs_statfs(struct vfsmount *vfs_mnt, struct kstatfs *buf)
 {
-       return vfs_statfs(ecryptfs_superblock_to_lower(sb), buf);
+       struct vfsmount *lower_mnt;
+
+       lower_mnt = ecryptfs_superblock_to_private(vfs_mnt->mnt_sb)->lower_mnt;
+       return vfs_statfs(lower_mnt, buf);
 }
 
 /**

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

> Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
> and debugged on 32-bit too, because x86_64 debugging is still quite a 
> PITA and wastes alot of time: for example it has no support for exact 
> kernel stacktraces.

Hopefully soon.

I think i386 only gained it very recently, so it can't be _that_ big
a problem.

The real issue is too deeply nested code like the callback hell
we have in some subsystems. Better would be to eliminate that. 2.4
was much nicer in this regard and there has been quite a lot of 
unnecessary complications in this area when the kernel went to 2.6.

> Also, the printout of the backtrace is butt-ugly and  
> as un-ergonomic to the human eye as it gets - who came up with that 
> "two-maybe-one function entries per-line" nonsense? [Whoever did it he 
> never had to look at (and make sense of) hundreds of stacktraces in a 
> row.]

The original goal was to make it fit as much as possible on 
the screen when you don't have a serial/net/fireconsole.
But arguably it's less and less useful because the kernel
has gotten so huge that most backtraces are very long and scroll
away anyways.

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Andrew Morton]

Ingo Molnar <mingo@elte.hu> wrote:
>
> Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
> and debugged on 32-bit too, because x86_64 debugging is still quite a 
> PITA and wastes alot of time: for example it has no support for exact 
> kernel stacktraces. Also, the printout of the backtrace is butt-ugly and 
> as un-ergonomic to the human eye as it gets

Yes, I find x86_64 traces significantly harder to follow.  And I miss the
display of the length of the functions (do_md_run+1208 instead of
do_md_run+1208/2043).  The latter form makes it easier to work out
whereabouts in the function things happened.

That, plus the mix of hex and decimal numbers..

> who came up with that 
> "two-maybe-one function entries per-line" nonsense? [Whoever did it he 
> never had to look at (and make sense of) hundreds of stacktraces in a 
> row.]

Plus they're wide enough to get usefully wordwrapped when someone mails
them to you.

Re: [PATCH] x86 NUMA panic compile error

[Martin Bligh]

Andrew Morton wrote:
> Andy Whitcroft <apw@shadowen.org> wrote:
> 
>>>So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? 
>>>(It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS
>>>or something).
>>
>>How about CONFIG_EXPERIMENTAL?
> 
> 
> Probably CONFIG_ADVANCED would be closer.

It defaults to off already - people have to explicitly enable it.

Plus the original point was to be able to build one kernel that'd work
across NUMA and non-NUMA boxes.

M.

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

[... feels the love ...]

On Monday 15 May 2006 21:39, Andrew Morton wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> >
> > Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
> > and debugged on 32-bit too, because x86_64 debugging is still quite a 
> > PITA and wastes alot of time: for example it has no support for exact 
> > kernel stacktraces. Also, the printout of the backtrace is butt-ugly and 
> > as un-ergonomic to the human eye as it gets
> 
> Yes, I find x86_64 traces significantly harder to follow.  And I miss the
> display of the length of the functions (do_md_run+1208 instead of
> do_md_run+1208/2043).  The latter form makes it easier to work out
> whereabouts in the function things happened.
> 
> That, plus the mix of hex and decimal numbers..
> 
> > who came up with that 
> > "two-maybe-one function entries per-line" nonsense? [Whoever did it he 
> > never had to look at (and make sense of) hundreds of stacktraces in a 
> > row.]
> 
> Plus they're wide enough to get usefully wordwrapped when someone mails
> them to you.

Hmm, I didn't realize they were _that_ unpopular. If you got the i386 
like space wasting backtraces would you guys all switch your development machines
to x86-64 ? @)

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Andrew Morton]

Andi Kleen <ak@suse.de> wrote:
>
> 
> [... feels the love ...]

heh.

> On Monday 15 May 2006 21:39, Andrew Morton wrote:
> > Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
> > > and debugged on 32-bit too, because x86_64 debugging is still quite a 
> > > PITA and wastes alot of time: for example it has no support for exact 
> > > kernel stacktraces. Also, the printout of the backtrace is butt-ugly and 
> > > as un-ergonomic to the human eye as it gets
> > 
> > Yes, I find x86_64 traces significantly harder to follow.  And I miss the
> > display of the length of the functions (do_md_run+1208 instead of
> > do_md_run+1208/2043).  The latter form makes it easier to work out
> > whereabouts in the function things happened.
> > 
> > That, plus the mix of hex and decimal numbers..
> > 
> > > who came up with that 
> > > "two-maybe-one function entries per-line" nonsense? [Whoever did it he 
> > > never had to look at (and make sense of) hundreds of stacktraces in a 
> > > row.]
> > 
> > Plus they're wide enough to get usefully wordwrapped when someone mails
> > them to you.
> 
> Hmm, I didn't realize they were _that_ unpopular. If you got the i386 
> like space wasting backtraces would you guys all switch your development machines
> to x86-64 ? @)
> 

Developers use serial consoles for such things.  (I discovered
`console=uart,...' yesterday.  It works nicely as an earlyprintk on ia64..)

It's reports-from-the-field which are the problem.

A lot of these problems can be address by simple cranking up the VGA screen
resolution, but I discovered that I don't know how to do that - I've always
used `vga=extended', but that doesn't work on an EFI-booted ia64 box.

Does anyone know what the magic option is to make the vga console use 50
rows?

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

On Monday 15 May 2006 21:59, Andrew Morton wrote:

> > On Monday 15 May 2006 21:39, Andrew Morton wrote:
> > > Ingo Molnar <mingo@elte.hu> wrote:
> > > >
> > > > Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
> > > > and debugged on 32-bit too, because x86_64 debugging is still quite a 
> > > > PITA and wastes alot of time: for example it has no support for exact 
> > > > kernel stacktraces. Also, the printout of the backtrace is butt-ugly and 
> > > > as un-ergonomic to the human eye as it gets
> > > 
> > > Yes, I find x86_64 traces significantly harder to follow.  And I miss the
> > > display of the length of the functions (do_md_run+1208 instead of
> > > do_md_run+1208/2043).  The latter form makes it easier to work out
> > > whereabouts in the function things happened.
> > > 
> > > That, plus the mix of hex and decimal numbers..
> > > 
> > > > who came up with that 
> > > > "two-maybe-one function entries per-line" nonsense? [Whoever did it he 
> > > > never had to look at (and make sense of) hundreds of stacktraces in a 
> > > > row.]
> > > 
> > > Plus they're wide enough to get usefully wordwrapped when someone mails
> > > them to you.
> > 
> > Hmm, I didn't realize they were _that_ unpopular. If you got the i386 
> > like space wasting backtraces would you guys all switch your development machines
> > to x86-64 ? @)
> > 
> 
> Developers use serial consoles for such things.  (I discovered
> `console=uart,...' yesterday.  It works nicely as an earlyprintk on ia64..)

I can also recommend firescope + firewire cards. It's not early
yet, but I hope eventually. But it can work without the target still
being alive and also does on most laptops.
 
> It's reports-from-the-field which are the problem.

In my experience the biggest problem in the field is that most 
of it scrolls away. That is why I tweaked the x86-64 format to be as space
efficient as possible. That's also why the "executive summary" was added.

But Ingo has a point that it usually doesn't help anyways because backtraces
tend to be so overlong now after the code got through 20 callbacks before
it can do something actually useful.


> A lot of these problems can be address by simple cranking up the VGA screen
> resolution, but I discovered that I don't know how to do that - I've always
> used `vga=extended', but that doesn't work on an EFI-booted ia64 box.
> 
> Does anyone know what the magic option is to make the vga console use 50
> rows?

I use vga=0x0f07

It's a butt ugly font, but it's the smallest I could find without using
the slow fbcon.

If you can't remember the hex number use vga=ask

-Andi

Re: 2.6.17-rc4-mm1

[Michal Piotrowski]

On 15/05/06, Andrew Morton <akpm@osdl.org> wrote:
> Great, thanks.   Here's the relevant part:
>
> modprobe      D 00000019  2740  2163   2129                     (NOTLB)
>        f0915e60 f1d7b694 8422805f 00000019 f0915e08 c10819a3 f1d7b694 f0915e18
>        00000007 f7e5f374 f7e5f250 f7f0f110 c741cf00 8429b934 00000019 000738d5
>        00000001 f1e6ac54 c101732e f0915e48 c10168d4 f887dba0 00000246 00000001
> Call Trace:
>  <c11d768e> wait_for_completion+0x8e/0x108   <c1180fae> i2c_del_adapter_nolock+0x255/0x277
>  <c1180fe7> i2c_del_adapter+0x17/0x28   <f887c023> i801_remove+0xd/0x2f [i2c_i801]
>  <c10eeb69> pci_device_remove+0x19/0x2c   <c11395a7> __device_release_driver+0x63/0x79
>  <c1139889> driver_detach+0x94/0xc4   <c1138d58> bus_remove_driver+0x5d/0x79
>  <c11399a2> driver_unregister+0xb/0x18   <c10eecd4> pci_unregister_driver+0x13/0xa5
>  <f887c9a5> i2c_i801_exit+0xd/0xf [i2c_i801]   <c103d3a8> sys_delete_module+0x19e/0x1d6
>  <c11dab67> sysenter_past_esp+0x54/0x75
>
> I'd assume that Kumar's i2c-add-support-for-virtual-i2c-adapters.patch is
> the culprit.

Unfortunately it's not this patch.
I'll check all Kumar's patches.

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

Re: 2.6.17-rc4-mm1

[Neil Brown]

On Tuesday May 16, reuben-lkml@reub.net wrote:
> 
> 
> On 15/05/2006 7:56 p.m., Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> > 
> > - This tree contains a large number of new bugs^H^H^H^Hpatches.
> 
> Indeed.  This is the first -mm in a fair while that has crapped itself on boot 
> on my box.
> 
> NeilB - is this yours?

Uhmmm. yes.  I have a patch that I was going to send of a little later
today.  Just give me an hour or two...

NeilBrown

Re: 2.6.17-rc4-mm1

[David Woodhouse]

On Mon, 2006-05-15 at 19:03 +0200, Michal Piotrowski wrote:
> make with O=/dir doesn't work. 

Thanks.

http://git.infradead.org/?p=hdrinstall-2.6.git;a=commitdiff;h=4090bed2af5e4b533a13b01ddbda0c9684cc669f

-- 
dwmw2

Re: [PATCH] x86 NUMA panic compile error

[H. Peter Anvin]

Followup to:  <200605152111.20693.ak@suse.de>
By author:    Andi Kleen <ak@suse.de>
In newsgroup: linux.dev.kernel
> 
> > x86 is a legacy architecture now anyway, right? ;)
> I wish everybody would agree on that @)
> 

It's going to live on for a very long time, though.  Intel is still
shipping some very fast 64-bit-deficient silicon.  Once that's gone,
it's going to live on for decades in the embedded world.

	-hpa

Re: [PATCH] x86 NUMA panic compile error

[Ingo Molnar]

* Andi Kleen <ak@suse.de> wrote:

> > Nevertheless for hard-to-debug bugs i prefer if they can be reproduced 
> > and debugged on 32-bit too, because x86_64 debugging is still quite a 
> > PITA and wastes alot of time: for example it has no support for exact 
> > kernel stacktraces.
> 
> Hopefully soon.

i've already implemented it for FRAME_POINTERS (i really needed it to 
not go insane when looking at lock validator output).

As you suggested a few weeks ago the real solution would be a dwarf 
parser. Maybe ia64's could be taken? Will post the patch for the 
FRAME_POINTERS solution soon. Sample output:

     [<ffffffff8020af4c>] __show_trace+0x3a/0x66
     [<ffffffff8020b36b>] show_trace+0x17/0x1a
     [<ffffffff80207e36>] show_regs+0x36/0x3c
     [<ffffffff80207e75>] smp_show_regs+0x39/0x52
     [<ffffffff8021559e>] smp_nmi_callback+0x6a/0x85
     [<ffffffff802163f2>] do_nmi+0x69/0x91
     [<ffffffff80601dca>] nmi+0x7e/0x85
     [<ffffffffffffffff>] 0xffffffffffffffff
     [<ffffffff80601ad0>] _spin_unlock_irqrestore+0x3e/0x47
     [<ffffffff8024424c>] prepare_to_wait+0x63/0x6d
     [<ffffffff8022ff0c>] do_syslog+0xf1/0x3ca
     [<ffffffff802ba3ed>] kmsg_read+0x3a/0x46
     [<ffffffff8027db72>] vfs_read+0xe6/0x191
     [<ffffffff8027e79d>] sys_read+0x44/0x82
     [<ffffffff80209b11>] system_call+0x7d/0x83
     [<ffffffffffffffff>] 0xffffffffffffffff

(and it works fine across irq/exception stacks too.)

> I think i386 only gained it very recently, so it can't be _that_ big a 
> problem.

i certainly used exact backtraces on i386 for many many years. Not sure 
whether those patches were all upstream though. It's also the 
combination of effects that makes the difference between i386 and x86_64 
so striking.

furthermore, the kernel's debugging infrastructure improved 
significantly, and we get more and more stackdumps to interpret [instead 
of hard to debug corruptions, etc.].

> The real issue is too deeply nested code like the callback hell we 
> have in some subsystems. Better would be to eliminate that. 2.4 was 
> much nicer in this regard and there has been quite a lot of 
> unnecessary complications in this area when the kernel went to 2.6.

i have no problems with interpreting occasional non-exact backtraces, 
but it is certainly non-obvious, and when you are looking at backtraces 
en masse, the unnecessary repetitive task can get really distracting and 
frustrating.

Exact backtraces on the other hand almost immediately create a unique 
and reliable "visual fingerprint", and if you have looked at enough of 
them, you almost recognize them just from looking at the shape of them. 
It's a completely different 'experience'. (and userspace developers will 
laugh out loud at us now i suspect ...)

> > Also, the printout of the backtrace is butt-ugly and as un-ergonomic 
> > to the human eye as it gets - who came up with that "two-maybe-one 
> > function entries per-line" nonsense? [Whoever did it he never had to 
> > look at (and make sense of) hundreds of stacktraces in a row.]
> 
> The original goal was to make it fit as much as possible on the screen 
> when you don't have a serial/net/fireconsole. But arguably it's less 
> and less useful because the kernel has gotten so huge that most 
> backtraces are very long and scroll away anyways.

yeah.

	Ingo

Re: 2.6.17-rc4-mm1

[Jean Delvare]

> > I'd assume that Kumar's i2c-add-support-for-virtual-i2c-adapters.patch is
> > the culprit.
> 
> Unfortunately it's not this patch.
> I'll check all Kumar's patches.

There are no differences in i2c patches between 2.6.17-rc3-mm1 and
2.6.17-rc4-mm1. As you said the bug is new in 2.6.17-rc4-mm1, this
suggests that the bug is not in the i2c patches. Could be that these
patches need to be updated to reflect a recent change in another tree
though.

I'll try to reproduce the bug here.

-- 
Jean Delvare

Re: 2.6.17-rc4-mm1

[Takashi Iwai]

At Mon, 15 May 2006 11:11:11 -0700,
Andrew Morton wrote:
> 
> Takashi Iwai <tiwai@suse.de> wrote:
> >
> > -unsigned int snd_cards_lock = 0;	/* locked for registering/using */
> > +static unsigned int snd_cards_lock = 0;	/* locked for registering/using */
> 
> May as well remove the `= 0' while you're there.  It adds four bytes to the
> module unnecessarily.

Yep.  Will remove it.

> >  void snd_request_card(int card)
> >  {
> > -	int locked;
> > -
> >  	if (! current->fs->root)
> >  		return;
> 
> I wonder what that's there for.

This is almost for backward compatibility only.
We have already module aliases, so it can be cleaned up.


Takashi

Re: [PATCH] x86 NUMA panic compile error

[Andi Kleen]

> As you suggested a few weeks ago the real solution would be a dwarf 
> parser. Maybe ia64's could be taken? 

Ia64's would be a lot of work.

> (and it works fine across irq/exception stacks too.)

It didn't work at all through the old locks/semaphore stubs.

> > I think i386 only gained it very recently, so it can't be _that_ big a 
> > problem.
> 
> i certainly used exact backtraces on i386 for many many years.

The patch into mainline went in in mid 2004. 

http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=commit;h=066479e379f387e5b1da0f1149fe0b97bac58888


-Andi

2.6.17-rc4-mm1: no help text for MTD_NAND_CS553

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-mtd.patch
>...
>  git trees
>...

This patch adds an MTD_NAND_CS553 option without a help text.

Please add at least a small help text.

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[-mm patch] drivers/mtd/devices/docprobe.c: correct #if's

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-mtd.patch
>...
>  git trees
>...

If we correct the names of the config options, the code might actually 
work as intended...
 
Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/mtd/devices/docprobe.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.17-rc4-mm1-full/drivers/mtd/devices/docprobe.c.old	2006-05-16 12:58:49.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/mtd/devices/docprobe.c	2006-05-16 12:59:08.000000000 +0200
@@ -231,21 +231,21 @@
 
 static int docfound;
 
-#ifdef CONFIG_DOC2000
+#ifdef CONFIG_MTD_DOC2000
 extern void DoC2k_init(struct mtd_info *);
 #define doc2k_initfunc (&DoC2k_init)
 #else 
 #define doc2k_initfunc NULL
 #endif
 
-#ifdef CONFIG_DOC2001
+#ifdef CONFIG_MTD_DOC2001
 extern void DoCMil_init(struct mtd_info *);
 #define docmil_initfunc (&DoCMil_init)
 #else 
 #define docmil_initfunc NULL
 #endif
 
-#ifdef CONFIG_DOC2001PLUS
+#ifdef CONFIG_MTD_DOC2001PLUS
 extern void DoCMilPlus_init(struct mtd_info *);
 #define docmplus_initfunc (&DoCMilPlus_init)
 #else 

[-mm patch] make dvb/b2c2/flexcop-fe-tuner.c:alps_tdee4_stv0297_tuner_set_params() static

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-dvb.patch
>...
>  git trees
>...

This patch makes the needlessly global 
alps_tdee4_stv0297_tuner_set_params() static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-rc4-mm1-full/drivers/media/dvb/b2c2/flexcop-fe-tuner.c.old	2006-05-16 12:50:54.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/dvb/b2c2/flexcop-fe-tuner.c	2006-05-16 12:51:08.000000000 +0200
@@ -354,7 +354,8 @@
 	.demod_address = 0x0e,
 };
 
-int alps_tdee4_stv0297_tuner_set_params (struct dvb_frontend* fe, struct dvb_frontend_parameters *fep)
+static int alps_tdee4_stv0297_tuner_set_params(struct dvb_frontend* fe,
+					       struct dvb_frontend_parameters *fep)
 {
 	struct flexcop_device *fc = fe->dvb->priv;
 	u8 buf[4];

Re: 2.6.17-rc4-mm1: no help text for MTD_NAND_CS553

[David Woodhouse]

On Tue, 2006-05-16 at 12:25 +0200, Adrian Bunk wrote:
> This patch adds an MTD_NAND_CS553 option without a help text.
> 
> Please add at least a small help text.

Done; thanks.

config MTD_NAND_CS553X
	tristate "NAND support for CS5535/CS5536 (AMD Geode companion chip)"
	depends on MTD_NAND && X86_PC && PCI
	help
	  The CS553x companion chips for the AMD Geode processor
	  include NAND flash controllers with built-in hardware ECC
	  capabilities; enabling this option will allow you to use
	  these. The driver will check the MSRs to verify that the
	  controller is enabled for NAND, and currently requires that
	  the controller be in MMIO mode.

	  If you say "m", the module will be called "cs553x_nand.ko".
-- 
dwmw2

Re: [-mm patch] drivers/mtd/devices/docprobe.c: correct #if's

[David Woodhouse]

On Tue, 2006-05-16 at 13:46 +0200, Adrian Bunk wrote:
> If we correct the names of the config options, the code might actually
> work as intended...

S'true. Applied; thanks.

I've dug out one or two of these devices from the toy cupboard -- I want
to make sure we get the new version of the driver, using the generic
NAND code, working with all of them... and then we can drop the old
drivers altogether.

-- 
dwmw2

[-mm patch] drivers/media/video/pwc/: make code static

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-dvb.patch
>...
>  git trees
>...

This patch makes the following needlessly global code static:
- pwc-ctrl.c: pwc_get_leds()
- pwc_preferred_compression

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/media/video/pwc/pwc-ctrl.c |    2 +-
 drivers/media/video/pwc/pwc-if.c   |    2 +-
 drivers/media/video/pwc/pwc.h      |    2 --
 3 files changed, 2 insertions(+), 4 deletions(-)

--- linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc.h.old	2006-05-16 12:54:35.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc.h	2006-05-16 12:55:17.000000000 +0200
@@ -274,7 +274,6 @@
 #if CONFIG_PWC_DEBUG
 extern int pwc_trace;
 #endif
-extern int pwc_preferred_compression;
 extern int pwc_mbufs;
 
 /** functions in pwc-if.c */
@@ -308,7 +307,6 @@
 extern int pwc_get_saturation(struct pwc_device *pdev, int *value);
 extern int pwc_set_saturation(struct pwc_device *pdev, int value);
 extern int pwc_set_leds(struct pwc_device *pdev, int on_value, int off_value);
-extern int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value);
 extern int pwc_get_cmos_sensor(struct pwc_device *pdev, int *sensor);
 extern int pwc_restore_user(struct pwc_device *pdev);
 extern int pwc_save_user(struct pwc_device *pdev);
--- linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-ctrl.c.old	2006-05-16 12:54:49.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-ctrl.c	2006-05-16 12:54:55.000000000 +0200
@@ -925,7 +925,7 @@
 	return SendControlMsg(SET_STATUS_CTL, LED_FORMATTER, 2);
 }
 
-int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value)
+static int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value)
 {
 	unsigned char buf[2];
 	int ret;
--- linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-if.c.old	2006-05-16 12:55:26.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-if.c	2006-05-16 12:55:36.000000000 +0200
@@ -133,7 +133,7 @@
 #endif
 static int power_save = 0;
 static int led_on = 100, led_off = 0; /* defaults to LED that is on while in use */
-       int pwc_preferred_compression = 1; /* 0..3 = uncompressed..high */
+static int pwc_preferred_compression = 1; /* 0..3 = uncompressed..high */
 static struct {
 	int type;
 	char serial_number[30];

[-mm patch] make variables static after klibc merge

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm1/
> 
> - This tree contains a large number of new bugs^H^H^H^Hpatches.
> 
>   - klibc (Kernel libc), as git-klibc.patch (Peter Anvin)
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-klibc.patch
>...
>  git trees
>...

We can now make the following variables static:
- drivers/md/md.c: mdp_major
- init/main.c: envp_init[]

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/md/md.c |    2 +-
 init/main.c     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.17-rc4-mm1-full/drivers/md/md.c.old	2006-05-16 12:49:59.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/md/md.c	2006-05-16 12:50:17.000000000 +0200
@@ -2563,7 +2563,7 @@
 	.default_attrs	= md_default_attrs,
 };
 
-int mdp_major = 0;
+static int mdp_major = 0;
 
 static struct kobject *md_probe(dev_t dev, int *part, void *data)
 {
--- linux-2.6.17-rc4-mm1-full/init/main.c.old	2006-05-16 13:20:22.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/init/main.c	2006-05-16 13:20:43.000000000 +0200
@@ -161,7 +161,7 @@
 __setup("maxcpus=", maxcpus);
 
 static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
-char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
+static char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
 static const char *panic_later, *panic_param;
 
 extern struct obs_kernel_param __setup_start[], __setup_end[];

[-mm patch] make drivers/mtd/nand/cs553x_nand.c:cs553x_init() static

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-mtd.patch
>...
>  git trees
>...

This patch makes the needlessly global cs553x_init() static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-rc4-mm1-full/drivers/mtd/nand/cs553x_nand.c.old	2006-05-16 13:02:13.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/mtd/nand/cs553x_nand.c	2006-05-16 13:02:24.000000000 +0200
@@ -267,7 +267,7 @@
 	return err;
 }
 
-int __init cs553x_init(void)
+static int __init cs553x_init(void)
 {
 	int err = -ENXIO;
 	int i;

[-mm patch] fs/nfs/: make code static

[Adrian Bunk]

This patch makes needlessly global code static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 fs/nfs/client.c         |    6 ++++--
 fs/nfs/internal.h       |    2 --
 fs/nfs/namespace.c      |   12 +++++++++---
 include/linux/nfs_fs.h  |    4 ----
 include/linux/nfs_xdr.h |    1 -
 5 files changed, 13 insertions(+), 12 deletions(-)

--- linux-2.6.17-rc4-mm1-full/fs/nfs/internal.h.old	2006-05-16 13:11:54.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/nfs/internal.h	2006-05-16 13:12:00.000000000 +0200
@@ -38,8 +38,6 @@
 };
 
 /* client.c */
-extern struct rpc_program nfs_program;
-
 extern void nfs_put_client(struct nfs_client *);
 extern struct nfs_client *nfs_find_client(struct sockaddr_in *, int);
 extern struct nfs_server *nfs_create_server(struct nfs_mount_data *,
--- linux-2.6.17-rc4-mm1-full/include/linux/nfs_xdr.h.old	2006-05-16 13:12:07.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/include/linux/nfs_xdr.h	2006-05-16 13:12:20.000000000 +0200
@@ -838,6 +838,5 @@
 extern struct rpc_version	nfs_version4;
 
 extern struct rpc_version	nfsacl_version3;
-extern struct rpc_program	nfsacl_program;
 
 #endif
--- linux-2.6.17-rc4-mm1-full/fs/nfs/client.c.old	2006-05-16 13:12:32.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/nfs/client.c	2006-05-16 13:25:59.000000000 +0200
@@ -75,7 +75,7 @@
 #endif
 };
 
-struct rpc_program nfs_program = {
+static struct rpc_program nfs_program = {
 	.name			= "nfs",
 	.number			= NFS_PROGRAM,
 	.nrvers			= ARRAY_SIZE(nfs_version),
@@ -90,12 +90,14 @@
 
 
 #ifdef CONFIG_NFS_V3_ACL
+static struct rpc_program	nfsacl_program;
+
 static struct rpc_stat		nfsacl_rpcstat = { &nfsacl_program };
 static struct rpc_version *	nfsacl_version[] = {
 	[3]			= &nfsacl_version3,
 };
 
-struct rpc_program		nfsacl_program = {
+static struct rpc_program	nfsacl_program = {
 	.name			= "nfsacl",
 	.number			= NFS_ACL_PROGRAM,
 	.nrvers			= ARRAY_SIZE(nfsacl_version),
--- linux-2.6.17-rc4-mm1-full/include/linux/nfs_fs.h.old	2006-05-16 13:13:54.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/include/linux/nfs_fs.h	2006-05-16 13:14:01.000000000 +0200
@@ -312,10 +312,6 @@
 extern struct nfs_open_context *get_nfs_open_context(struct nfs_open_context *ctx);
 extern void put_nfs_open_context(struct nfs_open_context *ctx);
 extern struct nfs_open_context *nfs_find_open_context(struct inode *inode, struct rpc_cred *cred, int mode);
-extern struct vfsmount *nfs_do_submount(const struct vfsmount *mnt_parent,
-					const struct dentry *dentry,
-					struct nfs_fh *fh,
-					struct nfs_fattr *fattr);
 
 /* linux/net/ipv4/ipconfig.c: trims ip addr off front of name, too. */
 extern u32 root_nfs_parse_addr(char *name); /*__init*/
--- linux-2.6.17-rc4-mm1-full/fs/nfs/namespace.c.old	2006-05-16 13:14:52.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/nfs/namespace.c	2006-05-16 13:14:33.000000000 +0200
@@ -26,6 +26,11 @@
 static DECLARE_WORK(nfs_automount_task, nfs_expire_automounts, &nfs_automount_list);
 int nfs_mountpoint_expiry_timeout = 500 * HZ;
 
+static struct vfsmount *nfs_do_submount(const struct vfsmount *mnt_parent,
+					const struct dentry *dentry,
+					struct nfs_fh *fh,
+					struct nfs_fattr *fattr);
+
 /*
  * nfs_path - reconstruct the path given an arbitrary dentry
  * @base - arbitrary string to prepend to the path
@@ -206,9 +211,10 @@
  * @fattr - attributes for new root inode
  *
  */
-struct vfsmount *nfs_do_submount(const struct vfsmount *mnt_parent,
-		const struct dentry *dentry, struct nfs_fh *fh,
-		struct nfs_fattr *fattr)
+static struct vfsmount *nfs_do_submount(const struct vfsmount *mnt_parent,
+					const struct dentry *dentry,
+					struct nfs_fh *fh,
+					struct nfs_fattr *fattr)
 {
 	struct nfs_clone_mount mountdata = {
 		.sb = mnt_parent->mnt_sb,

Re: 2.6.17-rc4-mm1

[Jean Delvare]

Quoting myself:

> I'll try to reproduce the bug here.

I can reproduce it, with both i2c-i801 and i2c-parport, so it's not
related to a specific driver. I'm currently performing a bisection on
2.6.17-rc4-mm1 to try and isolate the culprit. It seems to point to
gregkh-driver-*. i2c patches are innocent for sure, including Kumar's
ones.

-- 
Jean Delvare

Re: [-mm patch] make drivers/mtd/nand/cs553x_nand.c:cs553x_init() static

[David Woodhouse]

On Tue, 2006-05-16 at 14:37 +0200, Adrian Bunk wrote:
> This patch makes the needlessly global cs553x_init() static.

NAK. That problem was inherited from another board driver which was
copied and modified. And that driver inherited it in turn... let's not
piss about with them one at a time; let's just fix them _all_ at once,
instead. And let's remove the bizarre use of '#ifdef MODULE' around the
cleanup functions while we're at it.

http://git.infradead.org/?p=mtd-2.6.git;a=commitdiff;h=cead4dbc03ba6eb2e35bac04439b76a0cc2286ce

-- 
dwmw2

[-mm patch] arch/i386/oprofile/: make functions static

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
> +x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions.patch
>...
>  x86_64 tree updates
>...


This patch makes the following needlessly global functions static:
- nmi_int.c: profile_exceptions_notify()
- nmi_timer_int.c: profile_timer_exceptions_notify()

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 arch/i386/oprofile/nmi_int.c       |    4 ++--
 arch/i386/oprofile/nmi_timer_int.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.17-rc4-mm1-full/arch/i386/oprofile/nmi_int.c.old	2006-05-16 12:32:15.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/arch/i386/oprofile/nmi_int.c	2006-05-16 12:32:34.000000000 +0200
@@ -82,8 +82,8 @@
 #define exit_driverfs() do { } while (0)
 #endif /* CONFIG_PM */
 
-int profile_exceptions_notify(struct notifier_block *self,
-				unsigned long val, void *data)
+static int profile_exceptions_notify(struct notifier_block *self,
+				     unsigned long val, void *data)
 {
 	struct die_args *args = (struct die_args *)data;
 	int ret = NOTIFY_DONE;
--- linux-2.6.17-rc4-mm1-full/arch/i386/oprofile/nmi_timer_int.c.old	2006-05-16 12:32:55.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/arch/i386/oprofile/nmi_timer_int.c	2006-05-16 12:33:04.000000000 +0200
@@ -19,8 +19,8 @@
 #include <asm/ptrace.h>
 #include <asm/kdebug.h>
  
-int profile_timer_exceptions_notify(struct notifier_block *self,
-				unsigned long val, void *data)
+static int profile_timer_exceptions_notify(struct notifier_block *self,
+					   unsigned long val, void *data)
 {
 	struct die_args *args = (struct die_args *)data;
 	int ret = NOTIFY_DONE;

Re: 2.6.17-rc4-mm1

[Jean Delvare]

Michal Piotrowski reported:
> > When I try to "modprobe -r i2c_i801" modprobe hangs

Quoting myself:
> I can reproduce it, with both i2c-i801 and i2c-parport, so it's not
> related to a specific driver. I'm currently performing a bisection on
> 2.6.17-rc4-mm1 to try and isolate the culprit. It seems to point to
> gregkh-driver-*. i2c patches are innocent for sure, including Kumar's
> ones.

And the winner is...
gregkh-driver-driver-core-class_device_add-needs-error-checks.patch

Stephen, Greg?

-- 
Jean Delvare

Re: 2.6.17-rc4-mm1

[Stephen Hemminger]

Jean Delvare wrote:
> Michal Piotrowski reported:
>   
>>> When I try to "modprobe -r i2c_i801" modprobe hangs
>>>       
>
> Quoting myself:
>   
>> I can reproduce it, with both i2c-i801 and i2c-parport, so it's not
>> related to a specific driver. I'm currently performing a bisection on
>> 2.6.17-rc4-mm1 to try and isolate the culprit. It seems to point to
>> gregkh-driver-*. i2c patches are innocent for sure, including Kumar's
>> ones.
>>     
>
> And the winner is...
> gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
>
> Stephen, Greg?
>
>   
Look at the error return from class_device_register. I bet
it was working before because the class_device_register wasn't
checking something, now it is and that exposes a bug that has
existed in i2c since sysfs support was added.

I can make up a more verbose version if that helps

Re: 2.6.17-rc4-mm1

[Jean Delvare]

Quoting myself:
> And the winner is...
> gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> 
> Stephen, Greg?

Indeed this patch breaks class_device_add in the success case...

Andrew, maybe you want to put this in the hot-fixes directory for
2.6.17-rc1-mm4, as the problem hits all drivers which register with a
class.

Fix class_device_add success case after
gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
broke it. class_dev was no more put and class_name was no more freed
before leaving. The former caused locks on driver removal (class_dev
usage count could never be 0.)

This fix should be folded into
gregkh-driver-driver-core-class_device_add-needs-error-checks.patch

Signed-off-by: Jean Delvare <khali@linux-fr.org>
---
 drivers/base/class.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.17-rc4-mm1.orig/drivers/base/class.c	2006-05-16 16:38:02.000000000 +0200
+++ linux-2.6.17-rc4-mm1/drivers/base/class.c	2006-05-16 17:00:24.000000000 +0200
@@ -620,7 +620,7 @@
 	}
 	up(&parent_class->sem);
 
-	return 0;
+	goto out1;
 
  out8:
 	if (class_dev->dev)


-- 
Jean Delvare

[-mm patch] fs/ocfs2/dlm/: cleanups

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-ocfs2.patch
>...
>  git trees
>...


This patch #if 0's the no longer used dlm_dump_lock_resources().

Since this makes dlmdebug.h empty, this patch also removes this header.

Additionally, the needlessly global dlm_is_node_recovered() is made 
static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 fs/ocfs2/dlm/dlmdebug.c    |    4 ++--
 fs/ocfs2/dlm/dlmdebug.h    |   30 ------------------------------
 fs/ocfs2/dlm/dlmdomain.c   |    1 -
 fs/ocfs2/dlm/dlmmaster.c   |    1 -
 fs/ocfs2/dlm/dlmrecovery.c |    2 +-
 5 files changed, 3 insertions(+), 35 deletions(-)

--- linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmdebug.h	2006-03-20 06:53:29.000000000 +0100
+++ /dev/null	2006-04-23 00:42:46.000000000 +0200
@@ -1,30 +0,0 @@
-/* -*- mode: c; c-basic-offset: 8; -*-
- * vim: noexpandtab sw=8 ts=8 sts=0:
- *
- * dlmdebug.h
- *
- * Copyright (C) 2004 Oracle.  All rights reserved.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public
- * License as published by the Free Software Foundation; either
- * version 2 of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public
- * License along with this program; if not, write to the
- * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
- * Boston, MA 021110-1307, USA.
- *
- */
-
-#ifndef DLMDEBUG_H
-#define DLMDEBUG_H
-
-void dlm_dump_lock_resources(struct dlm_ctxt *dlm);
-
-#endif
--- linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmdebug.c.old	2006-05-16 13:16:46.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmdebug.c	2006-05-16 13:17:16.000000000 +0200
@@ -37,10 +37,8 @@
 
 #include "dlmapi.h"
 #include "dlmcommon.h"
-#include "dlmdebug.h"
 
 #include "dlmdomain.h"
-#include "dlmdebug.h"
 
 #define MLOG_MASK_PREFIX ML_DLM
 #include "cluster/masklog.h"
@@ -120,6 +118,7 @@
 }
 EXPORT_SYMBOL_GPL(dlm_print_one_lock);
 
+#if 0
 void dlm_dump_lock_resources(struct dlm_ctxt *dlm)
 {
 	struct dlm_lock_resource *res;
@@ -142,6 +141,7 @@
 	}
 	spin_unlock(&dlm->spinlock);
 }
+#endif  /*  0  */
 
 static const char *dlm_errnames[] = {
 	[DLM_NORMAL] =			"DLM_NORMAL",
--- linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmdomain.c.old	2006-05-16 13:17:25.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmdomain.c	2006-05-16 13:17:28.000000000 +0200
@@ -41,7 +41,6 @@
 #include "dlmapi.h"
 #include "dlmcommon.h"
 
-#include "dlmdebug.h"
 #include "dlmdomain.h"
 
 #include "dlmver.h"
--- linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmmaster.c.old	2006-05-16 13:17:36.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmmaster.c	2006-05-16 13:17:39.000000000 +0200
@@ -47,7 +47,6 @@
 
 #include "dlmapi.h"
 #include "dlmcommon.h"
-#include "dlmdebug.h"
 #include "dlmdomain.h"
 
 #define MLOG_MASK_PREFIX (ML_DLM|ML_DLM_MASTER)
--- linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmrecovery.c.old	2006-05-16 13:18:14.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/fs/ocfs2/dlm/dlmrecovery.c	2006-05-16 13:18:22.000000000 +0200
@@ -357,7 +357,7 @@
 
 /* returns true if node is no longer in the domain
  * could be dead or just not joined */
-int dlm_is_node_recovered(struct dlm_ctxt *dlm, u8 node)
+static int dlm_is_node_recovered(struct dlm_ctxt *dlm, u8 node)
 {
 	int recovered;
 	spin_lock(&dlm->spinlock);

[-mm patch] drivers/net/s2io.c: make bus_speed[] static

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
>  git-netdev-all.patch
>...
>  git trees
>...


This patch makes the needlessly global bus_speed[] static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-rc4-mm1-full/drivers/net/s2io.c.old	2006-05-16 13:06:58.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/net/s2io.c	2006-05-16 13:07:08.000000000 +0200
@@ -852,7 +852,7 @@
 	return 0;
 }
 
-int bus_speed[8] = {33, 133, 133, 200, 266, 133, 200, 266};
+static int bus_speed[8] = {33, 133, 133, 200, 266, 133, 200, 266};
 /**
  * s2io_print_pci_mode -
  */

Re: [-mm patch] drivers/net/s2io.c: make bus_speed[] static

[Andreas Mohr]

Hi,

On Tue, May 16, 2006 at 05:30:50PM +0200, Adrian Bunk wrote:
> This patch makes the needlessly global bus_speed[] static.

Is there a reason why you don't also constify it while you are at it?
Or is it because you want to do a series of static-only patches for now?

Andreas Mohr

Re: 2.6.17-rc4-mm1

[Greg KH]

On Tue, May 16, 2006 at 05:23:46PM +0200, Jean Delvare wrote:
> Quoting myself:
> > And the winner is...
> > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > 
> > Stephen, Greg?
> 
> Indeed this patch breaks class_device_add in the success case...
> 
> Andrew, maybe you want to put this in the hot-fixes directory for
> 2.6.17-rc1-mm4, as the problem hits all drivers which register with a
> class.
> 
> Fix class_device_add success case after
> gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> broke it. class_dev was no more put and class_name was no more freed
> before leaving. The former caused locks on driver removal (class_dev
> usage count could never be 0.)
> 
> This fix should be folded into
> gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> 
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> ---
>  drivers/base/class.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-2.6.17-rc4-mm1.orig/drivers/base/class.c	2006-05-16 16:38:02.000000000 +0200
> +++ linux-2.6.17-rc4-mm1/drivers/base/class.c	2006-05-16 17:00:24.000000000 +0200
> @@ -620,7 +620,7 @@
>  	}
>  	up(&parent_class->sem);
>  
> -	return 0;
> +	goto out1;
>  

Thanks for catching this.  I've merged this with Stephen's original
patch.

thanks again,

greg k-h

2.6.17-rc4-mm1: please drop add-raw-driver-kconfig-entry-for-s390.patch

[Adrian Bunk]

On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc3-mm1:
>...
> +add-raw-driver-kconfig-entry-for-s390.patch
> 
>  Enable raw driver on s390

Since it seems the NAK's of Christoph and Martin weren't enough:
  NAK++

How many more NAK's does it require to prevent offering a deprecated 
option on additional architectures?

This driver is declared obsolete since more than two years, and while 
it's worth a discussion how long to keep it for legacy users, merging a 
patch offering an obsolete driver for even more users is silly.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.17-rc4-mm1

[Stephen Hemminger]

On Tue, 16 May 2006 09:08:42 -0700
Greg KH <gregkh@suse.de> wrote:

> On Tue, May 16, 2006 at 05:23:46PM +0200, Jean Delvare wrote:
> > Quoting myself:
> > > And the winner is...
> > > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > > 
> > > Stephen, Greg?
> > 
> > Indeed this patch breaks class_device_add in the success case...
> > 
> > Andrew, maybe you want to put this in the hot-fixes directory for
> > 2.6.17-rc1-mm4, as the problem hits all drivers which register with a
> > class.
> > 
> > Fix class_device_add success case after
> > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > broke it. class_dev was no more put and class_name was no more freed
> > before leaving. The former caused locks on driver removal (class_dev
> > usage count could never be 0.)
> > 
> > This fix should be folded into
> > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > 
> > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> > ---
> >  drivers/base/class.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- linux-2.6.17-rc4-mm1.orig/drivers/base/class.c	2006-05-16 16:38:02.000000000 +0200
> > +++ linux-2.6.17-rc4-mm1/drivers/base/class.c	2006-05-16 17:00:24.000000000 +0200
> > @@ -620,7 +620,7 @@
> >  	}
> >  	up(&parent_class->sem);
> >  
> > -	return 0;
> > +	goto out1;
> >  
> 
> Thanks for catching this.  I've merged this with Stephen's original
> patch.
> 
> thanks again,
> 
> greg k-h

ditto, hmm, one more need for a test suite for basic driver stuff

Re: 2.6.17-rc4-mm1: please drop add-raw-driver-kconfig-entry-for-s390.patch

[Olaf Hering]

 On Tue, May 16, Adrian Bunk wrote:

> This driver is declared obsolete since more than two years, and while 
> it's worth a discussion how long to keep it for legacy users, merging a 
> patch offering an obsolete driver for even more users is silly.

If it is so deprecated, just drop it for 2.6.17. I mean, no major distro
that counts will be based on 2.6.17, so noone will miss it from now on.
nails with heads and stuff...

Re: [-mm patch] drivers/net/s2io.c: make bus_speed[] static

[Adrian Bunk]

On Tue, May 16, 2006 at 05:36:11PM +0200, Andreas Mohr wrote:
> Hi,
> 
> On Tue, May 16, 2006 at 05:30:50PM +0200, Adrian Bunk wrote:
> > This patch makes the needlessly global bus_speed[] static.
> 
> Is there a reason why you don't also constify it while you are at it?
> Or is it because you want to do a series of static-only patches for now?

The latter.

Feel free to send a patch that also makes it const.

> Andreas Mohr

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.17-rc4-mm1

[Greg KH]

On Tue, May 16, 2006 at 09:27:02AM -0700, Stephen Hemminger wrote:
> On Tue, 16 May 2006 09:08:42 -0700
> Greg KH <gregkh@suse.de> wrote:
> 
> > On Tue, May 16, 2006 at 05:23:46PM +0200, Jean Delvare wrote:
> > > Quoting myself:
> > > > And the winner is...
> > > > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > > > 
> > > > Stephen, Greg?
> > > 
> > > Indeed this patch breaks class_device_add in the success case...
> > > 
> > > Andrew, maybe you want to put this in the hot-fixes directory for
> > > 2.6.17-rc1-mm4, as the problem hits all drivers which register with a
> > > class.
> > > 
> > > Fix class_device_add success case after
> > > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > > broke it. class_dev was no more put and class_name was no more freed
> > > before leaving. The former caused locks on driver removal (class_dev
> > > usage count could never be 0.)
> > > 
> > > This fix should be folded into
> > > gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
> > > 
> > > Signed-off-by: Jean Delvare <khali@linux-fr.org>
> > > ---
> > >  drivers/base/class.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > --- linux-2.6.17-rc4-mm1.orig/drivers/base/class.c	2006-05-16 16:38:02.000000000 +0200
> > > +++ linux-2.6.17-rc4-mm1/drivers/base/class.c	2006-05-16 17:00:24.000000000 +0200
> > > @@ -620,7 +620,7 @@
> > >  	}
> > >  	up(&parent_class->sem);
> > >  
> > > -	return 0;
> > > +	goto out1;
> > >  
> > 
> > Thanks for catching this.  I've merged this with Stephen's original
> > patch.
> > 
> > thanks again,
> > 
> > greg k-h
> 
> ditto, hmm, one more need for a test suite for basic driver stuff

If you know of some way to create one, I would be glad to have it...

thanks,

greg k-h

[2.6 patch] the overdue removal of the obsolete raw driver

[Adrian Bunk]

On Tue, May 16, 2006 at 06:37:26PM +0200, Olaf Hering wrote:
>  On Tue, May 16, Adrian Bunk wrote:
> 
> > This driver is declared obsolete since more than two years, and while 
> > it's worth a discussion how long to keep it for legacy users, merging a 
> > patch offering an obsolete driver for even more users is silly.
> 
> If it is so deprecated, just drop it for 2.6.17. I mean, no major distro
> that counts will be based on 2.6.17, so noone will miss it from now on.
> nails with heads and stuff...

Although I fear it will still not be accepted due to legacy users,
I've attached it below.

cu
Adrian


<--  snip  -->


This patch contains the overdue removal of the obsolete raw driver.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 19 Jan 2006

 Documentation/feature-removal-schedule.txt |    8 
 drivers/char/Kconfig                       |   20 -
 drivers/char/Makefile                      |    1 
 drivers/char/mem.c                         |    1 
 drivers/char/raw.c                         |  343 ---------------------
 fs/compat_ioctl.c                          |   69 ----
 include/linux/compat_ioctl.h               |    3 
 include/linux/raw.h                        |   18 -
 8 files changed, 463 deletions(-)

--- linux-2.6.16-rc1-mm1-full/Documentation/feature-removal-schedule.txt.old	2006-01-19 03:29:57.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/Documentation/feature-removal-schedule.txt	2006-01-19 03:30:03.000000000 +0100
@@ -20,8 +19,0 @@
-What:	RAW driver (CONFIG_RAW_DRIVER)
-When:	December 2005
-Why:	declared obsolete since kernel 2.6.3
-	O_DIRECT can be used instead
-Who:	Adrian Bunk <bunk@stusta.de>
-
----------------------------
-
--- linux-2.6.16-rc1-mm1-full/drivers/char/Kconfig.old	2006-01-19 03:30:43.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/drivers/char/Kconfig	2006-01-19 03:31:11.000000000 +0100
@@ -939,26 +939,6 @@
 	tristate "NEC VR4100 series General-purpose I/O Unit support"
 	depends on CPU_VR41XX
 
-config RAW_DRIVER
-	tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
-	help
-	  The raw driver permits block devices to be bound to /dev/raw/rawN. 
-	  Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O. 
-	  See the raw(8) manpage for more details.
-
-          The raw driver is deprecated and will be removed soon.
-          Applications should simply open the device (eg /dev/hda1)
-          with the O_DIRECT flag.
-
-config MAX_RAW_DEVS
-	int "Maximum number of RAW devices to support (1-8192)"
-	depends on RAW_DRIVER
-	default "256"
-	help
-	  The maximum number of RAW devices that are supported.
-	  Default is 256. Increase this number in case you need lots of
-	  raw devices.
-
 config HPET
 	bool "HPET - High Precision Event Timer" if (X86 || IA64)
 	default n
--- linux-2.6.16-rc1-mm1-full/drivers/char/Makefile.old	2006-01-19 03:32:11.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/drivers/char/Makefile	2006-01-19 03:32:16.000000000 +0100
@@ -42,3 +42,2 @@
-obj-$(CONFIG_RAW_DRIVER)	+= raw.o
 obj-$(CONFIG_SGI_SNSC)		+= snsc.o snsc_event.o
 obj-$(CONFIG_MMTIMER)		+= mmtimer.o
--- linux-2.6.16-rc1-mm1-full/drivers/char/mem.c.old	2006-01-19 03:32:41.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/drivers/char/mem.c	2006-01-19 03:32:50.000000000 +0100
@@ -16,7 +16,6 @@
 #include <linux/mman.h>
 #include <linux/random.h>
 #include <linux/init.h>
-#include <linux/raw.h>
 #include <linux/tty.h>
 #include <linux/capability.h>
 #include <linux/smp_lock.h>
--- linux-2.6.16-rc1-mm1-full/include/linux/compat_ioctl.h.old	2006-01-19 03:34:12.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/include/linux/compat_ioctl.h	2006-01-19 03:34:17.000000000 +0100
@@ -568,9 +568,6 @@
 COMPATIBLE_IOCTL(DEVFSDIOC_SET_EVENT_MASK)
 COMPATIBLE_IOCTL(DEVFSDIOC_RELEASE_EVENT_QUEUE)
 COMPATIBLE_IOCTL(DEVFSDIOC_SET_DEBUG_MASK)
-/* Raw devices */
-COMPATIBLE_IOCTL(RAW_SETBIND)
-COMPATIBLE_IOCTL(RAW_GETBIND)
 /* SMB ioctls which do not need any translations */
 COMPATIBLE_IOCTL(SMB_IOC_NEWCONN)
 /* NCP ioctls which do not need any translations */
--- linux-2.6.16-rc1-mm1-full/fs/compat_ioctl.c.old	2006-01-19 03:32:58.000000000 +0100
+++ linux-2.6.16-rc1-mm1-full/fs/compat_ioctl.c	2006-01-19 03:33:25.000000000 +0100
@@ -53,7 +53,6 @@
 #include <linux/ext3_fs.h>
 #include <linux/videodev.h>
 #include <linux/netdevice.h>
-#include <linux/raw.h>
 #include <linux/smb_fs.h>
 #include <linux/blkpg.h>
 #include <linux/blkdev.h>
@@ -2141,71 +2140,6 @@
         return sys_ioctl(fd,cmd,ptr);
 }
 
-struct raw32_config_request
-{
-        compat_int_t    raw_minor;
-        __u64   block_major;
-        __u64   block_minor;
-} __attribute__((packed));
-
-static int get_raw32_request(struct raw_config_request *req, struct raw32_config_request __user *user_req)
-{
-        int ret;
-
-        if (!access_ok(VERIFY_READ, user_req, sizeof(struct raw32_config_request)))
-                return -EFAULT;
-
-        ret = __get_user(req->raw_minor, &user_req->raw_minor);
-        ret |= __get_user(req->block_major, &user_req->block_major);
-        ret |= __get_user(req->block_minor, &user_req->block_minor);
-
-        return ret ? -EFAULT : 0;
-}
-
-static int set_raw32_request(struct raw_config_request *req, struct raw32_config_request __user *user_req)
-{
-	int ret;
-
-        if (!access_ok(VERIFY_WRITE, user_req, sizeof(struct raw32_config_request)))
-                return -EFAULT;
-
-        ret = __put_user(req->raw_minor, &user_req->raw_minor);
-        ret |= __put_user(req->block_major, &user_req->block_major);
-        ret |= __put_user(req->block_minor, &user_req->block_minor);
-
-        return ret ? -EFAULT : 0;
-}
-
-static int raw_ioctl(unsigned fd, unsigned cmd, unsigned long arg)
-{
-        int ret;
-
-        switch (cmd) {
-        case RAW_SETBIND:
-        case RAW_GETBIND: {
-                struct raw_config_request req;
-                struct raw32_config_request __user *user_req = compat_ptr(arg);
-                mm_segment_t oldfs = get_fs();
-
-                if ((ret = get_raw32_request(&req, user_req)))
-                        return ret;
-
-                set_fs(KERNEL_DS);
-                ret = sys_ioctl(fd,cmd,(unsigned long)&req);
-                set_fs(oldfs);
-
-                if ((!ret) && (cmd == RAW_GETBIND)) {
-                        ret = set_raw32_request(&req, user_req);
-                }
-                break;
-        }
-        default:
-                ret = sys_ioctl(fd, cmd, arg);
-                break;
-        }
-        return ret;
-}
-
 struct serial_struct32 {
         compat_int_t    type;
         compat_int_t    line;
@@ -2913,9 +2847,6 @@
 HANDLE_IOCTL(VFAT_IOCTL_READDIR_BOTH32, vfat_ioctl32)
 HANDLE_IOCTL(VFAT_IOCTL_READDIR_SHORT32, vfat_ioctl32)
 HANDLE_IOCTL(REISERFS_IOC_UNPACK32, reiserfs_ioctl32)
-/* Raw devices */
-HANDLE_IOCTL(RAW_SETBIND, raw_ioctl)
-HANDLE_IOCTL(RAW_GETBIND, raw_ioctl)
 /* Serial */
 HANDLE_IOCTL(TIOCGSERIAL, serial_struct_ioctl)
 HANDLE_IOCTL(TIOCSSERIAL, serial_struct_ioctl)
--- linux-2.6.16-rc1-mm1-full/include/linux/raw.h	2006-01-03 04:21:10.000000000 +0100
+++ /dev/null	2005-11-08 19:07:57.000000000 +0100
@@ -1,18 +0,0 @@
-#ifndef __LINUX_RAW_H
-#define __LINUX_RAW_H
-
-#include <linux/types.h>
-
-#define RAW_SETBIND	_IO( 0xac, 0 )
-#define RAW_GETBIND	_IO( 0xac, 1 )
-
-struct raw_config_request 
-{
-	int	raw_minor;
-	__u64	block_major;
-	__u64	block_minor;
-};
-
-#define MAX_RAW_MINORS CONFIG_MAX_RAW_DEVS
-
-#endif /* __LINUX_RAW_H */
--- linux-2.6.16-rc1-mm1-full/drivers/char/raw.c	2006-01-18 20:21:53.000000000 +0100
+++ /dev/null	2005-11-08 19:07:57.000000000 +0100
@@ -1,343 +0,0 @@
-/*
- * linux/drivers/char/raw.c
- *
- * Front-end raw character devices.  These can be bound to any block
- * devices to provide genuine Unix raw character device semantics.
- *
- * We reserve minor number 0 for a control interface.  ioctl()s on this
- * device are used to bind the other minor numbers to block devices.
- */
-
-#include <linux/init.h>
-#include <linux/fs.h>
-#include <linux/devfs_fs_kernel.h>
-#include <linux/major.h>
-#include <linux/blkdev.h>
-#include <linux/module.h>
-#include <linux/raw.h>
-#include <linux/capability.h>
-#include <linux/uio.h>
-#include <linux/cdev.h>
-#include <linux/device.h>
-#include <linux/mutex.h>
-
-#include <asm/uaccess.h>
-
-struct raw_device_data {
-	struct block_device *binding;
-	int inuse;
-};
-
-static struct class *raw_class;
-static struct raw_device_data raw_devices[MAX_RAW_MINORS];
-static DEFINE_MUTEX(raw_mutex);
-static struct file_operations raw_ctl_fops;	     /* forward declaration */
-
-/*
- * Open/close code for raw IO.
- *
- * We just rewrite the i_mapping for the /dev/raw/rawN file descriptor to
- * point at the blockdev's address_space and set the file handle to use
- * O_DIRECT.
- *
- * Set the device's soft blocksize to the minimum possible.  This gives the
- * finest possible alignment and has no adverse impact on performance.
- */
-static int raw_open(struct inode *inode, struct file *filp)
-{
-	const int minor = iminor(inode);
-	struct block_device *bdev;
-	int err;
-
-	if (minor == 0) {	/* It is the control device */
-		filp->f_op = &raw_ctl_fops;
-		return 0;
-	}
-
-	mutex_lock(&raw_mutex);
-
-	/*
-	 * All we need to do on open is check that the device is bound.
-	 */
-	bdev = raw_devices[minor].binding;
-	err = -ENODEV;
-	if (!bdev)
-		goto out;
-	igrab(bdev->bd_inode);
-	err = blkdev_get(bdev, filp->f_mode, 0);
-	if (err)
-		goto out;
-	err = bd_claim(bdev, raw_open);
-	if (err)
-		goto out1;
-	err = set_blocksize(bdev, bdev_hardsect_size(bdev));
-	if (err)
-		goto out2;
-	filp->f_flags |= O_DIRECT;
-	filp->f_mapping = bdev->bd_inode->i_mapping;
-	if (++raw_devices[minor].inuse == 1)
-		filp->f_dentry->d_inode->i_mapping =
-			bdev->bd_inode->i_mapping;
-	filp->private_data = bdev;
-	mutex_unlock(&raw_mutex);
-	return 0;
-
-out2:
-	bd_release(bdev);
-out1:
-	blkdev_put(bdev);
-out:
-	mutex_unlock(&raw_mutex);
-	return err;
-}
-
-/*
- * When the final fd which refers to this character-special node is closed, we
- * make its ->mapping point back at its own i_data.
- */
-static int raw_release(struct inode *inode, struct file *filp)
-{
-	const int minor= iminor(inode);
-	struct block_device *bdev;
-
-	mutex_lock(&raw_mutex);
-	bdev = raw_devices[minor].binding;
-	if (--raw_devices[minor].inuse == 0) {
-		/* Here  inode->i_mapping == bdev->bd_inode->i_mapping  */
-		inode->i_mapping = &inode->i_data;
-		inode->i_mapping->backing_dev_info = &default_backing_dev_info;
-	}
-	mutex_unlock(&raw_mutex);
-
-	bd_release(bdev);
-	blkdev_put(bdev);
-	return 0;
-}
-
-/*
- * Forward ioctls to the underlying block device.
- */
-static int
-raw_ioctl(struct inode *inode, struct file *filp,
-		  unsigned int command, unsigned long arg)
-{
-	struct block_device *bdev = filp->private_data;
-
-	return blkdev_ioctl(bdev->bd_inode, NULL, command, arg);
-}
-
-static void bind_device(struct raw_config_request *rq)
-{
-	class_device_destroy(raw_class, MKDEV(RAW_MAJOR, rq->raw_minor));
-	class_device_create(raw_class, NULL, MKDEV(RAW_MAJOR, rq->raw_minor),
-				      NULL, "raw%d", rq->raw_minor);
-}
-
-/*
- * Deal with ioctls against the raw-device control interface, to bind
- * and unbind other raw devices.
- */
-static int raw_ctl_ioctl(struct inode *inode, struct file *filp,
-			unsigned int command, unsigned long arg)
-{
-	struct raw_config_request rq;
-	struct raw_device_data *rawdev;
-	int err = 0;
-
-	switch (command) {
-	case RAW_SETBIND:
-	case RAW_GETBIND:
-
-		/* First, find out which raw minor we want */
-
-		if (copy_from_user(&rq, (void __user *) arg, sizeof(rq))) {
-			err = -EFAULT;
-			goto out;
-		}
-
-		if (rq.raw_minor < 0 || rq.raw_minor >= MAX_RAW_MINORS) {
-			err = -EINVAL;
-			goto out;
-		}
-		rawdev = &raw_devices[rq.raw_minor];
-
-		if (command == RAW_SETBIND) {
-			dev_t dev;
-
-			/*
-			 * This is like making block devices, so demand the
-			 * same capability
-			 */
-			if (!capable(CAP_SYS_ADMIN)) {
-				err = -EPERM;
-				goto out;
-			}
-
-			/*
-			 * For now, we don't need to check that the underlying
-			 * block device is present or not: we can do that when
-			 * the raw device is opened.  Just check that the
-			 * major/minor numbers make sense.
-			 */
-
-			dev = MKDEV(rq.block_major, rq.block_minor);
-			if ((rq.block_major == 0 && rq.block_minor != 0) ||
-					MAJOR(dev) != rq.block_major ||
-					MINOR(dev) != rq.block_minor) {
-				err = -EINVAL;
-				goto out;
-			}
-
-			mutex_lock(&raw_mutex);
-			if (rawdev->inuse) {
-				mutex_unlock(&raw_mutex);
-				err = -EBUSY;
-				goto out;
-			}
-			if (rawdev->binding) {
-				bdput(rawdev->binding);
-				module_put(THIS_MODULE);
-			}
-			if (rq.block_major == 0 && rq.block_minor == 0) {
-				/* unbind */
-				rawdev->binding = NULL;
-				class_device_destroy(raw_class,
-						MKDEV(RAW_MAJOR, rq.raw_minor));
-			} else {
-				rawdev->binding = bdget(dev);
-				if (rawdev->binding == NULL)
-					err = -ENOMEM;
-				else {
-					__module_get(THIS_MODULE);
-					bind_device(&rq);
-				}
-			}
-			mutex_unlock(&raw_mutex);
-		} else {
-			struct block_device *bdev;
-
-			mutex_lock(&raw_mutex);
-			bdev = rawdev->binding;
-			if (bdev) {
-				rq.block_major = MAJOR(bdev->bd_dev);
-				rq.block_minor = MINOR(bdev->bd_dev);
-			} else {
-				rq.block_major = rq.block_minor = 0;
-			}
-			mutex_unlock(&raw_mutex);
-			if (copy_to_user((void __user *)arg, &rq, sizeof(rq))) {
-				err = -EFAULT;
-				goto out;
-			}
-		}
-		break;
-	default:
-		err = -EINVAL;
-		break;
-	}
-out:
-	return err;
-}
-
-static ssize_t raw_file_write(struct file *file, const char __user *buf,
-				   size_t count, loff_t *ppos)
-{
-	struct iovec local_iov = {
-		.iov_base = (char __user *)buf,
-		.iov_len = count
-	};
-
-	return generic_file_write_nolock(file, &local_iov, 1, ppos);
-}
-
-static ssize_t raw_file_aio_write(struct kiocb *iocb, const char __user *buf,
-					size_t count, loff_t pos)
-{
-	struct iovec local_iov = {
-		.iov_base = (char __user *)buf,
-		.iov_len = count
-	};
-
-	return generic_file_aio_write_nolock(iocb, &local_iov, 1, &iocb->ki_pos);
-}
-
-
-static struct file_operations raw_fops = {
-	.read	=	generic_file_read,
-	.aio_read = 	generic_file_aio_read,
-	.write	=	raw_file_write,
-	.aio_write = 	raw_file_aio_write,
-	.open	=	raw_open,
-	.release=	raw_release,
-	.ioctl	=	raw_ioctl,
-	.readv	= 	generic_file_readv,
-	.writev	= 	generic_file_writev,
-	.owner	=	THIS_MODULE,
-};
-
-static struct file_operations raw_ctl_fops = {
-	.ioctl	=	raw_ctl_ioctl,
-	.open	=	raw_open,
-	.owner	=	THIS_MODULE,
-};
-
-static struct cdev raw_cdev = {
-	.kobj	=	{.name = "raw", },
-	.owner	=	THIS_MODULE,
-};
-
-static int __init raw_init(void)
-{
-	int i;
-	dev_t dev = MKDEV(RAW_MAJOR, 0);
-
-	if (register_chrdev_region(dev, MAX_RAW_MINORS, "raw"))
-		goto error;
-
-	cdev_init(&raw_cdev, &raw_fops);
-	if (cdev_add(&raw_cdev, dev, MAX_RAW_MINORS)) {
-		kobject_put(&raw_cdev.kobj);
-		unregister_chrdev_region(dev, MAX_RAW_MINORS);
-		goto error;
-	}
-
-	raw_class = class_create(THIS_MODULE, "raw");
-	if (IS_ERR(raw_class)) {
-		printk(KERN_ERR "Error creating raw class.\n");
-		cdev_del(&raw_cdev);
-		unregister_chrdev_region(dev, MAX_RAW_MINORS);
-		goto error;
-	}
-	class_device_create(raw_class, NULL, MKDEV(RAW_MAJOR, 0), NULL, "rawctl");
-
-	devfs_mk_cdev(MKDEV(RAW_MAJOR, 0),
-		      S_IFCHR | S_IRUGO | S_IWUGO,
-		      "raw/rawctl");
-	for (i = 1; i < MAX_RAW_MINORS; i++)
-		devfs_mk_cdev(MKDEV(RAW_MAJOR, i),
-			      S_IFCHR | S_IRUGO | S_IWUGO,
-			      "raw/raw%d", i);
-	return 0;
-
-error:
-	printk(KERN_ERR "error register raw device\n");
-	return 1;
-}
-
-static void __exit raw_exit(void)
-{
-	int i;
-
-	for (i = 1; i < MAX_RAW_MINORS; i++)
-		devfs_remove("raw/raw%d", i);
-	devfs_remove("raw/rawctl");
-	devfs_remove("raw");
-	class_device_destroy(raw_class, MKDEV(RAW_MAJOR, 0));
-	class_destroy(raw_class);
-	cdev_del(&raw_cdev);
-	unregister_chrdev_region(MKDEV(RAW_MAJOR, 0), MAX_RAW_MINORS);
-}
-
-module_init(raw_init);
-module_exit(raw_exit);
-MODULE_LICENSE("GPL");

Re: [2.6 patch] the overdue removal of the obsolete raw driver

[Olaf Hering]

 On Tue, May 16, Adrian Bunk wrote:


> -When:	December 2005

Dude, you really screwed it up. ;-)

Re: [-mm patch] arch/i386/oprofile/: make functions static

[Andi Kleen]

On Tuesday 16 May 2006 15:24, Adrian Bunk wrote:
> On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc3-mm1:
> >...
> > +x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions.patch
> >...
> >  x86_64 tree updates
> >...
> 
> 
> This patch makes the following needlessly global functions static:
> - nmi_int.c: profile_exceptions_notify()
> - nmi_timer_int.c: profile_timer_exceptions_notify()

Merged. Thanks

-Andi

Re: [-mm patch] arch/i386/oprofile/: make functions static

[Andi Kleen]

On Tuesday 16 May 2006 15:24, Adrian Bunk wrote:
> On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc3-mm1:
> >...
> > +x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions.patch
> >...
> >  x86_64 tree updates
> >...
> 
> 
> This patch makes the following needlessly global functions static:
> - nmi_int.c: profile_exceptions_notify()
> - nmi_timer_int.c: profile_timer_exceptions_notify()

Applied.

-Andi

Re: [PATCH] x86 NUMA panic compile error

[Dave Jones]

On Mon, May 15, 2006 at 04:06:18PM -0700, H. Peter Anvin wrote:
 > Followup to:  <200605152111.20693.ak@suse.de>
 > By author:    Andi Kleen <ak@suse.de>
 > In newsgroup: linux.dev.kernel
 > > 
 > > > x86 is a legacy architecture now anyway, right? ;)
 > > I wish everybody would agree on that @)
 > > 
 > 
 > It's going to live on for a very long time, though.  Intel is still
 > shipping some very fast 64-bit-deficient silicon.  Once that's gone,
 > it's going to live on for decades in the embedded world.

There's also a surprising number of people still running
their shiny new x86-64's in 32 bit mode.  (I suspect because
they're reliant upon applications that aren't 64-bit clean
that for whatever reason don't run in 32-bit emulation).

I'd be surprised if any of the major distros stopped shipping
a 32-bit x86 release for several years.

		Dave

-- 
http://www.codemonkey.org.uk

Re: [PATCH] x86 NUMA panic compile error

[H. Peter Anvin]

Dave Jones wrote:
> On Mon, May 15, 2006 at 04:06:18PM -0700, H. Peter Anvin wrote:
>  > Followup to:  <200605152111.20693.ak@suse.de>
>  > By author:    Andi Kleen <ak@suse.de>
>  > In newsgroup: linux.dev.kernel
>  > > 
>  > > > x86 is a legacy architecture now anyway, right? ;)
>  > > I wish everybody would agree on that @)
>  > > 
>  > 
>  > It's going to live on for a very long time, though.  Intel is still
>  > shipping some very fast 64-bit-deficient silicon.  Once that's gone,
>  > it's going to live on for decades in the embedded world.
> 
> There's also a surprising number of people still running
> their shiny new x86-64's in 32 bit mode.  (I suspect because
> they're reliant upon applications that aren't 64-bit clean
> that for whatever reason don't run in 32-bit emulation).
> 
> I'd be surprised if any of the major distros stopped shipping
> a 32-bit x86 release for several years.
> 

Yup.  In fact, I wish Fedora had the 32-bit Firefox, at least as an option.  I keep having 
to add the 32-bit repos for that reason alone :(

	-hpa

Re: [-mm patch] fs/ocfs2/dlm/: cleanups

[Mark Fasheh]

Hi Adrian,

On Tue, May 16, 2006 at 05:26:41PM +0200, Adrian Bunk wrote:
> This patch #if 0's the no longer used dlm_dump_lock_resources().
> 
> Since this makes dlmdebug.h empty, this patch also removes this header.
> 
> Additionally, the needlessly global dlm_is_node_recovered() is made 
> static.
Yeah, that all looks good - thanks for the patch!
	--Mark

--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com

Re: 2.6.17-rc4-mm1: please drop add-raw-driver-kconfig-entry-for-s390.patch

[Alan Cox]

On Maw, 2006-05-16 at 18:12 +0200, Adrian Bunk wrote:
> Since it seems the NAK's of Christoph and Martin weren't enough:
>   NAK++

Then lets add an ACK++ as well

> This driver is declared obsolete since more than two years, and while 
> it's worth a discussion how long to keep it for legacy users, merging a 
> patch offering an obsolete driver for even more users is silly.

The real world expects a raw driver. Application authors also expect the
same functionality on all platforms. 

Also in truth you can NACK and "obsolete" the raw devices all you like,
nobody in the distribution world will drop it because it is part of
"standard" unix/linux OS functionality and has been for longer than
Linux even existed. If you want to fork Linux between "Linux the real
world", and "Linux the abstract unused by anyone perfection" that's a
fine way to ensure such a split happens.

You know the O_DIRECT stuff is better, I know the O_DIRECT stuff is
better, but so was betamax and so is a Dvorak keyboard...

I happen to like "Linux the real world OS", if I wanted to run something
more abstractly elegant then I'd download Plan 9. 

ACK

Alan

Re: [-mm patch] drivers/net/s2io.c: make bus_speed[] static

[Jeff Garzik]

Adrian Bunk wrote:
> On Mon, May 15, 2006 at 12:56:37AM -0700, Andrew Morton wrote:
>> ...
>> Changes since 2.6.17-rc3-mm1:
>> ...
>>  git-netdev-all.patch
>> ...
>>  git trees
>> ...
> 
> 
> This patch makes the needlessly global bus_speed[] static.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

applied

[-mm patch] drivers/media/video/pwc/: make code static

[Adrian Bunk]

This patch makes the following needlessly global code static:
- pwc-ctrl.c: pwc_get_leds()
- pwc_preferred_compression

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 16 May 2006

 drivers/media/video/pwc/pwc-ctrl.c |    2 +-
 drivers/media/video/pwc/pwc-if.c   |    2 +-
 drivers/media/video/pwc/pwc.h      |    2 --
 3 files changed, 2 insertions(+), 4 deletions(-)

--- linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc.h.old	2006-05-16 12:54:35.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc.h	2006-05-16 12:55:17.000000000 +0200
@@ -274,7 +274,6 @@
 #if CONFIG_PWC_DEBUG
 extern int pwc_trace;
 #endif
-extern int pwc_preferred_compression;
 extern int pwc_mbufs;
 
 /** functions in pwc-if.c */
@@ -308,7 +307,6 @@
 extern int pwc_get_saturation(struct pwc_device *pdev, int *value);
 extern int pwc_set_saturation(struct pwc_device *pdev, int value);
 extern int pwc_set_leds(struct pwc_device *pdev, int on_value, int off_value);
-extern int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value);
 extern int pwc_get_cmos_sensor(struct pwc_device *pdev, int *sensor);
 extern int pwc_restore_user(struct pwc_device *pdev);
 extern int pwc_save_user(struct pwc_device *pdev);
--- linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-ctrl.c.old	2006-05-16 12:54:49.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-ctrl.c	2006-05-16 12:54:55.000000000 +0200
@@ -925,7 +925,7 @@
 	return SendControlMsg(SET_STATUS_CTL, LED_FORMATTER, 2);
 }
 
-int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value)
+static int pwc_get_leds(struct pwc_device *pdev, int *on_value, int *off_value)
 {
 	unsigned char buf[2];
 	int ret;
--- linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-if.c.old	2006-05-16 12:55:26.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/media/video/pwc/pwc-if.c	2006-05-16 12:55:36.000000000 +0200
@@ -133,7 +133,7 @@
 #endif
 static int power_save = 0;
 static int led_on = 100, led_off = 0; /* defaults to LED that is on while in use */
-       int pwc_preferred_compression = 1; /* 0..3 = uncompressed..high */
+static int pwc_preferred_compression = 1; /* 0..3 = uncompressed..high */
 static struct {
 	int type;
 	char serial_number[30];