Skip to contentSkip to conversation

2.6.17-mm2

PATCH Applied Andrew Morton 22 participants 80 messages Jun 24, 2006 – Jul 9, 2006

Subsystems (9)
Networking Network drivers SCSI ACPI +5 more subsystems
lore
Share & tools
lore

Andrew Morton

author Applied
#0 lore raw

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 [email protected]

- 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

#1 lore raw
Quoted 2 lines · Andrew Morton

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

#2 lore raw
Quoted 28 lines · Rafael J. Wysocki
Quoted 2 lines · Andrew Morton

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
Quoted 1 line

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

Signature · 1 line
http://www.codemonkey.org.uk
#3 lore raw
Quoted 28 lines · On Sat, 24 Jun 2006 13:20:14 -0400 Dave Jones <[email protected]> wrote:
Quoted 27 lines · Rafael J. Wysocki
Quoted 2 lines · Andrew Morton

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>]
Quoted 6 lines
Quoted 2 lines
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.

#4 lore raw
Quoted 34 lines · Andrew Morton
Quoted 31 lines · On Sat, 24 Jun 2006 13:20:14 -0400 Dave Jones <[email protected]> wrote:
Quoted 29 lines · Rafael J. Wysocki
Quoted 2 lines · Andrew Morton

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>

Quoted 8 lines
Quoted 3 lines

'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.

Quoted 2 lines

Does removal of the __cpuinit from cpufreq_register_driver() fix it (or move the crash elsewhere)?

Yes (makes it go away).

Quoted 1 line

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

#5 lore raw
Quoted 5 lines · On Sun, 25 Jun 2006 10:51:55 +0200 "Rafael J. Wysocki" <[email protected]> wrote:
Quoted 5 lines
Quoted 1 line

My guess would be that cpufreq_register_driver() is being called after it has been unloaded from the kernel.

Quoted 8 lines
Quoted 1 line

Do you have CONFIG_CPU_FREQ=y?

Yes.

Quoted 2 lines

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??

Quoted 5 lines
Quoted 1 line

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.

#6 lore raw
Quoted 5 lines · On Sun, 25 Jun 2006 03:22:43 -0700 Andrew Morton <[email protected]> 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.

Quoted 9 lines

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?

#7 lore raw
Quoted 8 lines · Andrew Morton

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

#8 lore raw
Quoted 12 lines · On Sun, 25 Jun 2006 20:23:52 +0200 Sam Ravnborg <[email protected]> wrote:
Quoted 8 lines · Andrew Morton

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.

#9 lore raw
Quoted 10 lines · Andrew Morton
Quoted 6 lines
Quoted 3 lines

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

#10 lore raw
In reply to Andrew Morton
Quoted 22 lines · On Sun, 25 Jun 2006 08:16:10 -0700 Andrew Morton wrote:
Quoted 5 lines · On Sun, 25 Jun 2006 03:22:43 -0700 Andrew Morton <[email protected]> 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.

Quoted 9 lines

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.

Quoted 6 lines

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

#11 lore raw
Quoted 16 lines · Randy.Dunlap

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)

Quoted 9 lines

./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.

Quoted 8 lines

./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.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
#12 lore raw
Quoted 46 lines · On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:
Quoted 16 lines · Randy.Dunlap

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)

Quoted 9 lines

./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)

Quoted 5 lines

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.

Quoted 10 lines
Quoted 8 lines

./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

#13 lore raw
Quoted 3 lines · Randy.Dunlap

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.

#14 lore raw
In reply to Randy.Dunlap
Quoted 3 lines

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

#15 lore raw
In reply to Russell King
Quoted 5 lines · On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:
Quoted 4 lines · Randy.Dunlap

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:

...

Quoted 7 lines
Quoted 6 lines

./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

#16 lore raw
Quoted 15 lines · Randy.Dunlap
Quoted 5 lines · On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:
Quoted 4 lines · Randy.Dunlap

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:

...

Quoted 7 lines
Quoted 6 lines

./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.

Quoted 8 lines

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.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
#17 lore raw
In reply to Andrew Morton
Quoted 12 lines · Andrew Morton
Quoted 9 lines · On Sun, 25 Jun 2006 10:51:55 +0200 "Rafael J. Wysocki" <[email protected]> wrote:
Quoted 6 lines
Quoted 1 line

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.

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

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

#18 lore raw
In reply to Andrew Morton
Quoted 9 lines · Andrew Morton

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.

