* 2.6.17-mm2 @ 2006-06-24 13:19 Andrew Morton 2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki ` (14 more replies) 0 siblings, 15 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-24 13:19 UTC (permalink / raw) To: linux-kernel ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ - The locking validator patches have all been dropped - Ingo is redoing the patch series. - The arch-secific parts of the generic IRQ rework have been dropped, so it's a do-nothing patch series at present. If we can verify that it indeed does nothing then we might be able to squeak it into 2.6.18 for powerpc to merge against. - The kgdb patches have been tempdropped. Partly to make merging of other things easier, partly because someone broke it. - The various little -mm-only debugging patches have been temporarily dropped, to make followon patching easier. 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-mm1: origin.patch git-agpgart.patch git-cifs.patch git-dvb.patch git-gfs2.patch git-ia64.patch git-infiniband.patch git-input.patch git-jfs.patch git-kbuild.patch git-klibc.patch git-hdrinstall2.patch git-libata-all.patch git-mtd.patch git-netdev-all.patch git-ocfs2.patch git-pcmcia.patch git-s390.patch git-scsi-target.patch git-supertrak.patch git-watchdog.patch git-xfs.patch git-cryptodev.patch git trees -ehci-works-again-on-nvidia-controllers-with-2gb-ram.patch -uml-fix-wall_to_monotonic-initialization.patch -sparc-build-breakage.patch -ntfs-critical-bug-fix-affects-mips-and-possibly-others.patch -selinux-add-hooks-for-key-subsystem.patch -keys-fix-race-between-two-instantiators-of-a-key.patch -suspend_console-warning-fix.patch -myri10ge-build-fix.patch -for_each_possible_cpu-xfs.patch -revert-powernow-k8-crash-workaround.patch -git-acpi-fixup.patch -git-acpi-ia64-build-fix.patch -reapply-powernow-k8-crash-workaround.patch -ati-agp-build-fix.patch -create-sys-hypervisor-when-needed.patch -gregkh-driver-kobject_add-make-people-pay-attention-to-errors.patch -gregkh-driver-stable-abi-docs.patch -gregkh-driver-cciss-device-symlink.patch -gregkh-driver-driver-core-bus-device-event-delay.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 -gregkh-driver-driver-core-class_device_add-needs-error-checks.patch -gregkh-driver-driver-core-config_debug_pm-covers-drivers-base-power-too.patch -gregkh-driver-platform_bus-learns-about-modalias.patch -gregkh-driver-driver-core-remove-exports.patch -gregkh-driver-driver-core-allow-sysdev_class-have-attributes.patch -gregkh-driver-driver-core-fix-platform_device_add-to-use-device_add.patch -gregkh-driver-remove-duplication-from-documentation-power-devices_txt.patch -gregkh-driver-driver-core-pm_debug-device-suspend-messages-become-informative.patch -gregkh-driver-firmware_class-s-semaphores-mutexes.patch -gregkh-driver-make_class_name-kobj.patch -gregkh-driver-device-class.patch -gregkh-driver-driver-core-add-generic-subsystem-link-to-all-devices.patch -gregkh-driver-device-symlinks-for-classes.patch -gregkh-driver-driver-core-make-dev_info-and-friends-print-the-bus-name-if-there-is-no-driver.patch -gregkh-driver-driver-model-add-isa-bus.patch -saa7134-card-lifeview3000-ntsc.patch -gregkh-i2c-hwmon-lm83-add-lm82-support.patch -gregkh-i2c-hwmon-w83627ehf-add-voltages.patch -gregkh-i2c-hwmon-w83627ehf-add-alarms.patch -gregkh-i2c-hwmon-smsc47m192-new-driver.patch -gregkh-i2c-hwmon-f71805f-no-global-resource.patch -gregkh-i2c-hwmon-sysfs-interface-individual-alarm-files.patch -gregkh-i2c-i2c-piix4-add-ati-smbus-support.patch -gregkh-i2c-rtc-m41t00-driver-cleanup.patch -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 -gregkh-i2c-i2c-Kconfig-suggest-N-for-rare-devices.patch -gregkh-i2c-i2c-opencores-new-driver.patch -gregkh-i2c-hwmon-sysfs-interface-update-1.patch -gregkh-i2c-hwmon-sysfs-interface-update-2.patch -gregkh-i2c-hwmon-hdaps-typo.patch -gregkh-i2c-hwmon-maintenance-update.patch -gregkh-i2c-hwmon-w83792d-pwm-set-fix.patch -gregkh-i2c-hwmon-w83792d-add-data-lock.patch -gregkh-i2c-hwmon-abituguru-new-driver.patch -gregkh-i2c-hwmon-abituguru-fixes.patch -gregkh-i2c-hwmon-abituguru-nofans-detect-fix.patch -gregkh-i2c-i2c-opencores-cleanup.patch -gregkh-i2c-i2c-mark-data-const-for-write-block.patch -gregkh-i2c-i2c-scx200_acb-use-PCI-IO-resource-when-appropriate.patch -gregkh-i2c-i2c-scx200_acb-mark-scx200_acb_probe-init.patch -gregkh-i2c-i2c-scx200_acb-documentation-update.patch -gregkh-i2c-i2c-i801-01-fix-block-transaction-poll-loops.patch -gregkh-i2c-i2c-i801-02-remove-force_addr-parameter.patch -gregkh-i2c-i2c-i801-03-remove-pci-function-check.patch -gregkh-i2c-i2c-i801-04-cleanups.patch -gregkh-i2c-i2c-i801-05-better-pci-subsystem-integration.patch -gregkh-i2c-i2c-i801-06-merge-setup-function.patch -gregkh-i2c-hwmon-kconfig-header-fix.patch -gregkh-i2c-hwmon-lm70-new-driver.patch -gregkh-i2c-hwmon-vid-add-core-and-conroe-support.patch -gregkh-i2c-i2c-i2c-controllers-go-into-right-place-on-sysfs.patch -gregkh-i2c-w1-added-default-generic-read-write-operations.patch -gregkh-i2c-w1-replace-dscore-and-ds_w1_bridge-with-ds2490-driver.patch -gregkh-i2c-w1-userspace-communication-protocol-over-connector.patch -gregkh-i2c-w1-move-w1-connector-definitions-into-linux-include-connector.h.patch -gregkh-i2c-w1-netlink-mark-netlink-group-1-as-unused.patch -gregkh-i2c-w1-make-w1-connector-notifications-depend-on-connector.patch -gregkh-i2c-w1-use-mutexes-instead-of-semaphores.patch -gregkh-i2c-w1-exports.patch -gregkh-i2c-w1-cleanups.patch -gregkh-i2c-w1-possible-cleanups.patch -gregkh-i2c-w1-fix-dependencies-of-w1_slave_ds2433_crc.patch -gregkh-i2c-drivers-w1-w1.c-fix-a-compile-error.patch -gregkh-i2c-w1-clean-up-w1_con-dependency.patch -gregkh-i2c-w1-warning-fix.patch -git-infiniband-fixup.patch -git-libata-all-fixup.patch -git-libata-all-data_xfer-fixes.patch -git-libata-all-data_xfer-fixes-fixes.patch -git-libata-pata_cs5535-is-bust.patch -gregkh-pci-pci-hotplug-tollhouse-hp-sgi-hotplug-driver-changes.patch -gregkh-pci-acpiphp-configure-_prt-v3.patch -gregkh-pci-acpiphp-hotplug-slot-hotplug.patch -gregkh-pci-acpiphp-host-and-p2p-hotplug.patch -gregkh-pci-acpiphp-turn-off-slot-power-at-error-case.patch -gregkh-pci-pci-hotplug-don-t-use-acpi_os_free.patch -gregkh-pci-pciehp-dont-call-pci_enable_dev.patch -gregkh-pci-acpi_pcihp-fix-programming-_hpp-values.patch -gregkh-pci-acpi_pcihp-remove-improper-error-message-about-oshp.patch -gregkh-pci-acpi_pcihp-add-support-for-_hpx.patch -gregkh-pci-pciehp-fix-programming-hotplug-parameters.patch -gregkh-pci-shpc-cleanup-shpc-register-access.patch -gregkh-pci-shpc-cleanup-shpc-logical-slot-register-access.patch -gregkh-pci-shpc-cleanup-shpc-logical-slot-register-bits-access.patch -gregkh-pci-shpc-fix-shpc-logical-slot-register-bits-access.patch -gregkh-pci-shpc-fix-shpc-contoller-serr-int-register-bits-access.patch -gregkh-pci-shpchp-mask-global-serr-and-intr-at-controller-release-time.patch -gregkh-pci-shpchp-create-shpchpd-at-controller-probe-time.patch -gregkh-pci-sgi-hotplug-incorrect-power-status.patch -gregkh-pci-pciehp-replace-pci_find_slot-with-pci_get_slot.patch -gregkh-pci-pciehp-add-missing-pci_dev_put.patch -gregkh-pci-pciehp-implement-get_address-callback.patch -gregkh-pci-shpchp-remove-unnecessary-hpc_ctlr_handle-check.patch -gregkh-pci-shpchp-cleanup-interrupt-handler.patch -gregkh-pci-shpchp-cleanup-shpc-commands.patch -gregkh-pci-shpchp-cleanup-interrupt-polling-timer.patch -gregkh-pci-shpchp-remove-unused-hpc_evelnt_lock.patch -gregkh-pci-shpchp-cleanup-improper-info-messages.patch -gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch -gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch -gregkh-pci-pci-add-pci_cap_id_vndr.patch -gregkh-pci-pci-msi-abstractions-and-support-for-altix.patch -gregkh-pci-pci-per-platform-ia64_-first-last-_device_vector-definitions.patch -gregkh-pci-pci-altix-msi-support.patch -gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch -gregkh-pci-pci-fix-to-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch -gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch -gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch -gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch -gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch -gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch -gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch -gregkh-pci-pci-move-various-pci-ids-to-header-file.patch -gregkh-pci-pci-amd-8131-msi-quirk-called-too-late-bus_flags-not-inherited.patch -gregkh-pci-pci-allow-msi-to-work-on-kexec-kernel.patch -gregkh-pci-pci-disable-msi-mode-in-pci_disable_device.patch -gregkh-pci-pci-cleanup-unused-variable-about-msi-driver.patch -gregkh-pci-pci-don-t-move-ioapics-below-pci-bridge.patch -gregkh-pci-pci-remove-unneeded-msi-code.patch -gregkh-pci-pci-clean-up-pci-documentation-to-be-more-specific.patch -gregkh-pci-pci-fix-race-with-pci_walk_bus-and-pci_destroy_dev.patch -gregkh-pci-pci-msi-k8t-neo2-fir-run-only-where-needed.patch -gregkh-pci-fix-pci_get_device-usage-in-mpc85xx.patch -gregkh-pci-pci-fix-memory-leak-in-mmconfig-error-path.patch -gregkh-pci-pci-bus-parity-status-sysfs-interface.patch -gregkh-pci-pci-fix-issues-with-extended-conf-space-when-mmconfig-disabled-because-of-e820.patch -gregkh-pci-pci-nvidia-quirk-to-make-aer-pci-e-extended-capability-visible.patch -gregkh-usb-usb-add-yealink-phones-to-the-hid_quirk_ignore-blacklist.patch -gregkh-usb-usb-cdc-acm-add-a-new-special-case-for-modems-with-buggy-firmware.patch -gregkh-usb-usb-usbnet-zaurus-mtu-fixup.patch -gregkh-usb-usb-added-support-for-asix-88178-chipset-usb-gigabit-ethernet-adaptor.patch -gregkh-usb-usb-convert-the-semaphores-in-the-sisusb-driver-to-mutexes.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-console-fix-disconnection-issues.patch -gregkh-usb-usb-macbook-pro-touchpad-support.patch -gregkh-usb-usb-usbcore-always-turn-on-hub-port-power.patch -gregkh-usb-usb-clean-out-an-unnecessary-null-check-from-ub.patch -gregkh-usb-usbatm-remove-pointless-inline.patch -gregkh-usb-usbatm-remove-no-longer-needed-include.patch -gregkh-usb-usb-phidget-interfacekit-make-inputs-pollable-and-new-device-support.patch -gregkh-usb-usb-shuttle_usbat-fix-handling-of-scatter-gather-buffers.patch -gregkh-usb-usb-shuttle_usbat-hardcode-detection-of-hp-cdrw-devices.patch -gregkh-usb-usb-shuttle_usbat-hardcode-flash-detection-for-now.patch -gregkh-usb-usb-usb-storage-alauda-fix-transport-info-mismerge.patch -gregkh-usb-usb-net2280-add-a-shutdown-routine.patch -gregkh-usb-usb-uhci-store-the-endpoint-type-in-the-qh-structure.patch -gregkh-usb-usb-uhci-fix-obscure-bug-in-enqueue.patch -gregkh-usb-usb-hid-hidbp-input-drivers-fix-various-usb-input-hid-input.c-bugs-that-make-apple-mighty-mouse-work-poorly.patch -gregkh-usb-usbhid-automatically-set-hid_quirk_noget-for-keyboards-and-mice.patch gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch -gregkh-usb-uhci-common-result-routine-for-control-bulk-interrupt.patch -gregkh-usb-uhci-remove-non-iso-tds-as-they-are-used.patch -gregkh-usb-uhci-move-code-for-cleaning-up-unlinked-urbs.patch -gregkh-usb-uhci-eliminate-the-td-removal-list.patch -gregkh-usb-uhci-reimplement-fsbr.patch -gregkh-usb-uhci-work-around-old-intel-bug.patch -gregkh-usb-usb-correct-the-usb-info-in-documentation-power-swsusp_txt.patch -gregkh-usb-usb-remove-4088-byte-limit-on-usbfs-control-urbs.patch -gregkh-usb-usb-allow-high-bandwidth-isochronous-packets-via-usbfs.patch -gregkh-usb-uhci-use-integer-sized-frame-numbers.patch -gregkh-usb-uhci-fix-race-in-iso-dequeuing.patch -gregkh-usb-uhci-store-the-period-in-the-queue-header.patch -gregkh-usb-uhci-remove-iso-tds-as-they-are-used.patch -gregkh-usb-fix-a-deadlock-in-usbtest.patch -gregkh-usb-usb_interrupt_msg.patch -gregkh-usb-usb-new-cp2101-device.patch -gregkh-usb-gadgetfs-fix-aio-interface-bugs.patch -gregkh-usb-gadgetfs-fix-memory-leaks.patch -gregkh-usb-usbtest-report-errors-in-iso-tests.patch -gregkh-usb-usb-io_edgeport-cleanup-to-unicode-handling.patch -gregkh-usb-usb-serial-encapsulate-schedule_work-remove-double-calling.patch -gregkh-usb-usb-improve-kconfig-comment-for-mct_u232.patch -gregkh-usb-usb-syntax-cleanup-for-pl2303.patch -gregkh-usb-usb-storage-get-rid-of-the-timer-during-urb-submission.patch -gregkh-usb-improved-tt-scheduling-for-ehci.patch -gregkh-usb-usb-rmmod-pl2303-after-28.patch -gregkh-usb-ub-atomic-add_disk.patch -gregkh-usb-ub-random-cleanups.patch -gregkh-usb-usb-more-pegasus-log-spamming-removed.patch -gregkh-usb-usb-print-message-when-device-is-rejected-due-to-insufficient-power.patch -gregkh-usb-usbcore-fix-broken-rndis-config-selection.patch -gregkh-usb-usbhid-remove-unneeded-blacklist-entries.patch -gregkh-usb-usb-ftdi_sio-add-support-for-yost-engineering-servocenter3.1.patch -gregkh-usb-driver-for-apple-cinema-display.patch -gregkh-usb-usb-whiteheat-fix-firmware-spurious-errors.patch -gregkh-usb-usb-add-sierra-wireless-mc5720-id-to-airprime.c.patch -gregkh-usb-usb-negative-index-in-drivers-usb-host-isp116x-hcd.c.patch -gregkh-usb-usb-cdc_ether-recognize-olympus-r1000.patch -gregkh-usb-usbcore-port-reset-for-composite-devices.patch -gregkh-usb-usb-hub-use-usb_reset_composite_device.patch -gregkh-usb-usb-storage-use-usb_reset_composite_device.patch -gregkh-usb-usbhid-use-usb_reset_composite_device.patch -gregkh-usb-usbcore-recovery-from-set-configuration-failure.patch -gregkh-usb-usb-drivers-usb-core-devio.c-dereferences-a-userspace-pointer.patch -gregkh-usb-usb-new-devices-for-the-option-driver.patch -gregkh-usb-usb-free-allocated-memory-on-io_edgeport-startup-memory-failure.patch -gregkh-usb-usb-ehci-on-non-au1200-build-fix.patch -gregkh-usb-usb-add-apple-macbook-product-ids-to-usbhid.patch -gregkh-usb-usb-storage-unusual_devs-entry-for-nikon-dsc-d70s.patch -gregkh-usb-uhci-various-updates.patch -gregkh-usb-uhci-remove-hc_inaccessible-flag.patch -gregkh-usb-uhci-improve-fsbr-off-timing.patch -gregkh-usb-airprime.c-add-kyocera-wireless-kpc650-passport-support.patch -gregkh-usb-usb-io_edgeport-touch-up.patch -gregkh-usb-usb-update-usbmon-fix-glued-lines.patch -gregkh-usb-usb-implement-error-event-in-usbmon.patch -gregkh-usb-usb-update-usbmontxt.patch -gregkh-usb-usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers.patch -gregkh-usb-usb-trivial-debug-message-correction-in-gadget-ether-driver.patch -gregkh-usb-usb-serial-clean-tty-fields-on-failed-device-open.patch -gregkh-usb-usb-gadget-serial-fix-a-deadlock-when-closing-the-serial-device.patch -gregkh-usb-usb-gadget-serial-do-not-save-restore-irq-flags-in-gs_close.patch -gregkh-usb-usb-gadget-allow-drivers-support-speeds-higher-than-full-speed.patch -gregkh-usb-usb-gadget-fix-compile-errors.patch -gregkh-usb-usb-gadget-update-pxa2xx_udc.c-driver-to-fully-support-ixp4xx-platform.patch -gregkh-usb-usbserial-fixes-wrong-return-values.patch -gregkh-usb-usb-unusual_devs-entry-for-nokia-n80.patch -gregkh-usb-usb-whitespace-removal-from-usb-gadget-ether.patch -gregkh-usb-usb-move-linux-usb_cdc.h-to-linux-usb-cdc.h.patch -gregkh-usb-usb-move-hardware-specific-linux-usb_-.h-to-linux-usb-.h.patch -gregkh-usb-usb-move-linux-usb_input.h-to-linux-usb-input.h.patch -gregkh-usb-usb-endpoint.patch -gregkh-usb-usb-endpoint-pass-struct-device.patch -gregkh-usb-usb-endpoint-mess.patch -gregkh-usb-usb-devio-class-to-device.patch -gregkh-usb-usb-class-device-to-device.patch -gregkh-usb-usb-dynamic-usb-class.patch -x86_64-mm-agp-select.patch -xfs-remove-dir-check-in-xfs_link.patch -xfs-use-container_of-in-vn_from_inode.patch -xfs-remove-unused-behaviour-lock.patch -zone-handle-unaligned-zone-boundaries.patch -page-migration-make-do_swap_page-redo-the-fault.patch -slab-extract-cache_free_alien-from-__cache_free.patch -pg_uncached-is-ia64-only.patch -slab-page-mapping-cleanup.patch -migration-remove-unnecessary-pageswapcache-checks.patch -wait_table-and-zonelist-initializing-for-memory-hotadd-change-name-of-wait_table_size.patch -wait_table-and-zonelist-initializing-for-memory-hotadd-change-to-meminit-for-build_zonelist.patch -wait_table-and-zonelist-initializing-for-memory-hotaddadd-return-code-for-init_current_empty_zone.patch -wait_table-and-zonelist-initializing-for-memory-hotadd-wait_table-initialization.patch -wait_table-and-zonelist-initializing-for-memory-hotadd-update-zonelists.patch -squash-duplicate-page_to_pfn-and-pfn_to_page.patch -support-for-panic-at-oom.patch -mm-fix-typos-in-comments-in-mm-oom_killc.patch -reserve-space-for-swap-label.patch -tightening-hugetlb-strict-accounting.patch -slab-cleanup-kmem_getpages.patch -slab-stop-using-list_for_each.patch -swsusp-rework-memory-shrinker-rev-2.patch -unify-pxm_to_node-and-node_to_pxm.patch -mm-introduce-remap_vmalloc_range.patch -change-gen_pool-allocator-to-not-touch-managed-memory.patch -radix-tree-direct-data.patch -radix-tree-small.patch -likely-cleanup-remove-unlikely-in-sys_mprotect.patch -slab-redzone-double-free-detection.patch -buglet-in-radix_tree_tag_set.patch -writeback-fix-range-handling.patch -page-migration-cleanup-rename-ignrefs-to-migration.patch -page-migration-cleanup-group-functions.patch -page-migration-cleanup-remove-useless-definitions.patch -page-migration-cleanup-drop-nr_refs-in-remove_references.patch -page-migration-cleanup-extract-try_to_unmap-from-migration-functions.patch -page-migration-cleanup-pass-mapping-to-migration-functions.patch -page-migration-cleanup-move-fallback-handling-into-special-function.patch -swapless-pm-add-r-w-migration-entries.patch -swapless-pm-add-r-w-migration-entries-fix.patch -swapless-page-migration-rip-out-swap-based-logic.patch -swapless-page-migration-modify-core-logic.patch -more-page-migration-do-not-inc-dec-rss-counters.patch -more-page-migration-use-migration-entries-for-file-pages.patch -page-migration-update-documentation.patch -slab-verify-pointers-before-free.patch -sparsemem-record-nid-during-memory-present.patch -mm-cleanup-swap-unused-warning.patch -add-page_mkwrite-vm_operations-method.patch -add-page_mkwrite-vm_operations-method-fix.patch -swapoff-atomic_inc_not_zero-on-mm_users.patch -remove-unused-o_flags-from-do_shmat.patch -fix-update_mmu_cache-in-fremapc.patch -fix-update_mmu_cache-in-fremapc-fix.patch -mm-slabc-fix-early-init-assumption.patch -initialise-total_memory-earlier.patch -update-vm_total_pages-at-memory-hotadd.patch -slab-kmalloc-kzalloc-comments-cleanup-and-fix.patch -kernel-doc-for-mm-filemapc.patch -delete-unused-definitions-of-kvaddr_to_nid.patch -printk-should-not-be-called-under-zone-lock.patch -page-migration-simplify-migrate_pages.patch -page-migration-handle-freeing-of-pages-in-migrate_pages.patch -page-migration-use-allocator-function-for-migrate_pages.patch -page-migration-support-moving-of-individual-pages.patch -page-migration-support-moving-of-individual-pages-x86_64-support.patch -page-migration-support-moving-of-individual-pages-x86-support.patch -lsm-add-task_setioprio-hook.patch -selinux-add-security-hooks-to-getsetaffinity.patch -selinux-add-security-hook-call-to-mediate-attach_task.patch -frv-__user-infrastructure.patch -frv-basic-__iomem-annotations.patch -frv-signal-annotations.patch -frv-sysctl-__user-annotations.patch -frv-binfmt_elf_fdpic-__user-annotations.patch -frv-misc-__user-annotations.patch -frv-misc-sparse-annotations.patch -frv-wrong-syscall.patch -ext2-xip-wont-build-without-mmu.patch -frv-initrd-is-grossly-broken-on-frv-never-built.patch -frv-null-noise-removal-in-frv-xchg.patch -frv-ieee1394-is-borken-on-frv.patch -frv-add-missing-qualifier-to-memcpy_fromio-prototype.patch -frv-trivial-cleanups-in-frv_ksymsc.patch -frv-clean-frv-unistdh.patch -au1550-1200-add-missing-psc-defines-make-oss-driver-use.patch -x86-cache-pollution-aware-__copy_from_user_ll.patch -arch-i386-kernel-apicc-make-modern_apic-static.patch -i386-apmc-optimization.patch -x86-dont-trigger-full-rebuild-via-config_mtrr.patch -fix-x86-microcode-driver-handling-of-multiple-matching.patch -i386-break-out-of-recursion-in-stackframe-walk.patch -dont-trigger-full-rebuild-via-config_x86_mce.patch -x86-call-eisa_set_level_irq-in-pcibios_lookup_irq.patch -x86-kernel-irq-balancer-fix.patch -x86-kernel-irq-balancer-fix-tidy.patch -i386-let-usermode-execute-the-enter.patch -fix-broken-vm86-interrupt-signal-handling.patch -x86-make-using_apic_timer-__read_mostly.patch -x86-cyrix-code-config_pci-fix--add-__initdata.patch -x86-make-i387-mxcsr_feature_mask-__read_mostly.patch -x86-make-acpi-errata-__read_mostly.patch -x86-constify-arch-i386-pci-irqc.patch -x86-use-proper-defines-for-i8259a-i-o.patch -i386-fix-get_segment_eip-with-vm86.patch -i386-dont-try-kprobes-for-v8086-mode.patch -i386-extra-checks-in-show_registers.patch -via-c7-cpu-flags.patch -x86-compile-fix-for-asm-i386-alternativesh.patch -remove-duplicate-symbol-exports-on-alpha.patch -remove-empty-node-at-boot-time.patch -swsusp-add-architecture-special-saveable-pages-support.patch -swsusp-i386-mark-special-saveable-unsaveable-pages.patch -swsusp-x86_64-mark-special-saveable-unsaveable-pages.patch -swsusp-take-lowmem-reserves-into-account.patch -kernel-power-snapshotc-cleanups.patch -swsusp-use-less-memory-during-resume.patch -dont-use-flush_tlb_all-in-suspend-time.patch -swsusp-documentation-updates.patch -move-do_suspend_lowlevel-to-correct-segment.patch -m68k-completely-initialize-hw_regs_t-in-ide_setup_ports.patch -m68k-atyfb_base-compile-fix-for-config_pci=n.patch -m68k-cleanup-unistdh.patch -m68k-remove-some-unused-definitions-in-zorroh.patch -m68k-use-c99-initializer.patch -m68k-print-correct-stack-trace.patch -m68k-restore-amikbd-compatibility-with-24.patch -m68k-extra-delay.patch -m68k-use-proper-defines-for-zone-initialization.patch -m68k-adjust-to-changed-hardirq_mask.patch -m68k-m68k-mac-via2-fixes-and-cleanups.patch -m68k-clean-up-uaccessh.patch -m68k-typo-fix.patch -m68k-trapsc-constraints.patch -m68k-windfarm-is-powerpc-only-dont-do-it-on-m68k-macs.patch -xtensa-remove-verify_area-macros.patch -xtensa-remove-verify_area-macros-fix.patch -s390_hypfs-filesystem.patch -fix-a-race-condition-between-i_mapping-and-iput.patch -add-a-sysfs-file-to-determine-if-a-kexec-kernel-is-loaded.patch -insert-identical-resources-above-existing-resources.patch -remove-steal_locks.patch -avoid-tasklist_lock-at-getrusage-for-multithreaded-case-too.patch -#writeback-fix-range-handling.patch -fix-dcache-race-during-umount.patch -prune_one_dentry-tweaks.patch -vgacon-make-vga_map_mem-take-size-remove-extra-use.patch -zlib_inflate-upgrade-library-code-to-a-recent-version.patch -zlib_inflate-upgrade-library-code-to-a-recent-version-fix.patch -initramfs-cpio-unpacking-fix.patch -fix-cdrom-being-confused-on-using-kdump.patch -read_mapping_page-for-address-space.patch -locks-dont-unnecessarily-fail-posix-lock-operations.patch -locks-dont-do-unnecessary-allocations.patch -locks-clean-up-locks_remove_posix.patch -vfs-add-lock-owner-argument-to-flush-operation.patch -fs-locksc-make-posix_locks_deadlock-static.patch -moduleh-updated-comments-with-a-new.patch -remove-config_parport_arc-drivers-parport-parport_arcc.patch -mmput-might-sleep.patch -fs-fat-miscc-unexport-fat_sync_bhs.patch -poll-cleanups-microoptimizations.patch -ptrace-document-the-locking-rules.patch -cleanup-default-value-of-sched_smt.patch -cleanup-default-value-of-syscall_debug.patch -cleanup-default-value-of-usb_isp116x_hcd-usb_sl811_hcd-and-usb_sl811_cs.patch -cleanup-default-value-of-ip_dccp_ackvec.patch -cleanup-default-value-of-dvb_cinergyt2_enable_rc_input_device.patch -dup-fd-error.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 -jbd-fix-bug-in-journal_commit_transaction-fix.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 -isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub-fix.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-counters-add-percpu_counter_exceeds.patch -percpu-counter-data-type-changes-to-suppport.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 -connector-exports.patch -config_net=n-build-fix.patch -remove-softlockup-from-invalidate_mapping_pages.patch -add-doc-submitchecklist.patch -kernel-sysc-doesnt-need-inith.patch -make-rcu-api-inaccessible-to-non-gpl-linux-kernel-modules.patch -doc-add-audit-acct-to-docbook.patch -sgi-ioc4-detect-io-card-variant.patch -two-additions-to-linux-documentation-ioctl-numbertxt.patch -list-introduce-list_replace-helper.patch -list-use-list_replace_init-instead-of-list_splice_init.patch -when-config_base_samll=1-the-kernel-261611-cascade-in-kernel-timerc-may-enter-the-infinite-loop.patch -when-config_base_samll=1-the-kernel-261611-cascade-in-kernel-timerc-may-enter-the-infinite-loop-use-list_replace_init.patch -codingstyle-add-typedefs-chapter.patch fs-bufferc-possible-cleanups.patch -drivers-md-raid6algosc-fix-a-null-dereference.patch -adjust-handle_irr_event-return-type.patch -sparse-fixes-for-synclink_cs.patch -jbd-split-checkpoint-lists.patch -more-bug_on-conversion.patch -make-kernel-ignore-bogus-partitions.patch -drivers-block-loopc-dont-return-garbage-if-loop_set_status-not-called.patch -docs-update-sparsetxt-with-check_endian.patch -random-remove-bogus-sa_sample_random-from-at91-compact-flash-driver.patch -kthread-convert-s390machc-from-kernel_thread.patch Merged into mainline or a subsystem tree +disable-debugging-version-of-write_lock.patch Disable the debug version of write_lock() - it's a box-killer. +fix-typo-in-acpi-video-brightness-changes.patch Fix tpyo. +initramfs-overwrite-fix.patch initramfs fix -git-acpi-pre.patch -git-acpi-post.patch Dropped. +disable-acpi-on-some-phoenix-bios.patch +drivers-acpi-scanc-make-acpi_bus_type-static.patch +cpu_relax-use-in-acpi-lock.patch +cpu_relax-use-in-acpi-lock-fix.patch +acpi-asus-s3-resume-fix.patch +acpi-asus-s3-resume-fix-fix.patch ACPI stuff +more-for_each_cpu-removal.patch Keep trying to remove for_each_cpu(). +cifs-build-fix.patch Fix git-cifs.patch. +remove-useless-checks-in-cifs-connectc.patch +cifs-remove-f_ownerlock-use.patch CIFS tweaks. +fix-use-after-free-bug-in-cpia2-driver.patch +drivers-media-video-vivic-make-2-functions-static.patch +drivers-media-video-pwc-make-code-static.patch +fix-up-funky-logic-in-dvb.patch Fix git-dvb.patch +ieee1394-nodemgr-do-not-peek-into-struct.patch Don't abuse semaphores in ieee1394 +input-allow-root-to-inject-unknown-scan-codes.patch Input feature. +git-kbuild-revert-kbuild-ignore-makes-built-in-rules-variables.patch Fix git-kbuild.patch. -kbuild-export-symbol-usage-report-generator.patch +kbuild-export-symbol-usage-report-generator-2.patch Updated. -via-pata-fails-on-some-atapi-drives-tidy.patch Folded into via-pata-fails-on-some-atapi-drives.patch +ata-add-some-nvidia-chipset-ids.patch +make-drivers-scsi-pata_pcmciacpcmcia_remove_one-static.patch +libatah-needs-scatterlisth.patch +sata-is-bust-on-s390.patch sata things. +ni5010-netcard-cleanup-fix.patch +s2io-driver-irq-fix.patch +s2io-driver-irq-fix-tidy.patch +qla3xxx-NIC-driver.patch +qla3xxx-is-bust.patch Net driver updates. Includes a new driver from qlogic which almost compiles. -git-nfs.patch -git-nfs-fixup.patch -git-nfs-build-fixes.patch -nfs-build-fix-99.patch +#git-nfs.patch +#git-nfs-fixup.patch +#git-nfs-build-fixes.patch +#nfs-build-fix-99.patch NFS tree dropped. +add-lookup-hint-for-network-file-systems.patch Speed up NFS mkdirs +git-pcmcia-fixup.patch Fix reject in git-pcmcia,patch. +powerpc-adding-the-use-of-the-firmware-soft-reset-nmi-to-kdump.patch +powerpc-kcofnig-warning-fix.patch powerpc things. +64-bit-resources-kconfig-change.patch +64bit-resource-fix-up-printks-for-resources-in-arch-and-core-code-fix.patch Fix Greg's tree a bit more. +git-s390.patch s390 tree is back. +drivers-scsi-qla2xxx-make-more-some-functions-static.patch +drivers-scsi-advansysc-cleanups.patch scsi tweaks. +usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers-fix.patch +if-0-drivers-usb-input-hid-corechid_find_field_by_usage.patch USB tweaks. +x86_64-apic-fix-apic-error-on-bootup.patch +x86_64-fix-bus-numbering-format-in-mmconfig-warning.patch x86_64 updates. -radix-tree-rcu-lockless-readside-wraning-fix.patch -radix-tree-rcu-lockless-readside-fix.patch Folded into radix-tree-rcu-lockless-readside.patch +redo-radix-tree-fixes.patch +adix-tree-rcu-lockless-readside-update.patch +radix-tree-rcu-lockless-readside-semicolon.patch +adix-tree-rcu-lockless-readside-update-tidy.patch More radix-tree work. +zoned-vm-counters-create-vmstatc-h-from-page_allocc-h.patch +zoned-vm-counters-create-vmstatc-h-from-page_allocc-h-s390-fix.patch +zoned-vm-counters-create-vmstatc-h-from-page_allocc-h-fix.patch +zoned-vm-counters-basic-zvc-zoned-vm-counter-implementation.patch +zoned-vm-counters-basic-zvc-zoned-vm-counter-implementation-tidy.patch +zoned-vm-counters-convert-nr_mapped-to-per-zone-counter.patch +zoned-vm-counters-convert-nr_mapped-to-per-zone-counter-fix.patch +zoned-vm-counters-conversion-of-nr_pagecache-to-per-zone-counter.patch +zoned-vm-counters-remove-nr_file_mapped-from-scan-control-structure.patch +zoned-vm-counters-remove-nr_file_mapped-from-scan-control-structure-fix.patch +zoned-vm-counters-split-nr_anon_pages-off-from-nr_file_mapped.patch +zoned-vm-counters-zone_reclaim-remove-proc-sys-vm-zone_reclaim_interval.patch +zoned-vm-counters-conversion-of-nr_slab-to-per-zone-counter.patch +zoned-vm-counters-conversion-of-nr_slab-to-per-zone-counter-fix.patch +zoned-vm-counters-conversion-of-nr_pagetables-to-per-zone-counter.patch +zoned-vm-counters-conversion-of-nr_pagetables-to-per-zone-counter-fix.patch +zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter.patch +zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter-fix.patch +zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter-nfs-fix.patch +zoned-vm-counters-conversion-of-nr_writeback-to-per-zone-counter.patch +zoned-vm-counters-conversion-of-nr_writeback-to-per-zone-counter-fix.patch +zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter.patch +zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter-nfs-fix.patch +zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter-fix.patch +zoned-vm-counters-conversion-of-nr_bounce-to-per-zone-counter.patch +zoned-vm-counters-conversion-of-nr_bounce-to-per-zone-counter-fix.patch +zoned-vm-counters-remove-useless-struct-wbs.patch +zoned-vm-counters-remove-read_page_state.patch More efficient VM counters. Buggier ones, too - piles of fixes were needed here :( +cpu_relax-smpbootc.patch +cpu_relax-smpbootc-fix.patch +x86-apic-fix-apic-error-on-bootup.patch +fix-broken-vm86-interrupt-signal-handling.patch +i386-cpu_relax-in-crashc-and-doublefaultc.patch x86 updates +m68k-fix-uaccessh-for-gcc-3x.patch +m68k-fix-constraints-of-the-signal-functions-and-some-cleanup.patch +m68k-fix-__iounmap-for-030.patch +m68k-small-flush_icache-cleanup.patch +m68k-add-the-generic-dma-api-functions.patch +m68k-dma-api-addition.patch +m68k-fix-show_registers.patch +m68k-separate-handler-for-auto-and-user-vector-interrupt.patch +m68k-cleanup-generic-irq-names.patch +m68k-cleanup-amiga-irq-numbering.patch +m68k-introduce-irq-controller.patch +m68k-convert-generic-irq-code-to-irq-controller.patch +m68k-convert-amiga-irq-code.patch +m68k-convert-apollo-irq-code.patch +m68k-convert-atari-irq-code.patch +m68k-convert-hp300-irq-code.patch +m68k-convert-mac-irq-code.patch +m68k-convert-q40-irq-code.patch +m68k-convert-sun3-irq-code.patch +m68k-convert-vme-irq-code.patch m68k updates. +fix-oddball-boolean-logic-in-s390-netiucv.patch +s390-broken-null-test-in-claw-driver.patch s390 updates +fs-ufs-inodec-make-2-functions-static.patch Cleanup +rtc-add-rtc-ds1553-driver.patch +rtc-add-rtc-ds1553-driver-tidy.patch +rtc-add-rtc-ds1553-driver-fix.patch +rtc-add-rtc-ds1742-driver.patch +rtc-add-rtc-ds1742-driver-tidy.patch +rtc-add-rtc-ds1742-driver-fix.patch +rtc-add-rtc-rs5c348-driver.patch More RTC drivers. +fuse-add-control-filesystem-get_sb_single-fix.patch +fuse-add-control-filesystem-fuse-comment-control-filesystem.patch +fuse-scramble-lock-owner-id.patch FUSE updates. kthread-update-loopc-to-use-kthread-fix.patch Folded into kthread-update-loopc-to-use-kthread.patch -kthread-convert-lock-to-use-kthread.patch Droped, I think. -stop-on-cpu-lost.patch -stop-on-cpu-lost-tidy.patch Dropped. +led-add-led-heartbeat-trigger-update.patch Fix led-add-led-heartbeat-trigger.patch +autofs4-needs-to-force-fail-return-revalidate-update.patch Fix autofs4-needs-to-force-fail-return-revalidate.patch +add-synclink_gt-custom-hdlc-idle.patch +add-synclink_gt-crc-return-feature.patch +fix-synclink_gt-diagnostics-error-reporting.patch +synclink_gt-add-gt2-adapter-support.patch +corrections-to-memory-barrier-doc.patch +add-option-for-stripping-modules-while-installing-them.patch +binfmt_elf-fix-checks-for-bad-address.patch +binfmt_elf-fix-checks-for-bad-address-fix.patch +pacct-two-phase-process-accounting.patch +pacct-avoidance-to-refer-the-last-thread-as-a-representation-of-the-process.patch +pacct-none-delayed-process-accounting-accumulation.patch +ext2-cleanup-put_page-and-comment-fix.patch +remove-gratuitous-inclusion-of-linux-configh-from.patch +au1550_ac97-spin_unlock-in-error-path.patch +generic_file_buffered_write-deadlock-on-vectored-write.patch +parport-add-to-kernel-doc.patch +drivers-char-agp-nvidia-agpc-remove-unused-variable.patch +au1xxx-oss-sound-support-for-au1200.patch +s390-setupc-cleanup-build-fix.patch +remove-tty_dont_flip.patch +fix-kdump-crash-kernel-boot-memory-reservation-for-numa.patch +fix-biovec-256-in-proc-slabinfo.patch +add-receive_room-flow-control-to-flush_to_ldisc.patch +add-receive_room-flow-control-to-flush_to_ldisc-tidy.patch +remove-unlikelysb-in-prune_dcache.patch Misc patches. +introduce-crashboot-kernel-command-line-parameter.patch +kdump-cciss-driver-initialization-issue-fix.patch Unpleasant kdump patches. +reiserfs-reorganize-bitmap-loading-functions-fix.patch +reiserfs-reorganize-bitmap-loading-functions-fix2.patch Fix reiserfs-reorganize-bitmap-loading-functions.patch +cpu-hotplug-revert-init-patch-submitted-for-2617.patch +cpu-hotplug-revert-initdata-patch-submitted-for-2617.patch +cpu-hotplug-make-register_cpu_notifier-init-time-only.patch +cpu-hotplug-make-register_cpu_notifier-init-time-only-fix.patch +cpu-hotplug-make-cpu_notifier-related-notifier-blocks-__cpuinit-only.patch +cpu-hotplug-make-cpu_notifier-related-notifier-blocks-__cpuinit-only-fix.patch +cpu-hotplug-make-cpu_notifier-related-notifier-calls-__cpuinit-only.patch +cpu-hotplug-make-cpu_notifier-related-notifier-calls-__cpuinit-only-fix.patch +cpu-hotplug-add-hotplug-versions-of-cpu_notifier.patch +cpu-hotplug-use-hotplug-version-of-cpu-notifier-in-appropriate-places.patch CPU hotplug kernel sectioning optimisation. -per-task-delay-accounting-taskstats-interface-fix-exit-race-in-per-task-delay-accounting.patch -per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface-use-portable-cputime-api-in-__delayacct_add_tsk.patch -per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface-fix-return-value-of-delayacct_add_tsk.patch Folded into other patches. +chardev-gpio-for-scx200-pc-8736x-add-platforn_device-static-numpins.patch +chardev-gpio-for-scx200-pc-8736x-add-platforn_device-enomem-on-device_add-failure.patch +chardev-gpio-for-scx200-pc-8736x-add-platforn_device-scx200-init-undo-malloc.patch +chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio-no-static-init.patch +chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio-no-weird-comment-placement.patch +chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio-fixups.patch +chardev-gpio-for-scx200-pc-8736x-add-platform_device-request-region.patch +chardev-gpio-for-scx200-pc-8736x-add-platform_device-request-region-series.patch +chardev-gpio-for-scx200-pc-8736x-use-dev_dbg-extern-to-header.patch +chardev-gpio-for-scx200-pc-8736x-fix-gpio_current-make-precedence-explicit.patch +chardev-gpio-for-scx200-pc-8736x-replace-spinlocks-fix.patch +chardev-gpio-for-scx200-pc-8736x-replace-spinlocks-include-linux-ioh.patch Update the GPIO patches in -mm. +fix-and-optimize-clock-source-update.patch Update time management patches in -mm. +sched-cpu-hotplug-race-vs-set_cpus_allowed.patch CPu scheduler fix. +sched_exit-fix-parent-time_slice-calculation.patch +sched_exit-move-the-callsite-to-do_exit.patch +sched-uninline-task_rq_lock.patch +bug-if-setscheduler-is-called-from-interrupt-context.patch CPu scheduler work. +swap_prefetch-vs-zoned-counters.patch Fix up prefetch for the zoned-counters work. +pi-futex-rt-mutex-tester-fix.patch Fix pi-futex-rt-mutex-tester.patch +drop-tasklist-lock-in-do_sched_setscheduler.patch +rtmutex-modify-rtmutex-tester-to-test-the-setscheduler.patch +rtmutex-propagate-priority-settings-into-pi-lock-chains.patch +rtmutex-propagate-priority-settings-into-pi-lock-chains-fix.patch pi-fuex updates. +selinux-add-sockcreate-node-to-procattr-api.patch Add selinux hooks to /proc rework in -mm. +ecryptfs-superblock-operations-ecryptfs-build-fix.patch +ecryptfs-crypto-functions-fix-filesize-on-hard-link-creation.patch +ecryptfs-remove-debugging-cruft.patch +ecryptfs-get_sb_dev-fix.patch ecrtpyfs updates. +make-kernel-sysctlc_proc_do_string-static.patch Cleanup. +namespaces-utsname-implement-clone_newuts-flag-tidy.patch Clean up namespaces-utsname-implement-clone_newuts-flag.patch +task-watchers-register-semundo-task-watcher-cleanup.patch Clean up task-watchers-register-semundo-task-watcher.patch +fs-reiser4-possible-cleanups.patch +reiser4-get_sb_dev-fix.patch +reiser4-vs-zoned-allocator.patch reiser4 things. -ide_dma_speed-fixes-warning-fix.patch -ide_dma_speed-fixes-tidy.patch Folded into ide_dma_speed-fixes.patch -hpt370-clean-up-dma-timeout-handling-cleanup.patch Folded into hpt370-clean-up-dma-timeout-handling.patch +drivers-ide-legacy-ide-csc-make-2-functions-static.patch IDE cleanup. +dm-mirror-log-sector-size-fix.patch +dm-mirror-log-refactor-context.patch +dm-mirror-log-bitset_size-fix.patch +dm-mirror-log-sync_count-fix.patch +dm-kcopyd-error-accumulation-fix.patch +dm-table-split_args-handle-no-input.patch +dm-consolidate-creation-functions.patch +dm-add-exports-2.patch +dm-create-error-table.patch +dm-prevent-removal-if-open.patch +dm-improve-error-message-consistency.patch +dm-support-ioctls-on-mapped-devices.patch +dm-linear-support-ioctls.patch +dm-mpath-support-ioctls.patch +dm-export-blkdev_driver_ioctl.patch Device mapper updates. +drivers-md-mdc-make-code-static.patch MD cleanup. -genirq-convert-the-x86_64-architecture-to-irq-chips.patch -genirq-convert-the-i386-architecture-to-irq-chips.patch -genirq-convert-the-i386-architecture-to-irq-chips-fix-2.patch -genirq-add-chip-eoi-fastack-fasteoi.patch -genirq-add-chip-eoi-fastack-fasteoi-fix.patch -genirq-allow-usage-of-no_irq_chip.patch +genirq-add-irq_type_sense_mask.patch +genirq-add-irq-chip-support-fasteoi-handler-handle-interrupt-disabling.patch +genirq-irq-document-what-an-irq-is.patch +genirq-add-chip-eoi-fastack-fasteoi-core.patch +genirq-add-chip-eoi-fastack-fasteoi-fix.patch Various genirq patches added, removed and moved around. +acpi-reduce-code-size-clean-up-fix-validator-message.patch Remove some odd ACPI constructs to make lockdep happy. -lock-validator-sparc64-sparc-m68k-alpha-cris-build-fix.patch -lock-validator-floppyc-irq-release-fix.patch -lock-validator-floppyc-irq-release-fix-fix.patch -lock-validator-floppyc-irq-release-fix-fix-fix.patch -lock-validator-forcedethc-fix.patch -lock-validator-mutex-section-binutils-workaround.patch -lock-validator-add-__module_address-method.patch -lock-validator-better-lock-debugging.patch -lock-validator-locking-api-self-tests.patch -lock-validator-locking-api-self-tests-self-test-fix.patch -lock-validator-locking-init-debugging-improvement.patch -lock-validator-beautify-x86_64-stacktraces.patch -lock-validator-beautify-x86_64-stacktraces-fix.patch -lock-validator-beautify-x86_64-stacktraces-fix-2.patch -lock-validator-beautify-x86_64-stacktraces-fix-3.patch -lock-validator-beautify-x86_64-stacktraces-fix-4.patch -lock-validator-x86_64-document-stack-frame-internals.patch -lock-validator-stacktrace.patch -lock-validator-stacktrace-build-fix.patch -lock-validator-stacktrace-warning-fix.patch -lock-validator-stacktrace-fix-on-x86_64.patch -lock-validator-fown-locking-workaround.patch -lock-validator-sk_callback_lock-workaround.patch -lock-validator-irqtrace-core.patch -lock-validator-irqtrace-core-powerpc-fix-1.patch -lock-validator-irqtrace-core-non-x86-fix.patch -lock-validator-irqtrace-core-non-x86-fix-2.patch -lock-validator-irqtrace-core-non-x86-fix-3.patch -lock-validator-irqtrace-entrys-fix.patch -lock-validator-irqtrace-core-remove-softirqc-warn_on.patch -lock-validator-irqtrace-cleanup-include-asm-i386-irqflagsh.patch -lock-validator-irqtrace-cleanup-include-asm-x86_64-irqflagsh.patch -lock-validator-x86_64-irqflags-trace-entrys-fix.patch -lock-validator-x86_64-irqflags-trace-entrys-fix-fix.patch -lock-validator-lockdep-add-local_irq_enable_in_hardirq-api.patch -lock-validator-add-per_cpu_offset.patch -lock-validator-add-per_cpu_offset-fix.patch -lock-validator-core.patch -lock-validator-core-early_boot_irqs_-build-fix.patch -lock-validator-core-early_boot_irqs_-build-fix-sparc64-sparc-m68k-alpha-cris-irqtrace-build-fix.patch -lock-validator-core-fix-compiler-warning.patch -lock-validator-core-add-config_debug_non_nested_unlocks.patch -lock-validator-core-provide-lockdep_off-lockdep_on-apis.patch -lock-validator-procfs.patch -lock-validator-core-multichar-fix.patch -lock-validator-core-count_matching_names-fix.patch -lock-validator-core-provide-lockdep_reinit_key-api.patch -lock-validator-core-print-info-not-bug.patch -lock-validator-design-docs.patch -lock-validator-prove-rwsem-locking-correctness.patch -lock-validator-prove-rwsem-locking-correctness-fix.patch -lock-validator-prove-rwsem-locking-correctness-powerpc-fix.patch -lock-validator-prove-spinlock-rwlock-locking-correctness.patch -lock-validator-prove-mutex-locking-correctness.patch -lock-validator-prove-mutex-locking-correctness-fix-null-type-name-bug.patch -better-lock-debugging-remove-mutex-deadlock-checking-code.patch -lock-validator-print-all-lock-types-on-sysrq-d.patch -lock-validator-x86_64-early-init.patch -lock-validator-smp-alternatives-workaround.patch -lock-validator-do-not-recurse-in-printk.patch -lock-validator-disable-nmi-watchdog-if-config_lockdep.patch -lock-validator-disable-nmi-watchdog-if-config_lockdep-i386.patch -lock-validator-disable-nmi-watchdog-if-config_lockdep-x86_64.patch -lock-validator-special-locking-bdev.patch -lock-validator-special-locking-bdev-fix.patch -lock-validator-special-locking-direct-io.patch -lock-validator-special-locking-serial.patch -lock-validator-special-locking-serial-fix.patch -lock-validator-special-locking-dcache.patch -lock-validator-special-locking-i_mutex.patch -lock-validator-special-locking-s_lock.patch -lock-validator-special-locking-futex.patch -lock-validator-special-locking-genirq.patch -lock-validator-special-locking-genirq-lock-validator-early_init_irq_lock_type-build-fix.patch -lock-validator-special-locking-completions.patch -lock-validator-special-locking-waitqueues.patch -lock-validator-special-locking-mm.patch -lock-validator-special-locking-serio.patch -lock-validator-special-locking-slab.patch -lock-validator-special-locking-skb_queue_head_init.patch -lock-validator-special-locking-net-ipv4-igmpcpatch.patch -lock-validator-special-locking-net-ipv4-igmpc-2.patch -lock-validator-special-locking-timerc.patch -lock-validator-special-locking-schedc.patch -lock-validator-special-locking-sctp.patch -lock-validator-special-locking-hrtimerc.patch -lock-validator-special-locking-sock_lock_init.patch -lock-validator-special-locking-af_unix.patch -lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type.patch -lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type-fix.patch -lock-validator-special-locking-bh_lock_sock.patch -lock-validator-annotate-ieee1394-skb-head-locking.patch -lock-validator-special-locking-mmap_sem.patch -lock-validator-special-locking-sb-s_umount.patch -lock-validator-special-locking-reiser4-false-positive.patch -lock-validator-special-locking-sb-s_umount-fix.patch -lock-validator-special-locking-sb-s_umount-2.patch -lock-validator-special-locking-sb-s_umount-2-fix.patch -lockdep-annotate-rpc_populate-for.patch -lock-validator-special-locking-jbd.patch -lock-validator-special-locking-posix-timers.patch -lock-validator-annotate-ntfs-locking-rules.patch -lock-validator-special-locking-sch_genericc.patch -lock-validator-special-locking-xfrm.patch -lockdep-annotate-the-quota-code.patch -lockdep-add-i_mutex-ordering-annotations-to-the-sunrpc.patch -lockdep-add-parent-child-annotations-to-usbfs.patch -lock-validator-special-locking-sound-core-seq-seq_portsc.patch -lock-validator-special-locking-sound-core-seq-seq_devicec.patch -lock-validator-special-locking-sound-core-seq-seq_devicec-fix.patch -lock-validator-fix-rt_hash_lock_sz.patch -lock-validator-introduce-irq__lockdep.patch -lock-validator-fix-sparc32-breakage.patch -locking-validator-special-rule-8390c-disable_irq.patch -locking-validator-special-rule-3c59xc-disable_irq.patch -lock-validator-enable-lock-validator-in-kconfig.patch -lock-validator-enable-lock-validator-in-kconfig-require-trace_irqflags_support.patch -lock-validator-enable-lock-validator-in-kconfig-not-yet.patch -lock-validator-enable-lock-validator-in-kconfig-add-config_debug_non_nested_unlocks-kconfig.patch -lockdep-one-stacktrace-column-if-config_lockdep=y.patch -i386-remove-multi-entry-backtraces.patch -lockdep-further-improve-stacktrace-output.patch -lock-validator-irqtrace-support-non-x86-architectures.patch -lock-validator-disable-oprofile-if-lockdep=y.patch -lock-validator-select-kallsyms_all.patch -lock-validator-v3.patch -lockdep-x86-only.patch -lockdep-really-x86-only.patch -lockdep-really-really-x86-only.patch -lock-validator-s390-stacktrace-interface.patch -lock-validator-s390-config_frame_pointer-support.patch -lock-validator-s390-rwsem-semaphore-changes.patch -lock-validator-early_init_irq_lock_type--console_init.patch -lock-validator-s390-irqtrace-support.patch -lock-validator-__local_bh_enable-_local_bh_enable.patch -lock-validator-s390-use-raw_spinlock-in-mcck-handler.patch -lock-validator-add-s390-to-supported-options.patch -lockdep-avoid-false-positive-illegal-lock-usage-message-in-qeth-driver.patch -lockdep-hack-around-build-errors.patch Droped. -kgdb-core-lite.patch -lock-validator-special-locking-kgdb.patch -kgdb-core-lite-add-reboot-command.patch -kgdb-8250.patch -kgdb-8250-fix.patch -kgdb-netpoll_pass_skb_to_rx_hook.patch -kgdb-eth.patch -kgdb-i386-lite.patch -kgdb-cfi_annotations.patch -kgdb-sysrq_bugfix.patch -kgdb-module.patch -kgdb-core.patch -kgdb-i386.patch Shelved. -journal_add_journal_head-debug.patch -page-owner-tracking-leak-detector.patch -unplug-can-sleep.patch -firestream-warnings.patch -#periodically-scan-redzone-entries-and-slab-control-structures.patch -slab-leak-detector.patch -releasing-resources-with-children.patch -nr_blockdev_pages-in_interrupt-warning.patch -detect-atomic-counter-underflows.patch -device-suspend-debug.patch -slab-cache-shrinker-statistics.patch -mm-debug-dump-pageframes-on-bad_page.patch -debug-warn-if-we-sleep-in-an-irq-for-a-long-time.patch -debug-shared-irqs.patch -make-frame_pointer-default=y.patch -i386-enable-4k-stacks-by-default.patch -pidhash-temporary-debug-checks.patch -acpi-identify-which-device-is-not-power-manageable.patch -revert-tty-buffering-comment-out-debug-code.patch -mutex-subsystem-synchro-test-module.patch -x86-e820-debugging.patch -slab-leaks3-default-y.patch -x86-kmap_atomic-debugging.patch -profile-likely-unlikely-macros.patch -vdso-print-fatal-signals.patch -vdso-improve-print_fatal_signals-support-by-adding-memory-maps.patch Shelved. All 1268 patches: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/patch-list ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 13:19 2.6.17-mm2 Andrew Morton @ 2006-06-24 15:53 ` Rafael J. Wysocki 2006-06-24 17:20 ` 2.6.17-mm2 Dave Jones 2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall ` (13 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Rafael J. Wysocki @ 2006-06-24 15:53 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Saturday 24 June 2006 15:19, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ The box seems to work, although I have some "interesting" stuff in dmesg: int3: 0000 [1] PREEMPT last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device CPU 0 Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4 RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1} RSP: 0018:ffff810052c59e40 EFLAGS: 00000292 RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0 RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0 R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0 FS: 00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0 Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810) Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390 ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0 ffffc20000af4930 ffff8100531a5490 Call Trace: [<ffff810052c59f78>] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40> <6>note: modprobe[4839] exited with preempt_count 1 eth0: no IPv6 routers present hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 Slab corruption: start=ffff810041e09810, len=1936 060: 81 20 71 93 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b Prev obj: start=ffff810041e09080, len=1936 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Slab corruption: start=ffff810042e86080, len=1936 060: 3d d4 14 92 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b Next obj: start=ffff810042e86810, len=1936 000: 01 00 00 00 00 00 00 00 00 e0 3a 4a 00 81 ff ff 010: 02 00 00 00 00 00 00 00 40 20 40 00 00 00 00 00 and later, after a resume from disk: drivers/usb/core/inode.c: creating file '003' Slab corruption: start=ffff810041e05040, len=1936 060: cf f5 5f 9c 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b Next obj: start=ffff810041e057d0, len=1936 000: 01 00 00 00 00 00 00 00 00 00 4f 3c 00 81 ff ff 010: 02 00 00 00 00 00 00 00 00 01 40 00 00 00 00 00 Slab corruption: start=ffff810041e09080, len=1936 060: 7f 4f 01 95 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b Next obj: start=ffff810041e09810, len=1936 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Slab corruption: start=ffff810042e86810, len=1936 060: 68 06 7f 9c 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b 090: 6b 6b 6b 6b 6b 6b 6b 6b 01 00 00 00 6b 6b 6b 6b Prev obj: start=ffff810042e86080, len=1936 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Greetings, Rafael ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki @ 2006-06-24 17:20 ` Dave Jones 2006-06-24 21:34 ` 2.6.17-mm2 Andrew Morton 0 siblings, 1 reply; 93+ messages in thread From: Dave Jones @ 2006-06-24 17:20 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel On Sat, Jun 24, 2006 at 05:53:44PM +0200, Rafael J. Wysocki wrote: > On Saturday 24 June 2006 15:19, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > The box seems to work, although I have some "interesting" stuff in dmesg: > > int3: 0000 [1] PREEMPT > last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device > CPU 0 > Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd > Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4 > RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1} > RSP: 0018:ffff810052c59e40 EFLAGS: 00000292 > RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff > RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0 > RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001 > R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0 > R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0 > FS: 00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0 > Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810) > Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390 > ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0 > ffffc20000af4930 ffff8100531a5490 > Call Trace: [<ffff810052c59f78>] > > Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40> 'something' filled this function with breakpoints. Andrew mentioned he dropped the kgdb patches. Any chance something was missed? Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 17:20 ` 2.6.17-mm2 Dave Jones @ 2006-06-24 21:34 ` Andrew Morton 2006-06-25 8:51 ` 2.6.17-mm2 Rafael J. Wysocki 0 siblings, 1 reply; 93+ messages in thread From: Andrew Morton @ 2006-06-24 21:34 UTC (permalink / raw) To: Dave Jones; +Cc: rjw, linux-kernel, Chandra Seetharaman On Sat, 24 Jun 2006 13:20:14 -0400 Dave Jones <davej@redhat.com> wrote: > On Sat, Jun 24, 2006 at 05:53:44PM +0200, Rafael J. Wysocki wrote: > > On Saturday 24 June 2006 15:19, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > > > The box seems to work, although I have some "interesting" stuff in dmesg: > > > > int3: 0000 [1] PREEMPT > > last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device > > CPU 0 > > Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd > > Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4 > > RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1} > > RSP: 0018:ffff810052c59e40 EFLAGS: 00000292 > > RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff > > RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0 > > RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001 > > R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0 > > R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0 > > FS: 00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0 > > Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810) > > Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390 > > ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0 > > ffffc20000af4930 ffff8100531a5490 > > Call Trace: [<ffff810052c59f78>] > > > > Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > > RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40> > > 'something' filled this function with breakpoints. > Andrew mentioned he dropped the kgdb patches. Any chance something was missed? > My guess would be that cpufreq_register_driver() is being called after it has been unloaded from the kernel. Do you have CONFIG_CPU_FREQ=y? Does removal of the __cpuinit from cpufreq_register_driver() fix it (or move the crash elsewhere)? Do you get any section mismatch warnings at build-time? Chandra, those patches seem a bit wobbly. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 21:34 ` 2.6.17-mm2 Andrew Morton @ 2006-06-25 8:51 ` Rafael J. Wysocki 2006-06-25 10:22 ` 2.6.17-mm2 Andrew Morton 0 siblings, 1 reply; 93+ messages in thread From: Rafael J. Wysocki @ 2006-06-25 8:51 UTC (permalink / raw) To: Andrew Morton; +Cc: Dave Jones, linux-kernel, Chandra Seetharaman On Saturday 24 June 2006 23:34, Andrew Morton wrote: > On Sat, 24 Jun 2006 13:20:14 -0400 > Dave Jones <davej@redhat.com> wrote: > > > On Sat, Jun 24, 2006 at 05:53:44PM +0200, Rafael J. Wysocki wrote: > > > On Saturday 24 June 2006 15:19, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > > > > > The box seems to work, although I have some "interesting" stuff in dmesg: > > > > > > int3: 0000 [1] PREEMPT > > > last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device > > > CPU 0 > > > Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd > > > Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4 > > > RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1} > > > RSP: 0018:ffff810052c59e40 EFLAGS: 00000292 > > > RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff > > > RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0 > > > RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001 > > > R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0 > > > R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0 > > > FS: 00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > > > CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0 > > > Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810) > > > Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390 > > > ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0 > > > ffffc20000af4930 ffff8100531a5490 > > > Call Trace: [<ffff810052c59f78>] > > > > > > Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > > > RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40> > > > > 'something' filled this function with breakpoints. > > Andrew mentioned he dropped the kgdb patches. Any chance something was missed? > > > > My guess would be that cpufreq_register_driver() is being called after it > has been unloaded from the kernel. > > Do you have CONFIG_CPU_FREQ=y? Yes. > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or > move the crash elsewhere)? Yes (makes it go away). > Do you get any section mismatch warnings at build-time? Only this one: WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1164) and 'acpi_processor_power_exit' Greetings, Rafael ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 8:51 ` 2.6.17-mm2 Rafael J. Wysocki @ 2006-06-25 10:22 ` Andrew Morton 2006-06-25 15:16 ` 2.6.17-mm2 Andrew Morton ` (2 more replies) 0 siblings, 3 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-25 10:22 UTC (permalink / raw) To: Rafael J. Wysocki Cc: davej, linux-kernel, sekharan, Rusty Russell, Randy.Dunlap, Sam Ravnborg On Sun, 25 Jun 2006 10:51:55 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > > > > > > > My guess would be that cpufreq_register_driver() is being called after it > > has been unloaded from the kernel. > > > > Do you have CONFIG_CPU_FREQ=y? > > Yes. > > > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or > > move the crash elsewhere)? > > Yes (makes it go away). Well it would appear that the new __cpuinit on cpufreq_register_driver() is causing the problem, although I'm surprised that you don't have CONFIG_HOTPLUG_CPU set, if it's a swsusp requirement?? > > Do you get any section mismatch warnings at build-time? > > Only this one: > WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1164) and 'acpi_processor_power_exit' > That's a false-positive - the code in there is, I think, OK: static int first_run; ... if (!first_run) { dmi_check_system(processor_power_dmi_table); ... first_run++; } The warning is about the reference to processor_power_dmi_table. But as long as the first call to acpi_processor_power_init() happens prior to free_initmem(), we won't actually try to touch the unloaded memory. It's fragile and nasty though - it'd be nice to sort it out. Anyway. It's regrettable that the new section-checking code didn't complain about the bug. It looks like this is because the call to cpufreq_register_driver() happened at modprobe-time, and we don't check for that. Which is rather bad. Sam, would it be possible to check for references from modules into statically-linked __init code? It's always wrong... Rusty/Randy/whoever looks after modules: it also seems wrong that it's possible to load a module which refers to now-unloaded symbols. In fact, it's surprising - sorry if I'm misinterpreting this. If I'm not, it should be pretty easy to barf if a module is trying to get at symbols which lie between __init_begin and __init_end? Chandra, this is scary stuff. I'll tempdrop those patches until we can get the kbuild/modprobe infrastructure in place which will allow us to fully check your sectioning changes at depmod/modprobe time. <thinks> Actually, it should still be possible to do this - simply do a `make allyesconfig; make' with the patches unapplied, then do it with the patches applied and then look for the differences in the warnings. Need to do this with various combinations of CONFIG_MODULES, CONFIG_HOTPLUG, CONFIG_HOTPLUG_CPU, CONFIG_MEMORY_HOTPLUG, CONFIG_ACPI_HOTPLUG_MEMORY and CONFIG_ACPI_HOTPLUG_MEMORY_MODULE. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 10:22 ` 2.6.17-mm2 Andrew Morton @ 2006-06-25 15:16 ` Andrew Morton 2006-06-25 18:23 ` 2.6.17-mm2 Sam Ravnborg 2006-06-30 7:38 ` 2.6.17-mm2 Randy.Dunlap 2006-06-25 19:19 ` 2.6.17-mm2 Rafael J. Wysocki 2006-06-26 20:13 ` 2.6.17-mm2 Chandra Seetharaman 2 siblings, 2 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-25 15:16 UTC (permalink / raw) To: rjw, davej, linux-kernel, sekharan, rusty, rdunlap, sam On Sun, 25 Jun 2006 03:22:43 -0700 Andrew Morton <akpm@osdl.org> wrote: > Anyway. It's regrettable that the new section-checking code didn't > complain about the bug. It looks like this is because the call to > cpufreq_register_driver() happened at modprobe-time, and we don't check for > that. Which is rather bad. > > Sam, would it be possible to check for references from modules into > statically-linked __init code? It's always wrong... > > Rusty/Randy/whoever looks after modules: it also seems wrong that it's > possible to load a module which refers to now-unloaded symbols. In fact, > it's surprising - sorry if I'm misinterpreting this. If I'm not, it should > be pretty easy to barf if a module is trying to get at symbols which lie > between __init_begin and __init_end? > Actually we should be able to address this pretty simply by disallowing exports of symbols which are in the __init section. There's no sense in exporting something which ain't there. IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future into __init or __initdata should be a hard error. It'd be lovely to do that at compile-time, but I cannot think of a way. Sam, does that sound reasonable&&feasible? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 15:16 ` 2.6.17-mm2 Andrew Morton @ 2006-06-25 18:23 ` Sam Ravnborg 2006-06-25 18:40 ` 2.6.17-mm2 Andrew Morton 2006-06-30 7:38 ` 2.6.17-mm2 Randy.Dunlap 1 sibling, 1 reply; 93+ messages in thread From: Sam Ravnborg @ 2006-06-25 18:23 UTC (permalink / raw) To: Andrew Morton; +Cc: rjw, davej, linux-kernel, sekharan, rusty, rdunlap On Sun, Jun 25, 2006 at 08:16:10AM -0700, Andrew Morton wrote: > On Sun, 25 Jun 2006 03:22:43 -0700 > > Actually we should be able to address this pretty simply by disallowing > exports of symbols which are in the __init section. There's no sense in > exporting something which ain't there. > > IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future > into __init or __initdata should be a hard error. We could let modpost error out. Then the module does not get build but we detect it a bit later than optimal. Sam ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 18:23 ` 2.6.17-mm2 Sam Ravnborg @ 2006-06-25 18:40 ` Andrew Morton 2006-06-25 21:21 ` 2.6.17-mm2 Sam Ravnborg 0 siblings, 1 reply; 93+ messages in thread From: Andrew Morton @ 2006-06-25 18:40 UTC (permalink / raw) To: Sam Ravnborg; +Cc: rjw, davej, linux-kernel, sekharan, rusty, rdunlap On Sun, 25 Jun 2006 20:23:52 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > On Sun, Jun 25, 2006 at 08:16:10AM -0700, Andrew Morton wrote: > > On Sun, 25 Jun 2006 03:22:43 -0700 > > > > Actually we should be able to address this pretty simply by disallowing > > exports of symbols which are in the __init section. There's no sense in > > exporting something which ain't there. > > > > IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future > > into __init or __initdata should be a hard error. > We could let modpost error out. Then the module does not get build but > we detect it a bit later than optimal. > Well, it doesn't have anything to do with modules per-se. When vmlinux is post-processed we want to error out if vmlinux is exporting any __init/__initdata symbols to modules. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 18:40 ` 2.6.17-mm2 Andrew Morton @ 2006-06-25 21:21 ` Sam Ravnborg 0 siblings, 0 replies; 93+ messages in thread From: Sam Ravnborg @ 2006-06-25 21:21 UTC (permalink / raw) To: Andrew Morton; +Cc: rjw, davej, linux-kernel, sekharan, rusty, rdunlap On Sun, Jun 25, 2006 at 11:40:51AM -0700, Andrew Morton wrote: > > > > > IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future > > > into __init or __initdata should be a hard error. > > We could let modpost error out. Then the module does not get build but > > we detect it a bit later than optimal. > > > > Well, it doesn't have anything to do with modules per-se. When vmlinux is > post-processed we want to error out if vmlinux is exporting any > __init/__initdata symbols to modules. modpost has evolved over time and when I get the time I will refactor kbuild so we always call modpost in the final steps of the kernel build independent on module support or not. And then is makes perfect sense to have the check for exported symbols from illegal sections located there. In other words current modpost will be used also when executing "make vmlinux". That impose a few tricky things and I have posponed it for now. Implementing the suggested check should be possible and will try to look at that sooner. Sam ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 15:16 ` 2.6.17-mm2 Andrew Morton 2006-06-25 18:23 ` 2.6.17-mm2 Sam Ravnborg @ 2006-06-30 7:38 ` Randy.Dunlap 2006-07-02 10:11 ` 2.6.17-mm2 Russell King 1 sibling, 1 reply; 93+ messages in thread From: Randy.Dunlap @ 2006-06-30 7:38 UTC (permalink / raw) To: Andrew Morton; +Cc: rjw, davej, linux-kernel, sekharan, rusty, sam On Sun, 25 Jun 2006 08:16:10 -0700 Andrew Morton wrote: > On Sun, 25 Jun 2006 03:22:43 -0700 > Andrew Morton <akpm@osdl.org> wrote: > > > Anyway. It's regrettable that the new section-checking code didn't > > complain about the bug. It looks like this is because the call to > > cpufreq_register_driver() happened at modprobe-time, and we don't check for > > that. Which is rather bad. > > > > Sam, would it be possible to check for references from modules into > > statically-linked __init code? It's always wrong... > > > > Rusty/Randy/whoever looks after modules: it also seems wrong that it's > > possible to load a module which refers to now-unloaded symbols. In fact, > > it's surprising - sorry if I'm misinterpreting this. If I'm not, it should > > be pretty easy to barf if a module is trying to get at symbols which lie > > between __init_begin and __init_end? > > > > Actually we should be able to address this pretty simply by disallowing > exports of symbols which are in the __init section. There's no sense in > exporting something which ain't there. > > IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future > into __init or __initdata should be a hard error. > > It'd be lovely to do that at compile-time, but I cannot think of a way. > > Sam, does that sound reasonable&&feasible? Until modpost (or whatever) can do this, here are a few that a shell script has found for me by examing source code only -- may contain some false reports: ./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph) ./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup) ./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph); ./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup) ./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input); ./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup) ./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output); ./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value) ./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch); ./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on) ./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive); ./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on) ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info); ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info) ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info); ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info) ./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg); ./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index) ./arch/mips/au1000/common/prom.c:155:EXPORT_SYMBOL(prom_getcmdline); ./arch/mips/philips/pnx8550/common/prom.c:136:EXPORT_SYMBOL(prom_getcmdline); ./arch/mips/arc/cmdline.c:19:char * __init prom_getcmdline(void) ./arch/mips/au1000/common/setup.c:47:extern char * __init prom_getcmdline(void); ./arch/mips/galileo-boards/ev96100/init.c:56:char * __init prom_getcmdline(void) ./arch/mips/galileo-boards/ev96100/setup.c:52:extern char *__init prom_getcmdline(void); ./arch/mips/ite-boards/generic/pmon_prom.c:55:char * __init prom_getcmdline(void) ./arch/mips/jmr3927/common/prom.c:54:char * __init prom_getcmdline(void) ./arch/mips/mips-boards/generic/cmdline.c:34:char * __init prom_getcmdline(void) ./arch/mips/mips-boards/sim/sim_cmdline.c:24:char * __init prom_getcmdline(void) ./arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c:93:char * __init prom_getcmdline(void) ./arch/mips/tx4938/toshiba_rbtx4938/prom.c:75:char * __init prom_getcmdline(void) ./arch/powerpc/platforms/powermac/setup.c:397:EXPORT_SYMBOL(note_scsi_host); ./arch/powerpc/platforms/powermac/setup.c:370:void __init note_scsi_host(struct device_node *node, void *host) ./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new); ./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp) --- ~Randy ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-30 7:38 ` 2.6.17-mm2 Randy.Dunlap @ 2006-07-02 10:11 ` Russell King 2006-07-02 18:42 ` 2.6.17-mm2 Randy.Dunlap 2006-07-03 5:50 ` 2.6.17-mm2 Randy.Dunlap 0 siblings, 2 replies; 93+ messages in thread From: Russell King @ 2006-07-02 10:11 UTC (permalink / raw) To: Randy.Dunlap Cc: Andrew Morton, rjw, davej, linux-kernel, sekharan, rusty, sam On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote: > Until modpost (or whatever) can do this, here are a few that > a shell script has found for me by examing source code only -- > may contain some false reports: > > ./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph) > ./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup) > > ./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph); > ./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup) > > ./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input); > ./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup) > > ./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output); > ./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value) > > ./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch); > ./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on) > > ./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive); > ./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on) > > ./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg); > ./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index) > These would appear to be false: #ifdef CONFIG_MODULES #define __init_or_module #define __initdata_or_module #else #define __init_or_module __init #define __initdata_or_module __initdata #endif /*CONFIG_MODULES*/ and: #else /* !CONFIG_MODULES... */ #define EXPORT_SYMBOL(sym) #define EXPORT_SYMBOL_GPL(sym) #define EXPORT_SYMBOL_GPL_FUTURE(sym) #define EXPORT_UNUSED_SYMBOL(sym) #define EXPORT_UNUSED_SYMBOL_GPL(sym) means that in the modules case, they aren't marked as __init and are exported, but in the non-modular case they are marked as __init but not exported. Hence, export symbols marked as __init_or_module is safe. > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info); > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info) > > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info); > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info) > > ./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new); > ./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp) These are definitely buggy. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-07-02 10:11 ` 2.6.17-mm2 Russell King @ 2006-07-02 18:42 ` Randy.Dunlap 2006-07-02 18:47 ` 2.6.17-mm2 Arjan van de Ven 2006-07-02 18:47 ` 2.6.17-mm2 Sam Ravnborg 2006-07-03 5:50 ` 2.6.17-mm2 Randy.Dunlap 1 sibling, 2 replies; 93+ messages in thread From: Randy.Dunlap @ 2006-07-02 18:42 UTC (permalink / raw) To: Russell King; +Cc: akpm, rjw, davej, linux-kernel, sekharan, rusty, sam On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote: > On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote: > > Until modpost (or whatever) can do this, here are a few that > > a shell script has found for me by examing source code only -- > > may contain some false reports: > > > > ./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph) > > ./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup) > > > > ./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph); > > ./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup) > > > > ./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input); > > ./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup) > > > > ./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output); > > ./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value) > > > > ./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch); > > ./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on) > > > > ./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive); > > ./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on) > > > > ./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg); > > ./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index) > > > > These would appear to be false: > > #ifdef CONFIG_MODULES > #define __init_or_module > #define __initdata_or_module > #else > #define __init_or_module __init > #define __initdata_or_module __initdata > #endif /*CONFIG_MODULES*/ > > and: > > #else /* !CONFIG_MODULES... */ > #define EXPORT_SYMBOL(sym) > #define EXPORT_SYMBOL_GPL(sym) > #define EXPORT_SYMBOL_GPL_FUTURE(sym) > #define EXPORT_UNUSED_SYMBOL(sym) > #define EXPORT_UNUSED_SYMBOL_GPL(sym) > > means that in the modules case, they aren't marked as __init and are > exported, but in the non-modular case they are marked as __init but > not exported. > > Hence, export symbols marked as __init_or_module is safe. Thanks for checking + feedback. > > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info); > > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info) > > > > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info); > > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info) > > > > ./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new); > > ./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp) > > These are definitely buggy. Only if we have a policy of not exporting __init or __initdata or __exit. Are we there yet?? snd_chip_uda1341_mixer_new() is called from sound/arm/sa11xx-uda1341.c::sa11xx_uda1341_probe(), which is __init, so it looks safe to me, although I support a policy that EXPORTs cannot be __init or __exit or __initdata. --- ~Randy ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-07-02 18:42 ` 2.6.17-mm2 Randy.Dunlap @ 2006-07-02 18:47 ` Arjan van de Ven 2006-07-02 18:47 ` 2.6.17-mm2 Sam Ravnborg 1 sibling, 0 replies; 93+ messages in thread From: Arjan van de Ven @ 2006-07-02 18:47 UTC (permalink / raw) To: Randy.Dunlap Cc: Russell King, akpm, rjw, davej, linux-kernel, sekharan, rusty, sam On Sun, 2006-07-02 at 11:42 -0700, Randy.Dunlap wrote: > > Only if we have a policy of not exporting __init or __initdata or > __exit. Are we there yet?? __exit is harder, but __init and __initdata is obvious; those are tossed out of memory before you can even load a module so exporting those HAS to be a bug; no excuse possible. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-07-02 18:42 ` 2.6.17-mm2 Randy.Dunlap 2006-07-02 18:47 ` 2.6.17-mm2 Arjan van de Ven @ 2006-07-02 18:47 ` Sam Ravnborg 1 sibling, 0 replies; 93+ messages in thread From: Sam Ravnborg @ 2006-07-02 18:47 UTC (permalink / raw) To: Randy.Dunlap Cc: Russell King, akpm, rjw, davej, linux-kernel, sekharan, rusty > Only if we have a policy of not exporting __init or __initdata or > __exit. Are we there yet?? On the principle of minimum suprise we shall no allow exported symbols to magically disappear. Only some architectures do get rid of .init and therefore a module may work with architecture one, but not architecture two which is very unpredictable. It should be established as a rule better now than later that this is a no-go. Sam ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-07-02 10:11 ` 2.6.17-mm2 Russell King 2006-07-02 18:42 ` 2.6.17-mm2 Randy.Dunlap @ 2006-07-03 5:50 ` Randy.Dunlap 2006-07-03 13:49 ` 2.6.17-mm2 Russell King 1 sibling, 1 reply; 93+ messages in thread From: Randy.Dunlap @ 2006-07-03 5:50 UTC (permalink / raw) To: Russell King; +Cc: akpm, rjw, davej, linux-kernel, sekharan, rusty, sam On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote: > On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote: > > Until modpost (or whatever) can do this, here are a few that > > a shell script has found for me by examing source code only -- > > may contain some false reports: > > ... > > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info); > > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info) > > > > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info); > > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info) > > > These are definitely buggy. Um, well, I could blindly remove those __init sections, but in looking at the code, set_imx_fb_info() is not ever used, and imx_set_mmc_info() is called from some __init code... It looks like this code can only be built-in, not as a loadable module. (so someone who knows it should jump in here) If that's correct, then the EXPORT_SYMBOL() isn't even needed and the function can remain as __init (right?). --- ~Randy ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-07-03 5:50 ` 2.6.17-mm2 Randy.Dunlap @ 2006-07-03 13:49 ` Russell King 0 siblings, 0 replies; 93+ messages in thread From: Russell King @ 2006-07-03 13:49 UTC (permalink / raw) To: Randy.Dunlap; +Cc: akpm, rjw, davej, linux-kernel, sekharan, rusty, sam On Sun, Jul 02, 2006 at 10:50:24PM -0700, Randy.Dunlap wrote: > On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote: > > On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote: > > > Until modpost (or whatever) can do this, here are a few that > > > a shell script has found for me by examing source code only -- > > > may contain some false reports: > > > > ... > > > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info); > > > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info) > > > > > > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info); > > > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info) > > > > > These are definitely buggy. > > Um, well, I could blindly remove those __init sections, but in > looking at the code, set_imx_fb_info() is not ever used, and > imx_set_mmc_info() is called from some __init code... > > It looks like this code can only be built-in, not as a loadable > module. (so someone who knows it should jump in here) > If that's correct, then the EXPORT_SYMBOL() isn't even needed > and the function can remain as __init (right?). Since they're being used to set the platform data for devices, which are registered during the init time, they should definitely only be called early on during init - otherwise you're potentially changing data which drivers expect to be static. So the exports should go. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 10:22 ` 2.6.17-mm2 Andrew Morton 2006-06-25 15:16 ` 2.6.17-mm2 Andrew Morton @ 2006-06-25 19:19 ` Rafael J. Wysocki 2006-06-26 20:13 ` 2.6.17-mm2 Chandra Seetharaman 2 siblings, 0 replies; 93+ messages in thread From: Rafael J. Wysocki @ 2006-06-25 19:19 UTC (permalink / raw) To: Andrew Morton Cc: davej, linux-kernel, sekharan, Rusty Russell, Randy.Dunlap, Sam Ravnborg On Sunday 25 June 2006 12:22, Andrew Morton wrote: > On Sun, 25 Jun 2006 10:51:55 +0200 > "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > > > > > > > > > > > My guess would be that cpufreq_register_driver() is being called after it > > > has been unloaded from the kernel. > > > > > > Do you have CONFIG_CPU_FREQ=y? > > > > Yes. > > > > > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or > > > move the crash elsewhere)? > > > > Yes (makes it go away). > > Well it would appear that the new __cpuinit on cpufreq_register_driver() is > causing the problem, although I'm surprised that you don't have > CONFIG_HOTPLUG_CPU set, if it's a swsusp requirement?? It's only required if CONFIG_SMP is set. ;-) Greetings, Rafael ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 10:22 ` 2.6.17-mm2 Andrew Morton 2006-06-25 15:16 ` 2.6.17-mm2 Andrew Morton 2006-06-25 19:19 ` 2.6.17-mm2 Rafael J. Wysocki @ 2006-06-26 20:13 ` Chandra Seetharaman 2 siblings, 0 replies; 93+ messages in thread From: Chandra Seetharaman @ 2006-06-26 20:13 UTC (permalink / raw) To: Andrew Morton Cc: Rafael J. Wysocki, davej, linux-kernel, Rusty Russell, Randy.Dunlap, Sam Ravnborg On Sun, 2006-06-25 at 03:22 -0700, Andrew Morton wrote: > Chandra, this is scary stuff. I'll tempdrop those patches until we can get > the kbuild/modprobe infrastructure in place which will allow us to fully > check your sectioning changes at depmod/modprobe time. > > <thinks> > > Actually, it should still be possible to do this - simply do a `make > allyesconfig; make' with the patches unapplied, then do it with the patches > applied and then look for the differences in the warnings. Andrew, After looking at the code closely, IMO, the patch you applied om -mm (title cpufreq_register_driver-section-fix) seem to be in the right direction. It does need another patch to make sure the hotplug version of the cpu notifier register/unregister is used in cpufreq. Below is a patch. > > Need to do this with various combinations of CONFIG_MODULES, > CONFIG_HOTPLUG, CONFIG_HOTPLUG_CPU, CONFIG_MEMORY_HOTPLUG, > CONFIG_ACPI_HOTPLUG_MEMORY and CONFIG_ACPI_HOTPLUG_MEMORY_MODULE. I will test these combinations. --------------------- cpufreq_register_driver() has to made available at all time (not init only). Hence, we should be using hotplug version of the cpu notifier register/unregister function instead of the _init time only_ version. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> -- drivers/cpufreq/cpufreq.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) Index: linux-2.6.17/drivers/cpufreq/cpufreq.c =================================================================== --- linux-2.6.17.orig/drivers/cpufreq/cpufreq.c +++ linux-2.6.17/drivers/cpufreq/cpufreq.c @@ -1497,7 +1497,8 @@ int cpufreq_update_policy(unsigned int c } EXPORT_SYMBOL(cpufreq_update_policy); -static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, +#ifdef CONFIG_HOTPLUG_CPU +static int cpufreq_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu) { unsigned int cpu = (unsigned long)hcpu; @@ -1536,6 +1537,7 @@ static struct notifier_block __cpuinitda { .notifier_call = cpufreq_cpu_callback, }; +#endif /* CONFIG_HOTPLUG_CPU */ /********************************************************************* * REGISTER / UNREGISTER CPUFREQ DRIVER * @@ -1596,7 +1598,7 @@ int cpufreq_register_driver(struct cpufr } if (!ret) { - register_cpu_notifier(&cpufreq_cpu_notifier); + register_hotcpu_notifier(&cpufreq_cpu_notifier); dprintk("driver %s up and running\n", driver_data->name); cpufreq_debug_enable_ratelimit(); } @@ -1628,7 +1630,7 @@ int cpufreq_unregister_driver(struct cpu dprintk("unregistering driver %s\n", driver->name); sysdev_driver_unregister(&cpu_sysdev_class, &cpufreq_sysdev_driver); - unregister_cpu_notifier(&cpufreq_cpu_notifier); + unregister_hotcpu_notifier(&cpufreq_cpu_notifier); spin_lock_irqsave(&cpufreq_driver_lock, flags); cpufreq_driver = NULL; -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sekharan@us.ibm.com | .......you may get it. ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 13:19 2.6.17-mm2 Andrew Morton 2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki @ 2006-06-24 19:41 ` Dominik Karall 2006-06-24 21:43 ` 2.6.17-mm2 Andrew Morton 2006-06-25 6:06 ` 2.6.17-mm2 Reuben Farrelly ` (12 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Dominik Karall @ 2006-06-24 19:41 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Saturday, 24. June 2006 15:19, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 >7/2.6.17-mm2/ hi! I get this warning on make modules_install: WARNING: /lib/modules/2.6.17-mm2/kernel/net/ieee80211/ieee80211.ko needs unknown symbol wireless_spy_update regards, dominik ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall @ 2006-06-24 21:43 ` Andrew Morton 0 siblings, 0 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-24 21:43 UTC (permalink / raw) To: Dominik Karall; +Cc: linux-kernel, netdev, John W. Linville, Jeff Garzik On Sat, 24 Jun 2006 21:41:41 +0200 Dominik Karall <dominik.karall@gmx.net> wrote: > On Saturday, 24. June 2006 15:19, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 > >7/2.6.17-mm2/ > > hi! > > I get this warning on make modules_install: > > WARNING: /lib/modules/2.6.17-mm2/kernel/net/ieee80211/ieee80211.ko > needs unknown symbol wireless_spy_update > Someone removed the `#ifdef CONFIG_WIRELESS_EXT' from around the callsite in net/ieee80211/ieee80211_rx.c and didn't update Kconfig appropriately. Presumably, setting CONFIG_WIRELESS_EXT will get you going again. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 13:19 2.6.17-mm2 Andrew Morton 2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki 2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall @ 2006-06-25 6:06 ` Reuben Farrelly 2006-06-25 9:37 ` 2.6.17-mm2 Barry K. Nathan 2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski ` (11 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Reuben Farrelly @ 2006-06-25 6:06 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel Hi, On 25/06/2006 1:19 a.m., Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > > - The locking validator patches have all been dropped - Ingo is redoing the > patch series. > > - The arch-secific parts of the generic IRQ rework have been dropped, so > it's a do-nothing patch series at present. If we can verify that it indeed > does nothing then we might be able to squeak it into 2.6.18 for powerpc to > merge against. > > - The kgdb patches have been tempdropped. Partly to make merging of other > things easier, partly because someone broke it. > > - The various little -mm-only debugging patches have been temporarily > dropped, to make followon patching easier. I'm seeing a very bizarre problem with this release - and it's 100% reproduceable. But I've no real idea where to look any further. Seems that something is going on with this release that is completely screwing up a number of things including particularly Postfix which is running on the system. Even local deliveries from one account to another are failing, they are in the queue and are logged "skipped, still being delivered" but never actually complete, hence I end up with a big heap of mail all within the Postfix system but not actually completing delivery. What is so bizarre is that by reverting to 2.6.17-rc6-mm2, it all comes right and the piled up mail flushes straight through. So it does look to me like a kernel problem and not a Postfix one (at least, not a config problem). I also noticed when I restarted the system after I first noticed it that some of the partitions could not be unmounted at the final stages of shutdown because they were busy. Things like /home ... which is rather strange because there should be nothing whatsoever running on it at power off. Anything using them should have been TERMed or KILLed on the way down out of runlevel 3: Starting killall: [ OK ] Sending all processes the TERM signal... Sending all processes the KILL signal... Saving random seed: Syncing hardware clock to system time Turning off swap: Unmounting file systems: umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /home: device is busy umount2: Device or resource busy umount: /home: device is busy /var: cccccccc /home: mmmmmmmm Unmounting file systems (retry): umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /home: device is busy umount2: Device or resource busy umount: /home: device is busy /var: cccccccc /home: mmmmmmmm Unmounting file systems (retry): umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /home: device is busy umount2: Device or resource busy umount: /home: device is busy /var: cccccccc /home: mmmmmmmm umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /var: device is busy umount2: Device or resource busy umount: /home: device is busy umount2: Device or resource busy umount: /home: device is busy mount: /home is busy Please stand by while rebooting the system... md: stopping all md devices. md: md1 still in use. md: md2 still in use. md: md3 switched to read-only mode. md: md4 switched to read-only mode. md: md6 switched to read-only mode. md: md5 switched to read-only mode. md: md0 still in use. Synchronizing SCSI cache for disk sdc: Synchronizing SCSI cache for disk sdb: *** Where is the synchronizing entry for sda? <power cycled the box as it got stuck at this point> Is something bust something with regards to signals or something that could be causing these symptoms? Some more info: [root@tornado log]# mount /dev/md0 on / type ext3 (rw) none on /proc type proc (rw) sysfs on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) /dev/sda1 on /boot type ext3 (rw) /dev/md1 on /home type ext3 (rw) /dev/md2 on /var type ext3 (rw) /dev/md3 on /var/www/cgi-bin type ext3 (rw) /dev/md4 on /tmp type ext3 (rw) /dev/md5 on /var/www/html type ext3 (rw) /dev/sda8 on /var/spool/squid-1 type reiserfs (rw,noatime,notail) /dev/sdc8 on /var/spool/squid-2 type reiserfs (rw,noatime,notail) /dev/sdb1 on /store type ext3 (rw) /dev/sdb2 on /backup type ext3 (rw) /dev/shm on /var/spool/amavisd/tmp type tmpfs (rw,size=25m,mode=700,uid=101,gid=511) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) [root@tornado log]# and the usual hardware up at http://www.reub.net/files/kernel/system-hardware. 2.6.17-mm1 was a no-go for me due to the bustage with ReiserFS and bitmaps, even the hotfix didn't seem to fix that... :-( Reuben ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 6:06 ` 2.6.17-mm2 Reuben Farrelly @ 2006-06-25 9:37 ` Barry K. Nathan 2006-06-25 10:29 ` 2.6.17-mm2 Reuben Farrelly 0 siblings, 1 reply; 93+ messages in thread From: Barry K. Nathan @ 2006-06-25 9:37 UTC (permalink / raw) To: Reuben Farrelly; +Cc: Andrew Morton, linux-kernel On 6/24/06, Reuben Farrelly <reuben-lkml@reub.net> wrote: > 2.6.17-mm1 was a no-go for me due to the bustage with ReiserFS and bitmaps, even > the hotfix didn't seem to fix that... :-( Take 2.6.17-mm1, apply the hotfix, then apply this patch from 2.6.17-mm2 also: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/broken-out/reiserfs-reorganize-bitmap-loading-functions-fix2.patch That should make 2.6.17-mm1's reiserfs work. (This way you can at least see whether your 2.6.17-mm2 bug happens under -mm1 as well.) -- -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 9:37 ` 2.6.17-mm2 Barry K. Nathan @ 2006-06-25 10:29 ` Reuben Farrelly 0 siblings, 0 replies; 93+ messages in thread From: Reuben Farrelly @ 2006-06-25 10:29 UTC (permalink / raw) To: Barry K. Nathan; +Cc: Andrew Morton, linux-kernel On 25/06/2006 9:37 p.m., Barry K. Nathan wrote: > On 6/24/06, Reuben Farrelly <reuben-lkml@reub.net> wrote: >> 2.6.17-mm1 was a no-go for me due to the bustage with ReiserFS and >> bitmaps, even >> the hotfix didn't seem to fix that... :-( > > Take 2.6.17-mm1, apply the hotfix, then apply this patch from 2.6.17-mm2 > also: > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/broken-out/reiserfs-reorganize-bitmap-loading-functions-fix2.patch > > > That should make 2.6.17-mm1's reiserfs work. (This way you can at > least see whether your 2.6.17-mm2 bug happens under -mm1 as well.) Thanks. That seems to work a bit better...in fact -mm1 it seems to work just fine now. The problem with Postfix and the disks shutting down is obviously new to -mm2. Reuben ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (2 preceding siblings ...) 2006-06-25 6:06 ` 2.6.17-mm2 Reuben Farrelly @ 2006-06-25 11:19 ` Michal Piotrowski 2006-06-25 11:40 ` 2.6.17-mm2 Andrew Morton 2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall ` (10 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Michal Piotrowski @ 2006-06-25 11:19 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel Hi, On 24/06/06, Andrew Morton <akpm@osdl.org> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > I found this in /var/log/messages.1 Jun 24 22:29:52 ltg01-fedora kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6b7b Jun 24 22:29:52 ltg01-fedora kernel: printing eip: Jun 24 22:29:52 ltg01-fedora kernel: c01174f2 Jun 24 22:29:52 ltg01-fedora kernel: *pde = 00000000 Jun 24 22:29:52 ltg01-fedora kernel: Oops: 0000 [#1] Jun 24 22:29:52 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP Jun 24 22:29:52 ltg01-fedora kernel: last sysfs file: /devices/platform/i2c-9191/9191-0290/temp2_input Jun 24 22:29:52 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables x_tables p4_clockmod speedstep_lib binfmt_ misc thermal processor fan container parport_pc parport nvram snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq _oss snd_seq_midi_event evdev snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore ide_cd snd_pa ge_alloc intel_agp i2c_i801 sk98lin skge agpgart cdrom rtc unix Jun 24 22:29:52 ltg01-fedora kernel: CPU: 0 Jun 24 22:29:52 ltg01-fedora kernel: EIP: 0060:[<c01174f2>] Not tainted VLI Jun 24 22:29:52 ltg01-fedora kernel: EFLAGS: 00010096 (2.6.17-mm2 #51) Jun 24 22:29:52 ltg01-fedora kernel: EIP is at task_rq_lock+0x1d/0x57 Jun 24 22:29:52 ltg01-fedora kernel: eax: 6b6b6b6b ebx: c03cc740 ecx: c031e9e8 edx: f3aac7f0 Jun 24 22:29:52 ltg01-fedora kernel: esi: f3aac7f0 edi: ea28af5c ebp: ea28af4c esp: ea28af3c Jun 24 22:29:52 ltg01-fedora kernel: ds: 007b es: 007b ss: 0068 Jun 24 22:29:52 ltg01-fedora kernel: Process sh (pid: 23201, ti=ea28a000 task=f71f2e30 task.ti=ea28a000) Jun 24 22:29:52 ltg01-fedora kernel: Stack: f3aac7f0 ea28af84 f3aac7f0 00000010 ea28af6c c011b1a6 f71f2e30 ea28af6c Jun 24 22:29:52 ltg01-fedora kernel: 00000296 ea28af84 f71f2e30 00000010 ea28af98 c0120d9f 00000000 00000001 Jun 24 22:29:52 ltg01-fedora kernel: f3726170 f71f2efc ea28af84 ea28af84 ea8f329c 00000000 49dd0140 ea28afac Jun 24 22:29:52 ltg01-fedora kernel: Call Trace: Jun 24 22:29:52 ltg01-fedora kernel: [<c0103d84>] show_stack_log_lvl+0x8c/0x97 Jun 24 22:29:52 ltg01-fedora kernel: [<c0103ef7>] show_registers+0x12c/0x199 Jun 24 22:29:52 ltg01-fedora kernel: [<c01040f3>] die+0x18f/0x2ac Jun 24 22:29:52 ltg01-fedora kernel: [<c0115afe>] do_page_fault+0x3dd/0x4c3 Jun 24 22:29:52 ltg01-fedora kernel: [<c0103911>] error_code+0x39/0x40 Jun 24 22:29:52 ltg01-fedora kernel: [<c011b1a6>] sched_exit+0x29/0xab Jun 24 22:29:52 ltg01-fedora kernel: [<c0120d9f>] do_exit+0x7d3/0x801 Jun 24 22:29:52 ltg01-fedora kernel: [<c0120e46>] sys_exit_group+0x0/0x11 Jun 24 22:29:52 ltg01-fedora kernel: [<c0120e55>] sys_exit_group+0xf/0x11 Jun 24 22:29:52 ltg01-fedora kernel: [<c0102ddd>] sysenter_past_esp+0x56/0x79 Jun 24 22:29:52 ltg01-fedora kernel: Code: e9 1a 00 89 d8 e8 c1 e9 1a 00 5b 5e 5d c3 55 89 e5 57 56 53 83 ec 04 89 45 f0 89 d7 9c 8f 07 fa bb 40 c7 3c c0 8b 55 f0 8b 42 04 <8b> 40 10 89 de 03 34 85 00 66 39 c0 89 f0 e8 8d e9 1a 00 8b 55 Jun 24 22:29:52 ltg01-fedora kernel: EIP: [<c01174f2>] task_rq_lock+0x1d/0x57 SS:ESP 0068:ea28af3c Jun 24 22:29:52 ltg01-fedora kernel: <1>Fixing recursive fault but reboot is needed! Here is a config file http://www.stardust.webpages.pl/files/mm/2.6.17-mm2/mm-config Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski @ 2006-06-25 11:40 ` Andrew Morton 2006-06-25 12:18 ` 2.6.17-mm2 Michal Piotrowski 0 siblings, 1 reply; 93+ messages in thread From: Andrew Morton @ 2006-06-25 11:40 UTC (permalink / raw) To: Michal Piotrowski; +Cc: linux-kernel On Sun, 25 Jun 2006 13:19:25 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: > On 24/06/06, Andrew Morton <akpm@osdl.org> wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > > > I found this in /var/log/messages.1 > > Jun 24 22:29:52 ltg01-fedora kernel: BUG: unable to handle kernel > paging request at virtual address 6b6b6b7b > Jun 24 22:29:52 ltg01-fedora kernel: printing eip: > Jun 24 22:29:52 ltg01-fedora kernel: c01174f2 > Jun 24 22:29:52 ltg01-fedora kernel: *pde = 00000000 > Jun 24 22:29:52 ltg01-fedora kernel: Oops: 0000 [#1] > Jun 24 22:29:52 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP > Jun 24 22:29:52 ltg01-fedora kernel: last sysfs file: > /devices/platform/i2c-9191/9191-0290/temp2_input > Jun 24 22:29:52 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf > hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios > _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp > iptable_filter ip_tables x_tables p4_clockmod speedstep_lib binfmt_ > misc thermal processor fan container parport_pc parport nvram > snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq > _oss snd_seq_midi_event evdev snd_seq snd_seq_device snd_pcm_oss > snd_mixer_oss snd_pcm snd_timer snd soundcore ide_cd snd_pa > ge_alloc intel_agp i2c_i801 sk98lin skge agpgart cdrom rtc unix > Jun 24 22:29:52 ltg01-fedora kernel: CPU: 0 > Jun 24 22:29:52 ltg01-fedora kernel: EIP: 0060:[<c01174f2>] Not > tainted VLI > Jun 24 22:29:52 ltg01-fedora kernel: EFLAGS: 00010096 (2.6.17-mm2 #51) > Jun 24 22:29:52 ltg01-fedora kernel: EIP is at task_rq_lock+0x1d/0x57 OK, thanks. I expect the below will fix that (I've since dropped the offending patches) Begin forwarded message: Date: Sun, 25 Jun 2006 01:31:12 +0200 From: Ingo Molnar <mingo@elte.hu> To: Andrew Morton <akpm@osdl.org> Subject: Re: more -mm2 troubles ... * Ingo Molnar <mingo@elte.hu> wrote: > hm, look at the sched_exit() => task_rq_lock() use-after-free crash > below. > > I bet it was p->real_parent that got freed. (because at the point we > call sched_exit() we already unlink ourselves from the parent so it is > free to exit) > > We moved sched_exit() within exit.c to an unsafe place in mm2 - what > patch was that? patch below seems to fix it for me. mm2 is now stable. Ingo -------------- Subject: move sched_exit() back to under the tasklist_lock umbrella From: Ingo Molnar <mingo@elte.hu> seems like sched_exit() cannot be moved to a later stage just yet. Needs more investigation. Signed-off-by: Ingo Molnar <mingo@elte.hu> --- kernel/exit.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux/kernel/exit.c =================================================================== --- linux.orig/kernel/exit.c +++ linux/kernel/exit.c @@ -827,6 +827,7 @@ static void exit_notify(struct task_stru state = EXIT_DEAD; tsk->exit_state = state; + sched_exit(tsk); write_unlock_irq(&tasklist_lock); list_for_each_safe(_p, _n, &ptrace_dead) { @@ -952,8 +953,6 @@ fastcall NORET_TYPE void do_exit(long co if (tsk->splice_pipe) __free_pipe_info(tsk->splice_pipe); - sched_exit(tsk); - /* PF_DEAD causes final put_task_struct after we schedule. */ preempt_disable(); BUG_ON(tsk->flags & PF_DEAD); ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-25 11:40 ` 2.6.17-mm2 Andrew Morton @ 2006-06-25 12:18 ` Michal Piotrowski 0 siblings, 0 replies; 93+ messages in thread From: Michal Piotrowski @ 2006-06-25 12:18 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On 25/06/06, Andrew Morton <akpm@osdl.org> wrote: > On Sun, 25 Jun 2006 13:19:25 +0200 > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: > > > On 24/06/06, Andrew Morton <akpm@osdl.org> wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > > > > > > I found this in /var/log/messages.1 > > > > Jun 24 22:29:52 ltg01-fedora kernel: BUG: unable to handle kernel > > paging request at virtual address 6b6b6b7b > > Jun 24 22:29:52 ltg01-fedora kernel: printing eip: > > Jun 24 22:29:52 ltg01-fedora kernel: c01174f2 > > Jun 24 22:29:52 ltg01-fedora kernel: *pde = 00000000 > > Jun 24 22:29:52 ltg01-fedora kernel: Oops: 0000 [#1] > > Jun 24 22:29:52 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP > > Jun 24 22:29:52 ltg01-fedora kernel: last sysfs file: > > /devices/platform/i2c-9191/9191-0290/temp2_input > > Jun 24 22:29:52 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf > > hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios > > _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp > > iptable_filter ip_tables x_tables p4_clockmod speedstep_lib binfmt_ > > misc thermal processor fan container parport_pc parport nvram > > snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq > > _oss snd_seq_midi_event evdev snd_seq snd_seq_device snd_pcm_oss > > snd_mixer_oss snd_pcm snd_timer snd soundcore ide_cd snd_pa > > ge_alloc intel_agp i2c_i801 sk98lin skge agpgart cdrom rtc unix > > Jun 24 22:29:52 ltg01-fedora kernel: CPU: 0 > > Jun 24 22:29:52 ltg01-fedora kernel: EIP: 0060:[<c01174f2>] Not > > tainted VLI > > Jun 24 22:29:52 ltg01-fedora kernel: EFLAGS: 00010096 (2.6.17-mm2 #51) > > Jun 24 22:29:52 ltg01-fedora kernel: EIP is at task_rq_lock+0x1d/0x57 > > OK, thanks. I expect the below will fix that (I've since dropped the > offending patches) > Problem fixed, thanks. Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 (NULL pointer dereference) 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (3 preceding siblings ...) 2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski @ 2006-06-25 16:25 ` Dominik Karall 2006-06-25 17:18 ` Andrew Morton 2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk ` (9 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Dominik Karall @ 2006-06-25 16:25 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Saturday, 24. June 2006 15:19, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 >7/2.6.17-mm2/ hi! I got this error with 2.6.17-mm1 too, I took a picture with my mobile, hope it's readable: http://stud4.tuwien.ac.at/~e0227135/kernel/060625_180209.jpg hth, dominik ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 (NULL pointer dereference) 2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall @ 2006-06-25 17:18 ` Andrew Morton 2006-06-25 18:11 ` Dominik Karall 0 siblings, 1 reply; 93+ messages in thread From: Andrew Morton @ 2006-06-25 17:18 UTC (permalink / raw) To: Dominik Karall; +Cc: linux-kernel On Sun, 25 Jun 2006 18:25:26 +0200 Dominik Karall <dominik.karall@gmx.net> wrote: > On Saturday, 24. June 2006 15:19, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 > >7/2.6.17-mm2/ > > hi! > > I got this error with 2.6.17-mm1 too, I took a picture with my mobile, > hope it's readable: > http://stud4.tuwien.ac.at/~e0227135/kernel/060625_180209.jpg > hm, that's new. We do seem to be getting a few sysfs/kobject crashes in there. Do you actually have the bttv hardware present? ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 (NULL pointer dereference) 2006-06-25 17:18 ` Andrew Morton @ 2006-06-25 18:11 ` Dominik Karall 0 siblings, 0 replies; 93+ messages in thread From: Dominik Karall @ 2006-06-25 18:11 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Sunday, 25. June 2006 19:18, Andrew Morton wrote: > On Sun, 25 Jun 2006 18:25:26 +0200 > > Dominik Karall <dominik.karall@gmx.net> wrote: > > On Saturday, 24. June 2006 15:19, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2 > > >.6.1 7/2.6.17-mm2/ > > > > hi! > > > > I got this error with 2.6.17-mm1 too, I took a picture with my > > mobile, hope it's readable: > > http://stud4.tuwien.ac.at/~e0227135/kernel/060625_180209.jpg > > hm, that's new. We do seem to be getting a few sysfs/kobject > crashes in there. > > Do you actually have the bttv hardware present? Yes, the bttv hardware is present. You can find my lspci output and the .config file which I used for that kernel at: http://stud4.tuwien.ac.at/~e0227135/kernel/ hth, dominik ^ permalink raw reply [flat|nested] 93+ messages in thread
* 2.6.17-mm2: no QLA3YYY_NAPI help text 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (4 preceding siblings ...) 2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall @ 2006-06-25 16:47 ` Adrian Bunk 2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk ` (8 subsequent siblings) 14 siblings, 0 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-25 16:47 UTC (permalink / raw) To: Andrew Morton, Ron Mercer Cc: linux-kernel, Jeff Garzik, Stephen Hemminger, netdev [ resent with a subject adapted to vger mail filter... ] On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: >... > Changes since 2.6.17-mm1: >... > +qla3xxx-NIC-driver.patch >... > Net driver updates. Includes a new driver from qlogic which almost compiles. >... The QLA3XXX_NAPI option lacks a help text. Please add a help text. TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 93+ messages in thread
* 2.6.17-mm2: BLK_CPQ_CISS_DA=m error 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (5 preceding siblings ...) 2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk @ 2006-06-25 19:32 ` Adrian Bunk 2006-06-26 0:41 ` Vivek Goyal 2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk ` (7 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Adrian Bunk @ 2006-06-25 19:32 UTC (permalink / raw) To: Andrew Morton, Vivek Goyal Cc: linux-kernel, mike.miller, iss_storagedev, hbabu, fastboot On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: >... > Changes since 2.6.17-mm1: >... > +kdump-cciss-driver-initialization-issue-fix.patch > > Unpleasant kdump patches. >... This patch breaks CONFIG_BLK_CPQ_CISS_DA=m: <-- snip --> ... if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.17-mm2; fi WARNING: /lib/modules/2.6.17-mm2/kernel/drivers/block/cciss.ko needs unknown symbol crash_boot <-- 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] 93+ messages in thread
* Re: 2.6.17-mm2: BLK_CPQ_CISS_DA=m error 2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk @ 2006-06-26 0:41 ` Vivek Goyal 0 siblings, 0 replies; 93+ messages in thread From: Vivek Goyal @ 2006-06-26 0:41 UTC (permalink / raw) To: Adrian Bunk, Morton Andrew Morton Cc: linux-kernel, mike.miller, iss_storagedev, hbabu, fastboot On Sun, Jun 25, 2006 at 09:32:21PM +0200, Adrian Bunk wrote: > On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.17-mm1: > >... > > +kdump-cciss-driver-initialization-issue-fix.patch > > > > Unpleasant kdump patches. > >... > > This patch breaks CONFIG_BLK_CPQ_CISS_DA=m: > > <-- snip --> > > ... > if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map 2.6.17-mm2; fi > WARNING: /lib/modules/2.6.17-mm2/kernel/drivers/block/cciss.ko needs unknown symbol crash_boot > Sorry. I forgot to export the symbol crash_boot. Please find attached the patch. Thanks Vivek o Compilation of cciss driver broke when compiled as a module as crash_boot was not exported. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> --- linux-2.6.17-1M-vivek/init/main.c | 1 + 1 files changed, 1 insertion(+) diff -puN init/main.c~cciss-module-compilation-break-fix init/main.c --- linux-2.6.17-1M/init/main.c~cciss-module-compilation-break-fix 2006-06-25 20:31:24.000000000 -0400 +++ linux-2.6.17-1M-vivek/init/main.c 2006-06-25 20:31:24.000000000 -0400 @@ -131,6 +131,7 @@ static char *ramdisk_execute_command; * context. */ unsigned int crash_boot; +EXPORT_SYMBOL(crash_boot); /* Setup configured maximum number of CPUs to activate */ static unsigned int max_cpus = NR_CPUS; _ ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (6 preceding siblings ...) 2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk @ 2006-06-25 23:13 ` Adrian Bunk 2006-06-25 23:27 ` Alan Cox 2006-06-27 1:03 ` Jeff Garzik 2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk ` (6 subsequent siblings) 14 siblings, 2 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-25 23:13 UTC (permalink / raw) To: Andrew Morton, alan; +Cc: linux-kernel, jgarzik, linux-ide On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: >... > Changes since 2.6.17-mm1: >... > git-libata-all.patch >... > git trees >... This patch makes the needlessly global it821x_passthru_dev_select() static. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c.old 2006-06-25 22:52:11.000000000 +0200 +++ linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c 2006-06-25 22:52:52.000000000 +0200 @@ -411,7 +411,8 @@ * Device selection hook. If neccessary perform clock switching */ -void it821x_passthru_dev_select(struct ata_port *ap, unsigned int device) +static void it821x_passthru_dev_select(struct ata_port *ap, + unsigned int device) { struct it821x_dev *itdev = ap->private_data; if (itdev && device != itdev->last_device) { ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static 2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk @ 2006-06-25 23:27 ` Alan Cox 2006-06-27 1:03 ` Jeff Garzik 1 sibling, 0 replies; 93+ messages in thread From: Alan Cox @ 2006-06-25 23:27 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, alan, linux-kernel, jgarzik, linux-ide On Mon, Jun 26, 2006 at 01:13:24AM +0200, Adrian Bunk wrote: > On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.17-mm1: > >... > > git-libata-all.patch > >... > > git trees > >... > > This patch makes the needlessly global it821x_passthru_dev_select() > static. > > Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Alan Cox <alan@redhat.com> > > --- linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c.old 2006-06-25 22:52:11.000000000 +0200 > +++ linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c 2006-06-25 22:52:52.000000000 +0200 > @@ -411,7 +411,8 @@ > * Device selection hook. If neccessary perform clock switching > */ > > -void it821x_passthru_dev_select(struct ata_port *ap, unsigned int device) > +static void it821x_passthru_dev_select(struct ata_port *ap, > + unsigned int device) > { > struct it821x_dev *itdev = ap->private_data; > if (itdev && device != itdev->last_device) { -- "Some people are like Slinkies... Not really good for anything, but they still bring a smile to your face when you push them down a flight of stairs." -- Gordon Wolfe. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static 2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk 2006-06-25 23:27 ` Alan Cox @ 2006-06-27 1:03 ` Jeff Garzik 1 sibling, 0 replies; 93+ messages in thread From: Jeff Garzik @ 2006-06-27 1:03 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, alan, linux-kernel, linux-ide applied ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (7 preceding siblings ...) 2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk @ 2006-06-25 23:13 ` Adrian Bunk 2006-06-26 4:05 ` Steven French 2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk ` (5 subsequent siblings) 14 siblings, 1 reply; 93+ messages in thread From: Adrian Bunk @ 2006-06-25 23:13 UTC (permalink / raw) To: Andrew Morton, Steven French; +Cc: linux-kernel, linux-cifs-client On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: >... > Changes since 2.6.17-mm1: >... > +cifs-build-fix.patch > > Fix git-cifs.patch. >... Let's hope gcc guesses the prototye of the function right. Otherwise, this patch has turned a compile error into a nasty runtime error (in many cases, the stack is garbage). The -Werror-implicit-function-declaration gcc flag would turn such possible problems into compile errors. This patch removes the (never required) #ifdef from the prototype of thie function in fs/cifs/cifsproto.h. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6.17-mm2-full/fs/cifs/cifsproto.h.old 2006-06-26 00:00:56.000000000 +0200 +++ linux-2.6.17-mm2-full/fs/cifs/cifsproto.h 2006-06-26 00:01:02.000000000 +0200 @@ -64,11 +64,9 @@ extern void header_assemble(struct smb_hdr *, char /* command */ , const struct cifsTconInfo *, int /* length of fixed section (word count) in two byte units */); -#ifdef CONFIG_CIFS_EXPERIMENTAL extern int small_smb_init_no_tc(const int smb_cmd, const int wct, struct cifsSesInfo *ses, void ** request_buf); -#endif extern int CIFS_SessSetup(unsigned int xid, struct cifsSesInfo *ses, const int stage, const struct nls_table *nls_cp); ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype 2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk @ 2006-06-26 4:05 ` Steven French 0 siblings, 0 replies; 93+ messages in thread From: Steven French @ 2006-06-26 4:05 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, linux-cifs-client, linux-kernel The equivalent fix should already be merged in now The missed ifdef removal happened a couple days ago as I turned on the previously experimental new session establishment code (in fs/cifs/sess.c) and turn off the older code in fs/cifs/connect.c (necessary for legacy win9x lanman server support and more secure (ntlmv2) session establishment support). I have a few relatively minor changes to make to fs/cifs/sess.c (including changing buffer allocation in a few places, an ntlmv2 fix for support of one server type) still. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com Adrian Bunk <bunk@stusta.de> wrote on 06/25/2006 06:13:29 PM: > On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.17-mm1: > >... > > +cifs-build-fix.patch > > > > Fix git-cifs.patch. > >... > > Let's hope gcc guesses the prototye of the function right. > > Otherwise, this patch has turned a compile error into a nasty runtime > error (in many cases, the stack is garbage). > > The -Werror-implicit-function-declaration gcc flag would turn such > possible problems into compile errors. > > This patch removes the (never required) #ifdef from the prototype of > thie function in fs/cifs/cifsproto.h. > > Signed-off-by: Adrian Bunk <bunk@stusta.de> > > --- linux-2.6.17-mm2-full/fs/cifs/cifsproto.h.old 2006-06-26 00: > 00:56.000000000 +0200 > +++ linux-2.6.17-mm2-full/fs/cifs/cifsproto.h 2006-06-26 00:01:02. > 000000000 +0200 > @@ -64,11 +64,9 @@ > extern void header_assemble(struct smb_hdr *, char /* command */ , > const struct cifsTconInfo *, int /* length of > fixed section (word count) in two byte units */); > -#ifdef CONFIG_CIFS_EXPERIMENTAL > extern int small_smb_init_no_tc(const int smb_cmd, const int wct, > struct cifsSesInfo *ses, > void ** request_buf); > -#endif > extern int CIFS_SessSetup(unsigned int xid, struct cifsSesInfo *ses, > const int stage, > const struct nls_table *nls_cp); > ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] drivers/scsi/arcmsr/: cleanups 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (8 preceding siblings ...) 2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk @ 2006-06-26 15:17 ` Adrian Bunk 2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk ` (4 subsequent siblings) 14 siblings, 0 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-26 15:17 UTC (permalink / raw) To: Andrew Morton, Erich Chen; +Cc: linux-kernel, James.Bottomley, linux-scsi This patch contains the following cleanups: - arcmsr_attr.c: #if 0 the unused arcmsr_free_sysfs_attr() - arcmsr_hba.c: make the needlessly global arcmsr_iop_reset() static Signed-off-by: Adrian Bunk <bunk@stusta.de> --- drivers/scsi/arcmsr/arcmsr_attr.c | 2 ++ drivers/scsi/arcmsr/arcmsr_hba.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) --- linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_attr.c.old 2006-06-26 01:43:40.000000000 +0200 +++ linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_attr.c 2006-06-26 01:44:00.000000000 +0200 @@ -171,12 +171,14 @@ &arcmsr_sysfs_message_transfer_attr); } +#if 0 void arcmsr_free_sysfs_attr(struct AdapterControlBlock *acb) { struct Scsi_Host *host = acb->host; sysfs_remove_bin_file(&host->shost_gendev.kobj, &arcmsr_sysfs_message_transfer_attr); } +#endif /* 0 */ static ssize_t arcmsr_attr_host_driver_version(struct class_device *cdev, char *buf) { --- linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_hba.c.old 2006-06-26 01:44:09.000000000 +0200 +++ linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_hba.c 2006-06-26 01:44:19.000000000 +0200 @@ -1357,7 +1357,7 @@ acb->acb_flags |= ACB_F_IOP_INITED; } -void arcmsr_iop_reset(struct AdapterControlBlock *acb) +static void arcmsr_iop_reset(struct AdapterControlBlock *acb) { struct MessageUnit __iomem *reg = acb->pmu; struct CommandControlBlock *ccb; ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] drivers/md/raid5.c: remove an unused variable 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (9 preceding siblings ...) 2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk @ 2006-06-26 20:27 ` Adrian Bunk 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks ` (3 subsequent siblings) 14 siblings, 0 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-26 20:27 UTC (permalink / raw) To: Andrew Morton, Neil Brown; +Cc: linux-kernel, mingo, linux-raid This patch removes an unused variable. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6.17-mm2-full/drivers/md/raid5.c.old 2006-06-26 21:17:13.000000000 +0200 +++ linux-2.6.17-mm2-full/drivers/md/raid5.c 2006-06-26 21:17:20.000000000 +0200 @@ -2827,7 +2827,6 @@ struct stripe_head *sh; int pd_idx; int raid_disks = conf->raid_disks; - int data_disks = raid_disks - conf->max_degraded; sector_t max_sector = mddev->size << 1; int sync_blocks; int still_degraded = 0; ^ permalink raw reply [flat|nested] 93+ messages in thread
* 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (10 preceding siblings ...) 2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk @ 2006-06-26 21:41 ` Valdis.Kletnieks 2006-06-26 22:50 ` Valdis.Kletnieks ` (3 more replies) 2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk ` (2 subsequent siblings) 14 siblings, 4 replies; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-26 21:41 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 2545 bytes --] On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer related. This is at fairly early userspace - the initrd has run, but we're not into /etc/rc.sysinit yet (although the root filesystem is mounted and we have a kjournald for it). Poking with sysrq-T and sysrq-R gets me this: [ 108.301806] Pid: 4, comm: khelper [ 108.330565] EIP: 0060:[<c0119f48>] CPU: 0 [ 108.359315] EIP is at getnstimeofday+0x9e/0xb8 [ 108.387820] EFLAGS: 00000207 Not tainted (2.6.17-mm2 #1) [ 108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba [ 108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b [ 108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 [ 108.501579] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 [ 108.530366] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 108.559363] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 [ 108.588523] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc [ 108.617618] <c01006c5> kernel_thread_helper+0x5/0xb [ 115.881903] SysRq : Show Regs [ 115.910288] [ 115.938097] Pid: 4, comm: khelper [ 115.965908] EIP: 0060:[<c0119f48>] CPU: 0 [ 115.993553] EIP is at getnstimeofday+0x9e/0xb8 [ 116.020928] EFLAGS: 00000287 Not tainted (2.6.17-mm2 #1) [ 116.048387] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba [ 116.075750] ESI: 9484965a EDI: 2262af5b EBP: effd0e5c DS: 007b ES: 007b [ 116.103240] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 [ 116.130449] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 [ 116.158078] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 116.185729] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 [ 116.213729] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc [ 116.241689] <c01006c5> kernel_thread_helper+0x5/0xb Looking at the body of ktime_get_ts, I see: do { seq = read_seqbegin(&xtime_lock); getnstimeofday(ts); tomono = wall_to_monotonic; } while (read_seqretry(&xtime_lock, seq)); Which looks like a good place to get hung in a loop for a while.... Eventually (after about 2 minutes, it finally unwedges and continues on. Any ideas? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks @ 2006-06-26 22:50 ` Valdis.Kletnieks 2006-06-26 23:02 ` john stultz ` (2 subsequent siblings) 3 siblings, 0 replies; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-26 22:50 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 6125 bytes --] On Mon, 26 Jun 2006 17:41:07 EDT, Valdis.Kletnieks@vt.edu said: > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer > related. This is at fairly early userspace - the initrd has run, but we're not > into /etc/rc.sysinit yet (although the root filesystem is mounted and we have > a kjournald for it). Poking with sysrq-T and sysrq-R gets me this: > > [ 108.301806] Pid: 4, comm: khelper > [ 108.330565] EIP: 0060:[<c0119f48>] CPU: 0 > [ 108.359315] EIP is at getnstimeofday+0x9e/0xb8 > [ 108.387820] EFLAGS: 00000207 Not tainted (2.6.17-mm2 #1) > [ 108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba > [ 108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b > [ 108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 > [ 108.501579] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 > [ 108.530366] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 > [ 108.559363] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 > [ 108.588523] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc > [ 108.617618] <c01006c5> kernel_thread_helper+0x5/0xb Seems to be a problem with time in general - another reboot, and lots of sysrq-P, and I got these (note that this time around, rc.sysinit *did* get started, so we're apparently just making very slow progress rather than being hung and spinning for 90 seconds.... [ 81.127021] SysRq : Show Regs [ 81.147732] [ 81.168172] Pid: 1, comm: init [ 81.188564] EIP: 0060:[<c0119ffc>] CPU: 0 [ 81.208879] EIP is at do_gettimeofday+0x9a/0xc5 [ 81.229104] EFLAGS: 00000217 Not tainted (2.6.17-mm2 #1) [ 81.249441] EAX: d8ad347c EBX: f380a310 ECX: 66521e65 EDX: 226cbe02 [ 81.270003] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b [ 81.290974] CR0: 8005003b CR2: b7e7f0a8 CR3: 2ffbc000 CR4: 000006d0 [ 81.312250] <c01169ae> sys_time+0xe/0x2f <c0102261> sysenter_past_esp+0x56/0x79 [ 86.545414] SysRq : Show Regs [ 86.566974] [ 86.588290] Pid: 1, comm: init [ 86.609807] EIP: 0060:[<c0119ffc>] CPU: 0 [ 86.631315] EIP is at do_gettimeofday+0x9a/0xc5 [ 86.652737] EFLAGS: 00000213 Not tainted (2.6.17-mm2 #1) [ 86.674312] EAX: 1c0a39da EBX: f380a310 ECX: 56a2f30b EDX: d7a49202 [ 86.696028] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b [ 86.717769] CR0: 8005003b CR2: b7e7f0a8 CR3: 2ffbc000 CR4: 000006d0 [ 86.739558] <c01169ae> sys_time+0xe/0x2f <c0102261> sysenter_past_esp+0x56/0x79 [ 88.427273] SysRq : Show Regs [ 88.449183] [ 88.470683] Pid: 421, comm: rc.sysinit [ 88.492222] EIP: 0060:[<c0119f40>] CPU: 0 [ 88.513633] EIP is at getnstimeofday+0x96/0xb8 [ 88.535030] EFLAGS: 00000283 Not tainted (2.6.17-mm2 #1) [ 88.556511] EAX: efed47bc EBX: efed47bc ECX: 00000000 EDX: 0b16e0d5 [ 88.578361] ESI: b2c0c4bc EDI: 27c01a01 EBP: ef7d5f04 DS: 007b ES: 007b [ 88.600340] CR0: 8005003b CR2: b7e7f0a8 CR3: 2f26d000 CR4: 000006d0 [ 88.622445] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 [ 88.645207] <c0111f3c> do_fork+0x8d/0x16a <c010099b> sys_clone+0x25/0x2a [ 88.668218] <c0102261> sysenter_past_esp+0x56/0x79 [ 94.619871] SysRq : Show Regs [ 94.642631] [ 94.664936] Pid: 421, comm: rc.sysinit [ 94.687452] EIP: 0060:[<c0119f48>] CPU: 0 [ 94.709938] EIP is at getnstimeofday+0x9e/0xb8 [ 94.732370] EFLAGS: 00000203 Not tainted (2.6.17-mm2 #1) [ 94.755031] EAX: efed47bc EBX: efed47bc ECX: 00000000 EDX: 0b16e0d5 [ 94.777989] ESI: cd6d54bc EDI: 179d2144 EBP: ef7d5f04 DS: 007b ES: 007b [ 94.800978] CR0: 8005003b CR2: b7e7f0a8 CR3: 2f26d000 CR4: 000006d0 [ 94.823986] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 [ 94.847793] <c0111f3c> do_fork+0x8d/0x16a <c010099b> sys_clone+0x25/0x2a [ 94.871627] <c0102261> sysenter_past_esp+0x56/0x79 [ 99.793372] SysRq : Show Regs [ 99.816696] [ 99.839669] Pid: 1, comm: init [ 99.862968] EIP: 0060:[<c0119ffc>] CPU: 0 [ 99.886127] EIP is at do_gettimeofday+0x9a/0xc5 [ 99.909505] EFLAGS: 00000213 Not tainted (2.6.17-mm2 #1) [ 99.933139] EAX: bb9074fb EBX: f380a310 ECX: 317e8ecb EDX: c0228802 [ 99.957174] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b [ 99.981281] CR0: 8005003b CR2: b7e7f0a8 CR3: 2ffbc000 CR4: 000006d0 [ 100.005492] <c01169ae> sys_time+0xe/0x2f <c0102261> sysenter_past_esp+0x56/0x79 [ 103.357517] SysRq : Show Regs [ 103.380851] [ 103.403016] Pid: 421, comm: rc.sysinit [ 103.425480] EIP: 0060:[<c0119f48>] CPU: 0 [ 103.447836] EIP is at getnstimeofday+0x9e/0xb8 [ 103.470260] EFLAGS: 00000287 Not tainted (2.6.17-mm2 #1) [ 103.493102] EAX: efed47bc EBX: efed47bc ECX: 00000000 EDX: 0b16e0d5 [ 103.516288] ESI: 09ac3ebc EDI: 00eac4ec EBP: ef7d5f04 DS: 007b ES: 007b [ 103.539636] CR0: 8005003b CR2: b7e7f0a8 CR3: 2f26d000 CR4: 000006d0 [ 103.563122] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 [ 103.587133] <c0111f3c> do_fork+0x8d/0x16a <c010099b> sys_clone+0x25/0x2a [ 103.610981] <c0102261> sysenter_past_esp+0x56/0x79 [ 105.595474] SysRq : Show Regs [ 105.618994] [ 105.641896] Pid: 1, comm: init [ 105.664562] EIP: 0060:[<c0119ffc>] CPU: 0 [ 105.687319] EIP is at do_gettimeofday+0x9a/0xc5 [ 105.710233] EFLAGS: 00000217 Not tainted (2.6.17-mm2 #1) [ 105.733426] EAX: 0b996673 EBX: f380a310 ECX: 1edc1a9c EDX: c769d802 [ 105.756826] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b [ 105.780234] CR0: 8005003b CR2: b7d1f000 CR3: 2ffbc000 CR4: 000006d0 [ 105.803629] <c01169ae> sys_time+0xe/0x2f <c0102261> sysenter_past_esp+0x56/0x79 [ 106.787956] Real Time Clock Driver v1.12ac Every single one doing something time-related. I'm pretty sure that the RTC driver is a red herring - I stuck a 'set -x' in rc.sysinit, and we're moving along nicely by that point - whatever is wedging it has broken loose by that point. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks 2006-06-26 22:50 ` Valdis.Kletnieks @ 2006-06-26 23:02 ` john stultz 2006-06-26 23:27 ` Thomas Gleixner 2006-06-27 10:16 ` Roman Zippel 3 siblings, 0 replies; 93+ messages in thread From: john stultz @ 2006-06-26 23:02 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote: > On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer > related. This is at fairly early userspace - the initrd has run, but we're not > into /etc/rc.sysinit yet (although the root filesystem is mounted and we have > a kjournald for it). Poking with sysrq-T and sysrq-R gets me this: > > [ 108.301806] Pid: 4, comm: khelper > [ 108.330565] EIP: 0060:[<c0119f48>] CPU: 0 > [ 108.359315] EIP is at getnstimeofday+0x9e/0xb8 > [ 108.387820] EFLAGS: 00000207 Not tainted (2.6.17-mm2 #1) > [ 108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba > [ 108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b > [ 108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 > [ 108.501579] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 > [ 108.530366] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 > [ 108.559363] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 > [ 108.588523] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc > [ 108.617618] <c01006c5> kernel_thread_helper+0x5/0xb > [ 115.881903] SysRq : Show Regs > [ 115.910288] > [ 115.938097] Pid: 4, comm: khelper > [ 115.965908] EIP: 0060:[<c0119f48>] CPU: 0 > [ 115.993553] EIP is at getnstimeofday+0x9e/0xb8 > [ 116.020928] EFLAGS: 00000287 Not tainted (2.6.17-mm2 #1) > [ 116.048387] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba > [ 116.075750] ESI: 9484965a EDI: 2262af5b EBP: effd0e5c DS: 007b ES: 007b > [ 116.103240] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 > [ 116.130449] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 > [ 116.158078] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 > [ 116.185729] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 > [ 116.213729] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc > [ 116.241689] <c01006c5> kernel_thread_helper+0x5/0xb > > Looking at the body of ktime_get_ts, I see: > > do { > seq = read_seqbegin(&xtime_lock); > getnstimeofday(ts); > tomono = wall_to_monotonic; > > } while (read_seqretry(&xtime_lock, seq)); > > Which looks like a good place to get hung in a loop for a while.... > > Eventually (after about 2 minutes, it finally unwedges and continues on. > > Any ideas? It does look like something is hogging the xtime_lock. Does this occur w/o HRT enabled? Could you also send me your .config and dmesg please? thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks 2006-06-26 22:50 ` Valdis.Kletnieks 2006-06-26 23:02 ` john stultz @ 2006-06-26 23:27 ` Thomas Gleixner 2006-06-27 2:12 ` Valdis.Kletnieks 2006-06-27 10:16 ` Roman Zippel 3 siblings, 1 reply; 93+ messages in thread From: Thomas Gleixner @ 2006-06-26 23:27 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote: > On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/ > > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer > related. hrtimer is not really involved here. > This is at fairly early userspace - the initrd has run, but we're not > into /etc/rc.sysinit yet (although the root filesystem is mounted and we have > a kjournald for it). Poking with sysrq-T and sysrq-R gets me this: > > [ 108.301806] Pid: 4, comm: khelper > [ 108.330565] EIP: 0060:[<c0119f48>] CPU: 0 > [ 108.359315] EIP is at getnstimeofday+0x9e/0xb8 > [ 108.387820] EFLAGS: 00000207 Not tainted (2.6.17-mm2 #1) > [ 108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba > [ 108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b > [ 108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 > [ 108.501579] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 > [ 108.530366] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 > [ 108.559363] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 > [ 108.588523] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc > [ 108.617618] <c01006c5> kernel_thread_helper+0x5/0xb > [ 115.881903] SysRq : Show Regs > [ 115.910288] > [ 115.938097] Pid: 4, comm: khelper > [ 115.965908] EIP: 0060:[<c0119f48>] CPU: 0 > [ 115.993553] EIP is at getnstimeofday+0x9e/0xb8 > [ 116.020928] EFLAGS: 00000287 Not tainted (2.6.17-mm2 #1) > [ 116.048387] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba > [ 116.075750] ESI: 9484965a EDI: 2262af5b EBP: effd0e5c DS: 007b ES: 007b > [ 116.103240] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0 > [ 116.130449] <c0125c0c> ktime_get_ts+0x14/0x3f <c0110f84> copy_process+0x395/0x1111 > [ 116.158078] <c0111f3c> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 > [ 116.185729] <c0120431> __call_usermodehelper+0x2b/0x44 <c0120982> run_workqueue+0x94/0xe9 > [ 116.213729] <c0120e64> worker_thread+0xe1/0x115 <c01232b2> kthread+0xb0/0xdc > [ 116.241689] <c01006c5> kernel_thread_helper+0x5/0xb > > Looking at the body of ktime_get_ts, I see: > > do { > seq = read_seqbegin(&xtime_lock); > getnstimeofday(ts); > tomono = wall_to_monotonic; > > } while (read_seqretry(&xtime_lock, seq)); >From the stack trace: copy_process: .... do_posix_clock_monotonic_gettime(&p->start_time); #define do_posix_clock_monotonic_gettime(ts) ktime_get_ts(ts) ktime_get_ts() has not been touched since it was merged in 2.6.16 Can you provide the complete boot log up to this point please ? - Preferably over serial console. tglx ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-26 23:27 ` Thomas Gleixner @ 2006-06-27 2:12 ` Valdis.Kletnieks 2006-06-27 5:54 ` Thomas Gleixner 0 siblings, 1 reply; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-27 2:12 UTC (permalink / raw) To: tglx; +Cc: Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 31892 bytes --] On Tue, 27 Jun 2006 01:27:09 +0200, Thomas Gleixner said: > On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote: > > On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6. 17-mm2/ > > > > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer > > related. > > hrtimer is not really involved here. OK, the fact that it was continually in kernel/hrtimer.c was a red herring? :) (2.6.17-mm1 worked OK on this...) > ktime_get_ts() has not been touched since it was merged in 2.6.16 > > Can you provide the complete boot log up to this point please ? - > Preferably over serial console. Can't manage a serial console, you'll have to settle for the dmesg output once we get up and running: [ 0.000000] Linux version 2.6.17-mm2-test (valdis@turing-police.cc.vt.edu) (gcc version 4.1.1 20060619 (Red Hat 4.1.1-5)) #1 PREEMPT Mon Jun 26 20:20:32 EDT 2006 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000002ffe2800 (usable) [ 0.000000] BIOS-e820: 000000002ffe2800 - 0000000030000000 (reserved) [ 0.000000] BIOS-e820: 00000000feda0000 - 00000000fee00000 (reserved) [ 0.000000] BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved) [ 0.000000] 767MB LOWMEM available. [ 0.000000] On node 0 totalpages: 196578 [ 0.000000] DMA zone: 4096 pages, LIFO batch:0 [ 0.000000] Normal zone: 192482 pages, LIFO batch:31 [ 0.000000] DMI 2.3 present. [ 0.000000] ACPI: RSDP (v000 DELL ) @ 0x000fde50 [ 0.000000] ACPI: RSDT (v001 DELL CPi R 0x27d40107 ASL 0x00000061) @ 0x000fde64 [ 0.000000] ACPI: FADT (v001 DELL CPi R 0x27d40107 ASL 0x00000061) @ 0x000fde90 [ 0.000000] ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000 [ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] Allocating PCI resources starting at 40000000 (gap: 30000000:ceda0000) [ 0.000000] Detected 1595.395 MHz processor. [ 17.076049] Built 1 zonelists. Total pages: 196578 [ 17.076053] Kernel command line: console=tty0 vga=794 single [ 17.076524] Local APIC disabled by BIOS -- you can enable it with "lapic" [ 17.076537] mapped APIC to ffffd000 (01603000) [ 17.076543] Enabling fast FPU save and restore... done. [ 17.076547] Enabling unmasked SIMD FPU exception support... done. [ 17.076553] Initializing CPU#0 [ 17.076661] CPU 0 irqstacks, hard=c04ec000 soft=c04eb000 [ 17.076666] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 17.076790] Console: colour dummy device 80x25 [ 17.077842] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 17.079004] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 17.106571] Memory: 773400k/786312k available (2308k kernel code, 12312k reserved, 989k data, 192k init, 0k highmem) [ 17.106585] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 17.166527] Calibrating delay using timer specific routine.. 3192.23 BogoMIPS (lpj=1596116) [ 17.166576] Security Framework v1.0.0 initialized [ 17.166585] SELinux: Initializing. [ 17.166603] SELinux: Starting in permissive mode [ 17.166615] selinux_register_security: Registering secondary module capability [ 17.166623] Capability LSM initialized as secondary [ 17.166642] Mount-cache hash table entries: 512 [ 17.166791] CPU: After generic identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000 [ 17.166805] CPU: After vendor identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000 [ 17.166819] CPU: Trace cache: 12K uops, L1 D cache: 8K [ 17.166825] CPU: L2 cache: 512K [ 17.166830] CPU: After all inits, caps: 3febf9ff 00000000 00000000 00000080 00000000 00000000 00000000 [ 17.166840] Intel machine check architecture supported. [ 17.166850] Intel machine check reporting enabled on CPU#0. [ 17.166857] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available [ 17.166865] CPU0: Thermal monitoring enabled [ 17.166885] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04 [ 17.166899] Checking 'hlt' instruction... OK. [ 17.170623] SMP alternatives: switching to UP code [ 17.170630] Freeing SMP alternatives: 0k freed [ 17.170636] ACPI: Core revision 20060608 [ 17.213523] ACPI: setting ELCR to 0200 (from 0800) [ 17.219183] checking if image is initramfs... it is [ 17.365993] Freeing initrd memory: 1031k freed [ 17.366492] NET: Registered protocol family 16 [ 17.367056] ACPI: ACPI Dock Station Driver [ 17.367520] ACPI: bus type pci registered [ 17.381009] PCI: PCI BIOS revision 2.10 entry at 0xfbfee, last bus=2 [ 17.381016] Setting up standard PCI resources [ 17.411263] ACPI: Interpreter enabled [ 17.411276] ACPI: Using PIC for interrupt routing [ 17.415489] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 17.415503] PCI: Probing PCI hardware (bus 00) [ 17.415912] ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 [ 17.490877] PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO [ 17.490889] PCI quirk: region 0880-08bf claimed by ICH4 GPIO [ 17.490990] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 [ 17.491566] Boot video device is 0000:01:00.0 [ 17.492357] PCI: Transparent bridge - 0000:00:1e.0 [ 17.493327] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 17.643870] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) [ 17.645210] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 [ 17.646534] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) [ 17.647875] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) [ 17.651329] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] [ 17.652545] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] [ 17.655595] ACPI: Power Resource [PADA] (on) [ 17.657068] Linux Plug and Play Support v0.97 (c) Adam Belay [ 17.657090] pnp: PnP ACPI init [ 17.883045] pnp: PnP ACPI: found 17 devices [ 17.883086] Intel 82802 RNG detected [ 17.883685] usbcore: registered new driver usbfs [ 17.883950] usbcore: registered new driver hub [ 17.884558] PCI: Using ACPI for IRQ routing [ 17.884568] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [ 17.927252] pnp: 00:02: ioport range 0x4d0-0x4d1 has been reserved [ 17.927264] pnp: 00:02: ioport range 0x800-0x805 could not be reserved [ 17.927273] pnp: 00:02: ioport range 0x808-0x80f could not be reserved [ 17.927286] pnp: 00:03: ioport range 0x806-0x807 has been reserved [ 17.927295] pnp: 00:03: ioport range 0x810-0x85f could not be reserved [ 17.927303] pnp: 00:03: ioport range 0x860-0x87f has been reserved [ 17.927311] pnp: 00:03: ioport range 0x880-0x8bf has been reserved [ 17.927319] pnp: 00:03: ioport range 0x8c0-0x8df has been reserved [ 17.927326] pnp: 00:03: ioport range 0x8e0-0x8ff has been reserved [ 17.927341] pnp: 00:04: ioport range 0xf000-0xf0fe has been reserved [ 17.927349] pnp: 00:04: ioport range 0xf100-0xf1fe has been reserved [ 17.927370] pnp: 00:04: ioport range 0xf200-0xf2fe has been reserved [ 17.927379] pnp: 00:04: ioport range 0xf400-0xf4fe has been reserved [ 17.927387] pnp: 00:04: ioport range 0xf500-0xf5fe has been reserved [ 17.927396] pnp: 00:04: ioport range 0xf600-0xf6fe has been reserved [ 17.927405] pnp: 00:04: ioport range 0xf800-0xf8fe has been reserved [ 17.927413] pnp: 00:04: ioport range 0xf900-0xf9fe has been reserved [ 17.927431] pnp: 00:09: ioport range 0x900-0x91f has been reserved [ 17.927438] pnp: 00:09: ioport range 0x3f0-0x3f1 has been reserved [ 17.927454] pnp: 00:0f: ioport range 0xbf40-0xbf5f has been reserved [ 17.929718] PCI: Bridge: 0000:00:01.0 [ 17.929729] IO window: c000-cfff [ 17.929740] MEM window: fc000000-fdffffff [ 17.929750] PREFETCH window: d8000000-e7ffffff [ 17.929792] PCI: Bus 3, cardbus bridge: 0000:02:01.0 [ 17.929799] IO window: 0000e000-0000e0ff [ 17.929808] IO window: 0000e400-0000e4ff [ 17.929818] PREFETCH window: 40000000-41ffffff [ 17.929829] MEM window: f4000000-f5ffffff [ 17.929838] PCI: Bus 7, cardbus bridge: 0000:02:01.1 [ 17.929844] IO window: 0000e800-0000e8ff [ 17.929853] IO window: 00001000-000010ff [ 17.929863] PREFETCH window: 42000000-43ffffff [ 17.929873] MEM window: f6000000-f7ffffff [ 17.929882] PCI: Bus 11, cardbus bridge: 0000:02:03.0 [ 17.929888] IO window: 00001400-000014ff [ 17.929897] IO window: 00001800-000018ff [ 17.929907] PREFETCH window: 44000000-45ffffff [ 17.929917] MEM window: fa000000-fbffffff [ 17.929926] PCI: Bridge: 0000:00:1e.0 [ 17.929934] IO window: e000-ffff [ 17.929946] MEM window: f4000000-fbffffff [ 17.929956] PREFETCH window: 40000000-46ffffff [ 17.929991] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 17.930019] PCI: Enabling device 0000:02:01.0 (0000 -> 0003) [ 17.930959] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 [ 17.930967] PCI: setting IRQ 11 as level-triggered [ 17.930973] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [ 17.931011] PCI: Enabling device 0000:02:01.1 (0000 -> 0003) [ 17.931020] ACPI: PCI Interrupt 0000:02:01.1[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [ 17.931055] ACPI: PCI Interrupt 0000:02:03.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [ 17.931103] NET: Registered protocol family 2 [ 17.939416] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 17.939725] TCP established hash table entries: 131072 (order: 7, 524288 bytes) [ 17.940277] TCP bind hash table entries: 65536 (order: 6, 262144 bytes) [ 17.940808] TCP: Hash tables configured (established 131072 bind 65536) [ 17.940816] TCP reno registered [ 17.942193] Machine check exception polling timer started. [ 17.942330] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec. [ 17.954033] audit: initializing netlink socket (disabled) [ 17.954062] audit(1151368037.173:1): initialized [ 17.954290] VFS: Disk quotas dquot_6.5.1 [ 17.954321] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 17.954433] SELinux: Registering netfilter hooks [ 17.960062] Initializing Cryptographic API [ 17.960073] io scheduler noop registered [ 17.960086] io scheduler anticipatory registered (default) [ 17.960096] io scheduler deadline registered [ 17.960113] io scheduler cfq registered [ 17.961187] vesafb: framebuffer at 0xe0000000, mapped to 0xf0880000, using 5120k, total 32768k [ 17.961199] vesafb: mode is 1280x1024x16, linelength=2560, pages=1 [ 17.961206] vesafb: protected mode interface info at c000:e140 [ 17.961213] vesafb: pmi: set display start = c00ce185, set palette = c00ce20a [ 17.961218] vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03 [ 17.961246] vesafb: scrolling: redraw [ 17.961253] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 [ 18.042761] Console: switching to colour frame buffer device 160x64 [ 18.118229] fb0: VESA VGA frame buffer device [ 18.119853] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 18.137796] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds). [ 18.138627] Hangcheck: Using get_cycles(). [ 18.139017] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [ 18.140389] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 18.143041] 00:0d: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 18.145096] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 [ 18.145622] PCI: setting IRQ 5 as level-triggered [ 18.145628] ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [ 18.150711] RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize [ 18.153515] loop: loaded (max 8 devices) [ 18.155121] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [ 18.155653] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 [ 18.156511] 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html [ 18.157184] 0000:02:00.0: 3Com PCI 3c905C Tornado at f0804c00. [ 18.180566] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [ 18.181173] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 18.181949] ICH3M: IDE controller at PCI slot 0000:00:1f.1 [ 18.182459] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) [ 18.183917] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [ 18.184443] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 [ 18.185291] ICH3M: chipset revision 2 [ 18.185626] ICH3M: not 100% native mode: will probe irqs later [ 18.186180] ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:DMA [ 18.186891] ICH3M: too many IDE interfaces, no room in table [ 18.187409] Probing IDE interface ide0... [ 18.450439] hda: FUJITSU MHV2060AH, ATA DISK drive [ 18.857812] hdb: TOSHIBA CD-RW/DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive [ 18.913058] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [ 18.914653] hda: max request size: 128KiB [ 18.945264] hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100) [ 18.950740] hda: cache flushes supported [ 18.951152] hda: hda1 hda2 [ 18.961383] hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) [ 18.962142] Uniform CD-ROM driver Revision: 3.20 [ 18.995085] ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) [ 18.995333] USB Universal Host Controller Interface driver v3.0 [ 19.023273] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 [ 19.051304] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 19.051312] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 19.079265] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 [ 19.106918] uhci_hcd 0000:00:1d.0: irq 11, io base 0x0000bf80 [ 19.134365] usb usb1: new device found, idVendor=0000, idProduct=0000 [ 19.161938] usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 [ 19.189672] usb usb1: Product: UHCI Host Controller [ 19.217323] usb usb1: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd [ 19.244946] usb usb1: SerialNumber: 0000:00:1d.0 [ 19.273170] usb usb1: configuration #1 chosen from 1 choice [ 19.301075] hub 1-0:1.0: USB hub found [ 19.329130] hub 1-0:1.0: 2 ports detected [ 19.457331] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 [ 19.485837] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 19.485845] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 19.514259] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 2 [ 19.542782] uhci_hcd 0000:00:1d.2: irq 11, io base 0x0000bf20 [ 19.570654] usb usb2: new device found, idVendor=0000, idProduct=0000 [ 19.598622] usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 [ 19.626613] usb usb2: Product: UHCI Host Controller [ 19.654475] usb usb2: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd [ 19.682341] usb usb2: SerialNumber: 0000:00:1d.2 [ 19.710556] usb usb2: configuration #1 chosen from 1 choice [ 19.738543] hub 2-0:1.0: USB hub found [ 19.766078] hub 2-0:1.0: 2 ports detected [ 20.099723] usb 2-1: new low speed USB device using uhci_hcd and address 2 [ 20.295519] usb 2-1: new device found, idVendor=045e, idProduct=0023 [ 20.322578] usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0 [ 20.349770] usb 2-1: Product: Microsoft Trackball Optical® [ 20.376744] usb 2-1: Manufacturer: Microsoft [ 20.404665] usb 2-1: configuration #1 chosen from 1 choice [ 20.448492] input: Microsoft Microsoft Trackball Optical® as /class/input/input0 [ 20.475250] input: USB HID v1.00 Mouse [Microsoft Microsoft Trackball Optical®] on usb-0000:00:1d.2-1 [ 20.502548] usbcore: registered new driver usbhid [ 20.529495] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 20.557090] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 20.588872] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 20.616419] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 20.643830] mice: PS/2 mouse device common for all mice [ 20.671744] input: PC Speaker as /class/input/input1 [ 20.703182] input: AT Translated Set 2 keyboard as /class/input/input2 [ 20.729296] i2c /dev entries driver [ 20.756733] device-mapper: ioctl: 4.8.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com [ 20.783167] EDAC MC: Ver: 2.0.0 Jun 26 2006 [ 20.809776] Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC). [ 20.838718] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [ 20.866066] PCI: Setting latency timer of device 0000:00:1f.5 to 64 [ 21.394886] input: DualPoint Stick as /class/input/input3 [ 21.440329] input: AlpsPS/2 ALPS DualPoint TouchPad as /class/input/input4 [ 21.477604] intel8x0_measure_ac97_clock: measured 50992 usecs [ 21.504570] intel8x0: measured clock 96446 rejected [ 21.531559] intel8x0: clocking to 48000 [ 21.561232] ALSA device list: [ 21.587477] #0: Intel 82801CA-ICH3 with CS4205 at 0xd800, irq 5 [ 21.614454] TCP bic registered [ 21.640610] Initializing IPsec netlink socket [ 21.666716] NET: Registered protocol family 1 [ 21.692833] NET: Registered protocol family 10 [ 21.718628] lo: Disabled Privacy Extensions [ 21.744152] IPv6 over IPv4 tunneling driver [ 21.769925] NET: Registered protocol family 17 [ 21.794964] NET: Registered protocol family 15 [ 21.819751] Using IPI Shortcut mode [ 21.844980] Freeing unused kernel memory: 192k freed [ 21.869356] Time: tsc clocksource has been installed. [ 21.893677] Write protecting the kernel read-only data: 406k [ 23.024849] kjournald starting. Commit interval 5 seconds [ 23.047661] EXT3-fs: mounted filesystem with ordered data mode. [ 23.744042] security: 6 users, 5 roles, 1965 types, 81 bools, 1 sens, 256 cats [ 23.766353] security: 58 classes, 123884 rules [ 23.790135] SELinux: Completing initialization. [ 23.811527] SELinux: Setting up existing superblocks. [ 23.887619] SELinux: initialized (dev dm-0, type ext3), uses xattr [ 24.028866] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs [ 24.050014] SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts [ 24.071108] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts [ 24.092316] SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs [ 24.113511] SELinux: initialized (dev devpts, type devpts), uses transition SIDs [ 24.134412] SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts [ 24.155337] SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts [ 24.176033] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs [ 24.196440] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts [ 24.216556] SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts [ 24.236170] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs [ 24.255380] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs [ 24.274225] SELinux: initialized (dev proc, type proc), uses genfs_contexts [ 24.292902] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts [ 24.311432] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts [ 24.330082] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts [ 24.351494] audit(1151368041.674:2): policy loaded auid=4294967295 [ 24.370664] audit(1151368041.666:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security [ 47.325645] SysRq : Show Regs [ 47.346690] [ 47.367719] Pid: 4, comm: khelper [ 47.390642] EIP: 0060:[<c0119ee8>] CPU: 0 [ 47.412044] EIP is at getnstimeofday+0x9e/0xb8 [ 47.433443] EFLAGS: 00000283 Not tainted (2.6.17-mm2-test #1) [ 47.455170] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 47.477049] ESI: 49972cca EDI: aebbd096 EBP: effd0e5c DS: 007b ES: 007b [ 47.499328] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 47.521783] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 47.544819] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 47.567843] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 47.591251] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 47.614703] <c01006c5> kernel_thread_helper+0x5/0xb [ 50.090792] SysRq : Show Regs [ 50.114039] [ 50.137151] Pid: 4, comm: khelper [ 50.162186] EIP: 0060:[<c0119ee8>] CPU: 0 [ 50.185615] EIP is at getnstimeofday+0x9e/0xb8 [ 50.209150] EFLAGS: 00000283 Not tainted (2.6.17-mm2-test #1) [ 50.233053] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 50.257138] ESI: 5e71e8ca EDI: a36f8e9d EBP: effd0e5c DS: 007b ES: 007b [ 50.281259] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 50.305453] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 50.330131] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 50.354773] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 50.379825] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 50.405258] <c01006c5> kernel_thread_helper+0x5/0xb [ 55.545338] SysRq : Show Regs [ 55.569994] [ 55.594154] Pid: 1, comm: init [ 55.618624] EIP: 0060:[<c0119f93>] CPU: 0 [ 55.643037] EIP is at do_gettimeofday+0x91/0xc5 [ 55.667460] EFLAGS: 00000286 Not tainted (2.6.17-mm2-test #1) [ 55.692237] EAX: e22faad7 EBX: 8ef8e1d2 ECX: db50bbaa EDX: 62dc8f7e [ 55.717439] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b [ 55.743054] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 55.768593] <c0116992> sys_time+0xe/0x2f <c0102261> sysenter_past_esp+0x56/0x79 [ 58.448886] SysRq : Show Regs [ 58.474391] [ 58.499617] Pid: 4, comm: khelper [ 58.526676] EIP: 0060:[<c0119ee8>] CPU: 0 [ 58.551892] EIP is at getnstimeofday+0x9e/0xb8 [ 58.577215] EFLAGS: 00000207 Not tainted (2.6.17-mm2-test #1) [ 58.602764] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 58.628351] ESI: 5216c0ca EDI: 7fd02419 EBP: effd0e5c DS: 007b ES: 007b [ 58.654222] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 58.680144] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 58.706517] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 58.732893] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 58.759698] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 58.786851] <c01006c5> kernel_thread_helper+0x5/0xb [ 64.039899] SysRq : Show Regs [ 64.066806] [ 64.093395] Pid: 4, comm: khelper [ 64.122191] EIP: 0060:[<c0119ee8>] CPU: 0 [ 64.149014] EIP is at getnstimeofday+0x9e/0xb8 [ 64.175793] EFLAGS: 00000283 Not tainted (2.6.17-mm2-test #1) [ 64.202650] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 64.229018] ESI: f0575aca EDI: 67ff297e EBP: effd0e5c DS: 007b ES: 007b [ 64.254673] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 64.280580] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 64.307101] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 64.333709] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 64.360724] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 64.388065] <c01006c5> kernel_thread_helper+0x5/0xb [ 67.461531] SysRq : Show Regs [ 67.488572] [ 67.515345] Pid: 4, comm: khelper [ 67.543903] EIP: 0060:[<c0119ee8>] CPU: 0 [ 67.570469] EIP is at getnstimeofday+0x9e/0xb8 [ 67.596952] EFLAGS: 00000207 Not tainted (2.6.17-mm2-test #1) [ 67.623641] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 67.650193] ESI: e3ae9cca EDI: 59fc3768 EBP: effd0e5c DS: 007b ES: 007b [ 67.676652] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 67.702990] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 67.729631] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 67.756234] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 67.783266] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 67.810608] <c01006c5> kernel_thread_helper+0x5/0xb [ 71.047876] SysRq : Show Regs [ 71.074931] [ 71.101725] Pid: 4, comm: khelper [ 71.130292] EIP: 0060:[<c0119ee8>] CPU: 0 [ 71.156873] EIP is at getnstimeofday+0x9e/0xb8 [ 71.183369] EFLAGS: 00000207 Not tainted (2.6.17-mm2-test #1) [ 71.210065] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 71.236614] ESI: ee5cdaca EDI: 4b118ebe EBP: effd0e5c DS: 007b ES: 007b [ 71.263068] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 71.289404] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 71.316037] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 71.342641] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 71.369699] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 71.397075] <c01006c5> kernel_thread_helper+0x5/0xb [ 73.446308] SysRq : Show Regs [ 73.473414] [ 73.500205] Pid: 1, comm: init [ 73.526997] EIP: 0060:[<c0119f93>] CPU: 0 [ 73.553564] EIP is at do_gettimeofday+0x91/0xc5 [ 73.580059] EFLAGS: 00000286 Not tainted (2.6.17-mm2-test #1) [ 73.606786] EAX: 274c0afb EBX: 8ef8e1d2 ECX: cb3967e7 EDX: dd58277e [ 73.633399] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b [ 73.659894] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 73.686698] <c0116992> sys_time+0xe/0x2f <c0102261> sysenter_past_esp+0x56/0x79 [ 76.464785] SysRq : Show Regs [ 76.491801] [ 76.518628] Pid: 4, comm: khelper [ 76.547291] EIP: 0060:[<c0119ee8>] CPU: 0 [ 76.573824] EIP is at getnstimeofday+0x9e/0xb8 [ 76.600283] EFLAGS: 00000287 Not tainted (2.6.17-mm2-test #1) [ 76.626966] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 76.653500] ESI: 447068ca EDI: 3531262b EBP: effd0e5c DS: 007b ES: 007b [ 76.679940] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 76.706240] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 76.732842] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 76.759412] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 76.786408] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 76.813729] <c01006c5> kernel_thread_helper+0x5/0xb [ 79.214850] SysRq : Show Regs [ 79.241901] [ 79.268685] Pid: 4, comm: khelper [ 79.297242] EIP: 0060:[<c0119ee8>] CPU: 0 [ 79.323800] EIP is at getnstimeofday+0x9e/0xb8 [ 79.350280] EFLAGS: 00000283 Not tainted (2.6.17-mm2-test #1) [ 79.376960] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 79.403485] ESI: 585bd6ca EDI: 2a54f33c EBP: effd0e5c DS: 007b ES: 007b [ 79.429916] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 79.456234] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 79.482858] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 79.509452] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 79.536486] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 79.563846] <c01006c5> kernel_thread_helper+0x5/0xb [ 81.520148] SysRq : Show Regs [ 81.547171] [ 81.573927] Pid: 4, comm: khelper [ 81.602450] EIP: 0060:[<c0119ee8>] CPU: 0 [ 81.628985] EIP is at getnstimeofday+0x9e/0xb8 [ 81.655440] EFLAGS: 00000203 Not tainted (2.6.17-mm2-test #1) [ 81.682098] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 81.708598] ESI: 8bd8a4ca EDI: 215de670 EBP: effd0e5c DS: 007b ES: 007b [ 81.734997] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 81.761260] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 81.787828] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 81.814364] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 81.841334] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 81.868611] <c01006c5> kernel_thread_helper+0x5/0xb [ 85.189743] SysRq : Show Regs [ 85.216706] [ 85.243406] Pid: 4, comm: khelper [ 85.271856] EIP: 0060:[<c0119ee8>] CPU: 0 [ 85.298313] EIP is at getnstimeofday+0x9e/0xb8 [ 85.324694] EFLAGS: 00000207 Not tainted (2.6.17-mm2-test #1) [ 85.351280] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 85.377718] ESI: ede792ca EDI: 12898677 EBP: effd0e5c DS: 007b ES: 007b [ 85.404047] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 85.430268] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 85.456795] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 85.483292] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 85.510218] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 85.537472] <c01006c5> kernel_thread_helper+0x5/0xb [ 88.115373] SysRq : Show Regs [ 88.142335] [ 88.169013] Pid: 4, comm: khelper [ 88.197456] EIP: 0060:[<c0119ee8>] CPU: 0 [ 88.223929] EIP is at getnstimeofday+0x9e/0xb8 [ 88.250315] EFLAGS: 00000203 Not tainted (2.6.17-mm2-test #1) [ 88.276932] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408 [ 88.303435] ESI: 809e10ca EDI: 06b30ece EBP: effd0e5c DS: 007b ES: 007b [ 88.329807] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0 [ 88.356469] <c0125bac> ktime_get_ts+0x14/0x3f <c0110f68> copy_process+0x395/0x1111 [ 88.383810] <c0111f20> do_fork+0x8d/0x16a <c0100a27> kernel_thread+0x6c/0x74 [ 88.411220] <c01203d1> __call_usermodehelper+0x2b/0x44 <c0120922> run_workqueue+0x94/0xe9 [ 88.439162] <c0120e04> worker_thread+0xe1/0x115 <c0123252> kthread+0xb0/0xdc [ 88.467114] <c01006c5> kernel_thread_helper+0x5/0xb [ 89.913214] Real Time Clock Driver v1.12ac [ 90.489593] audit(1151368108.794:4): avc: denied { dac_override } for pid=452 comm="dmesg" capability=1 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:dmesg_t:s0 tclass=capability And after that, things move along OK. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-27 2:12 ` Valdis.Kletnieks @ 2006-06-27 5:54 ` Thomas Gleixner 0 siblings, 0 replies; 93+ messages in thread From: Thomas Gleixner @ 2006-06-27 5:54 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel On Mon, 2006-06-26 at 22:12 -0400, Valdis.Kletnieks@vt.edu wrote: > On Tue, 27 Jun 2006 01:27:09 +0200, Thomas Gleixner said: > > On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote: > > > On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6. > 17-mm2/ > > > > > > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer > > > related. > > > > hrtimer is not really involved here. > > OK, the fact that it was continually in kernel/hrtimer.c was a red herring? :) Yup. > [ 24.292902] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts > [ 24.311432] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts > [ 24.330082] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts > [ 24.351494] audit(1151368041.674:2): policy loaded auid=4294967295 > [ 24.370664] audit(1151368041.666:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security <snip> > [ 88.467114] <c01006c5> kernel_thread_helper+0x5/0xb > [ 89.913214] Real Time Clock Driver v1.12ac > [ 90.489593] audit(1151368108.794:4): avc: denied { dac_override } for pid=452 comm="dmesg" capability=1 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:dmesg_t:s0 tclass=capability > > And after that, things move along OK. Hmm, does not help much. Wild guess: Can you turn off CONFIG_RTC and try again ? tglx ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks ` (2 preceding siblings ...) 2006-06-26 23:27 ` Thomas Gleixner @ 2006-06-27 10:16 ` Roman Zippel 2006-06-27 16:43 ` Valdis.Kletnieks 3 siblings, 1 reply; 93+ messages in thread From: Roman Zippel @ 2006-06-27 10:16 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel Hi, On Mon, 26 Jun 2006, Valdis.Kletnieks@vt.edu wrote: > Which looks like a good place to get hung in a loop for a while.... > > Eventually (after about 2 minutes, it finally unwedges and continues on. > > Any ideas? Could you please try the patch below? tv_nsec can shortly become negative, but its absolute value will always be smaller then the current nsec offset. bye, Roman --- kernel/timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c 2006-06-27 11:59:19.000000000 +0200 +++ linux-2.6-mm/kernel/timer.c 2006-06-27 12:10:28.000000000 +0200 @@ -1129,7 +1129,7 @@ static void update_wall_time(void) clocksource_adjust(clock, offset); /* store full nanoseconds into xtime */ - xtime.tv_nsec = clock->xtime_nsec >> clock->shift; + xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift; clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift; /* check to see if there is a new clocksource to use */ ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-27 10:16 ` Roman Zippel @ 2006-06-27 16:43 ` Valdis.Kletnieks 2006-06-27 17:10 ` Roman Zippel 0 siblings, 1 reply; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-27 16:43 UTC (permalink / raw) To: Roman Zippel; +Cc: Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2637 bytes --] On Tue, 27 Jun 2006 12:16:15 +0200, Roman Zippel said: > Could you please try the patch below? > tv_nsec can shortly become negative, but its absolute value will always be > smaller then the current nsec offset. > Index: linux-2.6-mm/kernel/timer.c > =================================================================== > --- linux-2.6-mm.orig/kernel/timer.c 2006-06-27 11:59:19.000000000 +0200 > +++ linux-2.6-mm/kernel/timer.c 2006-06-27 12:10:28.000000000 +0200 > @@ -1129,7 +1129,7 @@ static void update_wall_time(void) > clocksource_adjust(clock, offset); > > /* store full nanoseconds into xtime */ > - xtime.tv_nsec = clock->xtime_nsec >> clock->shift; > + xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift; > clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift; > > /* check to see if there is a new clocksource to use */ Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't fix the problem I'm seeing. I've been doing the mm-bisect polka for a bit, and have it narrowed down to this set of patches: time-clocksource-infrastructure.patch time-clocksource-infrastructure-dont-enable-irq-too-early.patch time-use-clocksource-infrastructure-for-update_wall_time.patch time-use-clocksource-infrastructure-for-update_wall_time-mark-few-functions-as-__init.patch time-let-user-request-precision-from-current_tick_length.patch time-use-clocksource-abstraction-for-ntp-adjustments.patch time-use-clocksource-abstraction-for-ntp-adjustments-optimize-out-some-mults-since-gcc-cant-avoid-them.patch time-introduce-arch-generic-time-accessors.patch hangcheck-remove-monotomic_clock-on-x86.patch time-i386-conversion-part-1-move-timer_pitc-to-i8253c.patch time-i386-conversion-part-2-rework-tsc-support.patch time-i386-conversion-part-3-enable-generic-timekeeping.patch time-i386-conversion-part-4-remove-old-timer_opts-code.patch time-i386-clocksource-drivers.patch time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy.patch time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup.patch time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup-fix-missing-to-rename-pmtmr_good-to-acpi_pm_good.patch time-i386-clocksource-drivers-fix-spelling-typos.patch time-rename-clocksource-functions.patch make-pmtmr_ioport-__read_mostly.patch generic-time-add-macro-to-simplify-hide-mask.patch time-fix-time-going-backward-w-clock=pit.patch fix-and-optimize-clock-source-update.patch Does anybody know offhand if it's safe to bisect through here, or if there's a gotcha along the way? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-27 16:43 ` Valdis.Kletnieks @ 2006-06-27 17:10 ` Roman Zippel 2006-06-27 17:23 ` Roman Zippel 0 siblings, 1 reply; 93+ messages in thread From: Roman Zippel @ 2006-06-27 17:10 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel Hi, On Tue, 27 Jun 2006, Valdis.Kletnieks@vt.edu wrote: > On Tue, 27 Jun 2006 12:16:15 +0200, Roman Zippel said: > > > Could you please try the patch below? > > tv_nsec can shortly become negative, but its absolute value will always be > > smaller then the current nsec offset. > > > Index: linux-2.6-mm/kernel/timer.c > > =================================================================== > > --- linux-2.6-mm.orig/kernel/timer.c 2006-06-27 11:59:19.000000000 +0200 > > +++ linux-2.6-mm/kernel/timer.c 2006-06-27 12:10:28.000000000 +0200 > > @@ -1129,7 +1129,7 @@ static void update_wall_time(void) > > clocksource_adjust(clock, offset); > > > > /* store full nanoseconds into xtime */ > > - xtime.tv_nsec = clock->xtime_nsec >> clock->shift; > > + xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift; > > clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift; > > > > /* check to see if there is a new clocksource to use */ > > Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't > fix the problem I'm seeing. I've been doing the mm-bisect polka for a bit, > and have it narrowed down to this set of patches: I'm afraid the problem is somehow related, in the longer boot log one can see the edi counting down, so I think it's likely in timespec_add_ns(). What's weird is that you can trigger it this easily... bye, Roman ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-27 17:10 ` Roman Zippel @ 2006-06-27 17:23 ` Roman Zippel 2006-06-27 19:07 ` Valdis.Kletnieks 0 siblings, 1 reply; 93+ messages in thread From: Roman Zippel @ 2006-06-27 17:23 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel Hi, On Tue, 27 Jun 2006, Roman Zippel wrote: > On Tue, 27 Jun 2006, Valdis.Kletnieks@vt.edu wrote: > > > Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't > > fix the problem I'm seeing. I've been doing the mm-bisect polka for a bit, > > and have it narrowed down to this set of patches: > > I'm afraid the problem is somehow related, in the longer boot log one can > see the edi counting down, so I think it's likely in timespec_add_ns(). > What's weird is that you can trigger it this easily... Could you please try the patch below? This should better locate which of the values goes wrong. bye, Roman --- kernel/timer.c | 2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c 2006-06-27 19:16:13.000000000 +0200 +++ linux-2.6-mm/kernel/timer.c 2006-06-27 19:17:41.000000000 +0200 @@ -834,6 +834,8 @@ static inline void __get_realtime_clock_ } while (read_seqretry(&xtime_lock, seq)); + if (ts->tv_nsec < 0 || nsecs < 0) + printk("unexpected nsec: %ld,%Ld\n", ts->tv_nsec, nsecs); timespec_add_ns(ts, nsecs); } ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-27 17:23 ` Roman Zippel @ 2006-06-27 19:07 ` Valdis.Kletnieks 2006-06-28 0:07 ` john stultz 0 siblings, 1 reply; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-27 19:07 UTC (permalink / raw) To: Roman Zippel; +Cc: Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2807 bytes --] On Tue, 27 Jun 2006 19:23:53 +0200, Roman Zippel said: I finished bisecting - the problem code is somewhere in fix-and-optimize-clock-source-update.patch (which should narrow things down a bunch). > Could you please try the patch below? This should better locate which of > the values goes wrong. > + if (ts->tv_nsec < 0 || nsecs < 0) > + printk("unexpected nsec: %ld,%Ld\n", ts->tv_nsec, nsecs); > timespec_add_ns(ts, nsecs); I changed it slightly to also do a dump_stack() in case that mattered. I get: [ 22.562394] Time: tsc clocksource has been installed. (Does the clocksource matter here?) [ 25.241589] audit(1151434000.4294965869:2): policy loaded auid=4294967295 [ 25.260931] audit(1151434020.4294967250:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security [ 25.326263] unexpected nsec: -925155963,1574943831 [ 25.346995] <c01031ff> show_trace_log_lvl+0x54/0x174 <c01037bd> show_trace+0xd/0x10 [ 25.368300] <c010385a> dump_stack+0x19/0x1b <c011a4f6> getnstimeofday+0x99/0xd0 [ 25.389785] <c0125428> ktime_get_ts+0x14/0x3f <c0110ba2> copy_process+0x39f/0x10d8 [ 25.411587] <c0111b17> do_fork+0x8d/0x16a <c0100a24> kernel_thread+0x6c/0x74 [ 25.433731] <c011fc35> __call_usermodehelper+0x2b/0x44 <c0120186> run_workqueue+0x94/0xe9 [ 25.456400] <c0120668> worker_thread+0xe1/0x115 <c0122ace> kthread+0xb0/0xdc [ 25.479234] <c01006c5> kernel_thread_helper+0x5/0xb [ 25.551830] unexpected nsec: -347554993,1412474976 [ 25.574337] <c01031ff> show_trace_log_lvl+0x54/0x174 <c01037bd> show_trace+0xd/0x10 [ 25.597459] <c010385a> dump_stack+0x19/0x1b <c011a4f6> getnstimeofday+0x99/0xd0 [ 25.620925] <c0125428> ktime_get_ts+0x14/0x3f <c0110ba2> copy_process+0x39f/0x10d8 [ 25.644923] <c0111b17> do_fork+0x8d/0x16a <c0100998> sys_clone+0x25/0x2a [ 25.669118] <c010224d> sysenter_past_esp+0x56/0x79 [ 25.693213] unexpected nsec: -1276931327,751175871 [ 25.717404] <c01031ff> show_trace_log_lvl+0x54/0x174 <c01037bd> show_trace+0xd/0x10 [ 25.742269] <c010385a> dump_stack+0x19/0x1b <c011a4f6> getnstimeofday+0x99/0xd0 [ 25.767382] <c0125428> ktime_get_ts+0x14/0x3f <c0110ba2> copy_process+0x39f/0x10d8 [ 25.792768] <c0111b17> do_fork+0x8d/0x16a <c0100998> sys_clone+0x25/0x2a [ 25.818386] <c010224d> sysenter_past_esp+0x56/0x79 [ 74.653939] Real Time Clock Driver v1.12ac (Later on, during udev processing, we get: [ 92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2]) [ 92.087122] ACPI: Processor [CPU0] (supports 8 throttling states) [ 92.120270] ACPI: Thermal Zone [THM] (70 C) [ 72.242000] Time: acpi_pm clocksource has been installed. and the timestamps steps back about 20 seconds.... That help any? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-27 19:07 ` Valdis.Kletnieks @ 2006-06-28 0:07 ` john stultz 2006-06-28 10:35 ` Roman Zippel 0 siblings, 1 reply; 93+ messages in thread From: john stultz @ 2006-06-28 0:07 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel On Tue, 2006-06-27 at 15:07 -0400, Valdis.Kletnieks@vt.edu wrote: > On Tue, 27 Jun 2006 19:23:53 +0200, Roman Zippel said: > > I finished bisecting - the problem code is somewhere in > fix-and-optimize-clock-source-update.patch (which should narrow things > down a bunch). Thanks so much for narrowing this down! > > Could you please try the patch below? This should better locate which of > > the values goes wrong. > > > > + if (ts->tv_nsec < 0 || nsecs < 0) > > + printk("unexpected nsec: %ld,%Ld\n", ts->tv_nsec, nsecs); > > timespec_add_ns(ts, nsecs); > > I changed it slightly to also do a dump_stack() in case that mattered. I get: > > [ 22.562394] Time: tsc clocksource has been installed. > > (Does the clocksource matter here?) It might be related. Quick test to check: boot w/ "clocksource=acpi_pm" and let me know if the problem still appears. Then try booting w/ "clocksource=tsc" and see if the system still corrects itself. > [ 25.241589] audit(1151434000.4294965869:2): policy loaded auid=4294967295 > [ 25.260931] audit(1151434020.4294967250:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security > [ 25.326263] unexpected nsec: -925155963,1574943831 Hmm. Yea, the negative xtime nsec value is problematic. However the 1.5 seconds worth of nanoseconds that has accumulated is worrisome as well. > [ 92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2]) > [ 92.087122] ACPI: Processor [CPU0] (supports 8 throttling states) > [ 92.120270] ACPI: Thermal Zone [THM] (70 C) > [ 72.242000] Time: acpi_pm clocksource has been installed. > > and the timestamps steps back about 20 seconds.... Yea, that bit is expected. Basically the cpufreq driver is loading, and when we detect cpufreq changes we mark the TSC as unstable and we fall back to an alternative clocksource (acpi_pm in your case). At the same time, sched_clock sees that the TSC is unstable and it falls back to using jiffies, which causes the small jump in the printk timestamps. Thanks again for the testing and feedback! -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-28 0:07 ` john stultz @ 2006-06-28 10:35 ` Roman Zippel 2006-06-28 11:44 ` Roman Zippel 2006-06-28 23:41 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz 0 siblings, 2 replies; 93+ messages in thread From: Roman Zippel @ 2006-06-28 10:35 UTC (permalink / raw) To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel Hi, On Tue, 27 Jun 2006, john stultz wrote: > > [ 92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2]) > > [ 92.087122] ACPI: Processor [CPU0] (supports 8 throttling states) > > [ 92.120270] ACPI: Thermal Zone [THM] (70 C) > > [ 72.242000] Time: acpi_pm clocksource has been installed. > > > > and the timestamps steps back about 20 seconds.... > > Yea, that bit is expected. Basically the cpufreq driver is loading, and > when we detect cpufreq changes we mark the TSC as unstable and we fall > back to an alternative clocksource (acpi_pm in your case). At the same > time, sched_clock sees that the TSC is unstable and it falls back to > using jiffies, which causes the small jump in the printk timestamps. Frequency changes are IMO currently the most likely reason for this behaviour. If the cpu speeds down too much, the adjustment code might actually attempt to go backwards in time, the old adjustment code might have survived that, because it reacts slower to changes. The patch below should prevent this. Looking through the log file, I noticed other things: [ 17.942330] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec. ... [ 21.869356] Time: tsc clocksource has been installed. The speedstep code uses do_gettimeofday() but there is no real clock source installed, so it gets confused. IMO it would be better to install the PIT timer very early and later avoid switching to tsc at all, if there is any possibility of speed changes. bye, Roman --- include/linux/clocksource.h | 4 +++- kernel/timer.c | 6 ++++++ 2 files changed, 9 insertions(+), 1 deletion(-) Index: linux-2.6-mm/include/linux/clocksource.h =================================================================== --- linux-2.6-mm.orig/include/linux/clocksource.h 2006-06-28 11:53:01.000000000 +0200 +++ linux-2.6-mm/include/linux/clocksource.h 2006-06-28 12:14:30.000000000 +0200 @@ -55,7 +55,7 @@ struct clocksource { int rating; cycle_t (*read)(void); cycle_t mask; - u32 mult; + u32 mult, mult_min; u32 shift; int (*update_callback)(void); int is_continuous; @@ -169,6 +169,8 @@ static inline void clocksource_calculate tmp += c->mult/2; do_div(tmp, c->mult); + c->mult_min = max(c->mult >> 2, 1u); + c->cycle_interval = (cycle_t)tmp; if (c->cycle_interval == 0) c->cycle_interval = 1; Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c 2006-06-28 11:55:12.000000000 +0200 +++ linux-2.6-mm/kernel/timer.c 2006-06-28 12:13:50.000000000 +0200 @@ -1053,6 +1053,12 @@ static __always_inline int clocksource_b if (sign > 0 ? error > *interval : error < *interval) adj++; + if (sign < 0 && unlikely(clock->mult < clock->mult_min + (1 << adj))) { + if (clock->mult <= clock->mult_min) + return 0; + adj = fls(clock->mult - clock->mult_min) - 1; + } + *interval <<= adj; *offset <<= adj; return sign << adj; ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-28 10:35 ` Roman Zippel @ 2006-06-28 11:44 ` Roman Zippel 2006-06-29 23:07 ` Valdis.Kletnieks 2006-06-28 23:41 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz 1 sibling, 1 reply; 93+ messages in thread From: Roman Zippel @ 2006-06-28 11:44 UTC (permalink / raw) To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel Hi, On Wed, 28 Jun 2006, Roman Zippel wrote: > Frequency changes are IMO currently the most likely reason for this > behaviour. If the cpu speeds down too much, the adjustment code might > actually attempt to go backwards in time, the old adjustment code might > have survived that, because it reacts slower to changes. > The patch below should prevent this. Hmm, I've run some simulations and I found that it actually needed some extreme frequency differences to trigger a negative multiplier, but even then it recovered very quickly from it. Valdis, could you please add a call to the function below in __get_realtime_clock_ts() when the problem triggers to print the complete internal clock state. Thanks. bye, Roman --- kernel/timer.c | 7 +++++++ 1 file changed, 7 insertions(+) Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c 2006-06-28 13:30:30.000000000 +0200 +++ linux-2.6-mm/kernel/timer.c 2006-06-28 13:34:43.000000000 +0200 @@ -789,6 +789,13 @@ u64 current_tick_length(void) #include <linux/clocksource.h> static struct clocksource *clock; /* pointer to current clocksource */ +void printk_clock_info(void) +{ + printk("clock %s: m:%u,s:%u,cl:%Lu,ci:%Lu,xn:%Lu,xi:%Lu,e:%Ld\n", + clock->name, clock->mult, clock->shift, clock->cycle_last, clock->cycle_interval, + clock->xtime_nsec, clock->xtime_interval, clock->error); +} + #ifdef CONFIG_GENERIC_TIME /** * __get_nsec_offset - Returns nanoseconds since last call to periodic_hook ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-28 11:44 ` Roman Zippel @ 2006-06-29 23:07 ` Valdis.Kletnieks 2006-06-30 19:26 ` john stultz 0 siblings, 1 reply; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-29 23:07 UTC (permalink / raw) To: Roman Zippel; +Cc: john stultz, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2981 bytes --] On Wed, 28 Jun 2006 13:44:12 +0200, Roman Zippel said: > Valdis, could you please add a call to the function below in > __get_realtime_clock_ts() when the problem triggers to print the complete > internal clock state. Sorry for the delay, I got distracted by other stuff I'm paid to do.. ;) Here's what a test reboot got: 26.578105] audit(1151617213.106:2): policy loaded auid=4294967295 [ 26.597401] audit(1151617213.070:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r :security_t:s0 tclass=security [ 26.683670] unexpected nsec: -840940811,1655512912 [ 26.704096] clock tsc: m:4290198220,s:22,cl:42659140158,ci:1595067,xn:18158513697558798592,xi:18446736466713803524,e:3648592523541009408 [ 26.726249] unexpected nsec: -969254771,1077037877 [ 26.748379] clock tsc: m:4290198222,s:22,cl:42729323106,ci:1595067,xn:17978369712466660208,xi:18446736466716993658,e:4180283123443907584 [ 26.795463] unexpected nsec: -1374919676,1598670381 [ 26.819393] clock tsc: m:4290198248,s:22,cl:42842572863,ci:1595067,xn:17672124937802117152,xi:18446736466758465400,e:5038236766383932416 [ 27.266329] unexpected nsec: -782710824,2549621102 [ 27.291643] clock tsc: m:4290198468,s:22,cl:43597039554,ci:1595067,xn:15690541101761319008,xi:18446736467109380140,e:-7692993275657145344 [ 27.346941] unexpected nsec: -325230283,2119385465 [ 27.373616] clock tsc: m:4290198437,s:22,cl:43727835048,ci:1595067,xn:15348267530081761464,xi:18446736467059933063,e:-6702146452294080512 [ 27.437732] unexpected nsec: -1295951870,2004275512 [ 27.465648] clock tsc: m:4290198398,s:22,cl:43876176279,ci:1595067,xn:14951950762871702254,xi:18446736466997725450,e:-5578375800491670528 [ 27.535596] unexpected nsec: -689435342,2026093159 [ 27.565211] clock tsc: m:4290198355,s:22,cl:44034087912,ci:1595067,xn:14537619597154605516,xi:18446736466929137569,e:-4382097184645369856 [ 27.848139] unexpected nsec: -724490858,2057851911 [ 27.879434] clock tsc: m:4290198101,s:22,cl:44536534017,ci:1595067,xn:13204554107451287893,xi:18446736466523990551,e:-575679729966697472 [ 27.912117] unexpected nsec: -1417871539,554358979 [ 27.944886] clock tsc: m:4290198101,s:22,cl:44641808439,ci:1595067,xn:12934338129808808595,xi:18446736466523990551,e:221869107013499904 [ 37.257357] unexpected nsec: -138785571,1134135898 [ 37.291448] clock tsc: m:3483968852,s:22,cl:59571635559,ci:1595067,xn:12754194144714192038,xi:908396457673218998,e:311350649952236544 [ 42.318566] unexpected nsec: -321935843,935054298 [ 42.353815] clock tsc: m:3080902004,s:22,cl:67660220316,ci:1595067,xn:90071992551050208,xi:4413529548527152531,e:5223654203068061696 [ 47.381773] unexpected nsec: -922994772,489529208 [ 47.418133] clock tsc: m:1738504176,s:22,cl:75750400140,ci:1595067,xn:10700552714632370560,xi:249397886484535734,e:1008065933768526848 [ 107.031802] Real Time Clock Driver v1.12ac That tell you anything? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-29 23:07 ` Valdis.Kletnieks @ 2006-06-30 19:26 ` john stultz 2006-06-30 21:04 ` Valdis.Kletnieks 0 siblings, 1 reply; 93+ messages in thread From: john stultz @ 2006-06-30 19:26 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel On Thu, 2006-06-29 at 19:07 -0400, Valdis.Kletnieks@vt.edu wrote: > On Wed, 28 Jun 2006 13:44:12 +0200, Roman Zippel said: > > > Valdis, could you please add a call to the function below in > > __get_realtime_clock_ts() when the problem triggers to print the complete > > internal clock state. > > Sorry for the delay, I got distracted by other stuff I'm paid to do.. ;) Very much understand :) Thanks for the testing! > Here's what a test reboot got: > > 26.578105] audit(1151617213.106:2): policy loaded auid=4294967295 > [ 26.597401] audit(1151617213.070:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r > :security_t:s0 tclass=security > [ 26.683670] unexpected nsec: -840940811,1655512912 > [ 26.704096] clock tsc: m:4290198220,s:22,cl:42659140158,ci:1595067,xn:18158513697558798592,xi:18446736466713803524,e:3648592523541009408 > That tell you anything? Its a little after the fact (since things have already gone awry), but it does show the multiplier is way out of bound. I suspect the following patch will resolve it. The update callback hasn't kept up with the changes from Roman, and is a bit useless anyway. If the TSC is changing frequency, its unstable and we don't want to use it, so lets just mark it as such and move along. I'll work on a patch to cleanup the update_callback code, but if this resolves the issue, it should be the safe short term fix for 2.6.18. thanks again! -john diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c index 7e0d8da..68d23f0 100644 --- a/arch/i386/kernel/tsc.c +++ b/arch/i386/kernel/tsc.c @@ -348,22 +348,19 @@ static int tsc_update_callback(void) { int change = 0; - /* check to see if we should switch to the safe clocksource: */ - if (clocksource_tsc.rating != 50 && check_tsc_unstable()) { - clocksource_tsc.rating = 50; - clocksource_reselect(); - change = 1; - } - /* only update if tsc_khz has changed: */ if (current_tsc_khz != tsc_khz) { current_tsc_khz = tsc_khz; - clocksource_tsc.mult = clocksource_khz2mult(current_tsc_khz, - clocksource_tsc.shift); - change = 1; + /* TSC is chnaging freq, mark tsc as bad */ + mark_tsc_unstable(); } - return change; + /* check to see if we should switch to the safe clocksource: */ + if (clocksource_tsc.rating != 50 && check_tsc_unstable()) { + clocksource_tsc.rating = 50; + clocksource_reselect(); + } + return 0; } static int __init dmi_mark_tsc_unstable(struct dmi_system_id *d) ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-30 19:26 ` john stultz @ 2006-06-30 21:04 ` Valdis.Kletnieks 2006-07-03 1:13 ` Roman Zippel 0 siblings, 1 reply; 93+ messages in thread From: Valdis.Kletnieks @ 2006-06-30 21:04 UTC (permalink / raw) To: john stultz; +Cc: Roman Zippel, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 931 bytes --] On Fri, 30 Jun 2006 12:26:09 PDT, john stultz said: > Its a little after the fact (since things have already gone awry), but > it does show the multiplier is way out of bound. > > I suspect the following patch will resolve it. The update callback > hasn't kept up with the changes from Roman, and is a bit useless anyway. > If the TSC is changing frequency, its unstable and we don't want to use > it, so lets just mark it as such and move along. > > I'll work on a patch to cleanup the update_callback code, but if this > resolves the issue, it should be the safe short term fix for 2.6.18. *AHA* I *found* the bugger, I think. In kernel/timer.c, we have: static void clocksource_adjust(struct clocksource *clock, s64 offset) (s64 used for offset in multiple places). However, in other places, offset is a 'cycle_t', which is: include/linux/clocksource.h:typedef u64 cycle_t; So it looks like a signed/unsigned screwage. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-30 21:04 ` Valdis.Kletnieks @ 2006-07-03 1:13 ` Roman Zippel 2006-07-03 1:56 ` Daniel Walker 2006-07-05 4:29 ` Valdis.Kletnieks 0 siblings, 2 replies; 93+ messages in thread From: Roman Zippel @ 2006-07-03 1:13 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: john stultz, Andrew Morton, linux-kernel Hi, On Fri, 30 Jun 2006, Valdis.Kletnieks@vt.edu wrote: > *AHA* I *found* the bugger, I think. > > In kernel/timer.c, we have: > > static void clocksource_adjust(struct clocksource *clock, s64 offset) > (s64 used for offset in multiple places). > > However, in other places, offset is a 'cycle_t', which is: > > include/linux/clocksource.h:typedef u64 cycle_t; > > So it looks like a signed/unsigned screwage. It's a possibility, but the signed/unsigned usage is pretty much intentional. The assumptation is that time only goes forward so nothing there should become negative, only adjustments happen in both directions. It's really weird why it's getting completely so out of control early during boot. It would be great if you could also test the patch below, it should trigger closer to when it goes wrong and help to analyze the problem (or at least rule out a number of possibilities). bye, Roman --- kernel/timer.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c +++ linux-2.6-mm/kernel/timer.c @@ -1078,6 +1078,7 @@ static __always_inline int clocksource_b */ static void clocksource_adjust(struct clocksource *clock, s64 offset) { + static int cnt = 16; s64 error, interval = clock->cycle_interval; int adj; @@ -1091,6 +1092,13 @@ static void clocksource_adjust(struct cl } else return; + if ((adj > 10 || adj < -10 || (s32)clock->mult <= -adj) && cnt > 0) { + cnt--; + printk("big adj at %ld (%Lu,%d,%Ld,%Ld)\n", jiffies, current_tick_length(), + adj, interval, offset); + printk_clock_info(); + } + clock->mult += adj; clock->xtime_interval += interval; clock->xtime_nsec -= offset; @@ -1149,9 +1157,15 @@ static void update_wall_time(void) /* check to see if there is a new clocksource to use */ if (change_clocksource()) { + static int cnt = 16; clock->error = 0; clock->xtime_nsec = 0; clocksource_calculate_interval(clock, tick_nsec); + if (cnt > 0) { + cnt--; + printk("clock changed at %ld (%Lu)\n", jiffies, current_tick_length()); + printk_clock_info(); + } } } ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-03 1:13 ` Roman Zippel @ 2006-07-03 1:56 ` Daniel Walker 2006-07-03 2:20 ` Valdis.Kletnieks 2006-07-03 19:59 ` john stultz 2006-07-05 4:29 ` Valdis.Kletnieks 1 sibling, 2 replies; 93+ messages in thread From: Daniel Walker @ 2006-07-03 1:56 UTC (permalink / raw) To: Roman Zippel; +Cc: Valdis.Kletnieks, john stultz, Andrew Morton, linux-kernel On Mon, 2006-07-03 at 03:13 +0200, Roman Zippel wrote: > It's a possibility, but the signed/unsigned usage is pretty much > intentional. The assumptation is that time only goes forward so nothing > there should become negative, only adjustments happen in both directions. > It's really weird why it's getting completely so out of control early > during boot. It would be great if you could also test the patch below, it > should trigger closer to when it goes wrong and help to analyze the > problem (or at least rule out a number of possibilities). I was reviewing these new ntp adjustment functions, and it seems like it would be a lot easier to just switch to a better clocksource. These new functions seems to compensate for a clock that has a high rating but is actually quite poor.. Daniel ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-03 1:56 ` Daniel Walker @ 2006-07-03 2:20 ` Valdis.Kletnieks 2006-07-03 20:08 ` john stultz 2006-07-03 19:59 ` john stultz 1 sibling, 1 reply; 93+ messages in thread From: Valdis.Kletnieks @ 2006-07-03 2:20 UTC (permalink / raw) To: Daniel Walker; +Cc: Roman Zippel, john stultz, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 976 bytes --] On Sun, 02 Jul 2006 18:56:22 PDT, Daniel Walker said: > I was reviewing these new ntp adjustment functions, and it seems like it > would be a lot easier to just switch to a better clocksource. These new > functions seems to compensate for a clock that has a high rating but is > actually quite poor.. It is indeed poor - a few -mm's ago I tripped over a bug that kept it from recognizing the PM timer clocksource, and it refused to NTP sync because the clock drift was well outside the 500 ppm that NTP wants. All the same, it's *one* thing for a clock to be drifting 10 seconds per hour. It's something else to totally explode when handed a drifting clock. Currently, the kernel is build with CONFIG_RTC=m, and the clock starts behaving as soom as rc.sysinit modprobes it. Questions this raises: 1) What's up with *that*? 2) Anybody want to place bets that building with CONFIG_RTC=y will make the clock work right off the bat? 3) Is that a fix, or just wallpaper? :) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-03 2:20 ` Valdis.Kletnieks @ 2006-07-03 20:08 ` john stultz 0 siblings, 0 replies; 93+ messages in thread From: john stultz @ 2006-07-03 20:08 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Daniel Walker, Roman Zippel, Andrew Morton, linux-kernel On Sun, 2006-07-02 at 22:20 -0400, Valdis.Kletnieks@vt.edu wrote: > On Sun, 02 Jul 2006 18:56:22 PDT, Daniel Walker said: > > > I was reviewing these new ntp adjustment functions, and it seems like it > > would be a lot easier to just switch to a better clocksource. These new > > functions seems to compensate for a clock that has a high rating but is > > actually quite poor.. > > It is indeed poor - a few -mm's ago I tripped over a bug that kept it from > recognizing the PM timer clocksource, and it refused to NTP sync because > the clock drift was well outside the 500 ppm that NTP wants. All the same, > it's *one* thing for a clock to be drifting 10 seconds per hour. It's > something else to totally explode when handed a drifting clock. Yes, the TSC is a very poor clocksource. Although its high resolution and very quick access time makes it hard to quit. > Currently, the kernel is build with CONFIG_RTC=m, and the clock starts > behaving as soom as rc.sysinit modprobes it. Questions this raises: > > 1) What's up with *that*? Hmmm. Thats an interesting observation. Let me look to see if maybe something is going oddly in the settimeofday() path. > 2) Anybody want to place bets that building with CONFIG_RTC=y will make > the clock work right off the bat? No bets here, but please let us know if you see any change in behavior. thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-03 1:56 ` Daniel Walker 2006-07-03 2:20 ` Valdis.Kletnieks @ 2006-07-03 19:59 ` john stultz 2006-07-04 22:21 ` Valdis.Kletnieks 1 sibling, 1 reply; 93+ messages in thread From: john stultz @ 2006-07-03 19:59 UTC (permalink / raw) To: Daniel Walker; +Cc: Roman Zippel, Valdis.Kletnieks, Andrew Morton, linux-kernel On Sun, 2006-07-02 at 18:56 -0700, Daniel Walker wrote: > On Mon, 2006-07-03 at 03:13 +0200, Roman Zippel wrote: > I was reviewing these new ntp adjustment functions, and it seems like it > would be a lot easier to just switch to a better clocksource. These new > functions seems to compensate for a clock that has a high rating but is > actually quite poor.. Not quite. The issue is that the adjustment that the ntpd makes is quite fine grained, and some clocksources while quite stable, might not be able to make such a fine adjustment. So the extra error accounting just allows us to keep track and compensate for the resolution differences. Does that make sense? thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-03 19:59 ` john stultz @ 2006-07-04 22:21 ` Valdis.Kletnieks 0 siblings, 0 replies; 93+ messages in thread From: Valdis.Kletnieks @ 2006-07-04 22:21 UTC (permalink / raw) To: john stultz; +Cc: Daniel Walker, Roman Zippel, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 822 bytes --] On Mon, 03 Jul 2006 12:59:43 PDT, john stultz said: > On Sun, 2006-07-02 at 18:56 -0700, Daniel Walker wrote: > > On Mon, 2006-07-03 at 03:13 +0200, Roman Zippel wrote: > > I was reviewing these new ntp adjustment functions, and it seems like it > > would be a lot easier to just switch to a better clocksource. These new > > functions seems to compensate for a clock that has a high rating but is > > actually quite poor.. > > Not quite. The issue is that the adjustment that the ntpd makes is quite > fine grained, and some clocksources while quite stable, might not be > able to make such a fine adjustment. So the extra error accounting just > allows us to keep track and compensate for the resolution differences. > > Does that make sense? Except for the fact that NTP isn't running yet when I see this trouble... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-03 1:13 ` Roman Zippel 2006-07-03 1:56 ` Daniel Walker @ 2006-07-05 4:29 ` Valdis.Kletnieks 2006-07-06 0:37 ` Roman Zippel 2006-07-06 0:51 ` john stultz 1 sibling, 2 replies; 93+ messages in thread From: Valdis.Kletnieks @ 2006-07-05 4:29 UTC (permalink / raw) To: Roman Zippel; +Cc: john stultz, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 25759 bytes --] On Mon, 03 Jul 2006 03:13:39 +0200, Roman Zippel said: > Hi, > > On Fri, 30 Jun 2006, Valdis.Kletnieks@vt.edu wrote: > > > *AHA* I *found* the bugger, I think. > > > > In kernel/timer.c, we have: > > > > static void clocksource_adjust(struct clocksource *clock, s64 offset) > > (s64 used for offset in multiple places). > > > > However, in other places, offset is a 'cycle_t', which is: > > > > include/linux/clocksource.h:typedef u64 cycle_t; > > > > So it looks like a signed/unsigned screwage. > > It's a possibility, but the signed/unsigned usage is pretty much > intentional. The assumptation is that time only goes forward so nothing > there should become negative, only adjustments happen in both directions. > It's really weird why it's getting completely so out of control early > during boot. It would be great if you could also test the patch below, it > should trigger closer to when it goes wrong and help to analyze the > problem (or at least rule out a number of possibilities). Here you go.. For what it's worth, your debugging in clocksource_adjust seems to only pop before we start userspace, and get_realtime_clock_ts only once userspace starts. My speculation about the RTC module turns out to be a red herring - I tried a kernel with it built in, and the problem still manifested and cleared itself early in rc.sysinit. Checking the code there, what seems to matter is that rc.sysinit calls '/sbin/hwclock --hctosys --utc'. Output of 'hwclock --debug': hwclock from util-linux-2.13-pre6 Using /dev/rtc interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2006/07/05 07:57:52 Hw clock time : 2006/07/05 07:57:52 = 1152086272 seconds since 1969 Calling settimeofday: tv.tv_sec = 1152086272, tv.tv_usec = 0 tz.tz_minuteswest = 240 Absolutely nothing edifying there.. The dmesg, with all the suggested patches so far applied. Looks like something starts off uninitialized - we get the first 'big adj' squawk right after we allocate the console - we don't allocate the tsc timesource for another 4 seconds or so. I'll bite - what *am* I using as a timesource for those first 4 seconds? :) [ 0.000000] Linux version 2.6.17-mm2-test (valdis@turing-police.cc.vt.edu) (gcc version 4.1.1 20060629 (Red Hat 4.1.1-6)) #3 PREEMPT Tue Jul 4 18:42:05 EDT 2006 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000002ffe2800 (usable) [ 0.000000] BIOS-e820: 000000002ffe2800 - 0000000030000000 (reserved) [ 0.000000] BIOS-e820: 00000000feda0000 - 00000000fee00000 (reserved) [ 0.000000] BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved) [ 0.000000] 767MB LOWMEM available. [ 0.000000] On node 0 totalpages: 196578 [ 0.000000] DMA zone: 4096 pages, LIFO batch:0 [ 0.000000] Normal zone: 192482 pages, LIFO batch:31 [ 0.000000] DMI 2.3 present. [ 0.000000] ACPI: RSDP (v000 DELL ) @ 0x000fde50 [ 0.000000] ACPI: RSDT (v001 DELL CPi R 0x27d40107 ASL 0x00000061) @ 0x000fde64 [ 0.000000] ACPI: FADT (v001 DELL CPi R 0x27d40107 ASL 0x00000061) @ 0x000fde90 [ 0.000000] ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000 [ 0.000000] ACPI: PM-Timer IO Port: 0x808 [ 0.000000] Allocating PCI resources starting at 40000000 (gap: 30000000:ceda0000) [ 0.000000] Detected 1595.408 MHz processor. [ 24.231372] Built 1 zonelists. Total pages: 196578 [ 24.231376] Kernel command line: console=tty0 vga=794 single [ 24.231839] Local APIC disabled by BIOS -- you can enable it with "lapic" [ 24.231854] mapped APIC to ffffd000 (01603000) [ 24.231860] Enabling fast FPU save and restore... done. [ 24.231864] Enabling unmasked SIMD FPU exception support... done. [ 24.231871] Initializing CPU#0 [ 24.231977] CPU 0 irqstacks, hard=c04e2000 soft=c04e1000 [ 24.231982] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 24.232106] Console: colour dummy device 80x25 [ 24.232202] big adj at -299999 (4294314460971008,128,128,0) [ 24.232214] clock jiffies: m:255960832,s:8,cl:4294667297,ci:1,xn:76031960832,xi:255960832,e:4294967296 [ 24.232983] big adj at -299998 (4294314460971008,64,64,0) [ 24.232996] clock jiffies: m:255960960,s:8,cl:4294667298,ci:1,xn:76287921792,xi:255960960,e:4294967296 [ 24.233231] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 24.233991] big adj at -299997 (4294314460971008,64,64,0) [ 24.234010] clock jiffies: m:255961024,s:8,cl:4294667299,ci:1,xn:76543882816,xi:255961024,e:4294967296 [ 24.234390] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 24.234978] big adj at -299996 (4294314460971008,32,32,0) [ 24.234988] clock jiffies: m:255961088,s:8,cl:4294667300,ci:1,xn:76799843904,xi:255961088,e:3221225472 [ 24.235988] big adj at -299995 (4294314460971008,16,16,0) [ 24.236009] clock jiffies: m:255961120,s:8,cl:4294667301,ci:1,xn:77055805024,xi:255961120,e:2147483648 [ 24.238986] big adj at -299992 (4294314460971008,-32,-32,0) [ 24.239010] clock jiffies: m:255961141,s:8,cl:4294667304,ci:1,xn:77823688441,xi:255961141,e:-771751936 [ 24.239980] big adj at -299991 (4294314460971008,-16,-16,0) [ 24.240001] clock jiffies: m:255961109,s:8,cl:4294667305,ci:1,xn:78079649550,xi:255961109,e:-587202560 [ 24.261902] Memory: 773428k/786312k available (2279k kernel code, 12284k reserved, 981k data, 192k init, 0k highmem) [ 24.261916] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 24.321842] Calibrating delay using timer specific routine.. 3192.23 BogoMIPS (lpj=1596118) [ 24.321890] Security Framework v1.0.0 initialized [ 24.321899] SELinux: Initializing. [ 24.321916] SELinux: Starting in permissive mode [ 24.321930] selinux_register_security: Registering secondary module capability [ 24.321938] Capability LSM initialized as secondary [ 24.321957] Mount-cache hash table entries: 512 [ 24.322102] CPU: After generic identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000 [ 24.322116] CPU: After vendor identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000 [ 24.322130] CPU: Trace cache: 12K uops, L1 D cache: 8K [ 24.322137] CPU: L2 cache: 512K [ 24.322142] CPU: After all inits, caps: 3febf9ff 00000000 00000000 00000080 00000000 00000000 00000000 [ 24.322152] Intel machine check architecture supported. [ 24.322162] Intel machine check reporting enabled on CPU#0. [ 24.322169] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available [ 24.322177] CPU0: Thermal monitoring enabled [ 24.322196] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04 [ 24.322210] Checking 'hlt' instruction... OK. [ 24.325941] SMP alternatives: switching to UP code [ 24.325948] Freeing SMP alternatives: 0k freed [ 24.325953] ACPI: Core revision 20060608 [ 24.369235] ACPI: setting ELCR to 0200 (from 0800) [ 24.374594] checking if image is initramfs... it is [ 24.522694] Freeing initrd memory: 1031k freed [ 24.523169] NET: Registered protocol family 16 [ 24.523769] ACPI: ACPI Dock Station Driver [ 24.523784] ACPI: bus type pci registered [ 24.537296] PCI: PCI BIOS revision 2.10 entry at 0xfbfee, last bus=2 [ 24.537303] Setting up standard PCI resources [ 24.567815] ACPI: Interpreter enabled [ 24.567828] ACPI: Using PIC for interrupt routing [ 24.572140] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 24.572153] PCI: Probing PCI hardware (bus 00) [ 24.572578] ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 [ 24.648477] PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO [ 24.648490] PCI quirk: region 0880-08bf claimed by ICH4 GPIO [ 24.648591] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 [ 24.649169] Boot video device is 0000:01:00.0 [ 24.649943] PCI: Transparent bridge - 0000:00:1e.0 [ 24.650877] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 24.801769] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) [ 24.803130] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 [ 24.804452] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) [ 24.805785] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) [ 24.809149] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] [ 24.810372] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT] [ 24.813313] ACPI: Power Resource [PADA] (on) [ 24.814796] Linux Plug and Play Support v0.97 (c) Adam Belay [ 24.814820] pnp: PnP ACPI init [ 25.042773] pnp: PnP ACPI: found 17 devices [ 25.042817] Intel 82802 RNG detected [ 25.043398] usbcore: registered new driver usbfs [ 25.043657] usbcore: registered new driver hub [ 25.044250] PCI: Using ACPI for IRQ routing [ 25.044259] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [ 25.087170] pnp: 00:02: ioport range 0x4d0-0x4d1 has been reserved [ 25.087181] pnp: 00:02: ioport range 0x800-0x805 could not be reserved [ 25.087189] pnp: 00:02: ioport range 0x808-0x80f could not be reserved [ 25.087202] pnp: 00:03: ioport range 0x806-0x807 has been reserved [ 25.087209] pnp: 00:03: ioport range 0x810-0x85f could not be reserved [ 25.087217] pnp: 00:03: ioport range 0x860-0x87f has been reserved [ 25.087224] pnp: 00:03: ioport range 0x880-0x8bf has been reserved [ 25.087231] pnp: 00:03: ioport range 0x8c0-0x8df has been reserved [ 25.087237] pnp: 00:03: ioport range 0x8e0-0x8ff has been reserved [ 25.087253] pnp: 00:04: ioport range 0xf000-0xf0fe has been reserved [ 25.087261] pnp: 00:04: ioport range 0xf100-0xf1fe has been reserved [ 25.087269] pnp: 00:04: ioport range 0xf200-0xf2fe has been reserved [ 25.087276] pnp: 00:04: ioport range 0xf400-0xf4fe has been reserved [ 25.087283] pnp: 00:04: ioport range 0xf500-0xf5fe has been reserved [ 25.087291] pnp: 00:04: ioport range 0xf600-0xf6fe has been reserved [ 25.087298] pnp: 00:04: ioport range 0xf800-0xf8fe has been reserved [ 25.087306] pnp: 00:04: ioport range 0xf900-0xf9fe has been reserved [ 25.087323] pnp: 00:09: ioport range 0x900-0x91f has been reserved [ 25.087330] pnp: 00:09: ioport range 0x3f0-0x3f1 has been reserved [ 25.087347] pnp: 00:0f: ioport range 0xbf40-0xbf5f has been reserved [ 25.089593] PCI: Bridge: 0000:00:01.0 [ 25.089603] IO window: c000-cfff [ 25.089614] MEM window: fc000000-fdffffff [ 25.089624] PREFETCH window: d8000000-e7ffffff [ 25.089680] PCI: Bus 3, cardbus bridge: 0000:02:01.0 [ 25.089687] IO window: 0000e000-0000e0ff [ 25.089697] IO window: 0000e400-0000e4ff [ 25.089708] PREFETCH window: 40000000-41ffffff [ 25.089719] MEM window: f4000000-f5ffffff [ 25.089729] PCI: Bus 7, cardbus bridge: 0000:02:01.1 [ 25.089735] IO window: 0000e800-0000e8ff [ 25.089745] IO window: 00001000-000010ff [ 25.089755] PREFETCH window: 42000000-43ffffff [ 25.089765] MEM window: f6000000-f7ffffff [ 25.089775] PCI: Bus 11, cardbus bridge: 0000:02:03.0 [ 25.089781] IO window: 00001400-000014ff [ 25.089791] IO window: 00001800-000018ff [ 25.089801] PREFETCH window: 44000000-45ffffff [ 25.089812] MEM window: fa000000-fbffffff [ 25.089821] PCI: Bridge: 0000:00:1e.0 [ 25.089829] IO window: e000-ffff [ 25.089841] MEM window: f4000000-fbffffff [ 25.089852] PREFETCH window: 40000000-46ffffff [ 25.089888] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 25.089916] PCI: Enabling device 0000:02:01.0 (0000 -> 0003) [ 25.090851] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11 [ 25.090860] PCI: setting IRQ 11 as level-triggered [ 25.090865] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [ 25.090903] PCI: Enabling device 0000:02:01.1 (0000 -> 0003) [ 25.090912] ACPI: PCI Interrupt 0000:02:01.1[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [ 25.090947] ACPI: PCI Interrupt 0000:02:03.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 [ 25.090997] NET: Registered protocol family 2 [ 25.100721] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 25.101037] TCP established hash table entries: 131072 (order: 7, 524288 bytes) [ 25.101582] TCP bind hash table entries: 65536 (order: 6, 262144 bytes) [ 25.102109] TCP: Hash tables configured (established 131072 bind 65536) [ 25.102118] TCP reno registered [ 25.103491] Machine check exception polling timer started. [ 25.103629] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec. [ 25.115284] audit: initializing netlink socket (disabled) [ 25.115311] audit(1152053784.178:1): initialized [ 25.115507] VFS: Disk quotas dquot_6.5.1 [ 25.115537] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 25.115658] SELinux: Registering netfilter hooks [ 25.121372] Initializing Cryptographic API [ 25.121385] io scheduler noop registered [ 25.121400] io scheduler anticipatory registered (default) [ 25.121414] io scheduler deadline registered [ 25.121434] io scheduler cfq registered [ 25.122236] vesafb: framebuffer at 0xe0000000, mapped to 0xf0880000, using 5120k, total 32768k [ 25.122249] vesafb: mode is 1280x1024x16, linelength=2560, pages=1 [ 25.122256] vesafb: protected mode interface info at c000:e140 [ 25.122262] vesafb: scrolling: redraw [ 25.122269] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 [ 25.278897] Console: switching to colour frame buffer device 160x64 [ 25.279483] fb0: VESA VGA frame buffer device [ 25.281108] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 25.299034] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds). [ 25.299873] Hangcheck: Using get_cycles(). [ 25.300277] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [ 25.301635] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 25.304229] 00:0d: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [ 25.306284] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5 [ 25.306809] PCI: setting IRQ 5 as level-triggered [ 25.306815] ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [ 25.307648] ACPI: PCI interrupt for device 0000:00:1f.6 disabled [ 25.312431] RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize [ 25.315146] loop: loaded (max 8 devices) [ 25.316718] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11 [ 25.317257] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 [ 25.318098] 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html [ 25.318763] 0000:02:00.0: 3Com PCI 3c905C Tornado at f0804c00. [ 25.342167] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [ 25.342758] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 25.343543] ICH3M: IDE controller at PCI slot 0000:00:1f.1 [ 25.344068] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007) [ 25.345514] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 [ 25.346049] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 [ 25.346888] ICH3M: chipset revision 2 [ 25.347232] ICH3M: not 100% native mode: will probe irqs later [ 25.347780] ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:DMA [ 25.348499] ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:pio, hdd:pio [ 25.349211] Probing IDE interface ide0... [ 25.612743] hda: FUJITSU MHV2060AH, ATA DISK drive [ 26.020116] hdb: TOSHIBA CD-RW/DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive [ 26.075258] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [ 26.076319] Probing IDE interface ide1... [ 26.594608] hda: max request size: 128KiB [ 26.622741] hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100) [ 26.628219] hda: cache flushes supported [ 26.628628] hda: hda1 hda2 [ 26.638796] hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33) [ 26.666022] Uniform CD-ROM driver Revision: 3.20 [ 26.698666] ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) [ 26.698726] USB Universal Host Controller Interface driver v3.0 [ 26.726063] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 [ 26.753390] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 26.753398] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 26.780846] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 [ 26.808385] uhci_hcd 0000:00:1d.0: irq 11, io base 0x0000bf80 [ 26.835528] usb usb1: new device found, idVendor=0000, idProduct=0000 [ 26.862572] usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 [ 26.889563] usb usb1: Product: UHCI Host Controller [ 26.916458] usb usb1: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd [ 26.943542] usb usb1: SerialNumber: 0000:00:1d.0 [ 26.971026] usb usb1: configuration #1 chosen from 1 choice [ 26.998438] hub 1-0:1.0: USB hub found [ 27.025153] hub 1-0:1.0: 2 ports detected [ 27.152792] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 [ 27.180293] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 27.180301] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 27.207849] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 2 [ 27.235744] uhci_hcd 0000:00:1d.2: irq 11, io base 0x0000bf20 [ 27.263385] usb usb2: new device found, idVendor=0000, idProduct=0000 [ 27.290913] usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 [ 27.318344] usb usb2: Product: UHCI Host Controller [ 27.345662] usb usb2: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd [ 27.373143] usb usb2: SerialNumber: 0000:00:1d.2 [ 27.401348] usb usb2: configuration #1 chosen from 1 choice [ 27.429047] hub 2-0:1.0: USB hub found [ 27.456193] hub 2-0:1.0: 2 ports detected [ 27.789215] usb 2-1: new low speed USB device using uhci_hcd and address 2 [ 27.984255] usb 2-1: new device found, idVendor=045e, idProduct=0023 [ 28.010901] usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0 [ 28.037435] usb 2-1: Product: Microsoft Trackball Optical® [ 28.063757] usb 2-1: Manufacturer: Microsoft [ 28.090448] usb 2-1: configuration #1 chosen from 1 choice [ 28.134235] input: Microsoft Microsoft Trackball Optical® as /class/input/input0 [ 28.160854] input: USB HID v1.00 Mouse [Microsoft Microsoft Trackball Optical®] on usb-0000:00:1d.2-1 [ 28.187866] usbcore: registered new driver usbhid [ 28.215125] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 28.242995] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 28.274277] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 28.301472] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 28.328600] mice: PS/2 mouse device common for all mice [ 28.355927] input: PC Speaker as /class/input/input1 [ 28.386381] input: AT Translated Set 2 keyboard as /class/input/input2 [ 28.412351] i2c /dev entries driver [ 28.445100] device-mapper: 4.6.0-ioctl (2006-02-17) initialised: dm-devel@redhat.com [ 28.471229] EDAC MC: Ver: 2.0.0 Jul 4 2006 [ 28.497455] Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC). [ 28.525942] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5 [ 28.552844] PCI: Setting latency timer of device 0000:00:1f.5 to 64 [ 29.081381] input: DualPoint Stick as /class/input/input3 [ 29.126168] input: AlpsPS/2 ALPS DualPoint TouchPad as /class/input/input4 [ 29.163103] intel8x0_measure_ac97_clock: measured 50992 usecs [ 29.190075] intel8x0: measured clock 94563 rejected [ 29.216761] intel8x0: clocking to 48000 [ 29.246297] ALSA device list: [ 29.272438] #0: Intel 82801CA-ICH3 with CS4205 at 0xd800, irq 5 [ 29.299153] TCP bic registered [ 29.325327] Initializing IPsec netlink socket [ 29.351386] NET: Registered protocol family 1 [ 29.377536] NET: Registered protocol family 10 [ 29.403357] lo: Disabled Privacy Extensions [ 29.428765] IPv6 over IPv4 tunneling driver [ 29.454410] NET: Registered protocol family 17 [ 29.479450] NET: Registered protocol family 15 [ 29.504193] Using IPI Shortcut mode [ 29.528533] Time: tsc clocksource has been installed. [ 29.552855] clock changed at -296333 (4294314460971008) [ 29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0 [ 29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712) [ 29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936 [ 29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960) [ 29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320 [ 29.704510] big adj at -296330 (4294314460971008,-8192,-13067599872,-2961899520) [ 29.731241] clock tsc: m:2629481,s:22,cl:47452694348,ci:1595166,xn:580598318408480,xi:4194458688846,e:-41883408859136 [ 29.758931] big adj at -296329 (4294314460971008,262144,418163195904,304081797120) [ 29.786568] clock tsc: m:2621289,s:22,cl:47538833312,ci:1595166,xn:806396399112596,xi:4181391088974,e:647244064829440 [ 29.814707] big adj at -296328 (4294314460971008,-8388608,-13381222268928,-7813787025408) [ 29.843116] clock tsc: m:2883433,s:22,cl:47628162608,ci:1595166,xn:1063667357268644,xi:4599554284878,e:-22744806385192960 [ 29.872317] big adj at -296327 (4294314460971008,1,1595166,446268) [ 29.901485] clock tsc: m:4289462121,s:22,cl:47720682236,ci:1595166,xn:562144401219152,xi:18446735292041567566,e:753587310949187584 [ 29.931755] big adj at -296326 (4294314460971008,1,1595166,1284562) [ 29.962006] clock tsc: m:4289462122,s:22,cl:47814797030,ci:1595166,xn:44026083828728,xi:18446735292043162732,e:1537505019520821248 [ 29.993322] big adj at -296325 (4294314460971008,1,1595166,734154) [ 30.024732] clock tsc: m:4289462123,s:22,cl:47913697322,ci:1595166,xn:18207168308574885266,xi:18446735292044757898,e:2361282850206533632 [ 30.057404] big adj at -296324 (4294314460971008,1,1595166,1013902) [ 30.090153] clock tsc: m:4289462124,s:22,cl:48015787946,ci:1595166,xn:17938170826129443784,xi:18446735292046353064,e:3211634054207305728 [ 30.124811] Freeing unused kernel memory: 192k freed [ 30.158910] Write protecting the kernel read-only data: 402k [ 30.502924] unexpected nsec: -249310867,2962848525 [ 30.534582] clock tsc: m:4289462438,s:22,cl:48778277294,ci:1595166,xn:15924728282382833372,xi:18446735292547235188,e:-8884147731732662272 [ 30.567853] unexpected nsec: -1962978502,1374054342 [ 30.601090] clock tsc: m:4289462436,s:22,cl:48885153416,ci:1595166,xn:15654512304741409624,xi:18446735292544044856,e:-7993970621383804928 [ 78.648061] kjournald starting. Commit interval 5 seconds [ 78.681141] EXT3-fs: mounted filesystem with ordered data mode. [ 79.511997] security: 6 users, 5 roles, 1965 types, 81 bools, 1 sens, 256 cats [ 79.544616] security: 58 classes, 123884 rules [ 79.579276] SELinux: Completing initialization. [ 79.611956] SELinux: Setting up existing superblocks. [ 79.677464] SELinux: initialized (dev dm-0, type ext3), uses xattr [ 79.829815] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs [ 79.863240] SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts [ 79.896423] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts [ 79.929696] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts [ 79.963020] SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs [ 79.996350] SELinux: initialized (dev devpts, type devpts), uses transition SIDs [ 80.028943] SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts [ 80.061259] SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts [ 80.093142] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs [ 80.124561] SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts [ 80.155563] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs [ 80.186435] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs [ 80.216576] SELinux: initialized (dev proc, type proc), uses genfs_contexts [ 80.245849] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts [ 80.274340] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts [ 80.302334] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts [ 80.332660] audit(1152066829.655:2): policy loaded auid=4294967295 [ 80.360059] audit(1152066829.642:3): avc: granted { load_policy } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security [ 81.871761] unexpected nsec: -1188339803,701954360 [ 81.897554] clock tsc: m:1965639796,s:22,cl:130830426002,ci:1595166,xn:17365880163142832508,xi:18446741971357700448,e:-6392280673125578752 [ 129.407146] Real Time Clock Driver v1.12ac [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-05 4:29 ` Valdis.Kletnieks @ 2006-07-06 0:37 ` Roman Zippel 2006-07-06 0:56 ` john stultz 2006-07-06 6:38 ` Valdis.Kletnieks 2006-07-06 0:51 ` john stultz 1 sibling, 2 replies; 93+ messages in thread From: Roman Zippel @ 2006-07-06 0:37 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: john stultz, Andrew Morton, linux-kernel Hi, On Wed, 5 Jul 2006, Valdis.Kletnieks@vt.edu wrote: > I'll bite - what *am* I using as a timesource for those first 4 seconds? :) Jiffies and the first few adjustments are fine, it just compensates for the initial difference between NSEC_PER_JIFFY and TICK_NSEC. > [ 29.528533] Time: tsc clocksource has been installed. > [ 29.552855] clock changed at -296333 (4294314460971008) > [ 29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0 > [ 29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712) > [ 29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936 > [ 29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960) > [ 29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320 Ok, I see now the problem, the last cycle value is always at least 50 times incremented between adjustments and that also means any error adjustment is applied at least 50 times, which quickly gets out of control. Is it possible that your console output is really slow? Otherwise I can't explain these numbers, everything looks initialized fine for a 1.6GHz clock, but it seems to take ages to print a single line. I have to run some tests and later this week there should be a new patch compensating for this. John, now I also know why your version survived this, it did the error correction in the update loop, this kept error small, but it also caused the time to jump around, since it changed the multiplier in the past. bye, Roman ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 0:37 ` Roman Zippel @ 2006-07-06 0:56 ` john stultz 2006-07-06 6:38 ` Valdis.Kletnieks 1 sibling, 0 replies; 93+ messages in thread From: john stultz @ 2006-07-06 0:56 UTC (permalink / raw) To: Roman Zippel; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel On Thu, 2006-07-06 at 02:37 +0200, Roman Zippel wrote: > Hi, > > On Wed, 5 Jul 2006, Valdis.Kletnieks@vt.edu wrote: > > [ 29.528533] Time: tsc clocksource has been installed. > > [ 29.552855] clock changed at -296333 (4294314460971008) > > [ 29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0 > > [ 29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712) > > [ 29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936 > > [ 29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960) > > [ 29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320 > > Ok, I see now the problem, the last cycle value is always at least 50 > times incremented between adjustments and that also means any error > adjustment is applied at least 50 times, which quickly gets out of > control. > Is it possible that your console output is really slow? Otherwise I can't > explain these numbers, everything looks initialized fine for a 1.6GHz > clock, but it seems to take ages to print a single line. Dang! You beat me to the analysis :) I think we're on the same page here. > I have to run some tests and later this week there should be a new patch > compensating for this. Look forward to it. > John, now I also know why your version survived this, it did the error > correction in the update loop, this kept error small, but it also caused > the time to jump around, since it changed the multiplier in the past. Yep, agreed. thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 0:37 ` Roman Zippel 2006-07-06 0:56 ` john stultz @ 2006-07-06 6:38 ` Valdis.Kletnieks 1 sibling, 0 replies; 93+ messages in thread From: Valdis.Kletnieks @ 2006-07-06 6:38 UTC (permalink / raw) To: Roman Zippel; +Cc: john stultz, Andrew Morton, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1905 bytes --] On Thu, 06 Jul 2006 02:37:25 +0200, Roman Zippel said: > Ok, I see now the problem, the last cycle value is always at least 50 > times incremented between adjustments and that also means any error > adjustment is applied at least 50 times, which quickly gets out of > control. > Is it possible that your console output is really slow? Otherwise I can't > explain these numbers, everything looks initialized fine for a 1.6GHz > clock, but it seems to take ages to print a single line. Oh.. this is a real Homer Simpson moment.... "D'Oh!" :) The grub definition: title 2.6.17-mm2 testing kernel /vmlinuz-2.6.17-mm2-test single console=tty0 vga=794 initrd /initrd-selinux.img Yes, this laptop has a real actual DB-9 serial port on the back, and I've had it defined as a console for forever (since trying to debug a problem against 2.5.60 or so). So maybe that's where it's coming from. But a quick boot test or 3 shows the console=tty0 isn't the problem. It turns out to be the 'vga=794', which selects this mode: [ 16.633604] Console: colour dummy device 80x25 [ 17.685983] Console: switching to colour frame buffer device 160x64 And we promptly get a timing problem. I tried booting with 'vga=ask' and choosing mode 1, and got this mode instead: [ 31.003715] Console: colour VGA+ 80x50 And things came up fine at that point. Apparently, trying to scroll a big 160x64 is sufficiently slower than scrolling an 80x50 to trigger the problem. I'd look at John's patch in the morning: > Implement P-D control for clocksource_adjust() > diff --git a/kernel/timer.c b/kernel/timer.c > index 396a3c0..f4e7681 100644 > --- a/kernel/timer.c > +++ b/kernel/timer.c > @@ -1007,81 +1007,108 @@ static int __init timekeeping_init_devic Too many 2:30AM's in the past 2 weeks for a guy my age.. (Actually, the 2:30AM isn't the problem - it's the office hours 7 hours later. ;) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-05 4:29 ` Valdis.Kletnieks 2006-07-06 0:37 ` Roman Zippel @ 2006-07-06 0:51 ` john stultz 2006-07-06 1:12 ` john stultz 2006-07-06 20:33 ` Roman Zippel 1 sibling, 2 replies; 93+ messages in thread From: john stultz @ 2006-07-06 0:51 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel On Wed, 2006-07-05 at 00:29 -0400, Valdis.Kletnieks@vt.edu wrote: > On Mon, 03 Jul 2006 03:13:39 +0200, Roman Zippel said: > > Hi, > > > > On Fri, 30 Jun 2006, Valdis.Kletnieks@vt.edu wrote: > > > > > *AHA* I *found* the bugger, I think. > > > > > > In kernel/timer.c, we have: > > > > > > static void clocksource_adjust(struct clocksource *clock, s64 offset) > > > (s64 used for offset in multiple places). > > > > > > However, in other places, offset is a 'cycle_t', which is: > > > > > > include/linux/clocksource.h:typedef u64 cycle_t; > > > > > > So it looks like a signed/unsigned screwage. > > > > It's a possibility, but the signed/unsigned usage is pretty much > > intentional. The assumptation is that time only goes forward so nothing > > there should become negative, only adjustments happen in both directions. > > It's really weird why it's getting completely so out of control early > > during boot. It would be great if you could also test the patch below, it > > should trigger closer to when it goes wrong and help to analyze the > > problem (or at least rule out a number of possibilities). > > Here you go.. For what it's worth, your debugging in clocksource_adjust seems > to only pop before we start userspace, and get_realtime_clock_ts only once > userspace starts. Once again, thanks for the testing! My observations below... > The dmesg, with all the suggested patches so far applied. Looks like something > starts off uninitialized - we get the first 'big adj' squawk right after we > allocate the console - we don't allocate the tsc timesource for another 4 > seconds or so. > > I'll bite - what *am* I using as a timesource for those first 4 seconds? :) The jiffies clocksource. > [ 0.000000] Detected 1595.408 MHz processor. ... >[ 24.322196] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04 ... > [ 29.528533] Time: tsc clocksource has been installed. > [ 29.552855] clock changed at -296333 (4294314460971008) > [ 29.577109] clock tsc: m:2628985,s:22,cl: ,ci:1595166,xn:0,xi:4193667486510,e:0 Ok, so here's our initial TSC state: Verify the mult/shift pair: 2^s/m = 2^22/2628985 = 1.595408113777750729 cyc/ns => 1.595 GHz Verify the cycle_interval/xtime_interval pair: xi = ci*m = 1595166 * 2628985 = 4193667486510 Convert xi to ns: xi>>s = 4193667486510>>22 = 999848.2433581352234 ns/interval Convert ntp_tick to ns: ntp_tick>>32 = 4294314460971008>>32 = 999848 ns/tick Ok, that all looks pretty good... > [ 29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712) > [ 29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936 Now here's where things turn odd. Note that only one jiffy has passed (-296332 - -296333 = 1). However, looking at the difference between cycle_last: 47288392250 - 47171945132 = 116,447,118 That's *way* larger then the 1,595,166 value expected in ci! Same thing is seen in the later data points: 47452694348 - 47368150550 = 84,543,798 47538833312 - 47452694348 = 86,138,964 etc. So it seems either something is causing you to take interrupts at a lower frequency then what is expected, or your cpu is ~50x faster then advertised :) This is probably not an issue w/ the timekeeping code, however as a side-effect it appears to make the clocksource_adjust function oscillate pretty severely. I've reproduced a similar hang (not completely sure, as it occurred while X was loading) by adding the following to the top of update_wall_time: static int droptick; if(droptick++%60) return; Roman: While I'm not 100% confident about my assessment above, I worry this is mimicking the problems I had been seeing in my simulator w/ your clocksource_adjustment algorithm when I simulated dropping many ticks. While currently this behavior points to some other problem, with the dynticks patch, its much more likely that we will see 100s of ticks skipped. I quickly revived my P-D adjustment patch and it does not appear to suffer from the same problem with the above droptick change (although its only been lightly tested). I realize you may have a more trivial change to this issue, but would you consider my method again? Vladis: Mind trying the following patch to see if it affects the behavior. thanks -john Implement P-D control for clocksource_adjust() diff --git a/kernel/timer.c b/kernel/timer.c index 396a3c0..f4e7681 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1007,81 +1007,108 @@ static int __init timekeeping_init_devic device_initcall(timekeeping_init_device); -/* - * If the error is already larger, we look ahead another tick, - * to compensate for late or lost adjustments. - */ -static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset) +static int error_aproximation(u64 error, u64 unit, int max) { - int adj; - - /* - * As soon as the machine is synchronized to the external time - * source this should be the common case. - */ - error >>= 2; - if (likely(sign > 0 ? error <= *interval : error >= *interval)) - return sign; - - /* - * An extra look ahead dampens the effect of the current error, - * which can grow quite large with continously late updates, as - * it would dominate the adjustment value and can lead to - * oscillation. - */ - error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1); - error -= clock->xtime_interval >> 1; - - adj = 0; + int adj = 0; while (1) { error >>= 1; - if (sign > 0 ? error <= *interval : error >= *interval) - break; - adj++; + if (error <= unit) + return adj; + if (!max || adj < max) + adj++; } - - /* - * Add the current adjustments to the error and take the offset - * into account, the latter can cause the error to be hardly - * reduced at the next tick. Check the error again if there's - * room for another adjustment, thus further reducing the error - * which otherwise had to be corrected at the next update. - */ - error = (error << 1) - *interval + *offset; - if (sign > 0 ? error > *interval : error < *interval) - adj++; - - *interval <<= adj; - *offset <<= adj; - return sign << adj; } +#define MAXOFFADJ 4 /* vary max oscillation vs convergance speed */ /* * Adjust the multiplier to reduce the error value, * this is optimized for the most common adjustments of -1,0,1, * for other values we can do a bit more work. */ -static void clocksource_adjust(struct clocksource *clock, s64 offset) +static void clocksource_adjust(struct clocksource *clock, s64 offset, + s64 interval_cycs, s64 interval_error) { s64 error, interval = clock->cycle_interval; - int adj; - - error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1); - if (error > interval) { - adj = clocksource_bigadjust(1, error, &interval, &offset); - } else if (error < -interval) { - interval = -interval; - offset = -offset; - adj = clocksource_bigadjust(-1, error, &interval, &offset); - } else - return; + + error = shift_right(clock->error, (TICK_LENGTH_SHIFT - clock->shift)); + interval_error = shift_right(interval_error, + (TICK_LENGTH_SHIFT - clock->shift)); + + if ((error > interval) + ||(error < -(interval)) ) { + + int adj, multadj = 0; + s64 offset_update = 0, snsec_update = 0; + + /* First do the frequency adjustment: + * The idea here is to look at the error + * accumulated since the last call to + * update_wall_time to determine the + * frequency adjustment needed so no new + * error will be incurred in the next + * interval. + * + * This is basically derivative control + * using the PID terminology (we're calculating + * the derivative of the slope and correcting it). + * + * The math is basically: + * multadj = interval_error/interval_cycles + * Which we fudge using binary approximation. + */ + if(interval_error >= 0) { + adj = error_aproximation(interval_error, + interval_cycs, 0); + multadj += 1 << adj; + snsec_update += interval << adj; + offset_update += offset << adj; + } else { + adj = error_aproximation(-interval_error, + interval_cycs, 0); + multadj -= 1 << adj; + snsec_update -= interval << adj; + offset_update -= offset << adj; + } + /* Now do the offset adjustment: + * Now that the frequncy is fixed, we + * want to look at the total error accumulated + * to move us back in sync using the same method. + * However, we must be careful as if we make too + * sudden an adjustment we might overshoot. So we + * limit the amount of change to spread the + * adjustment (using MAXOFFADJ) over a longer + * period of time. + * + * This is basically proportional control + * using the PID terminology. + * + * We use interval_cycs here as the divisor, which + * hopes that the next sample will be similar in + * distance from the last. + */ + if(error >= 0) { + adj = error_aproximation(error, + interval_cycs, MAXOFFADJ); + multadj += 1<<adj; + snsec_update += interval <<adj; + offset_update += offset << adj; + } else { + adj = error_aproximation(-error, + interval_cycs, MAXOFFADJ); + multadj -= 1<<adj; + snsec_update -= interval <<adj; + offset_update -= offset << adj; + } - clock->mult += adj; - clock->xtime_interval += interval; - clock->xtime_nsec -= offset; - clock->error -= (interval - offset) << (TICK_LENGTH_SHIFT - clock->shift); + clock->mult += multadj; + clock->xtime_interval += snsec_update; + clock->xtime_nsec -= offset_update; + clock->error += (offset_update) + << (TICK_LENGTH_SHIFT - clock->shift); + } } + /* * update_wall_time - Uses the current clocksource to increment the wall time * @@ -1089,7 +1116,8 @@ static void clocksource_adjust(struct cl */ static void update_wall_time(void) { - cycle_t offset; + cycle_t offset, interval_cycs = 0; + s64 interval_error = 0; clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift; @@ -1106,8 +1134,13 @@ static void update_wall_time(void) /* accumulate one interval */ clock->xtime_nsec += clock->xtime_interval; clock->cycle_last += clock->cycle_interval; + interval_cycs += clock->cycle_interval; offset -= clock->cycle_interval; + /* accumulate error between NTP and clock interval */ + interval_error += current_tick_length(); + interval_error -= clock->xtime_interval << (TICK_LENGTH_SHIFT - clock->shift); + if (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) { clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift; xtime.tv_sec++; @@ -1119,14 +1152,10 @@ static void update_wall_time(void) >> clock->shift); /* increment the NTP state machine */ update_ntp_one_tick(); - - /* accumulate error between NTP and clock interval */ - clock->error += current_tick_length(); - clock->error -= clock->xtime_interval << (TICK_LENGTH_SHIFT - clock->shift); } - + clock->error += interval_error; /* correct the clock when NTP error is too big */ - clocksource_adjust(clock, offset); + clocksource_adjust(clock, offset, interval_cycs, interval_error); /* store full nanoseconds into xtime */ xtime.tv_nsec = clock->xtime_nsec >> clock->shift; ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 0:51 ` john stultz @ 2006-07-06 1:12 ` john stultz 2006-07-06 5:43 ` john stultz 2006-07-06 20:33 ` Roman Zippel 1 sibling, 1 reply; 93+ messages in thread From: john stultz @ 2006-07-06 1:12 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel On Wed, 2006-07-05 at 17:51 -0700, john stultz wrote: > I quickly revived my P-D adjustment patch and it does not appear to > suffer from the same problem with the above droptick change (although > its only been lightly tested). > > I realize you may have a more trivial change to this issue, but would > you consider my method again? > > Vladis: Mind trying the following patch to see if it affects the > behavior. Bah! Never mind. Don't bother, trying it. Of course, only after I send the mail, the same problem reproduces itself w/ my patch! grumble. -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 1:12 ` john stultz @ 2006-07-06 5:43 ` john stultz 0 siblings, 0 replies; 93+ messages in thread From: john stultz @ 2006-07-06 5:43 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel On Wed, 2006-07-05 at 18:12 -0700, john stultz wrote: > On Wed, 2006-07-05 at 17:51 -0700, john stultz wrote: > > I quickly revived my P-D adjustment patch and it does not appear to > > suffer from the same problem with the above droptick change (although > > its only been lightly tested). > > > > I realize you may have a more trivial change to this issue, but would > > you consider my method again? > > > > Vladis: Mind trying the following patch to see if it affects the > > behavior. > > Bah! Never mind. Don't bother, trying it. I take that back. :) Vladis, would you still try that patch to see if it helps? > Of course, only after I send the mail, the same problem reproduces > itself w/ my patch! In my rush to finish up for dinner, I fat-fingered the droptick code (forgot the static!) so I wasn't ever get timer ticks. :( Then after I fixed that, I noticed long-ish stalls starting X or switching between X and VT consoles. However after digging into it I realized the issue is that xtime is only being updated every 100 ticks, and nanosleep used xtime (via hrtimers), so it was getting the extra 100tick latency on every call. So just to be fair, I double checked the following patch against mainline, saw the hang Vladis was seeing, then applied it to my earlier patch along with this patch and the system booted fine w/ no stalls. thanks -john Patch to trigger the boot hang against vanilla 2.6.18-rc1 diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index d17766d..3f516f6 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -132,7 +132,7 @@ static void hrtimer_get_softirq_time(str do { seq = read_seqbegin(&xtime_lock); - xtim = timespec_to_ktime(xtime); + xtim = ktime_get_real(); tomono = timespec_to_ktime(wall_to_monotonic); } while (read_seqretry(&xtime_lock, seq)); diff --git a/kernel/timer.c b/kernel/timer.c index 396a3c0..5394104 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1090,6 +1090,9 @@ static void clocksource_adjust(struct cl static void update_wall_time(void) { cycle_t offset; + static int droptick; + if(droptick++%100) + return; clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift; ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 0:51 ` john stultz 2006-07-06 1:12 ` john stultz @ 2006-07-06 20:33 ` Roman Zippel 2006-07-06 22:05 ` john stultz 1 sibling, 1 reply; 93+ messages in thread From: Roman Zippel @ 2006-07-06 20:33 UTC (permalink / raw) To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel Hi, On Wed, 5 Jul 2006, john stultz wrote: > Roman: While I'm not 100% confident about my assessment above, I worry > this is mimicking the problems I had been seeing in my simulator w/ your > clocksource_adjustment algorithm when I simulated dropping many ticks. > While currently this behavior points to some other problem, with the > dynticks patch, its much more likely that we will see 100s of ticks > skipped. > > I quickly revived my P-D adjustment patch and it does not appear to > suffer from the same problem with the above droptick change (although > its only been lightly tested). The PID concept had me confused for a while and I'm still not sure it really applies, but there are similarities and what I want to do is not that different from yours (limiting then the effect of the current error) with the biggest difference that I keep everything in the big adjust function, so the extra work is only done when needed. > + int adj, multadj = 0; > + s64 offset_update = 0, snsec_update = 0; > + > + /* First do the frequency adjustment: > + * The idea here is to look at the error > + * accumulated since the last call to > + * update_wall_time to determine the > + * frequency adjustment needed so no new > + * error will be incurred in the next > + * interval. > + * > + * This is basically derivative control > + * using the PID terminology (we're calculating > + * the derivative of the slope and correcting it). > + * > + * The math is basically: > + * multadj = interval_error/interval_cycles > + * Which we fudge using binary approximation. > + */ > + if(interval_error >= 0) { > + adj = error_aproximation(interval_error, > + interval_cycs, 0); > + multadj += 1 << adj; > + snsec_update += interval << adj; > + offset_update += offset << adj; > + } else { > + adj = error_aproximation(-interval_error, > + interval_cycs, 0); > + multadj -= 1 << adj; > + snsec_update -= interval << adj; > + offset_update -= offset << adj; > + } Here we actually don't derive very much, we already know how it will change. :) We basically want to keep the difference between tick length and xtime interval as small as possible. Since most of the difference comes via second_overflow(), we might want to do some precalculations near there, so we avoid accumulating a lot of error in the first place, this is especially important with only rare updates. > + /* Now do the offset adjustment: > + * Now that the frequncy is fixed, we > + * want to look at the total error accumulated > + * to move us back in sync using the same method. > + * However, we must be careful as if we make too > + * sudden an adjustment we might overshoot. So we > + * limit the amount of change to spread the > + * adjustment (using MAXOFFADJ) over a longer > + * period of time. > + * > + * This is basically proportional control > + * using the PID terminology. > + * > + * We use interval_cycs here as the divisor, which > + * hopes that the next sample will be similar in > + * distance from the last. > + */ > + if(error >= 0) { > + adj = error_aproximation(error, > + interval_cycs, MAXOFFADJ); > + multadj += 1<<adj; > + snsec_update += interval <<adj; > + offset_update += offset << adj; > + } else { > + adj = error_aproximation(-error, > + interval_cycs, MAXOFFADJ); > + multadj -= 1<<adj; > + snsec_update -= interval <<adj; > + offset_update -= offset << adj; > + } The limitation avoids the biggest problems, but it also may slow down the error reduction (the more the bigger the shift value is). The main problem is really that we don't know how many ticks will be skipped and with interval_cycs you only know what happened last and this won't help if ticks are skipped in irregular intervals. Regarding dynticks it would help a lot here to know how many ticks are skipped so you can spread the error correction evenly over this period until the next adjustment and the correction is stopped in time. bye, Roman ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 20:33 ` Roman Zippel @ 2006-07-06 22:05 ` john stultz 2006-07-07 23:16 ` Roman Zippel 2006-07-08 20:02 ` [PATCH] adjust clock for lost ticks Roman Zippel 0 siblings, 2 replies; 93+ messages in thread From: john stultz @ 2006-07-06 22:05 UTC (permalink / raw) To: Roman Zippel; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel On Thu, 2006-07-06 at 22:33 +0200, Roman Zippel wrote: > Hi, > > On Wed, 5 Jul 2006, john stultz wrote: > > > Roman: While I'm not 100% confident about my assessment above, I worry > > this is mimicking the problems I had been seeing in my simulator w/ your > > clocksource_adjustment algorithm when I simulated dropping many ticks. > > While currently this behavior points to some other problem, with the > > dynticks patch, its much more likely that we will see 100s of ticks > > skipped. > > > > I quickly revived my P-D adjustment patch and it does not appear to > > suffer from the same problem with the above droptick change (although > > its only been lightly tested). > > The PID concept had me confused for a while and I'm still not sure it > really applies, but there are similarities and what I want to do is not > that different from yours (limiting then the effect of the current error) > with the biggest difference that I keep everything in the big adjust > function, so the extra work is only done when needed. Yea. I've been trying to map your method to the PID concept as well (when all you have is a hammer... ;) and they are similar, however the "future error" aspect of yours makes it a little more difficult to grasp, but it is more compact. > > + int adj, multadj = 0; > > + s64 offset_update = 0, snsec_update = 0; > > + > > + /* First do the frequency adjustment: > > + * The idea here is to look at the error > > + * accumulated since the last call to > > + * update_wall_time to determine the > > + * frequency adjustment needed so no new > > + * error will be incurred in the next > > + * interval. > > + * > > + * This is basically derivative control > > + * using the PID terminology (we're calculating > > + * the derivative of the slope and correcting it). > > + * > > + * The math is basically: > > + * multadj = interval_error/interval_cycles > > + * Which we fudge using binary approximation. > > + */ > > + if(interval_error >= 0) { > > + adj = error_aproximation(interval_error, > > + interval_cycs, 0); > > + multadj += 1 << adj; > > + snsec_update += interval << adj; > > + offset_update += offset << adj; > > + } else { > > + adj = error_aproximation(-interval_error, > > + interval_cycs, 0); > > + multadj -= 1 << adj; > > + snsec_update -= interval << adj; > > + offset_update -= offset << adj; > > + } > > Here we actually don't derive very much, we already know how it will > change. :) Correct, by looking one step ahead in your method that's where you're taking the derivative into effect. Although keeping this future reference does require some extra mental gymnastics for me. > We basically want to keep the difference between tick length and xtime > interval as small as possible. Since most of the difference comes via > second_overflow(), we might want to do some precalculations near there, so > we avoid accumulating a lot of error in the first place, this is > especially important with only rare updates. I don't think I disagree here, I can see how looking ahead in the future is helpful to correct for error when the adjustment changes. > > + /* Now do the offset adjustment: > > + * Now that the frequncy is fixed, we > > + * want to look at the total error accumulated > > + * to move us back in sync using the same method. > > + * However, we must be careful as if we make too > > + * sudden an adjustment we might overshoot. So we > > + * limit the amount of change to spread the > > + * adjustment (using MAXOFFADJ) over a longer > > + * period of time. > > + * > > + * This is basically proportional control > > + * using the PID terminology. > > + * > > + * We use interval_cycs here as the divisor, which > > + * hopes that the next sample will be similar in > > + * distance from the last. > > + */ > > + if(error >= 0) { > > + adj = error_aproximation(error, > > + interval_cycs, MAXOFFADJ); > > + multadj += 1<<adj; > > + snsec_update += interval <<adj; > > + offset_update += offset << adj; > > + } else { > > + adj = error_aproximation(-error, > > + interval_cycs, MAXOFFADJ); > > + multadj -= 1<<adj; > > + snsec_update -= interval <<adj; > > + offset_update -= offset << adj; > > + } > > The limitation avoids the biggest problems, but it also may slow down the > error reduction (the more the bigger the shift value is). The main problem > is really that we don't know how many ticks will be skipped and with > interval_cycs you only know what happened last and this won't help if > ticks are skipped in irregular intervals. I think one of the important parts of my method is that I've broken up the error into two different types of error, that can be manipulated independently: 1) Error accumulated in the last period - the derivative part. 2) Total error - the proportional part. Taking component #1, we directly correct the frequency to flatten the error slope so in the next tick we should not accumulate any *extra* error (ideally, of course, since our granularity won't quite allow for that). Note that there is no "gain" (using the PID terminology) in that sense being applied. Its just an absolute frequency correction. Then taking component #2, if we calculated error/interval that would be the ideal correction to the proportional component for the next tick. However since we don't know when the next tick will occur, we use two methods to dampen the effect to avoid overshoot: a) Use the value interval/interval_cycs as our "gain" factor, thus if ticks are being lost, we assume will will continue to lose ticks. You are correct here in that irregular tick skipping could defeat this, but if a constant gain factor (of say, 1<<8) was used, we would have a hard time converging because the error/(interval*gain) would goto zero early. So instead, keeping the non-constant gain in (a), we use b) a limiter (MAXOFFADJ) so any proportional change is very dampened. This does have the effect that any large error takes awhile to reduce, but since we correct the recent (derivative error) directly, we should not be accumulating more. The combination of these two effects allows us to converge reasonably quickly when we are not skipping ticks, and controls overshoot when we are skipping ticks (proportionally to the number of ticks skipped). > Regarding dynticks it would help a lot here to know how many ticks are > skipped so you can spread the error correction evenly over this period > until the next adjustment and the correction is stopped in time. I've considered alternatives, where we use a constant gain with the proportional component (so any proportional change would be spread over one second), but to avoid constant offsets when the total error was smaller then the gain factor, we could also calculate a non-gain'ed adjustment w/ a limiter and include that. This would be more ideal in your irregular ticks example, but I'm not sure its really that much more beneficial from what I proposed. Anyway, I'm interested in what you are thinking for a more minimal approach to what we have in mainline, since I have a harder time wrapping my head around the future-error part (I can intuit what you want to accomplish, and I understand the benefit of looking ahead, but I just haven't been able to work out a proof for it :). thanks -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-07-06 22:05 ` john stultz @ 2006-07-07 23:16 ` Roman Zippel 2006-07-08 20:02 ` [PATCH] adjust clock for lost ticks Roman Zippel 1 sibling, 0 replies; 93+ messages in thread From: Roman Zippel @ 2006-07-07 23:16 UTC (permalink / raw) To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Uwe Bugla Hi, On Thu, 6 Jul 2006, john stultz wrote: > Yea. I've been trying to map your method to the PID concept as well > (when all you have is a hammer... ;) and they are similar, however the > "future error" aspect of yours makes it a little more difficult to > grasp, but it is more compact. Let's take a different example model - let's take two cars, where one car tries to follow the other, but it's limited in how it can change the speed (and sometimes the driver also falls asleep :) ). First we want to match of course the speed of both cars, so that the distance between the cars increases as little as possible over time. Second we want to decrease the distance between the cars. The problem is to stop the correction when the distance is near zero, which is simple when we know the next time, we can change the speed, but if we miss the point we overshoot and the distance grows again. It's possible to keep these two parameters separate, but it's actually simpler to look at them together, by simply looking some time ahead and calculate the position of the car at this time and thus the speed of the other car to reach this position. The adjustment code basically does just this by using the difference in speed to calculate the upcoming error. The new patch now uses the current error to decide by how much to look ahead, basically if we already have a large error, we have to be more careful, but overshooting with a small adjustment doesn't do much harm. In the patch below I left some debug prints, which are useful to check how good the error adjustment works. It should be close to the final version (minus the prints and plus some more comments). > > Regarding dynticks it would help a lot here to know how many ticks are > > skipped so you can spread the error correction evenly over this period > > until the next adjustment and the correction is stopped in time. > > I've considered alternatives, where we use a constant gain with the > proportional component (so any proportional change would be spread over > one second), but to avoid constant offsets when the total error was > smaller then the gain factor, we could also calculate a non-gain'ed > adjustment w/ a limiter and include that. This would be more ideal in > your irregular ticks example, but I'm not sure its really that much more > beneficial from what I proposed. The problem is we have conflicting goals, adjusting for an unknown number of lost ticks is bad for precise timekeeping. I prefer to assume that lost ticks are the exceptions and we need the help from the dynticks code to assure precise timekeeping. bye, Roman --- kernel/timer.c | 89 +++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 56 insertions(+), 33 deletions(-) Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c 2006-07-07 02:51:57.000000000 +0200 +++ linux-2.6-mm/kernel/timer.c 2006-07-07 23:58:47.000000000 +0200 @@ -1013,15 +1013,9 @@ device_initcall(timekeeping_init_device) */ static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset) { - int adj; + s64 e, i; + int adj, mult; - /* - * As soon as the machine is synchronized to the external time - * source this should be the common case. - */ - error >>= 2; - if (likely(sign > 0 ? error <= *interval : error >= *interval)) - return sign; /* * An extra look ahead dampens the effect of the current error, @@ -1029,33 +1023,41 @@ static __always_inline int clocksource_b * it would dominate the adjustment value and can lead to * oscillation. */ - error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1); - error -= clock->xtime_interval >> 1; - - adj = 0; - while (1) { - error >>= 1; - if (sign > 0 ? error <= *interval : error >= *interval) - break; - adj++; + e = (sign > 0 ? clock->error : -clock->error) >> (TICK_LENGTH_SHIFT + 20 - 2 * SHIFT_HZ); + for (adj = 0; (e >>= 2) > 0; adj++) + ; + error >>= adj; + e = current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift); + e -= clock->xtime_interval; + error += e; + error -= e >> (adj + 1); + + i = *interval; + mult = 1; + if (error < 0) { + error = -error; + *interval = -*interval; + *offset = -*offset; + mult = -1; + } + + if (error <= i) { + *interval = 0; + *offset = 0; + return 0; } - /* - * Add the current adjustments to the error and take the offset - * into account, the latter can cause the error to be hardly - * reduced at the next tick. Check the error again if there's - * room for another adjustment, thus further reducing the error - * which otherwise had to be corrected at the next update. - */ - error = (error << 1) - *interval + *offset; - if (sign > 0 ? error > *interval : error < *interval) - adj++; + for (adj = 0; (error >>= 1) > i; adj++) + ; *interval <<= adj; *offset <<= adj; - return sign << adj; + return mult << adj; } +static unsigned long next_print = INITIAL_JIFFIES; +static int big_cnt, one_cnt, zero_cnt; + /* * Adjust the multiplier to reduce the error value, * this is optimized for the most common adjustments of -1,0,1, @@ -1066,15 +1068,36 @@ static void clocksource_adjust(struct cl s64 error, interval = clock->cycle_interval; int adj; + if (time_after(jiffies, next_print)) { + printk("adj: %d,%d,%d\n", zero_cnt, one_cnt, big_cnt); + zero_cnt = one_cnt = big_cnt = 0; + next_print = jiffies + 10 * HZ; + } error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1); if (error > interval) { - adj = clocksource_bigadjust(1, error, &interval, &offset); + error >>= 2; + if (likely(error <= interval)) { + one_cnt++; + adj = 1; + } else { + big_cnt++; + adj = clocksource_bigadjust(1, error, &interval, &offset); + } } else if (error < -interval) { - interval = -interval; - offset = -offset; - adj = clocksource_bigadjust(-1, error, &interval, &offset); - } else + error >>= 2; + if (likely(error >= -interval)) { + one_cnt++; + adj = -1; + interval = -interval; + offset = -offset; + } else { + big_cnt++; + adj = clocksource_bigadjust(-1, error, &interval, &offset); + } + } else { + zero_cnt++; return; + } clock->mult += adj; clock->xtime_interval += interval; ^ permalink raw reply [flat|nested] 93+ messages in thread
* [PATCH] adjust clock for lost ticks 2006-07-06 22:05 ` john stultz 2006-07-07 23:16 ` Roman Zippel @ 2006-07-08 20:02 ` Roman Zippel 2006-07-09 21:25 ` john stultz 1 sibling, 1 reply; 93+ messages in thread From: Roman Zippel @ 2006-07-08 20:02 UTC (permalink / raw) To: john stultz Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Uwe Bugla, James Bottomley A large number of lost ticks can cause an overadjustment of the clock. To compensate for this we look at the current error and the larger the error already is the more careful we are at adjusting the error. As small extra fix reset the error when the clock is set. Signed-off-by: Roman Zippel <zippel@linux-m68k.org> --- kernel/timer.c | 85 +++++++++++++++++++++++++++++++-------------------------- 1 file changed, 47 insertions(+), 38 deletions(-) Index: linux-2.6-mm/kernel/timer.c =================================================================== --- linux-2.6-mm.orig/kernel/timer.c 2006-07-07 02:51:57.000000000 +0200 +++ linux-2.6-mm/kernel/timer.c 2006-07-08 19:10:52.000000000 +0200 @@ -891,6 +891,7 @@ int do_settimeofday(struct timespec *tv) set_normalized_timespec(&xtime, sec, nsec); set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec); + clock->error = 0; ntp_clear(); write_sequnlock_irqrestore(&xtime_lock, flags); @@ -1008,52 +1009,52 @@ static int __init timekeeping_init_devic device_initcall(timekeeping_init_device); /* - * If the error is already larger, we look ahead another tick, + * If the error is already larger, we look ahead even further * to compensate for late or lost adjustments. */ -static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset) +static __always_inline int clocksource_bigadjust(s64 error, s64 *interval, s64 *offset) { - int adj; + s64 tick_error, i; + u32 look_ahead, adj; + s32 error2, mult; /* - * As soon as the machine is synchronized to the external time - * source this should be the common case. + * Use the current error value to determine how much to look ahead. + * The larger the error the slower we adjust for it to avoid problems + * with losing too many ticks, otherwise we would overadjust and + * produce an even larger error. The smaller the adjustment the + * faster we try to adjust for it, as lost ticks can do less harm + * here. This is tuned so that an error of about 1 msec is adusted + * within about 1 sec (or 2^20 nsec in 2^SHIFT_HZ ticks). */ - error >>= 2; - if (likely(sign > 0 ? error <= *interval : error >= *interval)) - return sign; + error2 = clock->error >> (TICK_LENGTH_SHIFT + 22 - 2 * SHIFT_HZ); + error2 = abs(error2); + for (look_ahead = 0; error2 > 0; look_ahead++) + error2 >>= 2; /* - * An extra look ahead dampens the effect of the current error, - * which can grow quite large with continously late updates, as - * it would dominate the adjustment value and can lead to - * oscillation. + * Now calculate the error in (1 << look_ahead) ticks, but first + * remove the single look ahead already included in the error. */ - error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1); - error -= clock->xtime_interval >> 1; - - adj = 0; - while (1) { - error >>= 1; - if (sign > 0 ? error <= *interval : error >= *interval) - break; - adj++; + tick_error = current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1); + tick_error -= clock->xtime_interval >> 1; + error = ((error - tick_error) >> look_ahead) + tick_error; + + /* Finally calculate the adjustment shift value. */ + i = *interval; + mult = 1; + if (error < 0) { + error = -error; + *interval = -*interval; + *offset = -*offset; + mult = -1; } - - /* - * Add the current adjustments to the error and take the offset - * into account, the latter can cause the error to be hardly - * reduced at the next tick. Check the error again if there's - * room for another adjustment, thus further reducing the error - * which otherwise had to be corrected at the next update. - */ - error = (error << 1) - *interval + *offset; - if (sign > 0 ? error > *interval : error < *interval) - adj++; + for (adj = 0; error > i; adj++) + error >>= 1; *interval <<= adj; *offset <<= adj; - return sign << adj; + return mult << adj; } /* @@ -1068,11 +1069,19 @@ static void clocksource_adjust(struct cl error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1); if (error > interval) { - adj = clocksource_bigadjust(1, error, &interval, &offset); + error >>= 2; + if (likely(error <= interval)) + adj = 1; + else + adj = clocksource_bigadjust(error, &interval, &offset); } else if (error < -interval) { - interval = -interval; - offset = -offset; - adj = clocksource_bigadjust(-1, error, &interval, &offset); + error >>= 2; + if (likely(error >= -interval)) { + adj = -1; + interval = -interval; + offset = -offset; + } else + adj = clocksource_bigadjust(error, &interval, &offset); } else return; @@ -1129,7 +1138,7 @@ static void update_wall_time(void) clocksource_adjust(clock, offset); /* store full nanoseconds into xtime */ - xtime.tv_nsec = clock->xtime_nsec >> clock->shift; + xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift; clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift; /* check to see if there is a new clocksource to use */ ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: [PATCH] adjust clock for lost ticks 2006-07-08 20:02 ` [PATCH] adjust clock for lost ticks Roman Zippel @ 2006-07-09 21:25 ` john stultz 0 siblings, 0 replies; 93+ messages in thread From: john stultz @ 2006-07-09 21:25 UTC (permalink / raw) To: Roman Zippel Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Uwe Bugla, James Bottomley On Sat, 2006-07-08 at 22:02 +0200, Roman Zippel wrote: > A large number of lost ticks can cause an overadjustment of the clock. > To compensate for this we look at the current error and the larger the > error already is the more careful we are at adjusting the error. > As small extra fix reset the error when the clock is set. > > Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Roman, Spent the weekend testing this, dropping 99/100 ticks, and was able to hold decent sync w/ ntpd. Also the softlockup hang appears resolved as well (confirmed by Vladis). Thanks for sending this out. I know its already in -mm, but: Acked-by: John Stultz <johnstul@us.ibm.com> -john ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-28 10:35 ` Roman Zippel 2006-06-28 11:44 ` Roman Zippel @ 2006-06-28 23:41 ` john stultz 2006-06-29 11:24 ` Roman Zippel 1 sibling, 1 reply; 93+ messages in thread From: john stultz @ 2006-06-28 23:41 UTC (permalink / raw) To: Roman Zippel; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel On Wed, 2006-06-28 at 12:35 +0200, Roman Zippel wrote: > Hi, > > On Tue, 27 Jun 2006, john stultz wrote: > > > > [ 92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2]) > > > [ 92.087122] ACPI: Processor [CPU0] (supports 8 throttling states) > > > [ 92.120270] ACPI: Thermal Zone [THM] (70 C) > > > [ 72.242000] Time: acpi_pm clocksource has been installed. > > > > > > and the timestamps steps back about 20 seconds.... > > > > Yea, that bit is expected. Basically the cpufreq driver is loading, and > > when we detect cpufreq changes we mark the TSC as unstable and we fall > > back to an alternative clocksource (acpi_pm in your case). At the same > > time, sched_clock sees that the TSC is unstable and it falls back to > > using jiffies, which causes the small jump in the printk timestamps. > > Frequency changes are IMO currently the most likely reason for this > behaviour. If the cpu speeds down too much, the adjustment code might > actually attempt to go backwards in time, the old adjustment code might > have survived that, because it reacts slower to changes. > The patch below should prevent this. I agree cpufreq changes could be the source. However, things still aren't making sense, since the accumulation is cycle based to begin with, so any cpufreq caused drift in time won't be noticed until NTPd starts adjusting the output from current_tick_len(). Vladis: I don't want to overwhelm you with patches to try, I think Roman's debug patches should help show where the issue is. But if you've got the time, try the patch below to quickly see if the cpufreq changes are indeed causing the problem. > Looking through the log file, I noticed other things: > > [ 17.942330] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec. > ... > [ 21.869356] Time: tsc clocksource has been installed. > > The speedstep code uses do_gettimeofday() but there is no real clock > source installed, so it gets confused. > IMO it would be better to install the PIT timer very early and later avoid > switching to tsc at all, if there is any possibility of speed changes. Hmm. Yea, while I'm not sure this is the issue at hand, it does look like I need to get some of the boot ordering worked out here. Using the PIT early on probably isn't the best solution as the 18us access latency might not be the best for the transition calibration. Currently jiffies is the default clocksource until late_initcall time, which was done to minimize the clocksource churn at boot time. I'm not quite recalling the details, but I think the motivation was to avoid confusion when looking at the dmesg, so we could instead allow clocksources to be selected as they load, but disable printing anything to dmesg until after late_initcall. I'll start working on that. thanks -john This patch tries blocking the cpufreq changes to see if its causing the accounting issue. diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c index 7e0d8da..24af443 100644 --- a/arch/i386/kernel/tsc.c +++ b/arch/i386/kernel/tsc.c @@ -356,7 +356,7 @@ static int tsc_update_callback(void) } /* only update if tsc_khz has changed: */ - if (current_tsc_khz != tsc_khz) { + if (0 && current_tsc_khz != tsc_khz) { current_tsc_khz = tsc_khz; clocksource_tsc.mult = clocksource_khz2mult(current_tsc_khz, clocksource_tsc.shift); ^ permalink raw reply related [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 hrtimer code wedges at boot? 2006-06-28 23:41 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz @ 2006-06-29 11:24 ` Roman Zippel 0 siblings, 0 replies; 93+ messages in thread From: Roman Zippel @ 2006-06-29 11:24 UTC (permalink / raw) To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel Hi, On Wed, 28 Jun 2006, john stultz wrote: > I agree cpufreq changes could be the source. However, things still > aren't making sense, since the accumulation is cycle based to begin > with, so any cpufreq caused drift in time won't be noticed until NTPd > starts adjusting the output from current_tick_len(). Indeed, AFAICT the clock should just run too fast, that leaves pretty much only the update function doing something I didn't expect. > Vladis: I don't want to overwhelm you with patches to try, I think > Roman's debug patches should help show where the issue is. But if you've > got the time, try the patch below to quickly see if the cpufreq changes > are indeed causing the problem. Another change that might help: Valdis, could you add another call to printk_clock_info() at the end of update_wall_time() after clocksource_calculate_interval()? > Hmm. Yea, while I'm not sure this is the issue at hand, it does look > like I need to get some of the boot ordering worked out here. Using the > PIT early on probably isn't the best solution as the 18us access latency > might not be the best for the transition calibration. Since it shouldn't be used much I don't think it matters and it could also be HPET, basically whoever provides the timer interrupt. bye, Roman ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (11 preceding siblings ...) 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks @ 2006-06-28 16:54 ` Adrian Bunk 2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk 2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk 14 siblings, 0 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-28 16:54 UTC (permalink / raw) To: Andrew Morton, Andreas Mohr; +Cc: linux-kernel, len.brown, linux-acpi On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote: >... > Changes since 2.6.17-mm1: >... > +cpu_relax-use-in-acpi-lock.patch >... > ACPI stuff >... This patch fixes the following issue: <-- snip --> ... CC arch/i386/mach-visws/mpparse.o In file included from include/asm/fixmap.h:26, from include/asm/smp.h:15, from arch/i386/mach-visws/mpparse.c:6: include/asm/acpi.h: In function ‘__acpi_acquire_global_lock’: include/asm/acpi.h:70: warning: implicit declaration of function ‘cpu_relax’ ... <-- snip --> Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6.17-mm2/include/asm-i386/acpi.h.old 2006-06-26 23:00:40.000000000 +0200 +++ linux-2.6.17-mm2/include/asm-i386/acpi.h 2006-06-26 23:01:04.000000000 +0200 @@ -31,6 +31,7 @@ #include <acpi/pdc_intel.h> #include <asm/system.h> /* defines cmpxchg */ +#include <asm/processor.h> #define COMPILER_DEPENDENT_INT64 long long #define COMPILER_DEPENDENT_UINT64 unsigned long long ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] fix sgivwfb compile 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (12 preceding siblings ...) 2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk @ 2006-06-28 16:54 ` Adrian Bunk 2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk 14 siblings, 0 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-28 16:54 UTC (permalink / raw) To: Andrew Morton, Jeremy Fitzhardinge Cc: linux-kernel, pazke, linux-visws-devel, Chris Wright This patch fixes the following compile error caused by clean-up-and-refactor-i386-sub-architecture-setup.patch: <-- snip --> ... LD .tmp_vmlinux1 drivers/built-in.o: In function `sgivwfb_set_par': sgivwfb.c:(.text+0x88583): undefined reference to `sgivwfb_mem_phys' sgivwfb.c:(.text+0x88596): undefined reference to `sgivwfb_mem_phys' sgivwfb.c:(.text+0x885a8): undefined reference to `sgivwfb_mem_phys' drivers/built-in.o: In function `sgivwfb_check_var': sgivwfb.c:(.text+0x88ad0): undefined reference to `sgivwfb_mem_size' drivers/built-in.o: In function `sgivwfb_mmap': sgivwfb.c:(.text+0x88c75): undefined reference to `sgivwfb_mem_size' sgivwfb.c:(.text+0x88c7f): undefined reference to `sgivwfb_mem_phys' drivers/built-in.o: In function `sgivwfb_probe': sgivwfb.c:(.init.text+0x4060): undefined reference to `sgivwfb_mem_size' sgivwfb.c:(.init.text+0x4065): undefined reference to `sgivwfb_mem_phys' sgivwfb.c:(.init.text+0x4076): undefined reference to `sgivwfb_mem_phys' sgivwfb.c:(.init.text+0x409c): undefined reference to `sgivwfb_mem_size' sgivwfb.c:(.init.text+0x410e): undefined reference to `sgivwfb_mem_size' sgivwfb.c:(.init.text+0x4113): undefined reference to `sgivwfb_mem_phys' sgivwfb.c:(.init.text+0x4162): undefined reference to `sgivwfb_mem_size' sgivwfb.c:(.init.text+0x4168): undefined reference to `sgivwfb_mem_phys' make: *** [.tmp_vmlinux1] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <bunk@stusta.de> --- arch/i386/mach-visws/setup.c | 4 ++-- drivers/video/sgivwfb.c | 6 ++---- include/asm-i386/mach-visws/setup_arch.h | 3 +++ 3 files changed, 7 insertions(+), 6 deletions(-) --- linux-2.6.17-mm2-full/include/asm-i386/mach-visws/setup_arch.h.old 2006-06-27 00:35:55.000000000 +0200 +++ linux-2.6.17-mm2-full/include/asm-i386/mach-visws/setup_arch.h 2006-06-27 00:36:10.000000000 +0200 @@ -1,5 +1,8 @@ /* Hook to call BIOS initialisation function */ +extern unsigned long sgivwfb_mem_phys; +extern unsigned long sgivwfb_mem_size; + /* no action for visws */ #define ARCH_SETUP --- linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c.old 2006-06-27 00:28:06.000000000 +0200 +++ linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c 2006-06-27 00:28:20.000000000 +0200 @@ -140,8 +140,8 @@ #define MB (1024 * 1024) -static unsigned long sgivwfb_mem_phys; -static unsigned long sgivwfb_mem_size; +unsigned long sgivwfb_mem_phys; +unsigned long sgivwfb_mem_size; long long mem_size __initdata = 0; --- linux-2.6.17-mm2-full/drivers/video/sgivwfb.c.old 2006-06-27 00:29:03.000000000 +0200 +++ linux-2.6.17-mm2-full/drivers/video/sgivwfb.c 2006-06-27 00:36:37.000000000 +0200 @@ -23,6 +23,8 @@ #include <asm/io.h> #include <asm/mtrr.h> +#include <setup_arch.h> + #define INCLUDE_TIMING_TABLE_DATA #define DBE_REG_BASE par->regs #include <video/sgivw.h> @@ -42,10 +44,6 @@ * The default can be overridden if the driver is compiled as a module */ -/* set by arch/i386/kernel/setup.c */ -extern unsigned long sgivwfb_mem_phys; -extern unsigned long sgivwfb_mem_size; - static int ypan = 0; static int ywrap = 0; ^ permalink raw reply [flat|nested] 93+ messages in thread
* [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls 2006-06-24 13:19 2.6.17-mm2 Andrew Morton ` (13 preceding siblings ...) 2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk @ 2006-06-28 16:54 ` Adrian Bunk 14 siblings, 0 replies; 93+ messages in thread From: Adrian Bunk @ 2006-06-28 16:54 UTC (permalink / raw) To: Andrew Morton, pazke; +Cc: linux-kernel, linux-visws-devel Thankfully, these dummy function calls are no longer required to avoid warnings - if they weren't eliminated as dead code but accidentially executed there would be a guaranteed NULL dereference. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c.old 2006-06-27 00:28:06.000000000 +0200 +++ linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c 2006-06-27 00:37:50.000000000 +0200 @@ -177,8 +177,4 @@ add_memory_region(sgivwfb_mem_phys, sgivwfb_mem_size, E820_RESERVED); return "PROM"; - - /* Remove gcc warnings */ - (void) sanitize_e820_map(NULL, NULL); - (void) copy_e820_map(NULL, 0); } ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 @ 2006-06-24 15:41 Martin J. Bligh 2006-06-26 14:48 ` 2.6.17-mm2 Martin J. Bligh 0 siblings, 1 reply; 93+ messages in thread From: Martin J. Bligh @ 2006-06-24 15:41 UTC (permalink / raw) To: Andrew Morton; +Cc: Linux Kernel Mailing List Panic on PPC64. I'm guessing it's the same as the i386 panics I sent you yesterday, just more cryptic ;-) But for the record ... http://test.kernel.org/abat/37737/debug/console.log cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0] pc: c0000000000c6a34: .s_show+0x178/0x364 lr: c0000000000c696c: .s_show+0xb0/0x364 sp: c0000000f99f7b40 msr: 8000000000001032 dar: fd528000 dsisr: 40000000 current = 0xc0000000f23e0000 paca = 0xc00000000046e300 pid = 17653, comm = cp enter ? for help ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-24 15:41 2.6.17-mm2 Martin J. Bligh @ 2006-06-26 14:48 ` Martin J. Bligh 2006-06-27 15:37 ` 2.6.17-mm2 Martin J. Bligh 0 siblings, 1 reply; 93+ messages in thread From: Martin J. Bligh @ 2006-06-26 14:48 UTC (permalink / raw) To: Martin J. Bligh; +Cc: Andrew Morton, Linux Kernel Mailing List, Andy Whitcroft Martin J. Bligh wrote: > Panic on PPC64. I'm guessing it's the same as the i386 panics I sent > you yesterday, just more cryptic ;-) But for the record ... > > http://test.kernel.org/abat/37737/debug/console.log > > cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0] > pc: c0000000000c6a34: .s_show+0x178/0x364 > lr: c0000000000c696c: .s_show+0xb0/0x364 > sp: c0000000f99f7b40 > msr: 8000000000001032 > dar: fd528000 > dsisr: 40000000 > current = 0xc0000000f23e0000 > paca = 0xc00000000046e300 > pid = 17653, comm = cp > enter ? for help > Eeek, this is definitely an intermittent thing. I was trawling older results, and it shows up (on PPC only) in 2.6.17-git10, so it's not just an -mm thing ;-( M. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-26 14:48 ` 2.6.17-mm2 Martin J. Bligh @ 2006-06-27 15:37 ` Martin J. Bligh 2006-06-28 10:42 ` 2.6.17-mm2 Andrew Morton 0 siblings, 1 reply; 93+ messages in thread From: Martin J. Bligh @ 2006-06-27 15:37 UTC (permalink / raw) To: Martin J. Bligh Cc: Martin J. Bligh, Andrew Morton, Linux Kernel Mailing List, Andy Whitcroft, linuxppc64-dev Martin J. Bligh wrote: > Martin J. Bligh wrote: > >> Panic on PPC64. I'm guessing it's the same as the i386 panics I sent >> you yesterday, just more cryptic ;-) But for the record ... >> >> http://test.kernel.org/abat/37737/debug/console.log >> >> cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0] >> pc: c0000000000c6a34: .s_show+0x178/0x364 >> lr: c0000000000c696c: .s_show+0xb0/0x364 >> sp: c0000000f99f7b40 >> msr: 8000000000001032 >> dar: fd528000 >> dsisr: 40000000 >> current = 0xc0000000f23e0000 >> paca = 0xc00000000046e300 >> pid = 17653, comm = cp >> enter ? for help >> > > Eeek, this is definitely an intermittent thing. I was trawling older > results, and it shows up (on PPC only) in 2.6.17-git10, so it's not > just an -mm thing ;-( OK, still happens in -mm3, though in a different workload now. I also get a new panic, that's maybe related but more informative cpu 0x0: Vector: 700 (Program Check) at [c0000000024938b0] pc: c0000000000c3218: .free_block+0xe4/0x240 lr: c0000000000c3514: .drain_array+0xf4/0x170 sp: c000000002493b30 msr: 8000000000021032 current = 0xc0000000025457f0 paca = 0xc0000000004f9f00 pid = 14, comm = events/0 kernel BUG in list_del at include/linux/list.h:160! Plus one with an actual backtrace from PPC64 that looks more like the i386 ones SMP NR_CPUS=32 NUMA Modules linked in: NIP: C0000000000A311C LR: C0000000000A30D4 CTR: C0000000000A3024 REGS: c0000007725b38d0 TRAP: 0300 Not tainted (2.6.17-mm3-autokern1) MSR: 8000000000001032 <ME,IR,DR> CR: 28224424 XER: 00000000 DAR: 000000077BCC6180, DSISR: 0000000040000000 TASK = c00000002fc74670[29812] 'cp' THREAD: c0000007725b0000 CPU: 2 GPR00: 0000000000000000 C0000007725B3B50 C00000000063B828 C00000001E303EC0 GPR04: 0000000000000010 0000000000000000 0000000000000000 FFFFFFFFFFFFFFFD GPR08: 0000000000000001 0000000000000000 000000077BCC6180 0000000000000000 GPR12: 0000000000000000 C00000000051FF80 0000000000000000 0000000000000001 GPR16: 0000000000000000 0000000000000004 0000000000020000 0000000000000000 GPR20: 0000000000000000 0000000000000000 C0000007759F9D00 0000000000000000 GPR24: 0000000000000E42 0000000000000000 000000000000474A C00000001E30F300 GPR28: 0000000000000000 0000000000000000 C000000000537288 C00000001E303E80 NIP [C0000000000A311C] .s_show+0xf8/0x364 LR [C0000000000A30D4] .s_show+0xb0/0x364 Call Trace: [C0000007725B3B50] [C0000000000A3334] .s_show+0x310/0x364 (unreliable) [C0000007725B3C20] [C0000000000D5E84] .seq_read+0x2f4/0x450 [C0000007725B3D00] [C0000000000AADF8] .vfs_read+0xe0/0x1b4 [C0000007725B3D90] [C0000000000AAFD4] .sys_read+0x54/0x98 [C0000007725B3E30] [C00000000000871C] syscall_exit+0x0/0x40 Instruction dump: 3b180001 7c004a78 79290020 7c0bfe70 7f5a4a14 7d600278 7c005850 54000ffe 7c094038 2c090000 41820008 ebbe80b0 <e96a0000> 2fab0000 419e0008 7c005a2c ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-27 15:37 ` 2.6.17-mm2 Martin J. Bligh @ 2006-06-28 10:42 ` Andrew Morton 2006-06-28 10:47 ` 2.6.17-mm2 Andrew Morton 2006-06-28 15:43 ` 2.6.17-mm2 Jeremy Fitzhardinge 0 siblings, 2 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-28 10:42 UTC (permalink / raw) To: Martin J. Bligh, Jeremy Fitzhardinge Cc: mbligh, mbligh, linux-kernel, apw, linuxppc64-dev On Tue, 27 Jun 2006 08:37:45 -0700 "Martin J. Bligh" <mbligh@mbligh.org> wrote: > SMP NR_CPUS=32 NUMA > Modules linked in: > NIP: C0000000000A311C LR: C0000000000A30D4 CTR: C0000000000A3024 > REGS: c0000007725b38d0 TRAP: 0300 Not tainted (2.6.17-mm3-autokern1) > MSR: 8000000000001032 <ME,IR,DR> CR: 28224424 XER: 00000000 > DAR: 000000077BCC6180, DSISR: 0000000040000000 > TASK = c00000002fc74670[29812] 'cp' THREAD: c0000007725b0000 CPU: 2 > GPR00: 0000000000000000 C0000007725B3B50 C00000000063B828 C00000001E303EC0 > GPR04: 0000000000000010 0000000000000000 0000000000000000 FFFFFFFFFFFFFFFD > GPR08: 0000000000000001 0000000000000000 000000077BCC6180 0000000000000000 > GPR12: 0000000000000000 C00000000051FF80 0000000000000000 0000000000000001 > GPR16: 0000000000000000 0000000000000004 0000000000020000 0000000000000000 > GPR20: 0000000000000000 0000000000000000 C0000007759F9D00 0000000000000000 > GPR24: 0000000000000E42 0000000000000000 000000000000474A C00000001E30F300 > GPR28: 0000000000000000 0000000000000000 C000000000537288 C00000001E303E80 > NIP [C0000000000A311C] .s_show+0xf8/0x364 > LR [C0000000000A30D4] .s_show+0xb0/0x364 > Call Trace: > [C0000007725B3B50] [C0000000000A3334] .s_show+0x310/0x364 (unreliable) > [C0000007725B3C20] [C0000000000D5E84] .seq_read+0x2f4/0x450 > [C0000007725B3D00] [C0000000000AADF8] .vfs_read+0xe0/0x1b4 > [C0000007725B3D90] [C0000000000AAFD4] .sys_read+0x54/0x98 > [C0000007725B3E30] [C00000000000871C] syscall_exit+0x0/0x40 This is caused by the vsprintf() changes. Right now, if you do snprintf(buf, 4, "1111111111111"); the memory at `buf' gets [31 31 31 31 00], which is not good. This'll plug it, but I didn't check very hard whether it still has any off-by-ones, or if breaks the intent of Jeremy's patch. I think it's OK.. --- a/lib/vsprintf.c~c +++ a/lib/vsprintf.c @@ -259,7 +259,9 @@ int vsnprintf(char *buf, size_t size, co int len; unsigned long long num; int i, base; - char *str, *end, c; + char *str; /* Where we're writing to */ + char *end; /* The last byte we can write to */ + char c; const char *s; int flags; /* flags to number() */ @@ -283,12 +285,12 @@ int vsnprintf(char *buf, size_t size, co } str = buf; - end = buf + size; + end = buf + size - 1; /* Make sure end is always >= buf */ - if (end < buf) { + if (end < buf - 1) { end = ((void *) ~0ull); - size = end - buf; + size = end - buf + 1; } for (; *fmt ; ++fmt) { _ ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 10:42 ` 2.6.17-mm2 Andrew Morton @ 2006-06-28 10:47 ` Andrew Morton 2006-06-28 14:43 ` 2.6.17-mm2 Martin J. Bligh 2006-06-28 15:43 ` 2.6.17-mm2 Jeremy Fitzhardinge 1 sibling, 1 reply; 93+ messages in thread From: Andrew Morton @ 2006-06-28 10:47 UTC (permalink / raw) To: mbligh, jeremy, mbligh, linux-kernel, apw, linuxppc64-dev On Wed, 28 Jun 2006 03:42:15 -0700 Andrew Morton <akpm@osdl.org> wrote: > his is caused by the vsprintf() changes. Right now, if you do > > snprintf(buf, 4, "1111111111111"); > > the memory at `buf' gets [31 31 31 31 00], which is not good. > > This'll plug it, but I didn't check very hard whether it still has any > off-by-ones, or if breaks the intent of Jeremy's patch. I think it's OK.. That diff was against an older kernel and doesn't apply. This is against mainline: --- a/lib/vsprintf.c~vsnprintf-fix +++ a/lib/vsprintf.c @@ -259,7 +259,9 @@ int vsnprintf(char *buf, size_t size, co int len; unsigned long long num; int i, base; - char *str, *end, c; + char *str; /* Where we're writing to */ + char *end; /* The last byte we can write to */ + char c; const char *s; int flags; /* flags to number() */ @@ -283,12 +285,12 @@ int vsnprintf(char *buf, size_t size, co } str = buf; - end = buf + size; + end = buf + size - 1; /* Make sure end is always >= buf */ - if (end < buf) { + if (end < buf - 1) { end = ((void *)-1); - size = end - buf; + size = end - buf + 1; } for (; *fmt ; ++fmt) { @@ -494,7 +496,6 @@ int vsnprintf(char *buf, size_t size, co /* the trailing null byte doesn't count towards the total */ return str-buf; } - EXPORT_SYMBOL(vsnprintf); /** _ ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 10:47 ` 2.6.17-mm2 Andrew Morton @ 2006-06-28 14:43 ` Martin J. Bligh 2006-06-28 15:06 ` 2.6.17-mm2 Andy Whitcroft 2006-06-28 19:11 ` 2.6.17-mm2 Andrew Morton 0 siblings, 2 replies; 93+ messages in thread From: Martin J. Bligh @ 2006-06-28 14:43 UTC (permalink / raw) To: Andrew Morton; +Cc: mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle Andrew Morton wrote: > On Wed, 28 Jun 2006 03:42:15 -0700 > Andrew Morton <akpm@osdl.org> wrote: > > >>his is caused by the vsprintf() changes. Right now, if you do >> >> snprintf(buf, 4, "1111111111111"); >> >>the memory at `buf' gets [31 31 31 31 00], which is not good. >> >>This'll plug it, but I didn't check very hard whether it still has any >>off-by-ones, or if breaks the intent of Jeremy's patch. I think it's OK.. Aha, you're a genius! How the hell did you figure that one out? Andy / Steve ... any chance one of you could kick this through the harness? Against -git10 or so, I'd think Thanks, M. > That diff was against an older kernel and doesn't apply. This is against > mainline: > > --- a/lib/vsprintf.c~vsnprintf-fix > +++ a/lib/vsprintf.c > @@ -259,7 +259,9 @@ int vsnprintf(char *buf, size_t size, co > int len; > unsigned long long num; > int i, base; > - char *str, *end, c; > + char *str; /* Where we're writing to */ > + char *end; /* The last byte we can write to */ > + char c; > const char *s; > > int flags; /* flags to number() */ > @@ -283,12 +285,12 @@ int vsnprintf(char *buf, size_t size, co > } > > str = buf; > - end = buf + size; > + end = buf + size - 1; > > /* Make sure end is always >= buf */ > - if (end < buf) { > + if (end < buf - 1) { > end = ((void *)-1); > - size = end - buf; > + size = end - buf + 1; > } > > for (; *fmt ; ++fmt) { > @@ -494,7 +496,6 @@ int vsnprintf(char *buf, size_t size, co > /* the trailing null byte doesn't count towards the total */ > return str-buf; > } > - > EXPORT_SYMBOL(vsnprintf); > > /** > _ > ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 14:43 ` 2.6.17-mm2 Martin J. Bligh @ 2006-06-28 15:06 ` Andy Whitcroft 2006-06-28 19:11 ` 2.6.17-mm2 Andrew Morton 1 sibling, 0 replies; 93+ messages in thread From: Andy Whitcroft @ 2006-06-28 15:06 UTC (permalink / raw) To: Martin J. Bligh Cc: Andrew Morton, mbligh, jeremy, linux-kernel, linuxppc64-dev, drfickle Martin J. Bligh wrote: > Andrew Morton wrote: > >> On Wed, 28 Jun 2006 03:42:15 -0700 >> Andrew Morton <akpm@osdl.org> wrote: >> >> >>> his is caused by the vsprintf() changes. Right now, if you do >>> >>> snprintf(buf, 4, "1111111111111"); >>> >>> the memory at `buf' gets [31 31 31 31 00], which is not good. >>> >>> This'll plug it, but I didn't check very hard whether it still has any >>> off-by-ones, or if breaks the intent of Jeremy's patch. I think it's >>> OK.. > > > Aha, you're a genius! How the hell did you figure that one out? > > Andy / Steve ... any chance one of you could kick this through the > harness? Against -git10 or so, I'd think > > Thanks, Suitibly kicked ... against 2.6.17-git10. -apw ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 14:43 ` 2.6.17-mm2 Martin J. Bligh 2006-06-28 15:06 ` 2.6.17-mm2 Andy Whitcroft @ 2006-06-28 19:11 ` Andrew Morton 2006-06-28 19:22 ` 2.6.17-mm2 Jeremy Fitzhardinge 2006-06-28 19:36 ` 2.6.17-mm2 Martin Bligh 1 sibling, 2 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-28 19:11 UTC (permalink / raw) To: Martin J. Bligh Cc: mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle On Wed, 28 Jun 2006 07:43:14 -0700 "Martin J. Bligh" <mbligh@google.com> wrote: > Andrew Morton wrote: > > On Wed, 28 Jun 2006 03:42:15 -0700 > > Andrew Morton <akpm@osdl.org> wrote: > > > > > >>his is caused by the vsprintf() changes. Right now, if you do > >> > >> snprintf(buf, 4, "1111111111111"); > >> > >>the memory at `buf' gets [31 31 31 31 00], which is not good. > >> > >>This'll plug it, but I didn't check very hard whether it still has any > >>off-by-ones, or if breaks the intent of Jeremy's patch. I think it's OK.. > > Aha, you're a genius! That's not what my kids say. > How the hell did you figure that one out? Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a tight loop. With that happening, a little two-way wasn't able to make it through `dbench 4' without soiling the upholstery. Then bisection-searching. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 19:11 ` 2.6.17-mm2 Andrew Morton @ 2006-06-28 19:22 ` Jeremy Fitzhardinge 2006-06-28 19:49 ` 2.6.17-mm2 Andrew Morton 2006-06-28 19:36 ` 2.6.17-mm2 Martin Bligh 1 sibling, 1 reply; 93+ messages in thread From: Jeremy Fitzhardinge @ 2006-06-28 19:22 UTC (permalink / raw) To: Andrew Morton Cc: Martin J. Bligh, mbligh, linux-kernel, apw, linuxppc64-dev, drfickle Andrew Morton wrote: > Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a > tight loop. With that happening, a little two-way wasn't able to make > it through `dbench 4' without soiling the upholstery. Then bisection-searching. > It's surprising it was so subtle. I'd been running with that code for a month or so without a peep of problem... J ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 19:22 ` 2.6.17-mm2 Jeremy Fitzhardinge @ 2006-06-28 19:49 ` Andrew Morton 0 siblings, 0 replies; 93+ messages in thread From: Andrew Morton @ 2006-06-28 19:49 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: mbligh, mbligh, linux-kernel, apw, linuxppc64-dev, drfickle On Wed, 28 Jun 2006 12:22:02 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Andrew Morton wrote: > > Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a > > tight loop. With that happening, a little two-way wasn't able to make > > it through `dbench 4' without soiling the upholstery. Then bisection-searching. > > > It's surprising it was so subtle. I'd been running with that code for a > month or so without a peep of problem... > It'll only bite if someone does snprintf() into a too-short buffer. That's rare (it's usually a bug). But it looks like the seq_file() code does it when someone is trying to generate more than PAGE_SIZE's worth of data. Like /proc/slabinfo. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 19:11 ` 2.6.17-mm2 Andrew Morton 2006-06-28 19:22 ` 2.6.17-mm2 Jeremy Fitzhardinge @ 2006-06-28 19:36 ` Martin Bligh 2006-06-29 0:17 ` 2.6.17-mm2 Martin J. Bligh 1 sibling, 1 reply; 93+ messages in thread From: Martin Bligh @ 2006-06-28 19:36 UTC (permalink / raw) To: Andrew Morton; +Cc: mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle >>How the hell did you figure that one out? > > Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a > tight loop. With that happening, a little two-way wasn't able to make > it through `dbench 4' without soiling the upholstery. Then bisection-searching. Aha. we probably trigger it because the automated test harness dumps a bunch of crap out of /proc before and after running dbench then ;-) Thanks! M. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 19:36 ` 2.6.17-mm2 Martin Bligh @ 2006-06-29 0:17 ` Martin J. Bligh 0 siblings, 0 replies; 93+ messages in thread From: Martin J. Bligh @ 2006-06-29 0:17 UTC (permalink / raw) To: Martin Bligh Cc: Andrew Morton, mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle Martin Bligh wrote: >>> How the hell did you figure that one out? >> >> >> Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a >> tight loop. With that happening, a little two-way wasn't able to make >> it through `dbench 4' without soiling the upholstery. Then >> bisection-searching. > > > Aha. we probably trigger it because the automated test harness dumps a > bunch of crap out of /proc before and after running dbench then ;-) OK, your patch does seem to fix it for the automated tests. Not 100% reliable, since it was a little intermittent before, but it looks good. Thanks to both Andrew and Andy. M. ^ permalink raw reply [flat|nested] 93+ messages in thread
* Re: 2.6.17-mm2 2006-06-28 10:42 ` 2.6.17-mm2 Andrew Morton 2006-06-28 10:47 ` 2.6.17-mm2 Andrew Morton @ 2006-06-28 15:43 ` Jeremy Fitzhardinge 1 sibling, 0 replies; 93+ messages in thread From: Jeremy Fitzhardinge @ 2006-06-28 15:43 UTC (permalink / raw) To: Andrew Morton; +Cc: Martin J. Bligh, mbligh, linux-kernel, apw, linuxppc64-dev Andrew Morton wrote: > This is caused by the vsprintf() changes. Right now, if you do > > snprintf(buf, 4, "1111111111111"); > > the memory at `buf' gets [31 31 31 31 00], which is not good. > > This'll plug it, but I didn't check very hard whether it still has any > off-by-ones, or if breaks the intent of Jeremy's patch. I think it's OK.. > Damn. This patch doesn't look right; the intent is that 'end' point to just beyond the formatted string. I'm pretty sure I tested this, since its the most obvious test. Clearly not enough. I'll look into it. J ^ permalink raw reply [flat|nested] 93+ messages in thread
end of thread, other threads:[~2006-07-09 21:25 UTC | newest] Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-06-24 13:19 2.6.17-mm2 Andrew Morton 2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki 2006-06-24 17:20 ` 2.6.17-mm2 Dave Jones 2006-06-24 21:34 ` 2.6.17-mm2 Andrew Morton 2006-06-25 8:51 ` 2.6.17-mm2 Rafael J. Wysocki 2006-06-25 10:22 ` 2.6.17-mm2 Andrew Morton 2006-06-25 15:16 ` 2.6.17-mm2 Andrew Morton 2006-06-25 18:23 ` 2.6.17-mm2 Sam Ravnborg 2006-06-25 18:40 ` 2.6.17-mm2 Andrew Morton 2006-06-25 21:21 ` 2.6.17-mm2 Sam Ravnborg 2006-06-30 7:38 ` 2.6.17-mm2 Randy.Dunlap 2006-07-02 10:11 ` 2.6.17-mm2 Russell King 2006-07-02 18:42 ` 2.6.17-mm2 Randy.Dunlap 2006-07-02 18:47 ` 2.6.17-mm2 Arjan van de Ven 2006-07-02 18:47 ` 2.6.17-mm2 Sam Ravnborg 2006-07-03 5:50 ` 2.6.17-mm2 Randy.Dunlap 2006-07-03 13:49 ` 2.6.17-mm2 Russell King 2006-06-25 19:19 ` 2.6.17-mm2 Rafael J. Wysocki 2006-06-26 20:13 ` 2.6.17-mm2 Chandra Seetharaman 2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall 2006-06-24 21:43 ` 2.6.17-mm2 Andrew Morton 2006-06-25 6:06 ` 2.6.17-mm2 Reuben Farrelly 2006-06-25 9:37 ` 2.6.17-mm2 Barry K. Nathan 2006-06-25 10:29 ` 2.6.17-mm2 Reuben Farrelly 2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski 2006-06-25 11:40 ` 2.6.17-mm2 Andrew Morton 2006-06-25 12:18 ` 2.6.17-mm2 Michal Piotrowski 2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall 2006-06-25 17:18 ` Andrew Morton 2006-06-25 18:11 ` Dominik Karall 2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk 2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk 2006-06-26 0:41 ` Vivek Goyal 2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk 2006-06-25 23:27 ` Alan Cox 2006-06-27 1:03 ` Jeff Garzik 2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk 2006-06-26 4:05 ` Steven French 2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk 2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk 2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks 2006-06-26 22:50 ` Valdis.Kletnieks 2006-06-26 23:02 ` john stultz 2006-06-26 23:27 ` Thomas Gleixner 2006-06-27 2:12 ` Valdis.Kletnieks 2006-06-27 5:54 ` Thomas Gleixner 2006-06-27 10:16 ` Roman Zippel 2006-06-27 16:43 ` Valdis.Kletnieks 2006-06-27 17:10 ` Roman Zippel 2006-06-27 17:23 ` Roman Zippel 2006-06-27 19:07 ` Valdis.Kletnieks 2006-06-28 0:07 ` john stultz 2006-06-28 10:35 ` Roman Zippel 2006-06-28 11:44 ` Roman Zippel 2006-06-29 23:07 ` Valdis.Kletnieks 2006-06-30 19:26 ` john stultz 2006-06-30 21:04 ` Valdis.Kletnieks 2006-07-03 1:13 ` Roman Zippel 2006-07-03 1:56 ` Daniel Walker 2006-07-03 2:20 ` Valdis.Kletnieks 2006-07-03 20:08 ` john stultz 2006-07-03 19:59 ` john stultz 2006-07-04 22:21 ` Valdis.Kletnieks 2006-07-05 4:29 ` Valdis.Kletnieks 2006-07-06 0:37 ` Roman Zippel 2006-07-06 0:56 ` john stultz 2006-07-06 6:38 ` Valdis.Kletnieks 2006-07-06 0:51 ` john stultz 2006-07-06 1:12 ` john stultz 2006-07-06 5:43 ` john stultz 2006-07-06 20:33 ` Roman Zippel 2006-07-06 22:05 ` john stultz 2006-07-07 23:16 ` Roman Zippel 2006-07-08 20:02 ` [PATCH] adjust clock for lost ticks Roman Zippel 2006-07-09 21:25 ` john stultz 2006-06-28 23:41 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz 2006-06-29 11:24 ` Roman Zippel 2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk 2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk 2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk 2006-06-24 15:41 2.6.17-mm2 Martin J. Bligh 2006-06-26 14:48 ` 2.6.17-mm2 Martin J. Bligh 2006-06-27 15:37 ` 2.6.17-mm2 Martin J. Bligh 2006-06-28 10:42 ` 2.6.17-mm2 Andrew Morton 2006-06-28 10:47 ` 2.6.17-mm2 Andrew Morton 2006-06-28 14:43 ` 2.6.17-mm2 Martin J. Bligh 2006-06-28 15:06 ` 2.6.17-mm2 Andy Whitcroft 2006-06-28 19:11 ` 2.6.17-mm2 Andrew Morton 2006-06-28 19:22 ` 2.6.17-mm2 Jeremy Fitzhardinge 2006-06-28 19:49 ` 2.6.17-mm2 Andrew Morton 2006-06-28 19:36 ` 2.6.17-mm2 Martin Bligh 2006-06-29 0:17 ` 2.6.17-mm2 Martin J. Bligh 2006-06-28 15:43 ` 2.6.17-mm2 Jeremy Fitzhardinge
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).