2.6.18-rc4-mm3

2.6.18-rc4-mm3

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/

- autofs mounting of nfs submounts remains broken.



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.

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



Changes since 2.6.18-rc4-mm2:

 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-agpgart.patch
 git-arm.patch
 git-block.patch
 git-cifs.patch
 git-cpufreq.patch
 git-drm.patch
 git-geode.patch
 git-gfs2.patch
 git-ia64.patch
 git-ieee1394.patch
 git-input.patch
 git-intelfb.patch
 git-kbuild.patch
 git-libata-all.patch
 git-lxdialog.patch
 git-mtd.patch
 git-netdev-all.patch
 git-net.patch
 git-nfs.patch
 git-ocfs2.patch
 git-parisc.patch
 git-pcmcia.patch
 git-powerpc.patch
 git-r8169.patch
 git-sas.patch
 git-s390.patch
 git-scsi-misc.patch
 git-scsi-rc-fixes.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch

 git trees

-add-imacfb-documentation-and-detection.patch
-adfs-error-message-fix.patch
-initialize-parts-of-udf-inode-earlier-in-create.patch
-fix-hrtimer-percpu-usage-typo.patch
-fix-x86_64-mm-allow-users-to-force-a-panic-on-nmi.patch
-dm-bug-oops-fix.patch
-change-panic_on_oops-message-to-fatal-exception.patch
-sys_getppid-oopses-on-debug-kernel-v2.patch
-futex_handle_fault-always-fails.patch
-fbdev-include-backlighth-only-when-__kernel__-is-defined.patch
-workqueue-remove-lock_cpu_hotplug.patch
-fuse-fix-error-case-in-fuse_readpages.patch
-asus_acpi-w3000-support.patch
-acpi-change-gfp_atomic-to-gfp_kernel-for-non-atomic.patch
-sound-pci-fm801-use-array_size-macro.patch
-emu10k1x-simplify-around-pci_register_driver.patch
-gregkh-driver-add-stable-branch-to-maintainers-file.patch
-gregkh-driver-pr_debug-should-not-be-used-in-drivers.patch
-add-__must_check-to-device-management-code.patch
-add-config_enable_must_check.patch
-v4l-dev2-handle-__must_check.patch
-drivers-base-platform-notify-needs-to-occur.patch
-sysfs-add-proper-sysfs_init-prototype.patch
-drm-build-fix.patch
-git-drm-oops-fix.patch
-i2c-build-fixes-tps65010.patch
-config_pm=n-slim-drivers-scsi-sata_sil.patch
-mtd-nand-fix-ams-delta-after-core-conversion.patch
-e100-fix-mdio-mdio-x.patch
-e100-increment-version-to-3510-k4.patch
-e1000-same-cosmetic-fix-as-earlier-sent-out-for-ipv4.patch
-e1000-remove-0x1000-as-supported-device.patch
-e1000-explicitly-power-up-the-phy-during-loopback-testing.patch
-e1000-explicit-locking-for-two-ethtool-path-functions.patch
-e1000-allow-nvm-to-setup-lplu-for-igp2-and-igp3.patch
-e1000-force-full-dma-clocking-for-10-100-speed.patch
-e1000-disable-aggressive-clocking-on-esb2-with-serdes-port.patch
-e1000-increment-driver-version-to-719-k6.patch
-ixgb-add-cx4-phy-type-detection-and-subdevice-id.patch
-ixgb-fix-cache-miss-due-to-miscalculation.patch
-ixgb-increment-version-to-10109-k4.patch
-82596-section-fixes.patch
-ac3200-section-fixes.patch
-cops-section-fix.patch
-cs89x0-section-fix.patch
-at1700-section-fix.patch
-e2100-section-fix.patch
-eepro-section-fix.patch
-eexpress-section-fix.patch
-es3210-section-fix.patch
-eth16i-section-fix.patch
-lance-section-fix.patch
-lne390-section-fix.patch
-ni52-section-fix.patch
-ibmtr-section-fix.patch
-smctr-section-fix.patch
-wd-section-fix.patch
-ni65-section-fix.patch
-seeq8005-section-fix.patch
-winbond-840-section-fix.patch
-fealnx-section-fix.patch
-sundance-section-fix.patch
-freescale-qe-ucc-gigabit-ethernet-driver.patch
-s2io-build-fix.patch
-net-add-netconsole-support-to-dm9000-driver.patch
-smc911x-re-release-spinlock-on-spurious-interrupt.patch
-via-rhine-napi-support.patch
-via-rhine-napi-poll-enable.patch
-via-rhine-add-option-avoid_d3-work-around-broken-bioses-2.patch
-lockdep-fix-smc91x.patch
-build-fixes-smc91x.patch
-add-ethtool-g-support-to-spidernet-network-driver.patch
-skge-remember-to-run-netif_poll_disable.patch
-s390-fix-arp_tbl-lock-usage-in-qeth.patch
-xircom_cb-wire-up-errors-from-pci_register_driver.patch
-pal-support-of-the-fixed-phy.patch
-fs_enet-use-pal-for-mii-management.patch
-ppc32-board-specific-part-of-fs_enet-update.patch
-velocity-remove-an-unused-function-from-the-header.patch
-net-drivers-net-via-rhinec-pci_module_init-to-pci_register_driver-conversion.patch
-lockdep-fix-sk_dst_check-deadlock.patch
-ppp-handle-kmalloc-failures.patch
-xt_physdev-build-fix.patch
-fix-potential-stack-overflow-in-net-core-utilsc.patch
-net-atm-compile-error-on-arm.patch
-tg3-convert-the-pci_device_id-table-to-pci_device.patch
-gregkh-pci-pciehp-make-pciehp-build-for-powerpc.patch
-gregkh-pci-pci-remove-dead-hotplug_pci_shpc_phprm_legacy-option.patch
-gregkh-pci-pci-use-pci_bios-as-last-fallback.patch
-pci-use-pcbios-as-last-fallback.patch
-pci-i386-mmconfig-dont-forget-bus-number-when-setting-fallback_slots-bits.patch
-pci-fix-ich6-quirks.patch
-aic7-cleanup-module_parm_desc-strings.patch
-buslogic-gcc-41-warning-fixes.patch
-scsi-limit-recursion-when-flushing-shost-starved_list.patch
-sg-nopage-page-refcounting-fix.patch
-gregkh-usb-usb-unusual_devs-entry-for-a-vox-wsx-300er-mp3-player.patch
-gregkh-usb-usb-removed-a-unbalanced-endif-from-ohci-au1xxx.c.patch
-gregkh-usb-usb-appletouch-fix-atp_disconnect.patch
-gregkh-usb-usb-additional-pid-for-sharp-w-zero3.patch
-gregkh-usb-usb-ftdi_sio-driver-new-pids.patch
-gregkh-usb-usb-usbtest.c-unsigned-retval-makes-ctrl_out-return-0-in-case-of-error.patch
-x86_64-mm-i386-kprobes-error_code.patch
-x86_64-mm-re-positioning-the-bss-segment.patch
-x86_64-wire-up-oops_enter-oops_exit.patch
-kprobes-x86_64-add-kprobe_end-macro-for-popsection.patch
-git-cryptodev-padlock-generic-build-fix.patch
-git-crypto-alignment-build-fixes.patch
-fix-up-lockdep-trace-in-fs-execc.patch
-intelfbhwc-intelfbhw_get_p1p2-defined-but-not-used.patch

 Merged into mainline or a subsystem tree.

+char-moxac-fix-endianess-and-multiple-card-issues.patch
+char-moxac-fix-endianess-and-multiple-card-issues-tidy.patch
+matroxfb-fix-jittery-display-on-non-ppc-systems.patch
+vcsa-attribute-bits-ioctlvt_gethifontmask.patch
+futex_find_get_task-remove-an-obscure-exit_zombie-check.patch
+mtd-nand-fix-ams-delta-after-core-conversion.patch
+fix-for-minix-crash.patch
+ext2-prevent-div-by-zero-on-corrupted-fs.patch
+spectrum_cs-fix-firmware-uploading-errors.patch
+ext3-filesystem-bogus-enospc-with-reservation-fix.patch
+ufs-write-to-hole-in-big-file.patch
+ufs-truncate-correction.patch
+remove-redundent-up-in-stop_machine.patch
+documentation-update-for-relay-interface.patch
+eventpollc-compile-fix.patch
+md-avoid-backward-event-updates-in-md-superblock-when-degraded.patch
+md-fix-recent-breakage-of-md-raid1-array-checking.patch
+cpuset-top_cpuset-tracks-hotplug-changes-to-cpu_online_map.patch
+manage-jbd-allocations-from-its-own-slabs.patch
+manage-jbd-allocations-from-its-own-slabs-tidy.patch
+register_one_node-compile-fix.patch
+sun-disk-label-fix-signed-int-usage-for-sector-count.patch
+sun-disk-label-fix-signed-int-usage-for-sector-count-fix.patch
+config_acpi_srat-numa-build-fix.patch
+lockdep-annotate-idescsi_pc_intr.patch
+lockdep-annotate-reiserfs.patch
+fix-up-lockdep-trace-in-fs-execc.patch
+proc-meminfo-dont-put-spaces-in-names.patch
+x86-numaq-kconfig-fix.patch
+cdrom-gdsc-fix-printk-format-warning.patch

 2.6.18 queue.

+asus_acpi-fix-proc-files-parsing.patch
+asus_acpi-dont-printk-on-writing-garbage-to-proc-files.patch

 ACPI driver fixes

+agph-constify-struct-agp_bridge_dataversion.patch

 AGP cleanup

+gregkh-driver-add-__must_check-to-device-management-code.patch
+gregkh-driver-add-config_enable_must_check.patch
+gregkh-driver-v4l-dev2-handle-__must_check.patch
+gregkh-driver-drivers-base-platform-notify-needs-to-occur-before-drivers-attach-to-the-device.patch
+gregkh-driver-drivers-base-check-errors.patch
+gregkh-driver-sysfs-add-proper-sysfs_init-prototype.patch
+gregkh-driver-nozomi.patch

 driver tree updates

-drm-minor-fixes.patch

 Dropped.

+ks0127-wire-up-i2c_add_driver-return-value.patch
+drivers-media-video-bt866c-array-overflows.patch

 DVB updates

+gregkh-i2c-i2c-tps65010-build-fixes.patch
+gregkh-i2c-hwmon-abituguru-timeout-fixes.patch
+gregkh-i2c-i2c-__must_check-fixes.patch
+gregkh-i2c-i2c-__must_check-fixes-i2c-dev.patch
+gregkh-i2c-i2c-algo-sibyte-cleanups.patch
+gregkh-i2c-i2c-algo-sibyte-merge-in-i2c-sibyte.patch
+gregkh-i2c-i2c-sibyte-drop-kip-walker-address.patch
+gregkh-i2c-i2c-au1550-fix-timeout-problem.patch
+gregkh-i2c-i2c-au1550-add-smbus-functionality-flag.patch
+gregkh-i2c-i2c-au1550-add-au1200-support.patch
+gregkh-i2c-i2c-fix-copy-n-paste-in-subsystem-Kconfig.patch
+gregkh-i2c-i2c-matroxfb-c99-struct-init.patch
+gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
+gregkh-i2c-i2c-bus-driver-for-TI-OMAP-boards.patch
+gregkh-i2c-i2c-isa-plan-for-removal.patch
+gregkh-i2c-i2c-stub-add-chip_addr-param.patch

 I2C tree updates

+input-i8042-get-rid-of-polling-timer.patch

 Yet another attempt at this input layer cleanup.

+git-intelfb-fixup.patch

 Fix rejects in git-intelfb.patch

+libata-add-40pin-short-cable-support-honour-drive.patch

 ATA fix

-1-of-2-jmicron-driver-hard_port_no-fix.patch

 Folded into 1-of-2-jmicron-driver.patch

+1-of-2-jmicron-driver-fix.patch

 Fix it.

+via-pata-controller-xfer-fixes-fix.patch

 Fix via-pata-controller-xfer-fixes.patch

+e1000-e1000_probe-resources-cleanup.patch

 net driver cleanup

+signedness-issue-in-drivers-net-phy-phy_devicec.patch
+b44-fix-eeprom-endianess-issue.patch
+forcedeth-decouple-vlan-and-rx-checksum-dependency.patch

 net driver fixes.

+git-net-fixup.patch

 Fix rejects in git-net.patch

+atm-he-fix-section-mismatch.patch

 ATM driver section fix.

+git-nfs-fixup.patch

 Fix rejects in git-nfs.patch

+drivers-net-pcmcia-xirc2ps_csc-remove-unused-label.patch

 PCMCIA driver cleanup.

+gregkh-pci-pci-use-pcbios-as-last-fallback.patch
+gregkh-pci-pci-i386-mmconfig-don-t-forget-bus-number-when-setting-fallback_slots-bits.patch
+gregkh-pci-pci-fix-ich6-quirks.patch
+gregkh-pci-cpci-hotplug-fix-resource-assignment.patch
+gregkh-pci-pci-kerneldoc-correction-in-pci-driver.patch

 PCI tree updates

-revert-gregkh-pci-pci-use-pci_bios-as-last-fallback.patch

 Unneeded (hopefully)

+pci-add-ich7-8-acpi-gpio-io-resource-quirks.patch

 More PCI quirks.

+signedness-issue-in-drivers-scsi-iprc.patch
+signedness-issue-in-drivers-scsi-osstc.patch

 SCSI driver fixlets.

-git-scsi-target-ibmvscsi-build-fix.patch

 Unneeded

+gregkh-usb-usb-pl2303-removed-support-for-oti-s-dku-5-clone-cable.patch
+gregkh-usb-unusual_devs-update-for-ucr-61s2b.patch
+gregkh-usb-uhci-increase-resume-detect-off-delay.patch
+gregkh-usb-usbcore-make-hcd_endpoint_disable-wait-for-queue-to-drain.patch
+gregkh-usb-usbcore-khubd-and-busy-port-handling.patch
+gregkh-usb-usb-skeleton-small-update.patch
+gregkh-usb-usb-storage-add-rio-karma-eject-support.patch

 USB tree updates.

+gregkh-usb-usb-storage-add-rio-karma-eject-support-fix.patch

 Fix it.

+turn-usb_resume_both-into-static-inline.patch
+signedness-issue-in-drivers-usb-gadget-etherc.patch
+adutux-fix-printk-format-warnings.patch
+aircable-fix-printk-format-warnings.patch

 USB fixes.

+x86_64-mm-disable-mmconfig-e820-heuristic.patch
+x86_64-mm-remove-safe_smp_processor_id.patch
+x86_64-mm-early_ioremap-warning.patch
+x86_64-mm-pte-exec.patch
+x86_64-mm-cpa-pse-cleanup.patch
+x86_64-mm-remove-apic-version-capability.patch
+x86_64-mm-cleanup-apic-id-checking.patch
+x86_64-mm-mpparse-style.patch
+x86_64-mm-nmi-irqtrace-check.patch
+x86_64-mm-fix-head.S-warning.patch
+x86_64-mm-recover-1mb.patch
+x86_64-mm-remove-e820-fallback.patch
+x86_64-mm-optimize-hweight64-for-x86_64.patch
+x86_64-mm-reload-cs-in-head.patch
+x86_64-mm-note-section.patch
+x86_64-mm-e820-comment.patch
+x86_64-mm-spin-irqs-enabled.patch
+x86_64-mm-remove-alternative-smp.patch
+x86_64-mm-i386-remove-alternative-smp.patch
+x86_64-mm-cleanup-spinlock.patch
+x86_64-mm-dmi-mmconfig-intel-sdv.patch

 x86_64 tree updates

+mm-x86_64-mm-generic-getcpu-syscall-tweaks.patch

 Cleanup

+git-cryptodev-fixup.patch
+git-cryptodev-fixup-2.patch

 Fix rejects in git-cryptodev.patch

+adix-tree-rcu-lockless-readside-fix-3.patch
+radix-tree-cleanup-radix_tree_deref_slot-and.patch
+cleanup-radix_tree_derefreplace_slot-calling-conventions.patch

 More radix-tree work.

+standardize-pxx_page-macros-fix.patch

 Fix standardize-pxx_page-macros.patch

+zvc-scale-thresholds-depending-on-the-size-of-the-system.patch
+zvc-scale-thresholds-depending-on-the-size-of-the-system-fix.patch
+extract-the-allocpercpu-functions-from-the-slab-allocator.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-use-add_active_range-and-free_area_init_nodes-fix.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
+account-for-memmap-and-optionally-the-kernel-image-as-holes.patch
+replace-min_unmapped_ratio-by-min_unmapped_pages-in-struct-zone.patch
+zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable.patch
+zone_reclaim-dynamic-slab-reclaim.patch
+zone_reclaim-dynamic-slab-reclaim-tidy.patch

 Memory management updates

+selinux-1-3-eliminate-inode_security_set_security.patch
+selinux-2-3-change-isec-semaphore-to-a-mutex.patch
+selinux-2-3-change-isec-semaphore-to-a-mutex-vs-git-net.patch
+selinux-3-3-convert-sbsec-semaphore-to-a-mutex.patch
+selinux-fix-tty-locking.patch

 SELinux updates