Quoted 4 lines

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.

--

 drivers/cpufreq/cpufreq.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)
drivers/cpufreq/cpufreq.c +5 -3
Index: 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;
Signature · 4 lines
----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - [email protected]   |      .......you may get it.
----------------------------------------------------------------------
#19 lore raw
In reply to Andrew Morton
Quoted 2 lines · Andrew Morton

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

#20 lore raw
Quoted 11 lines · On Sat, 24 Jun 2006 21:41:41 +0200 Dominik Karall <[email protected]>…
Quoted 2 lines · Andrew Morton

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.

#21 lore raw
In reply to Andrew Morton

Hi,

Quoted 11 lines · Andrew Morton

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.

Quoted 5 lines

- 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

#22 lore raw
Quoted 2 lines · Reuben Farrelly

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.)

Signature · 1 line
-Barry K. Nathan <[email protected]>
#23 lore raw
Quoted 11 lines · Barry K. Nathan
Quoted 2 lines · Reuben Farrelly

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

#24 lore raw
In reply to Andrew Morton

Hi,

Quoted 3 lines · Andrew Morton

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

Signature · 3 lines
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
#25 lore raw
Quoted 25 lines · On Sun, 25 Jun 2006 13:19:25 +0200 "Michal Piotrowski"…
Quoted 3 lines · Andrew Morton

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

Quoted 5 lines
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 <[email protected]>
To: Andrew Morton <[email protected]>
Subject: Re: more -mm2 troubles ...

Quoted 9 lines · Ingo Molnar

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 <[email protected]>

seems like sched_exit() cannot be moved to a later stage just yet. Needs more investigation.

---
 kernel/exit.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
kernel/exit.c +1 -2
Index: 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);
#26 lore raw
Quoted 34 lines · Andrew Morton
Quoted 25 lines · On Sun, 25 Jun 2006 13:19:25 +0200 "Michal Piotrowski"…
Quoted 3 lines · Andrew Morton

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

Quoted 5 lines
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
Quoted 3 lines

OK, thanks. I expect the below will fix that (I've since dropped the offending patches)

Problem fixed, thanks.

Regards,
Michal

Signature · 3 lines
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
#28 lore raw

Re: 2.6.17-mm2 (NULL pointer dereference)

Quoted 10 lines · On Sun, 25 Jun 2006 18:25:26 +0200 Dominik Karall <[email protected]>…
Quoted 2 lines · Andrew Morton

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?

#29 lore raw

Re: 2.6.17-mm2 (NULL pointer dereference)

Quoted 9 lines · Andrew Morton

On Sun, 25 Jun 2006 18:25:26 +0200

Quoted 6 lines · Dominik Karall
Quoted 2 lines · Andrew Morton

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2 .6.1 7/2.6.17-mm2/

hi!

Quoted 8 lines
Quoted 3 lines

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

#30 lore raw

2.6.17-mm2: no QLA3YYY_NAPI help text

In reply to Andrew Morton

[ resent with a subject adapted to vger mail filter... ]

Quoted 7 lines · Andrew Morton

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

#31 lore raw

2.6.17-mm2: BLK_CPQ_CISS_DA=m error

In reply to Andrew Morton
Quoted 7 lines · Andrew Morton

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

Signature · 4 lines
       "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
#32 lore raw

Re: 2.6.17-mm2: BLK_CPQ_CISS_DA=m error

Quoted 9 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton

...
Changes since 2.6.17-mm1:
...
+kdump-cciss-driver-initialization-issue-fix.patch

Unpleasant kdump patches.
...

Quoted 8 lines

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.

---

 linux-2.6.17-1M-vivek/init/main.c |    1 +
 1 files changed, 1 insertion(+)
init/main.c renamed from init/main.c~cciss-module-compilation-break-fix +1 -0
diff -puN init/main.c~cciss-module-compilation-break-fix init/main.c
@@ -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;

_

#33 lore raw

PATCH 1/1 make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static

In reply to Andrew Morton
Quoted 7 lines · Andrew Morton

...
Changes since 2.6.17-mm1:
...
git-libata-all.patch
...
git trees
...

This patch makes the needlessly global it821x_passthru_dev_select() static.

drivers/scsi/pata_it821x.c renamed from drivers/scsi/pata_it821x.c.old +2 -1
@@ -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) {
Acked-by on v1 1/1
#34 lore raw

Re: [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static

Quoted 9 lines · Adrian Bunk
Quoted 7 lines · Andrew Morton

...
Changes since 2.6.17-mm1:
...
git-libata-all.patch
...
git trees
...

Quoted 4 lines

This patch makes the needlessly global it821x_passthru_dev_select() static.

Quoted 13 lines
drivers/scsi/pata_it821x.c renamed from drivers/scsi/pata_it821x.c.old +2 -1
@@ -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) {
Signature · 5 lines
	"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.
#36 lore raw

PATCH 1/1 fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype

In reply to Andrew Morton
Quoted 7 lines · Andrew Morton

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

fs/cifs/cifsproto.h renamed from fs/cifs/cifsproto.h.old +0 -2
@@ -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);
#37 lore raw

Re: [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype

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 <[email protected]> wrote on 06/25/2006 06:13:29 PM:

Quoted 39 lines · Andrew Morton
Quoted 7 lines

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

--- 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

fs/cifs/cifsproto.h renamed from fs/cifs/cifsproto.h.old +0 -2
@@ -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);
#38 lore raw

PATCH 1/1 drivers/scsi/arcmsr/: cleanups

In reply to Andrew Morton

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

---

 drivers/scsi/arcmsr/arcmsr_attr.c |    2 ++
 drivers/scsi/arcmsr/arcmsr_hba.c  |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)
