* 2.6.17-rc2-mm1
@ 2006-04-27 8:41 Andrew Morton
2006-04-27 10:16 ` 2.6.17-rc2-mm1 Andi Kleen
` (7 more replies)
0 siblings, 8 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-27 8:41 UTC (permalink / raw
To: linux-kernel
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
- It took six hours work to get this release building and linking in just a
basic fashion on eight-odd architectures. It's getting out of control.
The acphphp driver is still broken and v4l and memory hotplug are, I
suspect, only hanging in there by the skin of their teeth.
Could patch submitters _please_ be a lot more careful about getting the
Kconfig correct, testing various Kconfig combinations (yes sometimes
people will want to disable your lovely new feature) and just generally
think about these things a bit harder? It isn't rocket science.
- Added the GFS tree to the -mm lineup as git-gfs2.patch . The DLM patches
were consequently dropped.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
Changes since 2.6.17-rc1-mm3:
origin.patch
git-acpi.patch
git-agpgart.patch
git-alsa.patch
git-arm.patch
git-cfq.patch
git-dvb.patch
git-gfs2.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-intelfb.patch
git-libata-all.patch
git-mmc.patch
git-mtd.patch
git-netdev-all.patch
git-nfs.patch
git-ocfs2.patch
git-powerpc.patch
git-pcmcia.patch
git-scsi-misc.patch
git-scsi-rc-fixes.patch
git-scsi-target.patch
git-watchdog.patch
git-xfs.patch
git-cryptodev.patch
git-viro-bird-m32r.patch
git-viro-bird-m68k.patch
git-viro-bird-frv.patch
git-viro-bird-upf.patch
git-viro-bird-volatile.patch
git trees
-uml-make-64-bit-cow-files-compatible-with-32-bit-ones.patch
-task-make-task-list-manipulations-rcu-safe.patch
-for_each_possible_cpu-x86_64.patch
-uml-madv_remove-fixes.patch
-m41t00-fix-bitmasks-when-writing-to-chip.patch
-swsusp-prevent-possible-image-corruption-on-resume.patch
-msi-k8t-neo2-fir-onboardsound-and-additional-soundcard.patch
-sound-fix-hang-in-mpu401_uartc.patch
-sound-fix-hang-in-mpu401_uartc-tidy.patch
-for_each_possible_cpu-for-arm.patch
-block-i-o-schedulers-document-runtime-selection.patch
-drivers-char-drm-drm_memoryc-possible-cleanups.patch
-drm-fix-further-issues-in-drivers-char-drm-via_irqc.patch
-sbp2-consolidate-workarounds.patch
-sbp2-add-read_capacity-workaround-for-ipod.patch
-sbp2-make-tsb42aa9-workaround-specific-to-momobay-cx-1.patch
-sbp2-add-ability-to-override-hardwired-blacklist.patch
-mtd-improve-parameter-parsing-for-block2mtd.patch
-mtd-improve-parameter-parsing-for-block2mtd-fix.patch
-bcm43xx-sysfs-code-cleanup.patch
-bcm43xx-fix-pctl-slowclock-limit-calculation.patch
-e1000-fix-media_type-phy_type-thinko.patch
-unaligned-access-in-sk_run_filter.patch
-nfs-make-2-functions-static.patch
-remove-needless-check-in-nfs_opendir.patch
-fix-nfs-proc_fs=n-compile-error.patch
-nfssunrpc-fix-compiler-warnings-if-config_proc_fs-config_sysctl-are-unset.patch
-nfs_show_stats-for_each_possible_cpu-not-nr_cpus.patch
-powerpc-pseries-bugfix-balance-calls-to-pci_device_put.patch
-powerpc-pseries-clear-pci-failure-counter-if-no-new-failures.patch
-serial-fix-uart_bug_txen-test.patch
-git-scsi-misc-scsi_kmap_atomic_sg-warning-fix.patch
-megaraid-unused-variable.patch
-scsi-megaraid-megaraid_mmc-fix-a-null-pointer-dereference.patch
-overrun-in-drivers-scsi-sim710c.patch
-aic7xxx-ahc_pci_write_config-fix.patch
-qla2xxx-only-free_irq-after-request_irq-succeeds.patch
-git-splice-fixup.patch
-ftdi_sio-adds-support-for-iplus-device.patch
-ipw2200-config_ipw_qos-to-config_ipw2200_qos.patch
-softmac-uses-wiress-ext.patch
-bcm43xx_phyc-fix-a-memory-leak.patch
-orinoco-remove-useless-cis-validation.patch
-orinoco-remove-pcmcia-audio-support-its-useless-for-wireless-cards.patch
-orinoco-remove-underscores-from-little-endian-field-names.patch
-orinoco-fix-truncating-commsquality-rid-with-the-latest-symbol-firmware.patch
-orinoco-remove-tracing-code-its-unused.patch
-orinoco-remove-debug-buffer-code-and-userspace-include-support.patch
-orinoco-symbol-card-supported-by-spectrum_cs-is-la4137-not-la4100.patch
-orinoco-optimize-tx-exception-handling-in-orinoco.patch
-orinoco-orinoco_xmit-should-only-return-valid-symbolic-constants.patch
-orinoco-replace-hermes_write_words-with-hermes_write_bytes.patch
-orinoco-dont-use-any-padding-for-tx-frames.patch
-orinoco-refactor-and-clean-up-tx-error-handling.patch
-orinoco-simplify-8023-encapsulation-code.patch
-orinoco-fix-bap0-offset-error-after-several-days-of-operation.patch
-orinoco-delay-fid-allocation-after-firmware-initialization.patch
-orinoco_pci-disable-device-and-free-irq-when-suspending.patch
-orinoco_pci-use-pci_iomap-for-resources.patch
-orinoco-support-pci-suspend-resume-for-nortel-plx-and-tmd-adaptors.patch
-orinoco-reduce-differences-between-pci-drivers-create-orinoco_pcih.patch
-orinoco-further-comment-cleanup-in-the-pci-drivers.patch
-orinoco-bump-version-to-015.patch
-bcm43-wireless-fix-printk-format-warnings.patch
-bcm43-fix-config-menu-alignment.patch
-x86_64-mm-kdump-trigger-points.patch
-x86_64-mm-increase-nodemap.patch
-x86_64-mm-new-syscalls.patch
-x86_64-mm-move-doublefault.patch
-x86_64-mm-alternatives-fix.patch
-arm-add_memory-build-fix.patch
-memory_hotplugh-cleanup.patch
-mm-slobc-for_each_possible_cpu-not-nr_cpus.patch
-oom-kill-mm-locking-fix.patch
-mm-fix-mm_struct-reference-counting-bugs-in-mm-oom_killc.patch
-page_allocc-buddy-handling-cleanup.patch
-hugetlbfs-add-kconfig-help-text.patch
-selinux-fix-mls-compatibility-off-by-one-bug.patch
-asm-i386-atomich-local_irq_save-should-be-used-instead-of-local_irq_disable.patch
-x86-cpuid-and-msr-notifier-callback-section-mismatches.patch
-patch-to-limit-present-cpus-to-fake-cpu-hot-add-testing.patch
-enable-sci_emulate-to-manually-simulate-physical-hotplug-testing.patch
-drivers-acpi-busc-make-struct-acpi_sci_dir-static.patch
-x86_64-use-select-for-gart_iommu-to-enable-agp.patch
-x86_64-sparsemem-does-not-need-node_mem_map.patch
-m32r-fix-pt_regs-for.patch
-m32r-update-include-asm-m32r-semaphoreh.patch
-m32r-mappi3-reboot-support.patch
-m32r-remove-a-warning-of-m32r_sioc.patch
-m32r-update-switch_to-macro-for-tuning.patch
-uml-change-sigjmp_buf-to-jmp_buf.patch
-uml-__user-annotations.patch
-uml-physical-memory-map-file-fixes.patch
-uml-add-missing-__volatile__.patch
-fix-file-lookup-without-ref.patch
-update-obsolete_oss_driver-schedule-and-dependencies.patch
-make-the-oss-sound_via82cxxx-option-available-again.patch
-kconfigdebug-set-debug_mutex-to-off-by-default.patch
-fs-fix-ocfs2-warning-when-debug_fs-is-not-enabled.patch
-voyager-no-need-to-define-bits_per_byte-when-its-already-in-typesh.patch
-apm-fix-armada-laptops-again.patch
-doc-vm-hugetlbpage-update-2.patch
-ipmi-fix-devinit-placement.patch
-config-update-usage-help-info.patch
-fix-potential-null-pointer-deref-in-gen_init_cpio.patch
-open-ipmi-bt-overflow.patch
-parport_pc-fix-section-mismatch-warnings-v2.patch
-pnp-fix-two-messages-in-managerc.patch
-fix-dependencies-of-hugetlb_page_size_64k.patch
-fix-dependencies-of-w1_slave_ds2433_crc.patch
-tpm-spacing-cleanups.patch
-tpm-reorganize-sysfs-files.patch
-tpm-chip-struct-update.patch
-tpm-return-chip-from-tpm_register_hardware.patch
-tpm-command-duration-update.patch
-tpm-new-12-sysfs-files.patch
-tpm-new-12-sysfs-files-fix.patch
-tpm-new-12-sysfs-files-fix-fix.patch
-tpm-tpm-new-12-sysfs-files-fix-fix-fix.patch
-tpm-driver-for-next-generation-tpm-chips.patch
-tpm-driver-for-next-generation-tpm-chips-fix.patch
-tpm-driver-for-next-generation-tpm-chips-fix-fix.patch
-tpm-msecs_to_jiffies-cleanups.patch
-tpm-use-clear_bit.patch
-tpm-use-clear_bit-fix.patch
-tpm-use-clear_bit-fix-fix.patch
-tpm-use-clear_bit-fix-fix-fix.patch
-tpm-use-clear_bit-fix-fix-fix-fix.patch
-tpm-tpm_infineon-updated-to-latest-interface-changes.patch
-tpm-check-mem-start-and-len.patch
-tpm-update-bios-log-code-for-12.patch
-tpm_infineon-section-fixup.patch
-bluetooth-fix-problem-with-sco.patch
-switch-kprobes-inline-functions-to-__kprobes-for-i386.patch
-switch-kprobes-inline-functions-to-__kprobes-for-x86_64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-ppc64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-ia64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-sparc64.patch
-ide-ati-sb600-ide-support.patch
-remove-the-obsolete-idepci_flag_force_pdc.patch
-alim15x3-uli-m-1573-south-bridge-support.patch
-fb-fix-section-mismatch-in-savagefb.patch
-radeonfb-section-mismatches.patch
-savagefb-fix-section-mismatch-warnings.patch
-fbdev-fix-return-error-of-fb_write.patch
-remove-redundant-null-checks-before-free-in-net.patch
Merged
+remove-softlockup-from-invalidate_mapping_pages.patch
+x25-fix-for-spinlock-recurse-and-spinlock-lockup-with.patch
+off-by-1-in-kernel-power-mainc.patch
+request_irq-remove-warnings-from-irq-probing.patch
+input-fix-oops-on-mk712-load.patch
+mv643xx_eth-provide-sysfs-class-device-symlink.patch
+s390-make-qeth-buildable.patch
+tpar-oops-fix.patch
+fix-array-overrun-in-drivers-char-mwave-mwaveddc.patch
+readd-the-oss-sound_cs4232-option.patch
+avoid-printing-pointless-tsc-skew-msgs.patch
+enable-x86_pc-for-hotplug_cpu.patch
+mark-vmsplit-embedded.patch
+kprobe-cleanup-for-vm_mask-judgement.patch
+kprobe-fix-resume-execution-on-i386.patch
2.6.17 queue (mostly)
+acpiphp-use-new-dock-driver-fix.patch
Fix acpiphp-use-new-dock-driver.patch
+fw-memory-leakages-in-driver-acpi-videoc.patch
+acpi-idle-__read_mostly-and-de-init-static-var.patch
+acpi-suppress-power-button-event-on-s3-resume.patch
ACPI udpates
+remove-for_each_cpu.patch
Remove for_each_cpu().
+alsa-pcmcia-sound-devices-shouldnt-depend-on-isa.patch
+alsa-rmmod-oops-fix.patch
ALSA fixes
+iosched-use-hlist-for-request-hashtable.patch
iosched cleanup
+gregkh-driver-frame-buffer-remove-cmap-sysfs-interface.patch
+gregkh-driver-kobject-fix-build-error.patch
+gregkh-driver-fix-ocfs2-warning-when-debug_fs-is-not-enabled.patch
+gregkh-driver-kobject-possible-cleanups.patch
+gregkh-driver-added-uri-of-linux-kernel-development-process.patch
+gregkh-driver-class-device-add-attribute_group-creation.patch
+gregkh-driver-netdev-create-attribute_groups-with-class_device_add.patch
+gregkh-driver-tty-return-class-device-pointer-from-tty_register_device.patch
+gregkh-driver-i4l-gigaset-move-sysfs-entry-to-tty-class-device.patch
Driver tree updates
+gregkh-driver-spi-spi_bitbang-clocking-fixes.patch
SPI fix
+netdev-hotplug-napi-race-cleanup.patch
net cleanup
+dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616.patch
+dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616-tidy.patch
DVB feature
+vivi-build-fix.patch
+git-dvb-Kconfig-fix.patch
+git-dvb-Kconfig-fix-2.patch
git-dvb.patch is a bit sick.
+gregkh-i2c-rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
+gregkh-i2c-i2c-piix4-remove-fix_hstcfg-parameter.patch
+gregkh-i2c-i2c-piix4-fix-typo-in-documentation.patch
+gregkh-i2c-i2c-piix4-improve-ibm-error-message.patch
+gregkh-i2c-i2c-nforce2-add-mcp51-mcp55-support.patch
+gregkh-i2c-hwmon-hdaps-update-id-list.patch
+gregkh-i2c-hwmon-w83791d-new-driver.patch
+gregkh-i2c-hwmon-lm83-documentation-update.patch
+gregkh-i2c-hwmon-improve-Kconfig-help.patch
+gregkh-i2c-hwmon-vid-mask-per-vrm.patch
I2C tree updates.
+gregkh-i2c-w1-possible-cleanups.patch
+gregkh-i2c-w1-fix-dependencies-of-w1_slave_ds2433_crc.patch
i2c cleanup and fix
-i2c-add-support-for-virtual-i2c-adapters-tidy.patch
-i2c-add-support-for-virtual-i2c-adapters-fix.patch
Folded into i2c-add-support-for-virtual-i2c-adapters.patch
+i2c-mpc-fix-up-error-handling.patch
+opencores-i2c-bus-driver.patch
+opencores-i2c-bus-driver-tidy.patch
+opencores-i2c-bus-driver-fix.patch
+i2c-pca954x-fix-initial-access-to-first-mux-switch-port.patch
I2C updates.
+smc911x-Kconfig-fix.patch
+via-rhine-zero-pad-short-packets-on-rhine-i-ethernet-cards.patch
netdev updates
+net-use-hlist_unhashed.patch
+ipv4-inet_init-fs_initcall.patch
net updates
+powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up.patch
+powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up-tidy.patch
powerpc fix
+serial-fix-uart_bug_txen-test.patch
serial fix (needs work)
-improve-pci-config-space-writeback-tidy.patch
Folded into improve-pci-config-space-writeback.patch
+pci-quirk-via-irq-fixup-should-only-run-for-via-southbridges.patch
+reverse-pci-config-space-restore-order.patch
PCI fixes
-revert-pci-pci-cardbus-cards-hidden-needs-pci=assign-busses-to-fix.patch
Dropped
+drivers-scsi-fix-proc_scsi_write-to-return-length-on.patch
+drivers-scsi-sdc-fix-uninitialized-variable-in-handling-medium-errors.patch
+drivers-scsi-aic7xxx-possible-cleanups-2.patch
+scsi-remove-documentation-scsi-cpqfctxt.patch
+enable-advansys-driver.patch
+advansys-warning-workaround.patch
+scsi-clean-up-warnings-in-advansys-driver.patch
+scsi-clean-up-warnings-in-advansys-driver-fix.patch
+mpt-fusion-driver-initialization-failure-fix.patch
SCSI fixes
-areca-raid-linux-scsi-driver-update4.patch
-areca-raid-linux-scsi-driver-update5.patch
Foxled into areca-raid-linux-scsi-driver.patch.
+gregkh-usb-usb-resource-leak-fix-for-whiteheat-driver.patch
+gregkh-usb-usb-add-new-itegno-usb-cdma-1x-card-support-for-pl2303.patch
+gregkh-usb-usb-storage-unusual-devs-update.patch
+gregkh-usb-usb-storage-atmel-unusual-dev-update.patch
+gregkh-usb-usb-net2280-handle-stalls-for-0-length-control-in-requests.patch
+gregkh-usb-usb-net2280-send-0-length-packets-for-ep0.patch
+gregkh-usb-usb-net2280-check-for-shared-irqs.patch
+gregkh-usb-usb-net2280-set-driver-data-before-it-is-used.patch
+gregkh-usb-usb-use-new-pci_class_serial_usb_-defines.patch
+gregkh-usb-usb-ftdi_sio-vendor-code-for-rr-cirkits-locobuffer-usb.patch
+gregkh-usb-usb-ftdi_sio-adds-support-for-iplus-device.patch
+gregkh-usb-usb-ftdi_sio-add-support-for-ask-rdr-400-series-card-reader.patch
+gregkh-usb-usb-sisusbvga-possible-cleanups.patch
+gregkh-usb-usb-allow-multiple-types-of-ehci-controllers-to-be-built-as-modules.patch
+gregkh-usb-usb-console-fix-cr-lf-issues.patch
+gregkh-usb-usb-console-fix-oops.patch
+gregkh-usb-usb-console-prevent-enodev-on-node.patch
+gregkh-usb-usb-macbook-pro-touchpad-support.patch
USB tree updates
+fix-sco-on-some-bluetooth-adapters.patch
+fix-sco-on-some-bluetooth-adapters-tidy.patch
USB fix
+x86_64-mm-acpi-nolapic.patch
+x86_64-mm-ia32-unistd-cleanup.patch
+x86_64-mm-large-bzimage.patch
+x86_64-mm-topology-comment.patch
+x86_64-mm-agp-select.patch
+x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
+x86_64-mm-new-compat-ptrace.patch
x86_64 tree updates
+gregkh-devfs-devfs-die-die-die.patch
+gregkh-devfs-devfs-remove-documentation.patch
+gregkh-devfs-devfs-scrub-partitions.patch
+gregkh-devfs-devfs-scrub-init.patch
+gregkh-devfs-devfs-remove-serial-subsystem.patch
+gregkh-devfs-devfs-remove-ide-subsystem.patch
+gregkh-devfs-devfs-remove-sound-subsystem.patch
+gregkh-devfs-devfs-remove-devfs-tape.patch
+gregkh-devfs-devfs-remove-devfs_mk_dir.patch
+gregkh-devfs-devfs-remove-devfs_mk_symlink.patch
+gregkh-devfs-devfs-remove-devfs_mk_bdev.patch
+gregkh-devfs-devfs-remove-devfs_mk_cdev.patch
+gregkh-devfs-devfs-remove-devfs_remove.patch
+gregkh-devfs-devfs-remove-devfs_fs_kernel.h.patch
+gregkh-devfs-devfs-remove-misc-devfs_name.patch
+gregkh-devfs-devfs-remove-genhd-devfs_name.patch
+gregkh-devfs-devfs-remove-videodev-devfs_name.patch
+gregkh-devfs-devfs-remove-line-devfs_name.patch
+gregkh-devfs-devfs-remove-tty-devfs_name.patch
+gregkh-devfs-devfs-tty_driver_no_devfs.patch
+gregkh-devfs-devfs-minor-cleanups.patch
+gregkh-devfs-devfs-feature-removal.patch
+gregkh-devfs-ndevfs.patch
Remove devfs
+reserve-space-for-swap-label.patch
+read-write-migration-entries-implement-correct-behavior-in-copy_one_pte.patch
+read-write-migration-entries-make-mprotect-convert-write-migration.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix-fix.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix-fix-fix.patch
+swsusp-rework-memory-shrinker-rev-2.patch
Memory management updates
+pgdat-allocation-for-new-node-add-specify-node-id.patch
+pgdat-allocation-for-new-node-add-specify-node-id-powerpc-fix.patch
+pgdat-allocation-for-new-node-add-specify-node-id-tidy.patch
+pgdat-allocation-for-new-node-add-specify-node-id-fix-3.patch
+pgdat-allocation-for-new-node-add-get-node-id-by-acpi.patch
+pgdat-allocation-for-new-node-add-get-node-id-by-acpi-tidy.patch
+pgdat-allocation-for-new-node-add-generic-alloc-node_data.patch
+pgdat-allocation-for-new-node-add-generic-alloc-node_data-tidy.patch
+pgdat-allocation-for-new-node-add-refresh-node_data.patch
+pgdat-allocation-for-new-node-add-refresh-node_data-fix.patch
+pgdat-allocation-for-new-node-add-export-kswapd-start-func.patch
+pgdat-allocation-for-new-node-add-export-kswapd-start-func-tidy.patch
+pgdat-allocation-for-new-node-add-call-pgdat-allocation.patch
Memory hotplug (node add)
+mm-introduce-remap_vmalloc_range.patch
+mm-introduce-remap_vmalloc_range-tidy.patch
+mm-introduce-remap_vmalloc_range-fix.patch
+change-gen_pool-allocator-to-not-touch-managed-memory.patch
+change-gen_pool-allocator-to-not-touch-managed-memory-update.patch
+change-gen_pool-allocator-to-not-touch-managed-memory-update-2.patch
+radix-tree-direct-data.patch
+radix-tree-small.patch
+likely-cleanup-remove-unlikely-in-sys_mprotect.patch
More memory management updates
+x86-x86_64-avoid-irq0-ioapic-pin-collision.patch
+x86-x86_64-avoid-irq0-ioapic-pin-collision-tidy.patch
x86_64 fix
+swsusp-add-architecture-special-saveable-pages-fix.patch
Fix swsusp-add-architecture-special-saveable-pages-support.patch
+swsusp-i386-mark-special-saveable-unsaveable-pages-fix.patch
Fix swsusp-i386-mark-special-saveable-unsaveable-pages.patch
+swsusp-x86_64-mark-special-saveable-unsaveable-pages-fix.patch
Fix swsusp-x86_64-mark-special-saveable-unsaveable-pages.patch
+kernel-power-snapshotc-cleanups.patch
+swsusp-use-less-memory-during-resume.patch
swsusp updates
-uml-prepare-fixing-compilation-output.patch
Dropped.
+s390-fix-i-o-termination-race-in-cio.patch
+s390-enable-interrupts-on-error-path.patch
+s390-bug-in-setup_rt_frame.patch
+s390-alternate-signal-stack-handling-bug.patch
+s390-qdio-memory-allocations.patch
+s390-dasd-ioctl-never-returns.patch
+s390-fix-slab-debugging.patch
+s390-futex-atomic-operations.patch
+s390-futex-atomic-operations-part-2.patch
+s390-tape-3590-changes.patch
+s390-segment-operation-error-codes.patch
+s390-instruction-processing-damage-handling.patch
+s390-add-read_mostly-optimization.patch
+s390-dasd-device-identifiers.patch
+s390-dasd-device-identifiers-fix.patch
+s390-new-system-calls.patch
s390 updates
-fix-cdrom-being-confused-on-using-kdump-tweaks.patch
Folded into fix-cdrom-being-confused-on-using-kdump.patch
+cond-resched-might-sleep-fix.patch
+enhancing-accessibility-of-lxdialog.patch
+the-scheduled-unexport-of-insert_resource.patch
+jbd-fix-bug-in-journal_commit_transaction.patch
+rename-swapper-to-idle.patch
+oss-cs46xx-cleanup-and-tiny-bugfix.patch
+i4l-memory-leak-fix-for-sc_ioctl.patch
+isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub.patch
+invert-irq-migrationc-brach-prediction.patch
+x86-powerpc-make-hardirq_ctx-and-softirq_ctx-__read_mostly.patch
+jbd-avoid-kfree-null.patch
+ext3_clear_inode-avoid-kfree-null.patch
+make-noirqdebug-irqfixup-__read_mostly-add-unlikely.patch
+leds-amstrad-delta-led-support.patch
+leds-amstrad-delta-led-support-tidy.patch
+update-devicestxt.patch
+binfmt_elf-codingstyle-cleanup-and-remove-some-pointless-casts.patch
+binfnt_elf-remove-more-casts.patch
+fix-incorrect-sa_onstack-behaviour-for-64-bit-processes.patch
+percpu-counter-data-type-changes-to-suppport.patch
+percpu-counter-data-type-changes-to-suppport-fix.patch
+remove-unlikely-in-might_sleep_if.patch
+process-events-header-cleanup.patch
+process-events-license-change.patch
+strstrip-api.patch
+ipmi-strstrip-conversion.patch
+rcu-introduce-rcu_needs_cpu-interface.patch
+s390-exploit-rcu_needs_cpu-interface.patch
Misc updates
+time-rename-clocksource-functions.patch
+make-pmtmr_ioport-__read_mostly.patch
Update time management patches in -mm.
+kprobe-boost-2byte-opcodes-on-i386.patch
+kprobemulti-kprobe-posthandler-for-booster.patch
+notify-page-fault-call-chain-for-x86_64.patch
+notify-page-fault-call-chain-for-i386.patch
+notify-page-fault-call-chain-for-ia64.patch
+notify-page-fault-call-chain-for-powerpc.patch
+notify-page-fault-call-chain-for-sparc64.patch
+kprobes-registers-for-notify-page-fault.patch
+notify-page-fault-call-chain.patch
kprobes updates
-dlm-core-locking.patch
-dlm-core-locking-resend-lookups.patch
-dlm-lockspaces-callbacks-directory.patch
-dlm-communication.patch
-dlm-recovery.patch
-dlm-recovery-clear-new_master-flag.patch
-dlm-recovery-remove-true-false-defines.patch
-dlm-configuration.patch
-dlm-device-interface.patch
-dlm-device-interface-fix-device-refcount.patch
-dlm-device-interface-dlm-force-unlock.patch
-dlm-device-interface-missing-variable.patch
-dlm-device-interface-check-allocation.patch
-dlm-device-interface-fix-unlock-race.patch
-dlm-device-interface-use-kzalloc.patch
-dlm-debug-fs.patch
-dlm-build.patch
-dlm-node-weights.patch
-dlm-rsb-flag-ops-with-inlined-functions.patch
-dlm-rework-recovery-control.patch
-dlm-better-handling-of-first-lock.patch
-dlm-no-directory-option.patch
-dlm-release-list-of-root-rsbs.patch
-dlm-return-error-in-status-reply.patch
-configfs-export-config_group_find_obj.patch
-dlm-use-configfs.patch
-dlm-remove-file.patch
-dlm-use-jhash.patch
-dlm-maintainer.patch
-drivers-dlm-fix-up-schedule_timeout-usage.patch
-dlm-cleanup-unused-functions.patch
-dlm-include-own-headers.patch
-dlm-sem2mutex.patch
Dropped.
+smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing.patch
+smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing-fix.patch
+sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks.patch
+sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks-fix-2.patch
CPU scheduler updates
+rtmutex-remove-buggy-bug_on-in-pi-boosting-code.patch
+futex-pi-enforce-waiter-bit-when-owner-died-is-detected.patch
+rtmutex-debug-printk-correct-task-information.patch
+futex-pi-make-use-of-restart_block-when-interrupted.patch
pi-futex updates
+proc-dont-lock-task_structs-indefinitely-task_mmu-small-fixes.patch
Fix proc-dont-lock-task_structs-indefinitely.patch
+ide-pdc202xx_oldc-remove-unneeded-tuneproc-call.patch
+ide-hpt3xxn-clocking-fixes.patch
+ide-io-increase-timeout-value-to-allow-for-slave-wakeup.patch
+ide-actually-honor-drives-minimum-pio-dma-cycle-times.patch
IDE updates
+savagefb-allocate-space-for-current-and-saved-register.patch
+savagefb-add-state-save-and_restore-hooks.patch
+savagefb-add-state-save-and_restore-hooks-tidy.patch
+savagefb-add-state-save-and_restore-hooks-fix.patch
+suspend-documentation-update-for-ibm-thinkpad-x30.patch
+asiliantfb-add-help-text-in-kconfig.patch
+backlight-locomo-backlight-driver-updates.patch
+fbdev-cleanup-the-config_video_select-mess.patch
+fbdev-remove-duplicate-includes.patch
+matroxfb-fix-dvi-setup-to-be-more-compatible.patch
fbdev updates
+drivers-char-ipmi-ipmi_msghandlerc-make-proc_ipmi_root-static.patch
+drivers-message-i2o-iopc-unexport-i2o_msg_nop.patch
Little fixes
All 707 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/patch-list
^ permalink raw reply [flat|nested] 90+ messages in thread
* 2.6.17-rc2-mm1
@ 2006-04-27 8:41 Andrew Morton
0 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-27 8:41 UTC (permalink / raw
To: linux-kernel
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
- It took six hours work to get this release building and linking in just a
basic fashion on eight-odd architectures. It's getting out of control.
The acphphp driver is still broken and v4l and memory hotplug are, I
suspect, only hanging in there by the skin of their teeth.
Could patch submitters _please_ be a lot more careful about getting the
Kconfig correct, testing various Kconfig combinations (yes sometimes
people will want to disable your lovely new feature) and just generally
think about these things a bit harder? It isn't rocket science.
- Added the GFS tree to the -mm lineup as git-gfs2.patch . The DLM patches
were consequently dropped.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
Changes since 2.6.17-rc1-mm3:
origin.patch
git-acpi.patch
git-agpgart.patch
git-alsa.patch
git-arm.patch
git-cfq.patch
git-dvb.patch
git-gfs2.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-intelfb.patch
git-libata-all.patch
git-mmc.patch
git-mtd.patch
git-netdev-all.patch
git-nfs.patch
git-ocfs2.patch
git-powerpc.patch
git-pcmcia.patch
git-scsi-misc.patch
git-scsi-rc-fixes.patch
git-scsi-target.patch
git-watchdog.patch
git-xfs.patch
git-cryptodev.patch
git-viro-bird-m32r.patch
git-viro-bird-m68k.patch
git-viro-bird-frv.patch
git-viro-bird-upf.patch
git-viro-bird-volatile.patch
git trees
-uml-make-64-bit-cow-files-compatible-with-32-bit-ones.patch
-task-make-task-list-manipulations-rcu-safe.patch
-for_each_possible_cpu-x86_64.patch
-uml-madv_remove-fixes.patch
-m41t00-fix-bitmasks-when-writing-to-chip.patch
-swsusp-prevent-possible-image-corruption-on-resume.patch
-msi-k8t-neo2-fir-onboardsound-and-additional-soundcard.patch
-sound-fix-hang-in-mpu401_uartc.patch
-sound-fix-hang-in-mpu401_uartc-tidy.patch
-for_each_possible_cpu-for-arm.patch
-block-i-o-schedulers-document-runtime-selection.patch
-drivers-char-drm-drm_memoryc-possible-cleanups.patch
-drm-fix-further-issues-in-drivers-char-drm-via_irqc.patch
-sbp2-consolidate-workarounds.patch
-sbp2-add-read_capacity-workaround-for-ipod.patch
-sbp2-make-tsb42aa9-workaround-specific-to-momobay-cx-1.patch
-sbp2-add-ability-to-override-hardwired-blacklist.patch
-mtd-improve-parameter-parsing-for-block2mtd.patch
-mtd-improve-parameter-parsing-for-block2mtd-fix.patch
-bcm43xx-sysfs-code-cleanup.patch
-bcm43xx-fix-pctl-slowclock-limit-calculation.patch
-e1000-fix-media_type-phy_type-thinko.patch
-unaligned-access-in-sk_run_filter.patch
-nfs-make-2-functions-static.patch
-remove-needless-check-in-nfs_opendir.patch
-fix-nfs-proc_fs=n-compile-error.patch
-nfssunrpc-fix-compiler-warnings-if-config_proc_fs-config_sysctl-are-unset.patch
-nfs_show_stats-for_each_possible_cpu-not-nr_cpus.patch
-powerpc-pseries-bugfix-balance-calls-to-pci_device_put.patch
-powerpc-pseries-clear-pci-failure-counter-if-no-new-failures.patch
-serial-fix-uart_bug_txen-test.patch
-git-scsi-misc-scsi_kmap_atomic_sg-warning-fix.patch
-megaraid-unused-variable.patch
-scsi-megaraid-megaraid_mmc-fix-a-null-pointer-dereference.patch
-overrun-in-drivers-scsi-sim710c.patch
-aic7xxx-ahc_pci_write_config-fix.patch
-qla2xxx-only-free_irq-after-request_irq-succeeds.patch
-git-splice-fixup.patch
-ftdi_sio-adds-support-for-iplus-device.patch
-ipw2200-config_ipw_qos-to-config_ipw2200_qos.patch
-softmac-uses-wiress-ext.patch
-bcm43xx_phyc-fix-a-memory-leak.patch
-orinoco-remove-useless-cis-validation.patch
-orinoco-remove-pcmcia-audio-support-its-useless-for-wireless-cards.patch
-orinoco-remove-underscores-from-little-endian-field-names.patch
-orinoco-fix-truncating-commsquality-rid-with-the-latest-symbol-firmware.patch
-orinoco-remove-tracing-code-its-unused.patch
-orinoco-remove-debug-buffer-code-and-userspace-include-support.patch
-orinoco-symbol-card-supported-by-spectrum_cs-is-la4137-not-la4100.patch
-orinoco-optimize-tx-exception-handling-in-orinoco.patch
-orinoco-orinoco_xmit-should-only-return-valid-symbolic-constants.patch
-orinoco-replace-hermes_write_words-with-hermes_write_bytes.patch
-orinoco-dont-use-any-padding-for-tx-frames.patch
-orinoco-refactor-and-clean-up-tx-error-handling.patch
-orinoco-simplify-8023-encapsulation-code.patch
-orinoco-fix-bap0-offset-error-after-several-days-of-operation.patch
-orinoco-delay-fid-allocation-after-firmware-initialization.patch
-orinoco_pci-disable-device-and-free-irq-when-suspending.patch
-orinoco_pci-use-pci_iomap-for-resources.patch
-orinoco-support-pci-suspend-resume-for-nortel-plx-and-tmd-adaptors.patch
-orinoco-reduce-differences-between-pci-drivers-create-orinoco_pcih.patch
-orinoco-further-comment-cleanup-in-the-pci-drivers.patch
-orinoco-bump-version-to-015.patch
-bcm43-wireless-fix-printk-format-warnings.patch
-bcm43-fix-config-menu-alignment.patch
-x86_64-mm-kdump-trigger-points.patch
-x86_64-mm-increase-nodemap.patch
-x86_64-mm-new-syscalls.patch
-x86_64-mm-move-doublefault.patch
-x86_64-mm-alternatives-fix.patch
-arm-add_memory-build-fix.patch
-memory_hotplugh-cleanup.patch
-mm-slobc-for_each_possible_cpu-not-nr_cpus.patch
-oom-kill-mm-locking-fix.patch
-mm-fix-mm_struct-reference-counting-bugs-in-mm-oom_killc.patch
-page_allocc-buddy-handling-cleanup.patch
-hugetlbfs-add-kconfig-help-text.patch
-selinux-fix-mls-compatibility-off-by-one-bug.patch
-asm-i386-atomich-local_irq_save-should-be-used-instead-of-local_irq_disable.patch
-x86-cpuid-and-msr-notifier-callback-section-mismatches.patch
-patch-to-limit-present-cpus-to-fake-cpu-hot-add-testing.patch
-enable-sci_emulate-to-manually-simulate-physical-hotplug-testing.patch
-drivers-acpi-busc-make-struct-acpi_sci_dir-static.patch
-x86_64-use-select-for-gart_iommu-to-enable-agp.patch
-x86_64-sparsemem-does-not-need-node_mem_map.patch
-m32r-fix-pt_regs-for.patch
-m32r-update-include-asm-m32r-semaphoreh.patch
-m32r-mappi3-reboot-support.patch
-m32r-remove-a-warning-of-m32r_sioc.patch
-m32r-update-switch_to-macro-for-tuning.patch
-uml-change-sigjmp_buf-to-jmp_buf.patch
-uml-__user-annotations.patch
-uml-physical-memory-map-file-fixes.patch
-uml-add-missing-__volatile__.patch
-fix-file-lookup-without-ref.patch
-update-obsolete_oss_driver-schedule-and-dependencies.patch
-make-the-oss-sound_via82cxxx-option-available-again.patch
-kconfigdebug-set-debug_mutex-to-off-by-default.patch
-fs-fix-ocfs2-warning-when-debug_fs-is-not-enabled.patch
-voyager-no-need-to-define-bits_per_byte-when-its-already-in-typesh.patch
-apm-fix-armada-laptops-again.patch
-doc-vm-hugetlbpage-update-2.patch
-ipmi-fix-devinit-placement.patch
-config-update-usage-help-info.patch
-fix-potential-null-pointer-deref-in-gen_init_cpio.patch
-open-ipmi-bt-overflow.patch
-parport_pc-fix-section-mismatch-warnings-v2.patch
-pnp-fix-two-messages-in-managerc.patch
-fix-dependencies-of-hugetlb_page_size_64k.patch
-fix-dependencies-of-w1_slave_ds2433_crc.patch
-tpm-spacing-cleanups.patch
-tpm-reorganize-sysfs-files.patch
-tpm-chip-struct-update.patch
-tpm-return-chip-from-tpm_register_hardware.patch
-tpm-command-duration-update.patch
-tpm-new-12-sysfs-files.patch
-tpm-new-12-sysfs-files-fix.patch
-tpm-new-12-sysfs-files-fix-fix.patch
-tpm-tpm-new-12-sysfs-files-fix-fix-fix.patch
-tpm-driver-for-next-generation-tpm-chips.patch
-tpm-driver-for-next-generation-tpm-chips-fix.patch
-tpm-driver-for-next-generation-tpm-chips-fix-fix.patch
-tpm-msecs_to_jiffies-cleanups.patch
-tpm-use-clear_bit.patch
-tpm-use-clear_bit-fix.patch
-tpm-use-clear_bit-fix-fix.patch
-tpm-use-clear_bit-fix-fix-fix.patch
-tpm-use-clear_bit-fix-fix-fix-fix.patch
-tpm-tpm_infineon-updated-to-latest-interface-changes.patch
-tpm-check-mem-start-and-len.patch
-tpm-update-bios-log-code-for-12.patch
-tpm_infineon-section-fixup.patch
-bluetooth-fix-problem-with-sco.patch
-switch-kprobes-inline-functions-to-__kprobes-for-i386.patch
-switch-kprobes-inline-functions-to-__kprobes-for-x86_64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-ppc64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-ia64.patch
-switch-kprobes-inline-functions-to-__kprobes-for-sparc64.patch
-ide-ati-sb600-ide-support.patch
-remove-the-obsolete-idepci_flag_force_pdc.patch
-alim15x3-uli-m-1573-south-bridge-support.patch
-fb-fix-section-mismatch-in-savagefb.patch
-radeonfb-section-mismatches.patch
-savagefb-fix-section-mismatch-warnings.patch
-fbdev-fix-return-error-of-fb_write.patch
-remove-redundant-null-checks-before-free-in-net.patch
Merged
+remove-softlockup-from-invalidate_mapping_pages.patch
+x25-fix-for-spinlock-recurse-and-spinlock-lockup-with.patch
+off-by-1-in-kernel-power-mainc.patch
+request_irq-remove-warnings-from-irq-probing.patch
+input-fix-oops-on-mk712-load.patch
+mv643xx_eth-provide-sysfs-class-device-symlink.patch
+s390-make-qeth-buildable.patch
+tpar-oops-fix.patch
+fix-array-overrun-in-drivers-char-mwave-mwaveddc.patch
+readd-the-oss-sound_cs4232-option.patch
+avoid-printing-pointless-tsc-skew-msgs.patch
+enable-x86_pc-for-hotplug_cpu.patch
+mark-vmsplit-embedded.patch
+kprobe-cleanup-for-vm_mask-judgement.patch
+kprobe-fix-resume-execution-on-i386.patch
2.6.17 queue (mostly)
+acpiphp-use-new-dock-driver-fix.patch
Fix acpiphp-use-new-dock-driver.patch
+fw-memory-leakages-in-driver-acpi-videoc.patch
+acpi-idle-__read_mostly-and-de-init-static-var.patch
+acpi-suppress-power-button-event-on-s3-resume.patch
ACPI udpates
+remove-for_each_cpu.patch
Remove for_each_cpu().
+alsa-pcmcia-sound-devices-shouldnt-depend-on-isa.patch
+alsa-rmmod-oops-fix.patch
ALSA fixes
+iosched-use-hlist-for-request-hashtable.patch
iosched cleanup
+gregkh-driver-frame-buffer-remove-cmap-sysfs-interface.patch
+gregkh-driver-kobject-fix-build-error.patch
+gregkh-driver-fix-ocfs2-warning-when-debug_fs-is-not-enabled.patch
+gregkh-driver-kobject-possible-cleanups.patch
+gregkh-driver-added-uri-of-linux-kernel-development-process.patch
+gregkh-driver-class-device-add-attribute_group-creation.patch
+gregkh-driver-netdev-create-attribute_groups-with-class_device_add.patch
+gregkh-driver-tty-return-class-device-pointer-from-tty_register_device.patch
+gregkh-driver-i4l-gigaset-move-sysfs-entry-to-tty-class-device.patch
Driver tree updates
+gregkh-driver-spi-spi_bitbang-clocking-fixes.patch
SPI fix
+netdev-hotplug-napi-race-cleanup.patch
net cleanup
+dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616.patch
+dvb-core-ule-fixes-and-rfc4326-additions-kernel-2616-tidy.patch
DVB feature
+vivi-build-fix.patch
+git-dvb-Kconfig-fix.patch
+git-dvb-Kconfig-fix-2.patch
git-dvb.patch is a bit sick.
+gregkh-i2c-rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
+gregkh-i2c-i2c-piix4-remove-fix_hstcfg-parameter.patch
+gregkh-i2c-i2c-piix4-fix-typo-in-documentation.patch
+gregkh-i2c-i2c-piix4-improve-ibm-error-message.patch
+gregkh-i2c-i2c-nforce2-add-mcp51-mcp55-support.patch
+gregkh-i2c-hwmon-hdaps-update-id-list.patch
+gregkh-i2c-hwmon-w83791d-new-driver.patch
+gregkh-i2c-hwmon-lm83-documentation-update.patch
+gregkh-i2c-hwmon-improve-Kconfig-help.patch
+gregkh-i2c-hwmon-vid-mask-per-vrm.patch
I2C tree updates.
+gregkh-i2c-w1-possible-cleanups.patch
+gregkh-i2c-w1-fix-dependencies-of-w1_slave_ds2433_crc.patch
i2c cleanup and fix
-i2c-add-support-for-virtual-i2c-adapters-tidy.patch
-i2c-add-support-for-virtual-i2c-adapters-fix.patch
Folded into i2c-add-support-for-virtual-i2c-adapters.patch
+i2c-mpc-fix-up-error-handling.patch
+opencores-i2c-bus-driver.patch
+opencores-i2c-bus-driver-tidy.patch
+opencores-i2c-bus-driver-fix.patch
+i2c-pca954x-fix-initial-access-to-first-mux-switch-port.patch
I2C updates.
+smc911x-Kconfig-fix.patch
+via-rhine-zero-pad-short-packets-on-rhine-i-ethernet-cards.patch
netdev updates
+net-use-hlist_unhashed.patch
+ipv4-inet_init-fs_initcall.patch
net updates
+powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up.patch
+powerpc-pseries-avoid-crash-in-pci-code-if-mem-system-not-up-tidy.patch
powerpc fix
+serial-fix-uart_bug_txen-test.patch
serial fix (needs work)
-improve-pci-config-space-writeback-tidy.patch
Folded into improve-pci-config-space-writeback.patch
+pci-quirk-via-irq-fixup-should-only-run-for-via-southbridges.patch
+reverse-pci-config-space-restore-order.patch
PCI fixes
-revert-pci-pci-cardbus-cards-hidden-needs-pci=assign-busses-to-fix.patch
Dropped
+drivers-scsi-fix-proc_scsi_write-to-return-length-on.patch
+drivers-scsi-sdc-fix-uninitialized-variable-in-handling-medium-errors.patch
+drivers-scsi-aic7xxx-possible-cleanups-2.patch
+scsi-remove-documentation-scsi-cpqfctxt.patch
+enable-advansys-driver.patch
+advansys-warning-workaround.patch
+scsi-clean-up-warnings-in-advansys-driver.patch
+scsi-clean-up-warnings-in-advansys-driver-fix.patch
+mpt-fusion-driver-initialization-failure-fix.patch
SCSI fixes
-areca-raid-linux-scsi-driver-update4.patch
-areca-raid-linux-scsi-driver-update5.patch
Foxled into areca-raid-linux-scsi-driver.patch.
+gregkh-usb-usb-resource-leak-fix-for-whiteheat-driver.patch
+gregkh-usb-usb-add-new-itegno-usb-cdma-1x-card-support-for-pl2303.patch
+gregkh-usb-usb-storage-unusual-devs-update.patch
+gregkh-usb-usb-storage-atmel-unusual-dev-update.patch
+gregkh-usb-usb-net2280-handle-stalls-for-0-length-control-in-requests.patch
+gregkh-usb-usb-net2280-send-0-length-packets-for-ep0.patch
+gregkh-usb-usb-net2280-check-for-shared-irqs.patch
+gregkh-usb-usb-net2280-set-driver-data-before-it-is-used.patch
+gregkh-usb-usb-use-new-pci_class_serial_usb_-defines.patch
+gregkh-usb-usb-ftdi_sio-vendor-code-for-rr-cirkits-locobuffer-usb.patch
+gregkh-usb-usb-ftdi_sio-adds-support-for-iplus-device.patch
+gregkh-usb-usb-ftdi_sio-add-support-for-ask-rdr-400-series-card-reader.patch
+gregkh-usb-usb-sisusbvga-possible-cleanups.patch
+gregkh-usb-usb-allow-multiple-types-of-ehci-controllers-to-be-built-as-modules.patch
+gregkh-usb-usb-console-fix-cr-lf-issues.patch
+gregkh-usb-usb-console-fix-oops.patch
+gregkh-usb-usb-console-prevent-enodev-on-node.patch
+gregkh-usb-usb-macbook-pro-touchpad-support.patch
USB tree updates
+fix-sco-on-some-bluetooth-adapters.patch
+fix-sco-on-some-bluetooth-adapters-tidy.patch
USB fix
+x86_64-mm-acpi-nolapic.patch
+x86_64-mm-ia32-unistd-cleanup.patch
+x86_64-mm-large-bzimage.patch
+x86_64-mm-topology-comment.patch
+x86_64-mm-agp-select.patch
+x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
+x86_64-mm-new-compat-ptrace.patch
x86_64 tree updates
+gregkh-devfs-devfs-die-die-die.patch
+gregkh-devfs-devfs-remove-documentation.patch
+gregkh-devfs-devfs-scrub-partitions.patch
+gregkh-devfs-devfs-scrub-init.patch
+gregkh-devfs-devfs-remove-serial-subsystem.patch
+gregkh-devfs-devfs-remove-ide-subsystem.patch
+gregkh-devfs-devfs-remove-sound-subsystem.patch
+gregkh-devfs-devfs-remove-devfs-tape.patch
+gregkh-devfs-devfs-remove-devfs_mk_dir.patch
+gregkh-devfs-devfs-remove-devfs_mk_symlink.patch
+gregkh-devfs-devfs-remove-devfs_mk_bdev.patch
+gregkh-devfs-devfs-remove-devfs_mk_cdev.patch
+gregkh-devfs-devfs-remove-devfs_remove.patch
+gregkh-devfs-devfs-remove-devfs_fs_kernel.h.patch
+gregkh-devfs-devfs-remove-misc-devfs_name.patch
+gregkh-devfs-devfs-remove-genhd-devfs_name.patch
+gregkh-devfs-devfs-remove-videodev-devfs_name.patch
+gregkh-devfs-devfs-remove-line-devfs_name.patch
+gregkh-devfs-devfs-remove-tty-devfs_name.patch
+gregkh-devfs-devfs-tty_driver_no_devfs.patch
+gregkh-devfs-devfs-minor-cleanups.patch
+gregkh-devfs-devfs-feature-removal.patch
+gregkh-devfs-ndevfs.patch
Remove devfs
+reserve-space-for-swap-label.patch
+read-write-migration-entries-implement-correct-behavior-in-copy_one_pte.patch
+read-write-migration-entries-make-mprotect-convert-write-migration.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix-fix.patch
+read-write-migration-entries-make-mprotect-convert-write-migration-fix-fix-fix.patch
+swsusp-rework-memory-shrinker-rev-2.patch
Memory management updates
+pgdat-allocation-for-new-node-add-specify-node-id.patch
+pgdat-allocation-for-new-node-add-specify-node-id-powerpc-fix.patch
+pgdat-allocation-for-new-node-add-specify-node-id-tidy.patch
+pgdat-allocation-for-new-node-add-specify-node-id-fix-3.patch
+pgdat-allocation-for-new-node-add-get-node-id-by-acpi.patch
+pgdat-allocation-for-new-node-add-get-node-id-by-acpi-tidy.patch
+pgdat-allocation-for-new-node-add-generic-alloc-node_data.patch
+pgdat-allocation-for-new-node-add-generic-alloc-node_data-tidy.patch
+pgdat-allocation-for-new-node-add-refresh-node_data.patch
+pgdat-allocation-for-new-node-add-refresh-node_data-fix.patch
+pgdat-allocation-for-new-node-add-export-kswapd-start-func.patch
+pgdat-allocation-for-new-node-add-export-kswapd-start-func-tidy.patch
+pgdat-allocation-for-new-node-add-call-pgdat-allocation.patch
Memory hotplug (node add)
+mm-introduce-remap_vmalloc_range.patch
+mm-introduce-remap_vmalloc_range-tidy.patch
+mm-introduce-remap_vmalloc_range-fix.patch
+change-gen_pool-allocator-to-not-touch-managed-memory.patch
+change-gen_pool-allocator-to-not-touch-managed-memory-update.patch
+change-gen_pool-allocator-to-not-touch-managed-memory-update-2.patch
+radix-tree-direct-data.patch
+radix-tree-small.patch
+likely-cleanup-remove-unlikely-in-sys_mprotect.patch
More memory management updates
+x86-x86_64-avoid-irq0-ioapic-pin-collision.patch
+x86-x86_64-avoid-irq0-ioapic-pin-collision-tidy.patch
x86_64 fix
+swsusp-add-architecture-special-saveable-pages-fix.patch
Fix swsusp-add-architecture-special-saveable-pages-support.patch
+swsusp-i386-mark-special-saveable-unsaveable-pages-fix.patch
Fix swsusp-i386-mark-special-saveable-unsaveable-pages.patch
+swsusp-x86_64-mark-special-saveable-unsaveable-pages-fix.patch
Fix swsusp-x86_64-mark-special-saveable-unsaveable-pages.patch
+kernel-power-snapshotc-cleanups.patch
+swsusp-use-less-memory-during-resume.patch
swsusp updates
-uml-prepare-fixing-compilation-output.patch
Dropped.
+s390-fix-i-o-termination-race-in-cio.patch
+s390-enable-interrupts-on-error-path.patch
+s390-bug-in-setup_rt_frame.patch
+s390-alternate-signal-stack-handling-bug.patch
+s390-qdio-memory-allocations.patch
+s390-dasd-ioctl-never-returns.patch
+s390-fix-slab-debugging.patch
+s390-futex-atomic-operations.patch
+s390-futex-atomic-operations-part-2.patch
+s390-tape-3590-changes.patch
+s390-segment-operation-error-codes.patch
+s390-instruction-processing-damage-handling.patch
+s390-add-read_mostly-optimization.patch
+s390-dasd-device-identifiers.patch
+s390-dasd-device-identifiers-fix.patch
+s390-new-system-calls.patch
s390 updates
-fix-cdrom-being-confused-on-using-kdump-tweaks.patch
Folded into fix-cdrom-being-confused-on-using-kdump.patch
+cond-resched-might-sleep-fix.patch
+enhancing-accessibility-of-lxdialog.patch
+the-scheduled-unexport-of-insert_resource.patch
+jbd-fix-bug-in-journal_commit_transaction.patch
+rename-swapper-to-idle.patch
+oss-cs46xx-cleanup-and-tiny-bugfix.patch
+i4l-memory-leak-fix-for-sc_ioctl.patch
+isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub.patch
+invert-irq-migrationc-brach-prediction.patch
+x86-powerpc-make-hardirq_ctx-and-softirq_ctx-__read_mostly.patch
+jbd-avoid-kfree-null.patch
+ext3_clear_inode-avoid-kfree-null.patch
+make-noirqdebug-irqfixup-__read_mostly-add-unlikely.patch
+leds-amstrad-delta-led-support.patch
+leds-amstrad-delta-led-support-tidy.patch
+update-devicestxt.patch
+binfmt_elf-codingstyle-cleanup-and-remove-some-pointless-casts.patch
+binfnt_elf-remove-more-casts.patch
+fix-incorrect-sa_onstack-behaviour-for-64-bit-processes.patch
+percpu-counter-data-type-changes-to-suppport.patch
+percpu-counter-data-type-changes-to-suppport-fix.patch
+remove-unlikely-in-might_sleep_if.patch
+process-events-header-cleanup.patch
+process-events-license-change.patch
+strstrip-api.patch
+ipmi-strstrip-conversion.patch
+rcu-introduce-rcu_needs_cpu-interface.patch
+s390-exploit-rcu_needs_cpu-interface.patch
Misc updates
+time-rename-clocksource-functions.patch
+make-pmtmr_ioport-__read_mostly.patch
Update time management patches in -mm.
+kprobe-boost-2byte-opcodes-on-i386.patch
+kprobemulti-kprobe-posthandler-for-booster.patch
+notify-page-fault-call-chain-for-x86_64.patch
+notify-page-fault-call-chain-for-i386.patch
+notify-page-fault-call-chain-for-ia64.patch
+notify-page-fault-call-chain-for-powerpc.patch
+notify-page-fault-call-chain-for-sparc64.patch
+kprobes-registers-for-notify-page-fault.patch
+notify-page-fault-call-chain.patch
kprobes updates
-dlm-core-locking.patch
-dlm-core-locking-resend-lookups.patch
-dlm-lockspaces-callbacks-directory.patch
-dlm-communication.patch
-dlm-recovery.patch
-dlm-recovery-clear-new_master-flag.patch
-dlm-recovery-remove-true-false-defines.patch
-dlm-configuration.patch
-dlm-device-interface.patch
-dlm-device-interface-fix-device-refcount.patch
-dlm-device-interface-dlm-force-unlock.patch
-dlm-device-interface-missing-variable.patch
-dlm-device-interface-check-allocation.patch
-dlm-device-interface-fix-unlock-race.patch
-dlm-device-interface-use-kzalloc.patch
-dlm-debug-fs.patch
-dlm-build.patch
-dlm-node-weights.patch
-dlm-rsb-flag-ops-with-inlined-functions.patch
-dlm-rework-recovery-control.patch
-dlm-better-handling-of-first-lock.patch
-dlm-no-directory-option.patch
-dlm-release-list-of-root-rsbs.patch
-dlm-return-error-in-status-reply.patch
-configfs-export-config_group_find_obj.patch
-dlm-use-configfs.patch
-dlm-remove-file.patch
-dlm-use-jhash.patch
-dlm-maintainer.patch
-drivers-dlm-fix-up-schedule_timeout-usage.patch
-dlm-cleanup-unused-functions.patch
-dlm-include-own-headers.patch
-dlm-sem2mutex.patch
Dropped.
+smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing.patch
+smpnice-dont-consider-sched-groups-which-are-lightly-loaded-for-balancing-fix.patch
+sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks.patch
+sched-avoid-unnecessarily-moving-highest-priority-task-move_tasks-fix-2.patch
CPU scheduler updates
+rtmutex-remove-buggy-bug_on-in-pi-boosting-code.patch
+futex-pi-enforce-waiter-bit-when-owner-died-is-detected.patch
+rtmutex-debug-printk-correct-task-information.patch
+futex-pi-make-use-of-restart_block-when-interrupted.patch
pi-futex updates
+proc-dont-lock-task_structs-indefinitely-task_mmu-small-fixes.patch
Fix proc-dont-lock-task_structs-indefinitely.patch
+ide-pdc202xx_oldc-remove-unneeded-tuneproc-call.patch
+ide-hpt3xxn-clocking-fixes.patch
+ide-io-increase-timeout-value-to-allow-for-slave-wakeup.patch
+ide-actually-honor-drives-minimum-pio-dma-cycle-times.patch
IDE updates
+savagefb-allocate-space-for-current-and-saved-register.patch
+savagefb-add-state-save-and_restore-hooks.patch
+savagefb-add-state-save-and_restore-hooks-tidy.patch
+savagefb-add-state-save-and_restore-hooks-fix.patch
+suspend-documentation-update-for-ibm-thinkpad-x30.patch
+asiliantfb-add-help-text-in-kconfig.patch
+backlight-locomo-backlight-driver-updates.patch
+fbdev-cleanup-the-config_video_select-mess.patch
+fbdev-remove-duplicate-includes.patch
+matroxfb-fix-dvi-setup-to-be-more-compatible.patch
fbdev updates
+drivers-char-ipmi-ipmi_msghandlerc-make-proc_ipmi_root-static.patch
+drivers-message-i2o-iopc-unexport-i2o_msg_nop.patch
Little fixes
All 707 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/patch-list
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
@ 2006-04-27 10:16 ` Andi Kleen
2006-04-27 19:19 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:27 ` 2.6.17-rc2-mm1 Michal Piotrowski
` (6 subsequent siblings)
7 siblings, 1 reply; 90+ messages in thread
From: Andi Kleen @ 2006-04-27 10:16 UTC (permalink / raw
To: Andrew Morton; +Cc: linux-kernel
Andrew Morton <akpm@osdl.org> writes:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
>
>
> - It took six hours work to get this release building and linking in just a
> basic fashion on eight-odd architectures. It's getting out of control.
We all appreciate your hard work.
> The acphphp driver is still broken and v4l and memory hotplug are, I
> suspect, only hanging in there by the skin of their teeth.
>
> Could patch submitters _please_ be a lot more careful about getting the
> Kconfig correct, testing various Kconfig combinations (yes sometimes
> people will want to disable your lovely new feature) and just generally
> think about these things a bit harder? It isn't rocket science.
Is this something that could be automated with some machine power?
e.g. every time a patch is added a small cluster could build the patches
with some configurations on various architectures and if it doesn't build
autoflame the patch submitter.
We use this in SUSE for the SUSE kernels and it works quite well.
Maybe someone could contribute the build power needed for that. I suppose
it could be done by just a few scripts listening to mm-commits?
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:16 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-04-27 10:27 ` Michal Piotrowski
2006-04-27 13:07 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:26 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 15:01 ` 2.6.17-rc2-mm1: ACPI_DOCK=n, HOTPLUG_PCI_ACPI=y compile error Adrian Bunk
` (5 subsequent siblings)
7 siblings, 2 replies; 90+ messages in thread
From: Michal Piotrowski @ 2006-04-27 10:27 UTC (permalink / raw
To: Andrew Morton; +Cc: linux-kernel, gregkh
Hi Andrew,
On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
>
[snip]
> +gregkh-devfs-ndevfs.patch
"You don't really want to run this. But if you did, here's a simple hack
showing how easy it is to do it.
Note, this patch will NOT be merged into mainline, so don't get your
panties into a bind..."
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
Please drop this patch.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 10:27 ` 2.6.17-rc2-mm1 Michal Piotrowski
@ 2006-04-27 13:07 ` Michal Piotrowski
2006-04-27 15:28 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 15:26 ` 2.6.17-rc2-mm1 Greg KH
1 sibling, 1 reply; 90+ messages in thread
From: Michal Piotrowski @ 2006-04-27 13:07 UTC (permalink / raw
To: Andrew Morton; +Cc: linux-kernel, gregkh
On 27/04/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Hi Andrew,
>
> On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> >
> [snip]
> > +gregkh-devfs-ndevfs.patch
>
> "You don't really want to run this. But if you did, here's a simple hack
> showing how easy it is to do it.
>
> Note, this patch will NOT be merged into mainline, so don't get your
> panties into a bind..."
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
>
> Please drop this patch.
Here is oops:
http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/oops1.jpg
Here is config:
http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 90+ messages in thread
* 2.6.17-rc2-mm1: ACPI_DOCK=n, HOTPLUG_PCI_ACPI=y compile error
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:16 ` 2.6.17-rc2-mm1 Andi Kleen
2006-04-27 10:27 ` 2.6.17-rc2-mm1 Michal Piotrowski
@ 2006-04-27 15:01 ` Adrian Bunk
2006-04-27 15:47 ` 2.6.17-rc2-mm1 Matthieu CASTET
` (4 subsequent siblings)
7 siblings, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2006-04-27 15:01 UTC (permalink / raw
To: Andrew Morton, Kristen Accardi
Cc: linux-kernel, gregkh, len.brown, linux-acpi
Although not mentioned in the changelog, acpi-dock-driver.patch was
updated in 2.6.17-rc2-mm1.
The changes cause the following compile error with CONFIG_ACPI_DOCK=n,
CONFIG_HOTPLUG_PCI_ACPI=y:
<-- snip -->
...
LD .tmp_vmlinux1
drivers/built-in.o: In function
`is_pci_dock_device':acpiphp_glue.c:(.text+0x1a08a): undefined reference to `is_dock_device'
drivers/built-in.o: In function `cleanup_bridge':
acpiphp_glue.c:(.text+0x1a127): undefined reference to `is_dock_device'
:acpiphp_glue.c:(.text+0x1a133): undefined reference to `unregister_hotplug_dock_device'
:acpiphp_glue.c:(.text+0x1a13b): undefined reference to `unregister_dock_notifier'
drivers/built-in.o: In function `register_slot':
acpiphp_glue.c:(.text+0x1b545): undefined reference to `is_dock_device'
:acpiphp_glue.c:(.text+0x1b742): undefined reference to `is_dock_device'
:acpiphp_glue.c:(.text+0x1b759): undefined reference to `register_hotplug_dock_device'
:acpiphp_glue.c:(.text+0x1b786): undefined reference to `register_dock_notifier'
make: *** [.tmp_vmlinux1] Error 1
<-- snip -->
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 10:27 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 13:07 ` 2.6.17-rc2-mm1 Michal Piotrowski
@ 2006-04-27 15:26 ` Greg KH
2006-04-27 15:43 ` 2.6.17-rc2-mm1 Michal Piotrowski
1 sibling, 1 reply; 90+ messages in thread
From: Greg KH @ 2006-04-27 15:26 UTC (permalink / raw
To: Michal Piotrowski; +Cc: Andrew Morton, linux-kernel
On Thu, Apr 27, 2006 at 12:27:53PM +0200, Michal Piotrowski wrote:
> Hi Andrew,
>
> On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> >
> [snip]
> > +gregkh-devfs-ndevfs.patch
>
> "You don't really want to run this. But if you did, here's a simple hack
> showing how easy it is to do it.
>
> Note, this patch will NOT be merged into mainline, so don't get your
> panties into a bind..."
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
>
> Please drop this patch.
Why drop it? Is it causing you any problems?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 13:07 ` 2.6.17-rc2-mm1 Michal Piotrowski
@ 2006-04-27 15:28 ` Greg KH
2006-04-27 15:32 ` 2.6.17-rc2-mm1 Michal Piotrowski
0 siblings, 1 reply; 90+ messages in thread
From: Greg KH @ 2006-04-27 15:28 UTC (permalink / raw
To: Michal Piotrowski; +Cc: Andrew Morton, linux-kernel
On Thu, Apr 27, 2006 at 03:07:54PM +0200, Michal Piotrowski wrote:
> On 27/04/06, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Hi Andrew,
> >
> > On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > >
> > [snip]
> > > +gregkh-devfs-ndevfs.patch
> >
> > "You don't really want to run this. But if you did, here's a simple hack
> > showing how easy it is to do it.
> >
> > Note, this patch will NOT be merged into mainline, so don't get your
> > panties into a bind..."
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
> >
> > Please drop this patch.
>
> Here is oops:
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/oops1.jpg
Ah, I guess it is causing you problems :)
> Here is config:
> http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config
If you set CONFIG_NDEV_FS=n does the oops go away?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 15:28 ` 2.6.17-rc2-mm1 Greg KH
@ 2006-04-27 15:32 ` Michal Piotrowski
2006-04-27 20:53 ` 2.6.17-rc2-mm1 Greg KH
0 siblings, 1 reply; 90+ messages in thread
From: Michal Piotrowski @ 2006-04-27 15:32 UTC (permalink / raw
To: Greg KH; +Cc: Andrew Morton, linux-kernel
Hi Greg,
On 27/04/06, Greg KH <gregkh@suse.de> wrote:
[snip]
>
> Ah, I guess it is causing you problems :)
>
> > Here is config:
> > http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config
>
> If you set CONFIG_NDEV_FS=n does the oops go away?
Yes.
>
> thanks,
>
> greg k-h
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 15:26 ` 2.6.17-rc2-mm1 Greg KH
@ 2006-04-27 15:43 ` Michal Piotrowski
0 siblings, 0 replies; 90+ messages in thread
From: Michal Piotrowski @ 2006-04-27 15:43 UTC (permalink / raw
To: Greg KH; +Cc: Andrew Morton, linux-kernel
On 27/04/06, Greg KH <gregkh@suse.de> wrote:
> On Thu, Apr 27, 2006 at 12:27:53PM +0200, Michal Piotrowski wrote:
> > Hi Andrew,
> >
> > On 27/04/06, Andrew Morton <akpm@osdl.org> wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > >
> > [snip]
> > > +gregkh-devfs-ndevfs.patch
> >
> > "You don't really want to run this. But if you did, here's a simple hack
> > showing how easy it is to do it.
> >
> > Note, this patch will NOT be merged into mainline, so don't get your
> > panties into a bind..."
> > http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-05-devfs/ndevfs.patch
> >
> > Please drop this patch.
>
> Why drop it?
As long as it doesn't go to mainline we shouldn't care about it in -mm.
>
> thanks,
>
> greg k-h
>
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
` (2 preceding siblings ...)
2006-04-27 15:01 ` 2.6.17-rc2-mm1: ACPI_DOCK=n, HOTPLUG_PCI_ACPI=y compile error Adrian Bunk
@ 2006-04-27 15:47 ` Matthieu CASTET
2006-04-27 18:02 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-27 17:57 ` [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y Adrian Bunk
` (3 subsequent siblings)
7 siblings, 1 reply; 90+ messages in thread
From: Matthieu CASTET @ 2006-04-27 15:47 UTC (permalink / raw
To: linux-kernel
Hi Andrew,
Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
>
64 bit resources core changes in ioport.h break pnp sysfs interface.
A patch like this is needed.
Matthieu
Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
--- 1/drivers/pnp/interface.c 2006-01-03 04:21:10.000000000 +0100
+++ 2/drivers/pnp/interface.c 2006-04-14 22:54:45.000000000 +0200
@@ -264,7 +264,7 @@
if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
pnp_printf(buffer," disabled\n");
else
- pnp_printf(buffer," 0x%lx-0x%lx\n",
+ pnp_printf(buffer," 0x%llx-0x%llx\n",
pnp_port_start(dev, i),
pnp_port_end(dev, i));
}
@@ -275,7 +275,7 @@
if (pnp_mem_flags(dev, i) & IORESOURCE_DISABLED)
pnp_printf(buffer," disabled\n");
else
- pnp_printf(buffer," 0x%lx-0x%lx\n",
+ pnp_printf(buffer," 0x%llx-0x%llx\n",
pnp_mem_start(dev, i),
pnp_mem_end(dev, i));
}
@@ -286,7 +286,7 @@
if (pnp_irq_flags(dev, i) & IORESOURCE_DISABLED)
pnp_printf(buffer," disabled\n");
else
- pnp_printf(buffer," %ld\n",
+ pnp_printf(buffer," %lld\n",
pnp_irq(dev, i));
}
}
@@ -296,7 +296,7 @@
if (pnp_dma_flags(dev, i) & IORESOURCE_DISABLED)
pnp_printf(buffer," disabled\n");
else
- pnp_printf(buffer," %ld\n",
+ pnp_printf(buffer," %lld\n",
pnp_dma(dev, i));
}
}
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-04-27 16:47 Martin Bligh
2006-04-28 8:20 ` 2.6.17-rc2-mm1 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 16:47 UTC (permalink / raw
To: Andrew Morton; +Cc: linuxppc64-dev, linux-kernel
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-04-27 16:50 Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 16:50 UTC (permalink / raw
To: Andrew Morton; +Cc: linuxppc64-dev, LKML
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-04-27 16:54 ` Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 16:54 UTC (permalink / raw
To: Andrew Morton; +Cc: LKML, Andy Whitcroft, linuxppc64-dev
OK, one more time, cause I'm an idiot, and can't type.
--------------------------------
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-04-27 16:54 ` Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 16:54 UTC (permalink / raw
To: Andrew Morton; +Cc: linuxppc64-dev, LKML
OK, one more time, cause I'm an idiot, and can't type.
--------------------------------
Still crashes in LTP on x86_64:
(introduced in previous release)
http://test.kernel.org/abat/29674/debug/console.log
Different panic on 2-way ppp64 blade, again during LTP.
http://test.kernel.org/abat/29675/debug/console.log
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=128 NUMA
Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
DAR: C00001800056B0B0, DSISR: 0000000040010000
TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
Call Trace:
[C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
[C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
[C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
[C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
[C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
[C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
[C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
Instruction dump:
3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
-- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
^ permalink raw reply [flat|nested] 90+ messages in thread
* [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
` (3 preceding siblings ...)
2006-04-27 15:47 ` 2.6.17-rc2-mm1 Matthieu CASTET
@ 2006-04-27 17:57 ` Adrian Bunk
2006-04-27 18:17 ` Andrew Morton
2006-04-27 18:00 ` [-mm patch] fs/nfs/inode.c: make nfs_follow_referral() Adrian Bunk
` (2 subsequent siblings)
7 siblings, 1 reply; 90+ messages in thread
From: Adrian Bunk @ 2006-04-27 17:57 UTC (permalink / raw
To: Andrew Morton, mchehab; +Cc: linux-kernel, v4l-dvb-maintainer
On Thu, Apr 27, 2006 at 01:41:41AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc1-mm3:
>...
> +git-dvb-Kconfig-fix.patch
> +git-dvb-Kconfig-fix-2.patch
>
> git-dvb.patch is a bit sick.
>...
These patches are completely sick.
Not every compatibility issue is about 32<->64 Bit...
Below is the patch I sent you after I discovered the bug
in 2.6.17-rc1-mm3. Is there any reason why you didn't merge my patch?
cu
Adrian
<-- snip -->
If CONFIG_VIDEO_DEV=m and CONFIG_VIDEO_V4L1_COMPAT=y, v4l1-compat should
be built as a module (currently, it isn't built at all leading to
problems with modules using it).
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 18 Apr 2006
--- linux-2.6.17-rc1-mm3-full/drivers/media/video/Makefile.old 2006-04-18 16:52:10.000000000 +0200
+++ linux-2.6.17-rc1-mm3-full/drivers/media/video/Makefile 2006-04-18 16:57:06.000000000 +0200
@@ -11,7 +11,10 @@
msp3400-objs := msp3400-driver.o msp3400-kthreads.o
obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-common.o compat_ioctl32.o
-obj-$(CONFIG_VIDEO_V4L1_COMPAT) += v4l1-compat.o
+
+ifeq ($(CONFIG_VIDEO_V4L1_COMPAT),y)
+ obj-$(CONFIG_VIDEO_DEV) += v4l1-compat.o
+endif
obj-$(CONFIG_VIDEO_BT848) += bt8xx/
obj-$(CONFIG_VIDEO_BT848) += tvaudio.o tda7432.o tda9875.o ir-kbd-i2c.o
^ permalink raw reply [flat|nested] 90+ messages in thread
* [-mm patch] fs/nfs/inode.c: make nfs_follow_referral()
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
` (4 preceding siblings ...)
2006-04-27 17:57 ` [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y Adrian Bunk
@ 2006-04-27 18:00 ` Adrian Bunk
2006-04-27 18:03 ` [-mm patch] mm/vmscan.c: make shrink_all_zones() static Adrian Bunk
2006-04-27 20:33 ` [-mm patch] fs/gfs2/: possible cleanups Adrian Bunk
7 siblings, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2006-04-27 18:00 UTC (permalink / raw
To: Andrew Morton, Manoj Naik, Trond Myklebust; +Cc: linux-kernel
On Thu, Apr 27, 2006 at 01:41:41AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc1-mm3:
>...
> git-nfs.patch
>...
> git trees
>...
This patch makes the needlessly global nfs_follow_referral() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc2-mm1-full/fs/nfs/inode.c.old 2006-04-27 19:45:08.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/nfs/inode.c 2006-04-27 19:45:26.000000000 +0200
@@ -2677,8 +2677,9 @@
* @addr - host addr of new server
*
*/
-struct vfsmount *nfs_follow_referral(const struct vfsmount *mnt_parent,
- const struct dentry *dentry, struct nfs4_fs_locations *locations)
+static struct vfsmount *nfs_follow_referral(const struct vfsmount *mnt_parent,
+ const struct dentry *dentry,
+ struct nfs4_fs_locations *locations)
{
struct vfsmount *mnt = ERR_PTR(-ENOENT);
struct nfs_clone_mount mountdata = {
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 15:47 ` 2.6.17-rc2-mm1 Matthieu CASTET
@ 2006-04-27 18:02 ` Vivek Goyal
2006-04-27 23:24 ` 2.6.17-rc2-mm1 Greg KH
2006-04-28 16:07 ` 2.6.17-rc2-mm1 matthieu castet
0 siblings, 2 replies; 90+ messages in thread
From: Vivek Goyal @ 2006-04-27 18:02 UTC (permalink / raw
To: Matthieu CASTET; +Cc: linux-kernel
On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> Hi Andrew,
>
> Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a écrit :
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> >
>
> 64 bit resources core changes in ioport.h break pnp sysfs interface.
>
> A patch like this is needed.
>
> Matthieu
>
> Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
>
> --- 1/drivers/pnp/interface.c 2006-01-03 04:21:10.000000000 +0100
> +++ 2/drivers/pnp/interface.c 2006-04-14 22:54:45.000000000 +0200
> @@ -264,7 +264,7 @@
> if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
> pnp_printf(buffer," disabled\n");
> else
> - pnp_printf(buffer," 0x%lx-0x%lx\n",
> + pnp_printf(buffer," 0x%llx-0x%llx\n",
> pnp_port_start(dev, i),
> pnp_port_end(dev, i));
I think it would break on ppc64 as u64 is unsigned long. It should be
explicitly typecasted to unsigned long long. Same is true for all the
instances.
(unsigned long long) pnp_port_start(dev, i)
-vivek
> }
> @@ -275,7 +275,7 @@
> if (pnp_mem_flags(dev, i) & IORESOURCE_DISABLED)
> pnp_printf(buffer," disabled\n");
> else
> - pnp_printf(buffer," 0x%lx-0x%lx\n",
> + pnp_printf(buffer," 0x%llx-0x%llx\n",
> pnp_mem_start(dev, i),
> pnp_mem_end(dev, i));
> }
> @@ -286,7 +286,7 @@
> if (pnp_irq_flags(dev, i) & IORESOURCE_DISABLED)
> pnp_printf(buffer," disabled\n");
> else
> - pnp_printf(buffer," %ld\n",
> + pnp_printf(buffer," %lld\n",
> pnp_irq(dev, i));
> }
> }
> @@ -296,7 +296,7 @@
> if (pnp_dma_flags(dev, i) & IORESOURCE_DISABLED)
> pnp_printf(buffer," disabled\n");
> else
> - pnp_printf(buffer," %ld\n",
> + pnp_printf(buffer," %lld\n",
> pnp_dma(dev, i));
> }
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* [-mm patch] mm/vmscan.c: make shrink_all_zones() static
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
` (5 preceding siblings ...)
2006-04-27 18:00 ` [-mm patch] fs/nfs/inode.c: make nfs_follow_referral() Adrian Bunk
@ 2006-04-27 18:03 ` Adrian Bunk
2006-04-27 18:52 ` Rafael J. Wysocki
2006-04-27 20:33 ` [-mm patch] fs/gfs2/: possible cleanups Adrian Bunk
7 siblings, 1 reply; 90+ messages in thread
From: Adrian Bunk @ 2006-04-27 18:03 UTC (permalink / raw
To: Andrew Morton, Rafael J. Wysocki, Con Kolivas; +Cc: linux-kernel
On Thu, Apr 27, 2006 at 01:41:41AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc1-mm3:
>...
> +swsusp-rework-memory-shrinker-rev-2.patch
>
> Memory management updates
>...
This patch makes the needlessly global shrink_all_zones() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc2-mm1-full/mm/vmscan.c.old 2006-04-27 18:09:55.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/mm/vmscan.c 2006-04-27 18:10:14.000000000 +0200
@@ -1291,8 +1291,8 @@
*
* For pass > 3 we also try to shrink the LRU lists that contain a few pages
*/
-unsigned long shrink_all_zones(unsigned long nr_pages, int pass, int prio,
- struct scan_control *sc)
+static unsigned long shrink_all_zones(unsigned long nr_pages, int pass,
+ int prio, struct scan_control *sc)
{
struct zone *zone;
unsigned long nr_to_scan, ret = 0;
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y
2006-04-27 17:57 ` [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y Adrian Bunk
@ 2006-04-27 18:17 ` Andrew Morton
2006-04-27 20:15 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 90+ messages in thread
From: Andrew Morton @ 2006-04-27 18:17 UTC (permalink / raw
To: Adrian Bunk; +Cc: mchehab, linux-kernel, v4l-dvb-maintainer
Adrian Bunk <bunk@stusta.de> wrote:
>
> Below is the patch I sent you after I discovered the bug
> in 2.6.17-rc1-mm3. Is there any reason why you didn't merge my patch?
I saw you'd cc'ed the maintainer on it.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [-mm patch] mm/vmscan.c: make shrink_all_zones() static
2006-04-27 18:03 ` [-mm patch] mm/vmscan.c: make shrink_all_zones() static Adrian Bunk
@ 2006-04-27 18:52 ` Rafael J. Wysocki
0 siblings, 0 replies; 90+ messages in thread
From: Rafael J. Wysocki @ 2006-04-27 18:52 UTC (permalink / raw
To: Adrian Bunk; +Cc: Andrew Morton, Con Kolivas, linux-kernel
On Thursday 27 April 2006 20:03, Adrian Bunk wrote:
> On Thu, Apr 27, 2006 at 01:41:41AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-rc1-mm3:
> >...
> > +swsusp-rework-memory-shrinker-rev-2.patch
> >
> > Memory management updates
> >...
>
>
> This patch makes the needlessly global shrink_all_zones() static.
Thanks for fixing.
Greetings,
Rafael
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.17-rc2-mm1-full/mm/vmscan.c.old 2006-04-27 18:09:55.000000000 +0200
> +++ linux-2.6.17-rc2-mm1-full/mm/vmscan.c 2006-04-27 18:10:14.000000000 +0200
> @@ -1291,8 +1291,8 @@
> *
> * For pass > 3 we also try to shrink the LRU lists that contain a few pages
> */
> -unsigned long shrink_all_zones(unsigned long nr_pages, int pass, int prio,
> - struct scan_control *sc)
> +static unsigned long shrink_all_zones(unsigned long nr_pages, int pass,
> + int prio, struct scan_control *sc)
> {
> struct zone *zone;
> unsigned long nr_to_scan, ret = 0;
>
>
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 10:16 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-04-27 19:19 ` Andrew Morton
2006-04-27 19:26 ` 2.6.17-rc2-mm1 Andi Kleen
2006-04-27 21:41 ` 2.6.17-rc2-mm1 Grant Coady
0 siblings, 2 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-27 19:19 UTC (permalink / raw
To: Andi Kleen; +Cc: linux-kernel
Andi Kleen <ak@suse.de> wrote:
>
> > The acphphp driver is still broken and v4l and memory hotplug are, I
> > suspect, only hanging in there by the skin of their teeth.
> >
> > Could patch submitters _please_ be a lot more careful about getting the
> > Kconfig correct, testing various Kconfig combinations (yes sometimes
> > people will want to disable your lovely new feature) and just generally
> > think about these things a bit harder? It isn't rocket science.
>
> Is this something that could be automated with some machine power?
>
> e.g. every time a patch is added a small cluster could build the patches
> with some configurations on various architectures and if it doesn't build
> autoflame the patch submitter.
>
> We use this in SUSE for the SUSE kernels and it works quite well.
>
> Maybe someone could contribute the build power needed for that. I suppose
> it could be done by just a few scripts listening to mm-commits?
I suspect something like that would be quite a lot of work to set up -
first-up one has to get all the patches to actually apply, and then work
through any compile-time interactions between them. Dunno.
I don't like dropping patches. Because then the thing needs to be fixed up
and resent and remerged and re-reviewed and rejects need to re-fixed-up and
this adds emailing overhead and 12-24 hour turnaround, etc. I very much
prefer to hang onto the patch and get it fixed up. This means that I
usually have to do the fixing-up.
And that's OK - it's one of the things I do. But it's striking how silly
so many of these problems are - they demonstrate a very basic lack of care
and thought.
It's obvious that the originators haven't even compiled their feature with
its config option disabled, or they haven't spent the requisite 30
seconds thinking about their Kconfig dependencies, or they haven't verified
that all architectures support the architecture functions which they're
relying upon or they haven't grepped the tree for symbol clashes, etc.
So at this point in time what I'd like to do is to encourage developers to
do these very basic things. That's the low-hanging fruit right now.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 19:19 ` 2.6.17-rc2-mm1 Andrew Morton
@ 2006-04-27 19:26 ` Andi Kleen
2006-04-27 19:44 ` checklist (Re: 2.6.17-rc2-mm1) Randy.Dunlap
2006-04-27 21:41 ` 2.6.17-rc2-mm1 Grant Coady
1 sibling, 1 reply; 90+ messages in thread
From: Andi Kleen @ 2006-04-27 19:26 UTC (permalink / raw
To: Andrew Morton; +Cc: linux-kernel
On Thursday 27 April 2006 21:19, Andrew Morton wrote:
> Andi Kleen <ak@suse.de> wrote:
> >
> > > The acphphp driver is still broken and v4l and memory hotplug are, I
> > > suspect, only hanging in there by the skin of their teeth.
> > >
> > > Could patch submitters _please_ be a lot more careful about getting the
> > > Kconfig correct, testing various Kconfig combinations (yes sometimes
> > > people will want to disable your lovely new feature) and just generally
> > > think about these things a bit harder? It isn't rocket science.
> >
> > Is this something that could be automated with some machine power?
> >
> > e.g. every time a patch is added a small cluster could build the patches
> > with some configurations on various architectures and if it doesn't build
> > autoflame the patch submitter.
> >
> > We use this in SUSE for the SUSE kernels and it works quite well.
> >
> > Maybe someone could contribute the build power needed for that. I suppose
> > it could be done by just a few scripts listening to mm-commits?
>
> I suspect something like that would be quite a lot of work to set up -
> first-up one has to get all the patches to actually apply, and then work
> through any compile-time interactions between them. Dunno.
The invariant could be that any single new patch added should still
compile. And it should apply of course. If not then warn the submitter.
Might generate quite a lot of email though.
Problem is when people add new stuff in multiple pieces that only
compile together though. iirc they go to mm-commits as individual
pieces, not a bundle right now.
It would probably not catch everything - just a few common
configurations and architectures.
>
> I don't like dropping patches. Because then the thing needs to be fixed up
> and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> this adds emailing overhead and 12-24 hour turnaround, etc. I very much
> prefer to hang onto the patch and get it fixed up. This means that I
> usually have to do the fixing-up.
If it's caught early enough the submitter can be warned and they
might even fix it up themselves and send a new patch.
> So at this point in time what I'd like to do is to encourage developers to
> do these very basic things. That's the low-hanging fruit right now.
Write a checklist for that?
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 19:26 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-04-27 19:44 ` Randy.Dunlap
2006-04-27 20:11 ` Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Randy.Dunlap @ 2006-04-27 19:44 UTC (permalink / raw
To: Andi Kleen; +Cc: akpm, linux-kernel
> > So at this point in time what I'd like to do is to encourage developers to
> > do these very basic things. That's the low-hanging fruit right now.
>
> Write a checklist for that?
I've been meaning to write up one myself, so I'll give it a shot.
This is all above and beyond good patch log descriptions.
1. Build cleanly with applicable or modified CONFIG options =y, =m, and =n.
No gcc warnings/errors, no linker warnings/errors.
2. Build on multiple CPU arch-es by using local cross-compile tools
or something like PLM at OSDL.
3. Check cleanly with sparse.
4. Make sure that any new or modified CONFIG options don't muck up
the config menu.
5. Use 'make checkstack' and 'make namespacecheck' and fix any
problems that they find. Note: checkstack does not point out
problems explicitly, but any one function that uses more than
512 bytes on the stack is a candidate for change.
6. Include kernel-doc to document global kernel APIs. (Not required
for static functions, but OK there also.) Use 'make htmldocs'
or 'make mandocs' to check the kernel-doc and fix any issues.
---
~Randy
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:36 ` Martin Bligh
@ 2006-04-27 19:56 ` Andi Kleen
2006-04-27 21:00 ` Martin Bligh
2006-04-27 21:00 ` Christoph Hellwig
2006-04-28 14:03 ` Paulo Marques
1 sibling, 2 replies; 90+ messages in thread
From: Andi Kleen @ 2006-04-27 19:56 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, Randy.Dunlap, linux-kernel
On Thursday 27 April 2006 22:36, Martin Bligh wrote:
>
> > - Matches kernel coding style(!)
>
> E_NEEDS_AUTOMATED_FILTER / lint of some form.
Some Unixes have a cstyle(1). Maybe there is a free variant of it somewhere.
But such a tool might put a lot of people on l-k out of job @)
> The others all look doable.
>
> The intent would not be that you get burdened with this, but that
> developers send it there before sending it to you. It could even
> hand out
It would be better to automate this - not require the developers
to do lots of manual steps.
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 19:44 ` checklist (Re: 2.6.17-rc2-mm1) Randy.Dunlap
@ 2006-04-27 20:11 ` Andrew Morton
2006-04-27 20:17 ` Randy.Dunlap
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-27 20:11 UTC (permalink / raw
To: Randy.Dunlap; +Cc: ak, linux-kernel
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
>
> > > So at this point in time what I'd like to do is to encourage developers to
> > > do these very basic things. That's the low-hanging fruit right now.
> >
> > Write a checklist for that?
>
> I've been meaning to write up one myself, so I'll give it a shot.
>
> This is all above and beyond good patch log descriptions.
>
>
> 1. Build cleanly with applicable or modified CONFIG options =y, =m, and =n.
> No gcc warnings/errors, no linker warnings/errors.
>
> 2. Build on multiple CPU arch-es by using local cross-compile tools
> or something like PLM at OSDL.
>
> 3. Check cleanly with sparse.
>
> 4. Make sure that any new or modified CONFIG options don't muck up
> the config menu.
>
> 5. Use 'make checkstack' and 'make namespacecheck' and fix any
> problems that they find. Note: checkstack does not point out
> problems explicitly, but any one function that uses more than
> 512 bytes on the stack is a candidate for change.
>
> 6. Include kernel-doc to document global kernel APIs. (Not required
> for static functions, but OK there also.) Use 'make htmldocs'
> or 'make mandocs' to check the kernel-doc and fix any issues.
>
A lot of these are pretty hard and labor-intensive for people to set up and
run. It would be nice, but from a global perspective it's not efficient
for every member of the kernel team to do all these things. It's OK I
think if a few specialists run these tools against lots of people's patches
all at once.
Which is basically what we're doing now, although I suspect we could be
more rigorous about it.
I should be doing more of these things myself, but it's plenty enough work
getting though the "applies, doesn't-ridicule-coding-style,
compiles-without-warnings, boots-on-several-arches" steps. It's good that
Adrian does some of the other steps. I'm not aware of anyone who is doing
regular sparse and kernel-doc checking on -mm.
That all being said, these are all good things to have in a list.
To your list I'd add
- Passes allnoconfig, allmodconfig
- Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously enabled.
- Has been build- and runtime tested with and without CONFIG_SMP and
CONFIG_PREEMPT.
- If it affects IO/Disk, etc: has been tested with and without CONFIG_LBD.
- ppc64 is a good architecture for cross-compilation checking because it
tends to use `unsigned long' for 64-bit quantities.
- Has been carefully reviewed wrt relevant Kconfig combinations. This is
very hard to get right with testing - brainpower pays off here.
- Matches kernel coding style(!)
- All new Kconfig options have help text
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 21:00 ` Martin Bligh
@ 2006-04-27 20:11 ` Andi Kleen
2006-04-27 21:22 ` Martin Bligh
0 siblings, 1 reply; 90+ messages in thread
From: Andi Kleen @ 2006-04-27 20:11 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, Randy.Dunlap, linux-kernel
On Thursday 27 April 2006 23:00, Martin Bligh wrote:
> > Some Unixes have a cstyle(1). Maybe there is a free variant of it
> > somewhere. But such a tool might put a lot of people on l-k out of job @)
>
> heh. we could do some basic stuff at least. run through lindent, and see
> if it changes ;-)
Good luck weeding out the false positives from that.
> Can't tell whether that was meant to be positive or negative feedback.
> All this would require is "email patch to test-thingy@test.kernel.org".
I meant it would be better if it happened automatically when the patch
is submitted through the normal channels.
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y
2006-04-27 18:17 ` Andrew Morton
@ 2006-04-27 20:15 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 90+ messages in thread
From: Mauro Carvalho Chehab @ 2006-04-27 20:15 UTC (permalink / raw
To: Andrew Morton; +Cc: Adrian Bunk, linux-kernel, v4l-dvb-maintainer
Adrian,
Em Qui, 2006-04-27 às 11:17 -0700, Andrew Morton escreveu:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > Below is the patch I sent you after I discovered the bug
> > in 2.6.17-rc1-mm3. Is there any reason why you didn't merge my patch?
>
> I saw you'd cc'ed the maintainer on it.
I didn't received the patch you sent before. I'm applying it to my tree.
I will update today also devel, so that akpm may retrieve this one (and
also a bunch of newer patches...). Let me first test the hole patchset
with allyesconfig/allmodconfig to avoid other troubles.
Cheers,
Mauro.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:11 ` Andrew Morton
@ 2006-04-27 20:17 ` Randy.Dunlap
2006-04-27 20:36 ` Martin Bligh
2006-04-27 20:52 ` Jan Dittmer
2 siblings, 0 replies; 90+ messages in thread
From: Randy.Dunlap @ 2006-04-27 20:17 UTC (permalink / raw
To: Andrew Morton; +Cc: ak, linux-kernel
On Thu, 27 Apr 2006 13:11:00 -0700 Andrew Morton wrote:
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> >
> >
> > > > So at this point in time what I'd like to do is to encourage developers to
> > > > do these very basic things. That's the low-hanging fruit right now.
> > >
> > > Write a checklist for that?
> >
> > I've been meaning to write up one myself, so I'll give it a shot.
> >
> > This is all above and beyond good patch log descriptions.
> >
> >
> > 1. Build cleanly with applicable or modified CONFIG options =y, =m, and =n.
> > No gcc warnings/errors, no linker warnings/errors.
> >
> > 2. Build on multiple CPU arch-es by using local cross-compile tools
> > or something like PLM at OSDL.
> >
> > 3. Check cleanly with sparse.
> >
> > 4. Make sure that any new or modified CONFIG options don't muck up
> > the config menu.
> >
> > 5. Use 'make checkstack' and 'make namespacecheck' and fix any
> > problems that they find. Note: checkstack does not point out
> > problems explicitly, but any one function that uses more than
> > 512 bytes on the stack is a candidate for change.
> >
> > 6. Include kernel-doc to document global kernel APIs. (Not required
> > for static functions, but OK there also.) Use 'make htmldocs'
> > or 'make mandocs' to check the kernel-doc and fix any issues.
> >
>
> A lot of these are pretty hard and labor-intensive for people to set up and
> run. It would be nice, but from a global perspective it's not efficient
> for every member of the kernel team to do all these things. It's OK I
> think if a few specialists run these tools against lots of people's patches
> all at once.
Yes, I know/agree. This is basically what I do (and hope others
would do) for larger patches, not smallish ones.
> Which is basically what we're doing now, although I suspect we could be
> more rigorous about it.
>
> I should be doing more of these things myself, but it's plenty enough work
> getting though the "applies, doesn't-ridicule-coding-style,
> compiles-without-warnings, boots-on-several-arches" steps. It's good that
> Adrian does some of the other steps. I'm not aware of anyone who is doing
> regular sparse and kernel-doc checking on -mm.
>
> That all being said, these are all good things to have in a list.
>
> To your list I'd add
>
> - Passes allnoconfig, allmodconfig
>
> - Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_SLAB,
> CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
> CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously enabled.
>
> - Has been build- and runtime tested with and without CONFIG_SMP and
> CONFIG_PREEMPT.
>
> - If it affects IO/Disk, etc: has been tested with and without CONFIG_LBD.
>
> - ppc64 is a good architecture for cross-compilation checking because it
> tends to use `unsigned long' for 64-bit quantities.
>
> - Has been carefully reviewed wrt relevant Kconfig combinations. This is
> very hard to get right with testing - brainpower pays off here.
>
> - Matches kernel coding style(!)
>
> - All new Kconfig options have help text
Yep, all good, of course.
---
~Randy
^ permalink raw reply [flat|nested] 90+ messages in thread
* [-mm patch] fs/gfs2/: possible cleanups
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
` (6 preceding siblings ...)
2006-04-27 18:03 ` [-mm patch] mm/vmscan.c: make shrink_all_zones() static Adrian Bunk
@ 2006-04-27 20:33 ` Adrian Bunk
7 siblings, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2006-04-27 20:33 UTC (permalink / raw
To: Andrew Morton; +Cc: linux-kernel
On Thu, Apr 27, 2006 at 01:41:41AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-rc1-mm3:
>...
> git-gfs2.patch
>...
> git trees
>...
This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 unused functions
- remove the following global function that was both unused and
unimplemented:
- super.c: gfs2_do_upgrade()
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
BTW: Please add a MAINTAINERS entry.
fs/gfs2/bmap.c | 3 +-
fs/gfs2/bmap.h | 2 -
fs/gfs2/dir.c | 8 +++---
fs/gfs2/eaops.c | 2 -
fs/gfs2/eaops.h | 1
fs/gfs2/eattr.c | 3 ++
fs/gfs2/eattr.h | 2 -
fs/gfs2/glock.c | 25 +++++++++++++--------
fs/gfs2/glock.h | 12 ----------
fs/gfs2/lm.c | 2 +
fs/gfs2/lm.h | 1
fs/gfs2/locking/dlm/lock.c | 10 ++++----
fs/gfs2/locking/dlm/lock_dlm.h | 4 ---
fs/gfs2/locking/dlm/main.c | 4 +--
fs/gfs2/locking/nolock/main.c | 8 +++---
fs/gfs2/lvb.c | 2 +
fs/gfs2/lvb.h | 1
fs/gfs2/ondisk.c | 38 +++++++++++++++++++++++++++++----
fs/gfs2/quota.c | 2 +
fs/gfs2/quota.h | 2 -
fs/gfs2/super.c | 8 +-----
fs/gfs2/super.h | 2 -
include/linux/gfs2_ondisk.h | 14 ------------
23 files changed, 79 insertions(+), 77 deletions(-)
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/bmap.h.old 2006-04-27 20:54:02.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/bmap.h 2006-04-27 20:54:10.000000000 +0200
@@ -13,8 +13,6 @@
typedef int (*gfs2_unstuffer_t) (struct gfs2_inode * ip,
struct buffer_head * dibh, uint64_t block,
void *private);
-int gfs2_unstuffer_sync(struct gfs2_inode *ip, struct buffer_head *dibh,
- uint64_t block, void *private);
int gfs2_unstuff_dinode(struct gfs2_inode *ip, gfs2_unstuffer_t unstuffer,
void *private);
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/bmap.c.old 2006-04-27 20:54:18.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/bmap.c 2006-04-27 20:54:34.000000000 +0200
@@ -59,7 +59,7 @@ struct strip_mine {
*
* Returns: errno
*/
-
+#if 0
int gfs2_unstuffer_sync(struct gfs2_inode *ip, struct buffer_head *dibh,
uint64_t block, void *private)
{
@@ -77,6 +77,7 @@ int gfs2_unstuffer_sync(struct gfs2_inod
return error;
}
+#endif /* 0 */
/**
* gfs2_unstuff_dinode - Unstuff a dinode when the data has grown too big
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/dir.c.old 2006-04-27 20:54:49.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/dir.c 2006-04-27 20:55:04.000000000 +0200
@@ -669,10 +669,10 @@ static void dirent_del(struct gfs2_inode
* Takes a dent from which to grab space as an argument. Returns the
* newly created dent.
*/
-struct gfs2_dirent *gfs2_init_dirent(struct inode *inode,
- struct gfs2_dirent *dent,
- const struct qstr *name,
- struct buffer_head *bh)
+static struct gfs2_dirent *gfs2_init_dirent(struct inode *inode,
+ struct gfs2_dirent *dent,
+ const struct qstr *name,
+ struct buffer_head *bh)
{
struct gfs2_inode *ip = inode->u.generic_ip;
struct gfs2_dirent *ndent;
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/eaops.h.old 2006-04-27 20:56:40.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/eaops.h 2006-04-27 20:56:45.000000000 +0200
@@ -21,7 +21,6 @@ struct gfs2_eattr_operations {
unsigned int gfs2_ea_name2type(const char *name, char **truncated_name);
-extern struct gfs2_eattr_operations gfs2_user_eaops;
extern struct gfs2_eattr_operations gfs2_system_eaops;
extern struct gfs2_eattr_operations *gfs2_ea_ops[];
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/eaops.c.old 2006-04-27 20:56:54.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/eaops.c 2006-04-27 20:57:00.000000000 +0200
@@ -167,7 +167,7 @@ static int system_eo_remove(struct gfs2_
return gfs2_ea_remove_i(ip, er);
}
-struct gfs2_eattr_operations gfs2_user_eaops = {
+static struct gfs2_eattr_operations gfs2_user_eaops = {
.eo_get = user_eo_get,
.eo_set = user_eo_set,
.eo_remove = user_eo_remove,
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/eattr.h.old 2006-04-27 20:58:49.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/eattr.h 2006-04-27 20:58:54.000000000 +0200
@@ -61,8 +61,6 @@ struct gfs2_ea_location {
struct gfs2_ea_header *el_prev;
};
-int gfs2_ea_repack(struct gfs2_inode *ip);
-
int gfs2_ea_get_i(struct gfs2_inode *ip, struct gfs2_ea_request *er);
int gfs2_ea_set_i(struct gfs2_inode *ip, struct gfs2_ea_request *er);
int gfs2_ea_remove_i(struct gfs2_inode *ip, struct gfs2_ea_request *er);
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/eattr.c.old 2006-04-27 20:59:01.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/eattr.c 2006-04-27 21:16:12.000000000 +0200
@@ -358,6 +358,7 @@ static int ea_remove_unstuffed(struct gf
return error;
}
+#if 0
static int gfs2_ea_repack_i(struct gfs2_inode *ip)
{
@@ -382,6 +383,8 @@ int gfs2_ea_repack(struct gfs2_inode *ip
return error;
}
+#endif /* 0 */
+
struct ea_list {
struct gfs2_ea_request *ei_er;
unsigned int ei_size;
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/glock.h.old 2006-04-27 21:00:00.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/glock.h 2006-04-27 21:03:10.000000000 +0200
@@ -73,8 +73,6 @@ static inline int gfs2_glock_is_blocking
return ret;
}
-struct gfs2_glock *gfs2_glock_find(struct gfs2_sbd *sdp,
- struct lm_lockname *name);
int gfs2_glock_get(struct gfs2_sbd *sdp,
uint64_t number, struct gfs2_glock_operations *glops,
int create, struct gfs2_glock **glp);
@@ -85,15 +83,11 @@ void gfs2_holder_init(struct gfs2_glock
void gfs2_holder_reinit(unsigned int state, unsigned flags,
struct gfs2_holder *gh);
void gfs2_holder_uninit(struct gfs2_holder *gh);
-struct gfs2_holder *gfs2_holder_get(struct gfs2_glock *gl, unsigned int state,
- int flags, gfp_t gfp_flags);
-void gfs2_holder_put(struct gfs2_holder *gh);
void gfs2_glock_xmote_th(struct gfs2_glock *gl, unsigned int state, int flags);
void gfs2_glock_drop_th(struct gfs2_glock *gl);
void gfs2_glmutex_lock(struct gfs2_glock *gl);
-int gfs2_glmutex_trylock(struct gfs2_glock *gl);
void gfs2_glmutex_unlock(struct gfs2_glock *gl);
int gfs2_glock_nq(struct gfs2_holder *gh);
@@ -101,9 +95,6 @@ int gfs2_glock_poll(struct gfs2_holder *
int gfs2_glock_wait(struct gfs2_holder *gh);
void gfs2_glock_dq(struct gfs2_holder *gh);
-void gfs2_glock_prefetch(struct gfs2_glock *gl, unsigned int state, int flags);
-void gfs2_glock_force_drop(struct gfs2_glock *gl);
-
int gfs2_glock_be_greedy(struct gfs2_glock *gl, unsigned int time);
void gfs2_glock_dq_uninit(struct gfs2_holder *gh);
@@ -148,7 +139,6 @@ static inline int gfs2_glock_nq_init(str
int gfs2_lvb_hold(struct gfs2_glock *gl);
void gfs2_lvb_unhold(struct gfs2_glock *gl);
-void gfs2_lvb_sync(struct gfs2_glock *gl);
void gfs2_glock_cb(lm_fsdata_t *fsdata, unsigned int type, void *data);
@@ -161,6 +151,4 @@ void gfs2_reclaim_glock(struct gfs2_sbd
void gfs2_scand_internal(struct gfs2_sbd *sdp);
void gfs2_gl_hash_clear(struct gfs2_sbd *sdp, int wait);
-int gfs2_dump_lockstate(struct gfs2_sbd *sdp);
-
#endif /* __GLOCK_DOT_H__ */
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/glock.c.old 2006-04-27 21:00:13.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/glock.c 2006-04-27 21:03:23.000000000 +0200
@@ -47,6 +47,8 @@ struct greedy {
typedef void (*glock_examiner) (struct gfs2_glock * gl);
+static int gfs2_dump_lockstate(struct gfs2_sbd *sdp);
+
/**
* relaxed_state_ok - is a requested lock compatible with the current lock mode?
* @actual: the current state of the lock
@@ -228,8 +230,8 @@ static struct gfs2_glock *search_bucket(
* Returns: NULL, or the struct gfs2_glock with the requested number
*/
-struct gfs2_glock *gfs2_glock_find(struct gfs2_sbd *sdp,
- struct lm_lockname *name)
+static struct gfs2_glock *gfs2_glock_find(struct gfs2_sbd *sdp,
+ struct lm_lockname *name)
{
struct gfs2_gl_hash_bucket *bucket = &sdp->sd_gl_hash[gl_hash(name)];
struct gfs2_glock *gl;
@@ -421,8 +423,9 @@ void gfs2_holder_uninit(struct gfs2_hold
* Returns: the holder structure, NULL on ENOMEM
*/
-struct gfs2_holder *gfs2_holder_get(struct gfs2_glock *gl, unsigned int state,
- int flags, gfp_t gfp_flags)
+static struct gfs2_holder *gfs2_holder_get(struct gfs2_glock *gl,
+ unsigned int state,
+ int flags, gfp_t gfp_flags)
{
struct gfs2_holder *gh;
@@ -442,7 +445,7 @@ struct gfs2_holder *gfs2_holder_get(stru
*
*/
-void gfs2_holder_put(struct gfs2_holder *gh)
+static void gfs2_holder_put(struct gfs2_holder *gh)
{
gfs2_holder_uninit(gh);
kfree(gh);
@@ -674,7 +677,7 @@ void gfs2_glmutex_lock(struct gfs2_glock
* Returns: 1 if the glock is acquired
*/
-int gfs2_glmutex_trylock(struct gfs2_glock *gl)
+static int gfs2_glmutex_trylock(struct gfs2_glock *gl)
{
int acquired = 1;
@@ -1301,7 +1304,8 @@ void gfs2_glock_dq(struct gfs2_holder *g
*
*/
-void gfs2_glock_prefetch(struct gfs2_glock *gl, unsigned int state, int flags)
+static void gfs2_glock_prefetch(struct gfs2_glock *gl, unsigned int state,
+ int flags)
{
struct gfs2_glock_operations *glops = gl->gl_ops;
@@ -1329,7 +1333,7 @@ void gfs2_glock_prefetch(struct gfs2_glo
* @gl: the glock
*
*/
-
+#if 0
void gfs2_glock_force_drop(struct gfs2_glock *gl)
{
struct gfs2_holder gh;
@@ -1345,6 +1349,7 @@ void gfs2_glock_force_drop(struct gfs2_g
wait_for_completion(&gh.gh_wait);
gfs2_holder_uninit(&gh);
}
+#endif /* 0 */
static void greedy_work(void *data)
{
@@ -1697,6 +1702,7 @@ void gfs2_lvb_unhold(struct gfs2_glock *
gfs2_glock_put(gl);
}
+#if 0
void gfs2_lvb_sync(struct gfs2_glock *gl)
{
gfs2_glmutex_lock(gl);
@@ -1707,6 +1713,7 @@ void gfs2_lvb_sync(struct gfs2_glock *gl
gfs2_glmutex_unlock(gl);
}
+#endif /* 0 */
static void blocking_cb(struct gfs2_sbd *sdp, struct lm_lockname *name,
unsigned int state)
@@ -2308,7 +2315,7 @@ static int dump_glock(struct gfs2_glock
*
*/
-int gfs2_dump_lockstate(struct gfs2_sbd *sdp)
+static int gfs2_dump_lockstate(struct gfs2_sbd *sdp)
{
struct gfs2_gl_hash_bucket *bucket;
struct gfs2_glock *gl;
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/dlm/lock_dlm.h.old 2006-04-27 21:03:37.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/dlm/lock_dlm.h 2006-04-27 21:04:52.000000000 +0200
@@ -162,12 +162,8 @@ int16_t gdlm_make_lmstate(int16_t);
void gdlm_queue_delayed(struct gdlm_lock *);
void gdlm_submit_delayed(struct gdlm_ls *);
int gdlm_release_all_locks(struct gdlm_ls *);
-int gdlm_create_lp(struct gdlm_ls *, struct lm_lockname *, struct gdlm_lock **);
void gdlm_delete_lp(struct gdlm_lock *);
-int gdlm_add_lvb(struct gdlm_lock *);
-void gdlm_del_lvb(struct gdlm_lock *);
unsigned int gdlm_do_lock(struct gdlm_lock *);
-unsigned int gdlm_do_unlock(struct gdlm_lock *);
int gdlm_get_lock(lm_lockspace_t *, struct lm_lockname *, lm_lock_t **);
void gdlm_put_lock(lm_lock_t *);
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/dlm/lock.c.old 2006-04-27 21:03:50.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/dlm/lock.c 2006-04-27 21:05:02.000000000 +0200
@@ -158,8 +158,8 @@ static inline void make_strname(struct l
str->namelen = GDLM_STRNAME_BYTES;
}
-int gdlm_create_lp(struct gdlm_ls *ls, struct lm_lockname *name,
- struct gdlm_lock **lpp)
+static int gdlm_create_lp(struct gdlm_ls *ls, struct lm_lockname *name,
+ struct gdlm_lock **lpp)
{
struct gdlm_lock *lp;
@@ -276,7 +276,7 @@ unsigned int gdlm_do_lock(struct gdlm_lo
return LM_OUT_ASYNC;
}
-unsigned int gdlm_do_unlock(struct gdlm_lock *lp)
+static unsigned int gdlm_do_unlock(struct gdlm_lock *lp)
{
struct gdlm_ls *ls = lp->ls;
unsigned int lkf = 0;
@@ -378,7 +378,7 @@ void gdlm_cancel(lm_lock_t *lock)
clear_bit(LFL_DLM_CANCEL, &lp->flags);
}
-int gdlm_add_lvb(struct gdlm_lock *lp)
+static int gdlm_add_lvb(struct gdlm_lock *lp)
{
char *lvb;
@@ -391,7 +391,7 @@ int gdlm_add_lvb(struct gdlm_lock *lp)
return 0;
}
-void gdlm_del_lvb(struct gdlm_lock *lp)
+static void gdlm_del_lvb(struct gdlm_lock *lp)
{
kfree(lp->lvb);
lp->lvb = NULL;
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/dlm/main.c.old 2006-04-27 21:05:38.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/dlm/main.c 2006-04-27 21:07:01.000000000 +0200
@@ -16,7 +16,7 @@ extern int gdlm_drop_period;
extern struct lm_lockops gdlm_ops;
-int __init init_lock_dlm(void)
+static int __init init_lock_dlm(void)
{
int error;
@@ -48,7 +48,7 @@ int __init init_lock_dlm(void)
return 0;
}
-void __exit exit_lock_dlm(void)
+static void __exit exit_lock_dlm(void)
{
gdlm_plock_exit();
gdlm_sysfs_exit();
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/nolock/main.c.old 2006-04-27 21:07:22.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/locking/nolock/main.c 2006-04-27 21:08:01.000000000 +0200
@@ -21,7 +21,7 @@ struct nolock_lockspace {
unsigned int nl_lvb_size;
};
-struct lm_lockops nolock_ops;
+static struct lm_lockops nolock_ops;
static int nolock_mount(char *table_name, char *host_data,
lm_callback_t cb, lm_fsdata_t *fsdata,
@@ -208,7 +208,7 @@ static void nolock_recovery_done(lm_lock
{
}
-struct lm_lockops nolock_ops = {
+static struct lm_lockops nolock_ops = {
.lm_proto_name = "lock_nolock",
.lm_mount = nolock_mount,
.lm_others_may_mount = nolock_others_may_mount,
@@ -229,7 +229,7 @@ struct lm_lockops nolock_ops = {
.lm_owner = THIS_MODULE,
};
-int __init init_nolock(void)
+static int __init init_nolock(void)
{
int error;
@@ -245,7 +245,7 @@ int __init init_nolock(void)
return 0;
}
-void __exit exit_nolock(void)
+static void __exit exit_nolock(void)
{
gfs_unregister_lockproto(&nolock_ops);
}
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/lvb.h.old 2006-04-27 21:08:19.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/lvb.h 2006-04-27 21:08:25.000000000 +0200
@@ -14,7 +14,6 @@
void gfs2_quota_lvb_in(struct gfs2_quota_lvb *qb, char *lvb);
void gfs2_quota_lvb_out(struct gfs2_quota_lvb *qb, char *lvb);
-void gfs2_quota_lvb_print(struct gfs2_quota_lvb *qb);
#endif /* __LVB_DOT_H__ */
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/lvb.c.old 2006-04-27 21:08:33.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/lvb.c 2006-04-27 21:08:45.000000000 +0200
@@ -43,6 +43,7 @@ void gfs2_quota_lvb_out(struct gfs2_quot
str->qb_value = cpu_to_be64(qb->qb_value);
}
+#if 0
void gfs2_quota_lvb_print(struct gfs2_quota_lvb *qb)
{
pv(qb, qb_magic, "%u");
@@ -50,4 +51,5 @@ void gfs2_quota_lvb_print(struct gfs2_qu
pv(qb, qb_warn, "%llu");
pv(qb, qb_value, "%lld");
}
+#endif /* 0 */
--- linux-2.6.17-rc2-mm1-full/include/linux/gfs2_ondisk.h.old 2006-04-27 21:09:03.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/include/linux/gfs2_ondisk.h 2006-04-27 21:20:13.000000000 +0200
@@ -450,22 +450,8 @@ extern void gfs2_quota_change_in(struct
/* Printing functions */
-extern void gfs2_inum_print(struct gfs2_inum *no);
-extern void gfs2_meta_header_print(struct gfs2_meta_header *mh);
-extern void gfs2_sb_print(struct gfs2_sb *sb);
extern void gfs2_rindex_print(struct gfs2_rindex *ri);
-extern void gfs2_rgrp_print(struct gfs2_rgrp *rg);
-extern void gfs2_quota_print(struct gfs2_quota *qu);
extern void gfs2_dinode_print(struct gfs2_dinode *di);
-extern void gfs2_dirent_print(struct gfs2_dirent *de, char *name);
-extern void gfs2_leaf_print(struct gfs2_leaf *lf);
-extern void gfs2_ea_header_print(struct gfs2_ea_header *ea, char *name);
-extern void gfs2_log_header_print(struct gfs2_log_header *lh);
-extern void gfs2_log_descriptor_print(struct gfs2_log_descriptor *ld);
-extern void gfs2_inum_range_print(struct gfs2_inum_range *ir);
-extern void gfs2_statfs_change_print(struct gfs2_statfs_change *sc);
-extern void gfs2_unlinked_tag_print(struct gfs2_unlinked_tag *ut);
-extern void gfs2_quota_change_print(struct gfs2_quota_change *qc);
#endif /* __KERNEL__ */
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/ondisk.c.old 2006-04-27 21:20:28.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/ondisk.c 2006-04-27 21:49:09.000000000 +0200
@@ -28,7 +28,7 @@
* @count: the number of bytes
*
*/
-
+#if 0
static void print_array(char *title, char *buf, int count)
{
int x;
@@ -42,6 +42,7 @@ static void print_array(char *title, cha
if (x % 16)
printk("\n");
}
+#endif /* 0 */
/*
* gfs2_xxx_in - read in an xxx struct
@@ -72,7 +73,7 @@ void gfs2_inum_out(const struct gfs2_inu
str->no_addr = cpu_to_be64(no->no_addr);
}
-void gfs2_inum_print(struct gfs2_inum *no)
+static void gfs2_inum_print(struct gfs2_inum *no)
{
pv(no, no_formal_ino, "%llu");
pv(no, no_addr, "%llu");
@@ -96,7 +97,7 @@ static void gfs2_meta_header_out(struct
str->mh_format = cpu_to_be32(mh->mh_format);
}
-void gfs2_meta_header_print(struct gfs2_meta_header *mh)
+static void gfs2_meta_header_print(struct gfs2_meta_header *mh)
{
pv(mh, mh_magic, "0x%.8X");
pv(mh, mh_type, "%u");
@@ -121,6 +122,7 @@ void gfs2_sb_in(struct gfs2_sb *sb, char
memcpy(sb->sb_locktable, str->sb_locktable, GFS2_LOCKNAME_LEN);
}
+#if 0
void gfs2_sb_print(struct gfs2_sb *sb)
{
gfs2_meta_header_print(&sb->sb_header);
@@ -136,6 +138,7 @@ void gfs2_sb_print(struct gfs2_sb *sb)
pv(sb, sb_lockproto, "%s");
pv(sb, sb_locktable, "%s");
}
+#endif /* 0 */
void gfs2_rindex_in(struct gfs2_rindex *ri, char *buf)
{
@@ -149,6 +152,7 @@ void gfs2_rindex_in(struct gfs2_rindex *
}
+#if 0
void gfs2_rindex_out(struct gfs2_rindex *ri, char *buf)
{
struct gfs2_rindex *str = (struct gfs2_rindex *)buf;
@@ -163,6 +167,8 @@ void gfs2_rindex_out(struct gfs2_rindex
memset(str->ri_reserved, 0, sizeof(str->ri_reserved));
}
+#endif /* 0 */
+
void gfs2_rindex_print(struct gfs2_rindex *ri)
{
pv(ri, ri_addr, "%llu");
@@ -196,6 +202,7 @@ void gfs2_rgrp_out(struct gfs2_rgrp *rg,
memset(&str->rg_reserved, 0, sizeof(str->rg_reserved));
}
+#if 0
void gfs2_rgrp_print(struct gfs2_rgrp *rg)
{
gfs2_meta_header_print(&rg->rg_header);
@@ -205,6 +212,7 @@ void gfs2_rgrp_print(struct gfs2_rgrp *r
pa(rg, rg_reserved, 36);
}
+#endif /* 0 */
void gfs2_quota_in(struct gfs2_quota *qu, char *buf)
{
@@ -215,6 +223,8 @@ void gfs2_quota_in(struct gfs2_quota *qu
qu->qu_value = be64_to_cpu(str->qu_value);
}
+#if 0
+
void gfs2_quota_out(struct gfs2_quota *qu, char *buf)
{
struct gfs2_quota *str = (struct gfs2_quota *)buf;
@@ -231,6 +241,8 @@ void gfs2_quota_print(struct gfs2_quota
pv(qu, qu_value, "%lld");
}
+#endif /* 0 */
+
void gfs2_dinode_in(struct gfs2_dinode *di, char *buf)
{
struct gfs2_dinode *str = (struct gfs2_dinode *)buf;
@@ -327,6 +339,8 @@ void gfs2_dinode_print(struct gfs2_dinod
pv(di, di_eattr, "%llu");
}
+#if 0
+
void gfs2_dirent_print(struct gfs2_dirent *de, char *name)
{
char buf[GFS2_FNAMESIZE + 1];
@@ -394,6 +408,8 @@ void gfs2_ea_header_print(struct gfs2_ea
printk(KERN_INFO " name = %s\n", buf);
}
+#endif /* 0 */
+
void gfs2_log_header_in(struct gfs2_log_header *lh, char *buf)
{
struct gfs2_log_header *str = (struct gfs2_log_header *)buf;
@@ -406,6 +422,8 @@ void gfs2_log_header_in(struct gfs2_log_
lh->lh_hash = be32_to_cpu(str->lh_hash);
}
+#if 0
+
void gfs2_log_header_print(struct gfs2_log_header *lh)
{
gfs2_meta_header_print(&lh->lh_header);
@@ -427,6 +445,8 @@ void gfs2_log_descriptor_print(struct gf
pa(ld, ld_reserved, 32);
}
+#endif /* 0 */
+
void gfs2_inum_range_in(struct gfs2_inum_range *ir, char *buf)
{
struct gfs2_inum_range *str = (struct gfs2_inum_range *)buf;
@@ -443,11 +463,13 @@ void gfs2_inum_range_out(struct gfs2_inu
str->ir_length = cpu_to_be64(ir->ir_length);
}
+#if 0
void gfs2_inum_range_print(struct gfs2_inum_range *ir)
{
pv(ir, ir_start, "%llu");
pv(ir, ir_length, "%llu");
}
+#endif /* 0 */
void gfs2_statfs_change_in(struct gfs2_statfs_change *sc, char *buf)
{
@@ -467,12 +489,14 @@ void gfs2_statfs_change_out(struct gfs2_
str->sc_dinodes = cpu_to_be64(sc->sc_dinodes);
}
+#if 0
void gfs2_statfs_change_print(struct gfs2_statfs_change *sc)
{
pv(sc, sc_total, "%lld");
pv(sc, sc_free, "%lld");
pv(sc, sc_dinodes, "%lld");
}
+#endif /* 0 */
void gfs2_unlinked_tag_in(struct gfs2_unlinked_tag *ut, char *buf)
{
@@ -491,12 +515,16 @@ void gfs2_unlinked_tag_out(struct gfs2_u
str->__pad = 0;
}
+#if 0
+
void gfs2_unlinked_tag_print(struct gfs2_unlinked_tag *ut)
{
gfs2_inum_print(&ut->ut_inum);
pv(ut, ut_flags, "%u");
}
+#endif /* 0 */
+
void gfs2_quota_change_in(struct gfs2_quota_change *qc, char *buf)
{
struct gfs2_quota_change *str = (struct gfs2_quota_change *)buf;
@@ -506,6 +534,8 @@ void gfs2_quota_change_in(struct gfs2_qu
qc->qc_id = be32_to_cpu(str->qc_id);
}
+#if 0
+
void gfs2_quota_change_print(struct gfs2_quota_change *qc)
{
pv(qc, qc_change, "%lld");
@@ -513,5 +543,5 @@ void gfs2_quota_change_print(struct gfs2
pv(qc, qc_id, "%u");
}
-
+#endif /* 0 */
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/quota.h.old 2006-04-27 21:11:20.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/quota.h 2006-04-27 21:11:26.000000000 +0200
@@ -24,8 +24,6 @@ void gfs2_quota_change(struct gfs2_inode
int gfs2_quota_sync(struct gfs2_sbd *sdp);
int gfs2_quota_refresh(struct gfs2_sbd *sdp, int user, uint32_t id);
-int gfs2_quota_read(struct gfs2_sbd *sdp, int user, uint32_t id,
- struct gfs2_quota *q);
int gfs2_quota_init(struct gfs2_sbd *sdp);
void gfs2_quota_scan(struct gfs2_sbd *sdp);
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/quota.c.old 2006-04-27 21:11:33.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/quota.c 2006-04-27 21:11:55.000000000 +0200
@@ -1086,6 +1086,7 @@ int gfs2_quota_refresh(struct gfs2_sbd *
return error;
}
+#if 0
int gfs2_quota_read(struct gfs2_sbd *sdp, int user, uint32_t id,
struct gfs2_quota *q)
{
@@ -1121,6 +1122,7 @@ int gfs2_quota_read(struct gfs2_sbd *sdp
return error;
}
+#endif /* 0 */
int gfs2_quota_init(struct gfs2_sbd *sdp)
{
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/super.h.old 2006-04-27 21:12:13.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/super.h 2006-04-27 21:13:03.000000000 +0200
@@ -14,7 +14,6 @@ void gfs2_tune_init(struct gfs2_tune *gt
int gfs2_check_sb(struct gfs2_sbd *sdp, struct gfs2_sb *sb, int silent);
int gfs2_read_sb(struct gfs2_sbd *sdp, struct gfs2_glock *gl, int silent);
-int gfs2_do_upgrade(struct gfs2_sbd *sdp, struct gfs2_glock *gl_sb);
static inline unsigned int gfs2_jindex_size(struct gfs2_sbd *sdp)
{
@@ -46,7 +45,6 @@ int gfs2_statfs_sync(struct gfs2_sbd *sd
int gfs2_statfs_i(struct gfs2_sbd *sdp, struct gfs2_statfs_change *sc);
int gfs2_statfs_slow(struct gfs2_sbd *sdp, struct gfs2_statfs_change *sc);
-int gfs2_lock_fs_check_clean(struct gfs2_sbd *sdp, struct gfs2_holder *t_gh);
int gfs2_freeze_fs(struct gfs2_sbd *sdp);
void gfs2_unfreeze_fs(struct gfs2_sbd *sdp);
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/super.c.old 2006-04-27 21:12:26.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/super.c 2006-04-27 21:13:14.000000000 +0200
@@ -264,11 +264,6 @@ int gfs2_read_sb(struct gfs2_sbd *sdp, s
return 0;
}
-int gfs2_do_upgrade(struct gfs2_sbd *sdp, struct gfs2_glock *sb_gl)
-{
- return 0;
-}
-
/**
* gfs2_jindex_hold - Grab a lock on the jindex
* @sdp: The GFS2 superblock
@@ -837,7 +832,8 @@ struct lfcc {
* Returns: errno
*/
-int gfs2_lock_fs_check_clean(struct gfs2_sbd *sdp, struct gfs2_holder *t_gh)
+static int gfs2_lock_fs_check_clean(struct gfs2_sbd *sdp,
+ struct gfs2_holder *t_gh)
{
struct gfs2_inode *ip;
struct gfs2_holder ji_gh;
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/lm.h.old 2006-04-27 22:05:59.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/lm.h 2006-04-27 22:06:03.000000000 +0200
@@ -26,7 +26,6 @@ unsigned int gfs2_lm_unlock(struct gfs2_
void gfs2_lm_cancel(struct gfs2_sbd *sdp, lm_lock_t *lock);
int gfs2_lm_hold_lvb(struct gfs2_sbd *sdp, lm_lock_t *lock, char **lvbp);
void gfs2_lm_unhold_lvb(struct gfs2_sbd *sdp, lm_lock_t *lock, char *lvb);
-void gfs2_lm_sync_lvb(struct gfs2_sbd *sdp, lm_lock_t *lock, char *lvb);
int gfs2_lm_plock_get(struct gfs2_sbd *sdp,
struct lm_lockname *name,
struct file *file, struct file_lock *fl);
--- linux-2.6.17-rc2-mm1-full/fs/gfs2/lm.c.old 2006-04-27 22:06:11.000000000 +0200
+++ linux-2.6.17-rc2-mm1-full/fs/gfs2/lm.c 2006-04-27 22:06:24.000000000 +0200
@@ -188,11 +188,13 @@ void gfs2_lm_unhold_lvb(struct gfs2_sbd
sdp->sd_lockstruct.ls_ops->lm_unhold_lvb(lock, lvb);
}
+#if 0
void gfs2_lm_sync_lvb(struct gfs2_sbd *sdp, lm_lock_t *lock, char *lvb)
{
if (likely(!test_bit(SDF_SHUTDOWN, &sdp->sd_flags)))
sdp->sd_lockstruct.ls_ops->lm_sync_lvb(lock, lvb);
}
+#endif /* 0 */
int gfs2_lm_plock_get(struct gfs2_sbd *sdp, struct lm_lockname *name,
struct file *file, struct file_lock *fl)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:11 ` Andrew Morton
2006-04-27 20:17 ` Randy.Dunlap
@ 2006-04-27 20:36 ` Martin Bligh
2006-04-27 19:56 ` Andi Kleen
2006-04-28 14:03 ` Paulo Marques
2006-04-27 20:52 ` Jan Dittmer
2 siblings, 2 replies; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 20:36 UTC (permalink / raw
To: Andrew Morton; +Cc: Randy.Dunlap, ak, linux-kernel
> A lot of these are pretty hard and labor-intensive for people to set up and
> run. It would be nice, but from a global perspective it's not efficient
> for every member of the kernel team to do all these things. It's OK I
> think if a few specialists run these tools against lots of people's patches
> all at once.
>
> Which is basically what we're doing now, although I suspect we could be
> more rigorous about it.
How about if I set up an automated email drop - you email it a patch and
it will compile test it on a few different configs and run sparse, will
send you back mail when it's done.
I don't want to boot it, as that gets into security nightmares, but I
should be able to provide something that does static testing.
> - Matches kernel coding style(!)
E_NEEDS_AUTOMATED_FILTER / lint of some form.
The others all look doable.
The intent would not be that you get burdened with this, but that
developers send it there before sending it to you. It could even
hand out
Signed-off-by: Magic-testing-framework <basictest@test.kernel.org>
tokens to people who use it ;-)
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:11 ` Andrew Morton
2006-04-27 20:17 ` Randy.Dunlap
2006-04-27 20:36 ` Martin Bligh
@ 2006-04-27 20:52 ` Jan Dittmer
2006-04-27 21:01 ` Randy.Dunlap
2 siblings, 1 reply; 90+ messages in thread
From: Jan Dittmer @ 2006-04-27 20:52 UTC (permalink / raw
To: Andrew Morton; +Cc: Randy.Dunlap, ak, linux-kernel
Andrew Morton wrote:
> Adrian does some of the other steps. I'm not aware of anyone who is doing
> regular sparse and kernel-doc checking on -mm.
Sparse checks are in the results at http://l4x.org/k/ . There is just
someone missing who looks at the results :(
Jan
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 15:32 ` 2.6.17-rc2-mm1 Michal Piotrowski
@ 2006-04-27 20:53 ` Greg KH
2006-04-27 22:09 ` 2.6.17-rc2-mm1 Michal Piotrowski
0 siblings, 1 reply; 90+ messages in thread
From: Greg KH @ 2006-04-27 20:53 UTC (permalink / raw
To: Michal Piotrowski; +Cc: Andrew Morton, linux-kernel
On Thu, Apr 27, 2006 at 05:32:43PM +0200, Michal Piotrowski wrote:
> Hi Greg,
>
> On 27/04/06, Greg KH <gregkh@suse.de> wrote:
> [snip]
> >
> > Ah, I guess it is causing you problems :)
> >
> > > Here is config:
> > > http://www.stardust.webpages.pl/files/mm/2.6.17-rc2-mm1/mm-config
> >
> > If you set CONFIG_NDEV_FS=n does the oops go away?
>
> Yes.
Ok, I've spent a bit of time trying to reproduce this and I can't. So
I'm just going to drop it from the patch set, because as you point out,
it's never going to go to mainline anyway, it was just a fun hack.
Sorry for the noise,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 19:56 ` Andi Kleen
@ 2006-04-27 21:00 ` Martin Bligh
2006-04-27 20:11 ` Andi Kleen
2006-04-27 21:00 ` Christoph Hellwig
1 sibling, 1 reply; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 21:00 UTC (permalink / raw
To: Andi Kleen; +Cc: Andrew Morton, Randy.Dunlap, linux-kernel
> Some Unixes have a cstyle(1). Maybe there is a free variant of it somewhere.
> But such a tool might put a lot of people on l-k out of job @)
heh. we could do some basic stuff at least. run through lindent, and see
if it changes ;-)
>>The others all look doable.
>>
>>The intent would not be that you get burdened with this, but that
>>developers send it there before sending it to you. It could even
>>hand out
>
> It would be better to automate this - not require the developers
> to do lots of manual steps.
Can't tell whether that was meant to be positive or negative feedback.
All this would require is "email patch to test-thingy@test.kernel.org".
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 19:56 ` Andi Kleen
2006-04-27 21:00 ` Martin Bligh
@ 2006-04-27 21:00 ` Christoph Hellwig
1 sibling, 0 replies; 90+ messages in thread
From: Christoph Hellwig @ 2006-04-27 21:00 UTC (permalink / raw
To: Andi Kleen; +Cc: Martin Bligh, Andrew Morton, Randy.Dunlap, linux-kernel
On Thu, Apr 27, 2006 at 09:56:11PM +0200, Andi Kleen wrote:
> On Thursday 27 April 2006 22:36, Martin Bligh wrote:
>
>
> >
> > > - Matches kernel coding style(!)
> >
> > E_NEEDS_AUTOMATED_FILTER / lint of some form.
>
> Some Unixes have a cstyle(1). Maybe there is a free variant of it somewhere.
> But such a tool might put a lot of people on l-k out of job @)
apparently the solaris one is released now as free software. haven't
actually looked at it yet, and it'd surely need various changes to
enforce the linux rules.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:52 ` Jan Dittmer
@ 2006-04-27 21:01 ` Randy.Dunlap
0 siblings, 0 replies; 90+ messages in thread
From: Randy.Dunlap @ 2006-04-27 21:01 UTC (permalink / raw
To: Jan Dittmer; +Cc: akpm, ak, linux-kernel
On Thu, 27 Apr 2006 22:52:00 +0200 Jan Dittmer wrote:
> Andrew Morton wrote:
> > Adrian does some of the other steps. I'm not aware of anyone who is doing
> > regular sparse and kernel-doc checking on -mm.
>
> Sparse checks are in the results at http://l4x.org/k/ . There is just
> someone missing who looks at the results :(
Thanks for reminding us of the URL.
If someone wants to try to fix those, they still should verify
their patches with gcc & sparse, of course.
And we've seen that problem of not looking at the results before. :(
---
~Randy
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:11 ` Andi Kleen
@ 2006-04-27 21:22 ` Martin Bligh
2006-04-28 17:30 ` Rafał J. Wysocki
0 siblings, 1 reply; 90+ messages in thread
From: Martin Bligh @ 2006-04-27 21:22 UTC (permalink / raw
To: Andi Kleen; +Cc: Andrew Morton, Randy.Dunlap, linux-kernel
Andi Kleen wrote:
> On Thursday 27 April 2006 23:00, Martin Bligh wrote:
>
>>>Some Unixes have a cstyle(1). Maybe there is a free variant of it
>>>somewhere. But such a tool might put a lot of people on l-k out of job @)
>>
>>heh. we could do some basic stuff at least. run through lindent, and see
>>if it changes ;-)
>
> Good luck weeding out the false positives from that.
Yes, I was joking.
>>Can't tell whether that was meant to be positive or negative feedback.
>>All this would require is "email patch to test-thingy@test.kernel.org".
>
>
> I meant it would be better if it happened automatically when the patch
> is submitted through the normal channels.
It would, and it pretty much does right now, in that we test -mm
(OK, we don't run sparse, but that's easy to fix). What I was trying to
do was take the burden off Andrew for handling the testing of every
single patch, which means getting the developer to deal with it.
Personally, I don't think "please email your patch in for automated
testing" is too much to ask from them.
It'd be easy to make the automated tester forward it to Andrew or
whatever, if it passed the tests.
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 19:19 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 19:26 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-04-27 21:41 ` Grant Coady
2006-04-27 21:50 ` 2.6.17-rc2-mm1 Randy.Dunlap
1 sibling, 1 reply; 90+ messages in thread
From: Grant Coady @ 2006-04-27 21:41 UTC (permalink / raw
To: Andrew Morton; +Cc: Andi Kleen, linux-kernel
On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <akpm@osdl.org> wrote:
>I don't like dropping patches. Because then the thing needs to be fixed up
>and resent and remerged and re-reviewed and rejects need to re-fixed-up and
>this adds emailing overhead and 12-24 hour turnaround, etc. I very much
>prefer to hang onto the patch and get it fixed up. This means that I
>usually have to do the fixing-up.
Perhaps dropping patches with obvious faults with some feedback
to submitter may reduce your workload ;) And is slowing down the
merge a little in these cases such a bad thing if it improves
patch quality over time?
Grant.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 21:41 ` 2.6.17-rc2-mm1 Grant Coady
@ 2006-04-27 21:50 ` Randy.Dunlap
2006-04-27 22:16 ` 2.6.17-rc2-mm1 Andrew Morton
0 siblings, 1 reply; 90+ messages in thread
From: Randy.Dunlap @ 2006-04-27 21:50 UTC (permalink / raw
To: Grant Coady; +Cc: akpm, ak, linux-kernel
On Fri, 28 Apr 2006 07:41:52 +1000 Grant Coady wrote:
> On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <akpm@osdl.org> wrote:
>
> >I don't like dropping patches. Because then the thing needs to be fixed up
> >and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> >this adds emailing overhead and 12-24 hour turnaround, etc. I very much
> >prefer to hang onto the patch and get it fixed up. This means that I
> >usually have to do the fixing-up.
>
> Perhaps dropping patches with obvious faults with some feedback
> to submitter may reduce your workload ;) And is slowing down the
> merge a little in these cases such a bad thing if it improves
> patch quality over time?
True dat. That's what I would do. :)
But I seem to need more sleep than Andrew does.
---
~Randy
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 20:53 ` 2.6.17-rc2-mm1 Greg KH
@ 2006-04-27 22:09 ` Michal Piotrowski
0 siblings, 0 replies; 90+ messages in thread
From: Michal Piotrowski @ 2006-04-27 22:09 UTC (permalink / raw
To: Greg KH; +Cc: Andrew Morton, linux-kernel
On 27/04/06, Greg KH <gregkh@suse.de> wrote:
[snip]
> Ok, I've spent a bit of time trying to reproduce this and I can't. So
> I'm just going to drop it from the patch set, because as you point out,
> it's never going to go to mainline anyway, it was just a fun hack.
>
> Sorry for the noise,
>
> greg k-h
>
Thanks.
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 21:50 ` 2.6.17-rc2-mm1 Randy.Dunlap
@ 2006-04-27 22:16 ` Andrew Morton
0 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-27 22:16 UTC (permalink / raw
To: Randy.Dunlap; +Cc: gcoady.lk, ak, linux-kernel
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> On Fri, 28 Apr 2006 07:41:52 +1000 Grant Coady wrote:
>
> > On Thu, 27 Apr 2006 12:19:30 -0700, Andrew Morton <akpm@osdl.org> wrote:
> >
> > >I don't like dropping patches. Because then the thing needs to be fixed up
> > >and resent and remerged and re-reviewed and rejects need to re-fixed-up and
> > >this adds emailing overhead and 12-24 hour turnaround, etc. I very much
> > >prefer to hang onto the patch and get it fixed up. This means that I
> > >usually have to do the fixing-up.
> >
> > Perhaps dropping patches with obvious faults with some feedback
> > to submitter may reduce your workload ;) And is slowing down the
> > merge a little in these cases such a bad thing if it improves
> > patch quality over time?
>
> True dat. That's what I would do. :)
As I say - I prefer to keep moving in the forward direction. So if a patch
needs coding-style cleanups, warning fixes, bugfixes, etc it's usually
quicker to just fix the thing immediately rather than send it back, wait
and then redo everything. The submitter sees the fixes and hence will
Never Do That Again (right?)
None of this is a particular burden for me - it'd average an hour a day,
tops. My main reason for the big whine is that this defect rate indicates
that people just aren't being sufficiently careful in their work. If so
many silly trivial things are slipping through, then what does this tell us
about the big things, ie: runtime bugs?
> But I seem to need more sleep than Andrew does.
There's plenty of time for that in the grave.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 18:02 ` 2.6.17-rc2-mm1 Vivek Goyal
@ 2006-04-27 23:24 ` Greg KH
2006-04-28 14:40 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-28 16:07 ` 2.6.17-rc2-mm1 matthieu castet
1 sibling, 1 reply; 90+ messages in thread
From: Greg KH @ 2006-04-27 23:24 UTC (permalink / raw
To: Vivek Goyal; +Cc: Matthieu CASTET, linux-kernel
On Thu, Apr 27, 2006 at 02:02:27PM -0400, Vivek Goyal wrote:
> On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> > Hi Andrew,
> >
> > Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a ?crit?:
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > >
> >
> > 64 bit resources core changes in ioport.h break pnp sysfs interface.
> >
> > A patch like this is needed.
> >
> > Matthieu
> >
> > Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> >
> > --- 1/drivers/pnp/interface.c 2006-01-03 04:21:10.000000000 +0100
> > +++ 2/drivers/pnp/interface.c 2006-04-14 22:54:45.000000000 +0200
> > @@ -264,7 +264,7 @@
> > if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
> > pnp_printf(buffer," disabled\n");
> > else
> > - pnp_printf(buffer," 0x%lx-0x%lx\n",
> > + pnp_printf(buffer," 0x%llx-0x%llx\n",
> > pnp_port_start(dev, i),
> > pnp_port_end(dev, i));
>
> I think it would break on ppc64 as u64 is unsigned long. It should be
> explicitly typecasted to unsigned long long. Same is true for all the
> instances.
Does ppc64 use the PnP code?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 16:47 2.6.17-rc2-mm1 Martin Bligh
@ 2006-04-28 8:20 ` Andrew Morton
0 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-28 8:20 UTC (permalink / raw
To: Martin Bligh; +Cc: apw, linuxppc64-dev, linux-kernel
(I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
Martin Bligh <mbligh@google.com> wrote:
>
> Still crashes in LTP on x86_64:
> (introduced in previous release)
>
> http://test.kernel.org/abat/29674/debug/console.log
What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
be stuck in flush_tlb_others. One of these could be a consequence of the
other, or both could be a consequence of something else.
> Different panic on 2-way ppp64 blade, again during LTP.
>
> http://test.kernel.org/abat/29675/debug/console.log
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA
> Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
> NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
> REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
> MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
> DAR: C00001800056B0B0, DSISR: 0000000040010000
> TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
> GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
> GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
> GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
> GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
> GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
> GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
> GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
> GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
> NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
> LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> Call Trace:
> [C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
> [C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> [C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
> [C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
> [C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
> [C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
> [C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
> Instruction dump:
> 3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
> eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
> -- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
Well that's silly. kswapd died trying to wake up kprefetchd. That code's
bog-simple, so I'd assume something's gone wrong with a CPU scheduler data
structure. So if there's a common strand here, it's breakage of sched data
structures by mtest01. Let me see if I can provoke it here.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-04-28 8:20 ` Andrew Morton
0 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2006-04-28 8:20 UTC (permalink / raw
To: Martin Bligh; +Cc: linuxppc64-dev, linux-kernel
(I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
Martin Bligh <mbligh@google.com> wrote:
>
> Still crashes in LTP on x86_64:
> (introduced in previous release)
>
> http://test.kernel.org/abat/29674/debug/console.log
What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
be stuck in flush_tlb_others. One of these could be a consequence of the
other, or both could be a consequence of something else.
> Different panic on 2-way ppp64 blade, again during LTP.
>
> http://test.kernel.org/abat/29675/debug/console.log
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=128 NUMA
> Modules linked in: evdev joydev st sr_mod ipv6 usbcore sg dm_mod
> NIP: C000000000048F0C LR: C0000000000AF854 CTR: 800000000000A984
> REGS: c0000000074af560 TRAP: 0300 Not tainted (2.6.17-rc2-mm1-autokern1)
> MSR: 8000000000001032 <ME,IR,DR> CR: 24002024 XER: 00000010
> DAR: C00001800056B0B0, DSISR: 0000000040010000
> TASK = c000000007460800[84] 'kswapd0' THREAD: c0000000074ac000 CPU: 1
> GPR00: 8000000000001032 C0000000074AF7E0 C000000000691420 C0000000007586A8
> GPR04: 000000000000000F 0000000000000000 0000000000000000 0000000000000000
> GPR08: C0000000FE80AAD8 C00001800056B080 0000000000000001 C0000000007586A8
> GPR12: 0000000024002024 C00000000056B280 0000000000000020 0000000000000020
> GPR16: 0000000000000020 0000000000000000 0000000000000000 000000000000000F
> GPR20: C0000000074AF860 0000000000000000 C0000000FFFF3098 0000000000000001
> GPR24: C0000000074AFE00 C00000000059FCC0 0000000000000001 C0000000007586A8
> GPR28: C000000000545680 0000000000000022 C0000000005A4DA8 C00000000056B080
> NIP [C000000000048F0C] .try_to_wake_up+0x98/0x598
> LR [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> Call Trace:
> [C0000000074AF7E0] [C0000000005A4DA8] 0xc0000000005a4da8 (unreliable)
> [C0000000074AF8F0] [C0000000000AF854] .add_to_swapped_list+0x23c/0x264
> [C0000000074AF990] [C000000000098290] .remove_mapping+0x88/0x174
> [C0000000074AFA20] [C000000000099340] .shrink_zone+0xc74/0xf9c
> [C0000000074AFD30] [C00000000009A008] .kswapd+0x3e4/0x54c
> [C0000000074AFED0] [C0000000000705C8] .kthread+0x174/0x1c4
> [C0000000074AFF90] [C000000000024AB0] .kernel_thread+0x4c/0x68
> Instruction dump:
> 3a810080 7d2000a6 79208042 f9340000 78008000 7c010164 e97b0008 ebfe8008
> eb9e8000 812b0010 79294da4 7d29fa14 <e8090030> 7fbc0214 7fa3eb78 4841f615
> -- 0:conmux-control -- time-stamp -- Apr/27/06 5:10:48 --
Well that's silly. kswapd died trying to wake up kprefetchd. That code's
bog-simple, so I'd assume something's gone wrong with a CPU scheduler data
structure. So if there's a common strand here, it's breakage of sched data
structures by mtest01. Let me see if I can provoke it here.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 20:36 ` Martin Bligh
2006-04-27 19:56 ` Andi Kleen
@ 2006-04-28 14:03 ` Paulo Marques
2006-04-28 15:22 ` Jan Engelhardt
2006-05-01 21:20 ` Valerie Henson
1 sibling, 2 replies; 90+ messages in thread
From: Paulo Marques @ 2006-04-28 14:03 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, Randy.Dunlap, ak, linux-kernel
Martin Bligh wrote:
>>[...]
> I don't want to boot it, as that gets into security nightmares, but I
> should be able to provide something that does static testing.
Actually, booting might not be that bad using a virtual machine with qemu.
You can use a command like:
qemu -nographic -kernel <kernel_image> -append <command line> -initrd
<initrd file>
and then set up the <command line> to use the serial console, and the
initrd to something simple that just outputs "[SUCCESS]" and powers off.
You can then monitor the standard output of this process. If after a
minute (for instance) no "[SUCCESS]" appears on its standard output, it
didn't boot and you have the dmesg data to (hopefully) show why it
didn't boot.
If it outputs "[SUCCESS]", then it booted fine. You still can append the
dmesg output to the test report.
Of course, the kernel configuration must include support for serial
console and the initrd filesystem used, at least.
Well, just my 2 cents,
--
Paulo Marques - www.grupopie.com
Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 23:24 ` 2.6.17-rc2-mm1 Greg KH
@ 2006-04-28 14:40 ` Vivek Goyal
0 siblings, 0 replies; 90+ messages in thread
From: Vivek Goyal @ 2006-04-28 14:40 UTC (permalink / raw
To: Greg KH; +Cc: Matthieu CASTET, linux-kernel
On Thu, Apr 27, 2006 at 04:24:44PM -0700, Greg KH wrote:
> On Thu, Apr 27, 2006 at 02:02:27PM -0400, Vivek Goyal wrote:
> > On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> > > Hi Andrew,
> > >
> > > Le Thu, 27 Apr 2006 01:41:41 -0700, Andrew Morton a ?crit?:
> > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc2/2.6.17-rc2-mm1/
> > > >
> > >
> > > 64 bit resources core changes in ioport.h break pnp sysfs interface.
> > >
> > > A patch like this is needed.
> > >
> > > Matthieu
> > >
> > > Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
> > >
> > > --- 1/drivers/pnp/interface.c 2006-01-03 04:21:10.000000000 +0100
> > > +++ 2/drivers/pnp/interface.c 2006-04-14 22:54:45.000000000 +0200
> > > @@ -264,7 +264,7 @@
> > > if (pnp_port_flags(dev, i) & IORESOURCE_DISABLED)
> > > pnp_printf(buffer," disabled\n");
> > > else
> > > - pnp_printf(buffer," 0x%lx-0x%lx\n",
> > > + pnp_printf(buffer," 0x%llx-0x%llx\n",
> > > pnp_port_start(dev, i),
> > > pnp_port_end(dev, i));
> >
> > I think it would break on ppc64 as u64 is unsigned long. It should be
> > explicitly typecasted to unsigned long long. Same is true for all the
> > instances.
>
> Does ppc64 use the PnP code?
>
I had assumed it. Just now did a allmodconfig on ppc64 and came to know
there is no such option as CONFIG_PNP. Sorry for the noise.
Thanks
Vivek
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-28 14:03 ` Paulo Marques
@ 2006-04-28 15:22 ` Jan Engelhardt
2006-05-01 21:20 ` Valerie Henson
1 sibling, 0 replies; 90+ messages in thread
From: Jan Engelhardt @ 2006-04-28 15:22 UTC (permalink / raw
To: Paulo Marques; +Cc: Martin Bligh, Andrew Morton, Randy.Dunlap, ak, linux-kernel
>
> and then set up the <command line> to use the serial console, and the initrd to
> something simple that just outputs "[SUCCESS]" and powers off.
>
Let it run for 5 minutes or so, to catch silly things like jiffy wraparound
and bombs that go off a little later than kernel boot.
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-27 18:02 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-27 23:24 ` 2.6.17-rc2-mm1 Greg KH
@ 2006-04-28 16:07 ` matthieu castet
2006-04-28 18:05 ` 2.6.17-rc2-mm1 Vivek Goyal
1 sibling, 1 reply; 90+ messages in thread
From: matthieu castet @ 2006-04-28 16:07 UTC (permalink / raw
To: vgoyal; +Cc: linux-kernel
Vivek Goyal wrote:
> On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
>
>
> I think it would break on ppc64 as u64 is unsigned long. It should be
> explicitly typecasted to unsigned long long. Same is true for all the
> instances.
On 64 bits platform, unsigned long isn't the same as unsigned long long ?
Do you mean there will be a warning ?
But pnp_printf is a variadic fonction (with no attribute format printf),
so gcc can't check the arguments type.
Matthieu
PS : according to arch/ppc/Kconfig, ISA (so PNP that depend on ISA)
could be enable on PPC_PREP or PPC_CHRP [1]. But there are others 64
bits architecture like ia64 that have ACPI and use PNP.
[1]
Find out whether you have ISA slots on your motherboard. ISA is the
name of a bus system, i.e. the way the CPU talks to the other
stuff
inside your box. If you have an Apple machine, say N here;
if you
have an IBM RS/6000 or pSeries machine or a PReP machine, say
Y. If
you have an embedded board, consult your board documentation.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-27 21:22 ` Martin Bligh
@ 2006-04-28 17:30 ` Rafał J. Wysocki
0 siblings, 0 replies; 90+ messages in thread
From: Rafał J. Wysocki @ 2006-04-28 17:30 UTC (permalink / raw
To: Martin Bligh; +Cc: Andi Kleen, Andrew Morton, Randy.Dunlap, linux-kernel
Hi,
On Thursday 27 April 2006 23:22, Martin Bligh wrote:
> Andi Kleen wrote:
> > On Thursday 27 April 2006 23:00, Martin Bligh wrote:
> >
> >>>Some Unixes have a cstyle(1). Maybe there is a free variant of it
> >>>somewhere. But such a tool might put a lot of people on l-k out of job @)
> >>
> >>heh. we could do some basic stuff at least. run through lindent, and see
> >>if it changes ;-)
> >
> > Good luck weeding out the false positives from that.
>
> Yes, I was joking.
>
> >>Can't tell whether that was meant to be positive or negative feedback.
> >>All this would require is "email patch to test-thingy@test.kernel.org".
> >
> >
> > I meant it would be better if it happened automatically when the patch
> > is submitted through the normal channels.
>
> It would, and it pretty much does right now, in that we test -mm
> (OK, we don't run sparse, but that's easy to fix). What I was trying to
> do was take the burden off Andrew for handling the testing of every
> single patch, which means getting the developer to deal with it.
> Personally, I don't think "please email your patch in for automated
> testing" is too much to ask from them.
>
> It'd be easy to make the automated tester forward it to Andrew or
> whatever, if it passed the tests.
I think an automated tester would be a good tool for developers if it could
email the results back to them. At least I would be using it. :-)
And if you want to make developers use it, you can design it to generate
a unique tag for each patch successfully tested and ask the developers to
include these tags in the patch headers.
Greetings,
Rafael
--
dr Rafał J. Wysocki
Systemy i Sieci Komputerowe
+48 605 05 36 93
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-28 16:07 ` 2.6.17-rc2-mm1 matthieu castet
@ 2006-04-28 18:05 ` Vivek Goyal
0 siblings, 0 replies; 90+ messages in thread
From: Vivek Goyal @ 2006-04-28 18:05 UTC (permalink / raw
To: matthieu castet; +Cc: linux-kernel
On Fri, Apr 28, 2006 at 06:07:17PM +0200, matthieu castet wrote:
> Vivek Goyal wrote:
> >On Thu, Apr 27, 2006 at 05:47:25PM +0200, Matthieu CASTET wrote:
> >
> >
> >I think it would break on ppc64 as u64 is unsigned long. It should be
> >explicitly typecasted to unsigned long long. Same is true for all the
> >instances.
> On 64 bits platform, unsigned long isn't the same as unsigned long long ?
>
> Do you mean there will be a warning ?
Yes.
> But pnp_printf is a variadic fonction (with no attribute format printf),
> so gcc can't check the arguments type.
>
You are right. I did not notice that for pnp_printf(), attribute format
printf is not specified. So gcc won't do the type checking on format string
arguments.
( __attribute__ ((format (printf, 2, 3)));
Thanks
Vivek
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-04-28 8:20 ` 2.6.17-rc2-mm1 Andrew Morton
@ 2006-05-01 14:24 ` Martin J. Bligh
-1 siblings, 0 replies; 90+ messages in thread
From: Martin J. Bligh @ 2006-05-01 14:24 UTC (permalink / raw
To: Andrew Morton; +Cc: apw, linuxppc64-dev, linux-kernel, Andi Kleen
Andrew Morton wrote:
> (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
>
> Martin Bligh <mbligh@google.com> wrote:
>
>>Still crashes in LTP on x86_64:
>>(introduced in previous release)
>>
>>http://test.kernel.org/abat/29674/debug/console.log
>
>
> What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> be stuck in flush_tlb_others. One of these could be a consequence of the
> other, or both could be a consequence of something else.
OK, well the latest one seems cleaner, on -rc3-mm1.
http://test.kernel.org/abat/30007/debug/console.log
Just has the double fault, with no NMI watchdog timeouts. Not that
it means any more to me, but still ;-) mtest01 seems to be able to
reproduce this every time, but I don't have an appropriate box here
to diagnose it with (this was a 4x Opteron inside IBM), and it's
definitely something in -mm that's not in mainline.
M.
double fault: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
CPU 0
Modules linked in:
Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
RSP: 0000:0000000000000000 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
ffff8100db12c0d0)
Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
0000000000000000 ffffffff80485520
Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
<ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
<ffffffff8020bba6>{do_double_fault+115}
<ffffffff8020aa91>{double_fault+125}
<ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
-- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 14:24 ` Martin J. Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin J. Bligh @ 2006-05-01 14:24 UTC (permalink / raw
To: Andrew Morton; +Cc: linuxppc64-dev, Andi Kleen, linux-kernel
Andrew Morton wrote:
> (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
>
> Martin Bligh <mbligh@google.com> wrote:
>
>>Still crashes in LTP on x86_64:
>>(introduced in previous release)
>>
>>http://test.kernel.org/abat/29674/debug/console.log
>
>
> What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> be stuck in flush_tlb_others. One of these could be a consequence of the
> other, or both could be a consequence of something else.
OK, well the latest one seems cleaner, on -rc3-mm1.
http://test.kernel.org/abat/30007/debug/console.log
Just has the double fault, with no NMI watchdog timeouts. Not that
it means any more to me, but still ;-) mtest01 seems to be able to
reproduce this every time, but I don't have an appropriate box here
to diagnose it with (this was a 4x Opteron inside IBM), and it's
definitely something in -mm that's not in mainline.
M.
double fault: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
CPU 0
Modules linked in:
Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
RSP: 0000:0000000000000000 EFLAGS: 00010082
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
ffff8100db12c0d0)
Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
0000000000000000 ffffffff80485520
Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
<ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
<ffffffff8020bba6>{do_double_fault+115}
<ffffffff8020aa91>{double_fault+125}
<ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
-- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 14:24 ` 2.6.17-rc2-mm1 Martin J. Bligh
@ 2006-05-01 17:07 ` Andrew Morton
-1 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2006-05-01 17:07 UTC (permalink / raw
To: Martin J. Bligh; +Cc: apw, linuxppc64-dev, linux-kernel, ak
"Martin J. Bligh" <mbligh@google.com> wrote:
>
> Andrew Morton wrote:
> > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> >
> > Martin Bligh <mbligh@google.com> wrote:
> >
> >>Still crashes in LTP on x86_64:
> >>(introduced in previous release)
> >>
> >>http://test.kernel.org/abat/29674/debug/console.log
> >
> >
> > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > be stuck in flush_tlb_others. One of these could be a consequence of the
> > other, or both could be a consequence of something else.
>
> OK, well the latest one seems cleaner, on -rc3-mm1.
> http://test.kernel.org/abat/30007/debug/console.log
>
> Just has the double fault, with no NMI watchdog timeouts. Not that
> it means any more to me, but still ;-) mtest01 seems to be able to
> reproduce this every time, but I don't have an appropriate box here
> to diagnose it with (this was a 4x Opteron inside IBM), and it's
> definitely something in -mm that's not in mainline.
>
> M.
>
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
> Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 17:07 ` Andrew Morton
0 siblings, 0 replies; 90+ messages in thread
From: Andrew Morton @ 2006-05-01 17:07 UTC (permalink / raw
To: Martin J. Bligh; +Cc: linuxppc64-dev, ak, linux-kernel
"Martin J. Bligh" <mbligh@google.com> wrote:
>
> Andrew Morton wrote:
> > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> >
> > Martin Bligh <mbligh@google.com> wrote:
> >
> >>Still crashes in LTP on x86_64:
> >>(introduced in previous release)
> >>
> >>http://test.kernel.org/abat/29674/debug/console.log
> >
> >
> > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > be stuck in flush_tlb_others. One of these could be a consequence of the
> > other, or both could be a consequence of something else.
>
> OK, well the latest one seems cleaner, on -rc3-mm1.
> http://test.kernel.org/abat/30007/debug/console.log
>
> Just has the double fault, with no NMI watchdog timeouts. Not that
> it means any more to me, but still ;-) mtest01 seems to be able to
> reproduce this every time, but I don't have an appropriate box here
> to diagnose it with (this was a 4x Opteron inside IBM), and it's
> definitely something in -mm that's not in mainline.
>
> M.
>
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
> Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:07 ` 2.6.17-rc2-mm1 Andrew Morton
@ 2006-05-01 17:14 ` Martin Bligh
-1 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:14 UTC (permalink / raw
To: Andrew Morton; +Cc: apw, linuxppc64-dev, linux-kernel, ak
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>>
>>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
>>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
>> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
OK, is there anything we could run this with that'd dump more info?
(eg debug patches or something). There's bugger all of use that I
can see in that stack (and why does __sched_text_start come up anyway,
is that an x86_64-ism ?). I suppose if we're really desperate, we can
play chop search, but that's very boring to try to do remotely ...
It's a couple-of-year-old 4x newisys box.
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 17:14 ` Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:14 UTC (permalink / raw
To: Andrew Morton; +Cc: linuxppc64-dev, ak, linux-kernel
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>>
>>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
>>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
>> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
OK, is there anything we could run this with that'd dump more info?
(eg debug patches or something). There's bugger all of use that I
can see in that stack (and why does __sched_text_start come up anyway,
is that an x86_64-ism ?). I suppose if we're really desperate, we can
play chop search, but that's very boring to try to do remotely ...
It's a couple-of-year-old 4x newisys box.
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:07 ` 2.6.17-rc2-mm1 Andrew Morton
@ 2006-05-01 17:19 ` Badari Pulavarty
-1 siblings, 0 replies; 90+ messages in thread
From: Badari Pulavarty @ 2006-05-01 17:19 UTC (permalink / raw
To: Andrew Morton; +Cc: Martin J. Bligh, apw, linuxppc64-dev, lkml, ak
On Mon, 2006-05-01 at 10:07 -0700, Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
> >
> > Andrew Morton wrote:
> > > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> > >
> > > Martin Bligh <mbligh@google.com> wrote:
> > >
> > >>Still crashes in LTP on x86_64:
> > >>(introduced in previous release)
> > >>
> > >>http://test.kernel.org/abat/29674/debug/console.log
> > >
> > >
> > > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > > be stuck in flush_tlb_others. One of these could be a consequence of the
> > > other, or both could be a consequence of something else.
> >
> > OK, well the latest one seems cleaner, on -rc3-mm1.
> > http://test.kernel.org/abat/30007/debug/console.log
> >
> > Just has the double fault, with no NMI watchdog timeouts. Not that
> > it means any more to me, but still ;-) mtest01 seems to be able to
> > reproduce this every time, but I don't have an appropriate box here
> > to diagnose it with (this was a 4x Opteron inside IBM), and it's
> > definitely something in -mm that's not in mainline.
> >
> > M.
> >
> > double fault: 0000 [1] SMP
> > last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> > CPU 0
> > Modules linked in:
> > Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> > RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> > RSP: 0000:0000000000000000 EFLAGS: 00010082
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> > RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> > RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> > FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> > CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> > CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> > Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> > ffff8100db12c0d0)
> > Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> > 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> > 0000000000000000 ffffffff80485520
> > Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> > <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> > <ffffffff8020bba6>{do_double_fault+115}
> > <ffffffff8020aa91>{double_fault+125}
> > <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> >
> > Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> > RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> > -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
I ran mtest01 multiple times with various options on my 4-way AMD64 box.
So far couldn't reproduce the problem (2.6.17-rc3-mm1).
Are there any special config or test options you are testing with ?
Thanks,
Badari
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 17:19 ` Badari Pulavarty
0 siblings, 0 replies; 90+ messages in thread
From: Badari Pulavarty @ 2006-05-01 17:19 UTC (permalink / raw
To: Andrew Morton; +Cc: linuxppc64-dev, ak, lkml, Martin J. Bligh
On Mon, 2006-05-01 at 10:07 -0700, Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
> >
> > Andrew Morton wrote:
> > > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> > >
> > > Martin Bligh <mbligh@google.com> wrote:
> > >
> > >>Still crashes in LTP on x86_64:
> > >>(introduced in previous release)
> > >>
> > >>http://test.kernel.org/abat/29674/debug/console.log
> > >
> > >
> > > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > > be stuck in flush_tlb_others. One of these could be a consequence of the
> > > other, or both could be a consequence of something else.
> >
> > OK, well the latest one seems cleaner, on -rc3-mm1.
> > http://test.kernel.org/abat/30007/debug/console.log
> >
> > Just has the double fault, with no NMI watchdog timeouts. Not that
> > it means any more to me, but still ;-) mtest01 seems to be able to
> > reproduce this every time, but I don't have an appropriate box here
> > to diagnose it with (this was a 4x Opteron inside IBM), and it's
> > definitely something in -mm that's not in mainline.
> >
> > M.
> >
> > double fault: 0000 [1] SMP
> > last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> > CPU 0
> > Modules linked in:
> > Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> > RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> > RSP: 0000:0000000000000000 EFLAGS: 00010082
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> > RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> > RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> > FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> > CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> > CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> > Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> > ffff8100db12c0d0)
> > Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> > 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> > 0000000000000000 ffffffff80485520
> > Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> > <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> > <ffffffff8020bba6>{do_double_fault+115}
> > <ffffffff8020aa91>{double_fault+125}
> > <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> >
> > Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> > RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> > -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
I ran mtest01 multiple times with various options on my 4-way AMD64 box.
So far couldn't reproduce the problem (2.6.17-rc3-mm1).
Are there any special config or test options you are testing with ?
Thanks,
Badari
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:19 ` 2.6.17-rc2-mm1 Badari Pulavarty
@ 2006-05-01 17:26 ` Martin Bligh
-1 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:26 UTC (permalink / raw
To: Badari Pulavarty; +Cc: Andrew Morton, apw, linuxppc64-dev, lkml, ak
> I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>
> Are there any special config or test options you are testing with ?
Config is here:
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
It's just doing "runalltests", I think.
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 17:26 ` Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:26 UTC (permalink / raw
To: Badari Pulavarty; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
> I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>
> Are there any special config or test options you are testing with ?
Config is here:
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
It's just doing "runalltests", I think.
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:07 ` 2.6.17-rc2-mm1 Andrew Morton
` (2 preceding siblings ...)
(?)
@ 2006-05-01 17:32 ` Martin Bligh
2006-05-02 20:20 ` 2.6.17-rc2-mm1 Martin Bligh
-1 siblings, 1 reply; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:32 UTC (permalink / raw
To: Andrew Morton; +Cc: apw, linux-kernel, ak
Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
>
>>Andrew Morton wrote:
>>
>>>(I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
>>>
>>>Martin Bligh <mbligh@google.com> wrote:
>>>
>>>
>>>>Still crashes in LTP on x86_64:
>>>>(introduced in previous release)
>>>>
>>>>http://test.kernel.org/abat/29674/debug/console.log
>>>
>>>
>>>What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
>>>hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
>>>be stuck in flush_tlb_others. One of these could be a consequence of the
>>>other, or both could be a consequence of something else.
>>
>>OK, well the latest one seems cleaner, on -rc3-mm1.
>>http://test.kernel.org/abat/30007/debug/console.log
>>
>>Just has the double fault, with no NMI watchdog timeouts. Not that
>>it means any more to me, but still ;-) mtest01 seems to be able to
>>reproduce this every time, but I don't have an appropriate box here
>>to diagnose it with (this was a 4x Opteron inside IBM), and it's
>>definitely something in -mm that's not in mainline.
Andy, any chance you could do another run on elm3b6 of ltp with:
2.6.17-rc3 + http://test.kernel.org/patches/2.6.17-rc3-mm1-64
Which is:
x86_64-add-compat_sys_vmsplice-and-use-it-in.patch
i386-x86-64-fix-acpi-disabled-lapic-handling.patch
x86_64-mm-defconfig-update.patch
x86_64-mm-phys-apicid.patch
x86_64-mm-memset-always-inline.patch
x86_64-mm-amd-core-cpuid.patch
x86_64-mm-amd-cpuid4.patch
x86_64-mm-alternatives.patch
x86_64-mm-pci-dma-cleanup.patch
x86_64-mm-ia32-unistd-cleanup.patch
x86_64-mm-large-bzimage.patch
x86_64-mm-topology-comment.patch
x86_64-mm-agp-select.patch
x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
x86_64-mm-new-compat-ptrace.patch
x86_64-mm-disable-agp-resource-check.patch
x86_64-mm-avoid-irq0-ioapic-pin-collision.patch
x86_64-mm-gart-direct-call.patch
x86_64-mm-new-northbridge.patch
x86_64-mm-iommu-warning.patch
x86_64-mm-serialize-assign_irq_vector-use-of-static-variables.patch
x86_64-mm-simplify-ioapic_register_intr.patch
x86_64-mm-i386-apic-overwrite.patch
x86_64-mm-i386-up-generic-arch.patch
x86_64-mm-iommu-enodev.patch
x86_64-mm-fix-die_lock-nesting.patch
x86_64-mm-add-nmi_exit-to-die_nmi.patch
x86_64-mm-compat-printk.patch
x86_64-mm-hotadd-reserve-fix-fix-fix.patch
x86_64-mm-compat-printk-fix.patch
x86_64-mm-new-northbridge-fix.patch
x86-64-calgary-iommu-introduce-iommu_detected.patch
x86-64-calgary-iommu-calgary-specific-bits.patch
x86-64-calgary-iommu-hook-it-in.patch
x86-64-check-for-valid-dma-data-direction-in-the-dma-api.patch
Thanks,
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:26 ` 2.6.17-rc2-mm1 Martin Bligh
@ 2006-05-01 17:55 ` Badari Pulavarty
-1 siblings, 0 replies; 90+ messages in thread
From: Badari Pulavarty @ 2006-05-01 17:55 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, apw, linuxppc64-dev, lkml, ak
On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
> > I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> > So far couldn't reproduce the problem (2.6.17-rc3-mm1).
> >
> > Are there any special config or test options you are testing with ?
>
> Config is here:
>
> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>
> It's just doing "runalltests", I think.
FWIW, I tried your config file on my 4-way AMD64 (melody) box
and ran latest "mtest01" fine.
I am now trying runalltests. I guess, its time to bi-sect :(
Thanks,
Badari
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 17:55 ` Badari Pulavarty
0 siblings, 0 replies; 90+ messages in thread
From: Badari Pulavarty @ 2006-05-01 17:55 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
> > I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> > So far couldn't reproduce the problem (2.6.17-rc3-mm1).
> >
> > Are there any special config or test options you are testing with ?
>
> Config is here:
>
> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>
> It's just doing "runalltests", I think.
FWIW, I tried your config file on my 4-way AMD64 (melody) box
and ran latest "mtest01" fine.
I am now trying runalltests. I guess, its time to bi-sect :(
Thanks,
Badari
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:55 ` 2.6.17-rc2-mm1 Badari Pulavarty
@ 2006-05-01 17:57 ` Martin Bligh
-1 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:57 UTC (permalink / raw
To: Badari Pulavarty; +Cc: Andrew Morton, apw, linuxppc64-dev, lkml, ak
Badari Pulavarty wrote:
> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>
>>>I ran mtest01 multiple times with various options on my 4-way AMD64 box.
>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>
>>>Are there any special config or test options you are testing with ?
>>
>>Config is here:
>>
>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>
>>It's just doing "runalltests", I think.
>
>
> FWIW, I tried your config file on my 4-way AMD64 (melody) box
> and ran latest "mtest01" fine.
>
> I am now trying runalltests. I guess, its time to bi-sect :(
There was a panic on PPC64 during LTP too, but it seems to have gone
away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
http://test.kernel.org/abat/29675/debug/console.log
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 17:57 ` Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 17:57 UTC (permalink / raw
To: Badari Pulavarty; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
Badari Pulavarty wrote:
> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>
>>>I ran mtest01 multiple times with various options on my 4-way AMD64 box.
>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>
>>>Are there any special config or test options you are testing with ?
>>
>>Config is here:
>>
>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>
>>It's just doing "runalltests", I think.
>
>
> FWIW, I tried your config file on my 4-way AMD64 (melody) box
> and ran latest "mtest01" fine.
>
> I am now trying runalltests. I guess, its time to bi-sect :(
There was a panic on PPC64 during LTP too, but it seems to have gone
away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
http://test.kernel.org/abat/29675/debug/console.log
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:57 ` 2.6.17-rc2-mm1 Martin Bligh
@ 2006-05-01 18:32 ` Andy Whitcroft
-1 siblings, 0 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-01 18:32 UTC (permalink / raw
To: Martin Bligh; +Cc: Badari Pulavarty, Andrew Morton, linuxppc64-dev, lkml, ak
Martin Bligh wrote:
> Badari Pulavarty wrote:
>
>> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>
>>>> I ran mtest01 multiple times with various options on my 4-way AMD64
>>>> box.
>>>> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>
>>>> Are there any special config or test options you are testing with ?
>>>
>>>
>>> Config is here:
>>>
>>> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>
>>> It's just doing "runalltests", I think.
>>
>>
>>
>> FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>> latest "mtest01" fine.
>>
>> I am now trying runalltests. I guess, its time to bi-sect :(
>
>
> There was a panic on PPC64 during LTP too, but it seems to have gone
> away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>
> http://test.kernel.org/abat/29675/debug/console.log
I think its more intermittant than gone. I've got another machine which
runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 18:32 ` Andy Whitcroft
0 siblings, 0 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-01 18:32 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, linuxppc64-dev, Badari Pulavarty, lkml, ak
Martin Bligh wrote:
> Badari Pulavarty wrote:
>
>> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>
>>>> I ran mtest01 multiple times with various options on my 4-way AMD64
>>>> box.
>>>> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>
>>>> Are there any special config or test options you are testing with ?
>>>
>>>
>>> Config is here:
>>>
>>> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>
>>> It's just doing "runalltests", I think.
>>
>>
>>
>> FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>> latest "mtest01" fine.
>>
>> I am now trying runalltests. I guess, its time to bi-sect :(
>
>
> There was a panic on PPC64 during LTP too, but it seems to have gone
> away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>
> http://test.kernel.org/abat/29675/debug/console.log
I think its more intermittant than gone. I've got another machine which
runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 14:24 ` 2.6.17-rc2-mm1 Martin J. Bligh
@ 2006-05-01 18:34 ` Andi Kleen
-1 siblings, 0 replies; 90+ messages in thread
From: Andi Kleen @ 2006-05-01 18:34 UTC (permalink / raw
To: Martin J. Bligh; +Cc: Andrew Morton, apw, linuxppc64-dev, linux-kernel
On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
That's really strange - i wonder why the backtracer can't find the original
stack. Should probably add some printk diagnosis here.
Can you send the output with this patch?
Index: linux/arch/x86_64/kernel/traps.c
===================================================================
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
HANDLE_STACK (stack < estack_end);
i += printk(" <EOE>");
stack = (unsigned long *) estack_end[-2];
+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
continue;
}
if (irqstack_end) {
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 18:34 ` Andi Kleen
0 siblings, 0 replies; 90+ messages in thread
From: Andi Kleen @ 2006-05-01 18:34 UTC (permalink / raw
To: Martin J. Bligh; +Cc: Andrew Morton, linuxppc64-dev, linux-kernel
On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
That's really strange - i wonder why the backtracer can't find the original
stack. Should probably add some printk diagnosis here.
Can you send the output with this patch?
Index: linux/arch/x86_64/kernel/traps.c
===================================================================
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
HANDLE_STACK (stack < estack_end);
i += printk(" <EOE>");
stack = (unsigned long *) estack_end[-2];
+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
continue;
}
if (irqstack_end) {
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-04-28 14:03 ` Paulo Marques
2006-04-28 15:22 ` Jan Engelhardt
@ 2006-05-01 21:20 ` Valerie Henson
2006-05-01 21:35 ` Martin Bligh
1 sibling, 1 reply; 90+ messages in thread
From: Valerie Henson @ 2006-05-01 21:20 UTC (permalink / raw
To: Paulo Marques; +Cc: Martin Bligh, Andrew Morton, Randy.Dunlap, ak, linux-kernel
On Fri, Apr 28, 2006 at 03:03:23PM +0100, Paulo Marques wrote:
> Martin Bligh wrote:
> >>[...]
> >I don't want to boot it, as that gets into security nightmares, but I
> >should be able to provide something that does static testing.
>
> Actually, booting might not be that bad using a virtual machine with qemu.
Honestly, the security nightmare begins with the compile. A patch to
the build system can result in arbitrarily insecure commands being run
during the compile - way easier than doing something that affects the
compiled kernel. A machine doing automatic compiles of untrusted
patches should be viewed as completely sacrificial from the beginning.
-VAL
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-05-01 21:20 ` Valerie Henson
@ 2006-05-01 21:35 ` Martin Bligh
2006-05-01 23:11 ` Valerie Henson
0 siblings, 1 reply; 90+ messages in thread
From: Martin Bligh @ 2006-05-01 21:35 UTC (permalink / raw
To: Valerie Henson
Cc: Paulo Marques, Andrew Morton, Randy.Dunlap, ak, linux-kernel
Valerie Henson wrote:
> On Fri, Apr 28, 2006 at 03:03:23PM +0100, Paulo Marques wrote:
>
>>Martin Bligh wrote:
>>
>>>>[...]
>>>
>>>I don't want to boot it, as that gets into security nightmares, but I
>>>should be able to provide something that does static testing.
>>
>>Actually, booting might not be that bad using a virtual machine with qemu.
>
>
> Honestly, the security nightmare begins with the compile. A patch to
> the build system can result in arbitrarily insecure commands being run
> during the compile - way easier than doing something that affects the
> compiled kernel. A machine doing automatic compiles of untrusted
> patches should be viewed as completely sacrificial from the beginning.
True - good point ... but it's easier to chroot jail. And I'm lazy ;-)
If anyone wants to make autotest (http://test.kernel.org/autotest)
support some sort of virtual boot via creating a UML instance or
something, that'd be great. But I won't hold my breath ;-)
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: checklist (Re: 2.6.17-rc2-mm1)
2006-05-01 21:35 ` Martin Bligh
@ 2006-05-01 23:11 ` Valerie Henson
0 siblings, 0 replies; 90+ messages in thread
From: Valerie Henson @ 2006-05-01 23:11 UTC (permalink / raw
To: Martin Bligh; +Cc: Paulo Marques, Andrew Morton, Randy.Dunlap, ak, linux-kernel
On Mon, May 01, 2006 at 02:35:05PM -0700, Martin Bligh wrote:
> Valerie Henson wrote:
> >
> >Honestly, the security nightmare begins with the compile. A patch to
> >the build system can result in arbitrarily insecure commands being run
> >during the compile - way easier than doing something that affects the
> >compiled kernel. A machine doing automatic compiles of untrusted
> >patches should be viewed as completely sacrificial from the beginning.
>
> True - good point ... but it's easier to chroot jail. And I'm lazy ;-)
> If anyone wants to make autotest (http://test.kernel.org/autotest)
> support some sort of virtual boot via creating a UML instance or
> something, that'd be great. But I won't hold my breath ;-)
I think you should do this, security issues be darned. Just wanted to
point out where the real concern was. And thanks in advance!
-VAL
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 18:32 ` 2.6.17-rc2-mm1 Andy Whitcroft
@ 2006-05-01 23:29 ` Badari Pulavarty
-1 siblings, 0 replies; 90+ messages in thread
From: Badari Pulavarty @ 2006-05-01 23:29 UTC (permalink / raw
To: Andy Whitcroft; +Cc: Martin Bligh, Andrew Morton, linuxppc64-dev, lkml, ak
Andy Whitcroft wrote:
>Martin Bligh wrote:
>
>>Badari Pulavarty wrote:
>>
>>>On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>>
>>>>>I ran mtest01 multiple times with various options on my 4-way AMD64
>>>>>box.
>>>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>>
>>>>>Are there any special config or test options you are testing with ?
>>>>>
>>>>
>>>>Config is here:
>>>>
>>>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>>
>>>>It's just doing "runalltests", I think.
>>>>
>>>
>>>
>>>FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>>>latest "mtest01" fine.
>>>
>>>I am now trying runalltests. I guess, its time to bi-sect :(
>>>
>>
>>There was a panic on PPC64 during LTP too, but it seems to have gone
>>away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>>
>>http://test.kernel.org/abat/29675/debug/console.log
>>
>
>I think its more intermittant than gone. I've got another machine which
>runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
>
I ran whole LTP with 2.6.17-rc3-mm1 on my (2-way P710) Power box and
didn't see any crashes. I also ran LTP on AMD64 box without any crashes.
Thanks,
Badari
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-01 23:29 ` Badari Pulavarty
0 siblings, 0 replies; 90+ messages in thread
From: Badari Pulavarty @ 2006-05-01 23:29 UTC (permalink / raw
To: Andy Whitcroft; +Cc: Andrew Morton, linuxppc64-dev, lkml, Martin Bligh, ak
Andy Whitcroft wrote:
>Martin Bligh wrote:
>
>>Badari Pulavarty wrote:
>>
>>>On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>>
>>>>>I ran mtest01 multiple times with various options on my 4-way AMD64
>>>>>box.
>>>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>>
>>>>>Are there any special config or test options you are testing with ?
>>>>>
>>>>
>>>>Config is here:
>>>>
>>>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>>
>>>>It's just doing "runalltests", I think.
>>>>
>>>
>>>
>>>FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>>>latest "mtest01" fine.
>>>
>>>I am now trying runalltests. I guess, its time to bi-sect :(
>>>
>>
>>There was a panic on PPC64 during LTP too, but it seems to have gone
>>away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>>
>>http://test.kernel.org/abat/29675/debug/console.log
>>
>
>I think its more intermittant than gone. I've got another machine which
>runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
>
I ran whole LTP with 2.6.17-rc3-mm1 on my (2-way P710) Power box and
didn't see any crashes. I also ran LTP on AMD64 box without any crashes.
Thanks,
Badari
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 18:34 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-05-02 13:20 ` Andy Whitcroft
-1 siblings, 0 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-02 13:20 UTC (permalink / raw
To: Andi Kleen; +Cc: Martin J. Bligh, Andrew Morton, linuxppc64-dev, linux-kernel
Andi Kleen wrote:
> On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
>
>
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
>
> That's really strange - i wonder why the backtracer can't find the original
> stack. Should probably add some printk diagnosis here.
>
> Can you send the output with this patch?
Submitted, they should show up in teh matrix forthwith. Will drop you
the output when done.
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-02 13:20 ` Andy Whitcroft
0 siblings, 0 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-02 13:20 UTC (permalink / raw
To: Andi Kleen; +Cc: Andrew Morton, linuxppc64-dev, linux-kernel, Martin J. Bligh
Andi Kleen wrote:
> On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
>
>
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
>
> That's really strange - i wonder why the backtracer can't find the original
> stack. Should probably add some printk diagnosis here.
>
> Can you send the output with this patch?
Submitted, they should show up in teh matrix forthwith. Will drop you
the output when done.
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 18:34 ` 2.6.17-rc2-mm1 Andi Kleen
(?)
(?)
@ 2006-05-02 20:00 ` Martin Bligh
2006-05-02 20:09 ` 2.6.17-rc2-mm1 Andi Kleen
-1 siblings, 1 reply; 90+ messages in thread
From: Martin Bligh @ 2006-05-02 20:00 UTC (permalink / raw
To: Andi Kleen; +Cc: Andrew Morton, apw, linux-kernel
> That's really strange - i wonder why the backtracer can't find the original
> stack. Should probably add some printk diagnosis here.
>
> Can you send the output with this patch?
>
> Index: linux/arch/x86_64/kernel/traps.c
> ===================================================================
> --- linux.orig/arch/x86_64/kernel/traps.c
> +++ linux/arch/x86_64/kernel/traps.c
> @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
> HANDLE_STACK (stack < estack_end);
> i += printk(" <EOE>");
> stack = (unsigned long *) estack_end[-2];
> + printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
> continue;
> }
> if (irqstack_end) {
Thanks for running this Andy:
http://test.kernel.org/abat/30183/debug/console.log
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-02 20:00 ` 2.6.17-rc2-mm1 Martin Bligh
@ 2006-05-02 20:09 ` Andi Kleen
2006-05-03 6:47 ` 2.6.17-rc2-mm1 Jan Beulich
0 siblings, 1 reply; 90+ messages in thread
From: Andi Kleen @ 2006-05-02 20:09 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, apw, linux-kernel, jbeulich
On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
> > Index: linux/arch/x86_64/kernel/traps.c
> > ===================================================================
> > --- linux.orig/arch/x86_64/kernel/traps.c
> > +++ linux/arch/x86_64/kernel/traps.c
> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
> > HANDLE_STACK (stack < estack_end);
> > i += printk(" <EOE>");
> > stack = (unsigned long *) estack_end[-2];
> > + printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
> > continue;
> > }
> > if (irqstack_end) {
>
> Thanks for running this Andy:
>
> http://test.kernel.org/abat/30183/debug/console.log
<EOE>new stack 0 (0 0 0 10082 10)
Hmm weird. There isn't anything resembling an exception frame at the top of the
stack. No idea how this could happen.
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-01 17:32 ` 2.6.17-rc2-mm1 Martin Bligh
@ 2006-05-02 20:20 ` Martin Bligh
0 siblings, 0 replies; 90+ messages in thread
From: Martin Bligh @ 2006-05-02 20:20 UTC (permalink / raw
To: Martin Bligh; +Cc: Andrew Morton, apw, linux-kernel, ak
> Andy, any chance you could do another run on elm3b6 of ltp with:
> 2.6.17-rc3 + http://test.kernel.org/patches/2.6.17-rc3-mm1-64
>
> Which is:
>
> x86_64-add-compat_sys_vmsplice-and-use-it-in.patch
> i386-x86-64-fix-acpi-disabled-lapic-handling.patch
> x86_64-mm-defconfig-update.patch
> x86_64-mm-phys-apicid.patch
> x86_64-mm-memset-always-inline.patch
> x86_64-mm-amd-core-cpuid.patch
> x86_64-mm-amd-cpuid4.patch
> x86_64-mm-alternatives.patch
> x86_64-mm-pci-dma-cleanup.patch
> x86_64-mm-ia32-unistd-cleanup.patch
> x86_64-mm-large-bzimage.patch
> x86_64-mm-topology-comment.patch
> x86_64-mm-agp-select.patch
> x86_64-mm-iommu_gart_bitmap-search-to-cross-next_bit.patch
> x86_64-mm-new-compat-ptrace.patch
> x86_64-mm-disable-agp-resource-check.patch
> x86_64-mm-avoid-irq0-ioapic-pin-collision.patch
> x86_64-mm-gart-direct-call.patch
> x86_64-mm-new-northbridge.patch
> x86_64-mm-iommu-warning.patch
> x86_64-mm-serialize-assign_irq_vector-use-of-static-variables.patch
> x86_64-mm-simplify-ioapic_register_intr.patch
> x86_64-mm-i386-apic-overwrite.patch
> x86_64-mm-i386-up-generic-arch.patch
> x86_64-mm-iommu-enodev.patch
> x86_64-mm-fix-die_lock-nesting.patch
> x86_64-mm-add-nmi_exit-to-die_nmi.patch
> x86_64-mm-compat-printk.patch
> x86_64-mm-hotadd-reserve-fix-fix-fix.patch
> x86_64-mm-compat-printk-fix.patch
> x86_64-mm-new-northbridge-fix.patch
> x86-64-calgary-iommu-introduce-iommu_detected.patch
> x86-64-calgary-iommu-calgary-specific-bits.patch
> x86-64-calgary-iommu-hook-it-in.patch
> x86-64-check-for-valid-dma-data-direction-in-the-dma-api.patch
It worked fine with this lot. Hmmm. I guess that makes sense, if it's
the same issue that intermittently occurs on ppc64 (and perhaps it's
easier to diagnose there, since we get better stack tracing).
M.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-03 5:37 Chuck Ebbert
0 siblings, 0 replies; 90+ messages in thread
From: Chuck Ebbert @ 2006-05-03 5:37 UTC (permalink / raw
To: Martin Bligh; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <445641EF.70601@google.com>
On Mon, 01 May 2006 10:14:23 -0700, Martin Bligh wrote:
> >>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> >>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> >> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
> >
> >
> > I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
>
> OK, is there anything we could run this with that'd dump more info?
> (eg debug patches or something). There's bugger all of use that I
> can see in that stack (and why does __sched_text_start come up anyway,
> is that an x86_64-ism ?).
Look at your System.map and see if another symbol has the same address
as __sched_text_start.
I have:
ffffffff8042eb30 T io_schedule_timeout
ffffffff8042eb30 T __sched_text_start
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-02 20:09 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-05-03 6:47 ` Jan Beulich
2006-05-03 6:49 ` 2.6.17-rc2-mm1 Andi Kleen
0 siblings, 1 reply; 90+ messages in thread
From: Jan Beulich @ 2006-05-03 6:47 UTC (permalink / raw
To: Andi Kleen; +Cc: Martin Bligh, Andrew Morton, apw, linux-kernel
>>> Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>
>> > Index: linux/arch/x86_64/kernel/traps.c
>> > ===================================================================
>> > --- linux.orig/arch/x86_64/kernel/traps.c
>> > +++ linux/arch/x86_64/kernel/traps.c
>> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>> > HANDLE_STACK (stack < estack_end);
>> > i += printk(" <EOE>");
>> > stack = (unsigned long *) estack_end[-2];
>> > + printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
estack_end[-2], estack_end[-3], estack_end[-4]);
>> > continue;
>> > }
>> > if (irqstack_end) {
>>
>> Thanks for running this Andy:
>>
>> http://test.kernel.org/abat/30183/debug/console.log
>
>
><EOE>new stack 0 (0 0 0 10082 10)
Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>Hmm weird. There isn't anything resembling an exception frame at the top of the
>stack. No idea how this could happen.
... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the conditions
in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
crossing a page boundary, and hence potentially faulting. Similarly, obtaining an entirely bad stack pointer anywhere in
that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
having recovery attached.
Jan
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 6:47 ` 2.6.17-rc2-mm1 Jan Beulich
@ 2006-05-03 6:49 ` Andi Kleen
2006-05-03 7:08 ` 2.6.17-rc2-mm1 Jan Beulich
2006-05-03 19:26 ` 2.6.17-rc2-mm1 Andy Whitcroft
0 siblings, 2 replies; 90+ messages in thread
From: Andi Kleen @ 2006-05-03 6:49 UTC (permalink / raw
To: Jan Beulich; +Cc: Martin Bligh, Andrew Morton, apw, linux-kernel
On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
> >>> Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
> >On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
> >
> >> > Index: linux/arch/x86_64/kernel/traps.c
> >> > ===================================================================
> >> > --- linux.orig/arch/x86_64/kernel/traps.c
> >> > +++ linux/arch/x86_64/kernel/traps.c
> >> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
> >> > HANDLE_STACK (stack < estack_end);
> >> > i += printk(" <EOE>");
> >> > stack = (unsigned long *) estack_end[-2];
> >> > + printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
> estack_end[-2], estack_end[-3], estack_end[-4]);
> >> > continue;
> >> > }
> >> > if (irqstack_end) {
> >>
> >> Thanks for running this Andy:
> >>
> >> http://test.kernel.org/abat/30183/debug/console.log
> >
> >
> ><EOE>new stack 0 (0 0 0 10082 10)
>
> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
Hmm, right.
> >Hmm weird. There isn't anything resembling an exception frame at the top of the
> >stack. No idea how this could happen.
>
> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
Any can you add that please and check?
Also worst case one could dump last branch pointers. AMD unfortunately only has four,
on Intel with 16 it's easier.
I can provide a patch for that if needed.
> This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the conditions
> in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
> crossing a page boundary, and hence potentially faulting.
Yes it probably should check for that.
> Similarly, obtaining an entirely bad stack pointer anywhere in
> that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
> having recovery attached.
That can cause recursive exceptions. I'm a bit paranoid with that.
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 6:49 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-05-03 7:08 ` Jan Beulich
2006-05-03 7:38 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-03 19:26 ` 2.6.17-rc2-mm1 Andy Whitcroft
1 sibling, 1 reply; 90+ messages in thread
From: Jan Beulich @ 2006-05-03 7:08 UTC (permalink / raw
To: Andi Kleen; +Cc: Martin Bligh, Andrew Morton, apw, linux-kernel
>> ><EOE>new stack 0 (0 0 0 10082 10)
>>
>> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>
>Hmm, right.
>
>> >Hmm weird. There isn't anything resembling an exception frame at the top of the
>> >stack. No idea how this could happen.
>>
>> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
item
>> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>
>Any can you add that please and check?
???
>Also worst case one could dump last branch pointers. AMD unfortunately only has four,
>on Intel with 16 it's easier.
Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on
both.
>I can provide a patch for that if needed.
>
>> This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the
conditions
>> in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
>> crossing a page boundary, and hence potentially faulting.
>
>Yes it probably should check for that.
>
>> Similarly, obtaining an entirely bad stack pointer anywhere in
>> that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
>> having recovery attached.
>
>That can cause recursive exceptions. I'm a bit paranoid with that.
Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.
Jan
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 7:08 ` 2.6.17-rc2-mm1 Jan Beulich
@ 2006-05-03 7:38 ` Andi Kleen
2006-05-03 8:12 ` 2.6.17-rc2-mm1 Andy Whitcroft
0 siblings, 1 reply; 90+ messages in thread
From: Andi Kleen @ 2006-05-03 7:38 UTC (permalink / raw
To: Jan Beulich; +Cc: Martin Bligh, Andrew Morton, apw, linux-kernel
On Wednesday 03 May 2006 09:08, Jan Beulich wrote:
> >> ><EOE>new stack 0 (0 0 0 10082 10)
> >>
> >> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
> >
> >Hmm, right.
> >
> >> >Hmm weird. There isn't anything resembling an exception frame at the top of the
> >> >stack. No idea how this could happen.
> >>
> >> ... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
> item
> >> (or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
> >
> >Any can you add that please and check?
> ???
Sorry I meant to write Andy but left out the d :-( - he did the testing
on the machine that showed the problem.
>
>
> >Also worst case one could dump last branch pointers. AMD unfortunately only has four,
> >on Intel with 16 it's easier.
>
> Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on
> both.
i usually just saved them as first thing in the exception entry point.
> >That can cause recursive exceptions. I'm a bit paranoid with that.
>
> Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.
Hmm point.
-Andi
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 7:38 ` 2.6.17-rc2-mm1 Andi Kleen
@ 2006-05-03 8:12 ` Andy Whitcroft
2006-05-03 8:25 ` 2.6.17-rc2-mm1 Jan Beulich
0 siblings, 1 reply; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-03 8:12 UTC (permalink / raw
To: Andi Kleen; +Cc: Jan Beulich, Martin Bligh, Andrew Morton, linux-kernel
Andi Kleen wrote:
> On Wednesday 03 May 2006 09:08, Jan Beulich wrote:
>
>>>>><EOE>new stack 0 (0 0 0 10082 10)
>>>>
>>>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>>>
>>>Hmm, right.
>>>
>>>
>>>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>>>stack. No idea how this could happen.
>>>>
>>>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed
>>
>>item
>>
>>>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>>>
>>>Any can you add that please and check?
>>
>>???
>
>
> Sorry I meant to write Andy but left out the d :-( - he did the testing
> on the machine that showed the problem.
Heh, happy to do the testing. Just to make sure I am doing the right
thing, you want an entire stack frame dropped out in the case that
SS/RSP are 0; so we get the RIP.
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 8:12 ` 2.6.17-rc2-mm1 Andy Whitcroft
@ 2006-05-03 8:25 ` Jan Beulich
0 siblings, 0 replies; 90+ messages in thread
From: Jan Beulich @ 2006-05-03 8:25 UTC (permalink / raw
To: Andy Whitcroft, Andi Kleen; +Cc: Martin Bligh, Andrew Morton, linux-kernel
>Heh, happy to do the testing. Just to make sure I am doing the right
>thing, you want an entire stack frame dropped out in the case that
>SS/RSP are 0; so we get the RIP.
Just decrement the indices in the previous printk() by one each, i.e. ranging from -1 to -5.
Jan
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 6:49 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-03 7:08 ` 2.6.17-rc2-mm1 Jan Beulich
@ 2006-05-03 19:26 ` Andy Whitcroft
2006-05-04 7:40 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-04 16:28 ` 2.6.17-rc2-mm1 Andy Whitcroft
1 sibling, 2 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-03 19:26 UTC (permalink / raw
To: Andi Kleen; +Cc: Jan Beulich, Martin Bligh, Andrew Morton, linux-kernel
Andi Kleen wrote:
> On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
>
>>>>>Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>>>
>>>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>>>
>>>
>>>>>Index: linux/arch/x86_64/kernel/traps.c
>>>>>===================================================================
>>>>>--- linux.orig/arch/x86_64/kernel/traps.c
>>>>>+++ linux/arch/x86_64/kernel/traps.c
>>>>>@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>>>>> HANDLE_STACK (stack < estack_end);
>>>>> i += printk(" <EOE>");
>>>>> stack = (unsigned long *) estack_end[-2];
>>>>>+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
>>
>>estack_end[-2], estack_end[-3], estack_end[-4]);
>>
>>>>> continue;
>>>>> }
>>>>> if (irqstack_end) {
>>>>
>>>>Thanks for running this Andy:
>>>>
>>>>http://test.kernel.org/abat/30183/debug/console.log
>>>
>>>
>>><EOE>new stack 0 (0 0 0 10082 10)
>>
>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>
>
> Hmm, right.
>
>
>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>stack. No idea how this could happen.
>>
>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>
>
> Any can you add that please and check?
Ok. Just got some results (in full at the end of the message). Seems
that this is indeed a stack frame:
new stack 0 (0 0 10046 10 ffffffff8047c8e8)
And if my reading of the System.map is right, this is _just_ in schedule.
ffffffff8047c17e T sha_init
ffffffff8047c1a8 T __sched_text_start
ffffffff8047c1a8 T schedule
ffffffff8047c8ed T thread_return
ffffffff8047c9be T wait_for_completion
ffffffff8047caa8 T wait_for_completion_timeout
By the looks of it that would make it here, at the call __switch_to?
Which of course makes loads of sense _if_ the loaded stack pointer was
crap say 0.
#define switch_to(prev,next,last) \
asm volatile(SAVE_CONTEXT \
"movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP
*/ \
"movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore
RSP */ \
"call __switch_to\n\t" \
".globl thread_return\n" \
"thread_return:\n\t"
I'll go shove some debug in there and see what pops out.
-apw
double fault: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
CPU 0
Modules linked in:
Pid: 228, comm: kswapd0 Tainted: G M 2.6.17-rc3-mm1-autokern1 #1
RIP: 0010:[<ffffffff8047c8e8>] <ffffffff8047c8e8>{__sched_text_start+1856}
RSP: 0000:0000000000000000 EFLAGS: 00010046
RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff805d9438
RDX: ffff8100e3d4a090 RSI: ffffffff805d9438 RDI: ffff8100e3d4a090
RBP: ffffffff805d9438 R08: 0000000000000001 R09: ffff8101001c9da8
R10: 0000000000000002 R11: 000000000000004d R12: ffffffff805013c0
R13: ffff8100013dc8c0 R14: ffff810008003620 R15: 000002a75ef255cc
FS: 0000000000000000(0000) GS:ffffffff805fa000(0000) knlGS:00000000f7e0b460
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: fffffffffffffff8 CR3: 000000006b004000 CR4: 00000000000006e0
Process kswapd0 (pid: 228, threadinfo ffff8101001c8000, task
ffff8100e3d4a090)
Stack: ffffffff80579e20 ffff8100e3d4a090 0000000000000001 ffffffff80579f58
0000000000000000 ffffffff80579e78 ffffffff8020b0e3 ffffffff80579f58
0000000000000000 ffffffff80485520
Call Trace: <#DF> <ffffffff8020b0e3>{show_registers+140}
<ffffffff8020b388>{__die+159} <ffffffff8020b3fd>{die+50}
<ffffffff8020bbd9>{do_double_fault+115}
<ffffffff8020aa91>{double_fault+125}
<ffffffff8047c8e8>{__sched_text_start+1856} <EOE>new stack 0 (0 0
10046 10 ffffffff8047c8e8)
Code: e8 1c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
RIP <ffffffff8047c8e8>{__sched_text_start+1856} RSP <0000000000000000>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
@ 2006-05-04 6:22 Chuck Ebbert
0 siblings, 0 replies; 90+ messages in thread
From: Chuck Ebbert @ 2006-05-04 6:22 UTC (permalink / raw
To: Andy Whitcroft
Cc: Andi Kleen, Andrew Morton, Jan Beulich, linux-kernel,
Martin Bligh
In-Reply-To: <445903DD.6090408@shadowen.org>
On Wed, 03 May 2006 20:26:21 +0100, Andy Whitcroft wrote:
> <ffffffff8047c8e8>{__sched_text_start+1856} <EOE>new stack 0 (0 0
> 10046 10 ffffffff8047c8e8)
Wow. The extra debug patch yields... exactly the same address that's
already being printed.
The real problem is that the stack-dump code prints the wrong symbol
name here. I don't see any easy way to fix it other than to put some
filler at __sched_text_start so the first sched function has a unique
address.
--
Chuck
"Penguins don't come from next door, they come from the Antarctic!"
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 19:26 ` 2.6.17-rc2-mm1 Andy Whitcroft
@ 2006-05-04 7:40 ` Andy Whitcroft
2006-05-04 16:28 ` 2.6.17-rc2-mm1 Andy Whitcroft
1 sibling, 0 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-04 7:40 UTC (permalink / raw
To: Andy Whitcroft
Cc: Andi Kleen, Jan Beulich, Martin Bligh, Andrew Morton,
linux-kernel
Andy Whitcroft wrote:
> Andi Kleen wrote:
>
>>On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
>>
>>
>>>>>>Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>>>>
>>>>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>>>>
>>>>
>>>>
>>>>>>Index: linux/arch/x86_64/kernel/traps.c
>>>>>>===================================================================
>>>>>>--- linux.orig/arch/x86_64/kernel/traps.c
>>>>>>+++ linux/arch/x86_64/kernel/traps.c
>>>>>>@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>>>>>> HANDLE_STACK (stack < estack_end);
>>>>>> i += printk(" <EOE>");
>>>>>> stack = (unsigned long *) estack_end[-2];
>>>>>>+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
>>>
>>>estack_end[-2], estack_end[-3], estack_end[-4]);
>>>
>>>
>>>>>> continue;
>>>>>> }
>>>>>> if (irqstack_end) {
>>>>>
>>>>>Thanks for running this Andy:
>>>>>
>>>>>http://test.kernel.org/abat/30183/debug/console.log
>>>>
>>>>
>>>><EOE>new stack 0 (0 0 0 10082 10)
>>>
>>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>>
>>
>>Hmm, right.
>>
>>
>>
>>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>>stack. No idea how this could happen.
>>>
>>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
>>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>>
>>
>>Any can you add that please and check?
>
>
> Ok. Just got some results (in full at the end of the message). Seems
> that this is indeed a stack frame:
>
> new stack 0 (0 0 10046 10 ffffffff8047c8e8)
>
> And if my reading of the System.map is right, this is _just_ in schedule.
>
> ffffffff8047c17e T sha_init
> ffffffff8047c1a8 T __sched_text_start
> ffffffff8047c1a8 T schedule
> ffffffff8047c8ed T thread_return
> ffffffff8047c9be T wait_for_completion
> ffffffff8047caa8 T wait_for_completion_timeout
>
> By the looks of it that would make it here, at the call __switch_to?
> Which of course makes loads of sense _if_ the loaded stack pointer was
> crap say 0.
A quick patch to check for a 0 rsp triggers, so will try and find out
what the new process is.
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.17-rc2-mm1
2006-05-03 19:26 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-04 7:40 ` 2.6.17-rc2-mm1 Andy Whitcroft
@ 2006-05-04 16:28 ` Andy Whitcroft
1 sibling, 0 replies; 90+ messages in thread
From: Andy Whitcroft @ 2006-05-04 16:28 UTC (permalink / raw
To: Andy Whitcroft
Cc: Andi Kleen, Jan Beulich, Martin Bligh, Andrew Morton,
linux-kernel
Andy Whitcroft wrote:
> Andi Kleen wrote:
>
>>On Wednesday 03 May 2006 08:47, Jan Beulich wrote:
>>
>>
>>>>>>Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>>>>
>>>>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>>>>
>>>>
>>>>
>>>>>>Index: linux/arch/x86_64/kernel/traps.c
>>>>>>===================================================================
>>>>>>--- linux.orig/arch/x86_64/kernel/traps.c
>>>>>>+++ linux/arch/x86_64/kernel/traps.c
>>>>>>@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>>>>>> HANDLE_STACK (stack < estack_end);
>>>>>> i += printk(" <EOE>");
>>>>>> stack = (unsigned long *) estack_end[-2];
>>>>>>+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
>>>
>>>estack_end[-2], estack_end[-3], estack_end[-4]);
>>>
>>>
>>>>>> continue;
>>>>>> }
>>>>>> if (irqstack_end) {
>>>>>
>>>>>Thanks for running this Andy:
>>>>>
>>>>>http://test.kernel.org/abat/30183/debug/console.log
>>>>
>>>>
>>>><EOE>new stack 0 (0 0 0 10082 10)
>>>
>>>Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>>
>>
>>Hmm, right.
>>
>>
>>
>>>>Hmm weird. There isn't anything resembling an exception frame at the top of the
>>>>stack. No idea how this could happen.
>>>
>>>... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
>>>(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.
>>
>>
>>Any can you add that please and check?
>
>
> Ok. Just got some results (in full at the end of the message). Seems
> that this is indeed a stack frame:
>
> new stack 0 (0 0 10046 10 ffffffff8047c8e8)
>
> And if my reading of the System.map is right, this is _just_ in schedule.
>
> ffffffff8047c17e T sha_init
> ffffffff8047c1a8 T __sched_text_start
> ffffffff8047c1a8 T schedule
> ffffffff8047c8ed T thread_return
> ffffffff8047c9be T wait_for_completion
> ffffffff8047caa8 T wait_for_completion_timeout
>
> By the looks of it that would make it here, at the call __switch_to?
> Which of course makes loads of sense _if_ the loaded stack pointer was
> crap say 0.
>
> #define switch_to(prev,next,last) \
> asm volatile(SAVE_CONTEXT \
> "movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP
> */ \
> "movq %P[threadrsp](%[next]),%%rsp\n\t" /* restore
> RSP */ \
> "call __switch_to\n\t" \
> ".globl thread_return\n" \
> "thread_return:\n\t"
>
> I'll go shove some debug in there and see what pops out.
Ok. I've been playing with this some. Basically when we pick up the
new process to schedule it has a 0 rsp. Dumping out the comm and flags
both reveal 0's throughout. I tried another run poisoning the flags
field when freeing a task but the flags remain 0.
Anyone got any good ideas for patches to blame?
-apw
^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2006-05-04 16:29 UTC | newest]
Thread overview: 90+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:16 ` 2.6.17-rc2-mm1 Andi Kleen
2006-04-27 19:19 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 19:26 ` 2.6.17-rc2-mm1 Andi Kleen
2006-04-27 19:44 ` checklist (Re: 2.6.17-rc2-mm1) Randy.Dunlap
2006-04-27 20:11 ` Andrew Morton
2006-04-27 20:17 ` Randy.Dunlap
2006-04-27 20:36 ` Martin Bligh
2006-04-27 19:56 ` Andi Kleen
2006-04-27 21:00 ` Martin Bligh
2006-04-27 20:11 ` Andi Kleen
2006-04-27 21:22 ` Martin Bligh
2006-04-28 17:30 ` Rafał J. Wysocki
2006-04-27 21:00 ` Christoph Hellwig
2006-04-28 14:03 ` Paulo Marques
2006-04-28 15:22 ` Jan Engelhardt
2006-05-01 21:20 ` Valerie Henson
2006-05-01 21:35 ` Martin Bligh
2006-05-01 23:11 ` Valerie Henson
2006-04-27 20:52 ` Jan Dittmer
2006-04-27 21:01 ` Randy.Dunlap
2006-04-27 21:41 ` 2.6.17-rc2-mm1 Grant Coady
2006-04-27 21:50 ` 2.6.17-rc2-mm1 Randy.Dunlap
2006-04-27 22:16 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:27 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 13:07 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:28 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 15:32 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 20:53 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 22:09 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:26 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 15:43 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:01 ` 2.6.17-rc2-mm1: ACPI_DOCK=n, HOTPLUG_PCI_ACPI=y compile error Adrian Bunk
2006-04-27 15:47 ` 2.6.17-rc2-mm1 Matthieu CASTET
2006-04-27 18:02 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-27 23:24 ` 2.6.17-rc2-mm1 Greg KH
2006-04-28 14:40 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-28 16:07 ` 2.6.17-rc2-mm1 matthieu castet
2006-04-28 18:05 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-27 17:57 ` [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y Adrian Bunk
2006-04-27 18:17 ` Andrew Morton
2006-04-27 20:15 ` Mauro Carvalho Chehab
2006-04-27 18:00 ` [-mm patch] fs/nfs/inode.c: make nfs_follow_referral() Adrian Bunk
2006-04-27 18:03 ` [-mm patch] mm/vmscan.c: make shrink_all_zones() static Adrian Bunk
2006-04-27 18:52 ` Rafael J. Wysocki
2006-04-27 20:33 ` [-mm patch] fs/gfs2/: possible cleanups Adrian Bunk
-- strict thread matches above, loose matches on Subject: below --
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 16:47 2.6.17-rc2-mm1 Martin Bligh
2006-04-28 8:20 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-28 8:20 ` 2.6.17-rc2-mm1 Andrew Morton
2006-05-01 14:24 ` 2.6.17-rc2-mm1 Martin J. Bligh
2006-05-01 14:24 ` 2.6.17-rc2-mm1 Martin J. Bligh
2006-05-01 17:07 ` 2.6.17-rc2-mm1 Andrew Morton
2006-05-01 17:07 ` 2.6.17-rc2-mm1 Andrew Morton
2006-05-01 17:14 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 17:14 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 17:19 ` 2.6.17-rc2-mm1 Badari Pulavarty
2006-05-01 17:19 ` 2.6.17-rc2-mm1 Badari Pulavarty
2006-05-01 17:26 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 17:26 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 17:55 ` 2.6.17-rc2-mm1 Badari Pulavarty
2006-05-01 17:55 ` 2.6.17-rc2-mm1 Badari Pulavarty
2006-05-01 17:57 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 17:57 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 18:32 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-01 18:32 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-01 23:29 ` 2.6.17-rc2-mm1 Badari Pulavarty
2006-05-01 23:29 ` 2.6.17-rc2-mm1 Badari Pulavarty
2006-05-01 17:32 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-02 20:20 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-01 18:34 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-01 18:34 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-02 13:20 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-02 13:20 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-02 20:00 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-02 20:09 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-03 6:47 ` 2.6.17-rc2-mm1 Jan Beulich
2006-05-03 6:49 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-03 7:08 ` 2.6.17-rc2-mm1 Jan Beulich
2006-05-03 7:38 ` 2.6.17-rc2-mm1 Andi Kleen
2006-05-03 8:12 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-03 8:25 ` 2.6.17-rc2-mm1 Jan Beulich
2006-05-03 19:26 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-04 7:40 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-05-04 16:28 ` 2.6.17-rc2-mm1 Andy Whitcroft
2006-04-27 16:50 2.6.17-rc2-mm1 Martin Bligh
2006-04-27 16:54 2.6.17-rc2-mm1 Martin Bligh
2006-04-27 16:54 ` 2.6.17-rc2-mm1 Martin Bligh
2006-05-03 5:37 2.6.17-rc2-mm1 Chuck Ebbert
2006-05-04 6:22 2.6.17-rc2-mm1 Chuck Ebbert
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.