+avr32-set-kbuild_defconfig.patch
+avr32-kprobes-compile-fix.patch
+avr32-asm-ioh-should-include-asm-byteorderh.patch
+avr32-fix-output-constraints-in-asm-bitopsh.patch
+avr32-standardize-pxx_page-macros-fix.patch

 Update avr32 architecture.

+x86-put-note-sections-into-a-pt_note-segment-in-vmlinux-fix.patch

 Fix x86-put-note-sections-into-a-pt_note-segment-in-vmlinux.patch

-add-force-of-use-mmconfig.patch
-add-efi-e820-memory-mapping-on-x86.patch
-fix-boot-on-efi-32-bit-machines.patch

 Dropped.

+mtrr-add-lock-annotations-for-prepare_set-and.patch
+x86-remove-default_ldt-and-simplify-ldt-setting.patch

 x86 updates.

-kill-default_ldt.patch

 Updated.

+alpha-fix-alpha_ev56-dependencies-typo.patch

 Alpha fixlet.

+xtensa-ptrace-exit_zombie-fix.patch

 xtensa fix.

+copy_process-cosmetic-ioprio-tweak.patch
+autofs4-autofs4_follow_link-false-negative-fix.patch
+autofs4-pending-flag-not-cleared-on-mount-fail.patch
+futex_find_get_task-dont-take-tasklist_lock.patch
+sys_get_robust_list-dont-take-tasklist_lock.patch
+docbook-fix-segfault-in-docprocc.patch
+solaris-emulation-incorrect-tty-locking.patch
+solaris-emulation-incorrect-tty-locking-fix.patch
+solaris-emulation-incorrect-tty-locking-fix-2.patch
+tty-fix-bits-and-note-more-bits-to-fix.patch
+windfarm_smu_satc-simplify-around-i2c_add_driver.patch
+make-spinlock-rwlock-annotations-more-accurate-by-using.patch
+replace-_spin_trylock-with-spin_trylock-in-the-irq.patch
+ext3-turn-on-reservation-dump-on-block-allocation-errors.patch
+ext3-add-more-comments-in-block-allocation-reservation-code.patch
+generic-boolean.patch
+fs-ntfs-conversion-to-generic-boolean.patch
+fs-jfs-conversion-to-generic-boolean.patch
+block_devc-mutex_lock_nested-fix.patch
+fix-mem_write-return-value.patch
+doc-fix-kernel-parameters-quiet.patch
+pass-a-lock-expression-to-__cond_lock-like-__acquire-and.patch
+cramfs-rewrite-init_cramfs_fs.patch
+freevxfs-fix-leak-on-error-path.patch
+cramfs-make-cramfs_uncompress_exit-return-void.patch
+9p-fix-leak-on-error-path.patch
+ban-register_filesystemnull.patch
+jbd-use-build_bug_on-in-journal-init.patch
+more-ext3-16t-overflow-fixes.patch
+ext3-inode-numbers-are-unsigned-long.patch
+lockdep-core-add-enable-disable_irq_irqsave-irqrestore-apis.patch
+really-ignore-kmem_cache_destroy-return-value.patch
+make-kmem_cache_destroy-return-void.patch
+set-exit_dead-state-in-do_exit-not-in-schedule.patch
+kill-pf_dead-flag.patch
+introduce-task_dead-state.patch
+fix-typo-in-rtc-kconfig.patch

 Misc.

+pass-sparse-the-lock-expression-given-to-lock-annotations.patch

 Update for new sparse features.

+ntp-add-ntp_update_frequency-fix.patch

 Fix ntp-add-ntp_update_frequency.patch

+kill-wall_jiffies.patch

 Time management cleanup.

+reiserfs-eliminate-minimum-window-size-for-bitmap-searching.patch

 reiserfs speedup/simplification.

+fs-cache-make-kafs-use-fs-cache-12-fix.patch

 Fix fs-cache-make-kafs-use-fs-cache-12.patch

+fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem-warning-fixes.patch

 Fix fs-cache-cachefiles-a-cache-that-backs-onto-a-mounted-filesystem.patch
 some more.

+hdaps-add-explicit-hardware-configuration-functions-fix-fix.patch

 Fix hdaps-add-explicit-hardware-configuration-functions.patch some more.

+generic-ioremap_page_range-x86_64-conversion-fix.patch

 Fix generic-ioremap_page_range-x86_64-conversion.patch

+support-piping-into-commands-in-proc-sys-kernel-core_pattern-fix-2.patch

 Fix support-piping-into-commands-in-proc-sys-kernel-core_pattern.patch some
 more.

+kprobes-make-kprobe-modules-more-portable.patch
+kprobes-make-kprobe-modules-more-portable-update.patch
+add-regs_return_value-helper.patch
+update-documentation-kprobestxt.patch
+update-documentation-kprobestxt-update.patch

 kprobes updates.

+knfsd-split-svc_serv-into-pools-fix.patch

 Fix knfsd-split-svc_serv-into-pools.patch

+nfsd-lockdep-annotation.patch
+knfsd-nfsd-lockdep-annotation-fix.patch
+knfsd-call-lockd_down-when-closing-a-socket-via-a-write-to-nfsd-portlist.patch
+knfsd-protect-update-to-sn_nrthreads-with-lock_kernel.patch
+knfsd-fixed-handling-of-lockd-fail-when-adding-nfsd-socket.patch
+knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one.patch
+knfsd-avoid-excess-stack-usage-in-svc_tcp_recvfrom.patch
+knfsd-prepare-knfsd-for-support-of-rsize-wsize-of-up-to-1mb-over-tcp.patch
+knfsd-allow-max-size-of-nfsd-payload-to-be-configured.patch
+knfsd-make-nfsd-readahead-params-cache-smp-friendly.patch
+knfsd-knfsd-cache-ipmap-per-tcp-socket.patch

 NFSD updates.

+zvc-support-nr_slab_reclaimable--nr_slab_unreclaimable-swap_prefetch.patch

 Update swap prefetch for mm changes.

+ecryptfs-mntput-lower-mount-on-umount_begin.patch
+vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers-ecryptfs.patch
+make-kmem_cache_destroy-return-void-ecryptfs.patch

 ecryptfs updates

-namespaces-add-nsproxy-dont-include-compileh.patch
+namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
-namespaces-utsname-switch-to-using-uts-namespaces-uml-fix.patch
-namespaces-utsname-use-init_utsname-when-appropriate-gmidi.patch
-namespaces-utsname-use-init_utsname-when-appropriate-print_kernel_version.patch
-namespaces-utsname-sysctl-hack-fix.patch

 namespace patch consolidation.

+make-kmem_cache_destroy-return-void-reiser4.patch

 Fix reiser4 for other -mm patches.

+atyfb-possible-cleanups.patch
+mbxfb-fix-a-chip-bug-resulting-in-wrong-pixclock.patch
+mbxfb-fix-framebuffer-size-smaller-than-requested.patch
+fbcon-make-3-functions-static.patch
+vt-proper-prototypes-for-some-console-functions.patch
+sstfb-clean-ups.patch

 fbdev updates.

+md-fix-issues-with-referencing-rdev-in-md-raid1.patch
+md-new-sysfs-interface-for-setting-bits-in-the-write-intent-bitmap.patch
+md-remove-unnecessary-variable-x-in-stripe_to_pdidx.patch

 MD updates

+srcu-3-rcu-variant-permitting-read-side-blocking-srcu-add-lock-annotations.patch

 Add lock annotation to SRCU.

+rcu-add-fake-writers-to-rcutorture-tidy.patch

 Clean up rcu-add-fake-writers-to-rcutorture.patch

+acpi_format_exception-debug.patch

 ACPI debugging.



All 1658 patches:

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

2.6.18-rc4-mm3: ROOT_NFS=y compile error

[Adrian Bunk]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
>  git-nfs.patch
>...
>  git trees
>...

This breaks CONFIG_ROOT_NFS=y:

<--  snip  -->

...
  CC      fs/nfs/mount_clnt.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c: In function ‘mnt_create’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: error: implicit declaration of function ‘xprt_create_proto’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: warning: assignment makes pointer from integer without a cast
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:86: error: implicit declaration of function ‘rpc_create_client’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:88: warning: assignment makes pointer from integer without a cast
make[3]: *** [fs/nfs/mount_clnt.o] Error 1

<--  snip  -->

cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

[-mm patch] drivers/i2c/busses/scx200_i2c.c: update struct scx200_i2c_data

[Adrian Bunk]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
>...
>  I2C tree updates
>...

drivers/i2c/busses/scx200_i2c.c was forgotten:

<--  snip  -->

...
  CC      drivers/i2c/busses/scx200_i2c.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: excess elements in struct initializer
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: (near initialization for ‘scx200_i2c_data’)
...

<--  snip  -->

While fixing it, I also converted the struct to C99 initializers.

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

--- linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c.old	2006-08-27 03:57:50.000000000 +0200
+++ linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c	2006-08-27 03:51:50.000000000 +0200
@@ -71,12 +71,12 @@
  */
 
 static struct i2c_algo_bit_data scx200_i2c_data = {
-	NULL,
-	scx200_i2c_setsda,
-	scx200_i2c_setscl,
-	scx200_i2c_getsda,
-	scx200_i2c_getscl,
-	10, 10, 100,		/* waits, timeout */
+	.setsda		= scx200_i2c_setsda,
+	.setscl		= scx200_i2c_setscl,
+	.getsda		= scx200_i2c_getsda,
+	.getscl		= scx200_i2c_getscl,
+	.udelay		= 10,
+	.timeout	= 100,
 };
 
 static struct i2c_adapter scx200_i2c_ops = {

2.6.18-rc4-mm3: NF_CONNTRACK_FTP=y compile error

[Adrian Bunk]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
>  git-net.patch
>...
>  git trees
>...

<--  snip  -->

...
  CC      net/netfilter/nf_conntrack_ftp.o
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c: In function ‘get_ipv6_addr’:
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: warning: implicit declaration of function ‘in6_pton’
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: ‘end’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: for each function it appears in.)
make[3]: *** [net/netfilter/nf_conntrack_ftp.o] Error 1

<--  snip  -->
 
cu
Adrian

-- 

    Gentoo kernels are 42 times more popular than SUSE kernels among
    KLive users  (a service by SUSE contractor Andrea Arcangeli that
    gathers data about kernels from many users worldwide).

       There are three kinds of lies: Lies, Damn Lies, and Statistics.
                                                    Benjamin Disraeli

[-mm patch] struct i2c_algo_pcf_data: remove the mdelay member

[Adrian Bunk]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
> +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
>...
>  I2C tree updates
>...

This patch also removes the only usage of the mdelay member in 
struct i2c_algo_pcf_data, but doesn't remove the struct member itself.

Is seems this patch was also intended?

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

--- linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h.old	2006-08-27 04:01:35.000000000 +0200
+++ linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h	2006-08-27 04:01:40.000000000 +0200
@@ -35,7 +35,6 @@ struct i2c_algo_pcf_data {
 
 	/* local settings */
 	int udelay;
-	int mdelay;
 	int timeout;
 };
 

Re: 2.6.18-rc4-mm3: NF_CONNTRACK_FTP=y compile error

[David Miller]

From: Adrian Bunk <bunk@stusta.de>
Date: Sun, 27 Aug 2006 04:42:19 +0200