drivers/scsi/arcmsr/arcmsr_attr.c renamed from drivers/scsi/arcmsr/arcmsr_attr.c.old +2 -0
@@ -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) {
drivers/scsi/arcmsr/arcmsr_hba.c renamed from drivers/scsi/arcmsr/arcmsr_hba.c.old +1 -1
@@ -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;
#39 lore raw

PATCH 1/1 drivers/md/raid5.c: remove an unused variable

In reply to Andrew Morton

This patch removes an unused variable.

drivers/md/raid5.c renamed from drivers/md/raid5.c.old +0 -1
@@ -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;
#40 lore raw

2.6.17-mm2 hrtimer code wedges at boot?

In reply to Andrew Morton
Quoted 2 lines · Andrew Morton

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?

#41 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 5 lines · On Mon, 26 Jun 2006 17:41:07 EDT, [email protected] 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:

Quoted 12 lines
[  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.

#42 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to [email protected]
Quoted 45 lines · On Mon, 2006-06-26 at 17:41 -0400, [email protected] wrote:
Quoted 2 lines · Andrew Morton

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));
Quoted 5 lines

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

#43 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to [email protected]
Quoted 6 lines · On Mon, 2006-06-26 at 17:41 -0400, [email protected] wrote:
Quoted 2 lines · Andrew Morton

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.

Quoted 33 lines

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:

Quoted 8 lines
        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

#44 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 4 lines · Thomas Gleixner
Quoted 3 lines · On Mon, 2006-06-26 at 17:41 -0400, [email protected] wrote:
Quoted 2 lines · Andrew Morton

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

17-mm2/

Quoted 5 lines
Quoted 3 lines

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...)