>   CC      net/netfilter/nf_conntrack_ftp.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c: In function ^[$,1rx^[(Bget_ipv6_addr^[$,1ry^[(B:
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: warning: implicit declaration of function ^[$,1rx^[(Bin6_pton^[$,1ry^[(B
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: ^[$,1rx^[(Bend^[$,1ry^[(B undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/net/netfilter/nf_conntrack_ftp.c:117: error: for each function it appears in.)
> make[3]: *** [net/netfilter/nf_conntrack_ftp.o] Error 1

So the one single place where we call this new in6_pton() thing,
it doesn't even compile.

Yoshifuji, what tree are you testing your builds against?  This
is the second build failure introduced by this in6_pton()
changeset.

I'm going to butcher it like this so at least it builds.

commit 32677088bc145cf7d45466e39286f1a8c7bf2d67
Author: David S. Miller <davem@sunset.davemloft.net>
Date:   Sat Aug 26 19:48:49 2006 -0700

    [NETFILTER]: Fix nf_conntrack_ftp.c build.
    
    Noticed by Adrian Bunk.
    
    Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c
index 9dccb40..0c17a5b 100644
--- a/net/netfilter/nf_conntrack_ftp.c
+++ b/net/netfilter/nf_conntrack_ftp.c
@@ -21,6 +21,7 @@ #include <linux/netfilter.h>
 #include <linux/ip.h>
 #include <linux/ipv6.h>
 #include <linux/ctype.h>
+#include <linux/inet.h>
 #include <net/checksum.h>
 #include <net/tcp.h>
 
@@ -114,7 +115,8 @@ static struct ftp_search {
 static int
 get_ipv6_addr(const char *src, size_t dlen, struct in6_addr *dst, u_int8_t term)
 {
-	int ret = in6_pton(src, min_t(size_t, dlen, 0xffff), dst, term, &end);
+	const char *end;
+	int ret = in6_pton(src, min_t(size_t, dlen, 0xffff), (u8 *)dst, term, &end);
 	if (ret > 0)
 		return (int)(end - src);
 	return 0;

Re: [-mm patch] drivers/i2c/busses/scx200_i2c.c: update struct scx200_i2c_data

[Jean Delvare]

Hi Adrian,

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> > +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
> >...
> >  I2C tree updates
> >...
> 
> drivers/i2c/busses/scx200_i2c.c was forgotten:
> 
> <--  snip  -->
> 
> ...
>   CC      drivers/i2c/busses/scx200_i2c.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: excess elements in struct initializer
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c:79: warning: (near initialization for ‘scx200_i2c_data’)
> ...
> 
> <--  snip  -->
> 
> While fixing it, I also converted the struct to C99 initializers.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c.old	2006-08-27 03:57:50.000000000 +0200
> +++ linux-2.6.18-rc4-mm3/drivers/i2c/busses/scx200_i2c.c	2006-08-27 03:51:50.000000000 +0200
> @@ -71,12 +71,12 @@
>   */
>  
>  static struct i2c_algo_bit_data scx200_i2c_data = {
> -	NULL,
> -	scx200_i2c_setsda,
> -	scx200_i2c_setscl,
> -	scx200_i2c_getsda,
> -	scx200_i2c_getscl,
> -	10, 10, 100,		/* waits, timeout */
> +	.setsda		= scx200_i2c_setsda,
> +	.setscl		= scx200_i2c_setscl,
> +	.getsda		= scx200_i2c_getsda,
> +	.getscl		= scx200_i2c_getscl,
> +	.udelay		= 10,
> +	.timeout	= 100,
>  };
>  
>  static struct i2c_adapter scx200_i2c_ops = {

Good catch, thanks for fixing that. I tried to catch and fix all users
when dropping mdelay from struct i2c_algo_bit_data, but obviously I
missed this one.

Patch applied.

-- 
Jean Delvare

Re: [-mm patch] struct i2c_algo_pcf_data: remove the mdelay member

[Jean Delvare]

Hi Adrian,

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> > +gregkh-i2c-i2c-algo-bit-kill-mdelay.patch
> >...
> >  I2C tree updates
> >...
> 
> This patch also removes the only usage of the mdelay member in 
> struct i2c_algo_pcf_data, but doesn't remove the struct member itself.
> 
> Is seems this patch was also intended?
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h.old	2006-08-27 04:01:35.000000000 +0200
> +++ linux-2.6.18-rc4-mm3/include/linux/i2c-algo-pcf.h	2006-08-27 04:01:40.000000000 +0200
> @@ -35,7 +35,6 @@ struct i2c_algo_pcf_data {
>  
>  	/* local settings */
>  	int udelay;
> -	int mdelay;
>  	int timeout;
>  };

I removed mdelay from i2c-elektor thinking that it was using
i2c-algo-bit, I didn't realize it was using a different i2c algorithm.
And I didn't know i2c-algo-pcf also had an unused mdelay.

I will send an updated i2c-algo-bit-kill-mdelay.patch to Greg which
doesn't affect i2c-elektor. Then we can stack a second patch doing the
same for i2c-algo-pcf, which will include your change above, and my
change to i2c-elektor.

I agree it doesn't matter much, in the end we end up removing
everything and it was dead code anyway, but let's still have clean
separate patches doing just one thing at a time.

I just found that i2c-algo-ite has the same unused mdelay member in its
algorithm data structure... But I wouldn't bother cleaning it up, given
that it is planed for removal next month anyway.

Thanks,
-- 
Jean Delvare

Re: 2.6.18-rc4-mm3

[Benoit Boissinot]

On 8/27/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>
> Changes since 2.6.18-rc4-mm2:
>
>  git-net.patch

It introduces a new warning for me:
net/netfilter/xt_CONNMARK.c: In function 'target':
net/netfilter/xt_CONNMARK.c:59: warning: implicit declaration of
function 'nf_conntrack_event_cache'

The warning is due to the following .config:
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_CONNTRACK_MARK=y
# CONFIG_IP_NF_CONNTRACK_EVENTS is not set
CONFIG_IP_NF_CONNTRACK_NETLINK=m

This change was introduced by:
http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=commit;h=76e4b41009b8a2e9dd246135cf43c7fe39553aa5

Proposed solution (based on the define in
include/net/netfilter/nf_conntrack_compat.h:

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>

Index: linux/net/netfilter/xt_CONNMARK.c
===================================================================
--- linux.orig/net/netfilter/xt_CONNMARK.c
+++ linux/net/netfilter/xt_CONNMARK.c
@@ -53,7 +53,7 @@ target(struct sk_buff **pskb,
 			newmark = (*ctmark & ~markinfo->mask) | markinfo->mark;
 			if (newmark != *ctmark) {
 				*ctmark = newmark;
-#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
+#if defined(CONFIG_IP_NF_CONNTRACK) || defined(CONFIG_IP_NF_CONNTRACK_MODULE)
 				ip_conntrack_event_cache(IPCT_MARK, *pskb);
 #else
 				nf_conntrack_event_cache(IPCT_MARK, *pskb);
@@ -65,7 +65,7 @@ target(struct sk_buff **pskb,
 				  ((*pskb)->nfmark & markinfo->mask);
 			if (*ctmark != newmark) {
 				*ctmark = newmark;
-#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
+#if defined(CONFIG_IP_NF_CONNTRACK) || defined(CONFIG_IP_NF_CONNTRACK_MODULE)
 				ip_conntrack_event_cache(IPCT_MARK, *pskb);
 #else
 				nf_conntrack_event_cache(IPCT_MARK, *pskb);

Re: 2.6.18-rc4-mm3

[Benoit Boissinot]

On 8/27/06, Andrew Morton <akpm@osdl.org> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>
>  git-acpi.patch

commit f62d31ee2f2f453b07107465fea54540cab418eb broke my laptop
(pentium M, dell D600).
I can reliably get a hard lockup (no sysrq) when modprobing ehci_hcd
and uhci_hci. It works when reverting the changeset.

I can provide cpuinfo or dmesg if necessary.

regards,

Benoit

Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

[Chuck Lever]

----- Original Message ----- 
From: "Adrian Bunk" <bunk@stusta.de>
To: "Andrew Morton" <akpm@osdl.org>; "Chuck Lever" <chuck.lever@oracle.com>; 
"Trond Myklebust" <Trond.Myklebust@netapp.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Saturday, August 26, 2006 7:56 PM
Subject: 2.6.18-rc4-mm3: ROOT_NFS=y compile error


> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>>...
>> Changes since 2.6.18-rc4-mm2:
>>...
>>  git-nfs.patch
>>...
>>  git trees
>>...
>
> This breaks CONFIG_ROOT_NFS=y:
>
> <--  snip  -->
>
> ...
>  CC      fs/nfs/mount_clnt.o
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c: In 
> function ‘mnt_create’:
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: 
> error: implicit declaration of function ‘xprt_create_proto’
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: 
> warning: assignment makes pointer from integer without a cast
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:86: 
> error: implicit declaration of function ‘rpc_create_client’
> /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:88: 
> warning: assignment makes pointer from integer without a cast
> make[3]: *** [fs/nfs/mount_clnt.o] Error 1
>
> <--  snip  -->

Looks like a patch got misapplied somewhere.  All my copies of this patch 
series has this change, but Andrew's doesn't.  Trond, let's hook up Monday 
and work this out. 

Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

[Andrew Morton]

On Sun, 27 Aug 2006 14:25:21 -0400
"Chuck Lever" <chuck.lever@oracle.com> wrote:

> >  CC      fs/nfs/mount_clnt.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c: In 
> > function ‘mnt_create’:
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: 
> > error: implicit declaration of function ‘xprt_create_proto’
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:82: 
> > warning: assignment makes pointer from integer without a cast
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:86: 
> > error: implicit declaration of function ‘rpc_create_client’
> > /home/bunk/linux/kernel-2.6/linux-2.6.18-rc4-mm3/fs/nfs/mount_clnt.c:88: 
> > warning: assignment makes pointer from integer without a cast
> > make[3]: *** [fs/nfs/mount_clnt.o] Error 1
> >
> > <--  snip  -->
> 
> Looks like a patch got misapplied somewhere.

That's quite possible.

>  All my copies of this patch 
> series has this change, but Andrew's doesn't.

What is "this change"?  The only change I see in Trond's mount_clnt.c is the
removal of the xprt.h include.

Re: 2.6.18-rc4-mm3

[Pablo Neira Ayuso]

Benoit Boissinot wrote:
> On 8/27/06, Andrew Morton <akpm@osdl.org> wrote:
> 
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/ 
>>
>>
>> Changes since 2.6.18-rc4-mm2:
>>
>>  git-net.patch
> 
> 
> It introduces a new warning for me:
> net/netfilter/xt_CONNMARK.c: In function 'target':
> net/netfilter/xt_CONNMARK.c:59: warning: implicit declaration of
> function 'nf_conntrack_event_cache'
> 
> The warning is due to the following .config:
> CONFIG_IP_NF_CONNTRACK=m
> CONFIG_IP_NF_CONNTRACK_MARK=y
> # CONFIG_IP_NF_CONNTRACK_EVENTS is not set
> CONFIG_IP_NF_CONNTRACK_NETLINK=m
> 
> This change was introduced by:
> http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.19.git;a=commit;h=76e4b41009b8a2e9dd246135cf43c7fe39553aa5 
> 
> Proposed solution (based on the define in
> include/net/netfilter/nf_conntrack_compat.h:

That is my fault, thanks for catching up this Benoit.

Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of 
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: 2.6.18-rc4-mm3

[Mel Gorman]

On (26/08/06 16:09), Andrew Morton didst pronounce:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
> 

This failed to build on two x86_64 machines I have access to with (one
on test.kernel.org);

  OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
  BFD: Warning: Writing section `.data.percpu' to huge (ie negative)
  file offset 0x80471000.
  /usr/local/autobench/sources/x86_64-cross/gcc-3.4.0-glibc-2.3.2/bin/x86_64-unknown-linux-gnu-objcopy:
  arch/x86_64/boot/compressed/vmlinux.bin: File truncated
  make[2]: *** [arch/x86_64/boot/compressed/vmlinux.bin] Error 1
  make[1]: *** [arch/x86_64/boot/compressed/vmlinux] Error 2
  make: *** [bzImage] Error 2
  08/26/06-17:16:14 Build the kernel. Failed rc = 2
  08/26/06-17:16:14 build: kernel build Failed rc = 1
  08/26/06-17:16:14 command complete: (2) rc=126
  Failed and terminated the run
   Fatal error, aborting autorun

CONFIG_NR_CPUS was 8. The build log can be seen at
http://test.kernel.org/abat/45342/debug/test.log.0 and the .config is at
http://test.kernel.org/abat/45342/build/dotconfig . I haven't done any
further investigation in case this is a known problem. If it's new, I'll
start digging.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

[Chuck Lever]

----- Original Message ----- 
From: "Andrew Morton" <akpm@osdl.org>
To: "Chuck Lever" <chuck.lever@oracle.com>
Cc: "Adrian Bunk" <bunk@stusta.de>; "Trond Myklebust" 
<Trond.Myklebust@netapp.com>; <linux-kernel@vger.kernel.org>
Sent: Sunday, August 27, 2006 4:56 PM
Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

>>  All my copies of this patch
>> series has this change, but Andrew's doesn't.
>
> What is "this change"?  The only change I see in Trond's mount_clnt.c is 
> the
> removal of the xprt.h include.

Found the problem.  Because of changes Trond had included already in his 
tree, my patches didn't fit on his repository.  When I ported my patches to 
his tree, I accidentally left out the hunk that updates fs/nfs/mount_clnt.c.

Trond should be sending out the missing hunk soon. 

Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error

[Trond Myklebust]

On Mon, 2006-08-28 at 13:36 -0400, Chuck Lever wrote:
> ----- Original Message ----- 
> From: "Andrew Morton" <akpm@osdl.org>
> To: "Chuck Lever" <chuck.lever@oracle.com>
> Cc: "Adrian Bunk" <bunk@stusta.de>; "Trond Myklebust" 
> <Trond.Myklebust@netapp.com>; <linux-kernel@vger.kernel.org>
> Sent: Sunday, August 27, 2006 4:56 PM
> Subject: Re: 2.6.18-rc4-mm3: ROOT_NFS=y compile error
> 
> >>  All my copies of this patch
> >> series has this change, but Andrew's doesn't.
> >
> > What is "this change"?  The only change I see in Trond's mount_clnt.c is 
> > the
> > removal of the xprt.h include.
> 
> Found the problem.  Because of changes Trond had included already in his 
> tree, my patches didn't fit on his repository.  When I ported my patches to 
> his tree, I accidentally left out the hunk that updates fs/nfs/mount_clnt.c.
> 
> Trond should be sending out the missing hunk soon. 

Already merged into the NFS git tree. See

http://linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-2.6.git;a=commitdiff;h=f0d01cd34daccb47b7eeab03f80fe7986485528e

The raw patch can also be found on

http://client.linux-nfs.org/Linux-2.6.x/2.6.18-rc5/linux-2.6.18-056-fix_nfsroot.dif

Cheers,
  Trond

Re: 2.6.18-rc4-mm3

[Andrew Morton]

On Mon, 28 Aug 2006 10:07:54 +0100
mel@skynet.ie (Mel Gorman) wrote:

> On (26/08/06 16:09), Andrew Morton didst pronounce:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
> > 
> 
> This failed to build on two x86_64 machines I have access to with (one
> on test.kernel.org);
> 
>   OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
>   BFD: Warning: Writing section `.data.percpu' to huge (ie negative)
>   file offset 0x80471000.
>   /usr/local/autobench/sources/x86_64-cross/gcc-3.4.0-glibc-2.3.2/bin/x86_64-unknown-linux-gnu-objcopy:
>   arch/x86_64/boot/compressed/vmlinux.bin: File truncated
>   make[2]: *** [arch/x86_64/boot/compressed/vmlinux.bin] Error 1
>   make[1]: *** [arch/x86_64/boot/compressed/vmlinux] Error 2
>   make: *** [bzImage] Error 2
>   08/26/06-17:16:14 Build the kernel. Failed rc = 2
>   08/26/06-17:16:14 build: kernel build Failed rc = 1
>   08/26/06-17:16:14 command complete: (2) rc=126
>   Failed and terminated the run
>    Fatal error, aborting autorun
> 
> CONFIG_NR_CPUS was 8. The build log can be seen at
> http://test.kernel.org/abat/45342/debug/test.log.0 and the .config is at
> http://test.kernel.org/abat/45342/build/dotconfig . I haven't done any
> further investigation in case this is a known problem. If it's new, I'll
> start digging.
> 

hm.  It works for me.  

BINUTILS_DIR=binutils-2.16.1
GCC_DIR=gcc-4.0.2
GLIBC_DIR=glibc-2.3.6

I guess one could poke around in vmlinux, find out what's happened to the
.data.percpu section.  `readelf --sections vmlinux', etc?

divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

[Mattia Dongili]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
[...]
>  git-net.patch

got this one when starting sshd:

[   44.412000] divide error: 0000 [#1]
[   44.412000] 4K_STACKS PREEMPT 
[   44.412000] last sysfs file: /devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
[   44.412000] Modules linked in: nfsd exportfs lockd sunrpc ipt_MASQUERADE iptable_nat ip_nat xt_tcpudp xt_state ip_conntrack iptable_filter ip_tables x_tables ipv6 jfs aes dm_crypt dm_mod rtc sony_acpi tun psmouse sonypi speedstep_ich speedstep_lib cpufreq_conservative cpufreq_ondemand freq_table cpufreq_powersave sd_mod usb_storage scsi_mod usbhid pcmcia snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer intel_agp agpgart i2c_i801 snd soundcore snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd usbcore evdev e100 mii pcspkr
[   44.412000] CPU:    0
[   44.412000] EIP:    0060:[<d1516aca>]    Not tainted VLI
[   44.412000] EFLAGS: 00210246   (2.6.18-rc4-mm3-1 #6) 
[   44.412000] EIP is at fib6_rule_match+0x7a/0x150 [ipv6]
[   44.412000] eax: 00000000   ebx: cd9d4e30   ecx: d15290e0   edx: 00000000
[   44.412000] esi: cd7d9e08   edi: cd9d4e30   ebp: cd9d4d34   esp: cd9d4d0c
[   44.412000] ds: 007b   es: 007b   ss: 0068
[   44.412000] Process sshd (pid: 3780, ti=cd9d4000 task=cf131590 task.ti=cd9d4000)
[   44.412000] Stack: 00000003 c018b200 00000000 ced9df60 cd9d4d6c 00000000 ced9df60 d15290e0 
[   44.412000]        cd7d9e08 cd9d4e30 cd9d4d58 c02c198e d15290e0 cd9d4e30 00000000 c123f380 
[   44.412000]        cd9d4e30 cd7d9e08 cd9d4e30 cd9d4d80 d15169dc d15290a0 cd9d4e30 00000000 
[   44.412000] Call Trace:
[   44.412000]  [<c02c198e>] fib_rules_lookup+0x5e/0xe0
[   44.412000]  [<d15169dc>] fib6_rule_lookup+0x3c/0xb0 [ipv6]
[   44.412000]  [<d14f8702>] ip6_route_output+0x32/0x40 [ipv6]
[   44.412000]  [<d14ed155>] ip6_dst_lookup_tail+0x95/0xd0 [ipv6]
[   44.412000]  [<d14ed1a7>] ip6_dst_lookup+0x17/0x20 [ipv6]
[   44.412000]  [<d15120ce>] ip6_datagram_connect+0x36e/0x6c0 [ipv6]
[   44.412000]  [<c02f6829>] inet_dgram_connect+0x39/0x80
[   44.412000]  [<c02a6ceb>] sys_connect+0x6b/0x90
[   44.412000]  [<c02a846f>] sys_socketcall+0x9f/0x260
[   44.412000]  [<c010325b>] syscall_call+0x7/0xb
[   44.412000]  [<b7c7c93c>] 0xb7c7c93c
[   44.412000]  =======================
[   44.412000] Code: 00 00 00 89 d8 83 e0 1f 0f 85 9a 00 00 00 8b 5d 08 0f b6 53 68 84 d2 75 78 8b 55 08 8b 5d 0c 8b 4a 60 8b 43 28 31 c8 89 d1 31 d2 <f7> 71 64 85 c0 0f 94 c0 0f b6 c0 8b 5d f4 8b 75 f8 8b 7d fc 89 
[   44.412000] EIP: [<d1516aca>] fib6_rule_match+0x7a/0x150 [ipv6] SS:ESP 0068:cd9d4d0c
[   44.412000]  <6>note: sshd[3780] exited with preempt_count 1

config and full dmesg:
http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1

it's at fib6_rules.c:132 but since I can't tell why r->fwmask is 0 I'll
avoid proposing a wrong patch :)

-- 
mattia
:wq!

one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Mattia Dongili]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
[...]
>  git-acpi.patch

Sorry for reporting separately, I deleted the other thread on the issue.
Here we go:
[    9.386644] PCI: Using ACPI for IRQ routing
[    9.386688] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[    9.391209] ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
[    9.391521]  [<c0103a9f>] dump_trace+0x1ef/0x230
[    9.391626]  [<c0103b06>] show_trace_log_lvl+0x26/0x40
[    9.391724]  [<c01042bb>] show_trace+0x1b/0x20
[    9.391820]  [<c01043a4>] dump_stack+0x24/0x30
[    9.391918]  [<c0249f15>] acpi_format_exception+0xa3/0xb0
[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
[    9.394977]  [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
[    9.395742]  [<c02568da>] acpi_bus_register_driver+0xa1/0x123
[    9.396507]  [<c0418adb>] acpi_motherboard_init+0x17/0xfb
[    9.397268]  [<c01003d0>] init+0x80/0x290
[    9.397343]  [<c0103593>] kernel_thread_helper+0x7/0x14
[    9.397439]  =======================

full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
DSDT: http://oioio.altervista.org/linux/DSDT.aml
      http://oioio.altervista.org/linux/DSDT.dsl
lspci: http://oioio.altervista.org/linux/lspci-v

-- 
mattia
:wq!

Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

[Andrew Morton]

On Mon, 28 Aug 2006 22:07:16 +0200
Mattia Dongili <malattia@linux.it> wrote:

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
> [...]
> >  git-net.patch
> 
> got this one when starting sshd:
> 
> [   44.412000] divide error: 0000 [#1]
> [   44.412000] 4K_STACKS PREEMPT 
> [   44.412000] last sysfs file: /devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
> [   44.412000] Modules linked in: nfsd exportfs lockd sunrpc ipt_MASQUERADE iptable_nat ip_nat xt_tcpudp xt_state ip_conntrack iptable_filter ip_tables x_tables ipv6 jfs aes dm_crypt dm_mod rtc sony_acpi tun psmouse sonypi speedstep_ich speedstep_lib cpufreq_conservative cpufreq_ondemand freq_table cpufreq_powersave sd_mod usb_storage scsi_mod usbhid pcmcia snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer intel_agp agpgart i2c_i801 snd soundcore snd_page_alloc yenta_socket rsrc_nonstatic pcmcia_core uhci_hcd usbcore evdev e100 mii pcspkr
> [   44.412000] CPU:    0
> [   44.412000] EIP:    0060:[<d1516aca>]    Not tainted VLI
> [   44.412000] EFLAGS: 00210246   (2.6.18-rc4-mm3-1 #6) 
> [   44.412000] EIP is at fib6_rule_match+0x7a/0x150 [ipv6]
> [   44.412000] eax: 00000000   ebx: cd9d4e30   ecx: d15290e0   edx: 00000000
> [   44.412000] esi: cd7d9e08   edi: cd9d4e30   ebp: cd9d4d34   esp: cd9d4d0c
> [   44.412000] ds: 007b   es: 007b   ss: 0068
> [   44.412000] Process sshd (pid: 3780, ti=cd9d4000 task=cf131590 task.ti=cd9d4000)
> [   44.412000] Stack: 00000003 c018b200 00000000 ced9df60 cd9d4d6c 00000000 ced9df60 d15290e0 
> [   44.412000]        cd7d9e08 cd9d4e30 cd9d4d58 c02c198e d15290e0 cd9d4e30 00000000 c123f380 
> [   44.412000]        cd9d4e30 cd7d9e08 cd9d4e30 cd9d4d80 d15169dc d15290a0 cd9d4e30 00000000 
> [   44.412000] Call Trace:
> [   44.412000]  [<c02c198e>] fib_rules_lookup+0x5e/0xe0
> [   44.412000]  [<d15169dc>] fib6_rule_lookup+0x3c/0xb0 [ipv6]
> [   44.412000]  [<d14f8702>] ip6_route_output+0x32/0x40 [ipv6]
> [   44.412000]  [<d14ed155>] ip6_dst_lookup_tail+0x95/0xd0 [ipv6]
> [   44.412000]  [<d14ed1a7>] ip6_dst_lookup+0x17/0x20 [ipv6]
> [   44.412000]  [<d15120ce>] ip6_datagram_connect+0x36e/0x6c0 [ipv6]
> [   44.412000]  [<c02f6829>] inet_dgram_connect+0x39/0x80
> [   44.412000]  [<c02a6ceb>] sys_connect+0x6b/0x90
> [   44.412000]  [<c02a846f>] sys_socketcall+0x9f/0x260
> [   44.412000]  [<c010325b>] syscall_call+0x7/0xb
> [   44.412000]  [<b7c7c93c>] 0xb7c7c93c
> [   44.412000]  =======================
> [   44.412000] Code: 00 00 00 89 d8 83 e0 1f 0f 85 9a 00 00 00 8b 5d 08 0f b6 53 68 84 d2 75 78 8b 55 08 8b 5d 0c 8b 4a 60 8b 43 28 31 c8 89 d1 31 d2 <f7> 71 64 85 c0 0f 94 c0 0f b6 c0 8b 5d f4 8b 75 f8 8b 7d fc 89 
> [   44.412000] EIP: [<d1516aca>] fib6_rule_match+0x7a/0x150 [ipv6] SS:ESP 0068:cd9d4d0c

I cannot work out how the heck you got a divide instruction in
fib6_rule_match().

Can you please do `make net/ipv6/fib6_rules.s', find the code which
implements fib6_rule_match() (line starting with "fib6_rule_match:") and
send that plus the next 200-odd lines?  Or just stick fib6_rules.s on a
server somewhere?  Or mail me fib6_rules.s off-list.

Thanks.

Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

[Andi Kleen]

> I cannot work out how the heck you got a divide instruction in
> fib6_rule_match().

This might be another symptom of the broken smp-alternatives patch.
It tended to randomly corrupt some instructions by inserting different
bytes which then crash in interesting ways.

I already sent a fix for that, but it's not in yet.

-Andi

Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

[Andrew Morton]

On Mon, 28 Aug 2006 22:07:16 +0200
Mattia Dongili <malattia@linux.it> wrote:

> [   44.412000]  =======================
> [   44.412000] Code: 00 00 00 89 d8 83 e0 1f 0f 85 9a 00 00 00 8b 5d 08 0f b6 53 68 84 d2 75 78 8b 55 08 8b 5d 0c 8b 4a 60 8b 43 28 31 c8 89 d1 31 d2 <f7> 71 64 85 c0 0f 94 c0 0f b6 c0 8b 5d f4 8b 75 f8 8b 7d fc 89 
> [   44.412000] EIP: [<d1516aca>] fib6_rule_match+0x7a/0x150 [ipv6] SS:ESP 0068:cd9d4d0c
> [   44.412000]  <6>note: sshd[3780] exited with preempt_count 1
> 
> config and full dmesg:
> http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
> http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
> 
> it's at fib6_rules.c:132 but since I can't tell why r->fwmask is 0 I'll
> avoid proposing a wrong patch :)

Oh.  It looks like this has already been fixed:

#ifdef CONFIG_IPV6_ROUTE_FWMARK
        if ((r->fwmark ^ fl->fl6_fwmark) & r->fwmask)
                return 0;
#endif

there's no divide in there now.

Re: divide error: 0000 in fib6_rule_match

[David Miller]

From: Andrew Morton <akpm@osdl.org>
Date: Mon, 28 Aug 2006 14:30:03 -0700

> Oh.  It looks like this has already been fixed:
> 
> #ifdef CONFIG_IPV6_ROUTE_FWMARK
>         if ((r->fwmark ^ fl->fl6_fwmark) & r->fwmask)
>                 return 0;
> #endif
> 
> there's no divide in there now.

That's right there used to be a typo there.

Re: 2.6.18-rc4-mm3

[Rafael J. Wysocki]

On Sunday 27 August 2006 01:09, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/

I get things like the appended one on a regular basis at the system startup.

IIRC it has been reported for one of the previous -mm kernels, but it's still
there.


Adding 2104504k swap on /dev/hdc3.  Priority:-1 extents:1 across:2104504k
skge eth0: enabling interface
BUG: MAX_STACK_TRACE_ENTRIES too low!
turning off the locking correctness validator.

Call Trace:
 [<ffffffff8020b119>] dump_trace+0xb9/0x3d0
 [<ffffffff8020b473>] show_trace+0x43/0x60
 [<ffffffff8020b785>] dump_stack+0x15/0x20
 [<ffffffff802489a6>] save_trace+0xd6/0xf0
 [<ffffffff80248ad1>] add_lock_to_list+0x91/0xc0
 [<ffffffff8024ad31>] __lock_acquire+0xb01/0xd30
 [<ffffffff8024b2fb>] lock_acquire+0x8b/0xc0
 [<ffffffff80475b05>] _spin_lock_irq+0x35/0x50
 [<ffffffff80472aec>] schedule+0x16c/0x5ef
 [<ffffffff804734b7>] preempt_schedule_irq+0x57/0x90
 [<ffffffff8020a3f6>] retint_kernel+0x26/0x30
 [<ffffffff804740fb>] __mutex_lock_slowpath+0x23b/0x270
 [<ffffffff80474139>] mutex_lock+0x9/0x10
 [<ffffffff8821801a>] :snd_seq_device:snd_seq_device_info+0x1a/0xd0
 [<ffffffff8806be5e>] :snd:snd_info_entry_open+0x27e/0x360
 [<ffffffff8028d19c>] __dentry_open+0x13c/0x290
 [<ffffffff8028d39d>] nameidata_to_filp+0x2d/0x50
 [<ffffffff8028d3fd>] do_filp_open+0x3d/0x50
 [<ffffffff8028d46a>] do_sys_open+0x5a/0xf0
 [<ffffffff8028d52b>] sys_open+0x1b/0x20
 [<ffffffff80209d2e>] system_call+0x7e/0x83
 [<00002ab9c19f1722>]
 [<ffffffff802489a6>] save_trace+0xd6/0xf0
 [<ffffffff80248ad1>] add_lock_to_list+0x91/0xc0
 [<ffffffff8024ad31>] __lock_acquire+0xb01/0xd30
 [<ffffffff80472aec>] schedule+0x16c/0x5ef
 [<ffffffff8024b2fb>] lock_acquire+0x8b/0xc0
 [<ffffffff80472aec>] schedule+0x16c/0x5ef
 [<ffffffff80475b05>] _spin_lock_irq+0x35/0x50
 [<ffffffff80472aec>] schedule+0x16c/0x5ef
 [<ffffffff8024b3a9>] mark_held_locks+0x79/0xa0
 [<ffffffff804734b1>] preempt_schedule_irq+0x51/0x90
 [<ffffffff804734b7>] preempt_schedule_irq+0x57/0x90
 [<ffffffff8020a3f6>] retint_kernel+0x26/0x30
 [<ffffffff804740fb>] __mutex_lock_slowpath+0x23b/0x270
 [<ffffffff8047411d>] __mutex_lock_slowpath+0x25d/0x270
 [<ffffffff80474139>] mutex_lock+0x9/0x10
 [<ffffffff8821801a>] :snd_seq_device:snd_seq_device_info+0x1a/0xd0
 [<ffffffff8806be5e>] :snd:snd_info_entry_open+0x27e/0x360
 [<ffffffff8806bbe0>] :snd:snd_info_entry_open+0x0/0x360
 [<ffffffff8028d19c>] __dentry_open+0x13c/0x290
 [<ffffffff8028d39d>] nameidata_to_filp+0x2d/0x50
 [<ffffffff8028d3fd>] do_filp_open+0x3d/0x50
 [<ffffffff80475960>] _spin_unlock+0x30/0x60
 [<ffffffff8028cb58>] get_unused_fd+0xf8/0x110
 [<ffffffff803581fa>] strncpy_from_user+0x3a/0x50
 [<ffffffff8028d46a>] do_sys_open+0x5a/0xf0
 [<ffffffff8028d52b>] sys_open+0x1b/0x20
 [<ffffffff80209d2e>] system_call+0x7e/0x83

NET: Registered protocol family 17

Re: divide error: 0000 in fib6_rule_match [Re: 2.6.18-rc4-mm3]

[Mattia Dongili]

On Mon, August 28, 2006 11:30 pm, Andrew Morton said:
> On Mon, 28 Aug 2006 22:07:16 +0200
> Mattia Dongili <malattia@linux.it> wrote:
[...]
>> it's at fib6_rules.c:132 but since I can't tell why r->fwmask is 0 I'll
>> avoid proposing a wrong patch :)
>
> Oh.  It looks like this has already been fixed:
>
> #ifdef CONFIG_IPV6_ROUTE_FWMARK
>         if ((r->fwmark ^ fl->fl6_fwmark) & r->fwmask)
>                 return 0;
> #endif
>
> there's no divide in there now.

Ok, great, I have a division instead of the bitwise and there in fact.

thanks
-- 
mattia
:wq!

Re: 2.6.18-rc4-mm3

[Haavard Skinnemoen]

On Sat, 26 Aug 2006 16:09:22 -0700
Andrew Morton <akpm@osdl.org> wrote:

> +namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch

This causes a multiple definition of init_nsproxy on AVR32. Reverting
namespaces-add-nsproxy-avr32-fix.patch fixes it.

Haavard

Re: 2.6.18-rc4-mm3

[Mel Gorman]

On Mon, 28 Aug 2006, Andrew Morton wrote:

> On Mon, 28 Aug 2006 10:07:54 +0100
> mel@skynet.ie (Mel Gorman) wrote:
>
>> On (26/08/06 16:09), Andrew Morton didst pronounce:
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/
>>>
>>
>> This failed to build on two x86_64 machines I have access to with (one
>> on test.kernel.org);
>>
>>   OBJCOPY arch/x86_64/boot/compressed/vmlinux.bin
>>   BFD: Warning: Writing section `.data.percpu' to huge (ie negative)
>>   file offset 0x80471000.
>>   /usr/local/autobench/sources/x86_64-cross/gcc-3.4.0-glibc-2.3.2/bin/x86_64-unknown-linux-gnu-objcopy:
>>   arch/x86_64/boot/compressed/vmlinux.bin: File truncated
>>   make[2]: *** [arch/x86_64/boot/compressed/vmlinux.bin] Error 1
>>   make[1]: *** [arch/x86_64/boot/compressed/vmlinux] Error 2
>>   make: *** [bzImage] Error 2
>>   08/26/06-17:16:14 Build the kernel. Failed rc = 2
>>   08/26/06-17:16:14 build: kernel build Failed rc = 1
>>   08/26/06-17:16:14 command complete: (2) rc=126
>>   Failed and terminated the run
>>    Fatal error, aborting autorun
>>
>> CONFIG_NR_CPUS was 8. The build log can be seen at
>> http://test.kernel.org/abat/45342/debug/test.log.0 and the .config is at
>> http://test.kernel.org/abat/45342/build/dotconfig . I haven't done any
>> further investigation in case this is a known problem. If it's new, I'll
>> start digging.
>>
>
> hm.  It works for me.
>
> BINUTILS_DIR=binutils-2.16.1
> GCC_DIR=gcc-4.0.2
> GLIBC_DIR=glibc-2.3.6
>
> I guess one could poke around in vmlinux, find out what's happened to the
> .data.percpu section.  `readelf --sections vmlinux', etc?


There didn't seem to be anything unusual about the .data.percpu section It 
turned out to be a binutils version problem. On the two test machines, the 
cross-compiler from 
http://developer.osdl.org/dev/plm/cross_compile/x86_64-unknown-linux-gnu.tar.bz2 
was being used. When later versions were used, the problem disappeared.

Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: 2.6.18-rc4-mm3

[Cedric Le Goater]

Haavard Skinnemoen wrote:
> On Sat, 26 Aug 2006 16:09:22 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
>> +namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
> 
> This causes a multiple definition of init_nsproxy on AVR32. Reverting
> namespaces-add-nsproxy-avr32-fix.patch fixes it.

Could you try this ?

thanks,

C.


Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>

---
 arch/avr32/kernel/init_task.c |    2 --
 1 file changed, 2 deletions(-)

Index: 2.6.18-rc4-mm3/arch/avr32/kernel/init_task.c
===================================================================
--- 2.6.18-rc4-mm3.orig/arch/avr32/kernel/init_task.c
+++ 2.6.18-rc4-mm3/arch/avr32/kernel/init_task.c
@@ -10,7 +10,6 @@
 #include <linux/sched.h>
 #include <linux/init_task.h>
 #include <linux/mqueue.h>
-#include <linux/nsproxy.h>

 #include <asm/pgtable.h>

@@ -19,7 +18,6 @@ static struct files_struct init_files =
 static struct signal_struct init_signals = INIT_SIGNALS(init_signals);
 static struct sighand_struct init_sighand = INIT_SIGHAND(init_sighand);
 struct mm_struct init_mm = INIT_MM(init_mm);
-struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy);

 EXPORT_SYMBOL(init_mm);

Re: 2.6.18-rc4-mm3

[Haavard Skinnemoen]

On Tue, 29 Aug 2006 17:18:58 +0200
Cedric Le Goater <clg@fr.ibm.com> wrote:

> Haavard Skinnemoen wrote:
> > On Sat, 26 Aug 2006 16:09:22 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> > 
> >> +namespaces-add-nsproxy-move-init_nsproxy-into-kernel-nsproxyc.patch
> > 
> > This causes a multiple definition of init_nsproxy on AVR32.
> > Reverting namespaces-add-nsproxy-avr32-fix.patch fixes it.
> 
> Could you try this ?

Yes, this works fine. This does in fact revert
namespaces-add-nsproxy-avr32-fix.patch, so it would work equally well
to just drop that patch.

Thanks,

Haavard

[-mm patch] net/sched/act_simple.c: make struct simp_hash_info static

[Adrian Bunk]

On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.18-rc4-mm2:
>...
>  git-net.patch
>...
>  git trees
>...

This patch makes the needlessly global struct simp_hash_info static.

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

--- linux-2.6.18-rc4-mm3/net/sched/act_simple.c.old	2006-08-30 20:54:20.000000000 +0200
+++ linux-2.6.18-rc4-mm3/net/sched/act_simple.c	2006-08-30 20:54:43.000000000 +0200
@@ -28,7 +28,7 @@
 static u32 simp_idx_gen;
 static DEFINE_RWLOCK(simp_lock);
 
-struct tcf_hashinfo simp_hash_info = {
+static struct tcf_hashinfo simp_hash_info = {
 	.htab	=	tcf_simp_ht,
 	.hmask	=	SIMP_TAB_MASK,
 	.lock	=	&simp_lock,

[-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

[Adrian Bunk]

This patch fixes the following section mismatch
(dmi_matched() is referenced from struct dmi_ids):

<--  snip  -->

...
  Building modules, stage 2.
  MODPOST 1956 modules
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x1e0) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x20c) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x238) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x264) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x290) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x2bc) and '__param_str_force'
WARNING: drivers/input/misc/wistron_btns.o - Section mismatch: reference to .init.text: from .data between 'dmi_ids' (at offset 0x2e8) and '__param_str_force'
...

<--  snip  -->

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

--- linux-2.6.18-rc4-mm3/drivers/input/misc/wistron_btns.c.old	2006-08-30 21:47:00.000000000 +0200
+++ linux-2.6.18-rc4-mm3/drivers/input/misc/wistron_btns.c	2006-08-30 21:47:57.000000000 +0200
@@ -242,7 +242,7 @@
 static int have_wifi;
 static int have_bluetooth;
 
-static int __init dmi_matched(struct dmi_system_id *dmi)
+static int dmi_matched(struct dmi_system_id *dmi)
 {
 	const struct key_entry *key;
 

[-mm patch] improve SECURITY_SELINUX_POLICYDB_VERSION_MAX{,_VALUE} help texts

[Adrian Bunk]

We can't expect everyone to know what "FC3" is.

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

--- linux-2.6.18-rc4-mm3/security/selinux/Kconfig.old	2006-08-30 21:56:31.000000000 +0200
+++ linux-2.6.18-rc4-mm3/security/selinux/Kconfig	2006-08-30 21:58:21.000000000 +0200
@@ -135,8 +135,10 @@ config SECURITY_SELINUX_POLICYDB_VERSION
 	  It can be adjusted downward to support legacy userland (init) that
 	  does not correctly handle kernels that support newer policy versions.
 
-	  Examples:  For FC3 or FC4, enable this option and set the value via
-	  the next option.  For FC5 and later, do not enable this option.
+	  Examples:
+	  For the Fedora Core 3 or 4 Linux distributions, enable this option
+	  and set the value via the next option. For Fedore Core 5 and later,
+	  do not enable this option.
 
 	  If you are unsure how to answer this question, answer N.
 
@@ -149,7 +151,9 @@ config SECURITY_SELINUX_POLICYDB_VERSION
 	  This option sets the value for the maximum policy format version
 	  supported by SELinux.
 
-	  Examples:  For FC3, use 18.  For FC4, use 19.
+	  Examples:
+	  For Fedora Core 3, use 18.
+	  For Fedora Core 4, use 19.
 
 	  If you are unsure how to answer this question, look for the
 	  policy format version supported by your policy toolchain, by

Re: [-mm patch] net/sched/act_simple.c: make struct simp_hash_info static

[David Miller]

From: Adrian Bunk <bunk@stusta.de>
Date: Wed, 30 Aug 2006 22:35:07 +0200

> On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.18-rc4-mm2:
> >...
> >  git-net.patch
> >...
> >  git trees
> >...
> 
> This patch makes the needlessly global struct simp_hash_info static.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

Applied, thanks Adrian.

Re: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

[Dmitry Torokhov]

On Wednesday 30 August 2006 16:35, Adrian Bunk wrote:
> This patch fixes the following section mismatch
> (dmi_matched() is referenced from struct dmi_ids):
>

dmi_ids is only used in select_keymap, which is __init. Moreover,
dmi_ids is marked __initdata so I do not see what the problem is...
 
-- 
Dmitry

Re: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

[Adrian Bunk]

On Wed, Aug 30, 2006 at 07:26:37PM -0400, Dmitry Torokhov wrote:
> On Wednesday 30 August 2006 16:35, Adrian Bunk wrote:
> > This patch fixes the following section mismatch
> > (dmi_matched() is referenced from struct dmi_ids):
> >
> 
> dmi_ids is only used in select_keymap, which is __init. Moreover,
> dmi_ids is marked __initdata so I do not see what the problem is...

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/revert-input-wistron-fix-section-reference-mismatches.patch

> Dmitry

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: [-mm patch] drivers/input/misc/wistron_btns.c: fix section mismatch

[Dmitry Torokhov]

On Wednesday 30 August 2006 19:36, Adrian Bunk wrote:
> On Wed, Aug 30, 2006 at 07:26:37PM -0400, Dmitry Torokhov wrote:
> > On Wednesday 30 August 2006 16:35, Adrian Bunk wrote:
> > > This patch fixes the following section mismatch
> > > (dmi_matched() is referenced from struct dmi_ids):
> > >
> > 
> > dmi_ids is only used in select_keymap, which is __init. Moreover,
> > dmi_ids is marked __initdata so I do not see what the problem is...
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/revert-input-wistron-fix-section-reference-mismatches.patch
>

Ah, I see. I think it is fixed properly in Linus' tree.

-- 
Dmitry

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

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

On Fri, 2006-09-15 at 09:52 +0800, Shaohua Li wrote:
> On Thu, 2006-09-14 at 10:55 -0700, keith mannthey wrote:
> > On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> > > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > 
> > > > I think that your SSDT is valid.  I can't point to a specific
> > > > reference in the spec, but I think the "try _HID first, then try
> > > > _CID" strategy is clearly the intent.  Otherwise, there would be
> > > > no reason to separate _HID from _CID.
> > > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > > is valid or invalid. 
> > 
> > Lets work on the assumption it is valid until someone points out in a
> > spec that says it isn't. 
> > 
> > > The 'try _HID first then _CID' has another downside. It highly depends
> > > on the driver is loaded first and then load the device. See motherboard
> > > driver loads first and the mem hotplug driver isn't loaded, in this
> > > situation if you scan the mem hotplug device, the mechanism will fail as
> > > the two pass search will still bind motherboard driver to the device.
> > Any solution depends on the mem hotplug device being loaded.  This
> > doesn't appear to be _HID before _CID specific issue .  
> > 
> > > If you take the two pass search, I have a feeling this will make acpi
> > > never be able to convert Linux driver model.
> > 
> > I am not trying to break forward work but what I do want is a solution
> > to my problem. 
> > 
> > > If you really want to workaround the issue, I prefer have a blacklist or
> > > something to let ACPI not use the _CID for your device, but please don't
> > > mess the ACPI core itself.
> > 
> > My fist pass to fix the problem was I guess a hack of sorts that caused
> > others problems (motherboard add return != 0 on unknown devices).  I
> > don't want another Keith grown hack that breaks other people. 
> > 
> > Can you elaborate on what you think would be safe way to do what you
> > propose since the ACPI core (can't/won't?) be fixed? I can imagine a
> > couple of different ways to fix this but I would like some feedback
> > before I go off and work on the 3rd pass of this fix. 

Ok off I went.... 

> > 1.  Make the memory device get scanned before the motherboard device
> > somehow.  Implicitly reorder the devices in the list. Perhaps a priority
> > sorted of sorts to have _HID device always before _CID devices during
> > the scan? 
> This will change the scan order of ACPI device, and sounds too hack to me.

  ACPI driver only has name with no _HID _CID contest.  The handle reads
the name space to fill in the device.    There is no way to explicitly
order the list correctly for all cases as we are trying to reorder the
driver list.
  
  I looked into making the memory device dynamically change itself to
not contain a _CID (thus changing the namespace) but it got pretty ugly.
This is perhaps doable but a little on the ugly side.  

  So I just flip the order of the device list for all cases in a simple
patch.  This is a total hack and workaround for just my current
situation.   


> > 3.  Some special blacklist of the motherboard device on my specific
> > system. 

Uhh this looks to require a whole new black list infrastructure?

Any more ideas????

Thanks,
  Keith 

Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>


[-- Attachment #2: patch-acpi-scanfix-v2 --]
[-- Type: text/plain, Size: 396 bytes --]

--- linux-2.6.17/drivers/acpi/scan.c	2006-09-20 13:58:06.000000000 -0700
+++ linux-2.6.18-rc6-mm2-works/drivers/acpi/scan.c	2006-09-20 11:31:33.000000000 -0700
@@ -601,7 +601,7 @@
 		return -ENODEV;
 
 	spin_lock(&acpi_device_lock);
-	list_add_tail(&driver->node, &acpi_bus_drivers);
+	list_add(&driver->node, &acpi_bus_drivers);
 	spin_unlock(&acpi_device_lock);
 	acpi_driver_attach(driver);
 

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Thursday 14 September 2006 19:39, Shaohua Li wrote:
> > PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
> > driver to release a device and bind another driver to it.  Maybe we
> > could do something similar for ACPI. 
> After we convert acpi core to Linux driver model, we have the
> capability. But not sure if this can help Keith.

When will the conversion to the Linux driver model happen?

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-14 at 10:55 -0700, keith mannthey wrote:
> On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> 
> > > I think that your SSDT is valid.  I can't point to a specific
> > > reference in the spec, but I think the "try _HID first, then try
> > > _CID" strategy is clearly the intent.  Otherwise, there would be
> > > no reason to separate _HID from _CID.
> > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > is valid or invalid. 
> 
> Lets work on the assumption it is valid until someone points out in a
> spec that says it isn't. 
> 
> > The 'try _HID first then _CID' has another downside. It highly depends
> > on the driver is loaded first and then load the device. See motherboard
> > driver loads first and the mem hotplug driver isn't loaded, in this
> > situation if you scan the mem hotplug device, the mechanism will fail as
> > the two pass search will still bind motherboard driver to the device.
> Any solution depends on the mem hotplug device being loaded.  This
> doesn't appear to be _HID before _CID specific issue .  
> 
> > If you take the two pass search, I have a feeling this will make acpi
> > never be able to convert Linux driver model.
> 
> I am not trying to break forward work but what I do want is a solution
> to my problem. 
> 
> > If you really want to workaround the issue, I prefer have a blacklist or
> > something to let ACPI not use the _CID for your device, but please don't
> > mess the ACPI core itself.
> 
> My fist pass to fix the problem was I guess a hack of sorts that caused
> others problems (motherboard add return != 0 on unknown devices).  I
> don't want another Keith grown hack that breaks other people. 
> 
> Can you elaborate on what you think would be safe way to do what you
> propose since the ACPI core (can't/won't?) be fixed? I can imagine a
> couple of different ways to fix this but I would like some feedback
> before I go off and work on the 3rd pass of this fix. 
> 
> 1.  Make the memory device get scanned before the motherboard device
> somehow.  Implicitly reorder the devices in the list. Perhaps a priority
> sorted of sorts to have _HID device always before _CID devices during
> the scan? 
This will change the scan order of ACPI device, and sounds too hack to me.

> 2.  Have the motherboard device (if it finds the right acpi device type)
> hook into the memory device somehow. 
> 
> 3.  Some special blacklist of the motherboard device on my specific
> system. 
Either one of the two looks ok.

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-14 at 10:36 -0600, Bjorn Helgaas wrote:
> On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> > On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > > I think that your SSDT is valid.  I can't point to a specific
> > > reference in the spec, but I think the "try _HID first, then try
> > > _CID" strategy is clearly the intent.  Otherwise, there would be
> > > no reason to separate _HID from _CID.
> 
> > The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> > is valid or invalid. 
> 
> This problem is more general than just Keith's situation.  This
> could happen with any device that has both _HID and _CID.  As
> soon as you have both _HID and _CID, you can have a driver that
> claims the _HID and another that claims the _CID.
We don't see such issue before, don't think it's generic. We did have
some devices with _CID, like a pcie root bridge claims pnp0a03 (pci root
bridge), but they are really compatible.

> The spec obviously anticipates this situation, which is why I
> think the SSDT is valid from the ACPI spec point of view.
> 
> Now, if you have some definition of the programming model of
> PNP0C01/PNP0C02, and the memory device doesn't conform to that
> model, then I would agree that the SSDT is invalid.  But I
> don't know where a PNP0C01/PNP0C02 programming model is defined.
> 
> The linux driver does nothing more than reserve the resources
> of the device, so it doesn't use any programming model at all.
> The memory device (in fact, any ACPI device at all) trivially
> conforms to this "null programming model."
> 
> > The 'try _HID first then _CID' has another downside. It highly depends
> > on the driver is loaded first and then load the device. See motherboard
> > driver loads first and the mem hotplug driver isn't loaded, in this
> > situation if you scan the mem hotplug device, the mechanism will fail as
> > the two pass search will still bind motherboard driver to the device.
> 
> I agree, this is a problem that will have to be resolved.  And it's
> really not just an ACPI problem.  A PCI driver can claim devices based
> on a class or a vendor/device/subvendor/subdevice with wildcards.
> Another driver can claim devices with a specific vendor/device/etc.
> Some devices may match with both drivers.
I'd prefer don't do ACPI core change in this stage and just workaround
Keith's issue till we find this is really a generic problem.

> PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
> driver to release a device and bind another driver to it.  Maybe we
> could do something similar for ACPI. 
After we convert acpi core to Linux driver model, we have the
capability. But not sure if this can help Keith.

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-09-14 at 11:01 +0800, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:

> > I think that your SSDT is valid.  I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent.  Otherwise, there would be
> > no reason to separate _HID from _CID.
> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid. 

Lets work on the assumption it is valid until someone points out in a
spec that says it isn't. 

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.
Any solution depends on the mem hotplug device being loaded.  This
doesn't appear to be _HID before _CID specific issue .  

> If you take the two pass search, I have a feeling this will make acpi
> never be able to convert Linux driver model.

I am not trying to break forward work but what I do want is a solution
to my problem. 

> If you really want to workaround the issue, I prefer have a blacklist or
> something to let ACPI not use the _CID for your device, but please don't
> mess the ACPI core itself.

My fist pass to fix the problem was I guess a hack of sorts that caused
others problems (motherboard add return != 0 on unknown devices).  I
don't want another Keith grown hack that breaks other people. 

Can you elaborate on what you think would be safe way to do what you
propose since the ACPI core (can't/won't?) be fixed? I can imagine a
couple of different ways to fix this but I would like some feedback
before I go off and work on the 3rd pass of this fix. 

1.  Make the memory device get scanned before the motherboard device
somehow.  Implicitly reorder the devices in the list. Perhaps a priority
sorted of sorts to have _HID device always before _CID devices during
the scan? 

2.  Have the motherboard device (if it finds the right acpi device type)
hook into the memory device somehow. 

3.  Some special blacklist of the motherboard device on my specific
system. 


Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Wednesday 13 September 2006 21:01, Shaohua Li wrote:
> On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> > I think that your SSDT is valid.  I can't point to a specific
> > reference in the spec, but I think the "try _HID first, then try
> > _CID" strategy is clearly the intent.  Otherwise, there would be
> > no reason to separate _HID from _CID.

> The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
> is valid or invalid. 

This problem is more general than just Keith's situation.  This
could happen with any device that has both _HID and _CID.  As
soon as you have both _HID and _CID, you can have a driver that
claims the _HID and another that claims the _CID.

The spec obviously anticipates this situation, which is why I
think the SSDT is valid from the ACPI spec point of view.

Now, if you have some definition of the programming model of
PNP0C01/PNP0C02, and the memory device doesn't conform to that
model, then I would agree that the SSDT is invalid.  But I
don't know where a PNP0C01/PNP0C02 programming model is defined.

The linux driver does nothing more than reserve the resources
of the device, so it doesn't use any programming model at all.
The memory device (in fact, any ACPI device at all) trivially
conforms to this "null programming model."

> The 'try _HID first then _CID' has another downside. It highly depends
> on the driver is loaded first and then load the device. See motherboard
> driver loads first and the mem hotplug driver isn't loaded, in this
> situation if you scan the mem hotplug device, the mechanism will fail as
> the two pass search will still bind motherboard driver to the device.

I agree, this is a problem that will have to be resolved.  And it's
really not just an ACPI problem.  A PCI driver can claim devices based
on a class or a vendor/device/subvendor/subdevice with wildcards.
Another driver can claim devices with a specific vendor/device/etc.
Some devices may match with both drivers.

PCI has a /sys/bus/pci/driver/XXX/{bind,unbind} mechanism to cause a
driver to release a device and bind another driver to it.  Maybe we
could do something similar for ACPI. 

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Wed, 2006-09-13 at 22:51 +0800, Bjorn Helgaas wrote:
> On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> > On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > > >> If we decide that "try HID first, then try CID" is the right
> thing,
> > > >> I think we should figure out how to make that work.  Maybe that
> > > >> means extending the driver model somehow.
> > > > Don't think it's easy, especially no other bus needs it I guess.
> > >
> > > I agree it's probably not easy, but I think having the right
> > > semantics is more important than fitting cleanly into the
> > > driver model.  But I know that without code, I'm just venting
> > > hot air, not contributing to a solution.
> > >
> > > How's the ACPI driver model integration going, anyway?  I seem
> > > to recall some patches a while back, but I don't think they're
> > > in the tree yet.
> > >
> > > > Do we really need the memory hotplug device returns
> pnp0c01/pnp0c02?
> > > > What's the purpose?
> > >
> > > I don't know.  But I think Keith already determined that a BIOS
> change
> > > is not likely.  I hate to ask for BIOS changes like this because
> it
> > > feels like asking them to avoid broken things in Linux.
> >
> >   Ok my motherboard patch was dropped from -mm so I am broken again
> but
> > others are fixed. Is the answer that we do nothing about this
> issues?  
> >
> >   I am pretty sure my SSDT table is valid if someone *cannot* point
> out
> > in the spec where my device is malformed  by having both HID and CID
> I
> > will not be able even start the request to change the BIOS (it would
> be
> > a waste of my time).  Sure having the CID of the memory device may
> be
> > overkill but is it wrong? 
> 
> I think that your SSDT is valid.  I can't point to a specific
> reference in the spec, but I think the "try _HID first, then try
> _CID" strategy is clearly the intent.  Otherwise, there would be
> no reason to separate _HID from _CID.
The spec actually doesn't mention PNP0C01/PNP0C02. It's hard to say this
is valid or invalid. 

The 'try _HID first then _CID' has another downside. It highly depends
on the driver is loaded first and then load the device. See motherboard
driver loads first and the mem hotplug driver isn't loaded, in this
situation if you scan the mem hotplug device, the mechanism will fail as
the two pass search will still bind motherboard driver to the device.

If you take the two pass search, I have a feeling this will make acpi
never be able to convert Linux driver model.

If you really want to workaround the issue, I prefer have a blacklist or
something to let ACPI not use the _CID for your device, but please don't
mess the ACPI core itself.

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Tuesday 12 September 2006 19:27, keith mannthey wrote:
> On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> > >> If we decide that "try HID first, then try CID" is the right thing,
> > >> I think we should figure out how to make that work.  Maybe that
> > >> means extending the driver model somehow.
> > > Don't think it's easy, especially no other bus needs it I guess.
> > 
> > I agree it's probably not easy, but I think having the right
> > semantics is more important than fitting cleanly into the
> > driver model.  But I know that without code, I'm just venting
> > hot air, not contributing to a solution.
> > 
> > How's the ACPI driver model integration going, anyway?  I seem
> > to recall some patches a while back, but I don't think they're
> > in the tree yet.
> > 
> > > Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> > > What's the purpose?
> > 
> > I don't know.  But I think Keith already determined that a BIOS change
> > is not likely.  I hate to ask for BIOS changes like this because it
> > feels like asking them to avoid broken things in Linux.
> 
>   Ok my motherboard patch was dropped from -mm so I am broken again but
> others are fixed. Is the answer that we do nothing about this issues?   
> 
>   I am pretty sure my SSDT table is valid if someone *cannot* point out
> in the spec where my device is malformed  by having both HID and CID I
> will not be able even start the request to change the BIOS (it would be
> a waste of my time).  Sure having the CID of the memory device may be
> overkill but is it wrong?  

I think that your SSDT is valid.  I can't point to a specific
reference in the spec, but I think the "try _HID first, then try
_CID" strategy is clearly the intent.  Otherwise, there would be
no reason to separate _HID from _CID.

>   Unless someone can show me a alternate solution I am going to push the
> check HID before CID patch to -mm in the next day or two. 

I support this, although I do understand that it will make it more
difficult to integrate ACPI into the driver model because the driver
model currently only does one pass to check whether a driver can claim
a device.

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-09-07 at 20:27 -0600, Bjorn Helgaas wrote:
> > On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> >> If we decide that "try HID first, then try CID" is the right thing,
> >> I think we should figure out how to make that work.  Maybe that
> >> means extending the driver model somehow.
> > Don't think it's easy, especially no other bus needs it I guess.
> 
> I agree it's probably not easy, but I think having the right
> semantics is more important than fitting cleanly into the
> driver model.  But I know that without code, I'm just venting
> hot air, not contributing to a solution.
> 
> How's the ACPI driver model integration going, anyway?  I seem
> to recall some patches a while back, but I don't think they're
> in the tree yet.
> 
> > Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> > What's the purpose?
> 
> I don't know.  But I think Keith already determined that a BIOS change
> is not likely.  I hate to ask for BIOS changes like this because it
> feels like asking them to avoid broken things in Linux.

  Ok my motherboard patch was dropped from -mm so I am broken again but
others are fixed. Is the answer that we do nothing about this issues?   

  I am pretty sure my SSDT table is valid if someone *cannot* point out
in the spec where my device is malformed  by having both HID and CID I
will not be able even start the request to change the BIOS (it would be
a waste of my time).  Sure having the CID of the memory device may be
overkill but is it wrong?  

  Unless someone can show me a alternate solution I am going to push the
check HID before CID patch to -mm in the next day or two. 

Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

> On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
>> If we decide that "try HID first, then try CID" is the right thing,
>> I think we should figure out how to make that work.  Maybe that
>> means extending the driver model somehow.
> Don't think it's easy, especially no other bus needs it I guess.

I agree it's probably not easy, but I think having the right
semantics is more important than fitting cleanly into the
driver model.  But I know that without code, I'm just venting
hot air, not contributing to a solution.

How's the ACPI driver model integration going, anyway?  I seem
to recall some patches a while back, but I don't think they're
in the tree yet.

> Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
> What's the purpose?

I don't know.  But I think Keith already determined that a BIOS change
is not likely.  I hate to ask for BIOS changes like this because it
feels like asking them to avoid broken things in Linux.

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-07 at 09:25 -0600, Bjorn Helgaas wrote:
> On Wednesday 06 September 2006 20:03, Shaohua Li wrote:
> > On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> > > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: 
> > > > From one of the ACPI guys: 
> > > >  
> > > > > Get hid 
> > > > > Look for driver 
> > > > > If you find a match, load it 
> > > > > If no match, get CID 
> > > > > Look for driver 
> > > > > If you find a match, load it 
> > > > > If you did not find an hid or cid match, punt
> > > 
> > > I think this is what my patch is doing.
> > > 
> > > when looking for a driver: (acpi_bus_find_driver) 
> > > I check against the HID  
> > > return if found  
> > > Then I check against the CID 
> > > return if found 
> > > else 
> > > punt 
> > > 
> > > Any objections to pushing this into -mm and dropping the motherboard 
> > > change?
> 
> > I'd prefer not take this way. The ACPI driver model is already mess
> > enough, let's don't make it worse. We are converting the ACPI driver
> > model to Linux driver model, this will make the attempt difficult.
> 
> I see that driver_bind() and driver_probe_device() don't mesh well
> with the idea that multiple drivers might be able to claim a device,
> because there doesn't seem to be a way to prioritize one driver
> over another.  Is that the problem you're referring to?
Yes.

> If we decide that "try HID first, then try CID" is the right thing,
> I think we should figure out how to make that work.  Maybe that
> means extending the driver model somehow.
Don't think it's easy, especially no other bus needs it I guess.

> > We can let the motherboard driver not bind to your device (say we didn't
> > register the motherboard driver, but just reserve the resource of the
> > deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
> > mem region of the device too).
> 
> My point was that ACPI tells us what resources the device uses,
> and we should reserve all of them so we accurately model the system.
> 
> Reserving resources without registering the driver sounds like a hack
> to work around broken behavior elsewhere, so I don't think it's a
> good idea.
Do we really need the memory hotplug device returns pnp0c01/pnp0c02?
What's the purpose?

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Wednesday 06 September 2006 20:03, Shaohua Li wrote:
> On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> > On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: 
> > > From one of the ACPI guys: 
> > >  
> > > > Get hid 
> > > > Look for driver 
> > > > If you find a match, load it 
> > > > If no match, get CID 
> > > > Look for driver 
> > > > If you find a match, load it 
> > > > If you did not find an hid or cid match, punt
> > 
> > I think this is what my patch is doing.
> > 
> > when looking for a driver: (acpi_bus_find_driver) 
> > I check against the HID  
> > return if found  
> > Then I check against the CID 
> > return if found 
> > else 
> > punt 
> > 
> > Any objections to pushing this into -mm and dropping the motherboard 
> > change?

> I'd prefer not take this way. The ACPI driver model is already mess
> enough, let's don't make it worse. We are converting the ACPI driver
> model to Linux driver model, this will make the attempt difficult.

I see that driver_bind() and driver_probe_device() don't mesh well
with the idea that multiple drivers might be able to claim a device,
because there doesn't seem to be a way to prioritize one driver
over another.  Is that the problem you're referring to?

If we decide that "try HID first, then try CID" is the right thing,
I think we should figure out how to make that work.  Maybe that
means extending the driver model somehow.

> We can let the motherboard driver not bind to your device (say we didn't
> register the motherboard driver, but just reserve the resource of the
> deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
> mem region of the device too).

My point was that ACPI tells us what resources the device uses,
and we should reserve all of them so we accurately model the system.

Reserving resources without registering the driver sounds like a hack
to work around broken behavior elsewhere, so I don't think it's a
good idea.

Bjorn

RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Thu, 2006-09-07 at 04:04 +0800, keith mannthey wrote:
> On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote: 
> > From one of the ACPI guys: 
> >  
> > > Get hid 
> > > Look for driver 
> > > If you find a match, load it 
> > > If no match, get CID 
> > > Look for driver 
> > > If you find a match, load it 
> > > If you did not find an hid or cid match, punt
> 
> I think this is what my patch is doing.
> 
> when looking for a driver: (acpi_bus_find_driver) 
> I check against the HID  
> return if found  
> Then I check against the CID 
> return if found 
> else 
> punt 
> 
> Any objections to pushing this into -mm and dropping the motherboard 
> change?
I'd prefer not take this way. The ACPI driver model is already mess
enough, let's don't make it worse. We are converting the ACPI driver
model to Linux driver model, this will make the attempt difficult.

We can let the motherboard driver not bind to your device (say we didn't
register the motherboard driver, but just reserve the resource of the
deivce). Is it ok to you? (I remember Bjorn said he wants to reserve the
mem region of the device too).

Thanks,
Shaohua

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Wed, 2006-09-06 at 11:59 -0700, Moore, Robert wrote:
> From one of the ACPI guys:
> 
> > Get hid
> > Look for driver
> > If you find a match, load it
> > If no match, get CID
> > Look for driver
> > If you find a match, load it
> > If you did not find an hid or cid match, punt

I think this is what my patch is doing.

when looking for a driver: (acpi_bus_find_driver)
I check against the HID 
return if found 
Then I check against the CID
return if found
else
punt 

Any objections to pushing this into -mm and dropping the motherboard
change?

Thanks,
  Keith 
  

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Moore, Robert]

>From one of the ACPI guys:

> Get hid
> Look for driver
> If you find a match, load it
> If no match, get CID
> Look for driver
> If you find a match, load it
> If you did not find an hid or cid match, punt



> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of keith mannthey
> Sent: Wednesday, September 06, 2006 11:14 AM
> To: Bjorn Helgaas
> Cc: Len Brown; Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew
Morton;
> lkml; linux acpi; KAMEZAWA Hiroyuki
> Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
code:
> 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> 
> On Fri, 2006-09-01 at 17:20 -0600, Bjorn Helgaas wrote:
> > On Friday 01 September 2006 17:01, keith mannthey wrote:
> > > On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > > > The current ACPI driver binding algorithm in
acpi_bus_find_driver()
> > > > looks at each driver, checking whether it can match either the
_HID
> > > > or the _CID of a device.  Since we try the motherboard driver
first,
> > > > it matches the memory device _CID.
> > >
> > > Ok I reverted the motherboard driver patch and cooked up the
following
> > > patch that works for my issue.
> > >
> > >   It creates the idea that acpi_match_ids has a type of request to
> check
> > > against for _HID, _CID or both.  See acpi_bus_match_req. I then
fix up
> > > all the needed callers to change the API to acpi_match_ids and
> > > acpi_bus_match and have callers can say what they want to match
> > > against.
> > >
> > >   Then in acpi_bus_find_driver I have it do 2 passes to search for
> _HID
> > > first then the _CID.
> > >
> > > Does this look like it is in the right ballpark or should we be
doing
> > > something else?  Built/tested against 2.6.18-rc4-mm3.
> >
> > Conceptually I like this much better than mucking with the
motherboard
> > driver.  I'm not sure the important people have signed off on this
> > strategy of binding with _HID first, then _CID (hi, Len :-))  Maybe
> > there are ramifications that we need to consider.  But I think it
> > is a better match for "what people expect should happen."
> 
> ACPI folks can we get some response to this?  This problem has been
> reported a few times against the -mm tree and I would like to get the
> proper fix (whatever it is) upstream sometime soon.
> 
> Bjorn thanks for the help and for pointing the error reports in the
> right direction.
> 
> Thanks,
>   Keith
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Fri, 2006-09-01 at 17:20 -0600, Bjorn Helgaas wrote:
> On Friday 01 September 2006 17:01, keith mannthey wrote:
> > On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > > The current ACPI driver binding algorithm in acpi_bus_find_driver()
> > > looks at each driver, checking whether it can match either the _HID
> > > or the _CID of a device.  Since we try the motherboard driver first,
> > > it matches the memory device _CID.
> > 
> > Ok I reverted the motherboard driver patch and cooked up the following
> > patch that works for my issue.  
> > 
> >   It creates the idea that acpi_match_ids has a type of request to check
> > against for _HID, _CID or both.  See acpi_bus_match_req. I then fix up
> > all the needed callers to change the API to acpi_match_ids and
> > acpi_bus_match and have callers can say what they want to match
> > against. 
> >   
> >   Then in acpi_bus_find_driver I have it do 2 passes to search for _HID
> > first then the _CID.  
> > 
> > Does this look like it is in the right ballpark or should we be doing
> > something else?  Built/tested against 2.6.18-rc4-mm3. 
> 
> Conceptually I like this much better than mucking with the motherboard
> driver.  I'm not sure the important people have signed off on this
> strategy of binding with _HID first, then _CID (hi, Len :-))  Maybe
> there are ramifications that we need to consider.  But I think it
> is a better match for "what people expect should happen."

ACPI folks can we get some response to this?  This problem has been
reported a few times against the -mm tree and I would like to get the
proper fix (whatever it is) upstream sometime soon. 

Bjorn thanks for the help and for pointing the error reports in the
right direction. 

Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Friday 01 September 2006 17:01, keith mannthey wrote:
> On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > The current ACPI driver binding algorithm in acpi_bus_find_driver()
> > looks at each driver, checking whether it can match either the _HID
> > or the _CID of a device.  Since we try the motherboard driver first,
> > it matches the memory device _CID.
> 
> Ok I reverted the motherboard driver patch and cooked up the following
> patch that works for my issue.  
> 
>   It creates the idea that acpi_match_ids has a type of request to check
> against for _HID, _CID or both.  See acpi_bus_match_req. I then fix up
> all the needed callers to change the API to acpi_match_ids and
> acpi_bus_match and have callers can say what they want to match
> against. 
>   
>   Then in acpi_bus_find_driver I have it do 2 passes to search for _HID
> first then the _CID.  
> 
> Does this look like it is in the right ballpark or should we be doing
> something else?  Built/tested against 2.6.18-rc4-mm3. 

Conceptually I like this much better than mucking with the motherboard
driver.  I'm not sure the important people have signed off on this
strategy of binding with _HID first, then _CID (hi, Len :-))  Maybe
there are ramifications that we need to consider.  But I think it
is a better match for "what people expect should happen."

> Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>
> 
> 
> diff -urN linux-2.6.17-orig/drivers/acpi/scan.c linux-2.6.17/drivers/acpi/scan.c
> --- linux-2.6.17-orig/drivers/acpi/scan.c	2006-09-01 17:11:37.000000000 -0400
> +++ linux-2.6.17/drivers/acpi/scan.c	2006-09-01 18:13:53.000000000 -0400
> @@ -235,13 +235,13 @@
>  	return 0;
>  }
>  
> -int acpi_match_ids(struct acpi_device *device, char *ids)
> +int acpi_match_ids(struct acpi_device *device, char *ids, int type)
>  {
> -	if (device->flags.hardware_id)
> +	if ((device->flags.hardware_id) && (type != ACPI_BUS_MATCH_CID))
>  		if (strstr(ids, device->pnp.hardware_id))
>  			return 0;
>  
> -	if (device->flags.compatible_ids) {
> +	if ((device->flags.compatible_ids) && (type != ACPI_BUS_MATCH_HID)) {
>  		struct acpi_compatible_id_list *cid_list = device->pnp.cid_list;
>  		int i;
>  
> @@ -329,7 +329,8 @@
>  
>  	device->wakeup.flags.valid = 1;
>  	/* Power button, Lid switch always enable wakeup */
> -	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E"))
> +	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E", 
> +							ACPI_BUS_MATCH_ALL))
>  		device->wakeup.flags.run_wake = 1;
>  
>        end:
> @@ -471,11 +472,11 @@
>   * matches the specified driver's criteria.
>   */
>  static int
> -acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver)
> +acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver, int type)
>  {
>  	if (driver && driver->ops.match)
>  		return driver->ops.match(device, driver);
> -	return acpi_match_ids(device, driver->ids);
> +	return acpi_match_ids(device, driver->ids, type);
>  }
>  
>  /**
> @@ -549,7 +550,7 @@
>  			continue;
>  		spin_unlock(&acpi_device_lock);
>  
> -		if (!acpi_bus_match(dev, drv)) {
> +		if (!acpi_bus_match(dev, drv, ACPI_BUS_MATCH_ALL)) {
>  			if (!acpi_bus_driver_init(dev, drv)) {
>  				acpi_start_single_object(dev);
>  				atomic_inc(&drv->references);
> @@ -651,7 +652,22 @@
>  
>  		atomic_inc(&driver->references);
>  		spin_unlock(&acpi_device_lock);
> -		if (!acpi_bus_match(device, driver)) {
> +		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_HID)) {
> +			result = acpi_bus_driver_init(device, driver);
> +			if (!result)
> +				goto Done;
> +		}
> +		atomic_dec(&driver->references);
> +		spin_lock(&acpi_device_lock);
> +	}
> +
> +	list_for_each_safe(node, next, &acpi_bus_drivers) {
> +		struct acpi_driver *driver =
> +		    container_of(node, struct acpi_driver, node);
> +
> +		atomic_inc(&driver->references);
> +		spin_unlock(&acpi_device_lock);
> +		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_ALL)) {
>  			result = acpi_bus_driver_init(device, driver);
>  			if (!result)
>  				goto Done;
> diff -urN linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c linux-2.6.17/drivers/pnp/pnpacpi/core.c
> --- linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c	2006-09-01 17:11:37.000000000 -0400
> +++ linux-2.6.17/drivers/pnp/pnpacpi/core.c	2006-09-01 18:03:26.000000000 -0400
> @@ -41,7 +41,7 @@
>  	;
>  static inline int is_exclusive_device(struct acpi_device *dev)
>  {
> -	return (!acpi_match_ids(dev, excluded_id_list));
> +	return (!acpi_match_ids(dev, excluded_id_list, ACPI_BUS_MATCH_ALL));
>  }
>  
>  /*
> diff -urN linux-2.6.17-orig/include/acpi/acpi_bus.h linux-2.6.17/include/acpi/acpi_bus.h
> --- linux-2.6.17-orig/include/acpi/acpi_bus.h	2006-09-01 17:11:38.000000000 -0400
> +++ linux-2.6.17/include/acpi/acpi_bus.h	2006-09-01 18:00:27.000000000 -0400
> @@ -79,6 +79,12 @@
>  	ACPI_BUS_DEVICE_TYPE_COUNT
>  };
>  
> +enum acpi_bus_match_req {
> +	ACPI_BUS_MATCH_HID = 0,
> +	ACPI_BUS_MATCH_CID,
> +	ACPI_BUS_MATCH_ALL
> +};
> +
>  struct acpi_driver;
>  struct acpi_device;
>  
> @@ -335,7 +341,7 @@
>  int acpi_bus_trim(struct acpi_device *start, int rmdevice);
>  int acpi_bus_start(struct acpi_device *device);
>  acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd);
> -int acpi_match_ids(struct acpi_device *device, char *ids);
> +int acpi_match_ids(struct acpi_device *device, char *ids, int type);
>  int acpi_create_dir(struct acpi_device *);
>  void acpi_remove_dir(struct acpi_device *);
>  
> 
> 
> 

-- 
VGER BF report: H 0

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-08-31 at 21:15 -0600, Bjorn Helgaas wrote:
> > On Thu, 2006-08-31 at 17:06 -0600, Bjorn Helgaas wrote:
> >> Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
> >> like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.
> >
> > Sure great sounds.  I understand AE_OK is a 0 return so I can change it
> > to AE_CTRL_TERMINATE.  I don't want  acpi_reserve_io_ranges to return a
> > happy state when if finds a resource type is doesn't know.
> 
> Except that when the motherboard driver claims a device, it really
> should claim all the resources used by the device.  It currently only
> claims I/O port resources, but I think it should also claim MMIO
> resources.  Otherwise, the system resource accounting is screwed up,
> and resources consumed by the motherboard device could be mistakenly
> allocated to another device.
> 
> > Kame (who helped me greatly in tracking down the source my troubles)
> > thinks that the root cause is that the device (my memory_device) has
> > both a _HID and _CID. The driver for _HID is different for _CID and the
> > driver for _CID is found before _HID and I pass the wrong device up the
> > chain.
> 
> Ok, this is starting to make sense.  It sounds like your memory
> device has _HID of PNP0C80 and _CID of PNP0C01 (or PNP0C02).
> 
> The current ACPI driver binding algorithm in acpi_bus_find_driver()
> looks at each driver, checking whether it can match either the _HID
> or the _CID of a device.  Since we try the motherboard driver first,
> it matches the memory device _CID.

Ok I reverted the motherboard driver patch and cooked up the following
patch that works for my issue.  

  It creates the idea that acpi_match_ids has a type of request to check
against for _HID, _CID or both.  See acpi_bus_match_req. I then fix up
all the needed callers to change the API to acpi_match_ids and
acpi_bus_match and have callers can say what they want to match
against. 
  
  Then in acpi_bus_find_driver I have it do 2 passes to search for _HID
first then the _CID.  

Does this look like it is in the right ballpark or should we be doing
something else?  Built/tested against 2.6.18-rc4-mm3. 

Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>


diff -urN linux-2.6.17-orig/drivers/acpi/scan.c linux-2.6.17/drivers/acpi/scan.c
--- linux-2.6.17-orig/drivers/acpi/scan.c	2006-09-01 17:11:37.000000000 -0400
+++ linux-2.6.17/drivers/acpi/scan.c	2006-09-01 18:13:53.000000000 -0400
@@ -235,13 +235,13 @@
 	return 0;
 }
 
-int acpi_match_ids(struct acpi_device *device, char *ids)
+int acpi_match_ids(struct acpi_device *device, char *ids, int type)
 {
-	if (device->flags.hardware_id)
+	if ((device->flags.hardware_id) && (type != ACPI_BUS_MATCH_CID))
 		if (strstr(ids, device->pnp.hardware_id))
 			return 0;
 
-	if (device->flags.compatible_ids) {
+	if ((device->flags.compatible_ids) && (type != ACPI_BUS_MATCH_HID)) {
 		struct acpi_compatible_id_list *cid_list = device->pnp.cid_list;
 		int i;
 
@@ -329,7 +329,8 @@
 
 	device->wakeup.flags.valid = 1;
 	/* Power button, Lid switch always enable wakeup */
-	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E"))
+	if (!acpi_match_ids(device, "PNP0C0D,PNP0C0C,PNP0C0E", 
+							ACPI_BUS_MATCH_ALL))
 		device->wakeup.flags.run_wake = 1;
 
       end:
@@ -471,11 +472,11 @@
  * matches the specified driver's criteria.
  */
 static int
-acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver)
+acpi_bus_match(struct acpi_device *device, struct acpi_driver *driver, int type)
 {
 	if (driver && driver->ops.match)
 		return driver->ops.match(device, driver);
-	return acpi_match_ids(device, driver->ids);
+	return acpi_match_ids(device, driver->ids, type);
 }
 
 /**
@@ -549,7 +550,7 @@
 			continue;
 		spin_unlock(&acpi_device_lock);
 
-		if (!acpi_bus_match(dev, drv)) {
+		if (!acpi_bus_match(dev, drv, ACPI_BUS_MATCH_ALL)) {
 			if (!acpi_bus_driver_init(dev, drv)) {
 				acpi_start_single_object(dev);
 				atomic_inc(&drv->references);
@@ -651,7 +652,22 @@
 
 		atomic_inc(&driver->references);
 		spin_unlock(&acpi_device_lock);
-		if (!acpi_bus_match(device, driver)) {
+		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_HID)) {
+			result = acpi_bus_driver_init(device, driver);
+			if (!result)
+				goto Done;
+		}
+		atomic_dec(&driver->references);
+		spin_lock(&acpi_device_lock);
+	}
+
+	list_for_each_safe(node, next, &acpi_bus_drivers) {
+		struct acpi_driver *driver =
+		    container_of(node, struct acpi_driver, node);
+
+		atomic_inc(&driver->references);
+		spin_unlock(&acpi_device_lock);
+		if (!acpi_bus_match(device, driver, ACPI_BUS_MATCH_ALL)) {
 			result = acpi_bus_driver_init(device, driver);
 			if (!result)
 				goto Done;
diff -urN linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c linux-2.6.17/drivers/pnp/pnpacpi/core.c
--- linux-2.6.17-orig/drivers/pnp/pnpacpi/core.c	2006-09-01 17:11:37.000000000 -0400
+++ linux-2.6.17/drivers/pnp/pnpacpi/core.c	2006-09-01 18:03:26.000000000 -0400
@@ -41,7 +41,7 @@
 	;
 static inline int is_exclusive_device(struct acpi_device *dev)
 {
-	return (!acpi_match_ids(dev, excluded_id_list));
+	return (!acpi_match_ids(dev, excluded_id_list, ACPI_BUS_MATCH_ALL));
 }
 
 /*
diff -urN linux-2.6.17-orig/include/acpi/acpi_bus.h linux-2.6.17/include/acpi/acpi_bus.h
--- linux-2.6.17-orig/include/acpi/acpi_bus.h	2006-09-01 17:11:38.000000000 -0400
+++ linux-2.6.17/include/acpi/acpi_bus.h	2006-09-01 18:00:27.000000000 -0400
@@ -79,6 +79,12 @@
 	ACPI_BUS_DEVICE_TYPE_COUNT
 };
 
+enum acpi_bus_match_req {
+	ACPI_BUS_MATCH_HID = 0,
+	ACPI_BUS_MATCH_CID,
+	ACPI_BUS_MATCH_ALL
+};
+
 struct acpi_driver;
 struct acpi_device;
 
@@ -335,7 +341,7 @@
 int acpi_bus_trim(struct acpi_device *start, int rmdevice);
 int acpi_bus_start(struct acpi_device *device);
 acpi_status acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd);
-int acpi_match_ids(struct acpi_device *device, char *ids);
+int acpi_match_ids(struct acpi_device *device, char *ids, int type);
 int acpi_create_dir(struct acpi_device *);
 void acpi_remove_dir(struct acpi_device *);
 



-- 
VGER BF report: H 0.238464

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[KAMEZAWA Hiroyuki]

On Thu, 31 Aug 2006 21:15:55 -0600 (MDT)
"Bjorn Helgaas" <bjorn.helgaas@hp.com> wrote:

> Ok, this is starting to make sense.  It sounds like your memory
> device has _HID of PNP0C80 and _CID of PNP0C01 (or PNP0C02).
> 
> The current ACPI driver binding algorithm in acpi_bus_find_driver()
> looks at each driver, checking whether it can match either the _HID
> or the _CID of a device.  Since we try the motherboard driver first,
> it matches the memory device _CID.
> 
> I couldn't find a specific reference in the spec, but this seems
> intuitively sub-optimal.  It seems like it'd be better to look
> first for a driver that can claim the _HID (which is more specific),
> and only fall back to checking the _CIDs if no _HID-specific driver
> is found.
> 
I like it :)

-Kame

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

> > Also see   
> > http://sourceforge.net/mailarchive/forum.php? 
> > thread_id=15282420&forum_id=223
> > 
> > I don't claim this is the ACPI correct solution and am welcome to any 
> > input that fixes my issue: acpi_bus_find_driver returning the
> > incorrect 
> > driver for a given handle.    
> Then the issue is your device _CID returned PNP0C01 or PNP0C02. Is this
> intended? Can we change the BIOS?

  The spec talks about _HID for the memory device and that is ok but I
don't see any reference to required _CID. My _CID is listed as hex.  Can
I just convert it?

 Changing the bios is a little bit of a long shot at this point. 

Thanks,
  Keith 

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

> On Thu, 2006-08-31 at 17:06 -0600, Bjorn Helgaas wrote:
>> Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
>> like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.
>
> Sure great sounds.  I understand AE_OK is a 0 return so I can change it
> to AE_CTRL_TERMINATE.  I don't want  acpi_reserve_io_ranges to return a
> happy state when if finds a resource type is doesn't know.

Except that when the motherboard driver claims a device, it really
should claim all the resources used by the device.  It currently only
claims I/O port resources, but I think it should also claim MMIO
resources.  Otherwise, the system resource accounting is screwed up,
and resources consumed by the motherboard device could be mistakenly
allocated to another device.

> Kame (who helped me greatly in tracking down the source my troubles)
> thinks that the root cause is that the device (my memory_device) has
> both a _HID and _CID. The driver for _HID is different for _CID and the
> driver for _CID is found before _HID and I pass the wrong device up the
> chain.

Ok, this is starting to make sense.  It sounds like your memory
device has _HID of PNP0C80 and _CID of PNP0C01 (or PNP0C02).

The current ACPI driver binding algorithm in acpi_bus_find_driver()
looks at each driver, checking whether it can match either the _HID
or the _CID of a device.  Since we try the motherboard driver first,
it matches the memory device _CID.

I couldn't find a specific reference in the spec, but this seems
intuitively sub-optimal.  It seems like it'd be better to look
first for a driver that can claim the _HID (which is more specific),
and only fall back to checking the _CIDs if no _HID-specific driver
is found.

This looks fairly easy to do in ACPI.  Not so easy in PNPACPI,
since I don't think PNP has the concept of _HID vs _CID.  Maybe
Len will chime in with an opinion.

Bjorn

Re: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Shaohua Li]

On Fri, 2006-09-01 at 09:19 +0800, keith mannthey wrote:
> On Thu, 2006-08-31 at 17:06 -0600, Bjorn Helgaas wrote: 
> > On Thursday 31 August 2006 10:48, keith mannthey wrote: 
> > > On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote: 
> > > > On Tuesday 29 August 2006 16:04, Moore, Robert wrote: 
> > > > > As far as the unknown exception, 
> > > > >  
> > > > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e 
> > > > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b 
> > > > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31 
> > > > >  
> > > > > I would guess that the callback routine for walk_resources is
> returning 
> > > > > a non-zero status value which is causing an immediate abort of
> the walk 
> > > > > with that value -- and the value is bogus. 
> > >  
> > >   Before I put this check in acpi_motherboard_add always attached
> itself 
> > > to any resource type. I simply changed it so if the type is not 
> > > ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't
> attach 
> > > and can continue to find the correct device to attach to. 
> > >  
> > >   Perhaps the motherboard device needs to attach to more device
> types?   
> > >  
> > >   It was suggest by acpi folks to return -EINVAL.  Should
> something else 
> > > be returned?  
> >  
> > Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status 
> > like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.
> 
> Sure great sounds.  I understand AE_OK is a 0 return so I can change
> it 
> to AE_CTRL_TERMINATE.  I don't want  acpi_reserve_io_ranges to return
> a 
> happy state when if finds a resource type is doesn't know.   
>   
> > Problem 2: I don't understand how your patch works.  An ACPI device 
> > has a list of resources it uses.  Are you saying that claiming all 
> > the IO port resources of a PNP0C01 or PNP0C02 device causes the
> ACPI 
> > memory hotplug driver to fail? 
> >  
>   I don't know a whole heck of a lot about ACPI but let me try and 
> explain the situation as best I can. I will attach my SSDT as well. 
> Memory devices are PNP0C80. 
> 
>    What the acpi_memory_device_driver is loaded in the system and you
> do 
> a hot-add event the following call path takes place...
> 
> acpi_memory_get_device 
>   acpi_bus_add 
>     acpi_add_single_object 
>       acpi_bus_find_driver 
>         acpi_bus_driver_init 
>           driver->ops.add
> 
>   The problem is the motherboard driver driver->ops.add is called
> before 
> my memory device is scanned and it ALWASY returns AE_OK. Such that
> the 
> device that is passed back up to that acpi_memory_get_device is NOT
> the 
> memory_device_driver but this motherboard device and the add fails 
> bigtime.  I need acpi_find_bus_driver to return to me the 
> acpi_memory_device_driver not the motherboard driver.  
> 
>   It seems pretty sane to be to have the add 
> 
> > Is there some conflict between those PNP0C01 resources and the 
> > resources of a hotplug memory device?  Can you figure out exactly 
> > what the conflict is by disassembling the DSDT for those devices?
> 
> Kame (who helped me greatly in tracking down the source my troubles) 
> thinks that the root cause is that the device (my memory_device) has 
> both a _HID and _CID. The driver for _HID is different for _CID and
> the 
> driver for _CID is found before _HID and I pass the wrong device up
> the 
> chain. 
> 
> > We should understand this better before introducing special cases 
> > to the motherboard driver.  We should be able to trust the ACPI 
> > description of the motherboard resources.  The motherboard driver 
> > currently claims only I/O port resources, but it really should 
> > claim MMIO resources as well.
> 
> The design of my patch is to make the motherboard driver return 
> something other than 0 when it's driver->ops.add is called with
> resource 
> types that are not what it expects.  
> 
> This way the scan if acpi_bus_find_driver will fine the correct acpi 
> device. 
> 
> Also see   
> http://sourceforge.net/mailarchive/forum.php? 
> thread_id=15282420&forum_id=223
> 
> I don't claim this is the ACPI correct solution and am welcome to any 
> input that fixes my issue: acpi_bus_find_driver returning the
> incorrect 
> driver for a given handle.    
Then the issue is your device _CID returned PNP0C01 or PNP0C02. Is this
intended? Can we change the BIOS?

Thanks,
Shaohua

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Bjorn Helgaas]

On Thursday 31 August 2006 10:48, keith mannthey wrote:
> On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > As far as the unknown exception,
> > > 
> > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > > 
> > > I would guess that the callback routine for walk_resources is returning
> > > a non-zero status value which is causing an immediate abort of the walk
> > > with that value -- and the value is bogus.
> 
>   Before I put this check in acpi_motherboard_add always attached itself
> to any resource type. I simply changed it so if the type is not
> ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> and can continue to find the correct device to attach to.
> 
>   Perhaps the motherboard device needs to attach to more device types?  
> 
>   It was suggest by acpi folks to return -EINVAL.  Should something else
> be returned? 

Problem 1: acpi_reserve_io_ranges() needs to return an acpi_status
like AE_OK or AE_CTRL_TERMINATE, not a -EINVAL.

Problem 2: I don't understand how your patch works.  An ACPI device
has a list of resources it uses.  Are you saying that claiming all
the IO port resources of a PNP0C01 or PNP0C02 device causes the ACPI
memory hotplug driver to fail?

Is there some conflict between those PNP0C01 resources and the
resources of a hotplug memory device?  Can you figure out exactly
what the conflict is by disassembling the DSDT for those devices?

We should understand this better before introducing special cases
to the motherboard driver.  We should be able to trust the ACPI
description of the motherboard resources.  The motherboard driver
currently claims only I/O port resources, but it really should
claim MMIO resources as well.

> > http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > 
> > From: Keith Mannthey <kmannth@us.ibm.com>
> > ...
> > Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
> > Fix a bug where the motherboard driver attached to hot-add memory event and
> > caused the add memory call to fail.
> > 
> > Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Cc: Andi Kleen <ak@muc.de>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
> > --- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > +++ a/drivers/acpi/motherboard.c
> > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> >  		}
> >  	} else {
> >  		/* Memory mapped IO? */
> > +		 return -EINVAL;
> >  	}
> >  
> >  	if (requested_res)
> > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> >  
> >  static int acpi_motherboard_add(struct acpi_device *device)
> >  {
> > +	acpi_status status;
> >  	if (!device)
> >  		return -EINVAL;
> > -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > +
> > +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> >  			    acpi_reserve_io_ranges, NULL);
> >  
> > +	if (ACPI_FAILURE(status))
> > +		return -ENODEV;
> > +
> >  	return 0;
> >  }

RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-08-31 at 10:02 -0700, Moore, Robert wrote: 
> Return AE_OK to continue the walk. AE_CTRL_DEPTH will cause the walk to
> continue, but go no further down the current branch of the namespace.
> 
> Anything other than these two exceptions will completely abort the walk.

Let me check with AE_OK (this is non-zero?).  It will be several hours. 

Thanks,
  Keith 


> > -----Original Message-----
> > From: keith mannthey [mailto:kmannth@us.ibm.com]
> > Sent: Thursday, August 31, 2006 9:49 AM
> > To: Len Brown
> > Cc: Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew Morton; lkml;
> linux
> > acpi; KAMEZAWA Hiroyuki
> > Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
> > code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> > 
> > On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > > As far as the unknown exception,
> > > >
> > > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > > >
> > > > I would guess that the callback routine for walk_resources is
> > returning
> > > > a non-zero status value which is causing an immediate abort of the
> > walk
> > > > with that value -- and the value is bogus.
> > 
> >   Before I put this check in acpi_motherboard_add always attached
> itself
> > to any resource type. I simply changed it so if the type is not
> > ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> > and can continue to find the correct device to attach to.
> > 
> >   Perhaps the motherboard device needs to attach to more device types?
> > 
> >   It was suggest by acpi folks to return -EINVAL.  Should something
> else
> > be returned?
> > 
> > 
> > Thanks,
> >   Keith
> > 
> > > Yep, see -EINVAL below.
> > >
> > > -Len
> > >
> > >
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> > rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-
> > fix.patch
> > >
> > >
> > >
> > > From: Keith Mannthey <kmannth@us.ibm.com>
> > >
> > > This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I
> > have
> > > test both options and they work as expected.  I am adding memory to
> the
> > > 2nd node of a numa system (x86_64).
> > >
> > > Major changes from last set is the config change and RESERVE
> enablment.
> > >
> > >
> > > This patch:
> > >
> > >
> > > Make ACPI motherboard driver not attach to devices/handles it
> dosen't
> > expect.
> > > Fix a bug where the motherboard driver attached to hot-add memory
> event
> > and
> > > caused the add memory call to fail.
> > >
> > > Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> > > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > > Cc: Andi Kleen <ak@muc.de>
> > > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > > ---
> > >
> > >
> > > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-
> > motherboard-fix drivers/acpi/motherboard.c
> > > ---
> a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > > +++ a/drivers/acpi/motherboard.c
> > > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> > >  		}
> > >  	} else {
> > >  		/* Memory mapped IO? */
> > > +		 return -EINVAL;
> > >  	}
> > >
> > >  	if (requested_res)
> > > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> > >
> > >  static int acpi_motherboard_add(struct acpi_device *device)
> > >  {
> > > +	acpi_status status;
> > >  	if (!device)
> > >  		return -EINVAL;
> > > -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > > +
> > > +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > >  			    acpi_reserve_io_ranges, NULL);
> > >
> > > +	if (ACPI_FAILURE(status))
> > > +		return -ENODEV;
> > > +
> > >  	return 0;
> > >  }
> > >
> > > _

RE: one more ACPI Error (utglobal-0125): Unknown exception code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Moore, Robert]

Return AE_OK to continue the walk. AE_CTRL_DEPTH will cause the walk to
continue, but go no further down the current branch of the namespace.

Anything other than these two exceptions will completely abort the walk.

Bob


> -----Original Message-----
> From: keith mannthey [mailto:kmannth@us.ibm.com]
> Sent: Thursday, August 31, 2006 9:49 AM
> To: Len Brown
> Cc: Moore, Robert; Li, Shaohua; Mattia Dongili; Andrew Morton; lkml;
linux
> acpi; KAMEZAWA Hiroyuki
> Subject: Re: one more ACPI Error (utglobal-0125): Unknown exception
> code:0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> 
> On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> > On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > > As far as the unknown exception,
> > >
> > > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > >
> > > I would guess that the callback routine for walk_resources is
> returning
> > > a non-zero status value which is causing an immediate abort of the
> walk
> > > with that value -- and the value is bogus.
> 
>   Before I put this check in acpi_motherboard_add always attached
itself
> to any resource type. I simply changed it so if the type is not
> ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
> and can continue to find the correct device to attach to.
> 
>   Perhaps the motherboard device needs to attach to more device types?
> 
>   It was suggest by acpi folks to return -EINVAL.  Should something
else
> be returned?
> 
> 
> Thanks,
>   Keith
> 
> > Yep, see -EINVAL below.
> >
> > -Len
> >
> >
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-
> fix.patch
> >
> >
> >
> > From: Keith Mannthey <kmannth@us.ibm.com>
> >
> > This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I
> have
> > test both options and they work as expected.  I am adding memory to
the
> > 2nd node of a numa system (x86_64).
> >
> > Major changes from last set is the config change and RESERVE
enablment.
> >
> >
> > This patch:
> >
> >
> > Make ACPI motherboard driver not attach to devices/handles it
dosen't
> expect.
> > Fix a bug where the motherboard driver attached to hot-add memory
event
> and
> > caused the add memory call to fail.
> >
> > Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > Cc: Andi Kleen <ak@muc.de>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> >
> >
> > diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-
> motherboard-fix drivers/acpi/motherboard.c
> > ---
a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> > +++ a/drivers/acpi/motherboard.c
> > @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
> >  		}
> >  	} else {
> >  		/* Memory mapped IO? */
> > +		 return -EINVAL;
> >  	}
> >
> >  	if (requested_res)
> > @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
> >
> >  static int acpi_motherboard_add(struct acpi_device *device)
> >  {
> > +	acpi_status status;
> >  	if (!device)
> >  		return -EINVAL;
> > -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> > +
> > +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> >  			    acpi_reserve_io_ranges, NULL);
> >
> > +	if (ACPI_FAILURE(status))
> > +		return -ENODEV;
> > +
> >  	return 0;
> >  }
> >
> > _

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[keith mannthey]

On Thu, 2006-08-31 at 02:48 -0400, Len Brown wrote:
> On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> > As far as the unknown exception,
> > 
> > >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> > >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> > >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> > 
> > I would guess that the callback routine for walk_resources is returning
> > a non-zero status value which is causing an immediate abort of the walk
> > with that value -- and the value is bogus.

  Before I put this check in acpi_motherboard_add always attached itself
to any resource type. I simply changed it so if the type is not
ACPI_RESOURCE_TYPE_IO or ACPI_RESOURCE_TYPE_FIXED_IO it doesn't attach
and can continue to find the correct device to attach to.

  Perhaps the motherboard device needs to attach to more device types?  

  It was suggest by acpi folks to return -EINVAL.  Should something else
be returned? 
 

Thanks,
  Keith 

> Yep, see -EINVAL below.
> 
> -Len
> 
> http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> 
> 
> 
> From: Keith Mannthey <kmannth@us.ibm.com>
> 
> This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I have
> test both options and they work as expected.  I am adding memory to the
> 2nd node of a numa system (x86_64).
> 
> Major changes from last set is the config change and RESERVE enablment.
> 
> 
> This patch:
> 
> 
> Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
> Fix a bug where the motherboard driver attached to hot-add memory event and
> caused the add memory call to fail.
> 
> Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Cc: Andi Kleen <ak@muc.de>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
> 
> 
> diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
> --- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
> +++ a/drivers/acpi/motherboard.c
> @@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
>  		}
>  	} else {
>  		/* Memory mapped IO? */
> +		 return -EINVAL;
>  	}
>  
>  	if (requested_res)
> @@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
>  
>  static int acpi_motherboard_add(struct acpi_device *device)
>  {
> +	acpi_status status;
>  	if (!device)
>  		return -EINVAL;
> -	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
> +
> +	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
>  			    acpi_reserve_io_ranges, NULL);
>  
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
>  	return 0;
>  }
>  
> _

Re: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Len Brown]

On Tuesday 29 August 2006 16:04, Moore, Robert wrote:
> As far as the unknown exception,
> 
> >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> 
> I would guess that the callback routine for walk_resources is returning
> a non-zero status value which is causing an immediate abort of the walk
> with that value -- and the value is bogus.

Yep, see -EINVAL below.

-Len

http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch



From: Keith Mannthey <kmannth@us.ibm.com>

This patch set allow SPARSEMEM and RESERVE based hot-add to work.  I have
test both options and they work as expected.  I am adding memory to the
2nd node of a numa system (x86_64).

Major changes from last set is the config change and RESERVE enablment.


This patch:


Make ACPI motherboard driver not attach to devices/handles it dosen't expect.
Fix a bug where the motherboard driver attached to hot-add memory event and
caused the add memory call to fail.

Signed-off-by: Keith Mannthey<kmannth@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---


diff -puN drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix drivers/acpi/motherboard.c
--- a/drivers/acpi/motherboard.c~hot-add-mem-x86_64-acpi-motherboard-fix
+++ a/drivers/acpi/motherboard.c
@@ -87,6 +87,7 @@ static acpi_status acpi_reserve_io_range
 		}
 	} else {
 		/* Memory mapped IO? */
+		 return -EINVAL;
 	}
 
 	if (requested_res)