Quoted 4 lines

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 ([email protected]) (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: [email protected]
[   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.

#45 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 5 lines · On Mon, 2006-06-26 at 22:12 -0400, [email protected] wrote:
Quoted 4 lines · Thomas Gleixner
Quoted 3 lines · On Mon, 2006-06-26 at 17:41 -0400, [email protected] wrote:
Quoted 2 lines · Andrew Morton

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

Quoted 8 lines

17-mm2/

Quoted 5 lines
Quoted 3 lines

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.

Quoted 5 lines
[   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>

Quoted 5 lines
[   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

#46 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to [email protected]

Hi,

Quoted 5 lines · On Mon, 26 Jun 2006, [email protected] 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(-)
kernel/timer.c +1 -1
Index: linux-2.6-mm/kernel/timer.c
===================================================================
@@ -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 */
#47 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 9 lines · Roman Zippel

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
===================================================================

kernel/timer.c static void update_wall_time(void) · line 1135

Quoted 8 lines
kernel/timer.c +1 -1
@@ -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?

#48 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 18 lines · On Tue, 27 Jun 2006, [email protected] wrote:
Quoted 16 lines · Roman Zippel

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
===================================================================

kernel/timer.c +1 -1
@@ -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;
 
Quoted 5 lines

kernel/timer.c static void update_wall_time(void) · line 1135

Quoted 1 line
kernel/timer.c +0 -0
 	/* 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

#49 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 9 lines · Roman Zippel
Quoted 3 lines · On Tue, 27 Jun 2006, [email protected] 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(+)
kernel/timer.c +2 -0
Index: linux-2.6-mm/kernel/timer.c
===================================================================
@@ -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);
 }
 
#50 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

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).

kernel/timer.c static inline void __get_realtime_clock_ · line 839

Quoted 7 lines

Could you please try the patch below? This should better locate which of the values goes wrong.

kernel/timer.c +2 -0
+	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?

#51 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 5 lines · On Tue, 2006-06-27 at 15:07 -0400, [email protected] 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!

Quoted 10 lines

kernel/timer.c static inline void __get_realtime_clock_ · line 839

Quoted 7 lines

Could you please try the patch below? This should better locate which of the values goes wrong.

kernel/timer.c +2 -0
+	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:

Quoted 3 lines
[   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.

Quoted 3 lines
[   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.

Quoted 6 lines
[   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

#52 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 5 lines · john stultz
Quoted 5 lines
[   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.
Quoted 7 lines
Quoted 1 line

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(-)
include/linux/clocksource.h +3 -1
Index: linux-2.6-mm/include/linux/clocksource.h
===================================================================
@@ -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;
kernel/timer.c +6 -0
Index: linux-2.6-mm/kernel/timer.c
===================================================================
@@ -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;
#53 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 5 lines · Roman Zippel

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(+)
kernel/timer.c +7 -0
Index: linux-2.6-mm/kernel/timer.c
===================================================================
@@ -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
#54 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 3 lines · Roman Zippel

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?

#55 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 7 lines · On Thu, 2006-06-29 at 19:07 -0400, [email protected] wrote:
Quoted 3 lines · Roman Zippel

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!

Quoted 9 lines

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

arch/i386/kernel/tsc.c +8 -11
index 7e0d8da..68d23f0 100644
@@ -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)
#56 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 10 lines · john stultz

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.

#57 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 4 lines · On Fri, 30 Jun 2006, [email protected] wrote:

*AHA* I *found* the bugger, I think.

In kernel/timer.c, we have:

Quoted 8 lines

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(+)
kernel/timer.c +14 -0
Index: 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();
+		}
 	}
 }
 
#58 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 7 lines · Roman Zippel

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

#59 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 4 lines · Daniel Walker

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? :)

#60 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 7 lines · On Sun, 2006-07-02 at 22:20 -0400, [email protected] wrote:
Quoted 4 lines · Daniel Walker

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

#61 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to Daniel Walker
Quoted 5 lines · Daniel Walker

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

#62 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 7 lines · john stultz
Quoted 5 lines · Daniel Walker

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

Quoted 6 lines

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

#63 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to Roman Zippel
Quoted 17 lines · Roman Zippel

Hi,

Quoted 4 lines · On Fri, 30 Jun 2006, [email protected] wrote:

*AHA* I *found* the bugger, I think.

In kernel/timer.c, we have:

Quoted 8 lines

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.

Quoted 7 lines

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 ([email protected]) (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: [email protected]
[   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
#64 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 1 line · On Wed, 5 Jul 2006, [email protected] 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.

Quoted 7 lines
[   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

#65 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 11 lines · Roman Zippel

Hi,

Quoted 7 lines · On Wed, 5 Jul 2006, [email protected] 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
Quoted 7 lines

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.

Quoted 2 lines

I have to run some tests and later this week there should be a new patch compensating for this.

Look forward to it.

Quoted 3 lines

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

#66 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to Roman Zippel
Quoted 7 lines · Roman Zippel

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:

kernel/timer.c static int __init timekeeping_init_devic

Quoted 7 lines

Implement P-D control for clocksource_adjust()

kernel/timer.c +0 -0
index 396a3c0..f4e7681 100644
@@ -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. ;)

#67 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to [email protected]
Quoted 26 lines · On Wed, 2006-07-05 at 00:29 -0400, [email protected] wrote:
Quoted 17 lines · Roman Zippel

Hi,

Quoted 4 lines · On Fri, 30 Jun 2006, [email protected] wrote:

*AHA* I *found* the bugger, I think.

In kernel/timer.c, we have:

Quoted 8 lines

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.

Quoted 7 lines

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).

Quoted 3 lines

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

Quoted 6 lines

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.

Quoted 1 line
[    0.000000] Detected 1595.408 MHz processor.

...

Quoted 1 line
[   24.322196] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04

...

Quoted 3 lines
[   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...

Quoted 2 lines
[   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()

kernel/timer.c +95 -66
index 396a3c0..f4e7681 100644
@@ -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;
#68 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 9 lines · john stultz

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

#69 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 5 lines · john stultz
Quoted 4 lines · john stultz

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).

Quoted 7 lines
Quoted 5 lines

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?

Quoted 2 lines

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

kernel/hrtimer.c +1 -1
index d17766d..3f516f6 100644
@@ -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));
kernel/timer.c +3 -0
index 396a3c0..5394104 100644
@@ -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;
 
#70 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to john stultz

Hi,

Quoted 10 lines · john stultz

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.

Quoted 22 lines
kernel/timer.c +22 -0
+		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);

kernel/timer.c static int __init timekeeping_init_devic · line 1071

Quoted 10 lines
kernel/timer.c +10 -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.

Quoted 20 lines
kernel/timer.c +20 -0
+		/* 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);

kernel/timer.c static int __init timekeeping_init_devic · line 1101

Quoted 10 lines
kernel/timer.c +10 -0
+			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

#71 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Quoted 15 lines · Roman Zippel

Hi,

Quoted 10 lines · john stultz

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).

Quoted 5 lines

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.

Quoted 27 lines
Quoted 27 lines
kernel/timer.c +27 -0
+		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, 
Quoted 8 lines

kernel/timer.c static int __init timekeeping_init_devic · line 1071

Quoted 5 lines
kernel/timer.c +5 -0
+						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.

Quoted 5 lines

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.

Quoted 28 lines
Quoted 28 lines
kernel/timer.c +28 -0
+		/* 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;
Quoted 8 lines

Review

Quoted 2 lines
(quoted diff) +2 -0
+			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).

Quoted 3 lines

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

#72 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 4 lines · john stultz

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).

Quoted 11 lines
Quoted 3 lines

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(-)
kernel/timer.c +56 -33
Index: linux-2.6-mm/kernel/timer.c
===================================================================
@@ -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;
#73 lore raw

PATCH 1/1 adjust clock for lost ticks

In reply to john stultz

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.

---
 kernel/timer.c |   85 +++++++++++++++++++++++++++++++--------------------------
 1 file changed, 47 insertions(+), 38 deletions(-)
kernel/timer.c +47 -38
Index: linux-2.6-mm/kernel/timer.c
===================================================================
@@ -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 */
Acked-by on v1 1/1
#74 lore raw

Re: [PATCH] adjust clock for lost ticks

Quoted 6 lines · Roman Zippel

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.

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:

-john

#75 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

In reply to Roman Zippel
Quoted 17 lines · Roman Zippel

Hi,

Quoted 5 lines · john stultz
Quoted 5 lines
[   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.
Quoted 7 lines
Quoted 1 line

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.

Quoted 5 lines

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.

Quoted 10 lines

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.

arch/i386/kernel/tsc.c +1 -1
index 7e0d8da..24af443 100644
@@ -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);
#76 lore raw

Re: 2.6.17-mm2 hrtimer code wedges at boot?

Hi,

Quoted 4 lines · john stultz

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.

Quoted 4 lines

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()?

Quoted 4 lines

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

#77 lore raw

PATCH 1/1 include/asm-i386/acpi.h should #include <asm/processor.h>

In reply to Andrew Morton
Quoted 7 lines · Andrew Morton

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

include/asm-i386/acpi.h renamed from include/asm-i386/acpi.h.old +1 -0
@@ -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
#78 lore raw

PATCH 1/1 fix sgivwfb compile

In reply to Andrew Morton

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 -->

---

 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(-)
include/asm-i386/mach-visws/setup_arch.h renamed from include/asm-i386/mach-visws/setup_arch.h.old +3 -0
@@ -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
arch/i386/mach-visws/setup.c renamed from arch/i386/mach-visws/setup.c.old +2 -2
@@ -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;
 
drivers/video/sgivwfb.c renamed from drivers/video/sgivwfb.c.old +2 -4
@@ -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;
 
#79 lore raw

PATCH 1/1 arch/i386/mach-visws/setup.c: remove dummy function calls

In reply to Andrew Morton

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.

arch/i386/mach-visws/setup.c renamed from arch/i386/mach-visws/setup.c.old +0 -4
@@ -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);
 }