@@ -96,11 +97,16 @@ static acpi_status acpi_reserve_io_range
 
 static int acpi_motherboard_add(struct acpi_device *device)
 {
+	acpi_status status;
 	if (!device)
 		return -EINVAL;
-	acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+
+	status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
 			    acpi_reserve_io_ranges, NULL);
 
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
 	return 0;
 }
 
_

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Moore, Robert]

As far as the unknown exception,

>[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
>[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
>[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31

I would guess that the callback routine for walk_resources is returning
a non-zero status value which is causing an immediate abort of the walk
with that value -- and the value is bogus.

Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Li, Shaohua
> Sent: Monday, August 28, 2006 7:06 PM
> To: Mattia Dongili; Andrew Morton
> Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> Subject: RE: one more ACPI Error (utglobal-0125): Unknown exception
code:
> 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> 
> 
> 
> >-----Original Message-----
> >From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
> >owner@vger.kernel.org] On Behalf Of Mattia Dongili
> >Sent: Tuesday, August 29, 2006 4:24 AM
> >To: Andrew Morton
> >Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
> >Subject: one more ACPI Error (utglobal-0125): Unknown exception code:
> >0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
> >
> >On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
> >>
> >>
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
> >rc4/2.6.18-rc4-mm3/
> >[...]
> >>  git-acpi.patch
> >
> >Sorry for reporting separately, I deleted the other thread on the
> issue.
> >Here we go:
> >[    9.386644] PCI: Using ACPI for IRQ routing
> >[    9.386688] PCI: If a device doesn't work, try "pci=routeirq".  If
> it
> >helps, post a report
> >[    9.391209] ACPI Error (utglobal-0125): Unknown exception code:
> >0xFFFFFFEA [20060707]
> >[    9.391521]  [<c0103a9f>] dump_trace+0x1ef/0x230
> >[    9.391626]  [<c0103b06>] show_trace_log_lvl+0x26/0x40
> >[    9.391724]  [<c01042bb>] show_trace+0x1b/0x20
> >[    9.391820]  [<c01043a4>] dump_stack+0x24/0x30
> >[    9.391918]  [<c0249f15>] acpi_format_exception+0xa3/0xb0
> >[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
> >[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
> >[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
> >[    9.394977]  [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
> >[    9.395742]  [<c02568da>] acpi_bus_register_driver+0xa1/0x123
> >[    9.396507]  [<c0418adb>] acpi_motherboard_init+0x17/0xfb
> >[    9.397268]  [<c01003d0>] init+0x80/0x290
> >[    9.397343]  [<c0103593>] kernel_thread_helper+0x7/0x14
> >[    9.397439]  =======================
> >
> >full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
> >config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
> >DSDT: http://oioio.altervista.org/linux/DSDT.aml
> >      http://oioio.altervista.org/linux/DSDT.dsl
> >lspci: http://oioio.altervista.org/linux/lspci-v
> Below patch is the root cause.
>
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc
>
4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patc
> h
> 
> motherboard driver is expected to reserve resources used by
motherboard,
> so hotplug will not fail. I don't know why memory hotplug guys change
> it.
> 
> Thanks,
> Shaohua
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: one more ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [Re: 2.6.18-rc4-mm3]

[Li, Shaohua]

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>owner@vger.kernel.org] On Behalf Of Mattia Dongili
>Sent: Tuesday, August 29, 2006 4:24 AM
>To: Andrew Morton
>Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
>Subject: one more ACPI Error (utglobal-0125): Unknown exception code:
>0xFFFFFFEA [Re: 2.6.18-rc4-mm3]
>
>On Sat, Aug 26, 2006 at 04:09:22PM -0700, Andrew Morton wrote:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-
>rc4/2.6.18-rc4-mm3/
>[...]
>>  git-acpi.patch
>
>Sorry for reporting separately, I deleted the other thread on the
issue.
>Here we go:
>[    9.386644] PCI: Using ACPI for IRQ routing
>[    9.386688] PCI: If a device doesn't work, try "pci=routeirq".  If
it
>helps, post a report
>[    9.391209] ACPI Error (utglobal-0125): Unknown exception code:
>0xFFFFFFEA [20060707]
>[    9.391521]  [<c0103a9f>] dump_trace+0x1ef/0x230
>[    9.391626]  [<c0103b06>] show_trace_log_lvl+0x26/0x40
>[    9.391724]  [<c01042bb>] show_trace+0x1b/0x20
>[    9.391820]  [<c01043a4>] dump_stack+0x24/0x30
>[    9.391918]  [<c0249f15>] acpi_format_exception+0xa3/0xb0
>[    9.392729]  [<c0246fb6>] acpi_ut_status_exit+0x31/0x5e
>[    9.393453]  [<c0243352>] acpi_walk_resources+0x10e/0x11b
>[    9.394174]  [<c025697e>] acpi_motherboard_add+0x22/0x31
>[    9.394977]  [<c0255890>] acpi_bus_driver_init+0x2b/0x7c
>[    9.395742]  [<c02568da>] acpi_bus_register_driver+0xa1/0x123
>[    9.396507]  [<c0418adb>] acpi_motherboard_init+0x17/0xfb
>[    9.397268]  [<c01003d0>] init+0x80/0x290
>[    9.397343]  [<c0103593>] kernel_thread_helper+0x7/0x14
>[    9.397439]  =======================
>
>full dmesg: http://oioio.altervista.org/linux/dmesg-2.6.18-rc4-mm3-1
>config: http://oioio.altervista.org/linux/config-2.6.18-rc4-mm3-1
>DSDT: http://oioio.altervista.org/linux/DSDT.aml
>      http://oioio.altervista.org/linux/DSDT.dsl
>lspci: http://oioio.altervista.org/linux/lspci-v
Below patch is the root cause.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc
4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patc
h

motherboard driver is expected to reserve resources used by motherboard,
so hotplug will not fail. I don't know why memory hotplug guys change
it.

Thanks,
Shaohua