linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.6.17-mm2
@ 2006-06-24 13:19 Andrew Morton
  2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki
                   ` (14 more replies)
  0 siblings, 15 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-24 13:19 UTC (permalink / raw)
  To: linux-kernel


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


- The locking validator patches have all been dropped - Ingo is redoing the
  patch series.

- The arch-secific parts of the generic IRQ rework have been dropped, so
  it's a do-nothing patch series at present.  If we can verify that it indeed
  does nothing then we might be able to squeak it into 2.6.18 for powerpc to
  merge against.

- The kgdb patches have been tempdropped.  Partly to make merging of other
  things easier, partly because someone broke it.

- The various little -mm-only debugging patches have been temporarily
  dropped, to make followon patching easier.




Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

        echo "subscribe mm-commits" | mail majordomo@vger.kernel.org

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

        http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.



Changes since 2.6.17-mm1:


 origin.patch
 git-agpgart.patch
 git-cifs.patch
 git-dvb.patch
 git-gfs2.patch
 git-ia64.patch
 git-infiniband.patch
 git-input.patch
 git-jfs.patch
 git-kbuild.patch
 git-klibc.patch
 git-hdrinstall2.patch
 git-libata-all.patch
 git-mtd.patch
 git-netdev-all.patch
 git-ocfs2.patch
 git-pcmcia.patch
 git-s390.patch
 git-scsi-target.patch
 git-supertrak.patch
 git-watchdog.patch
 git-xfs.patch
 git-cryptodev.patch 

 git trees


-ehci-works-again-on-nvidia-controllers-with-2gb-ram.patch
-uml-fix-wall_to_monotonic-initialization.patch
-sparc-build-breakage.patch
-ntfs-critical-bug-fix-affects-mips-and-possibly-others.patch
-selinux-add-hooks-for-key-subsystem.patch
-keys-fix-race-between-two-instantiators-of-a-key.patch
-suspend_console-warning-fix.patch
-myri10ge-build-fix.patch
-for_each_possible_cpu-xfs.patch
-revert-powernow-k8-crash-workaround.patch
-git-acpi-fixup.patch
-git-acpi-ia64-build-fix.patch
-reapply-powernow-k8-crash-workaround.patch
-ati-agp-build-fix.patch
-create-sys-hypervisor-when-needed.patch
-gregkh-driver-kobject_add-make-people-pay-attention-to-errors.patch
-gregkh-driver-stable-abi-docs.patch
-gregkh-driver-cciss-device-symlink.patch
-gregkh-driver-driver-core-bus-device-event-delay.patch
-gregkh-driver-tty-return-class-device-pointer-from-tty_register_device.patch
-gregkh-driver-i4l-gigaset-move-sysfs-entry-to-tty-class-device.patch
-gregkh-driver-driver-core-class_device_add-needs-error-checks.patch
-gregkh-driver-driver-core-config_debug_pm-covers-drivers-base-power-too.patch
-gregkh-driver-platform_bus-learns-about-modalias.patch
-gregkh-driver-driver-core-remove-exports.patch
-gregkh-driver-driver-core-allow-sysdev_class-have-attributes.patch
-gregkh-driver-driver-core-fix-platform_device_add-to-use-device_add.patch
-gregkh-driver-remove-duplication-from-documentation-power-devices_txt.patch
-gregkh-driver-driver-core-pm_debug-device-suspend-messages-become-informative.patch
-gregkh-driver-firmware_class-s-semaphores-mutexes.patch
-gregkh-driver-make_class_name-kobj.patch
-gregkh-driver-device-class.patch
-gregkh-driver-driver-core-add-generic-subsystem-link-to-all-devices.patch
-gregkh-driver-device-symlinks-for-classes.patch
-gregkh-driver-driver-core-make-dev_info-and-friends-print-the-bus-name-if-there-is-no-driver.patch
-gregkh-driver-driver-model-add-isa-bus.patch
-saa7134-card-lifeview3000-ntsc.patch
-gregkh-i2c-hwmon-lm83-add-lm82-support.patch
-gregkh-i2c-hwmon-w83627ehf-add-voltages.patch
-gregkh-i2c-hwmon-w83627ehf-add-alarms.patch
-gregkh-i2c-hwmon-smsc47m192-new-driver.patch
-gregkh-i2c-hwmon-f71805f-no-global-resource.patch
-gregkh-i2c-hwmon-sysfs-interface-individual-alarm-files.patch
-gregkh-i2c-i2c-piix4-add-ati-smbus-support.patch
-gregkh-i2c-rtc-m41t00-driver-cleanup.patch
-gregkh-i2c-rtc-add-support-for-m41t81-m41t85-chips-to-m41t00-driver.patch
-gregkh-i2c-i2c-piix4-remove-fix_hstcfg-parameter.patch
-gregkh-i2c-i2c-piix4-fix-typo-in-documentation.patch
-gregkh-i2c-i2c-piix4-improve-ibm-error-message.patch
-gregkh-i2c-i2c-nforce2-add-mcp51-mcp55-support.patch
-gregkh-i2c-hwmon-hdaps-update-id-list.patch
-gregkh-i2c-hwmon-w83791d-new-driver.patch
-gregkh-i2c-hwmon-lm83-documentation-update.patch
-gregkh-i2c-hwmon-improve-Kconfig-help.patch
-gregkh-i2c-hwmon-vid-mask-per-vrm.patch
-gregkh-i2c-i2c-Kconfig-suggest-N-for-rare-devices.patch
-gregkh-i2c-i2c-opencores-new-driver.patch
-gregkh-i2c-hwmon-sysfs-interface-update-1.patch
-gregkh-i2c-hwmon-sysfs-interface-update-2.patch
-gregkh-i2c-hwmon-hdaps-typo.patch
-gregkh-i2c-hwmon-maintenance-update.patch
-gregkh-i2c-hwmon-w83792d-pwm-set-fix.patch
-gregkh-i2c-hwmon-w83792d-add-data-lock.patch
-gregkh-i2c-hwmon-abituguru-new-driver.patch
-gregkh-i2c-hwmon-abituguru-fixes.patch
-gregkh-i2c-hwmon-abituguru-nofans-detect-fix.patch
-gregkh-i2c-i2c-opencores-cleanup.patch
-gregkh-i2c-i2c-mark-data-const-for-write-block.patch
-gregkh-i2c-i2c-scx200_acb-use-PCI-IO-resource-when-appropriate.patch
-gregkh-i2c-i2c-scx200_acb-mark-scx200_acb_probe-init.patch
-gregkh-i2c-i2c-scx200_acb-documentation-update.patch
-gregkh-i2c-i2c-i801-01-fix-block-transaction-poll-loops.patch
-gregkh-i2c-i2c-i801-02-remove-force_addr-parameter.patch
-gregkh-i2c-i2c-i801-03-remove-pci-function-check.patch
-gregkh-i2c-i2c-i801-04-cleanups.patch
-gregkh-i2c-i2c-i801-05-better-pci-subsystem-integration.patch
-gregkh-i2c-i2c-i801-06-merge-setup-function.patch
-gregkh-i2c-hwmon-kconfig-header-fix.patch
-gregkh-i2c-hwmon-lm70-new-driver.patch
-gregkh-i2c-hwmon-vid-add-core-and-conroe-support.patch
-gregkh-i2c-i2c-i2c-controllers-go-into-right-place-on-sysfs.patch
-gregkh-i2c-w1-added-default-generic-read-write-operations.patch
-gregkh-i2c-w1-replace-dscore-and-ds_w1_bridge-with-ds2490-driver.patch
-gregkh-i2c-w1-userspace-communication-protocol-over-connector.patch
-gregkh-i2c-w1-move-w1-connector-definitions-into-linux-include-connector.h.patch
-gregkh-i2c-w1-netlink-mark-netlink-group-1-as-unused.patch
-gregkh-i2c-w1-make-w1-connector-notifications-depend-on-connector.patch
-gregkh-i2c-w1-use-mutexes-instead-of-semaphores.patch
-gregkh-i2c-w1-exports.patch
-gregkh-i2c-w1-cleanups.patch
-gregkh-i2c-w1-possible-cleanups.patch
-gregkh-i2c-w1-fix-dependencies-of-w1_slave_ds2433_crc.patch
-gregkh-i2c-drivers-w1-w1.c-fix-a-compile-error.patch
-gregkh-i2c-w1-clean-up-w1_con-dependency.patch
-gregkh-i2c-w1-warning-fix.patch
-git-infiniband-fixup.patch
-git-libata-all-fixup.patch
-git-libata-all-data_xfer-fixes.patch
-git-libata-all-data_xfer-fixes-fixes.patch
-git-libata-pata_cs5535-is-bust.patch
-gregkh-pci-pci-hotplug-tollhouse-hp-sgi-hotplug-driver-changes.patch
-gregkh-pci-acpiphp-configure-_prt-v3.patch
-gregkh-pci-acpiphp-hotplug-slot-hotplug.patch
-gregkh-pci-acpiphp-host-and-p2p-hotplug.patch
-gregkh-pci-acpiphp-turn-off-slot-power-at-error-case.patch
-gregkh-pci-pci-hotplug-don-t-use-acpi_os_free.patch
-gregkh-pci-pciehp-dont-call-pci_enable_dev.patch
-gregkh-pci-acpi_pcihp-fix-programming-_hpp-values.patch
-gregkh-pci-acpi_pcihp-remove-improper-error-message-about-oshp.patch
-gregkh-pci-acpi_pcihp-add-support-for-_hpx.patch
-gregkh-pci-pciehp-fix-programming-hotplug-parameters.patch
-gregkh-pci-shpc-cleanup-shpc-register-access.patch
-gregkh-pci-shpc-cleanup-shpc-logical-slot-register-access.patch
-gregkh-pci-shpc-cleanup-shpc-logical-slot-register-bits-access.patch
-gregkh-pci-shpc-fix-shpc-logical-slot-register-bits-access.patch
-gregkh-pci-shpc-fix-shpc-contoller-serr-int-register-bits-access.patch
-gregkh-pci-shpchp-mask-global-serr-and-intr-at-controller-release-time.patch
-gregkh-pci-shpchp-create-shpchpd-at-controller-probe-time.patch
-gregkh-pci-sgi-hotplug-incorrect-power-status.patch
-gregkh-pci-pciehp-replace-pci_find_slot-with-pci_get_slot.patch
-gregkh-pci-pciehp-add-missing-pci_dev_put.patch
-gregkh-pci-pciehp-implement-get_address-callback.patch
-gregkh-pci-shpchp-remove-unnecessary-hpc_ctlr_handle-check.patch
-gregkh-pci-shpchp-cleanup-interrupt-handler.patch
-gregkh-pci-shpchp-cleanup-shpc-commands.patch
-gregkh-pci-shpchp-cleanup-interrupt-polling-timer.patch
-gregkh-pci-shpchp-remove-unused-hpc_evelnt_lock.patch
-gregkh-pci-shpchp-cleanup-improper-info-messages.patch
-gregkh-pci-pci-hotplug-fake-null-pointer-dereferences-in-ibm-hot-plug-controller-driver.patch
-gregkh-pci-pci-hotplug-fix-recovery-path-from-errors-during-pcie_init.patch
-gregkh-pci-pci-add-pci_cap_id_vndr.patch
-gregkh-pci-pci-msi-abstractions-and-support-for-altix.patch
-gregkh-pci-pci-per-platform-ia64_-first-last-_device_vector-definitions.patch
-gregkh-pci-pci-altix-msi-support.patch
-gregkh-pci-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
-gregkh-pci-pci-fix-to-pci-ignore-pre-set-64-bit-bars-on-32-bit-platforms.patch
-gregkh-pci-pci-add-pci_assign_resource_fixed-allow-fixed-address-assignments.patch
-gregkh-pci-pci-add-a-enable-sysfs-attribute-to-the-pci-devices-to-allow-userspace-to-enable-devices-without-doing-foul-direct-access.patch
-gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch
-gregkh-pci-pci-acpi-rename-the-functions-to-avoid-multiple-instances.patch
-gregkh-pci-pci-i386-x86_84-disable-pci-resource-decode-on-device-disable.patch
-gregkh-pci-pci-bus-parity-status-broken-hardware-attribute-edac-foundation.patch
-gregkh-pci-pci-move-various-pci-ids-to-header-file.patch
-gregkh-pci-pci-amd-8131-msi-quirk-called-too-late-bus_flags-not-inherited.patch
-gregkh-pci-pci-allow-msi-to-work-on-kexec-kernel.patch
-gregkh-pci-pci-disable-msi-mode-in-pci_disable_device.patch
-gregkh-pci-pci-cleanup-unused-variable-about-msi-driver.patch
-gregkh-pci-pci-don-t-move-ioapics-below-pci-bridge.patch
-gregkh-pci-pci-remove-unneeded-msi-code.patch
-gregkh-pci-pci-clean-up-pci-documentation-to-be-more-specific.patch
-gregkh-pci-pci-fix-race-with-pci_walk_bus-and-pci_destroy_dev.patch
-gregkh-pci-pci-msi-k8t-neo2-fir-run-only-where-needed.patch
-gregkh-pci-fix-pci_get_device-usage-in-mpc85xx.patch
-gregkh-pci-pci-fix-memory-leak-in-mmconfig-error-path.patch
-gregkh-pci-pci-bus-parity-status-sysfs-interface.patch
-gregkh-pci-pci-fix-issues-with-extended-conf-space-when-mmconfig-disabled-because-of-e820.patch
-gregkh-pci-pci-nvidia-quirk-to-make-aer-pci-e-extended-capability-visible.patch
-gregkh-usb-usb-add-yealink-phones-to-the-hid_quirk_ignore-blacklist.patch
-gregkh-usb-usb-cdc-acm-add-a-new-special-case-for-modems-with-buggy-firmware.patch
-gregkh-usb-usb-usbnet-zaurus-mtu-fixup.patch
-gregkh-usb-usb-added-support-for-asix-88178-chipset-usb-gigabit-ethernet-adaptor.patch
-gregkh-usb-usb-convert-the-semaphores-in-the-sisusb-driver-to-mutexes.patch
-gregkh-usb-usb-sisusbvga-possible-cleanups.patch
-gregkh-usb-usb-allow-multiple-types-of-ehci-controllers-to-be-built-as-modules.patch
-gregkh-usb-usb-console-fix-cr-lf-issues.patch
-gregkh-usb-usb-console-fix-oops.patch
-gregkh-usb-usb-console-prevent-enodev-on-node.patch
-gregkh-usb-usb-console-fix-disconnection-issues.patch
-gregkh-usb-usb-macbook-pro-touchpad-support.patch
-gregkh-usb-usb-usbcore-always-turn-on-hub-port-power.patch
-gregkh-usb-usb-clean-out-an-unnecessary-null-check-from-ub.patch
-gregkh-usb-usbatm-remove-pointless-inline.patch
-gregkh-usb-usbatm-remove-no-longer-needed-include.patch
-gregkh-usb-usb-phidget-interfacekit-make-inputs-pollable-and-new-device-support.patch
-gregkh-usb-usb-shuttle_usbat-fix-handling-of-scatter-gather-buffers.patch
-gregkh-usb-usb-shuttle_usbat-hardcode-detection-of-hp-cdrw-devices.patch
-gregkh-usb-usb-shuttle_usbat-hardcode-flash-detection-for-now.patch
-gregkh-usb-usb-usb-storage-alauda-fix-transport-info-mismerge.patch
-gregkh-usb-usb-net2280-add-a-shutdown-routine.patch
-gregkh-usb-usb-uhci-store-the-endpoint-type-in-the-qh-structure.patch
-gregkh-usb-usb-uhci-fix-obscure-bug-in-enqueue.patch
-gregkh-usb-usb-hid-hidbp-input-drivers-fix-various-usb-input-hid-input.c-bugs-that-make-apple-mighty-mouse-work-poorly.patch
-gregkh-usb-usbhid-automatically-set-hid_quirk_noget-for-keyboards-and-mice.patch
 gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch
-gregkh-usb-uhci-common-result-routine-for-control-bulk-interrupt.patch
-gregkh-usb-uhci-remove-non-iso-tds-as-they-are-used.patch
-gregkh-usb-uhci-move-code-for-cleaning-up-unlinked-urbs.patch
-gregkh-usb-uhci-eliminate-the-td-removal-list.patch
-gregkh-usb-uhci-reimplement-fsbr.patch
-gregkh-usb-uhci-work-around-old-intel-bug.patch
-gregkh-usb-usb-correct-the-usb-info-in-documentation-power-swsusp_txt.patch
-gregkh-usb-usb-remove-4088-byte-limit-on-usbfs-control-urbs.patch
-gregkh-usb-usb-allow-high-bandwidth-isochronous-packets-via-usbfs.patch
-gregkh-usb-uhci-use-integer-sized-frame-numbers.patch
-gregkh-usb-uhci-fix-race-in-iso-dequeuing.patch
-gregkh-usb-uhci-store-the-period-in-the-queue-header.patch
-gregkh-usb-uhci-remove-iso-tds-as-they-are-used.patch
-gregkh-usb-fix-a-deadlock-in-usbtest.patch
-gregkh-usb-usb_interrupt_msg.patch
-gregkh-usb-usb-new-cp2101-device.patch
-gregkh-usb-gadgetfs-fix-aio-interface-bugs.patch
-gregkh-usb-gadgetfs-fix-memory-leaks.patch
-gregkh-usb-usbtest-report-errors-in-iso-tests.patch
-gregkh-usb-usb-io_edgeport-cleanup-to-unicode-handling.patch
-gregkh-usb-usb-serial-encapsulate-schedule_work-remove-double-calling.patch
-gregkh-usb-usb-improve-kconfig-comment-for-mct_u232.patch
-gregkh-usb-usb-syntax-cleanup-for-pl2303.patch
-gregkh-usb-usb-storage-get-rid-of-the-timer-during-urb-submission.patch
-gregkh-usb-improved-tt-scheduling-for-ehci.patch
-gregkh-usb-usb-rmmod-pl2303-after-28.patch
-gregkh-usb-ub-atomic-add_disk.patch
-gregkh-usb-ub-random-cleanups.patch
-gregkh-usb-usb-more-pegasus-log-spamming-removed.patch
-gregkh-usb-usb-print-message-when-device-is-rejected-due-to-insufficient-power.patch
-gregkh-usb-usbcore-fix-broken-rndis-config-selection.patch
-gregkh-usb-usbhid-remove-unneeded-blacklist-entries.patch
-gregkh-usb-usb-ftdi_sio-add-support-for-yost-engineering-servocenter3.1.patch
-gregkh-usb-driver-for-apple-cinema-display.patch
-gregkh-usb-usb-whiteheat-fix-firmware-spurious-errors.patch
-gregkh-usb-usb-add-sierra-wireless-mc5720-id-to-airprime.c.patch
-gregkh-usb-usb-negative-index-in-drivers-usb-host-isp116x-hcd.c.patch
-gregkh-usb-usb-cdc_ether-recognize-olympus-r1000.patch
-gregkh-usb-usbcore-port-reset-for-composite-devices.patch
-gregkh-usb-usb-hub-use-usb_reset_composite_device.patch
-gregkh-usb-usb-storage-use-usb_reset_composite_device.patch
-gregkh-usb-usbhid-use-usb_reset_composite_device.patch
-gregkh-usb-usbcore-recovery-from-set-configuration-failure.patch
-gregkh-usb-usb-drivers-usb-core-devio.c-dereferences-a-userspace-pointer.patch
-gregkh-usb-usb-new-devices-for-the-option-driver.patch
-gregkh-usb-usb-free-allocated-memory-on-io_edgeport-startup-memory-failure.patch
-gregkh-usb-usb-ehci-on-non-au1200-build-fix.patch
-gregkh-usb-usb-add-apple-macbook-product-ids-to-usbhid.patch
-gregkh-usb-usb-storage-unusual_devs-entry-for-nikon-dsc-d70s.patch
-gregkh-usb-uhci-various-updates.patch
-gregkh-usb-uhci-remove-hc_inaccessible-flag.patch
-gregkh-usb-uhci-improve-fsbr-off-timing.patch
-gregkh-usb-airprime.c-add-kyocera-wireless-kpc650-passport-support.patch
-gregkh-usb-usb-io_edgeport-touch-up.patch
-gregkh-usb-usb-update-usbmon-fix-glued-lines.patch
-gregkh-usb-usb-implement-error-event-in-usbmon.patch
-gregkh-usb-usb-update-usbmontxt.patch
-gregkh-usb-usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers.patch
-gregkh-usb-usb-trivial-debug-message-correction-in-gadget-ether-driver.patch
-gregkh-usb-usb-serial-clean-tty-fields-on-failed-device-open.patch
-gregkh-usb-usb-gadget-serial-fix-a-deadlock-when-closing-the-serial-device.patch
-gregkh-usb-usb-gadget-serial-do-not-save-restore-irq-flags-in-gs_close.patch
-gregkh-usb-usb-gadget-allow-drivers-support-speeds-higher-than-full-speed.patch
-gregkh-usb-usb-gadget-fix-compile-errors.patch
-gregkh-usb-usb-gadget-update-pxa2xx_udc.c-driver-to-fully-support-ixp4xx-platform.patch
-gregkh-usb-usbserial-fixes-wrong-return-values.patch
-gregkh-usb-usb-unusual_devs-entry-for-nokia-n80.patch
-gregkh-usb-usb-whitespace-removal-from-usb-gadget-ether.patch
-gregkh-usb-usb-move-linux-usb_cdc.h-to-linux-usb-cdc.h.patch
-gregkh-usb-usb-move-hardware-specific-linux-usb_-.h-to-linux-usb-.h.patch
-gregkh-usb-usb-move-linux-usb_input.h-to-linux-usb-input.h.patch
-gregkh-usb-usb-endpoint.patch
-gregkh-usb-usb-endpoint-pass-struct-device.patch
-gregkh-usb-usb-endpoint-mess.patch
-gregkh-usb-usb-devio-class-to-device.patch
-gregkh-usb-usb-class-device-to-device.patch
-gregkh-usb-usb-dynamic-usb-class.patch
-x86_64-mm-agp-select.patch
-xfs-remove-dir-check-in-xfs_link.patch
-xfs-use-container_of-in-vn_from_inode.patch
-xfs-remove-unused-behaviour-lock.patch
-zone-handle-unaligned-zone-boundaries.patch
-page-migration-make-do_swap_page-redo-the-fault.patch
-slab-extract-cache_free_alien-from-__cache_free.patch
-pg_uncached-is-ia64-only.patch
-slab-page-mapping-cleanup.patch
-migration-remove-unnecessary-pageswapcache-checks.patch
-wait_table-and-zonelist-initializing-for-memory-hotadd-change-name-of-wait_table_size.patch
-wait_table-and-zonelist-initializing-for-memory-hotadd-change-to-meminit-for-build_zonelist.patch
-wait_table-and-zonelist-initializing-for-memory-hotaddadd-return-code-for-init_current_empty_zone.patch
-wait_table-and-zonelist-initializing-for-memory-hotadd-wait_table-initialization.patch
-wait_table-and-zonelist-initializing-for-memory-hotadd-update-zonelists.patch
-squash-duplicate-page_to_pfn-and-pfn_to_page.patch
-support-for-panic-at-oom.patch
-mm-fix-typos-in-comments-in-mm-oom_killc.patch
-reserve-space-for-swap-label.patch
-tightening-hugetlb-strict-accounting.patch
-slab-cleanup-kmem_getpages.patch
-slab-stop-using-list_for_each.patch
-swsusp-rework-memory-shrinker-rev-2.patch
-unify-pxm_to_node-and-node_to_pxm.patch
-mm-introduce-remap_vmalloc_range.patch
-change-gen_pool-allocator-to-not-touch-managed-memory.patch
-radix-tree-direct-data.patch
-radix-tree-small.patch
-likely-cleanup-remove-unlikely-in-sys_mprotect.patch
-slab-redzone-double-free-detection.patch
-buglet-in-radix_tree_tag_set.patch
-writeback-fix-range-handling.patch
-page-migration-cleanup-rename-ignrefs-to-migration.patch
-page-migration-cleanup-group-functions.patch
-page-migration-cleanup-remove-useless-definitions.patch
-page-migration-cleanup-drop-nr_refs-in-remove_references.patch
-page-migration-cleanup-extract-try_to_unmap-from-migration-functions.patch
-page-migration-cleanup-pass-mapping-to-migration-functions.patch
-page-migration-cleanup-move-fallback-handling-into-special-function.patch
-swapless-pm-add-r-w-migration-entries.patch
-swapless-pm-add-r-w-migration-entries-fix.patch
-swapless-page-migration-rip-out-swap-based-logic.patch
-swapless-page-migration-modify-core-logic.patch
-more-page-migration-do-not-inc-dec-rss-counters.patch
-more-page-migration-use-migration-entries-for-file-pages.patch
-page-migration-update-documentation.patch
-slab-verify-pointers-before-free.patch
-sparsemem-record-nid-during-memory-present.patch
-mm-cleanup-swap-unused-warning.patch
-add-page_mkwrite-vm_operations-method.patch
-add-page_mkwrite-vm_operations-method-fix.patch
-swapoff-atomic_inc_not_zero-on-mm_users.patch
-remove-unused-o_flags-from-do_shmat.patch
-fix-update_mmu_cache-in-fremapc.patch
-fix-update_mmu_cache-in-fremapc-fix.patch
-mm-slabc-fix-early-init-assumption.patch
-initialise-total_memory-earlier.patch
-update-vm_total_pages-at-memory-hotadd.patch
-slab-kmalloc-kzalloc-comments-cleanup-and-fix.patch
-kernel-doc-for-mm-filemapc.patch
-delete-unused-definitions-of-kvaddr_to_nid.patch
-printk-should-not-be-called-under-zone-lock.patch
-page-migration-simplify-migrate_pages.patch
-page-migration-handle-freeing-of-pages-in-migrate_pages.patch
-page-migration-use-allocator-function-for-migrate_pages.patch
-page-migration-support-moving-of-individual-pages.patch
-page-migration-support-moving-of-individual-pages-x86_64-support.patch
-page-migration-support-moving-of-individual-pages-x86-support.patch
-lsm-add-task_setioprio-hook.patch
-selinux-add-security-hooks-to-getsetaffinity.patch
-selinux-add-security-hook-call-to-mediate-attach_task.patch
-frv-__user-infrastructure.patch
-frv-basic-__iomem-annotations.patch
-frv-signal-annotations.patch
-frv-sysctl-__user-annotations.patch
-frv-binfmt_elf_fdpic-__user-annotations.patch
-frv-misc-__user-annotations.patch
-frv-misc-sparse-annotations.patch
-frv-wrong-syscall.patch
-ext2-xip-wont-build-without-mmu.patch
-frv-initrd-is-grossly-broken-on-frv-never-built.patch
-frv-null-noise-removal-in-frv-xchg.patch
-frv-ieee1394-is-borken-on-frv.patch
-frv-add-missing-qualifier-to-memcpy_fromio-prototype.patch
-frv-trivial-cleanups-in-frv_ksymsc.patch
-frv-clean-frv-unistdh.patch
-au1550-1200-add-missing-psc-defines-make-oss-driver-use.patch
-x86-cache-pollution-aware-__copy_from_user_ll.patch
-arch-i386-kernel-apicc-make-modern_apic-static.patch
-i386-apmc-optimization.patch
-x86-dont-trigger-full-rebuild-via-config_mtrr.patch
-fix-x86-microcode-driver-handling-of-multiple-matching.patch
-i386-break-out-of-recursion-in-stackframe-walk.patch
-dont-trigger-full-rebuild-via-config_x86_mce.patch
-x86-call-eisa_set_level_irq-in-pcibios_lookup_irq.patch
-x86-kernel-irq-balancer-fix.patch
-x86-kernel-irq-balancer-fix-tidy.patch
-i386-let-usermode-execute-the-enter.patch
-fix-broken-vm86-interrupt-signal-handling.patch
-x86-make-using_apic_timer-__read_mostly.patch
-x86-cyrix-code-config_pci-fix--add-__initdata.patch
-x86-make-i387-mxcsr_feature_mask-__read_mostly.patch
-x86-make-acpi-errata-__read_mostly.patch
-x86-constify-arch-i386-pci-irqc.patch
-x86-use-proper-defines-for-i8259a-i-o.patch
-i386-fix-get_segment_eip-with-vm86.patch
-i386-dont-try-kprobes-for-v8086-mode.patch
-i386-extra-checks-in-show_registers.patch
-via-c7-cpu-flags.patch
-x86-compile-fix-for-asm-i386-alternativesh.patch
-remove-duplicate-symbol-exports-on-alpha.patch
-remove-empty-node-at-boot-time.patch
-swsusp-add-architecture-special-saveable-pages-support.patch
-swsusp-i386-mark-special-saveable-unsaveable-pages.patch
-swsusp-x86_64-mark-special-saveable-unsaveable-pages.patch
-swsusp-take-lowmem-reserves-into-account.patch
-kernel-power-snapshotc-cleanups.patch
-swsusp-use-less-memory-during-resume.patch
-dont-use-flush_tlb_all-in-suspend-time.patch
-swsusp-documentation-updates.patch
-move-do_suspend_lowlevel-to-correct-segment.patch
-m68k-completely-initialize-hw_regs_t-in-ide_setup_ports.patch
-m68k-atyfb_base-compile-fix-for-config_pci=n.patch
-m68k-cleanup-unistdh.patch
-m68k-remove-some-unused-definitions-in-zorroh.patch
-m68k-use-c99-initializer.patch
-m68k-print-correct-stack-trace.patch
-m68k-restore-amikbd-compatibility-with-24.patch
-m68k-extra-delay.patch
-m68k-use-proper-defines-for-zone-initialization.patch
-m68k-adjust-to-changed-hardirq_mask.patch
-m68k-m68k-mac-via2-fixes-and-cleanups.patch
-m68k-clean-up-uaccessh.patch
-m68k-typo-fix.patch
-m68k-trapsc-constraints.patch
-m68k-windfarm-is-powerpc-only-dont-do-it-on-m68k-macs.patch
-xtensa-remove-verify_area-macros.patch
-xtensa-remove-verify_area-macros-fix.patch
-s390_hypfs-filesystem.patch
-fix-a-race-condition-between-i_mapping-and-iput.patch
-add-a-sysfs-file-to-determine-if-a-kexec-kernel-is-loaded.patch
-insert-identical-resources-above-existing-resources.patch
-remove-steal_locks.patch
-avoid-tasklist_lock-at-getrusage-for-multithreaded-case-too.patch
-#writeback-fix-range-handling.patch
-fix-dcache-race-during-umount.patch
-prune_one_dentry-tweaks.patch
-vgacon-make-vga_map_mem-take-size-remove-extra-use.patch
-zlib_inflate-upgrade-library-code-to-a-recent-version.patch
-zlib_inflate-upgrade-library-code-to-a-recent-version-fix.patch
-initramfs-cpio-unpacking-fix.patch
-fix-cdrom-being-confused-on-using-kdump.patch
-read_mapping_page-for-address-space.patch
-locks-dont-unnecessarily-fail-posix-lock-operations.patch
-locks-dont-do-unnecessary-allocations.patch
-locks-clean-up-locks_remove_posix.patch
-vfs-add-lock-owner-argument-to-flush-operation.patch
-fs-locksc-make-posix_locks_deadlock-static.patch
-moduleh-updated-comments-with-a-new.patch
-remove-config_parport_arc-drivers-parport-parport_arcc.patch
-mmput-might-sleep.patch
-fs-fat-miscc-unexport-fat_sync_bhs.patch
-poll-cleanups-microoptimizations.patch
-ptrace-document-the-locking-rules.patch
-cleanup-default-value-of-sched_smt.patch
-cleanup-default-value-of-syscall_debug.patch
-cleanup-default-value-of-usb_isp116x_hcd-usb_sl811_hcd-and-usb_sl811_cs.patch
-cleanup-default-value-of-ip_dccp_ackvec.patch
-cleanup-default-value-of-dvb_cinergyt2_enable_rc_input_device.patch
-dup-fd-error.patch
-cond-resched-might-sleep-fix.patch
-enhancing-accessibility-of-lxdialog.patch
-the-scheduled-unexport-of-insert_resource.patch
-jbd-fix-bug-in-journal_commit_transaction.patch
-jbd-fix-bug-in-journal_commit_transaction-fix.patch
-rename-swapper-to-idle.patch
-oss-cs46xx-cleanup-and-tiny-bugfix.patch
-i4l-memory-leak-fix-for-sc_ioctl.patch
-isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub.patch
-isdn-unsafe-interaction-between-isdn_write-and-isdn_writebuf_stub-fix.patch
-invert-irq-migrationc-brach-prediction.patch
-x86-powerpc-make-hardirq_ctx-and-softirq_ctx-__read_mostly.patch
-jbd-avoid-kfree-null.patch
-ext3_clear_inode-avoid-kfree-null.patch
-make-noirqdebug-irqfixup-__read_mostly-add-unlikely.patch
-leds-amstrad-delta-led-support.patch
-leds-amstrad-delta-led-support-tidy.patch
-update-devicestxt.patch
-binfmt_elf-codingstyle-cleanup-and-remove-some-pointless-casts.patch
-binfnt_elf-remove-more-casts.patch
-fix-incorrect-sa_onstack-behaviour-for-64-bit-processes.patch
-percpu-counters-add-percpu_counter_exceeds.patch
-percpu-counter-data-type-changes-to-suppport.patch
-remove-unlikely-in-might_sleep_if.patch
-process-events-header-cleanup.patch
-process-events-license-change.patch
-strstrip-api.patch
-ipmi-strstrip-conversion.patch
-connector-exports.patch
-config_net=n-build-fix.patch
-remove-softlockup-from-invalidate_mapping_pages.patch
-add-doc-submitchecklist.patch
-kernel-sysc-doesnt-need-inith.patch
-make-rcu-api-inaccessible-to-non-gpl-linux-kernel-modules.patch
-doc-add-audit-acct-to-docbook.patch
-sgi-ioc4-detect-io-card-variant.patch
-two-additions-to-linux-documentation-ioctl-numbertxt.patch
-list-introduce-list_replace-helper.patch
-list-use-list_replace_init-instead-of-list_splice_init.patch
-when-config_base_samll=1-the-kernel-261611-cascade-in-kernel-timerc-may-enter-the-infinite-loop.patch
-when-config_base_samll=1-the-kernel-261611-cascade-in-kernel-timerc-may-enter-the-infinite-loop-use-list_replace_init.patch
-codingstyle-add-typedefs-chapter.patch
 fs-bufferc-possible-cleanups.patch
-drivers-md-raid6algosc-fix-a-null-dereference.patch
-adjust-handle_irr_event-return-type.patch
-sparse-fixes-for-synclink_cs.patch
-jbd-split-checkpoint-lists.patch
-more-bug_on-conversion.patch
-make-kernel-ignore-bogus-partitions.patch
-drivers-block-loopc-dont-return-garbage-if-loop_set_status-not-called.patch
-docs-update-sparsetxt-with-check_endian.patch
-random-remove-bogus-sa_sample_random-from-at91-compact-flash-driver.patch
-kthread-convert-s390machc-from-kernel_thread.patch

 Merged into mainline or a subsystem tree

+disable-debugging-version-of-write_lock.patch

 Disable the debug version of write_lock() - it's a box-killer.

+fix-typo-in-acpi-video-brightness-changes.patch

 Fix tpyo.

+initramfs-overwrite-fix.patch

 initramfs fix

-git-acpi-pre.patch
-git-acpi-post.patch

 Dropped.

+disable-acpi-on-some-phoenix-bios.patch
+drivers-acpi-scanc-make-acpi_bus_type-static.patch
+cpu_relax-use-in-acpi-lock.patch
+cpu_relax-use-in-acpi-lock-fix.patch
+acpi-asus-s3-resume-fix.patch
+acpi-asus-s3-resume-fix-fix.patch

 ACPI stuff

+more-for_each_cpu-removal.patch

 Keep trying to remove for_each_cpu().

+cifs-build-fix.patch

 Fix git-cifs.patch.

+remove-useless-checks-in-cifs-connectc.patch
+cifs-remove-f_ownerlock-use.patch

 CIFS tweaks.

+fix-use-after-free-bug-in-cpia2-driver.patch
+drivers-media-video-vivic-make-2-functions-static.patch
+drivers-media-video-pwc-make-code-static.patch
+fix-up-funky-logic-in-dvb.patch

 Fix git-dvb.patch

+ieee1394-nodemgr-do-not-peek-into-struct.patch

 Don't abuse semaphores in ieee1394

+input-allow-root-to-inject-unknown-scan-codes.patch

 Input feature.

+git-kbuild-revert-kbuild-ignore-makes-built-in-rules-variables.patch

 Fix git-kbuild.patch.

-kbuild-export-symbol-usage-report-generator.patch
+kbuild-export-symbol-usage-report-generator-2.patch

 Updated.

-via-pata-fails-on-some-atapi-drives-tidy.patch

 Folded into via-pata-fails-on-some-atapi-drives.patch

+ata-add-some-nvidia-chipset-ids.patch
+make-drivers-scsi-pata_pcmciacpcmcia_remove_one-static.patch
+libatah-needs-scatterlisth.patch
+sata-is-bust-on-s390.patch

 sata things.

+ni5010-netcard-cleanup-fix.patch
+s2io-driver-irq-fix.patch
+s2io-driver-irq-fix-tidy.patch
+qla3xxx-NIC-driver.patch
+qla3xxx-is-bust.patch

 Net driver updates.  Includes a new driver from qlogic which almost compiles.

-git-nfs.patch
-git-nfs-fixup.patch
-git-nfs-build-fixes.patch
-nfs-build-fix-99.patch
+#git-nfs.patch
+#git-nfs-fixup.patch
+#git-nfs-build-fixes.patch
+#nfs-build-fix-99.patch

 NFS tree dropped.

+add-lookup-hint-for-network-file-systems.patch

 Speed up NFS mkdirs

+git-pcmcia-fixup.patch

 Fix reject in git-pcmcia,patch.

+powerpc-adding-the-use-of-the-firmware-soft-reset-nmi-to-kdump.patch
+powerpc-kcofnig-warning-fix.patch

 powerpc things.

+64-bit-resources-kconfig-change.patch
+64bit-resource-fix-up-printks-for-resources-in-arch-and-core-code-fix.patch

 Fix Greg's tree a bit more.

+git-s390.patch

 s390 tree is back.

+drivers-scsi-qla2xxx-make-more-some-functions-static.patch
+drivers-scsi-advansysc-cleanups.patch

 scsi tweaks.

+usb-new-driver-for-cypress-cy7c63xxx-mirco-controllers-fix.patch
+if-0-drivers-usb-input-hid-corechid_find_field_by_usage.patch

 USB tweaks.

+x86_64-apic-fix-apic-error-on-bootup.patch
+x86_64-fix-bus-numbering-format-in-mmconfig-warning.patch

 x86_64 updates.

-radix-tree-rcu-lockless-readside-wraning-fix.patch
-radix-tree-rcu-lockless-readside-fix.patch

 Folded into radix-tree-rcu-lockless-readside.patch

+redo-radix-tree-fixes.patch
+adix-tree-rcu-lockless-readside-update.patch
+radix-tree-rcu-lockless-readside-semicolon.patch
+adix-tree-rcu-lockless-readside-update-tidy.patch

 More radix-tree work.

+zoned-vm-counters-create-vmstatc-h-from-page_allocc-h.patch
+zoned-vm-counters-create-vmstatc-h-from-page_allocc-h-s390-fix.patch
+zoned-vm-counters-create-vmstatc-h-from-page_allocc-h-fix.patch
+zoned-vm-counters-basic-zvc-zoned-vm-counter-implementation.patch
+zoned-vm-counters-basic-zvc-zoned-vm-counter-implementation-tidy.patch
+zoned-vm-counters-convert-nr_mapped-to-per-zone-counter.patch
+zoned-vm-counters-convert-nr_mapped-to-per-zone-counter-fix.patch
+zoned-vm-counters-conversion-of-nr_pagecache-to-per-zone-counter.patch
+zoned-vm-counters-remove-nr_file_mapped-from-scan-control-structure.patch
+zoned-vm-counters-remove-nr_file_mapped-from-scan-control-structure-fix.patch
+zoned-vm-counters-split-nr_anon_pages-off-from-nr_file_mapped.patch
+zoned-vm-counters-zone_reclaim-remove-proc-sys-vm-zone_reclaim_interval.patch
+zoned-vm-counters-conversion-of-nr_slab-to-per-zone-counter.patch
+zoned-vm-counters-conversion-of-nr_slab-to-per-zone-counter-fix.patch
+zoned-vm-counters-conversion-of-nr_pagetables-to-per-zone-counter.patch
+zoned-vm-counters-conversion-of-nr_pagetables-to-per-zone-counter-fix.patch
+zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter.patch
+zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter-fix.patch
+zoned-vm-counters-conversion-of-nr_dirty-to-per-zone-counter-nfs-fix.patch
+zoned-vm-counters-conversion-of-nr_writeback-to-per-zone-counter.patch
+zoned-vm-counters-conversion-of-nr_writeback-to-per-zone-counter-fix.patch
+zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter.patch
+zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter-nfs-fix.patch
+zoned-vm-counters-conversion-of-nr_unstable-to-per-zone-counter-fix.patch
+zoned-vm-counters-conversion-of-nr_bounce-to-per-zone-counter.patch
+zoned-vm-counters-conversion-of-nr_bounce-to-per-zone-counter-fix.patch
+zoned-vm-counters-remove-useless-struct-wbs.patch
+zoned-vm-counters-remove-read_page_state.patch

 More efficient VM counters.  Buggier ones, too - piles of fixes were needed
 here :(

+cpu_relax-smpbootc.patch
+cpu_relax-smpbootc-fix.patch
+x86-apic-fix-apic-error-on-bootup.patch
+fix-broken-vm86-interrupt-signal-handling.patch
+i386-cpu_relax-in-crashc-and-doublefaultc.patch

 x86 updates

+m68k-fix-uaccessh-for-gcc-3x.patch
+m68k-fix-constraints-of-the-signal-functions-and-some-cleanup.patch
+m68k-fix-__iounmap-for-030.patch
+m68k-small-flush_icache-cleanup.patch
+m68k-add-the-generic-dma-api-functions.patch
+m68k-dma-api-addition.patch
+m68k-fix-show_registers.patch
+m68k-separate-handler-for-auto-and-user-vector-interrupt.patch
+m68k-cleanup-generic-irq-names.patch
+m68k-cleanup-amiga-irq-numbering.patch
+m68k-introduce-irq-controller.patch
+m68k-convert-generic-irq-code-to-irq-controller.patch
+m68k-convert-amiga-irq-code.patch
+m68k-convert-apollo-irq-code.patch
+m68k-convert-atari-irq-code.patch
+m68k-convert-hp300-irq-code.patch
+m68k-convert-mac-irq-code.patch
+m68k-convert-q40-irq-code.patch
+m68k-convert-sun3-irq-code.patch
+m68k-convert-vme-irq-code.patch

 m68k updates.

+fix-oddball-boolean-logic-in-s390-netiucv.patch
+s390-broken-null-test-in-claw-driver.patch

 s390 updates

+fs-ufs-inodec-make-2-functions-static.patch

 Cleanup

+rtc-add-rtc-ds1553-driver.patch
+rtc-add-rtc-ds1553-driver-tidy.patch
+rtc-add-rtc-ds1553-driver-fix.patch
+rtc-add-rtc-ds1742-driver.patch
+rtc-add-rtc-ds1742-driver-tidy.patch
+rtc-add-rtc-ds1742-driver-fix.patch
+rtc-add-rtc-rs5c348-driver.patch

 More RTC drivers.

+fuse-add-control-filesystem-get_sb_single-fix.patch
+fuse-add-control-filesystem-fuse-comment-control-filesystem.patch
+fuse-scramble-lock-owner-id.patch

 FUSE updates.

 kthread-update-loopc-to-use-kthread-fix.patch

 Folded into kthread-update-loopc-to-use-kthread.patch

-kthread-convert-lock-to-use-kthread.patch

 Droped, I think.

-stop-on-cpu-lost.patch
-stop-on-cpu-lost-tidy.patch

 Dropped.

+led-add-led-heartbeat-trigger-update.patch

 Fix led-add-led-heartbeat-trigger.patch

+autofs4-needs-to-force-fail-return-revalidate-update.patch

 Fix autofs4-needs-to-force-fail-return-revalidate.patch

+add-synclink_gt-custom-hdlc-idle.patch
+add-synclink_gt-crc-return-feature.patch
+fix-synclink_gt-diagnostics-error-reporting.patch
+synclink_gt-add-gt2-adapter-support.patch
+corrections-to-memory-barrier-doc.patch
+add-option-for-stripping-modules-while-installing-them.patch
+binfmt_elf-fix-checks-for-bad-address.patch
+binfmt_elf-fix-checks-for-bad-address-fix.patch
+pacct-two-phase-process-accounting.patch
+pacct-avoidance-to-refer-the-last-thread-as-a-representation-of-the-process.patch
+pacct-none-delayed-process-accounting-accumulation.patch
+ext2-cleanup-put_page-and-comment-fix.patch
+remove-gratuitous-inclusion-of-linux-configh-from.patch
+au1550_ac97-spin_unlock-in-error-path.patch
+generic_file_buffered_write-deadlock-on-vectored-write.patch
+parport-add-to-kernel-doc.patch
+drivers-char-agp-nvidia-agpc-remove-unused-variable.patch
+au1xxx-oss-sound-support-for-au1200.patch
+s390-setupc-cleanup-build-fix.patch
+remove-tty_dont_flip.patch
+fix-kdump-crash-kernel-boot-memory-reservation-for-numa.patch
+fix-biovec-256-in-proc-slabinfo.patch
+add-receive_room-flow-control-to-flush_to_ldisc.patch
+add-receive_room-flow-control-to-flush_to_ldisc-tidy.patch
+remove-unlikelysb-in-prune_dcache.patch

 Misc patches.

+introduce-crashboot-kernel-command-line-parameter.patch
+kdump-cciss-driver-initialization-issue-fix.patch

 Unpleasant kdump patches.

+reiserfs-reorganize-bitmap-loading-functions-fix.patch
+reiserfs-reorganize-bitmap-loading-functions-fix2.patch

 Fix reiserfs-reorganize-bitmap-loading-functions.patch

+cpu-hotplug-revert-init-patch-submitted-for-2617.patch
+cpu-hotplug-revert-initdata-patch-submitted-for-2617.patch
+cpu-hotplug-make-register_cpu_notifier-init-time-only.patch
+cpu-hotplug-make-register_cpu_notifier-init-time-only-fix.patch
+cpu-hotplug-make-cpu_notifier-related-notifier-blocks-__cpuinit-only.patch
+cpu-hotplug-make-cpu_notifier-related-notifier-blocks-__cpuinit-only-fix.patch
+cpu-hotplug-make-cpu_notifier-related-notifier-calls-__cpuinit-only.patch
+cpu-hotplug-make-cpu_notifier-related-notifier-calls-__cpuinit-only-fix.patch
+cpu-hotplug-add-hotplug-versions-of-cpu_notifier.patch
+cpu-hotplug-use-hotplug-version-of-cpu-notifier-in-appropriate-places.patch

 CPU hotplug kernel sectioning optimisation.

-per-task-delay-accounting-taskstats-interface-fix-exit-race-in-per-task-delay-accounting.patch
-per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface-use-portable-cputime-api-in-__delayacct_add_tsk.patch
-per-task-delay-accounting-delay-accounting-usage-of-taskstats-interface-fix-return-value-of-delayacct_add_tsk.patch

 Folded into other patches.

+chardev-gpio-for-scx200-pc-8736x-add-platforn_device-static-numpins.patch
+chardev-gpio-for-scx200-pc-8736x-add-platforn_device-enomem-on-device_add-failure.patch
+chardev-gpio-for-scx200-pc-8736x-add-platforn_device-scx200-init-undo-malloc.patch
+chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio-no-static-init.patch
+chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio-no-weird-comment-placement.patch
+chardev-gpio-for-scx200-pc-8736x-add-new-pc8736x_gpio-fixups.patch
+chardev-gpio-for-scx200-pc-8736x-add-platform_device-request-region.patch
+chardev-gpio-for-scx200-pc-8736x-add-platform_device-request-region-series.patch
+chardev-gpio-for-scx200-pc-8736x-use-dev_dbg-extern-to-header.patch
+chardev-gpio-for-scx200-pc-8736x-fix-gpio_current-make-precedence-explicit.patch
+chardev-gpio-for-scx200-pc-8736x-replace-spinlocks-fix.patch
+chardev-gpio-for-scx200-pc-8736x-replace-spinlocks-include-linux-ioh.patch

 Update the GPIO patches in -mm.

+fix-and-optimize-clock-source-update.patch

 Update time management patches in -mm.

+sched-cpu-hotplug-race-vs-set_cpus_allowed.patch

 CPu scheduler fix.

+sched_exit-fix-parent-time_slice-calculation.patch
+sched_exit-move-the-callsite-to-do_exit.patch
+sched-uninline-task_rq_lock.patch
+bug-if-setscheduler-is-called-from-interrupt-context.patch

 CPu scheduler work.

+swap_prefetch-vs-zoned-counters.patch

 Fix up prefetch for the zoned-counters work.

+pi-futex-rt-mutex-tester-fix.patch

 Fix pi-futex-rt-mutex-tester.patch

+drop-tasklist-lock-in-do_sched_setscheduler.patch
+rtmutex-modify-rtmutex-tester-to-test-the-setscheduler.patch
+rtmutex-propagate-priority-settings-into-pi-lock-chains.patch
+rtmutex-propagate-priority-settings-into-pi-lock-chains-fix.patch

 pi-fuex updates.

+selinux-add-sockcreate-node-to-procattr-api.patch

 Add selinux hooks to /proc rework in -mm.

+ecryptfs-superblock-operations-ecryptfs-build-fix.patch
+ecryptfs-crypto-functions-fix-filesize-on-hard-link-creation.patch
+ecryptfs-remove-debugging-cruft.patch
+ecryptfs-get_sb_dev-fix.patch

 ecrtpyfs updates.

+make-kernel-sysctlc_proc_do_string-static.patch

 Cleanup.

+namespaces-utsname-implement-clone_newuts-flag-tidy.patch

 Clean up namespaces-utsname-implement-clone_newuts-flag.patch

+task-watchers-register-semundo-task-watcher-cleanup.patch

 Clean up task-watchers-register-semundo-task-watcher.patch

+fs-reiser4-possible-cleanups.patch
+reiser4-get_sb_dev-fix.patch
+reiser4-vs-zoned-allocator.patch

 reiser4 things.

-ide_dma_speed-fixes-warning-fix.patch
-ide_dma_speed-fixes-tidy.patch

 Folded into ide_dma_speed-fixes.patch

-hpt370-clean-up-dma-timeout-handling-cleanup.patch

 Folded into hpt370-clean-up-dma-timeout-handling.patch

+drivers-ide-legacy-ide-csc-make-2-functions-static.patch

 IDE cleanup.

+dm-mirror-log-sector-size-fix.patch
+dm-mirror-log-refactor-context.patch
+dm-mirror-log-bitset_size-fix.patch
+dm-mirror-log-sync_count-fix.patch
+dm-kcopyd-error-accumulation-fix.patch
+dm-table-split_args-handle-no-input.patch
+dm-consolidate-creation-functions.patch
+dm-add-exports-2.patch
+dm-create-error-table.patch
+dm-prevent-removal-if-open.patch
+dm-improve-error-message-consistency.patch
+dm-support-ioctls-on-mapped-devices.patch
+dm-linear-support-ioctls.patch
+dm-mpath-support-ioctls.patch
+dm-export-blkdev_driver_ioctl.patch

 Device mapper updates.

+drivers-md-mdc-make-code-static.patch

 MD cleanup.

-genirq-convert-the-x86_64-architecture-to-irq-chips.patch
-genirq-convert-the-i386-architecture-to-irq-chips.patch
-genirq-convert-the-i386-architecture-to-irq-chips-fix-2.patch
-genirq-add-chip-eoi-fastack-fasteoi.patch
-genirq-add-chip-eoi-fastack-fasteoi-fix.patch
-genirq-allow-usage-of-no_irq_chip.patch
+genirq-add-irq_type_sense_mask.patch
+genirq-add-irq-chip-support-fasteoi-handler-handle-interrupt-disabling.patch
+genirq-irq-document-what-an-irq-is.patch
+genirq-add-chip-eoi-fastack-fasteoi-core.patch
+genirq-add-chip-eoi-fastack-fasteoi-fix.patch

 Various genirq patches added, removed and moved around.

+acpi-reduce-code-size-clean-up-fix-validator-message.patch

 Remove some odd ACPI constructs to make lockdep happy.

-lock-validator-sparc64-sparc-m68k-alpha-cris-build-fix.patch
-lock-validator-floppyc-irq-release-fix.patch
-lock-validator-floppyc-irq-release-fix-fix.patch
-lock-validator-floppyc-irq-release-fix-fix-fix.patch
-lock-validator-forcedethc-fix.patch
-lock-validator-mutex-section-binutils-workaround.patch
-lock-validator-add-__module_address-method.patch
-lock-validator-better-lock-debugging.patch
-lock-validator-locking-api-self-tests.patch
-lock-validator-locking-api-self-tests-self-test-fix.patch
-lock-validator-locking-init-debugging-improvement.patch
-lock-validator-beautify-x86_64-stacktraces.patch
-lock-validator-beautify-x86_64-stacktraces-fix.patch
-lock-validator-beautify-x86_64-stacktraces-fix-2.patch
-lock-validator-beautify-x86_64-stacktraces-fix-3.patch
-lock-validator-beautify-x86_64-stacktraces-fix-4.patch
-lock-validator-x86_64-document-stack-frame-internals.patch
-lock-validator-stacktrace.patch
-lock-validator-stacktrace-build-fix.patch
-lock-validator-stacktrace-warning-fix.patch
-lock-validator-stacktrace-fix-on-x86_64.patch
-lock-validator-fown-locking-workaround.patch
-lock-validator-sk_callback_lock-workaround.patch
-lock-validator-irqtrace-core.patch
-lock-validator-irqtrace-core-powerpc-fix-1.patch
-lock-validator-irqtrace-core-non-x86-fix.patch
-lock-validator-irqtrace-core-non-x86-fix-2.patch
-lock-validator-irqtrace-core-non-x86-fix-3.patch
-lock-validator-irqtrace-entrys-fix.patch
-lock-validator-irqtrace-core-remove-softirqc-warn_on.patch
-lock-validator-irqtrace-cleanup-include-asm-i386-irqflagsh.patch
-lock-validator-irqtrace-cleanup-include-asm-x86_64-irqflagsh.patch
-lock-validator-x86_64-irqflags-trace-entrys-fix.patch
-lock-validator-x86_64-irqflags-trace-entrys-fix-fix.patch
-lock-validator-lockdep-add-local_irq_enable_in_hardirq-api.patch
-lock-validator-add-per_cpu_offset.patch
-lock-validator-add-per_cpu_offset-fix.patch
-lock-validator-core.patch
-lock-validator-core-early_boot_irqs_-build-fix.patch
-lock-validator-core-early_boot_irqs_-build-fix-sparc64-sparc-m68k-alpha-cris-irqtrace-build-fix.patch
-lock-validator-core-fix-compiler-warning.patch
-lock-validator-core-add-config_debug_non_nested_unlocks.patch
-lock-validator-core-provide-lockdep_off-lockdep_on-apis.patch
-lock-validator-procfs.patch
-lock-validator-core-multichar-fix.patch
-lock-validator-core-count_matching_names-fix.patch
-lock-validator-core-provide-lockdep_reinit_key-api.patch
-lock-validator-core-print-info-not-bug.patch
-lock-validator-design-docs.patch
-lock-validator-prove-rwsem-locking-correctness.patch
-lock-validator-prove-rwsem-locking-correctness-fix.patch
-lock-validator-prove-rwsem-locking-correctness-powerpc-fix.patch
-lock-validator-prove-spinlock-rwlock-locking-correctness.patch
-lock-validator-prove-mutex-locking-correctness.patch
-lock-validator-prove-mutex-locking-correctness-fix-null-type-name-bug.patch
-better-lock-debugging-remove-mutex-deadlock-checking-code.patch
-lock-validator-print-all-lock-types-on-sysrq-d.patch
-lock-validator-x86_64-early-init.patch
-lock-validator-smp-alternatives-workaround.patch
-lock-validator-do-not-recurse-in-printk.patch
-lock-validator-disable-nmi-watchdog-if-config_lockdep.patch
-lock-validator-disable-nmi-watchdog-if-config_lockdep-i386.patch
-lock-validator-disable-nmi-watchdog-if-config_lockdep-x86_64.patch
-lock-validator-special-locking-bdev.patch
-lock-validator-special-locking-bdev-fix.patch
-lock-validator-special-locking-direct-io.patch
-lock-validator-special-locking-serial.patch
-lock-validator-special-locking-serial-fix.patch
-lock-validator-special-locking-dcache.patch
-lock-validator-special-locking-i_mutex.patch
-lock-validator-special-locking-s_lock.patch
-lock-validator-special-locking-futex.patch
-lock-validator-special-locking-genirq.patch
-lock-validator-special-locking-genirq-lock-validator-early_init_irq_lock_type-build-fix.patch
-lock-validator-special-locking-completions.patch
-lock-validator-special-locking-waitqueues.patch
-lock-validator-special-locking-mm.patch
-lock-validator-special-locking-serio.patch
-lock-validator-special-locking-slab.patch
-lock-validator-special-locking-skb_queue_head_init.patch
-lock-validator-special-locking-net-ipv4-igmpcpatch.patch
-lock-validator-special-locking-net-ipv4-igmpc-2.patch
-lock-validator-special-locking-timerc.patch
-lock-validator-special-locking-schedc.patch
-lock-validator-special-locking-sctp.patch
-lock-validator-special-locking-hrtimerc.patch
-lock-validator-special-locking-sock_lock_init.patch
-lock-validator-special-locking-af_unix.patch
-lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type.patch
-lock-validator-special-locking-af_unix-undo-af_unix-_bh-locking-changes-and-split-lock-type-fix.patch
-lock-validator-special-locking-bh_lock_sock.patch
-lock-validator-annotate-ieee1394-skb-head-locking.patch
-lock-validator-special-locking-mmap_sem.patch
-lock-validator-special-locking-sb-s_umount.patch
-lock-validator-special-locking-reiser4-false-positive.patch
-lock-validator-special-locking-sb-s_umount-fix.patch
-lock-validator-special-locking-sb-s_umount-2.patch
-lock-validator-special-locking-sb-s_umount-2-fix.patch
-lockdep-annotate-rpc_populate-for.patch
-lock-validator-special-locking-jbd.patch
-lock-validator-special-locking-posix-timers.patch
-lock-validator-annotate-ntfs-locking-rules.patch
-lock-validator-special-locking-sch_genericc.patch
-lock-validator-special-locking-xfrm.patch
-lockdep-annotate-the-quota-code.patch
-lockdep-add-i_mutex-ordering-annotations-to-the-sunrpc.patch
-lockdep-add-parent-child-annotations-to-usbfs.patch
-lock-validator-special-locking-sound-core-seq-seq_portsc.patch
-lock-validator-special-locking-sound-core-seq-seq_devicec.patch
-lock-validator-special-locking-sound-core-seq-seq_devicec-fix.patch
-lock-validator-fix-rt_hash_lock_sz.patch
-lock-validator-introduce-irq__lockdep.patch
-lock-validator-fix-sparc32-breakage.patch
-locking-validator-special-rule-8390c-disable_irq.patch
-locking-validator-special-rule-3c59xc-disable_irq.patch
-lock-validator-enable-lock-validator-in-kconfig.patch
-lock-validator-enable-lock-validator-in-kconfig-require-trace_irqflags_support.patch
-lock-validator-enable-lock-validator-in-kconfig-not-yet.patch
-lock-validator-enable-lock-validator-in-kconfig-add-config_debug_non_nested_unlocks-kconfig.patch
-lockdep-one-stacktrace-column-if-config_lockdep=y.patch
-i386-remove-multi-entry-backtraces.patch
-lockdep-further-improve-stacktrace-output.patch
-lock-validator-irqtrace-support-non-x86-architectures.patch
-lock-validator-disable-oprofile-if-lockdep=y.patch
-lock-validator-select-kallsyms_all.patch
-lock-validator-v3.patch
-lockdep-x86-only.patch
-lockdep-really-x86-only.patch
-lockdep-really-really-x86-only.patch
-lock-validator-s390-stacktrace-interface.patch
-lock-validator-s390-config_frame_pointer-support.patch
-lock-validator-s390-rwsem-semaphore-changes.patch
-lock-validator-early_init_irq_lock_type--console_init.patch
-lock-validator-s390-irqtrace-support.patch
-lock-validator-__local_bh_enable-_local_bh_enable.patch
-lock-validator-s390-use-raw_spinlock-in-mcck-handler.patch
-lock-validator-add-s390-to-supported-options.patch
-lockdep-avoid-false-positive-illegal-lock-usage-message-in-qeth-driver.patch
-lockdep-hack-around-build-errors.patch

 Droped.

-kgdb-core-lite.patch
-lock-validator-special-locking-kgdb.patch
-kgdb-core-lite-add-reboot-command.patch
-kgdb-8250.patch
-kgdb-8250-fix.patch
-kgdb-netpoll_pass_skb_to_rx_hook.patch
-kgdb-eth.patch
-kgdb-i386-lite.patch
-kgdb-cfi_annotations.patch
-kgdb-sysrq_bugfix.patch
-kgdb-module.patch
-kgdb-core.patch
-kgdb-i386.patch

 Shelved.

-journal_add_journal_head-debug.patch
-page-owner-tracking-leak-detector.patch
-unplug-can-sleep.patch
-firestream-warnings.patch
-#periodically-scan-redzone-entries-and-slab-control-structures.patch
-slab-leak-detector.patch
-releasing-resources-with-children.patch
-nr_blockdev_pages-in_interrupt-warning.patch
-detect-atomic-counter-underflows.patch
-device-suspend-debug.patch
-slab-cache-shrinker-statistics.patch
-mm-debug-dump-pageframes-on-bad_page.patch
-debug-warn-if-we-sleep-in-an-irq-for-a-long-time.patch
-debug-shared-irqs.patch
-make-frame_pointer-default=y.patch
-i386-enable-4k-stacks-by-default.patch
-pidhash-temporary-debug-checks.patch
-acpi-identify-which-device-is-not-power-manageable.patch
-revert-tty-buffering-comment-out-debug-code.patch
-mutex-subsystem-synchro-test-module.patch
-x86-e820-debugging.patch
-slab-leaks3-default-y.patch
-x86-kmap_atomic-debugging.patch
-profile-likely-unlikely-macros.patch
-vdso-print-fatal-signals.patch
-vdso-improve-print_fatal_signals-support-by-adding-memory-maps.patch

 Shelved.



All 1268 patches:

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



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
@ 2006-06-24 15:53 ` Rafael J. Wysocki
  2006-06-24 17:20   ` 2.6.17-mm2 Dave Jones
  2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall
                   ` (13 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Rafael J. Wysocki @ 2006-06-24 15:53 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Saturday 24 June 2006 15:19, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/

The box seems to work, although I have some "interesting" stuff in dmesg:

int3: 0000 [1] PREEMPT
last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device
CPU 0
Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd
Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4
RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1}
RSP: 0018:ffff810052c59e40  EFLAGS: 00000292
RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff
RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0
RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0
R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0
FS:  00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0
Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810)
Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390
       ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0
       ffffc20000af4930 ffff8100531a5490
Call Trace: [<ffff810052c59f78>]

Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40>
 <6>note: modprobe[4839] exited with preempt_count 1
eth0: no IPv6 routers present
hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Slab corruption: start=ffff810041e09810, len=1936
060: 81 20 71 93 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=ffff810041e09080, len=1936
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Slab corruption: start=ffff810042e86080, len=1936
060: 3d d4 14 92 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=ffff810042e86810, len=1936
000: 01 00 00 00 00 00 00 00 00 e0 3a 4a 00 81 ff ff
010: 02 00 00 00 00 00 00 00 40 20 40 00 00 00 00 00

and later, after a resume from disk:

drivers/usb/core/inode.c: creating file '003'
Slab corruption: start=ffff810041e05040, len=1936
060: cf f5 5f 9c 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=ffff810041e057d0, len=1936
000: 01 00 00 00 00 00 00 00 00 00 4f 3c 00 81 ff ff
010: 02 00 00 00 00 00 00 00 00 01 40 00 00 00 00 00
Slab corruption: start=ffff810041e09080, len=1936
060: 7f 4f 01 95 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=ffff810041e09810, len=1936
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Slab corruption: start=ffff810042e86810, len=1936
060: 68 06 7f 9c 90 90 90 50 6b 6b 6b 6b 6b 6b 6b 6b
090: 6b 6b 6b 6b 6b 6b 6b 6b 01 00 00 00 6b 6b 6b 6b
Prev obj: start=ffff810042e86080, len=1936
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b

Greetings,
Rafael

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki
@ 2006-06-24 17:20   ` Dave Jones
  2006-06-24 21:34     ` 2.6.17-mm2 Andrew Morton
  0 siblings, 1 reply; 93+ messages in thread
From: Dave Jones @ 2006-06-24 17:20 UTC (permalink / raw)
  To: Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel

On Sat, Jun 24, 2006 at 05:53:44PM +0200, Rafael J. Wysocki wrote:
 > On Saturday 24 June 2006 15:19, Andrew Morton wrote:
 > > 
 > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
 > 
 > The box seems to work, although I have some "interesting" stuff in dmesg:
 > 
 > int3: 0000 [1] PREEMPT
 > last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device
 > CPU 0
 > Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd
 > Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4
 > RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1}
 > RSP: 0018:ffff810052c59e40  EFLAGS: 00000292
 > RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff
 > RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0
 > RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001
 > R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0
 > R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0
 > FS:  00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000
 > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 > CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0
 > Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810)
 > Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390
 >        ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0
 >        ffffc20000af4930 ffff8100531a5490
 > Call Trace: [<ffff810052c59f78>]
 > 
 > Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
 > RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40>

'something' filled this function with breakpoints.
Andrew mentioned he dropped the kgdb patches. Any chance something was missed?

		Dave

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

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
  2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki
@ 2006-06-24 19:41 ` Dominik Karall
  2006-06-24 21:43   ` 2.6.17-mm2 Andrew Morton
  2006-06-25  6:06 ` 2.6.17-mm2 Reuben Farrelly
                   ` (12 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Dominik Karall @ 2006-06-24 19:41 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Saturday, 24. June 2006 15:19, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
>7/2.6.17-mm2/

hi!

I get this warning on make modules_install:

WARNING: /lib/modules/2.6.17-mm2/kernel/net/ieee80211/ieee80211.ko 
needs unknown symbol wireless_spy_update

regards,
dominik

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 17:20   ` 2.6.17-mm2 Dave Jones
@ 2006-06-24 21:34     ` Andrew Morton
  2006-06-25  8:51       ` 2.6.17-mm2 Rafael J. Wysocki
  0 siblings, 1 reply; 93+ messages in thread
From: Andrew Morton @ 2006-06-24 21:34 UTC (permalink / raw)
  To: Dave Jones; +Cc: rjw, linux-kernel, Chandra Seetharaman

On Sat, 24 Jun 2006 13:20:14 -0400
Dave Jones <davej@redhat.com> wrote:

> On Sat, Jun 24, 2006 at 05:53:44PM +0200, Rafael J. Wysocki wrote:
>  > On Saturday 24 June 2006 15:19, Andrew Morton wrote:
>  > > 
>  > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
>  > 
>  > The box seems to work, although I have some "interesting" stuff in dmesg:
>  > 
>  > int3: 0000 [1] PREEMPT
>  > last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device
>  > CPU 0
>  > Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd
>  > Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4
>  > RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1}
>  > RSP: 0018:ffff810052c59e40  EFLAGS: 00000292
>  > RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff
>  > RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0
>  > RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001
>  > R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0
>  > R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0
>  > FS:  00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000
>  > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>  > CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0
>  > Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810)
>  > Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390
>  >        ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0
>  >        ffffc20000af4930 ffff8100531a5490
>  > Call Trace: [<ffff810052c59f78>]
>  > 
>  > Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
>  > RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40>
> 
> 'something' filled this function with breakpoints.
> Andrew mentioned he dropped the kgdb patches. Any chance something was missed?
> 

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

Do you have CONFIG_CPU_FREQ=y?

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

Do you get any section mismatch warnings at build-time?

Chandra, those patches seem a bit wobbly.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall
@ 2006-06-24 21:43   ` Andrew Morton
  0 siblings, 0 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-24 21:43 UTC (permalink / raw)
  To: Dominik Karall; +Cc: linux-kernel, netdev, John W. Linville, Jeff Garzik

On Sat, 24 Jun 2006 21:41:41 +0200
Dominik Karall <dominik.karall@gmx.net> wrote:

> On Saturday, 24. June 2006 15:19, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
> >7/2.6.17-mm2/
> 
> hi!
> 
> I get this warning on make modules_install:
> 
> WARNING: /lib/modules/2.6.17-mm2/kernel/net/ieee80211/ieee80211.ko 
> needs unknown symbol wireless_spy_update
> 

Someone removed the `#ifdef CONFIG_WIRELESS_EXT' from around the callsite
in net/ieee80211/ieee80211_rx.c and didn't update Kconfig appropriately.

Presumably, setting CONFIG_WIRELESS_EXT will get you going again.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
  2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki
  2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall
@ 2006-06-25  6:06 ` Reuben Farrelly
  2006-06-25  9:37   ` 2.6.17-mm2 Barry K. Nathan
  2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski
                   ` (11 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Reuben Farrelly @ 2006-06-25  6:06 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

Hi,

On 25/06/2006 1:19 a.m., Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
> 
> 
> - The locking validator patches have all been dropped - Ingo is redoing the
>   patch series.
> 
> - The arch-secific parts of the generic IRQ rework have been dropped, so
>   it's a do-nothing patch series at present.  If we can verify that it indeed
>   does nothing then we might be able to squeak it into 2.6.18 for powerpc to
>   merge against.
> 
> - The kgdb patches have been tempdropped.  Partly to make merging of other
>   things easier, partly because someone broke it.
> 
> - The various little -mm-only debugging patches have been temporarily
>   dropped, to make followon patching easier.

I'm seeing a very bizarre problem with this release - and it's 100%
reproduceable.  But I've no real idea where to look any further.

Seems that something is going on with this release that is completely screwing
up a number of things including particularly Postfix which is running on the 
system.  Even local deliveries from one account to another are failing, they are 
in the queue and are logged "skipped, still being delivered" but never actually 
complete, hence I end up with a big heap of mail all within the Postfix system 
but not actually completing delivery.

What is so bizarre is that by reverting to 2.6.17-rc6-mm2, it all comes right
and the piled up mail flushes straight through.  So it does look to me like a
kernel problem and not a Postfix one (at least, not a config problem).

I also noticed when I restarted the system after I first noticed it that some of
the partitions could not be unmounted at the final stages of shutdown because
they were busy.  Things like /home ... which is rather strange because there
should be nothing whatsoever running on it at power off.  Anything using them
should have been TERMed or KILLed on the way down out of runlevel 3:

Starting killall:  [  OK  ]
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Saving random seed:
Syncing hardware clock to system time
Turning off swap:
Unmounting file systems:  umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /home: device is busy
umount2: Device or resource busy
umount: /home: device is busy

/var:               cccccccc
/home:              mmmmmmmm
Unmounting file systems (retry):  umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /home: device is busy
umount2: Device or resource busy
umount: /home: device is busy

/var:               cccccccc
/home:              mmmmmmmm
Unmounting file systems (retry):  umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /home: device is busy
umount2: Device or resource busy
umount: /home: device is busy

/var:               cccccccc
/home:              mmmmmmmm
umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /var: device is busy
umount2: Device or resource busy
umount: /home: device is busy
umount2: Device or resource busy
umount: /home: device is busy
mount: /home is busy
Please stand by while rebooting the system...
md: stopping all md devices.
md: md1 still in use.
md: md2 still in use.
md: md3 switched to read-only mode.
md: md4 switched to read-only mode.
md: md6 switched to read-only mode.
md: md5 switched to read-only mode.
md: md0 still in use.
Synchronizing SCSI cache for disk sdc:
Synchronizing SCSI cache for disk sdb:

*** Where is the synchronizing entry for sda?
<power cycled the box as it got stuck at this point>


Is something bust something with regards to signals or something that could be
causing these symptoms?

Some more info:

[root@tornado log]# mount
/dev/md0 on / type ext3 (rw)
none on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)
/dev/sda1 on /boot type ext3 (rw)
/dev/md1 on /home type ext3 (rw)
/dev/md2 on /var type ext3 (rw)
/dev/md3 on /var/www/cgi-bin type ext3 (rw)
/dev/md4 on /tmp type ext3 (rw)
/dev/md5 on /var/www/html type ext3 (rw)
/dev/sda8 on /var/spool/squid-1 type reiserfs (rw,noatime,notail)
/dev/sdc8 on /var/spool/squid-2 type reiserfs (rw,noatime,notail)
/dev/sdb1 on /store type ext3 (rw)
/dev/sdb2 on /backup type ext3 (rw)
/dev/shm on /var/spool/amavisd/tmp type tmpfs (rw,size=25m,mode=700,uid=101,gid=511)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
[root@tornado log]#

and the usual hardware up at http://www.reub.net/files/kernel/system-hardware.

2.6.17-mm1 was a no-go for me due to the bustage with ReiserFS and bitmaps, even
the hotfix didn't seem to fix that...  :-(

Reuben




^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 21:34     ` 2.6.17-mm2 Andrew Morton
@ 2006-06-25  8:51       ` Rafael J. Wysocki
  2006-06-25 10:22         ` 2.6.17-mm2 Andrew Morton
  0 siblings, 1 reply; 93+ messages in thread
From: Rafael J. Wysocki @ 2006-06-25  8:51 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Dave Jones, linux-kernel, Chandra Seetharaman

On Saturday 24 June 2006 23:34, Andrew Morton wrote:
> On Sat, 24 Jun 2006 13:20:14 -0400
> Dave Jones <davej@redhat.com> wrote:
> 
> > On Sat, Jun 24, 2006 at 05:53:44PM +0200, Rafael J. Wysocki wrote:
> >  > On Saturday 24 June 2006 15:19, Andrew Morton wrote:
> >  > > 
> >  > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
> >  > 
> >  > The box seems to work, although I have some "interesting" stuff in dmesg:
> >  > 
> >  > int3: 0000 [1] PREEMPT
> >  > last sysfs file: /devices/pci0000:00/0000:00:0a.0/0000:02:00.0/subsystem_device
> >  > CPU 0
> >  > Modules linked in: acpi_cpufreq usbserial asus_acpi thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd_seq snd_seqd
> >  > Pid: 4839, comm: modprobe Not tainted 2.6.17-mm2 #4
> >  > RIP: 0010:[<ffffffff806b0401>] <ffffffff806b0401>{cpufreq_register_driver+1}
> >  > RSP: 0018:ffff810052c59e40  EFLAGS: 00000292
> >  > RAX: 00000000ffffffea RBX: ffffffff8832a340 RCX: 00000000ffffffff
> >  > RDX: ffff8100567e3810 RSI: ffffffff883092cf RDI: ffffffff8832a2a0
> >  > RBP: ffff810052c59e48 R08: 0000000000000000 R09: 0000000000000001
> >  > R10: 0000000000000001 R11: 0000000000000001 R12: ffff8100545f4de0
> >  > R13: ffffffff8832a340 R14: ffffc20000af49b0 R15: ffff8100545f53a0
> >  > FS:  00002ae4d623db00(0000) GS:ffffffff80689000(0000) knlGS:0000000000000000
> >  > CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >  > CR2: 000000000051a680 CR3: 0000000054243000 CR4: 00000000000006e0
> >  > Process modprobe (pid: 4839, threadinfo ffff810052c58000, task ffff8100567e3810)
> >  > Stack: ffffffff880c808f ffff810052c59f78 ffffffff8024f14a ffffffff8832a390
> >  >        ffffffff8832a358 ffffffff8830e340 ffffc20000af4970 ffffc20000af43b0
> >  >        ffffc20000af4930 ffff8100531a5490
> >  > Call Trace: [<ffff810052c59f78>]
> >  > 
> >  > Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
> >  > RIP <ffffffff806b0401>{cpufreq_register_driver+1} RSP <ffff810052c59e40>
> > 
> > 'something' filled this function with breakpoints.
> > Andrew mentioned he dropped the kgdb patches. Any chance something was missed?
> > 
> 
> My guess would be that cpufreq_register_driver() is being called after it
> has been unloaded from the kernel.
> 
> Do you have CONFIG_CPU_FREQ=y?

Yes.

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

Yes (makes it go away).

> Do you get any section mismatch warnings at build-time?

Only this one:
WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1164) and 'acpi_processor_power_exit'

Greetings,
Rafael

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25  6:06 ` 2.6.17-mm2 Reuben Farrelly
@ 2006-06-25  9:37   ` Barry K. Nathan
  2006-06-25 10:29     ` 2.6.17-mm2 Reuben Farrelly
  0 siblings, 1 reply; 93+ messages in thread
From: Barry K. Nathan @ 2006-06-25  9:37 UTC (permalink / raw)
  To: Reuben Farrelly; +Cc: Andrew Morton, linux-kernel

On 6/24/06, Reuben Farrelly <reuben-lkml@reub.net> wrote:
> 2.6.17-mm1 was a no-go for me due to the bustage with ReiserFS and bitmaps, even
> the hotfix didn't seem to fix that...  :-(

Take 2.6.17-mm1, apply the hotfix, then apply this patch from 2.6.17-mm2 also:

http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/broken-out/reiserfs-reorganize-bitmap-loading-functions-fix2.patch

That should make 2.6.17-mm1's reiserfs work. (This way you can at
least see whether your 2.6.17-mm2 bug happens under -mm1 as well.)
-- 
-Barry K. Nathan <barryn@pobox.com>

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25  8:51       ` 2.6.17-mm2 Rafael J. Wysocki
@ 2006-06-25 10:22         ` Andrew Morton
  2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
                             ` (2 more replies)
  0 siblings, 3 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-25 10:22 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: davej, linux-kernel, sekharan, Rusty Russell, Randy.Dunlap, Sam Ravnborg

On Sun, 25 Jun 2006 10:51:55 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> > > 
> > 
> > My guess would be that cpufreq_register_driver() is being called after it
> > has been unloaded from the kernel.
> > 
> > Do you have CONFIG_CPU_FREQ=y?
> 
> Yes.
> 
> > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or
> > move the crash elsewhere)?
> 
> Yes (makes it go away).

Well it would appear that the new __cpuinit on cpufreq_register_driver() is
causing the problem, although I'm surprised that you don't have
CONFIG_HOTPLUG_CPU set, if it's a swsusp requirement??

> > Do you get any section mismatch warnings at build-time?
> 
> Only this one:
> WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0x1164) and 'acpi_processor_power_exit'
> 

That's a false-positive - the code in there is, I think, OK:

	static int first_run;

	...

	if (!first_run) {
		dmi_check_system(processor_power_dmi_table);
		...
		first_run++;
	}

The warning is about the reference to processor_power_dmi_table.  But as
long as the first call to acpi_processor_power_init() happens prior to
free_initmem(), we won't actually try to touch the unloaded memory.

It's fragile and nasty though - it'd be nice to sort it out.


Anyway.  It's regrettable that the new section-checking code didn't
complain about the bug.  It looks like this is because the call to
cpufreq_register_driver() happened at modprobe-time, and we don't check for
that.  Which is rather bad.

Sam, would it be possible to check for references from modules into
statically-linked __init code?  It's always wrong...

Rusty/Randy/whoever looks after modules: it also seems wrong that it's
possible to load a module which refers to now-unloaded symbols.  In fact,
it's surprising - sorry if I'm misinterpreting this.  If I'm not, it should
be pretty easy to barf if a module is trying to get at symbols which lie
between __init_begin and __init_end?

Chandra, this is scary stuff.  I'll tempdrop those patches until we can get
the kbuild/modprobe infrastructure in place which will allow us to fully
check your sectioning changes at depmod/modprobe time.

<thinks>

Actually, it should still be possible to do this - simply do a `make
allyesconfig; make' with the patches unapplied, then do it with the patches
applied and then look for the differences in the warnings.

Need to do this with various combinations of CONFIG_MODULES,
CONFIG_HOTPLUG, CONFIG_HOTPLUG_CPU, CONFIG_MEMORY_HOTPLUG,
CONFIG_ACPI_HOTPLUG_MEMORY and CONFIG_ACPI_HOTPLUG_MEMORY_MODULE.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25  9:37   ` 2.6.17-mm2 Barry K. Nathan
@ 2006-06-25 10:29     ` Reuben Farrelly
  0 siblings, 0 replies; 93+ messages in thread
From: Reuben Farrelly @ 2006-06-25 10:29 UTC (permalink / raw)
  To: Barry K. Nathan; +Cc: Andrew Morton, linux-kernel



On 25/06/2006 9:37 p.m., Barry K. Nathan wrote:
> On 6/24/06, Reuben Farrelly <reuben-lkml@reub.net> wrote:
>> 2.6.17-mm1 was a no-go for me due to the bustage with ReiserFS and 
>> bitmaps, even
>> the hotfix didn't seem to fix that...  :-(
> 
> Take 2.6.17-mm1, apply the hotfix, then apply this patch from 2.6.17-mm2 
> also:
> 
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/broken-out/reiserfs-reorganize-bitmap-loading-functions-fix2.patch 
> 
> 
> That should make 2.6.17-mm1's reiserfs work. (This way you can at
> least see whether your 2.6.17-mm2 bug happens under -mm1 as well.)

Thanks.  That seems to work a bit better...in fact -mm1 it seems to work just 
fine now.

The problem with Postfix and the disks shutting down is obviously new to -mm2.

Reuben

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (2 preceding siblings ...)
  2006-06-25  6:06 ` 2.6.17-mm2 Reuben Farrelly
@ 2006-06-25 11:19 ` Michal Piotrowski
  2006-06-25 11:40   ` 2.6.17-mm2 Andrew Morton
  2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall
                   ` (10 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Michal Piotrowski @ 2006-06-25 11:19 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

Hi,

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

I found this in /var/log/messages.1

Jun 24 22:29:52 ltg01-fedora kernel: BUG: unable to handle kernel
paging request at virtual address 6b6b6b7b
Jun 24 22:29:52 ltg01-fedora kernel:  printing eip:
Jun 24 22:29:52 ltg01-fedora kernel: c01174f2
Jun 24 22:29:52 ltg01-fedora kernel: *pde = 00000000
Jun 24 22:29:52 ltg01-fedora kernel: Oops: 0000 [#1]
Jun 24 22:29:52 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
Jun 24 22:29:52 ltg01-fedora kernel: last sysfs file:
/devices/platform/i2c-9191/9191-0290/temp2_input
Jun 24 22:29:52 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
iptable_filter ip_tables x_tables p4_clockmod speedstep_lib binfmt_
misc thermal processor fan container parport_pc parport nvram
snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq
_oss snd_seq_midi_event evdev snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd soundcore ide_cd snd_pa
ge_alloc intel_agp i2c_i801 sk98lin skge agpgart cdrom rtc unix
Jun 24 22:29:52 ltg01-fedora kernel: CPU:    0
Jun 24 22:29:52 ltg01-fedora kernel: EIP:    0060:[<c01174f2>]    Not
tainted VLI
Jun 24 22:29:52 ltg01-fedora kernel: EFLAGS: 00010096   (2.6.17-mm2 #51)
Jun 24 22:29:52 ltg01-fedora kernel: EIP is at task_rq_lock+0x1d/0x57
Jun 24 22:29:52 ltg01-fedora kernel: eax: 6b6b6b6b   ebx: c03cc740
ecx: c031e9e8   edx: f3aac7f0
Jun 24 22:29:52 ltg01-fedora kernel: esi: f3aac7f0   edi: ea28af5c
ebp: ea28af4c   esp: ea28af3c
Jun 24 22:29:52 ltg01-fedora kernel: ds: 007b   es: 007b   ss: 0068
Jun 24 22:29:52 ltg01-fedora kernel: Process sh (pid: 23201,
ti=ea28a000 task=f71f2e30 task.ti=ea28a000)
Jun 24 22:29:52 ltg01-fedora kernel: Stack: f3aac7f0 ea28af84 f3aac7f0
00000010 ea28af6c c011b1a6 f71f2e30 ea28af6c
Jun 24 22:29:52 ltg01-fedora kernel:        00000296 ea28af84 f71f2e30
00000010 ea28af98 c0120d9f 00000000 00000001
Jun 24 22:29:52 ltg01-fedora kernel:        f3726170 f71f2efc ea28af84
ea28af84 ea8f329c 00000000 49dd0140 ea28afac
Jun 24 22:29:52 ltg01-fedora kernel: Call Trace:
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0103d84>] show_stack_log_lvl+0x8c/0x97
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0103ef7>] show_registers+0x12c/0x199
Jun 24 22:29:52 ltg01-fedora kernel:  [<c01040f3>] die+0x18f/0x2ac
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0115afe>] do_page_fault+0x3dd/0x4c3
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0103911>] error_code+0x39/0x40
Jun 24 22:29:52 ltg01-fedora kernel:  [<c011b1a6>] sched_exit+0x29/0xab
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0120d9f>] do_exit+0x7d3/0x801
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0120e46>] sys_exit_group+0x0/0x11
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0120e55>] sys_exit_group+0xf/0x11
Jun 24 22:29:52 ltg01-fedora kernel:  [<c0102ddd>] sysenter_past_esp+0x56/0x79
Jun 24 22:29:52 ltg01-fedora kernel: Code: e9 1a 00 89 d8 e8 c1 e9 1a
00 5b 5e 5d c3 55 89 e5 57 56 53 83 ec 04 89 45 f0 89
d7 9c 8f 07 fa bb 40 c7 3c c0 8b 55 f0 8b 42 04 <8b> 40 10 89 de 03 34
85 00 66 39 c0 89 f0 e8 8d e9 1a 00 8b 55
Jun 24 22:29:52 ltg01-fedora kernel: EIP: [<c01174f2>]
task_rq_lock+0x1d/0x57 SS:ESP 0068:ea28af3c
Jun 24 22:29:52 ltg01-fedora kernel:  <1>Fixing recursive fault but
reboot is needed!

Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm2/mm-config

Regards,
Michal

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

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski
@ 2006-06-25 11:40   ` Andrew Morton
  2006-06-25 12:18     ` 2.6.17-mm2 Michal Piotrowski
  0 siblings, 1 reply; 93+ messages in thread
From: Andrew Morton @ 2006-06-25 11:40 UTC (permalink / raw)
  To: Michal Piotrowski; +Cc: linux-kernel

On Sun, 25 Jun 2006 13:19:25 +0200
"Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> On 24/06/06, Andrew Morton <akpm@osdl.org> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
> >
> 
> I found this in /var/log/messages.1
> 
> Jun 24 22:29:52 ltg01-fedora kernel: BUG: unable to handle kernel
> paging request at virtual address 6b6b6b7b
> Jun 24 22:29:52 ltg01-fedora kernel:  printing eip:
> Jun 24 22:29:52 ltg01-fedora kernel: c01174f2
> Jun 24 22:29:52 ltg01-fedora kernel: *pde = 00000000
> Jun 24 22:29:52 ltg01-fedora kernel: Oops: 0000 [#1]
> Jun 24 22:29:52 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> Jun 24 22:29:52 ltg01-fedora kernel: last sysfs file:
> /devices/platform/i2c-9191/9191-0290/temp2_input
> Jun 24 22:29:52 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> iptable_filter ip_tables x_tables p4_clockmod speedstep_lib binfmt_
> misc thermal processor fan container parport_pc parport nvram
> snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq
> _oss snd_seq_midi_event evdev snd_seq snd_seq_device snd_pcm_oss
> snd_mixer_oss snd_pcm snd_timer snd soundcore ide_cd snd_pa
> ge_alloc intel_agp i2c_i801 sk98lin skge agpgart cdrom rtc unix
> Jun 24 22:29:52 ltg01-fedora kernel: CPU:    0
> Jun 24 22:29:52 ltg01-fedora kernel: EIP:    0060:[<c01174f2>]    Not
> tainted VLI
> Jun 24 22:29:52 ltg01-fedora kernel: EFLAGS: 00010096   (2.6.17-mm2 #51)
> Jun 24 22:29:52 ltg01-fedora kernel: EIP is at task_rq_lock+0x1d/0x57

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




Begin forwarded message:

Date: Sun, 25 Jun 2006 01:31:12 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Subject: Re: more -mm2 troubles ...



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

> hm, look at the sched_exit() => task_rq_lock() use-after-free crash 
> below.
> 
> I bet it was p->real_parent that got freed. (because at the point we 
> call sched_exit() we already unlink ourselves from the parent so it is 
> free to exit)
> 
> We moved sched_exit() within exit.c to an unsafe place in mm2 - what 
> patch was that?

patch below seems to fix it for me. mm2 is now stable.

	Ingo

--------------
Subject: move sched_exit() back to under the tasklist_lock umbrella
From: Ingo Molnar <mingo@elte.hu>

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

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 kernel/exit.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Index: linux/kernel/exit.c
===================================================================
--- linux.orig/kernel/exit.c
+++ linux/kernel/exit.c
@@ -827,6 +827,7 @@ static void exit_notify(struct task_stru
 		state = EXIT_DEAD;
 	tsk->exit_state = state;
 
+	sched_exit(tsk);
 	write_unlock_irq(&tasklist_lock);
 
 	list_for_each_safe(_p, _n, &ptrace_dead) {
@@ -952,8 +953,6 @@ fastcall NORET_TYPE void do_exit(long co
 	if (tsk->splice_pipe)
 		__free_pipe_info(tsk->splice_pipe);
 
-	sched_exit(tsk);
-
 	/* PF_DEAD causes final put_task_struct after we schedule. */
 	preempt_disable();
 	BUG_ON(tsk->flags & PF_DEAD);

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 11:40   ` 2.6.17-mm2 Andrew Morton
@ 2006-06-25 12:18     ` Michal Piotrowski
  0 siblings, 0 replies; 93+ messages in thread
From: Michal Piotrowski @ 2006-06-25 12:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On 25/06/06, Andrew Morton <akpm@osdl.org> wrote:
> On Sun, 25 Jun 2006 13:19:25 +0200
> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
>
> > On 24/06/06, Andrew Morton <akpm@osdl.org> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
> > >
> >
> > I found this in /var/log/messages.1
> >
> > Jun 24 22:29:52 ltg01-fedora kernel: BUG: unable to handle kernel
> > paging request at virtual address 6b6b6b7b
> > Jun 24 22:29:52 ltg01-fedora kernel:  printing eip:
> > Jun 24 22:29:52 ltg01-fedora kernel: c01174f2
> > Jun 24 22:29:52 ltg01-fedora kernel: *pde = 00000000
> > Jun 24 22:29:52 ltg01-fedora kernel: Oops: 0000 [#1]
> > Jun 24 22:29:52 ltg01-fedora kernel: 4K_STACKS PREEMPT SMP
> > Jun 24 22:29:52 ltg01-fedora kernel: last sysfs file:
> > /devices/platform/i2c-9191/9191-0290/temp2_input
> > Jun 24 22:29:52 ltg01-fedora kernel: Modules linked in: ipv6 w83627hf
> > hwmon_vid hwmon i2c_isa af_packet ip_conntrack_netbios
> > _ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp
> > iptable_filter ip_tables x_tables p4_clockmod speedstep_lib binfmt_
> > misc thermal processor fan container parport_pc parport nvram
> > snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq
> > _oss snd_seq_midi_event evdev snd_seq snd_seq_device snd_pcm_oss
> > snd_mixer_oss snd_pcm snd_timer snd soundcore ide_cd snd_pa
> > ge_alloc intel_agp i2c_i801 sk98lin skge agpgart cdrom rtc unix
> > Jun 24 22:29:52 ltg01-fedora kernel: CPU:    0
> > Jun 24 22:29:52 ltg01-fedora kernel: EIP:    0060:[<c01174f2>]    Not
> > tainted VLI
> > Jun 24 22:29:52 ltg01-fedora kernel: EFLAGS: 00010096   (2.6.17-mm2 #51)
> > Jun 24 22:29:52 ltg01-fedora kernel: EIP is at task_rq_lock+0x1d/0x57
>
> OK, thanks.  I expect the below will fix that (I've since dropped the
> offending patches)
>

Problem fixed, thanks.

Regards,
Michal

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

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 10:22         ` 2.6.17-mm2 Andrew Morton
@ 2006-06-25 15:16           ` Andrew Morton
  2006-06-25 18:23             ` 2.6.17-mm2 Sam Ravnborg
  2006-06-30  7:38             ` 2.6.17-mm2 Randy.Dunlap
  2006-06-25 19:19           ` 2.6.17-mm2 Rafael J. Wysocki
  2006-06-26 20:13           ` 2.6.17-mm2 Chandra Seetharaman
  2 siblings, 2 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-25 15:16 UTC (permalink / raw)
  To: rjw, davej, linux-kernel, sekharan, rusty, rdunlap, sam

On Sun, 25 Jun 2006 03:22:43 -0700
Andrew Morton <akpm@osdl.org> wrote:

> Anyway.  It's regrettable that the new section-checking code didn't
> complain about the bug.  It looks like this is because the call to
> cpufreq_register_driver() happened at modprobe-time, and we don't check for
> that.  Which is rather bad.
> 
> Sam, would it be possible to check for references from modules into
> statically-linked __init code?  It's always wrong...
> 
> Rusty/Randy/whoever looks after modules: it also seems wrong that it's
> possible to load a module which refers to now-unloaded symbols.  In fact,
> it's surprising - sorry if I'm misinterpreting this.  If I'm not, it should
> be pretty easy to barf if a module is trying to get at symbols which lie
> between __init_begin and __init_end?
> 

Actually we should be able to address this pretty simply by disallowing
exports of symbols which are in the __init section.  There's no sense in
exporting something which ain't there.

IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future
into __init or __initdata should be a hard error.

It'd be lovely to do that at compile-time, but I cannot think of a way.

Sam, does that sound reasonable&&feasible?

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 (NULL pointer dereference)
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (3 preceding siblings ...)
  2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski
@ 2006-06-25 16:25 ` Dominik Karall
  2006-06-25 17:18   ` Andrew Morton
  2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk
                   ` (9 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Dominik Karall @ 2006-06-25 16:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Saturday, 24. June 2006 15:19, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
>7/2.6.17-mm2/

hi!

I got this error with 2.6.17-mm1 too, I took a picture with my mobile, 
hope it's readable:
http://stud4.tuwien.ac.at/~e0227135/kernel/060625_180209.jpg

hth,
dominik

^ permalink raw reply	[flat|nested] 93+ messages in thread

* 2.6.17-mm2: no QLA3YYY_NAPI help text
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (4 preceding siblings ...)
  2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall
@ 2006-06-25 16:47 ` Adrian Bunk
  2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk
                   ` (8 subsequent siblings)
  14 siblings, 0 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-25 16:47 UTC (permalink / raw)
  To: Andrew Morton, Ron Mercer
  Cc: linux-kernel, Jeff Garzik, Stephen Hemminger, netdev

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

On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm1:
>...
> +qla3xxx-NIC-driver.patch
>...
>  Net driver updates.  Includes a new driver from qlogic which almost compiles.
>...

The QLA3XXX_NAPI option lacks a help text.

Please add a help text.

TIA
Adrian

--

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


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 (NULL pointer dereference)
  2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall
@ 2006-06-25 17:18   ` Andrew Morton
  2006-06-25 18:11     ` Dominik Karall
  0 siblings, 1 reply; 93+ messages in thread
From: Andrew Morton @ 2006-06-25 17:18 UTC (permalink / raw)
  To: Dominik Karall; +Cc: linux-kernel

On Sun, 25 Jun 2006 18:25:26 +0200
Dominik Karall <dominik.karall@gmx.net> wrote:

> On Saturday, 24. June 2006 15:19, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1
> >7/2.6.17-mm2/
> 
> hi!
> 
> I got this error with 2.6.17-mm1 too, I took a picture with my mobile, 
> hope it's readable:
> http://stud4.tuwien.ac.at/~e0227135/kernel/060625_180209.jpg
> 

hm, that's new.  We do seem to be getting a few sysfs/kobject crashes in
there.

Do you actually have the bttv hardware present?

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 (NULL pointer dereference)
  2006-06-25 17:18   ` Andrew Morton
@ 2006-06-25 18:11     ` Dominik Karall
  0 siblings, 0 replies; 93+ messages in thread
From: Dominik Karall @ 2006-06-25 18:11 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Sunday, 25. June 2006 19:18, Andrew Morton wrote:
> On Sun, 25 Jun 2006 18:25:26 +0200
>
> Dominik Karall <dominik.karall@gmx.net> wrote:
> > On Saturday, 24. June 2006 15:19, Andrew Morton wrote:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> > >.6.1 7/2.6.17-mm2/
> >
> > hi!
> >
> > I got this error with 2.6.17-mm1 too, I took a picture with my
> > mobile, hope it's readable:
> > http://stud4.tuwien.ac.at/~e0227135/kernel/060625_180209.jpg
>
> hm, that's new.  We do seem to be getting a few sysfs/kobject
> crashes in there.
>
> Do you actually have the bttv hardware present?

Yes, the bttv hardware is present. You can find my lspci output and 
the .config file which I used for that kernel at:
http://stud4.tuwien.ac.at/~e0227135/kernel/

hth,
dominik

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
@ 2006-06-25 18:23             ` Sam Ravnborg
  2006-06-25 18:40               ` 2.6.17-mm2 Andrew Morton
  2006-06-30  7:38             ` 2.6.17-mm2 Randy.Dunlap
  1 sibling, 1 reply; 93+ messages in thread
From: Sam Ravnborg @ 2006-06-25 18:23 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rjw, davej, linux-kernel, sekharan, rusty, rdunlap

On Sun, Jun 25, 2006 at 08:16:10AM -0700, Andrew Morton wrote:
> On Sun, 25 Jun 2006 03:22:43 -0700
> 
> Actually we should be able to address this pretty simply by disallowing
> exports of symbols which are in the __init section.  There's no sense in
> exporting something which ain't there.
> 
> IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future
> into __init or __initdata should be a hard error.
We could let modpost error out. Then the module does not get build but
we detect it a bit later than optimal.

	Sam

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 18:23             ` 2.6.17-mm2 Sam Ravnborg
@ 2006-06-25 18:40               ` Andrew Morton
  2006-06-25 21:21                 ` 2.6.17-mm2 Sam Ravnborg
  0 siblings, 1 reply; 93+ messages in thread
From: Andrew Morton @ 2006-06-25 18:40 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: rjw, davej, linux-kernel, sekharan, rusty, rdunlap

On Sun, 25 Jun 2006 20:23:52 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> On Sun, Jun 25, 2006 at 08:16:10AM -0700, Andrew Morton wrote:
> > On Sun, 25 Jun 2006 03:22:43 -0700
> > 
> > Actually we should be able to address this pretty simply by disallowing
> > exports of symbols which are in the __init section.  There's no sense in
> > exporting something which ain't there.
> > 
> > IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future
> > into __init or __initdata should be a hard error.
> We could let modpost error out. Then the module does not get build but
> we detect it a bit later than optimal.
> 

Well, it doesn't have anything to do with modules per-se.  When vmlinux is
post-processed we want to error out if vmlinux is exporting any
__init/__initdata symbols to modules.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 10:22         ` 2.6.17-mm2 Andrew Morton
  2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
@ 2006-06-25 19:19           ` Rafael J. Wysocki
  2006-06-26 20:13           ` 2.6.17-mm2 Chandra Seetharaman
  2 siblings, 0 replies; 93+ messages in thread
From: Rafael J. Wysocki @ 2006-06-25 19:19 UTC (permalink / raw)
  To: Andrew Morton
  Cc: davej, linux-kernel, sekharan, Rusty Russell, Randy.Dunlap, Sam Ravnborg

On Sunday 25 June 2006 12:22, Andrew Morton wrote:
> On Sun, 25 Jun 2006 10:51:55 +0200
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
> > > > 
> > > 
> > > My guess would be that cpufreq_register_driver() is being called after it
> > > has been unloaded from the kernel.
> > > 
> > > Do you have CONFIG_CPU_FREQ=y?
> > 
> > Yes.
> > 
> > > Does removal of the __cpuinit from cpufreq_register_driver() fix it (or
> > > move the crash elsewhere)?
> > 
> > Yes (makes it go away).
> 
> Well it would appear that the new __cpuinit on cpufreq_register_driver() is
> causing the problem, although I'm surprised that you don't have
> CONFIG_HOTPLUG_CPU set, if it's a swsusp requirement??

It's only required if CONFIG_SMP is set. ;-)

Greetings,
Rafael

^ permalink raw reply	[flat|nested] 93+ messages in thread

* 2.6.17-mm2: BLK_CPQ_CISS_DA=m error
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (5 preceding siblings ...)
  2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk
@ 2006-06-25 19:32 ` Adrian Bunk
  2006-06-26  0:41   ` Vivek Goyal
  2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk
                   ` (7 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Adrian Bunk @ 2006-06-25 19:32 UTC (permalink / raw)
  To: Andrew Morton, Vivek Goyal
  Cc: linux-kernel, mike.miller, iss_storagedev, hbabu, fastboot

On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm1:
>...
> +kdump-cciss-driver-initialization-issue-fix.patch
> 
>  Unpleasant kdump patches.
>...

This patch breaks CONFIG_BLK_CPQ_CISS_DA=m:

<--  snip  -->

...
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  2.6.17-mm2; fi
WARNING: /lib/modules/2.6.17-mm2/kernel/drivers/block/cciss.ko needs unknown symbol crash_boot

<--  snip  -->
 
cu
Adrian

-- 

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


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 18:40               ` 2.6.17-mm2 Andrew Morton
@ 2006-06-25 21:21                 ` Sam Ravnborg
  0 siblings, 0 replies; 93+ messages in thread
From: Sam Ravnborg @ 2006-06-25 21:21 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rjw, davej, linux-kernel, sekharan, rusty, rdunlap

On Sun, Jun 25, 2006 at 11:40:51AM -0700, Andrew Morton wrote:
 > > 
> > > IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future
> > > into __init or __initdata should be a hard error.
> > We could let modpost error out. Then the module does not get build but
> > we detect it a bit later than optimal.
> > 
> 
> Well, it doesn't have anything to do with modules per-se.  When vmlinux is
> post-processed we want to error out if vmlinux is exporting any
> __init/__initdata symbols to modules.

modpost has evolved over time and when I get the time I will refactor
kbuild so we always call modpost in the final steps of the kernel build
independent on module support or not. And then is makes perfect sense
to have the check for exported symbols from illegal sections located
there.
In other words current modpost will be used also when
executing "make vmlinux". That impose a few tricky things and I have
posponed it for now. Implementing the suggested check should be possible
and will try to look at that sooner.

	Sam


^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (6 preceding siblings ...)
  2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk
@ 2006-06-25 23:13 ` Adrian Bunk
  2006-06-25 23:27   ` Alan Cox
  2006-06-27  1:03   ` Jeff Garzik
  2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk
                   ` (6 subsequent siblings)
  14 siblings, 2 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-25 23:13 UTC (permalink / raw)
  To: Andrew Morton, alan; +Cc: linux-kernel, jgarzik, linux-ide

On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm1:
>...
>  git-libata-all.patch
>...
>  git trees
>...

This patch makes the needlessly global it821x_passthru_dev_select() 
static.

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

--- linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c.old	2006-06-25 22:52:11.000000000 +0200
+++ linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c	2006-06-25 22:52:52.000000000 +0200
@@ -411,7 +411,8 @@
  *	Device selection hook. If neccessary perform clock switching
  */
  
-void it821x_passthru_dev_select(struct ata_port *ap, unsigned int device)
+static void it821x_passthru_dev_select(struct ata_port *ap,
+				       unsigned int device)
 {
 	struct it821x_dev *itdev = ap->private_data;
 	if (itdev && device != itdev->last_device) {


^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (7 preceding siblings ...)
  2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk
@ 2006-06-25 23:13 ` Adrian Bunk
  2006-06-26  4:05   ` Steven French
  2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk
                   ` (5 subsequent siblings)
  14 siblings, 1 reply; 93+ messages in thread
From: Adrian Bunk @ 2006-06-25 23:13 UTC (permalink / raw)
  To: Andrew Morton, Steven French; +Cc: linux-kernel, linux-cifs-client

On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm1:
>...
> +cifs-build-fix.patch
> 
>  Fix git-cifs.patch.
>...

Let's hope gcc guesses the prototye of the function right.

Otherwise, this patch has turned a compile error into a nasty runtime 
error (in many cases, the stack is garbage).

The -Werror-implicit-function-declaration gcc flag would turn such 
possible problems into compile errors.

This patch removes the (never required) #ifdef from the prototype of 
thie function in fs/cifs/cifsproto.h. 
 
Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.17-mm2-full/fs/cifs/cifsproto.h.old	2006-06-26 00:00:56.000000000 +0200
+++ linux-2.6.17-mm2-full/fs/cifs/cifsproto.h	2006-06-26 00:01:02.000000000 +0200
@@ -64,11 +64,9 @@
 extern void header_assemble(struct smb_hdr *, char /* command */ ,
 			    const struct cifsTconInfo *, int /* length of
 			    fixed section (word count) in two byte units */);
-#ifdef CONFIG_CIFS_EXPERIMENTAL
 extern int small_smb_init_no_tc(const int smb_cmd, const int wct,
 				struct cifsSesInfo *ses,
 				void ** request_buf);
-#endif
 extern int CIFS_SessSetup(unsigned int xid, struct cifsSesInfo *ses,
 			     const int stage, 
 			     const struct nls_table *nls_cp);


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static
  2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk
@ 2006-06-25 23:27   ` Alan Cox
  2006-06-27  1:03   ` Jeff Garzik
  1 sibling, 0 replies; 93+ messages in thread
From: Alan Cox @ 2006-06-25 23:27 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, alan, linux-kernel, jgarzik, linux-ide

On Mon, Jun 26, 2006 at 01:13:24AM +0200, Adrian Bunk wrote:
> On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-mm1:
> >...
> >  git-libata-all.patch
> >...
> >  git trees
> >...
> 
> This patch makes the needlessly global it821x_passthru_dev_select() 
> static.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

Acked-by: Alan Cox <alan@redhat.com>

> 
> --- linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c.old	2006-06-25 22:52:11.000000000 +0200
> +++ linux-2.6.17-mm2-full/drivers/scsi/pata_it821x.c	2006-06-25 22:52:52.000000000 +0200
> @@ -411,7 +411,8 @@
>   *	Device selection hook. If neccessary perform clock switching
>   */
>   
> -void it821x_passthru_dev_select(struct ata_port *ap, unsigned int device)
> +static void it821x_passthru_dev_select(struct ata_port *ap,
> +				       unsigned int device)
>  {
>  	struct it821x_dev *itdev = ap->private_data;
>  	if (itdev && device != itdev->last_device) {

-- 
	"Some people are like Slinkies...
	Not really good for anything,
	but they still bring a smile to your face
	when you push them down a flight of stairs."
			-- Gordon Wolfe.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2: BLK_CPQ_CISS_DA=m error
  2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk
@ 2006-06-26  0:41   ` Vivek Goyal
  0 siblings, 0 replies; 93+ messages in thread
From: Vivek Goyal @ 2006-06-26  0:41 UTC (permalink / raw)
  To: Adrian Bunk, Morton Andrew Morton
  Cc: linux-kernel, mike.miller, iss_storagedev, hbabu, fastboot

On Sun, Jun 25, 2006 at 09:32:21PM +0200, Adrian Bunk wrote:
> On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-mm1:
> >...
> > +kdump-cciss-driver-initialization-issue-fix.patch
> > 
> >  Unpleasant kdump patches.
> >...
> 
> This patch breaks CONFIG_BLK_CPQ_CISS_DA=m:
> 
> <--  snip  -->
> 
> ...
> if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  2.6.17-mm2; fi
> WARNING: /lib/modules/2.6.17-mm2/kernel/drivers/block/cciss.ko needs unknown symbol crash_boot
>

Sorry. I forgot to export the symbol crash_boot. Please find attached the
patch.

Thanks
Vivek
 


o Compilation of cciss driver broke when compiled as a module as crash_boot
  was not exported.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---

 linux-2.6.17-1M-vivek/init/main.c |    1 +
 1 files changed, 1 insertion(+)

diff -puN init/main.c~cciss-module-compilation-break-fix init/main.c
--- linux-2.6.17-1M/init/main.c~cciss-module-compilation-break-fix	2006-06-25 20:31:24.000000000 -0400
+++ linux-2.6.17-1M-vivek/init/main.c	2006-06-25 20:31:24.000000000 -0400
@@ -131,6 +131,7 @@ static char *ramdisk_execute_command;
  * context.
  */
 unsigned int crash_boot;
+EXPORT_SYMBOL(crash_boot);
 
 /* Setup configured maximum number of CPUs to activate */
 static unsigned int max_cpus = NR_CPUS;
_

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype
  2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk
@ 2006-06-26  4:05   ` Steven French
  0 siblings, 0 replies; 93+ messages in thread
From: Steven French @ 2006-06-26  4:05 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, linux-cifs-client, linux-kernel

The equivalent fix should already be merged in now

 The missed ifdef removal happened a couple days ago as I turned on the 
previously experimental  new session establishment code (in 
fs/cifs/sess.c) and turn off the older code in fs/cifs/connect.c 
(necessary for legacy win9x lanman server support and more secure (ntlmv2) 
session establishment support).    I have a few relatively minor changes 
to make to fs/cifs/sess.c (including changing buffer allocation in a few 
places, an ntlmv2 fix for support of one server type) still.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

Adrian Bunk <bunk@stusta.de> wrote on 06/25/2006 06:13:29 PM:

> On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.17-mm1:
> >...
> > +cifs-build-fix.patch
> > 
> >  Fix git-cifs.patch.
> >...
> 
> Let's hope gcc guesses the prototye of the function right.
> 
> Otherwise, this patch has turned a compile error into a nasty runtime 
> error (in many cases, the stack is garbage).
> 
> The -Werror-implicit-function-declaration gcc flag would turn such 
> possible problems into compile errors.
> 
> This patch removes the (never required) #ifdef from the prototype of 
> thie function in fs/cifs/cifsproto.h. 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6.17-mm2-full/fs/cifs/cifsproto.h.old   2006-06-26 00:
> 00:56.000000000 +0200
> +++ linux-2.6.17-mm2-full/fs/cifs/cifsproto.h   2006-06-26 00:01:02.
> 000000000 +0200
> @@ -64,11 +64,9 @@
>  extern void header_assemble(struct smb_hdr *, char /* command */ ,
>               const struct cifsTconInfo *, int /* length of
>               fixed section (word count) in two byte units */);
> -#ifdef CONFIG_CIFS_EXPERIMENTAL
>  extern int small_smb_init_no_tc(const int smb_cmd, const int wct,
>              struct cifsSesInfo *ses,
>              void ** request_buf);
> -#endif
>  extern int CIFS_SessSetup(unsigned int xid, struct cifsSesInfo *ses,
>                const int stage, 
>                const struct nls_table *nls_cp);
> 


^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] drivers/scsi/arcmsr/: cleanups
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (8 preceding siblings ...)
  2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk
@ 2006-06-26 15:17 ` Adrian Bunk
  2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk
                   ` (4 subsequent siblings)
  14 siblings, 0 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-26 15:17 UTC (permalink / raw)
  To: Andrew Morton, Erich Chen; +Cc: linux-kernel, James.Bottomley, linux-scsi

This patch contains the following cleanups:
- arcmsr_attr.c: #if 0 the unused arcmsr_free_sysfs_attr()
- arcmsr_hba.c: make the needlessly global arcmsr_iop_reset() static

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

---

 drivers/scsi/arcmsr/arcmsr_attr.c |    2 ++
 drivers/scsi/arcmsr/arcmsr_hba.c  |    2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_attr.c.old	2006-06-26 01:43:40.000000000 +0200
+++ linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_attr.c	2006-06-26 01:44:00.000000000 +0200
@@ -171,12 +171,14 @@
 							&arcmsr_sysfs_message_transfer_attr);
 }
 
+#if 0
 void
 arcmsr_free_sysfs_attr(struct AdapterControlBlock *acb) {
 	struct Scsi_Host *host = acb->host;
 
 	sysfs_remove_bin_file(&host->shost_gendev.kobj, &arcmsr_sysfs_message_transfer_attr);
 }
+#endif  /*  0  */
 
 static ssize_t
 arcmsr_attr_host_driver_version(struct class_device *cdev, char *buf) {
--- linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_hba.c.old	2006-06-26 01:44:09.000000000 +0200
+++ linux-2.6.17-mm2-full/drivers/scsi/arcmsr/arcmsr_hba.c	2006-06-26 01:44:19.000000000 +0200
@@ -1357,7 +1357,7 @@
 	acb->acb_flags |= ACB_F_IOP_INITED;
 }
 
-void arcmsr_iop_reset(struct AdapterControlBlock *acb)
+static void arcmsr_iop_reset(struct AdapterControlBlock *acb)
 {
 	struct MessageUnit __iomem *reg = acb->pmu;
 	struct CommandControlBlock *ccb;


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 10:22         ` 2.6.17-mm2 Andrew Morton
  2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
  2006-06-25 19:19           ` 2.6.17-mm2 Rafael J. Wysocki
@ 2006-06-26 20:13           ` Chandra Seetharaman
  2 siblings, 0 replies; 93+ messages in thread
From: Chandra Seetharaman @ 2006-06-26 20:13 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Rafael J. Wysocki, davej, linux-kernel, Rusty Russell,
	Randy.Dunlap, Sam Ravnborg

On Sun, 2006-06-25 at 03:22 -0700, Andrew Morton wrote:

> Chandra, this is scary stuff.  I'll tempdrop those patches until we can get
> the kbuild/modprobe infrastructure in place which will allow us to fully
> check your sectioning changes at depmod/modprobe time.
> 
> <thinks>
> 
> Actually, it should still be possible to do this - simply do a `make
> allyesconfig; make' with the patches unapplied, then do it with the patches
> applied and then look for the differences in the warnings.

Andrew, 

After looking at the code closely, IMO, the patch you applied om -mm
(title cpufreq_register_driver-section-fix) seem to be in the right
direction.

It does need another patch to make sure the hotplug version of the cpu
notifier register/unregister is used in cpufreq.

Below is a patch.
> 
> Need to do this with various combinations of CONFIG_MODULES,
> CONFIG_HOTPLUG, CONFIG_HOTPLUG_CPU, CONFIG_MEMORY_HOTPLUG,
> CONFIG_ACPI_HOTPLUG_MEMORY and CONFIG_ACPI_HOTPLUG_MEMORY_MODULE.

I will test these combinations.
---------------------


cpufreq_register_driver() has to made available at all time (not init
only). Hence, we should be using hotplug version of the cpu notifier
register/unregister function instead of the _init time only_ version.

Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com>
--
 drivers/cpufreq/cpufreq.c |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

Index: linux-2.6.17/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-2.6.17.orig/drivers/cpufreq/cpufreq.c
+++ linux-2.6.17/drivers/cpufreq/cpufreq.c
@@ -1497,7 +1497,8 @@ int cpufreq_update_policy(unsigned int c
 }
 EXPORT_SYMBOL(cpufreq_update_policy);
 
-static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb,
+#ifdef CONFIG_HOTPLUG_CPU
+static int cpufreq_cpu_callback(struct notifier_block *nfb,
 					unsigned long action, void *hcpu)
 {
 	unsigned int cpu = (unsigned long)hcpu;
@@ -1536,6 +1537,7 @@ static struct notifier_block __cpuinitda
 {
     .notifier_call = cpufreq_cpu_callback,
 };
+#endif /* CONFIG_HOTPLUG_CPU */
 
 /*********************************************************************
  *               REGISTER / UNREGISTER CPUFREQ DRIVER                *
@@ -1596,7 +1598,7 @@ int cpufreq_register_driver(struct cpufr
 	}
 
 	if (!ret) {
-		register_cpu_notifier(&cpufreq_cpu_notifier);
+		register_hotcpu_notifier(&cpufreq_cpu_notifier);
 		dprintk("driver %s up and running\n", driver_data->name);
 		cpufreq_debug_enable_ratelimit();
 	}
@@ -1628,7 +1630,7 @@ int cpufreq_unregister_driver(struct cpu
 	dprintk("unregistering driver %s\n", driver->name);
 
 	sysdev_driver_unregister(&cpu_sysdev_class, &cpufreq_sysdev_driver);
-	unregister_cpu_notifier(&cpufreq_cpu_notifier);
+	unregister_hotcpu_notifier(&cpufreq_cpu_notifier);
 
 	spin_lock_irqsave(&cpufreq_driver_lock, flags);
 	cpufreq_driver = NULL;

-- 

----------------------------------------------------------------------
    Chandra Seetharaman               | Be careful what you choose....
              - sekharan@us.ibm.com   |      .......you may get it.
----------------------------------------------------------------------



^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] drivers/md/raid5.c: remove an unused variable
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (9 preceding siblings ...)
  2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk
@ 2006-06-26 20:27 ` Adrian Bunk
  2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
                   ` (3 subsequent siblings)
  14 siblings, 0 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-26 20:27 UTC (permalink / raw)
  To: Andrew Morton, Neil Brown; +Cc: linux-kernel, mingo, linux-raid

This patch removes an unused variable.

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

--- linux-2.6.17-mm2-full/drivers/md/raid5.c.old	2006-06-26 21:17:13.000000000 +0200
+++ linux-2.6.17-mm2-full/drivers/md/raid5.c	2006-06-26 21:17:20.000000000 +0200
@@ -2827,7 +2827,6 @@
 	struct stripe_head *sh;
 	int pd_idx;
 	int raid_disks = conf->raid_disks;
-	int data_disks = raid_disks - conf->max_degraded;
 	sector_t max_sector = mddev->size << 1;
 	int sync_blocks;
 	int still_degraded = 0;


^ permalink raw reply	[flat|nested] 93+ messages in thread

* 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (10 preceding siblings ...)
  2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk
@ 2006-06-26 21:41 ` Valdis.Kletnieks
  2006-06-26 22:50   ` Valdis.Kletnieks
                     ` (3 more replies)
  2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk
                   ` (2 subsequent siblings)
  14 siblings, 4 replies; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-26 21:41 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/

I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer
related.  This is at fairly early userspace - the initrd has run, but we're not
into /etc/rc.sysinit yet (although the root filesystem is mounted and we have
a kjournald for it).  Poking with sysrq-T and sysrq-R gets me this:

[  108.301806] Pid: 4, comm:              khelper
[  108.330565] EIP: 0060:[<c0119f48>] CPU: 0
[  108.359315] EIP is at getnstimeofday+0x9e/0xb8
[  108.387820]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2 #1)
[  108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
[  108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b
[  108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
[  108.501579]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
[  108.530366]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[  108.559363]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
[  108.588523]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
[  108.617618]  <c01006c5> kernel_thread_helper+0x5/0xb
[  115.881903] SysRq : Show Regs
[  115.910288]
[  115.938097] Pid: 4, comm:              khelper
[  115.965908] EIP: 0060:[<c0119f48>] CPU: 0
[  115.993553] EIP is at getnstimeofday+0x9e/0xb8
[  116.020928]  EFLAGS: 00000287    Not tainted  (2.6.17-mm2 #1)
[  116.048387] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
[  116.075750] ESI: 9484965a EDI: 2262af5b EBP: effd0e5c DS: 007b ES: 007b
[  116.103240] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
[  116.130449]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
[  116.158078]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[  116.185729]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
[  116.213729]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
[  116.241689]  <c01006c5> kernel_thread_helper+0x5/0xb

Looking at the body of ktime_get_ts, I see:

        do {
                seq = read_seqbegin(&xtime_lock);
                getnstimeofday(ts);
                tomono = wall_to_monotonic;

        } while (read_seqretry(&xtime_lock, seq));

Which looks like a good place to get hung in a loop for a while....

Eventually (after about 2 minutes, it finally unwedges and continues on.

Any ideas?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
@ 2006-06-26 22:50   ` Valdis.Kletnieks
  2006-06-26 23:02   ` john stultz
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-26 22:50 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

On Mon, 26 Jun 2006 17:41:07 EDT, Valdis.Kletnieks@vt.edu said:
> I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer
> related.  This is at fairly early userspace - the initrd has run, but we're not
> into /etc/rc.sysinit yet (although the root filesystem is mounted and we have
> a kjournald for it).  Poking with sysrq-T and sysrq-R gets me this:
> 
> [  108.301806] Pid: 4, comm:              khelper
> [  108.330565] EIP: 0060:[<c0119f48>] CPU: 0
> [  108.359315] EIP is at getnstimeofday+0x9e/0xb8
> [  108.387820]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2 #1)
> [  108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
> [  108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b
> [  108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
> [  108.501579]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
> [  108.530366]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
> [  108.559363]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
> [  108.588523]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
> [  108.617618]  <c01006c5> kernel_thread_helper+0x5/0xb

Seems to be a problem with time in general - another reboot, and lots of
sysrq-P, and I got these (note that this time around, rc.sysinit *did* get
started, so we're apparently just making very slow progress rather than
being hung and spinning for 90 seconds....

[   81.127021] SysRq : Show Regs
[   81.147732] 
[   81.168172] Pid: 1, comm:                 init
[   81.188564] EIP: 0060:[<c0119ffc>] CPU: 0
[   81.208879] EIP is at do_gettimeofday+0x9a/0xc5
[   81.229104]  EFLAGS: 00000217    Not tainted  (2.6.17-mm2 #1)
[   81.249441] EAX: d8ad347c EBX: f380a310 ECX: 66521e65 EDX: 226cbe02
[   81.270003] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b
[   81.290974] CR0: 8005003b CR2: b7e7f0a8 CR3: 2ffbc000 CR4: 000006d0
[   81.312250]  <c01169ae> sys_time+0xe/0x2f  <c0102261> sysenter_past_esp+0x56/0x79
[   86.545414] SysRq : Show Regs
[   86.566974] 
[   86.588290] Pid: 1, comm:                 init
[   86.609807] EIP: 0060:[<c0119ffc>] CPU: 0
[   86.631315] EIP is at do_gettimeofday+0x9a/0xc5
[   86.652737]  EFLAGS: 00000213    Not tainted  (2.6.17-mm2 #1)
[   86.674312] EAX: 1c0a39da EBX: f380a310 ECX: 56a2f30b EDX: d7a49202
[   86.696028] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b
[   86.717769] CR0: 8005003b CR2: b7e7f0a8 CR3: 2ffbc000 CR4: 000006d0
[   86.739558]  <c01169ae> sys_time+0xe/0x2f  <c0102261> sysenter_past_esp+0x56/0x79
[   88.427273] SysRq : Show Regs
[   88.449183] 
[   88.470683] Pid: 421, comm:           rc.sysinit
[   88.492222] EIP: 0060:[<c0119f40>] CPU: 0
[   88.513633] EIP is at getnstimeofday+0x96/0xb8
[   88.535030]  EFLAGS: 00000283    Not tainted  (2.6.17-mm2 #1)
[   88.556511] EAX: efed47bc EBX: efed47bc ECX: 00000000 EDX: 0b16e0d5
[   88.578361] ESI: b2c0c4bc EDI: 27c01a01 EBP: ef7d5f04 DS: 007b ES: 007b
[   88.600340] CR0: 8005003b CR2: b7e7f0a8 CR3: 2f26d000 CR4: 000006d0
[   88.622445]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
[   88.645207]  <c0111f3c> do_fork+0x8d/0x16a  <c010099b> sys_clone+0x25/0x2a
[   88.668218]  <c0102261> sysenter_past_esp+0x56/0x79 
[   94.619871] SysRq : Show Regs
[   94.642631] 
[   94.664936] Pid: 421, comm:           rc.sysinit
[   94.687452] EIP: 0060:[<c0119f48>] CPU: 0
[   94.709938] EIP is at getnstimeofday+0x9e/0xb8
[   94.732370]  EFLAGS: 00000203    Not tainted  (2.6.17-mm2 #1)
[   94.755031] EAX: efed47bc EBX: efed47bc ECX: 00000000 EDX: 0b16e0d5
[   94.777989] ESI: cd6d54bc EDI: 179d2144 EBP: ef7d5f04 DS: 007b ES: 007b
[   94.800978] CR0: 8005003b CR2: b7e7f0a8 CR3: 2f26d000 CR4: 000006d0
[   94.823986]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
[   94.847793]  <c0111f3c> do_fork+0x8d/0x16a  <c010099b> sys_clone+0x25/0x2a
[   94.871627]  <c0102261> sysenter_past_esp+0x56/0x79 
[   99.793372] SysRq : Show Regs
[   99.816696] 
[   99.839669] Pid: 1, comm:                 init
[   99.862968] EIP: 0060:[<c0119ffc>] CPU: 0
[   99.886127] EIP is at do_gettimeofday+0x9a/0xc5
[   99.909505]  EFLAGS: 00000213    Not tainted  (2.6.17-mm2 #1)
[   99.933139] EAX: bb9074fb EBX: f380a310 ECX: 317e8ecb EDX: c0228802
[   99.957174] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b
[   99.981281] CR0: 8005003b CR2: b7e7f0a8 CR3: 2ffbc000 CR4: 000006d0
[  100.005492]  <c01169ae> sys_time+0xe/0x2f  <c0102261> sysenter_past_esp+0x56/0x79
[  103.357517] SysRq : Show Regs
[  103.380851] 
[  103.403016] Pid: 421, comm:           rc.sysinit
[  103.425480] EIP: 0060:[<c0119f48>] CPU: 0
[  103.447836] EIP is at getnstimeofday+0x9e/0xb8
[  103.470260]  EFLAGS: 00000287    Not tainted  (2.6.17-mm2 #1)
[  103.493102] EAX: efed47bc EBX: efed47bc ECX: 00000000 EDX: 0b16e0d5
[  103.516288] ESI: 09ac3ebc EDI: 00eac4ec EBP: ef7d5f04 DS: 007b ES: 007b
[  103.539636] CR0: 8005003b CR2: b7e7f0a8 CR3: 2f26d000 CR4: 000006d0
[  103.563122]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
[  103.587133]  <c0111f3c> do_fork+0x8d/0x16a  <c010099b> sys_clone+0x25/0x2a
[  103.610981]  <c0102261> sysenter_past_esp+0x56/0x79 
[  105.595474] SysRq : Show Regs
[  105.618994] 
[  105.641896] Pid: 1, comm:                 init
[  105.664562] EIP: 0060:[<c0119ffc>] CPU: 0
[  105.687319] EIP is at do_gettimeofday+0x9a/0xc5
[  105.710233]  EFLAGS: 00000217    Not tainted  (2.6.17-mm2 #1)
[  105.733426] EAX: 0b996673 EBX: f380a310 ECX: 1edc1a9c EDX: c769d802
[  105.756826] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b
[  105.780234] CR0: 8005003b CR2: b7d1f000 CR3: 2ffbc000 CR4: 000006d0
[  105.803629]  <c01169ae> sys_time+0xe/0x2f  <c0102261> sysenter_past_esp+0x56/0x79
[  106.787956] Real Time Clock Driver v1.12ac

Every single one doing something time-related.  I'm pretty sure that the
RTC driver is a red herring - I stuck a 'set -x' in rc.sysinit, and we're
moving along nicely by that point - whatever is wedging it has broken loose
by that point.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
  2006-06-26 22:50   ` Valdis.Kletnieks
@ 2006-06-26 23:02   ` john stultz
  2006-06-26 23:27   ` Thomas Gleixner
  2006-06-27 10:16   ` Roman Zippel
  3 siblings, 0 replies; 93+ messages in thread
From: john stultz @ 2006-06-26 23:02 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel

On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
> 
> I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer
> related.  This is at fairly early userspace - the initrd has run, but we're not
> into /etc/rc.sysinit yet (although the root filesystem is mounted and we have
> a kjournald for it).  Poking with sysrq-T and sysrq-R gets me this:
> 
> [  108.301806] Pid: 4, comm:              khelper
> [  108.330565] EIP: 0060:[<c0119f48>] CPU: 0
> [  108.359315] EIP is at getnstimeofday+0x9e/0xb8
> [  108.387820]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2 #1)
> [  108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
> [  108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b
> [  108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
> [  108.501579]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
> [  108.530366]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
> [  108.559363]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
> [  108.588523]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
> [  108.617618]  <c01006c5> kernel_thread_helper+0x5/0xb
> [  115.881903] SysRq : Show Regs
> [  115.910288]
> [  115.938097] Pid: 4, comm:              khelper
> [  115.965908] EIP: 0060:[<c0119f48>] CPU: 0
> [  115.993553] EIP is at getnstimeofday+0x9e/0xb8
> [  116.020928]  EFLAGS: 00000287    Not tainted  (2.6.17-mm2 #1)
> [  116.048387] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
> [  116.075750] ESI: 9484965a EDI: 2262af5b EBP: effd0e5c DS: 007b ES: 007b
> [  116.103240] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
> [  116.130449]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
> [  116.158078]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
> [  116.185729]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
> [  116.213729]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
> [  116.241689]  <c01006c5> kernel_thread_helper+0x5/0xb
> 
> Looking at the body of ktime_get_ts, I see:
> 
>         do {
>                 seq = read_seqbegin(&xtime_lock);
>                 getnstimeofday(ts);
>                 tomono = wall_to_monotonic;
> 
>         } while (read_seqretry(&xtime_lock, seq));
> 
> Which looks like a good place to get hung in a loop for a while....
> 
> Eventually (after about 2 minutes, it finally unwedges and continues on.
> 
> Any ideas?

It does look like something is hogging the xtime_lock. Does this occur
w/o HRT enabled? 

Could you also send me your .config and dmesg please?

thanks
-john



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
  2006-06-26 22:50   ` Valdis.Kletnieks
  2006-06-26 23:02   ` john stultz
@ 2006-06-26 23:27   ` Thomas Gleixner
  2006-06-27  2:12     ` Valdis.Kletnieks
  2006-06-27 10:16   ` Roman Zippel
  3 siblings, 1 reply; 93+ messages in thread
From: Thomas Gleixner @ 2006-06-26 23:27 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel

On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm2/
> 
> I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer
> related.  

hrtimer is not really involved here.

> This is at fairly early userspace - the initrd has run, but we're not
> into /etc/rc.sysinit yet (although the root filesystem is mounted and we have
> a kjournald for it).  Poking with sysrq-T and sysrq-R gets me this:
> 
> [  108.301806] Pid: 4, comm:              khelper
> [  108.330565] EIP: 0060:[<c0119f48>] CPU: 0
> [  108.359315] EIP is at getnstimeofday+0x9e/0xb8
> [  108.387820]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2 #1)
> [  108.416344] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
> [  108.444765] ESI: a7955c5a EDI: 4a12cf06 EBP: effd0e5c DS: 007b ES: 007b
> [  108.473303] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
> [  108.501579]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
> [  108.530366]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
> [  108.559363]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
> [  108.588523]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
> [  108.617618]  <c01006c5> kernel_thread_helper+0x5/0xb
> [  115.881903] SysRq : Show Regs
> [  115.910288]
> [  115.938097] Pid: 4, comm:              khelper
> [  115.965908] EIP: 0060:[<c0119f48>] CPU: 0
> [  115.993553] EIP is at getnstimeofday+0x9e/0xb8
> [  116.020928]  EFLAGS: 00000287    Not tainted  (2.6.17-mm2 #1)
> [  116.048387] EAX: efed073c EBX: efed073c ECX: 00000000 EDX: 0f16d9ba
> [  116.075750] ESI: 9484965a EDI: 2262af5b EBP: effd0e5c DS: 007b ES: 007b
> [  116.103240] CR0: 8005003b CR2: b7d9acb0 CR3: 2ffbc000 CR4: 000006d0
> [  116.130449]  <c0125c0c> ktime_get_ts+0x14/0x3f  <c0110f84> copy_process+0x395/0x1111
> [  116.158078]  <c0111f3c> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
> [  116.185729]  <c0120431> __call_usermodehelper+0x2b/0x44  <c0120982> run_workqueue+0x94/0xe9
> [  116.213729]  <c0120e64> worker_thread+0xe1/0x115  <c01232b2> kthread+0xb0/0xdc
> [  116.241689]  <c01006c5> kernel_thread_helper+0x5/0xb
> 
> Looking at the body of ktime_get_ts, I see:
> 
>         do {
>                 seq = read_seqbegin(&xtime_lock);
>                 getnstimeofday(ts);
>                 tomono = wall_to_monotonic;
> 
>         } while (read_seqretry(&xtime_lock, seq));

>From the stack trace:

copy_process:
 ....
 do_posix_clock_monotonic_gettime(&p->start_time);

#define do_posix_clock_monotonic_gettime(ts) ktime_get_ts(ts)

ktime_get_ts() has not been touched since it was merged in 2.6.16

Can you provide the complete boot log up to this point please ? -
Preferably over serial console.

	tglx




^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static
  2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk
  2006-06-25 23:27   ` Alan Cox
@ 2006-06-27  1:03   ` Jeff Garzik
  1 sibling, 0 replies; 93+ messages in thread
From: Jeff Garzik @ 2006-06-27  1:03 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, alan, linux-kernel, linux-ide

applied


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-26 23:27   ` Thomas Gleixner
@ 2006-06-27  2:12     ` Valdis.Kletnieks
  2006-06-27  5:54       ` Thomas Gleixner
  0 siblings, 1 reply; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-27  2:12 UTC (permalink / raw)
  To: tglx; +Cc: Andrew Morton, linux-kernel

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

On Tue, 27 Jun 2006 01:27:09 +0200, Thomas Gleixner said:
> On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said:
> > > 
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.
17-mm2/
> > 
> > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer
> > related.  
> 
> hrtimer is not really involved here.

OK, the fact that it was continually in kernel/hrtimer.c was a red herring? :)

(2.6.17-mm1 worked OK on this...)

> ktime_get_ts() has not been touched since it was merged in 2.6.16
> 
> Can you provide the complete boot log up to this point please ? -
> Preferably over serial console.

Can't manage a serial console, you'll have to settle for the dmesg output
once we get up and running:

[    0.000000] Linux version 2.6.17-mm2-test (valdis@turing-police.cc.vt.edu) (gcc version 4.1.1 20060619 (Red Hat 4.1.1-5)) #1 PREEMPT Mon Jun 26 20:20:32 EDT 2006
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000002ffe2800 (usable)
[    0.000000]  BIOS-e820: 000000002ffe2800 - 0000000030000000 (reserved)
[    0.000000]  BIOS-e820: 00000000feda0000 - 00000000fee00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
[    0.000000] 767MB LOWMEM available.
[    0.000000] On node 0 totalpages: 196578
[    0.000000]   DMA zone: 4096 pages, LIFO batch:0
[    0.000000]   Normal zone: 192482 pages, LIFO batch:31
[    0.000000] DMI 2.3 present.
[    0.000000] ACPI: RSDP (v000 DELL                                  ) @ 0x000fde50
[    0.000000] ACPI: RSDT (v001 DELL    CPi R   0x27d40107 ASL  0x00000061) @ 0x000fde64
[    0.000000] ACPI: FADT (v001 DELL    CPi R   0x27d40107 ASL  0x00000061) @ 0x000fde90
[    0.000000] ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] Allocating PCI resources starting at 40000000 (gap: 30000000:ceda0000)
[    0.000000] Detected 1595.395 MHz processor.
[   17.076049] Built 1 zonelists.  Total pages: 196578
[   17.076053] Kernel command line: console=tty0 vga=794 single
[   17.076524] Local APIC disabled by BIOS -- you can enable it with "lapic"
[   17.076537] mapped APIC to ffffd000 (01603000)
[   17.076543] Enabling fast FPU save and restore... done.
[   17.076547] Enabling unmasked SIMD FPU exception support... done.
[   17.076553] Initializing CPU#0
[   17.076661] CPU 0 irqstacks, hard=c04ec000 soft=c04eb000
[   17.076666] PID hash table entries: 4096 (order: 12, 16384 bytes)
[   17.076790] Console: colour dummy device 80x25
[   17.077842] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[   17.079004] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[   17.106571] Memory: 773400k/786312k available (2308k kernel code, 12312k reserved, 989k data, 192k init, 0k highmem)
[   17.106585] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[   17.166527] Calibrating delay using timer specific routine.. 3192.23 BogoMIPS (lpj=1596116)
[   17.166576] Security Framework v1.0.0 initialized
[   17.166585] SELinux:  Initializing.
[   17.166603] SELinux:  Starting in permissive mode
[   17.166615] selinux_register_security:  Registering secondary module capability
[   17.166623] Capability LSM initialized as secondary
[   17.166642] Mount-cache hash table entries: 512
[   17.166791] CPU: After generic identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000
[   17.166805] CPU: After vendor identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000
[   17.166819] CPU: Trace cache: 12K uops, L1 D cache: 8K
[   17.166825] CPU: L2 cache: 512K
[   17.166830] CPU: After all inits, caps: 3febf9ff 00000000 00000000 00000080 00000000 00000000 00000000
[   17.166840] Intel machine check architecture supported.
[   17.166850] Intel machine check reporting enabled on CPU#0.
[   17.166857] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
[   17.166865] CPU0: Thermal monitoring enabled
[   17.166885] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04
[   17.166899] Checking 'hlt' instruction... OK.
[   17.170623] SMP alternatives: switching to UP code
[   17.170630] Freeing SMP alternatives: 0k freed
[   17.170636] ACPI: Core revision 20060608
[   17.213523] ACPI: setting ELCR to 0200 (from 0800)
[   17.219183] checking if image is initramfs... it is
[   17.365993] Freeing initrd memory: 1031k freed
[   17.366492] NET: Registered protocol family 16
[   17.367056] ACPI: ACPI Dock Station Driver 
[   17.367520] ACPI: bus type pci registered
[   17.381009] PCI: PCI BIOS revision 2.10 entry at 0xfbfee, last bus=2
[   17.381016] Setting up standard PCI resources
[   17.411263] ACPI: Interpreter enabled
[   17.411276] ACPI: Using PIC for interrupt routing
[   17.415489] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   17.415503] PCI: Probing PCI hardware (bus 00)
[   17.415912] ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
[   17.490877] PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
[   17.490889] PCI quirk: region 0880-08bf claimed by ICH4 GPIO
[   17.490990] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
[   17.491566] Boot video device is 0000:01:00.0
[   17.492357] PCI: Transparent bridge - 0000:00:1e.0
[   17.493327] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   17.643870] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
[   17.645210] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11
[   17.646534] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
[   17.647875] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
[   17.651329] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[   17.652545] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
[   17.655595] ACPI: Power Resource [PADA] (on)
[   17.657068] Linux Plug and Play Support v0.97 (c) Adam Belay
[   17.657090] pnp: PnP ACPI init
[   17.883045] pnp: PnP ACPI: found 17 devices
[   17.883086] Intel 82802 RNG detected
[   17.883685] usbcore: registered new driver usbfs
[   17.883950] usbcore: registered new driver hub
[   17.884558] PCI: Using ACPI for IRQ routing
[   17.884568] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   17.927252] pnp: 00:02: ioport range 0x4d0-0x4d1 has been reserved
[   17.927264] pnp: 00:02: ioport range 0x800-0x805 could not be reserved
[   17.927273] pnp: 00:02: ioport range 0x808-0x80f could not be reserved
[   17.927286] pnp: 00:03: ioport range 0x806-0x807 has been reserved
[   17.927295] pnp: 00:03: ioport range 0x810-0x85f could not be reserved
[   17.927303] pnp: 00:03: ioport range 0x860-0x87f has been reserved
[   17.927311] pnp: 00:03: ioport range 0x880-0x8bf has been reserved
[   17.927319] pnp: 00:03: ioport range 0x8c0-0x8df has been reserved
[   17.927326] pnp: 00:03: ioport range 0x8e0-0x8ff has been reserved
[   17.927341] pnp: 00:04: ioport range 0xf000-0xf0fe has been reserved
[   17.927349] pnp: 00:04: ioport range 0xf100-0xf1fe has been reserved
[   17.927370] pnp: 00:04: ioport range 0xf200-0xf2fe has been reserved
[   17.927379] pnp: 00:04: ioport range 0xf400-0xf4fe has been reserved
[   17.927387] pnp: 00:04: ioport range 0xf500-0xf5fe has been reserved
[   17.927396] pnp: 00:04: ioport range 0xf600-0xf6fe has been reserved
[   17.927405] pnp: 00:04: ioport range 0xf800-0xf8fe has been reserved
[   17.927413] pnp: 00:04: ioport range 0xf900-0xf9fe has been reserved
[   17.927431] pnp: 00:09: ioport range 0x900-0x91f has been reserved
[   17.927438] pnp: 00:09: ioport range 0x3f0-0x3f1 has been reserved
[   17.927454] pnp: 00:0f: ioport range 0xbf40-0xbf5f has been reserved
[   17.929718] PCI: Bridge: 0000:00:01.0
[   17.929729]   IO window: c000-cfff
[   17.929740]   MEM window: fc000000-fdffffff
[   17.929750]   PREFETCH window: d8000000-e7ffffff
[   17.929792] PCI: Bus 3, cardbus bridge: 0000:02:01.0
[   17.929799]   IO window: 0000e000-0000e0ff
[   17.929808]   IO window: 0000e400-0000e4ff
[   17.929818]   PREFETCH window: 40000000-41ffffff
[   17.929829]   MEM window: f4000000-f5ffffff
[   17.929838] PCI: Bus 7, cardbus bridge: 0000:02:01.1
[   17.929844]   IO window: 0000e800-0000e8ff
[   17.929853]   IO window: 00001000-000010ff
[   17.929863]   PREFETCH window: 42000000-43ffffff
[   17.929873]   MEM window: f6000000-f7ffffff
[   17.929882] PCI: Bus 11, cardbus bridge: 0000:02:03.0
[   17.929888]   IO window: 00001400-000014ff
[   17.929897]   IO window: 00001800-000018ff
[   17.929907]   PREFETCH window: 44000000-45ffffff
[   17.929917]   MEM window: fa000000-fbffffff
[   17.929926] PCI: Bridge: 0000:00:1e.0
[   17.929934]   IO window: e000-ffff
[   17.929946]   MEM window: f4000000-fbffffff
[   17.929956]   PREFETCH window: 40000000-46ffffff
[   17.929991] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[   17.930019] PCI: Enabling device 0000:02:01.0 (0000 -> 0003)
[   17.930959] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
[   17.930967] PCI: setting IRQ 11 as level-triggered
[   17.930973] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[   17.931011] PCI: Enabling device 0000:02:01.1 (0000 -> 0003)
[   17.931020] ACPI: PCI Interrupt 0000:02:01.1[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[   17.931055] ACPI: PCI Interrupt 0000:02:03.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[   17.931103] NET: Registered protocol family 2
[   17.939416] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[   17.939725] TCP established hash table entries: 131072 (order: 7, 524288 bytes)
[   17.940277] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
[   17.940808] TCP: Hash tables configured (established 131072 bind 65536)
[   17.940816] TCP reno registered
[   17.942193] Machine check exception polling timer started.
[   17.942330] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec.
[   17.954033] audit: initializing netlink socket (disabled)
[   17.954062] audit(1151368037.173:1): initialized
[   17.954290] VFS: Disk quotas dquot_6.5.1
[   17.954321] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[   17.954433] SELinux:  Registering netfilter hooks
[   17.960062] Initializing Cryptographic API
[   17.960073] io scheduler noop registered
[   17.960086] io scheduler anticipatory registered (default)
[   17.960096] io scheduler deadline registered
[   17.960113] io scheduler cfq registered
[   17.961187] vesafb: framebuffer at 0xe0000000, mapped to 0xf0880000, using 5120k, total 32768k
[   17.961199] vesafb: mode is 1280x1024x16, linelength=2560, pages=1
[   17.961206] vesafb: protected mode interface info at c000:e140
[   17.961213] vesafb: pmi: set display start = c00ce185, set palette = c00ce20a
[   17.961218] vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03 
[   17.961246] vesafb: scrolling: redraw
[   17.961253] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[   18.042761] Console: switching to colour frame buffer device 160x64
[   18.118229] fb0: VESA VGA frame buffer device
[   18.119853] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[   18.137796] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
[   18.138627] Hangcheck: Using get_cycles().
[   18.139017] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[   18.140389] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   18.143041] 00:0d: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   18.145096] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
[   18.145622] PCI: setting IRQ 5 as level-triggered
[   18.145628] ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
[   18.150711] RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize
[   18.153515] loop: loaded (max 8 devices)
[   18.155121] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
[   18.155653] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[   18.156511] 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
[   18.157184] 0000:02:00.0: 3Com PCI 3c905C Tornado at f0804c00.
[   18.180566] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   18.181173] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[   18.181949] ICH3M: IDE controller at PCI slot 0000:00:1f.1
[   18.182459] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
[   18.183917] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
[   18.184443] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[   18.185291] ICH3M: chipset revision 2
[   18.185626] ICH3M: not 100% native mode: will probe irqs later
[   18.186180]     ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:DMA
[   18.186891] ICH3M: too many IDE interfaces, no room in table
[   18.187409] Probing IDE interface ide0...
[   18.450439] hda: FUJITSU MHV2060AH, ATA DISK drive
[   18.857812] hdb: TOSHIBA CD-RW/DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive
[   18.913058] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[   18.914653] hda: max request size: 128KiB
[   18.945264] hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)
[   18.950740] hda: cache flushes supported
[   18.951152]  hda: hda1 hda2
[   18.961383] hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
[   18.962142] Uniform CD-ROM driver Revision: 3.20
[   18.995085] ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
[   18.995333] USB Universal Host Controller Interface driver v3.0
[   19.023273] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[   19.051304] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[   19.051312] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   19.079265] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
[   19.106918] uhci_hcd 0000:00:1d.0: irq 11, io base 0x0000bf80
[   19.134365] usb usb1: new device found, idVendor=0000, idProduct=0000
[   19.161938] usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
[   19.189672] usb usb1: Product: UHCI Host Controller
[   19.217323] usb usb1: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd
[   19.244946] usb usb1: SerialNumber: 0000:00:1d.0
[   19.273170] usb usb1: configuration #1 chosen from 1 choice
[   19.301075] hub 1-0:1.0: USB hub found
[   19.329130] hub 1-0:1.0: 2 ports detected
[   19.457331] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[   19.485837] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[   19.485845] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   19.514259] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 2
[   19.542782] uhci_hcd 0000:00:1d.2: irq 11, io base 0x0000bf20
[   19.570654] usb usb2: new device found, idVendor=0000, idProduct=0000
[   19.598622] usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
[   19.626613] usb usb2: Product: UHCI Host Controller
[   19.654475] usb usb2: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd
[   19.682341] usb usb2: SerialNumber: 0000:00:1d.2
[   19.710556] usb usb2: configuration #1 chosen from 1 choice
[   19.738543] hub 2-0:1.0: USB hub found
[   19.766078] hub 2-0:1.0: 2 ports detected
[   20.099723] usb 2-1: new low speed USB device using uhci_hcd and address 2
[   20.295519] usb 2-1: new device found, idVendor=045e, idProduct=0023
[   20.322578] usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0
[   20.349770] usb 2-1: Product: Microsoft Trackball Optical®
[   20.376744] usb 2-1: Manufacturer: Microsoft
[   20.404665] usb 2-1: configuration #1 chosen from 1 choice
[   20.448492] input: Microsoft Microsoft Trackball Optical® as /class/input/input0
[   20.475250] input: USB HID v1.00 Mouse [Microsoft Microsoft Trackball Optical®] on usb-0000:00:1d.2-1
[   20.502548] usbcore: registered new driver usbhid
[   20.529495] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[   20.557090] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[   20.588872] serio: i8042 AUX port at 0x60,0x64 irq 12
[   20.616419] serio: i8042 KBD port at 0x60,0x64 irq 1
[   20.643830] mice: PS/2 mouse device common for all mice
[   20.671744] input: PC Speaker as /class/input/input1
[   20.703182] input: AT Translated Set 2 keyboard as /class/input/input2
[   20.729296] i2c /dev entries driver
[   20.756733] device-mapper: ioctl: 4.8.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
[   20.783167] EDAC MC: Ver: 2.0.0 Jun 26 2006
[   20.809776] Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
[   20.838718] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
[   20.866066] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[   21.394886] input: DualPoint Stick as /class/input/input3
[   21.440329] input: AlpsPS/2 ALPS DualPoint TouchPad as /class/input/input4
[   21.477604] intel8x0_measure_ac97_clock: measured 50992 usecs
[   21.504570] intel8x0: measured clock 96446 rejected
[   21.531559] intel8x0: clocking to 48000
[   21.561232] ALSA device list:
[   21.587477]   #0: Intel 82801CA-ICH3 with CS4205 at 0xd800, irq 5
[   21.614454] TCP bic registered
[   21.640610] Initializing IPsec netlink socket
[   21.666716] NET: Registered protocol family 1
[   21.692833] NET: Registered protocol family 10
[   21.718628] lo: Disabled Privacy Extensions
[   21.744152] IPv6 over IPv4 tunneling driver
[   21.769925] NET: Registered protocol family 17
[   21.794964] NET: Registered protocol family 15
[   21.819751] Using IPI Shortcut mode
[   21.844980] Freeing unused kernel memory: 192k freed
[   21.869356] Time: tsc clocksource has been installed.
[   21.893677] Write protecting the kernel read-only data: 406k
[   23.024849] kjournald starting.  Commit interval 5 seconds
[   23.047661] EXT3-fs: mounted filesystem with ordered data mode.
[   23.744042] security:  6 users, 5 roles, 1965 types, 81 bools, 1 sens, 256 cats
[   23.766353] security:  58 classes, 123884 rules
[   23.790135] SELinux:  Completing initialization.
[   23.811527] SELinux:  Setting up existing superblocks.
[   23.887619] SELinux: initialized (dev dm-0, type ext3), uses xattr
[   24.028866] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[   24.050014] SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
[   24.071108] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
[   24.092316] SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
[   24.113511] SELinux: initialized (dev devpts, type devpts), uses transition SIDs
[   24.134412] SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
[   24.155337] SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
[   24.176033] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[   24.196440] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
[   24.216556] SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
[   24.236170] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
[   24.255380] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
[   24.274225] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[   24.292902] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
[   24.311432] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
[   24.330082] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
[   24.351494] audit(1151368041.674:2): policy loaded auid=4294967295
[   24.370664] audit(1151368041.666:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security
[   47.325645] SysRq : Show Regs
[   47.346690] 
[   47.367719] Pid: 4, comm:              khelper
[   47.390642] EIP: 0060:[<c0119ee8>] CPU: 0
[   47.412044] EIP is at getnstimeofday+0x9e/0xb8
[   47.433443]  EFLAGS: 00000283    Not tainted  (2.6.17-mm2-test #1)
[   47.455170] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   47.477049] ESI: 49972cca EDI: aebbd096 EBP: effd0e5c DS: 007b ES: 007b
[   47.499328] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   47.521783]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   47.544819]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   47.567843]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   47.591251]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   47.614703]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   50.090792] SysRq : Show Regs
[   50.114039] 
[   50.137151] Pid: 4, comm:              khelper
[   50.162186] EIP: 0060:[<c0119ee8>] CPU: 0
[   50.185615] EIP is at getnstimeofday+0x9e/0xb8
[   50.209150]  EFLAGS: 00000283    Not tainted  (2.6.17-mm2-test #1)
[   50.233053] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   50.257138] ESI: 5e71e8ca EDI: a36f8e9d EBP: effd0e5c DS: 007b ES: 007b
[   50.281259] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   50.305453]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   50.330131]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   50.354773]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   50.379825]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   50.405258]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   55.545338] SysRq : Show Regs
[   55.569994] 
[   55.594154] Pid: 1, comm:                 init
[   55.618624] EIP: 0060:[<c0119f93>] CPU: 0
[   55.643037] EIP is at do_gettimeofday+0x91/0xc5
[   55.667460]  EFLAGS: 00000286    Not tainted  (2.6.17-mm2-test #1)
[   55.692237] EAX: e22faad7 EBX: 8ef8e1d2 ECX: db50bbaa EDX: 62dc8f7e
[   55.717439] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b
[   55.743054] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   55.768593]  <c0116992> sys_time+0xe/0x2f  <c0102261> sysenter_past_esp+0x56/0x79
[   58.448886] SysRq : Show Regs
[   58.474391] 
[   58.499617] Pid: 4, comm:              khelper
[   58.526676] EIP: 0060:[<c0119ee8>] CPU: 0
[   58.551892] EIP is at getnstimeofday+0x9e/0xb8
[   58.577215]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2-test #1)
[   58.602764] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   58.628351] ESI: 5216c0ca EDI: 7fd02419 EBP: effd0e5c DS: 007b ES: 007b
[   58.654222] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   58.680144]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   58.706517]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   58.732893]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   58.759698]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   58.786851]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   64.039899] SysRq : Show Regs
[   64.066806] 
[   64.093395] Pid: 4, comm:              khelper
[   64.122191] EIP: 0060:[<c0119ee8>] CPU: 0
[   64.149014] EIP is at getnstimeofday+0x9e/0xb8
[   64.175793]  EFLAGS: 00000283    Not tainted  (2.6.17-mm2-test #1)
[   64.202650] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   64.229018] ESI: f0575aca EDI: 67ff297e EBP: effd0e5c DS: 007b ES: 007b
[   64.254673] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   64.280580]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   64.307101]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   64.333709]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   64.360724]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   64.388065]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   67.461531] SysRq : Show Regs
[   67.488572] 
[   67.515345] Pid: 4, comm:              khelper
[   67.543903] EIP: 0060:[<c0119ee8>] CPU: 0
[   67.570469] EIP is at getnstimeofday+0x9e/0xb8
[   67.596952]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2-test #1)
[   67.623641] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   67.650193] ESI: e3ae9cca EDI: 59fc3768 EBP: effd0e5c DS: 007b ES: 007b
[   67.676652] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   67.702990]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   67.729631]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   67.756234]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   67.783266]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   67.810608]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   71.047876] SysRq : Show Regs
[   71.074931] 
[   71.101725] Pid: 4, comm:              khelper
[   71.130292] EIP: 0060:[<c0119ee8>] CPU: 0
[   71.156873] EIP is at getnstimeofday+0x9e/0xb8
[   71.183369]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2-test #1)
[   71.210065] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   71.236614] ESI: ee5cdaca EDI: 4b118ebe EBP: effd0e5c DS: 007b ES: 007b
[   71.263068] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   71.289404]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   71.316037]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   71.342641]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   71.369699]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   71.397075]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   73.446308] SysRq : Show Regs
[   73.473414] 
[   73.500205] Pid: 1, comm:                 init
[   73.526997] EIP: 0060:[<c0119f93>] CPU: 0
[   73.553564] EIP is at do_gettimeofday+0x91/0xc5
[   73.580059]  EFLAGS: 00000286    Not tainted  (2.6.17-mm2-test #1)
[   73.606786] EAX: 274c0afb EBX: 8ef8e1d2 ECX: cb3967e7 EDX: dd58277e
[   73.633399] ESI: ffffffff EDI: 00000000 EBP: c16d7fa4 DS: 007b ES: 007b
[   73.659894] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   73.686698]  <c0116992> sys_time+0xe/0x2f  <c0102261> sysenter_past_esp+0x56/0x79
[   76.464785] SysRq : Show Regs
[   76.491801] 
[   76.518628] Pid: 4, comm:              khelper
[   76.547291] EIP: 0060:[<c0119ee8>] CPU: 0
[   76.573824] EIP is at getnstimeofday+0x9e/0xb8
[   76.600283]  EFLAGS: 00000287    Not tainted  (2.6.17-mm2-test #1)
[   76.626966] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   76.653500] ESI: 447068ca EDI: 3531262b EBP: effd0e5c DS: 007b ES: 007b
[   76.679940] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   76.706240]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   76.732842]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   76.759412]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   76.786408]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   76.813729]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   79.214850] SysRq : Show Regs
[   79.241901] 
[   79.268685] Pid: 4, comm:              khelper
[   79.297242] EIP: 0060:[<c0119ee8>] CPU: 0
[   79.323800] EIP is at getnstimeofday+0x9e/0xb8
[   79.350280]  EFLAGS: 00000283    Not tainted  (2.6.17-mm2-test #1)
[   79.376960] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   79.403485] ESI: 585bd6ca EDI: 2a54f33c EBP: effd0e5c DS: 007b ES: 007b
[   79.429916] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   79.456234]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   79.482858]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   79.509452]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   79.536486]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   79.563846]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   81.520148] SysRq : Show Regs
[   81.547171] 
[   81.573927] Pid: 4, comm:              khelper
[   81.602450] EIP: 0060:[<c0119ee8>] CPU: 0
[   81.628985] EIP is at getnstimeofday+0x9e/0xb8
[   81.655440]  EFLAGS: 00000203    Not tainted  (2.6.17-mm2-test #1)
[   81.682098] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   81.708598] ESI: 8bd8a4ca EDI: 215de670 EBP: effd0e5c DS: 007b ES: 007b
[   81.734997] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   81.761260]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   81.787828]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   81.814364]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   81.841334]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   81.868611]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   85.189743] SysRq : Show Regs
[   85.216706] 
[   85.243406] Pid: 4, comm:              khelper
[   85.271856] EIP: 0060:[<c0119ee8>] CPU: 0
[   85.298313] EIP is at getnstimeofday+0x9e/0xb8
[   85.324694]  EFLAGS: 00000207    Not tainted  (2.6.17-mm2-test #1)
[   85.351280] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   85.377718] ESI: ede792ca EDI: 12898677 EBP: effd0e5c DS: 007b ES: 007b
[   85.404047] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   85.430268]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   85.456795]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   85.483292]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   85.510218]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   85.537472]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   88.115373] SysRq : Show Regs
[   88.142335] 
[   88.169013] Pid: 4, comm:              khelper
[   88.197456] EIP: 0060:[<c0119ee8>] CPU: 0
[   88.223929] EIP is at getnstimeofday+0x9e/0xb8
[   88.250315]  EFLAGS: 00000203    Not tainted  (2.6.17-mm2-test #1)
[   88.276932] EAX: efd562dc EBX: efd562dc ECX: 00000000 EDX: 07e3c408
[   88.303435] ESI: 809e10ca EDI: 06b30ece EBP: effd0e5c DS: 007b ES: 007b
[   88.329807] CR0: 8005003b CR2: 08069000 CR3: 2ffb8000 CR4: 000006d0
[   88.356469]  <c0125bac> ktime_get_ts+0x14/0x3f  <c0110f68> copy_process+0x395/0x1111
[   88.383810]  <c0111f20> do_fork+0x8d/0x16a  <c0100a27> kernel_thread+0x6c/0x74
[   88.411220]  <c01203d1> __call_usermodehelper+0x2b/0x44  <c0120922> run_workqueue+0x94/0xe9
[   88.439162]  <c0120e04> worker_thread+0xe1/0x115  <c0123252> kthread+0xb0/0xdc
[   88.467114]  <c01006c5> kernel_thread_helper+0x5/0xb 
[   89.913214] Real Time Clock Driver v1.12ac
[   90.489593] audit(1151368108.794:4): avc:  denied  { dac_override } for  pid=452 comm="dmesg" capability=1 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:dmesg_t:s0 tclass=capability

And after that, things move along OK.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-27  2:12     ` Valdis.Kletnieks
@ 2006-06-27  5:54       ` Thomas Gleixner
  0 siblings, 0 replies; 93+ messages in thread
From: Thomas Gleixner @ 2006-06-27  5:54 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel

On Mon, 2006-06-26 at 22:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Jun 2006 01:27:09 +0200, Thomas Gleixner said:
> > On Mon, 2006-06-26 at 17:41 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Sat, 24 Jun 2006 06:19:14 PDT, Andrew Morton said:
> > > > 
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.
> 17-mm2/
> > > 
> > > I'm seeing a 2-minute or so hang at system startup, seems to be hrtimer
> > > related.  
> > 
> > hrtimer is not really involved here.
> 
> OK, the fact that it was continually in kernel/hrtimer.c was a red herring? :)

Yup.

> [   24.292902] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
> [   24.311432] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
> [   24.330082] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
> [   24.351494] audit(1151368041.674:2): policy loaded auid=4294967295
> [   24.370664] audit(1151368041.666:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security

<snip>

> [   88.467114]  <c01006c5> kernel_thread_helper+0x5/0xb 
> [   89.913214] Real Time Clock Driver v1.12ac
> [   90.489593] audit(1151368108.794:4): avc:  denied  { dac_override } for  pid=452 comm="dmesg" capability=1 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:system_r:dmesg_t:s0 tclass=capability
> 
> And after that, things move along OK.

Hmm, does not help much. Wild guess: Can you turn off CONFIG_RTC and try
again ?

	tglx



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
                     ` (2 preceding siblings ...)
  2006-06-26 23:27   ` Thomas Gleixner
@ 2006-06-27 10:16   ` Roman Zippel
  2006-06-27 16:43     ` Valdis.Kletnieks
  3 siblings, 1 reply; 93+ messages in thread
From: Roman Zippel @ 2006-06-27 10:16 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel

Hi,

On Mon, 26 Jun 2006, Valdis.Kletnieks@vt.edu wrote:

> Which looks like a good place to get hung in a loop for a while....
> 
> Eventually (after about 2 minutes, it finally unwedges and continues on.
> 
> Any ideas?

Could you please try the patch below?
tv_nsec can shortly become negative, but its absolute value will always be 
smaller then the current nsec offset.

bye, Roman

---
 kernel/timer.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-06-27 11:59:19.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-06-27 12:10:28.000000000 +0200
@@ -1129,7 +1129,7 @@ static void update_wall_time(void)
 	clocksource_adjust(clock, offset);
 
 	/* store full nanoseconds into xtime */
-	xtime.tv_nsec = clock->xtime_nsec >> clock->shift;
+	xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift;
 	clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift;
 
 	/* check to see if there is a new clocksource to use */

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-27 10:16   ` Roman Zippel
@ 2006-06-27 16:43     ` Valdis.Kletnieks
  2006-06-27 17:10       ` Roman Zippel
  0 siblings, 1 reply; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-27 16:43 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Andrew Morton, linux-kernel

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

On Tue, 27 Jun 2006 12:16:15 +0200, Roman Zippel said:

> Could you please try the patch below?
> tv_nsec can shortly become negative, but its absolute value will always be 
> smaller then the current nsec offset.

> Index: linux-2.6-mm/kernel/timer.c
> ===================================================================
> --- linux-2.6-mm.orig/kernel/timer.c	2006-06-27 11:59:19.000000000 +0200
> +++ linux-2.6-mm/kernel/timer.c	2006-06-27 12:10:28.000000000 +0200
> @@ -1129,7 +1129,7 @@ static void update_wall_time(void)
>  	clocksource_adjust(clock, offset);
>  
>  	/* store full nanoseconds into xtime */
> -	xtime.tv_nsec = clock->xtime_nsec >> clock->shift;
> +	xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift;
>  	clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift;
>  
>  	/* check to see if there is a new clocksource to use */

Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't
fix the problem I'm seeing.  I've been doing the mm-bisect polka for a bit,
and have it narrowed down to this set of patches:

time-clocksource-infrastructure.patch
time-clocksource-infrastructure-dont-enable-irq-too-early.patch
time-use-clocksource-infrastructure-for-update_wall_time.patch
time-use-clocksource-infrastructure-for-update_wall_time-mark-few-functions-as-__init.patch
time-let-user-request-precision-from-current_tick_length.patch
time-use-clocksource-abstraction-for-ntp-adjustments.patch
time-use-clocksource-abstraction-for-ntp-adjustments-optimize-out-some-mults-since-gcc-cant-avoid-them.patch
time-introduce-arch-generic-time-accessors.patch
hangcheck-remove-monotomic_clock-on-x86.patch
time-i386-conversion-part-1-move-timer_pitc-to-i8253c.patch
time-i386-conversion-part-2-rework-tsc-support.patch
time-i386-conversion-part-3-enable-generic-timekeeping.patch
time-i386-conversion-part-4-remove-old-timer_opts-code.patch
time-i386-clocksource-drivers.patch
time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy.patch
time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup.patch
time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup-fix-missing-to-rename-pmtmr_good-to-acpi_pm_good.patch
time-i386-clocksource-drivers-fix-spelling-typos.patch
time-rename-clocksource-functions.patch
make-pmtmr_ioport-__read_mostly.patch
generic-time-add-macro-to-simplify-hide-mask.patch
time-fix-time-going-backward-w-clock=pit.patch
fix-and-optimize-clock-source-update.patch

Does anybody know offhand if it's safe to bisect through here, or if
there's a gotcha along the way?



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-27 16:43     ` Valdis.Kletnieks
@ 2006-06-27 17:10       ` Roman Zippel
  2006-06-27 17:23         ` Roman Zippel
  0 siblings, 1 reply; 93+ messages in thread
From: Roman Zippel @ 2006-06-27 17:10 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel

Hi,

On Tue, 27 Jun 2006, Valdis.Kletnieks@vt.edu wrote:

> On Tue, 27 Jun 2006 12:16:15 +0200, Roman Zippel said:
> 
> > Could you please try the patch below?
> > tv_nsec can shortly become negative, but its absolute value will always be 
> > smaller then the current nsec offset.
> 
> > Index: linux-2.6-mm/kernel/timer.c
> > ===================================================================
> > --- linux-2.6-mm.orig/kernel/timer.c	2006-06-27 11:59:19.000000000 +0200
> > +++ linux-2.6-mm/kernel/timer.c	2006-06-27 12:10:28.000000000 +0200
> > @@ -1129,7 +1129,7 @@ static void update_wall_time(void)
> >  	clocksource_adjust(clock, offset);
> >  
> >  	/* store full nanoseconds into xtime */
> > -	xtime.tv_nsec = clock->xtime_nsec >> clock->shift;
> > +	xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift;
> >  	clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift;
> >  
> >  	/* check to see if there is a new clocksource to use */
> 
> Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't
> fix the problem I'm seeing.  I've been doing the mm-bisect polka for a bit,
> and have it narrowed down to this set of patches:

I'm afraid the problem is somehow related, in the longer boot log one can 
see the edi counting down, so I think it's likely in timespec_add_ns().
What's weird is that you can trigger it this easily...

bye, Roman

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-27 17:10       ` Roman Zippel
@ 2006-06-27 17:23         ` Roman Zippel
  2006-06-27 19:07           ` Valdis.Kletnieks
  0 siblings, 1 reply; 93+ messages in thread
From: Roman Zippel @ 2006-06-27 17:23 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel

Hi,

On Tue, 27 Jun 2006, Roman Zippel wrote:

> On Tue, 27 Jun 2006, Valdis.Kletnieks@vt.edu wrote:
> 
> > Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't
> > fix the problem I'm seeing.  I've been doing the mm-bisect polka for a bit,
> > and have it narrowed down to this set of patches:
> 
> I'm afraid the problem is somehow related, in the longer boot log one can 
> see the edi counting down, so I think it's likely in timespec_add_ns().
> What's weird is that you can trigger it this easily...

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

bye, Roman

---
 kernel/timer.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-06-27 19:16:13.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-06-27 19:17:41.000000000 +0200
@@ -834,6 +834,8 @@ static inline void __get_realtime_clock_
 
 	} while (read_seqretry(&xtime_lock, seq));
 
+	if (ts->tv_nsec < 0 || nsecs < 0)
+		printk("unexpected nsec: %ld,%Ld\n", ts->tv_nsec, nsecs);
 	timespec_add_ns(ts, nsecs);
 }
 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-27 17:23         ` Roman Zippel
@ 2006-06-27 19:07           ` Valdis.Kletnieks
  2006-06-28  0:07             ` john stultz
  0 siblings, 1 reply; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-27 19:07 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Andrew Morton, linux-kernel

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

On Tue, 27 Jun 2006 19:23:53 +0200, Roman Zippel said:

I finished bisecting - the problem code is somewhere in
fix-and-optimize-clock-source-update.patch (which should narrow things
down a bunch).

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


> +	if (ts->tv_nsec < 0 || nsecs < 0)
> +		printk("unexpected nsec: %ld,%Ld\n", ts->tv_nsec, nsecs);
>  	timespec_add_ns(ts, nsecs);

I changed it slightly to also do a dump_stack() in case that mattered. I get:

[   22.562394] Time: tsc clocksource has been installed.

(Does the clocksource matter here?)

[   25.241589] audit(1151434000.4294965869:2): policy loaded auid=4294967295
[   25.260931] audit(1151434020.4294967250:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security
[   25.326263] unexpected nsec: -925155963,1574943831
[   25.346995]  <c01031ff> show_trace_log_lvl+0x54/0x174  <c01037bd> show_trace+0xd/0x10
[   25.368300]  <c010385a> dump_stack+0x19/0x1b  <c011a4f6> getnstimeofday+0x99/0xd0
[   25.389785]  <c0125428> ktime_get_ts+0x14/0x3f  <c0110ba2> copy_process+0x39f/0x10d8
[   25.411587]  <c0111b17> do_fork+0x8d/0x16a  <c0100a24> kernel_thread+0x6c/0x74
[   25.433731]  <c011fc35> __call_usermodehelper+0x2b/0x44  <c0120186> run_workqueue+0x94/0xe9
[   25.456400]  <c0120668> worker_thread+0xe1/0x115  <c0122ace> kthread+0xb0/0xdc
[   25.479234]  <c01006c5> kernel_thread_helper+0x5/0xb
[   25.551830] unexpected nsec: -347554993,1412474976
[   25.574337]  <c01031ff> show_trace_log_lvl+0x54/0x174  <c01037bd> show_trace+0xd/0x10
[   25.597459]  <c010385a> dump_stack+0x19/0x1b  <c011a4f6> getnstimeofday+0x99/0xd0
[   25.620925]  <c0125428> ktime_get_ts+0x14/0x3f  <c0110ba2> copy_process+0x39f/0x10d8
[   25.644923]  <c0111b17> do_fork+0x8d/0x16a  <c0100998> sys_clone+0x25/0x2a
[   25.669118]  <c010224d> sysenter_past_esp+0x56/0x79
[   25.693213] unexpected nsec: -1276931327,751175871
[   25.717404]  <c01031ff> show_trace_log_lvl+0x54/0x174  <c01037bd> show_trace+0xd/0x10
[   25.742269]  <c010385a> dump_stack+0x19/0x1b  <c011a4f6> getnstimeofday+0x99/0xd0
[   25.767382]  <c0125428> ktime_get_ts+0x14/0x3f  <c0110ba2> copy_process+0x39f/0x10d8
[   25.792768]  <c0111b17> do_fork+0x8d/0x16a  <c0100998> sys_clone+0x25/0x2a
[   25.818386]  <c010224d> sysenter_past_esp+0x56/0x79
[   74.653939] Real Time Clock Driver v1.12ac

(Later on, during udev processing, we get:

[   92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2])
[   92.087122] ACPI: Processor [CPU0] (supports 8 throttling states)
[   92.120270] ACPI: Thermal Zone [THM] (70 C)
[   72.242000] Time: acpi_pm clocksource has been installed.

and the timestamps steps back about 20 seconds.... 

That help any?


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-27 19:07           ` Valdis.Kletnieks
@ 2006-06-28  0:07             ` john stultz
  2006-06-28 10:35               ` Roman Zippel
  0 siblings, 1 reply; 93+ messages in thread
From: john stultz @ 2006-06-28  0:07 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel

On Tue, 2006-06-27 at 15:07 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 27 Jun 2006 19:23:53 +0200, Roman Zippel said:
> 
> I finished bisecting - the problem code is somewhere in
> fix-and-optimize-clock-source-update.patch (which should narrow things
> down a bunch).

Thanks so much for narrowing this down!


> > Could you please try the patch below? This should better locate which of 
> > the values goes wrong.
> 
> 
> > +	if (ts->tv_nsec < 0 || nsecs < 0)
> > +		printk("unexpected nsec: %ld,%Ld\n", ts->tv_nsec, nsecs);
> >  	timespec_add_ns(ts, nsecs);
> 
> I changed it slightly to also do a dump_stack() in case that mattered. I get:
> 
> [   22.562394] Time: tsc clocksource has been installed.
> 
> (Does the clocksource matter here?)

It might be related. Quick test to check: boot w/ "clocksource=acpi_pm"
and let me know if the problem still appears. Then try booting w/
"clocksource=tsc" and see if the system still corrects itself.


> [   25.241589] audit(1151434000.4294965869:2): policy loaded auid=4294967295
> [   25.260931] audit(1151434020.4294967250:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security
> [   25.326263] unexpected nsec: -925155963,1574943831

Hmm. Yea, the negative xtime nsec value is problematic. However the 1.5
seconds worth of nanoseconds that has accumulated is worrisome as well.


> [   92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2])
> [   92.087122] ACPI: Processor [CPU0] (supports 8 throttling states)
> [   92.120270] ACPI: Thermal Zone [THM] (70 C)
> [   72.242000] Time: acpi_pm clocksource has been installed.
> 
> and the timestamps steps back about 20 seconds.... 

Yea, that bit is expected. Basically the cpufreq driver is loading, and
when we detect cpufreq changes we mark the TSC as unstable and we fall
back to an alternative clocksource (acpi_pm in your case). At the same
time, sched_clock sees that the TSC is unstable and it falls back to
using jiffies, which causes the small jump in the printk timestamps.

Thanks again for the testing and feedback!
-john


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-28  0:07             ` john stultz
@ 2006-06-28 10:35               ` Roman Zippel
  2006-06-28 11:44                 ` Roman Zippel
  2006-06-28 23:41                 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz
  0 siblings, 2 replies; 93+ messages in thread
From: Roman Zippel @ 2006-06-28 10:35 UTC (permalink / raw)
  To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

Hi,

On Tue, 27 Jun 2006, john stultz wrote:

> > [   92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2])
> > [   92.087122] ACPI: Processor [CPU0] (supports 8 throttling states)
> > [   92.120270] ACPI: Thermal Zone [THM] (70 C)
> > [   72.242000] Time: acpi_pm clocksource has been installed.
> > 
> > and the timestamps steps back about 20 seconds.... 
> 
> Yea, that bit is expected. Basically the cpufreq driver is loading, and
> when we detect cpufreq changes we mark the TSC as unstable and we fall
> back to an alternative clocksource (acpi_pm in your case). At the same
> time, sched_clock sees that the TSC is unstable and it falls back to
> using jiffies, which causes the small jump in the printk timestamps.

Frequency changes are IMO currently the most likely reason for this 
behaviour. If the cpu speeds down too much, the adjustment code might 
actually attempt to go backwards in time, the old adjustment code might 
have survived that, because it reacts slower to changes.
The patch below should prevent this.

Looking through the log file, I noticed other things:

[   17.942330] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec.
...
[   21.869356] Time: tsc clocksource has been installed.

The speedstep code uses do_gettimeofday() but there is no real clock 
source installed, so it gets confused.
IMO it would be better to install the PIT timer very early and later avoid 
switching to tsc at all, if there is any possibility of speed changes.

bye, Roman



---
 include/linux/clocksource.h |    4 +++-
 kernel/timer.c              |    6 ++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

Index: linux-2.6-mm/include/linux/clocksource.h
===================================================================
--- linux-2.6-mm.orig/include/linux/clocksource.h	2006-06-28 11:53:01.000000000 +0200
+++ linux-2.6-mm/include/linux/clocksource.h	2006-06-28 12:14:30.000000000 +0200
@@ -55,7 +55,7 @@ struct clocksource {
 	int rating;
 	cycle_t (*read)(void);
 	cycle_t mask;
-	u32 mult;
+	u32 mult, mult_min;
 	u32 shift;
 	int (*update_callback)(void);
 	int is_continuous;
@@ -169,6 +169,8 @@ static inline void clocksource_calculate
 	tmp += c->mult/2;
 	do_div(tmp, c->mult);
 
+	c->mult_min = max(c->mult >> 2, 1u);
+
 	c->cycle_interval = (cycle_t)tmp;
 	if (c->cycle_interval == 0)
 		c->cycle_interval = 1;
Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-06-28 11:55:12.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-06-28 12:13:50.000000000 +0200
@@ -1053,6 +1053,12 @@ static __always_inline int clocksource_b
 	if (sign > 0 ? error > *interval : error < *interval)
 		adj++;
 
+	if (sign < 0 && unlikely(clock->mult < clock->mult_min + (1 << adj))) {
+		if (clock->mult <= clock->mult_min)
+			return 0;
+		adj = fls(clock->mult - clock->mult_min) - 1;
+	}
+
 	*interval <<= adj;
 	*offset <<= adj;
 	return sign << adj;

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-28 10:35               ` Roman Zippel
@ 2006-06-28 11:44                 ` Roman Zippel
  2006-06-29 23:07                   ` Valdis.Kletnieks
  2006-06-28 23:41                 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz
  1 sibling, 1 reply; 93+ messages in thread
From: Roman Zippel @ 2006-06-28 11:44 UTC (permalink / raw)
  To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

Hi,

On Wed, 28 Jun 2006, Roman Zippel wrote:

> Frequency changes are IMO currently the most likely reason for this 
> behaviour. If the cpu speeds down too much, the adjustment code might 
> actually attempt to go backwards in time, the old adjustment code might 
> have survived that, because it reacts slower to changes.
> The patch below should prevent this.

Hmm, I've run some simulations and I found that it actually needed some 
extreme frequency differences to trigger a negative multiplier, but even 
then it recovered very quickly from it.
Valdis, could you please add a call to the function below in 
__get_realtime_clock_ts() when the problem triggers to print the complete 
internal clock state.
Thanks.

bye, Roman

---
 kernel/timer.c |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-06-28 13:30:30.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-06-28 13:34:43.000000000 +0200
@@ -789,6 +789,13 @@ u64 current_tick_length(void)
 #include <linux/clocksource.h>
 static struct clocksource *clock; /* pointer to current clocksource */
 
+void printk_clock_info(void)
+{
+	printk("clock %s: m:%u,s:%u,cl:%Lu,ci:%Lu,xn:%Lu,xi:%Lu,e:%Ld\n",
+		clock->name, clock->mult, clock->shift, clock->cycle_last, clock->cycle_interval,
+		clock->xtime_nsec, clock->xtime_interval, clock->error);
+}
+
 #ifdef CONFIG_GENERIC_TIME
 /**
  * __get_nsec_offset - Returns nanoseconds since last call to periodic_hook

^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h>
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (11 preceding siblings ...)
  2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
@ 2006-06-28 16:54 ` Adrian Bunk
  2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk
  2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk
  14 siblings, 0 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-28 16:54 UTC (permalink / raw)
  To: Andrew Morton, Andreas Mohr; +Cc: linux-kernel, len.brown, linux-acpi

On Sat, Jun 24, 2006 at 06:19:14AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.17-mm1:
>...
> +cpu_relax-use-in-acpi-lock.patch
>...
>  ACPI stuff
>...

This patch fixes the following issue:

<--  snip  -->

...
  CC      arch/i386/mach-visws/mpparse.o
In file included from include/asm/fixmap.h:26,
                 from include/asm/smp.h:15,
                 from arch/i386/mach-visws/mpparse.c:6:
include/asm/acpi.h: In function ‘__acpi_acquire_global_lock’:
include/asm/acpi.h:70: warning: implicit declaration of function ‘cpu_relax’
...

<--  snip  -->

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

--- linux-2.6.17-mm2/include/asm-i386/acpi.h.old	2006-06-26 23:00:40.000000000 +0200
+++ linux-2.6.17-mm2/include/asm-i386/acpi.h	2006-06-26 23:01:04.000000000 +0200
@@ -31,6 +31,7 @@
 #include <acpi/pdc_intel.h>
 
 #include <asm/system.h>		/* defines cmpxchg */
+#include <asm/processor.h>
 
 #define COMPILER_DEPENDENT_INT64   long long
 #define COMPILER_DEPENDENT_UINT64  unsigned long long

^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] fix sgivwfb compile
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (12 preceding siblings ...)
  2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk
@ 2006-06-28 16:54 ` Adrian Bunk
  2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk
  14 siblings, 0 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-28 16:54 UTC (permalink / raw)
  To: Andrew Morton, Jeremy Fitzhardinge
  Cc: linux-kernel, pazke, linux-visws-devel, Chris Wright

This patch fixes the following compile error caused by 
clean-up-and-refactor-i386-sub-architecture-setup.patch:

<--  snip  -->

...
  LD      .tmp_vmlinux1
drivers/built-in.o: In function `sgivwfb_set_par':
sgivwfb.c:(.text+0x88583): undefined reference to `sgivwfb_mem_phys'
sgivwfb.c:(.text+0x88596): undefined reference to `sgivwfb_mem_phys'
sgivwfb.c:(.text+0x885a8): undefined reference to `sgivwfb_mem_phys'
drivers/built-in.o: In function `sgivwfb_check_var':
sgivwfb.c:(.text+0x88ad0): undefined reference to `sgivwfb_mem_size'
drivers/built-in.o: In function `sgivwfb_mmap':
sgivwfb.c:(.text+0x88c75): undefined reference to `sgivwfb_mem_size'
sgivwfb.c:(.text+0x88c7f): undefined reference to `sgivwfb_mem_phys'
drivers/built-in.o: In function `sgivwfb_probe':
sgivwfb.c:(.init.text+0x4060): undefined reference to `sgivwfb_mem_size'
sgivwfb.c:(.init.text+0x4065): undefined reference to `sgivwfb_mem_phys'
sgivwfb.c:(.init.text+0x4076): undefined reference to `sgivwfb_mem_phys'
sgivwfb.c:(.init.text+0x409c): undefined reference to `sgivwfb_mem_size'
sgivwfb.c:(.init.text+0x410e): undefined reference to `sgivwfb_mem_size'
sgivwfb.c:(.init.text+0x4113): undefined reference to `sgivwfb_mem_phys'
sgivwfb.c:(.init.text+0x4162): undefined reference to `sgivwfb_mem_size'
sgivwfb.c:(.init.text+0x4168): undefined reference to `sgivwfb_mem_phys'
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->

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

---

 arch/i386/mach-visws/setup.c             |    4 ++--
 drivers/video/sgivwfb.c                  |    6 ++----
 include/asm-i386/mach-visws/setup_arch.h |    3 +++
 3 files changed, 7 insertions(+), 6 deletions(-)

--- linux-2.6.17-mm2-full/include/asm-i386/mach-visws/setup_arch.h.old	2006-06-27 00:35:55.000000000 +0200
+++ linux-2.6.17-mm2-full/include/asm-i386/mach-visws/setup_arch.h	2006-06-27 00:36:10.000000000 +0200
@@ -1,5 +1,8 @@
 /* Hook to call BIOS initialisation function */
 
+extern unsigned long sgivwfb_mem_phys;
+extern unsigned long sgivwfb_mem_size;
+
 /* no action for visws */
 
 #define ARCH_SETUP
--- linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c.old	2006-06-27 00:28:06.000000000 +0200
+++ linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c	2006-06-27 00:28:20.000000000 +0200
@@ -140,8 +140,8 @@
 
 #define MB (1024 * 1024)
 
-static unsigned long sgivwfb_mem_phys;
-static unsigned long sgivwfb_mem_size;
+unsigned long sgivwfb_mem_phys;
+unsigned long sgivwfb_mem_size;
 
 long long mem_size __initdata = 0;
 
--- linux-2.6.17-mm2-full/drivers/video/sgivwfb.c.old	2006-06-27 00:29:03.000000000 +0200
+++ linux-2.6.17-mm2-full/drivers/video/sgivwfb.c	2006-06-27 00:36:37.000000000 +0200
@@ -23,6 +23,8 @@
 #include <asm/io.h>
 #include <asm/mtrr.h>
 
+#include <setup_arch.h>
+
 #define INCLUDE_TIMING_TABLE_DATA
 #define DBE_REG_BASE par->regs
 #include <video/sgivw.h>
@@ -42,10 +44,6 @@
  *  The default can be overridden if the driver is compiled as a module
  */
 
-/* set by arch/i386/kernel/setup.c */
-extern unsigned long sgivwfb_mem_phys;
-extern unsigned long sgivwfb_mem_size;
-
 static int ypan = 0;
 static int ywrap = 0;
 


^ permalink raw reply	[flat|nested] 93+ messages in thread

* [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls
  2006-06-24 13:19 2.6.17-mm2 Andrew Morton
                   ` (13 preceding siblings ...)
  2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk
@ 2006-06-28 16:54 ` Adrian Bunk
  14 siblings, 0 replies; 93+ messages in thread
From: Adrian Bunk @ 2006-06-28 16:54 UTC (permalink / raw)
  To: Andrew Morton, pazke; +Cc: linux-kernel, linux-visws-devel

Thankfully, these dummy function calls are no longer required to avoid 
warnings - if they weren't eliminated as dead code but accidentially 
executed there would be a guaranteed NULL dereference.

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

--- linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c.old	2006-06-27 00:28:06.000000000 +0200
+++ linux-2.6.17-mm2-full/arch/i386/mach-visws/setup.c	2006-06-27 00:37:50.000000000 +0200
@@ -177,8 +177,4 @@
 	add_memory_region(sgivwfb_mem_phys, sgivwfb_mem_size, E820_RESERVED);
 
 	return "PROM";
-
-	/* Remove gcc warnings */
-	(void) sanitize_e820_map(NULL, NULL);
-	(void) copy_e820_map(NULL, 0);
 }


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-28 10:35               ` Roman Zippel
  2006-06-28 11:44                 ` Roman Zippel
@ 2006-06-28 23:41                 ` john stultz
  2006-06-29 11:24                   ` Roman Zippel
  1 sibling, 1 reply; 93+ messages in thread
From: john stultz @ 2006-06-28 23:41 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

On Wed, 2006-06-28 at 12:35 +0200, Roman Zippel wrote:
> Hi,
> 
> On Tue, 27 Jun 2006, john stultz wrote:
> 
> > > [   92.087113] ACPI: CPU0 (power states: C1[C1] C2[C2])
> > > [   92.087122] ACPI: Processor [CPU0] (supports 8 throttling states)
> > > [   92.120270] ACPI: Thermal Zone [THM] (70 C)
> > > [   72.242000] Time: acpi_pm clocksource has been installed.
> > > 
> > > and the timestamps steps back about 20 seconds.... 
> > 
> > Yea, that bit is expected. Basically the cpufreq driver is loading, and
> > when we detect cpufreq changes we mark the TSC as unstable and we fall
> > back to an alternative clocksource (acpi_pm in your case). At the same
> > time, sched_clock sees that the TSC is unstable and it falls back to
> > using jiffies, which causes the small jump in the printk timestamps.
> 
> Frequency changes are IMO currently the most likely reason for this 
> behaviour. If the cpu speeds down too much, the adjustment code might 
> actually attempt to go backwards in time, the old adjustment code might 
> have survived that, because it reacts slower to changes.
> The patch below should prevent this.

I agree cpufreq changes could be the source. However, things still
aren't making sense, since the accumulation is cycle based to begin
with, so any cpufreq caused drift in time won't be noticed until NTPd
starts adjusting the output from current_tick_len().

Vladis: I don't want to overwhelm you with patches to try, I think
Roman's debug patches should help show where the issue is. But if you've
got the time, try the patch below to quickly see if the cpufreq changes
are indeed causing the problem.

> Looking through the log file, I noticed other things:
> 
> [   17.942330] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec.
> ...
> [   21.869356] Time: tsc clocksource has been installed.
> 
> The speedstep code uses do_gettimeofday() but there is no real clock 
> source installed, so it gets confused.
> IMO it would be better to install the PIT timer very early and later avoid 
> switching to tsc at all, if there is any possibility of speed changes.

Hmm. Yea, while I'm not sure this is the issue at hand, it does look
like I need to get some of the boot ordering worked out here. Using the
PIT early on probably isn't the best solution as the 18us access latency
might not be the best for the transition calibration. Currently jiffies
is the default clocksource until late_initcall time, which was done to
minimize the clocksource churn at boot time.  I'm not quite recalling
the details, but I think the motivation was to avoid confusion when
looking at the dmesg, so we could instead allow clocksources to be
selected as they load, but disable printing anything to dmesg until
after late_initcall.

I'll start working on that.

thanks
-john




This patch tries blocking the cpufreq changes to see if its causing the
accounting issue.

diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c
index 7e0d8da..24af443 100644
--- a/arch/i386/kernel/tsc.c
+++ b/arch/i386/kernel/tsc.c
@@ -356,7 +356,7 @@ static int tsc_update_callback(void)
 	}
 
 	/* only update if tsc_khz has changed: */
-	if (current_tsc_khz != tsc_khz) {
+	if (0 && current_tsc_khz != tsc_khz) {
 		current_tsc_khz = tsc_khz;
 		clocksource_tsc.mult = clocksource_khz2mult(current_tsc_khz,
 							clocksource_tsc.shift);



^ permalink raw reply related	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-28 23:41                 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz
@ 2006-06-29 11:24                   ` Roman Zippel
  0 siblings, 0 replies; 93+ messages in thread
From: Roman Zippel @ 2006-06-29 11:24 UTC (permalink / raw)
  To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

Hi,

On Wed, 28 Jun 2006, john stultz wrote:

> I agree cpufreq changes could be the source. However, things still
> aren't making sense, since the accumulation is cycle based to begin
> with, so any cpufreq caused drift in time won't be noticed until NTPd
> starts adjusting the output from current_tick_len().

Indeed, AFAICT the clock should just run too fast, that leaves pretty much 
only the update function doing something I didn't expect.

> Vladis: I don't want to overwhelm you with patches to try, I think
> Roman's debug patches should help show where the issue is. But if you've
> got the time, try the patch below to quickly see if the cpufreq changes
> are indeed causing the problem.

Another change that might help: Valdis, could you add another call to 
printk_clock_info() at the end of update_wall_time() after 
clocksource_calculate_interval()?

> Hmm. Yea, while I'm not sure this is the issue at hand, it does look
> like I need to get some of the boot ordering worked out here. Using the
> PIT early on probably isn't the best solution as the 18us access latency
> might not be the best for the transition calibration.

Since it shouldn't be used much I don't think it matters and it could 
also be HPET, basically whoever provides the timer interrupt.

bye, Roman

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-28 11:44                 ` Roman Zippel
@ 2006-06-29 23:07                   ` Valdis.Kletnieks
  2006-06-30 19:26                     ` john stultz
  0 siblings, 1 reply; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-29 23:07 UTC (permalink / raw)
  To: Roman Zippel; +Cc: john stultz, Andrew Morton, linux-kernel

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

On Wed, 28 Jun 2006 13:44:12 +0200, Roman Zippel said:

> Valdis, could you please add a call to the function below in 
> __get_realtime_clock_ts() when the problem triggers to print the complete 
> internal clock state.

Sorry for the delay, I got distracted by other stuff I'm paid to do.. ;)

Here's what a test reboot got:

   26.578105] audit(1151617213.106:2): policy loaded auid=4294967295
[   26.597401] audit(1151617213.070:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r
:security_t:s0 tclass=security
[   26.683670] unexpected nsec: -840940811,1655512912
[   26.704096] clock tsc: m:4290198220,s:22,cl:42659140158,ci:1595067,xn:18158513697558798592,xi:18446736466713803524,e:3648592523541009408
[   26.726249] unexpected nsec: -969254771,1077037877
[   26.748379] clock tsc: m:4290198222,s:22,cl:42729323106,ci:1595067,xn:17978369712466660208,xi:18446736466716993658,e:4180283123443907584
[   26.795463] unexpected nsec: -1374919676,1598670381
[   26.819393] clock tsc: m:4290198248,s:22,cl:42842572863,ci:1595067,xn:17672124937802117152,xi:18446736466758465400,e:5038236766383932416
[   27.266329] unexpected nsec: -782710824,2549621102
[   27.291643] clock tsc: m:4290198468,s:22,cl:43597039554,ci:1595067,xn:15690541101761319008,xi:18446736467109380140,e:-7692993275657145344
[   27.346941] unexpected nsec: -325230283,2119385465
[   27.373616] clock tsc: m:4290198437,s:22,cl:43727835048,ci:1595067,xn:15348267530081761464,xi:18446736467059933063,e:-6702146452294080512
[   27.437732] unexpected nsec: -1295951870,2004275512
[   27.465648] clock tsc: m:4290198398,s:22,cl:43876176279,ci:1595067,xn:14951950762871702254,xi:18446736466997725450,e:-5578375800491670528
[   27.535596] unexpected nsec: -689435342,2026093159
[   27.565211] clock tsc: m:4290198355,s:22,cl:44034087912,ci:1595067,xn:14537619597154605516,xi:18446736466929137569,e:-4382097184645369856
[   27.848139] unexpected nsec: -724490858,2057851911
[   27.879434] clock tsc: m:4290198101,s:22,cl:44536534017,ci:1595067,xn:13204554107451287893,xi:18446736466523990551,e:-575679729966697472
[   27.912117] unexpected nsec: -1417871539,554358979
[   27.944886] clock tsc: m:4290198101,s:22,cl:44641808439,ci:1595067,xn:12934338129808808595,xi:18446736466523990551,e:221869107013499904
[   37.257357] unexpected nsec: -138785571,1134135898
[   37.291448] clock tsc: m:3483968852,s:22,cl:59571635559,ci:1595067,xn:12754194144714192038,xi:908396457673218998,e:311350649952236544
[   42.318566] unexpected nsec: -321935843,935054298
[   42.353815] clock tsc: m:3080902004,s:22,cl:67660220316,ci:1595067,xn:90071992551050208,xi:4413529548527152531,e:5223654203068061696
[   47.381773] unexpected nsec: -922994772,489529208
[   47.418133] clock tsc: m:1738504176,s:22,cl:75750400140,ci:1595067,xn:10700552714632370560,xi:249397886484535734,e:1008065933768526848
[  107.031802] Real Time Clock Driver v1.12ac

That tell you anything?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
  2006-06-25 18:23             ` 2.6.17-mm2 Sam Ravnborg
@ 2006-06-30  7:38             ` Randy.Dunlap
  2006-07-02 10:11               ` 2.6.17-mm2 Russell King
  1 sibling, 1 reply; 93+ messages in thread
From: Randy.Dunlap @ 2006-06-30  7:38 UTC (permalink / raw)
  To: Andrew Morton; +Cc: rjw, davej, linux-kernel, sekharan, rusty, sam

On Sun, 25 Jun 2006 08:16:10 -0700 Andrew Morton wrote:

> On Sun, 25 Jun 2006 03:22:43 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> > Anyway.  It's regrettable that the new section-checking code didn't
> > complain about the bug.  It looks like this is because the call to
> > cpufreq_register_driver() happened at modprobe-time, and we don't check for
> > that.  Which is rather bad.
> > 
> > Sam, would it be possible to check for references from modules into
> > statically-linked __init code?  It's always wrong...
> > 
> > Rusty/Randy/whoever looks after modules: it also seems wrong that it's
> > possible to load a module which refers to now-unloaded symbols.  In fact,
> > it's surprising - sorry if I'm misinterpreting this.  If I'm not, it should
> > be pretty easy to barf if a module is trying to get at symbols which lie
> > between __init_begin and __init_end?
> > 
> 
> Actually we should be able to address this pretty simply by disallowing
> exports of symbols which are in the __init section.  There's no sense in
> exporting something which ain't there.
> 
> IOW, any reference from __ksymtab, __ksymtab_gpl or __ksymtab_gpl_future
> into __init or __initdata should be a hard error.
> 
> It'd be lovely to do that at compile-time, but I cannot think of a way.
> 
> Sam, does that sound reasonable&&feasible?


Until modpost (or whatever) can do this, here are a few that
a shell script has found for me by examing source code only --
may contain some false reports:


./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph)
./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup)

./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph);
./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup)

./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input);
./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup)

./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output);
./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value)

./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch);
./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on)

./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive);
./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on)

./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info);
./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info)

./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info);
./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info)

./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg);
./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index)

./arch/mips/au1000/common/prom.c:155:EXPORT_SYMBOL(prom_getcmdline);
./arch/mips/philips/pnx8550/common/prom.c:136:EXPORT_SYMBOL(prom_getcmdline);
./arch/mips/arc/cmdline.c:19:char * __init prom_getcmdline(void)
./arch/mips/au1000/common/setup.c:47:extern char * __init prom_getcmdline(void);
./arch/mips/galileo-boards/ev96100/init.c:56:char * __init prom_getcmdline(void)
./arch/mips/galileo-boards/ev96100/setup.c:52:extern char *__init prom_getcmdline(void);
./arch/mips/ite-boards/generic/pmon_prom.c:55:char * __init prom_getcmdline(void)
./arch/mips/jmr3927/common/prom.c:54:char * __init prom_getcmdline(void)
./arch/mips/mips-boards/generic/cmdline.c:34:char * __init prom_getcmdline(void)
./arch/mips/mips-boards/sim/sim_cmdline.c:24:char * __init prom_getcmdline(void)
./arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_prom.c:93:char * __init prom_getcmdline(void)
./arch/mips/tx4938/toshiba_rbtx4938/prom.c:75:char * __init prom_getcmdline(void)

./arch/powerpc/platforms/powermac/setup.c:397:EXPORT_SYMBOL(note_scsi_host);
./arch/powerpc/platforms/powermac/setup.c:370:void __init note_scsi_host(struct device_node *node, void *host)

./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new);
./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp)


---
~Randy

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-29 23:07                   ` Valdis.Kletnieks
@ 2006-06-30 19:26                     ` john stultz
  2006-06-30 21:04                       ` Valdis.Kletnieks
  0 siblings, 1 reply; 93+ messages in thread
From: john stultz @ 2006-06-30 19:26 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel

On Thu, 2006-06-29 at 19:07 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 28 Jun 2006 13:44:12 +0200, Roman Zippel said:
> 
> > Valdis, could you please add a call to the function below in 
> > __get_realtime_clock_ts() when the problem triggers to print the complete 
> > internal clock state.
> 
> Sorry for the delay, I got distracted by other stuff I'm paid to do.. ;)

Very much understand :) Thanks for the testing!

> Here's what a test reboot got:
> 
>    26.578105] audit(1151617213.106:2): policy loaded auid=4294967295
> [   26.597401] audit(1151617213.070:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r
> :security_t:s0 tclass=security
> [   26.683670] unexpected nsec: -840940811,1655512912
> [   26.704096] clock tsc: m:4290198220,s:22,cl:42659140158,ci:1595067,xn:18158513697558798592,xi:18446736466713803524,e:3648592523541009408

> That tell you anything?

Its a little after the fact (since things have already gone awry), but
it does show the multiplier is way out of bound.

I suspect the following patch will resolve it. The update callback
hasn't kept up with the changes from Roman, and is a bit useless anyway.
If the TSC is changing frequency, its unstable and we don't want to use
it, so lets just mark it as such and move along.

I'll work on a patch to cleanup the update_callback code, but if this
resolves the issue, it should be the safe short term fix for 2.6.18.

thanks again!
-john

diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c
index 7e0d8da..68d23f0 100644
--- a/arch/i386/kernel/tsc.c
+++ b/arch/i386/kernel/tsc.c
@@ -348,22 +348,19 @@ static int tsc_update_callback(void)
 {
 	int change = 0;
 
-	/* check to see if we should switch to the safe clocksource: */
-	if (clocksource_tsc.rating != 50 && check_tsc_unstable()) {
-		clocksource_tsc.rating = 50;
-		clocksource_reselect();
-		change = 1;
-	}
-
 	/* only update if tsc_khz has changed: */
 	if (current_tsc_khz != tsc_khz) {
 		current_tsc_khz = tsc_khz;
-		clocksource_tsc.mult = clocksource_khz2mult(current_tsc_khz,
-							clocksource_tsc.shift);
-		change = 1;
+		/* TSC is chnaging freq, mark tsc as bad */
+		mark_tsc_unstable();
 	}
 
-	return change;
+	/* check to see if we should switch to the safe clocksource: */
+	if (clocksource_tsc.rating != 50 && check_tsc_unstable()) {
+		clocksource_tsc.rating = 50;
+		clocksource_reselect();
+	}
+	return 0;
 }
 
 static int __init dmi_mark_tsc_unstable(struct dmi_system_id *d)




^ permalink raw reply related	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-30 19:26                     ` john stultz
@ 2006-06-30 21:04                       ` Valdis.Kletnieks
  2006-07-03  1:13                         ` Roman Zippel
  0 siblings, 1 reply; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-06-30 21:04 UTC (permalink / raw)
  To: john stultz; +Cc: Roman Zippel, Andrew Morton, linux-kernel

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

On Fri, 30 Jun 2006 12:26:09 PDT, john stultz said:

> Its a little after the fact (since things have already gone awry), but
> it does show the multiplier is way out of bound.
> 
> I suspect the following patch will resolve it. The update callback
> hasn't kept up with the changes from Roman, and is a bit useless anyway.
> If the TSC is changing frequency, its unstable and we don't want to use
> it, so lets just mark it as such and move along.
> 
> I'll work on a patch to cleanup the update_callback code, but if this
> resolves the issue, it should be the safe short term fix for 2.6.18.

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

In kernel/timer.c, we have:

static void clocksource_adjust(struct clocksource *clock, s64 offset)
(s64 used for offset in multiple places).

However, in other places, offset is a 'cycle_t', which is:

include/linux/clocksource.h:typedef u64 cycle_t;

So it looks like a signed/unsigned screwage.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-30  7:38             ` 2.6.17-mm2 Randy.Dunlap
@ 2006-07-02 10:11               ` Russell King
  2006-07-02 18:42                 ` 2.6.17-mm2 Randy.Dunlap
  2006-07-03  5:50                 ` 2.6.17-mm2 Randy.Dunlap
  0 siblings, 2 replies; 93+ messages in thread
From: Russell King @ 2006-07-02 10:11 UTC (permalink / raw)
  To: Randy.Dunlap
  Cc: Andrew Morton, rjw, davej, linux-kernel, sekharan, rusty, sam

On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote:
> Until modpost (or whatever) can do this, here are a few that
> a shell script has found for me by examing source code only --
> may contain some false reports:
> 
> ./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph)
> ./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup)
> 
> ./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph);
> ./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup)
> 
> ./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input);
> ./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup)
> 
> ./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output);
> ./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value)
> 
> ./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch);
> ./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on)
> 
> ./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive);
> ./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on)
>
> ./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg);
> ./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index)
> 

These would appear to be false:

#ifdef CONFIG_MODULES
#define __init_or_module
#define __initdata_or_module
#else
#define __init_or_module __init
#define __initdata_or_module __initdata
#endif /*CONFIG_MODULES*/

and:

#else /* !CONFIG_MODULES... */
#define EXPORT_SYMBOL(sym)
#define EXPORT_SYMBOL_GPL(sym)
#define EXPORT_SYMBOL_GPL_FUTURE(sym)
#define EXPORT_UNUSED_SYMBOL(sym)
#define EXPORT_UNUSED_SYMBOL_GPL(sym)

means that in the modules case, they aren't marked as __init and are
exported, but in the non-modular case they are marked as __init but
not exported.

Hence, export symbols marked as __init_or_module is safe.

> ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info);
> ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info)
> 
> ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info);
> ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info)
>
> ./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new);
> ./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp)

These are definitely buggy.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-07-02 10:11               ` 2.6.17-mm2 Russell King
@ 2006-07-02 18:42                 ` Randy.Dunlap
  2006-07-02 18:47                   ` 2.6.17-mm2 Arjan van de Ven
  2006-07-02 18:47                   ` 2.6.17-mm2 Sam Ravnborg
  2006-07-03  5:50                 ` 2.6.17-mm2 Randy.Dunlap
  1 sibling, 2 replies; 93+ messages in thread
From: Randy.Dunlap @ 2006-07-02 18:42 UTC (permalink / raw)
  To: Russell King; +Cc: akpm, rjw, davej, linux-kernel, sekharan, rusty, sam

On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:

> On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote:
> > Until modpost (or whatever) can do this, here are a few that
> > a shell script has found for me by examing source code only --
> > may contain some false reports:
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:81:EXPORT_SYMBOL(at91_set_A_periph)
> > ./arch/arm/mach-at91rm9200/gpio.c:67:int __init_or_module at91_set_A_periph(unsigned pin, int use_pullup)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:101:EXPORT_SYMBOL(at91_set_B_periph);
> > ./arch/arm/mach-at91rm9200/gpio.c:87:int __init_or_module at91_set_B_periph(unsigned pin, int use_pullup)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:122:EXPORT_SYMBOL(at91_set_gpio_input);
> > ./arch/arm/mach-at91rm9200/gpio.c:108:int __init_or_module at91_set_gpio_input(unsigned pin, int use_pullup)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:144:EXPORT_SYMBOL(at91_set_gpio_output);
> > ./arch/arm/mach-at91rm9200/gpio.c:129:int __init_or_module at91_set_gpio_output(unsigned pin, int value)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:160:EXPORT_SYMBOL(at91_set_deglitch);
> > ./arch/arm/mach-at91rm9200/gpio.c:150:int __init_or_module at91_set_deglitch(unsigned pin, int is_on)
> > 
> > ./arch/arm/mach-at91rm9200/gpio.c:177:EXPORT_SYMBOL(at91_set_multi_drive);
> > ./arch/arm/mach-at91rm9200/gpio.c:166:int __init_or_module at91_set_multi_drive(unsigned pin, int is_on)
> >
> > ./arch/arm/plat-omap/mux.c:196:EXPORT_SYMBOL(omap_cfg_reg);
> > ./arch/arm/plat-omap/mux.c:58:int __init_or_module omap_cfg_reg(const unsigned long index)
> > 
> 
> These would appear to be false:
> 
> #ifdef CONFIG_MODULES
> #define __init_or_module
> #define __initdata_or_module
> #else
> #define __init_or_module __init
> #define __initdata_or_module __initdata
> #endif /*CONFIG_MODULES*/
> 
> and:
> 
> #else /* !CONFIG_MODULES... */
> #define EXPORT_SYMBOL(sym)
> #define EXPORT_SYMBOL_GPL(sym)
> #define EXPORT_SYMBOL_GPL_FUTURE(sym)
> #define EXPORT_UNUSED_SYMBOL(sym)
> #define EXPORT_UNUSED_SYMBOL_GPL(sym)
> 
> means that in the modules case, they aren't marked as __init and are
> exported, but in the non-modular case they are marked as __init but
> not exported.
> 
> Hence, export symbols marked as __init_or_module is safe.

Thanks for checking + feedback.

> > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info);
> > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info)
> > 
> > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info);
> > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info)
> >
> > ./sound/i2c/l3/uda1341.c:929:EXPORT_SYMBOL(snd_chip_uda1341_mixer_new);
> > ./sound/i2c/l3/uda1341.c:769:int __init snd_chip_uda1341_mixer_new(struct snd_card *card, struct l3_client **clntp)
> 
> These are definitely buggy.

Only if we have a policy of not exporting __init or __initdata or
__exit.  Are we there yet??

snd_chip_uda1341_mixer_new() is called from
sound/arm/sa11xx-uda1341.c::sa11xx_uda1341_probe(), which is
__init, so it looks safe to me, although I support a policy
that EXPORTs cannot be __init or __exit or __initdata.

---
~Randy

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-07-02 18:42                 ` 2.6.17-mm2 Randy.Dunlap
@ 2006-07-02 18:47                   ` Arjan van de Ven
  2006-07-02 18:47                   ` 2.6.17-mm2 Sam Ravnborg
  1 sibling, 0 replies; 93+ messages in thread
From: Arjan van de Ven @ 2006-07-02 18:47 UTC (permalink / raw)
  To: Randy.Dunlap
  Cc: Russell King, akpm, rjw, davej, linux-kernel, sekharan, rusty, sam

On Sun, 2006-07-02 at 11:42 -0700, Randy.Dunlap wrote:
> 
> Only if we have a policy of not exporting __init or __initdata or
> __exit.  Are we there yet??

__exit is harder, but __init and __initdata is obvious; those are tossed
out of memory before you can even load a module so exporting those HAS
to be a bug; no excuse possible.



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-07-02 18:42                 ` 2.6.17-mm2 Randy.Dunlap
  2006-07-02 18:47                   ` 2.6.17-mm2 Arjan van de Ven
@ 2006-07-02 18:47                   ` Sam Ravnborg
  1 sibling, 0 replies; 93+ messages in thread
From: Sam Ravnborg @ 2006-07-02 18:47 UTC (permalink / raw)
  To: Randy.Dunlap
  Cc: Russell King, akpm, rjw, davej, linux-kernel, sekharan, rusty

 
> Only if we have a policy of not exporting __init or __initdata or
> __exit.  Are we there yet??

On the principle of minimum suprise we shall no allow exported symbols
to magically disappear. Only some architectures do get rid of .init and
therefore a module may work with architecture one, but not architecture
two which is very unpredictable.

It should be established as a rule better now than later that this is a
no-go.

	Sam

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-06-30 21:04                       ` Valdis.Kletnieks
@ 2006-07-03  1:13                         ` Roman Zippel
  2006-07-03  1:56                           ` Daniel Walker
  2006-07-05  4:29                           ` Valdis.Kletnieks
  0 siblings, 2 replies; 93+ messages in thread
From: Roman Zippel @ 2006-07-03  1:13 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: john stultz, Andrew Morton, linux-kernel

Hi,

On Fri, 30 Jun 2006, Valdis.Kletnieks@vt.edu wrote:

> *AHA* I *found* the bugger, I think.
> 
> In kernel/timer.c, we have:
> 
> static void clocksource_adjust(struct clocksource *clock, s64 offset)
> (s64 used for offset in multiple places).
> 
> However, in other places, offset is a 'cycle_t', which is:
> 
> include/linux/clocksource.h:typedef u64 cycle_t;
> 
> So it looks like a signed/unsigned screwage.

It's a possibility, but the signed/unsigned usage is pretty much 
intentional. The assumptation is that time only goes forward so nothing 
there should become negative, only adjustments happen in both directions.
It's really weird why it's getting completely so out of control early 
during boot. It would be great if you could also test the patch below, it 
should trigger closer to when it goes wrong and help to analyze the 
problem (or at least rule out a number of possibilities).

bye, Roman

---
 kernel/timer.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c
+++ linux-2.6-mm/kernel/timer.c
@@ -1078,6 +1078,7 @@ static __always_inline int clocksource_b
  */
 static void clocksource_adjust(struct clocksource *clock, s64 offset)
 {
+	static int cnt = 16;
 	s64 error, interval = clock->cycle_interval;
 	int adj;
 
@@ -1091,6 +1092,13 @@ static void clocksource_adjust(struct cl
 	} else
 		return;
 
+	if ((adj > 10 || adj < -10 || (s32)clock->mult <= -adj) && cnt > 0) {
+		cnt--;
+		printk("big adj at %ld (%Lu,%d,%Ld,%Ld)\n", jiffies, current_tick_length(),
+			adj, interval, offset);
+		printk_clock_info();
+	}
+
 	clock->mult += adj;
 	clock->xtime_interval += interval;
 	clock->xtime_nsec -= offset;
@@ -1149,9 +1157,15 @@ static void update_wall_time(void)
 
 	/* check to see if there is a new clocksource to use */
 	if (change_clocksource()) {
+		static int cnt = 16;
 		clock->error = 0;
 		clock->xtime_nsec = 0;
 		clocksource_calculate_interval(clock, tick_nsec);
+		if (cnt > 0) {
+			cnt--;
+			printk("clock changed at %ld (%Lu)\n", jiffies, current_tick_length());
+			printk_clock_info();
+		}
 	}
 }
 

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-03  1:13                         ` Roman Zippel
@ 2006-07-03  1:56                           ` Daniel Walker
  2006-07-03  2:20                             ` Valdis.Kletnieks
  2006-07-03 19:59                             ` john stultz
  2006-07-05  4:29                           ` Valdis.Kletnieks
  1 sibling, 2 replies; 93+ messages in thread
From: Daniel Walker @ 2006-07-03  1:56 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Valdis.Kletnieks, john stultz, Andrew Morton, linux-kernel

On Mon, 2006-07-03 at 03:13 +0200, Roman Zippel wrote:

> It's a possibility, but the signed/unsigned usage is pretty much 
> intentional. The assumptation is that time only goes forward so nothing 
> there should become negative, only adjustments happen in both directions.
> It's really weird why it's getting completely so out of control early 
> during boot. It would be great if you could also test the patch below, it 
> should trigger closer to when it goes wrong and help to analyze the 
> problem (or at least rule out a number of possibilities).

I was reviewing these new ntp adjustment functions, and it seems like it
would be a lot easier to just switch to a better clocksource. These new
functions seems to compensate for a clock that has a high rating but is
actually quite poor..

Daniel


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-03  1:56                           ` Daniel Walker
@ 2006-07-03  2:20                             ` Valdis.Kletnieks
  2006-07-03 20:08                               ` john stultz
  2006-07-03 19:59                             ` john stultz
  1 sibling, 1 reply; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-07-03  2:20 UTC (permalink / raw)
  To: Daniel Walker; +Cc: Roman Zippel, john stultz, Andrew Morton, linux-kernel

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

On Sun, 02 Jul 2006 18:56:22 PDT, Daniel Walker said:

> I was reviewing these new ntp adjustment functions, and it seems like it
> would be a lot easier to just switch to a better clocksource. These new
> functions seems to compensate for a clock that has a high rating but is
> actually quite poor..

It is indeed poor - a few -mm's ago I tripped over a bug that kept it from
recognizing the PM timer clocksource, and it refused to NTP sync because
the clock drift was well outside the 500 ppm that NTP wants.  All the same,
it's *one* thing for a clock to be drifting 10 seconds per hour.  It's
something else to totally explode when handed a drifting clock.

Currently, the kernel is build with CONFIG_RTC=m, and the clock starts
behaving as soom as rc.sysinit modprobes it.  Questions this raises:

1) What's up with *that*?
2) Anybody want to place bets that building with CONFIG_RTC=y will make
the clock work right off the bat?
3) Is that a fix, or just wallpaper? :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-07-02 10:11               ` 2.6.17-mm2 Russell King
  2006-07-02 18:42                 ` 2.6.17-mm2 Randy.Dunlap
@ 2006-07-03  5:50                 ` Randy.Dunlap
  2006-07-03 13:49                   ` 2.6.17-mm2 Russell King
  1 sibling, 1 reply; 93+ messages in thread
From: Randy.Dunlap @ 2006-07-03  5:50 UTC (permalink / raw)
  To: Russell King; +Cc: akpm, rjw, davej, linux-kernel, sekharan, rusty, sam

On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:

> On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote:
> > Until modpost (or whatever) can do this, here are a few that
> > a shell script has found for me by examing source code only --
> > may contain some false reports:
> > 
...
> > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info);
> > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info)
> > 
> > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info);
> > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info)
> >
> These are definitely buggy.

Um, well, I could blindly remove those __init sections, but in
looking at the code, set_imx_fb_info() is not ever used, and
imx_set_mmc_info() is called from some __init code...

It looks like this code can only be built-in, not as a loadable
module.  (so someone who knows it should jump in here)
If that's correct, then the EXPORT_SYMBOL() isn't even needed
and the function can remain as __init (right?).

---
~Randy

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-07-03  5:50                 ` 2.6.17-mm2 Randy.Dunlap
@ 2006-07-03 13:49                   ` Russell King
  0 siblings, 0 replies; 93+ messages in thread
From: Russell King @ 2006-07-03 13:49 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: akpm, rjw, davej, linux-kernel, sekharan, rusty, sam

On Sun, Jul 02, 2006 at 10:50:24PM -0700, Randy.Dunlap wrote:
> On Sun, 2 Jul 2006 11:11:46 +0100 Russell King wrote:
> > On Fri, Jun 30, 2006 at 12:38:13AM -0700, Randy.Dunlap wrote:
> > > Until modpost (or whatever) can do this, here are a few that
> > > a shell script has found for me by examing source code only --
> > > may contain some false reports:
> > > 
> ...
> > > ./arch/arm/mach-imx/generic.c:196:EXPORT_SYMBOL(imx_set_mmc_info);
> > > ./arch/arm/mach-imx/generic.c:192:void __init imx_set_mmc_info(struct imxmmc_platform_data *info)
> > > 
> > > ./arch/arm/mach-imx/generic.c:204:EXPORT_SYMBOL(set_imx_fb_info);
> > > ./arch/arm/mach-imx/generic.c:200:void __init set_imx_fb_info(struct imxfb_mach_info *hard_imx_fb_info)
> > >
> > These are definitely buggy.
> 
> Um, well, I could blindly remove those __init sections, but in
> looking at the code, set_imx_fb_info() is not ever used, and
> imx_set_mmc_info() is called from some __init code...
> 
> It looks like this code can only be built-in, not as a loadable
> module.  (so someone who knows it should jump in here)
> If that's correct, then the EXPORT_SYMBOL() isn't even needed
> and the function can remain as __init (right?).

Since they're being used to set the platform data for devices, which
are registered during the init time, they should definitely only be
called early on during init - otherwise you're potentially changing
data which drivers expect to be static.

So the exports should go.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-03  1:56                           ` Daniel Walker
  2006-07-03  2:20                             ` Valdis.Kletnieks
@ 2006-07-03 19:59                             ` john stultz
  2006-07-04 22:21                               ` Valdis.Kletnieks
  1 sibling, 1 reply; 93+ messages in thread
From: john stultz @ 2006-07-03 19:59 UTC (permalink / raw)
  To: Daniel Walker; +Cc: Roman Zippel, Valdis.Kletnieks, Andrew Morton, linux-kernel

On Sun, 2006-07-02 at 18:56 -0700, Daniel Walker wrote:
> On Mon, 2006-07-03 at 03:13 +0200, Roman Zippel wrote:
> I was reviewing these new ntp adjustment functions, and it seems like it
> would be a lot easier to just switch to a better clocksource. These new
> functions seems to compensate for a clock that has a high rating but is
> actually quite poor..

Not quite. The issue is that the adjustment that the ntpd makes is quite
fine grained, and some clocksources while quite stable, might not be
able to make such a fine adjustment. So the extra error accounting just
allows us to keep track and compensate for the resolution differences.

Does that make sense?

thanks
-john



^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-03  2:20                             ` Valdis.Kletnieks
@ 2006-07-03 20:08                               ` john stultz
  0 siblings, 0 replies; 93+ messages in thread
From: john stultz @ 2006-07-03 20:08 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Daniel Walker, Roman Zippel, Andrew Morton, linux-kernel

On Sun, 2006-07-02 at 22:20 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 02 Jul 2006 18:56:22 PDT, Daniel Walker said:
> 
> > I was reviewing these new ntp adjustment functions, and it seems like it
> > would be a lot easier to just switch to a better clocksource. These new
> > functions seems to compensate for a clock that has a high rating but is
> > actually quite poor..
> 
> It is indeed poor - a few -mm's ago I tripped over a bug that kept it from
> recognizing the PM timer clocksource, and it refused to NTP sync because
> the clock drift was well outside the 500 ppm that NTP wants.  All the same,
> it's *one* thing for a clock to be drifting 10 seconds per hour.  It's
> something else to totally explode when handed a drifting clock.

Yes, the TSC is a very poor clocksource. Although its high resolution
and very quick access time makes it hard to quit. 

> Currently, the kernel is build with CONFIG_RTC=m, and the clock starts
> behaving as soom as rc.sysinit modprobes it.  Questions this raises:
> 
> 1) What's up with *that*?

Hmmm. Thats an interesting observation. Let me look to see if maybe
something is going oddly in the settimeofday() path.

> 2) Anybody want to place bets that building with CONFIG_RTC=y will make
> the clock work right off the bat?

No bets here, but please let us know if you see any change in behavior.

thanks
-john


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-03 19:59                             ` john stultz
@ 2006-07-04 22:21                               ` Valdis.Kletnieks
  0 siblings, 0 replies; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-07-04 22:21 UTC (permalink / raw)
  To: john stultz; +Cc: Daniel Walker, Roman Zippel, Andrew Morton, linux-kernel

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

On Mon, 03 Jul 2006 12:59:43 PDT, john stultz said:
> On Sun, 2006-07-02 at 18:56 -0700, Daniel Walker wrote:
> > On Mon, 2006-07-03 at 03:13 +0200, Roman Zippel wrote:
> > I was reviewing these new ntp adjustment functions, and it seems like it
> > would be a lot easier to just switch to a better clocksource. These new
> > functions seems to compensate for a clock that has a high rating but is
> > actually quite poor..
> 
> Not quite. The issue is that the adjustment that the ntpd makes is quite
> fine grained, and some clocksources while quite stable, might not be
> able to make such a fine adjustment. So the extra error accounting just
> allows us to keep track and compensate for the resolution differences.
> 
> Does that make sense?

Except for the fact that NTP isn't running yet when I see this trouble...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-03  1:13                         ` Roman Zippel
  2006-07-03  1:56                           ` Daniel Walker
@ 2006-07-05  4:29                           ` Valdis.Kletnieks
  2006-07-06  0:37                             ` Roman Zippel
  2006-07-06  0:51                             ` john stultz
  1 sibling, 2 replies; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-07-05  4:29 UTC (permalink / raw)
  To: Roman Zippel; +Cc: john stultz, Andrew Morton, linux-kernel

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

On Mon, 03 Jul 2006 03:13:39 +0200, Roman Zippel said:
> Hi,
> 
> On Fri, 30 Jun 2006, Valdis.Kletnieks@vt.edu wrote:
> 
> > *AHA* I *found* the bugger, I think.
> > 
> > In kernel/timer.c, we have:
> > 
> > static void clocksource_adjust(struct clocksource *clock, s64 offset)
> > (s64 used for offset in multiple places).
> > 
> > However, in other places, offset is a 'cycle_t', which is:
> > 
> > include/linux/clocksource.h:typedef u64 cycle_t;
> > 
> > So it looks like a signed/unsigned screwage.
> 
> It's a possibility, but the signed/unsigned usage is pretty much 
> intentional. The assumptation is that time only goes forward so nothing 
> there should become negative, only adjustments happen in both directions.
> It's really weird why it's getting completely so out of control early 
> during boot. It would be great if you could also test the patch below, it 
> should trigger closer to when it goes wrong and help to analyze the 
> problem (or at least rule out a number of possibilities).

Here you go.. For what it's worth, your debugging in clocksource_adjust seems
to only pop before we start userspace, and get_realtime_clock_ts only once
userspace starts.

My speculation about the RTC module turns out to be a red herring - I tried
a kernel with it built in, and the problem still manifested and cleared itself
early in rc.sysinit.  Checking the code there, what seems to matter is that
rc.sysinit calls '/sbin/hwclock --hctosys --utc'.

Output of 'hwclock --debug':

hwclock from util-linux-2.13-pre6
Using /dev/rtc interface to clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2006/07/05 07:57:52
Hw clock time : 2006/07/05 07:57:52 = 1152086272 seconds since 1969
Calling settimeofday:
        tv.tv_sec = 1152086272, tv.tv_usec = 0
        tz.tz_minuteswest = 240

Absolutely nothing edifying there..

The dmesg, with all the suggested patches so far applied.  Looks like something
starts off uninitialized - we get the first 'big adj' squawk right after we
allocate the console - we don't allocate the tsc timesource for another 4
seconds or so.

I'll bite - what *am* I using as a timesource for those first 4 seconds? :)

[    0.000000] Linux version 2.6.17-mm2-test (valdis@turing-police.cc.vt.edu) (gcc version 4.1.1 20060629 (Red Hat 4.1.1-6)) #3 PREEMPT Tue Jul 4 18:42:05 EDT 2006
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000002ffe2800 (usable)
[    0.000000]  BIOS-e820: 000000002ffe2800 - 0000000030000000 (reserved)
[    0.000000]  BIOS-e820: 00000000feda0000 - 00000000fee00000 (reserved)
[    0.000000]  BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
[    0.000000] 767MB LOWMEM available.
[    0.000000] On node 0 totalpages: 196578
[    0.000000]   DMA zone: 4096 pages, LIFO batch:0
[    0.000000]   Normal zone: 192482 pages, LIFO batch:31
[    0.000000] DMI 2.3 present.
[    0.000000] ACPI: RSDP (v000 DELL                                  ) @ 0x000fde50
[    0.000000] ACPI: RSDT (v001 DELL    CPi R   0x27d40107 ASL  0x00000061) @ 0x000fde64
[    0.000000] ACPI: FADT (v001 DELL    CPi R   0x27d40107 ASL  0x00000061) @ 0x000fde90
[    0.000000] ACPI: DSDT (v001 INT430 SYSFexxx 0x00001001 MSFT 0x0100000e) @ 0x00000000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] Allocating PCI resources starting at 40000000 (gap: 30000000:ceda0000)
[    0.000000] Detected 1595.408 MHz processor.
[   24.231372] Built 1 zonelists.  Total pages: 196578
[   24.231376] Kernel command line: console=tty0 vga=794 single
[   24.231839] Local APIC disabled by BIOS -- you can enable it with "lapic"
[   24.231854] mapped APIC to ffffd000 (01603000)
[   24.231860] Enabling fast FPU save and restore... done.
[   24.231864] Enabling unmasked SIMD FPU exception support... done.
[   24.231871] Initializing CPU#0
[   24.231977] CPU 0 irqstacks, hard=c04e2000 soft=c04e1000
[   24.231982] PID hash table entries: 4096 (order: 12, 16384 bytes)
[   24.232106] Console: colour dummy device 80x25
[   24.232202] big adj at -299999 (4294314460971008,128,128,0)
[   24.232214] clock jiffies: m:255960832,s:8,cl:4294667297,ci:1,xn:76031960832,xi:255960832,e:4294967296
[   24.232983] big adj at -299998 (4294314460971008,64,64,0)
[   24.232996] clock jiffies: m:255960960,s:8,cl:4294667298,ci:1,xn:76287921792,xi:255960960,e:4294967296
[   24.233231] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[   24.233991] big adj at -299997 (4294314460971008,64,64,0)
[   24.234010] clock jiffies: m:255961024,s:8,cl:4294667299,ci:1,xn:76543882816,xi:255961024,e:4294967296
[   24.234390] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[   24.234978] big adj at -299996 (4294314460971008,32,32,0)
[   24.234988] clock jiffies: m:255961088,s:8,cl:4294667300,ci:1,xn:76799843904,xi:255961088,e:3221225472
[   24.235988] big adj at -299995 (4294314460971008,16,16,0)
[   24.236009] clock jiffies: m:255961120,s:8,cl:4294667301,ci:1,xn:77055805024,xi:255961120,e:2147483648
[   24.238986] big adj at -299992 (4294314460971008,-32,-32,0)
[   24.239010] clock jiffies: m:255961141,s:8,cl:4294667304,ci:1,xn:77823688441,xi:255961141,e:-771751936
[   24.239980] big adj at -299991 (4294314460971008,-16,-16,0)
[   24.240001] clock jiffies: m:255961109,s:8,cl:4294667305,ci:1,xn:78079649550,xi:255961109,e:-587202560
[   24.261902] Memory: 773428k/786312k available (2279k kernel code, 12284k reserved, 981k data, 192k init, 0k highmem)
[   24.261916] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[   24.321842] Calibrating delay using timer specific routine.. 3192.23 BogoMIPS (lpj=1596118)
[   24.321890] Security Framework v1.0.0 initialized
[   24.321899] SELinux:  Initializing.
[   24.321916] SELinux:  Starting in permissive mode
[   24.321930] selinux_register_security:  Registering secondary module capability
[   24.321938] Capability LSM initialized as secondary
[   24.321957] Mount-cache hash table entries: 512
[   24.322102] CPU: After generic identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000
[   24.322116] CPU: After vendor identify, caps: 3febf9ff 00000000 00000000 00000000 00000000 00000000 00000000
[   24.322130] CPU: Trace cache: 12K uops, L1 D cache: 8K
[   24.322137] CPU: L2 cache: 512K
[   24.322142] CPU: After all inits, caps: 3febf9ff 00000000 00000000 00000080 00000000 00000000 00000000
[   24.322152] Intel machine check architecture supported.
[   24.322162] Intel machine check reporting enabled on CPU#0.
[   24.322169] CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
[   24.322177] CPU0: Thermal monitoring enabled
[   24.322196] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04
[   24.322210] Checking 'hlt' instruction... OK.
[   24.325941] SMP alternatives: switching to UP code
[   24.325948] Freeing SMP alternatives: 0k freed
[   24.325953] ACPI: Core revision 20060608
[   24.369235] ACPI: setting ELCR to 0200 (from 0800)
[   24.374594] checking if image is initramfs... it is
[   24.522694] Freeing initrd memory: 1031k freed
[   24.523169] NET: Registered protocol family 16
[   24.523769] ACPI: ACPI Dock Station Driver 
[   24.523784] ACPI: bus type pci registered
[   24.537296] PCI: PCI BIOS revision 2.10 entry at 0xfbfee, last bus=2
[   24.537303] Setting up standard PCI resources
[   24.567815] ACPI: Interpreter enabled
[   24.567828] ACPI: Using PIC for interrupt routing
[   24.572140] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   24.572153] PCI: Probing PCI hardware (bus 00)
[   24.572578] ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
[   24.648477] PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO
[   24.648490] PCI quirk: region 0880-08bf claimed by ICH4 GPIO
[   24.648591] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
[   24.649169] Boot video device is 0000:01:00.0
[   24.649943] PCI: Transparent bridge - 0000:00:1e.0
[   24.650877] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   24.801769] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11)
[   24.803130] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11
[   24.804452] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11)
[   24.805785] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11)
[   24.809149] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[   24.810372] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIE._PRT]
[   24.813313] ACPI: Power Resource [PADA] (on)
[   24.814796] Linux Plug and Play Support v0.97 (c) Adam Belay
[   24.814820] pnp: PnP ACPI init
[   25.042773] pnp: PnP ACPI: found 17 devices
[   25.042817] Intel 82802 RNG detected
[   25.043398] usbcore: registered new driver usbfs
[   25.043657] usbcore: registered new driver hub
[   25.044250] PCI: Using ACPI for IRQ routing
[   25.044259] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   25.087170] pnp: 00:02: ioport range 0x4d0-0x4d1 has been reserved
[   25.087181] pnp: 00:02: ioport range 0x800-0x805 could not be reserved
[   25.087189] pnp: 00:02: ioport range 0x808-0x80f could not be reserved
[   25.087202] pnp: 00:03: ioport range 0x806-0x807 has been reserved
[   25.087209] pnp: 00:03: ioport range 0x810-0x85f could not be reserved
[   25.087217] pnp: 00:03: ioport range 0x860-0x87f has been reserved
[   25.087224] pnp: 00:03: ioport range 0x880-0x8bf has been reserved
[   25.087231] pnp: 00:03: ioport range 0x8c0-0x8df has been reserved
[   25.087237] pnp: 00:03: ioport range 0x8e0-0x8ff has been reserved
[   25.087253] pnp: 00:04: ioport range 0xf000-0xf0fe has been reserved
[   25.087261] pnp: 00:04: ioport range 0xf100-0xf1fe has been reserved
[   25.087269] pnp: 00:04: ioport range 0xf200-0xf2fe has been reserved
[   25.087276] pnp: 00:04: ioport range 0xf400-0xf4fe has been reserved
[   25.087283] pnp: 00:04: ioport range 0xf500-0xf5fe has been reserved
[   25.087291] pnp: 00:04: ioport range 0xf600-0xf6fe has been reserved
[   25.087298] pnp: 00:04: ioport range 0xf800-0xf8fe has been reserved
[   25.087306] pnp: 00:04: ioport range 0xf900-0xf9fe has been reserved
[   25.087323] pnp: 00:09: ioport range 0x900-0x91f has been reserved
[   25.087330] pnp: 00:09: ioport range 0x3f0-0x3f1 has been reserved
[   25.087347] pnp: 00:0f: ioport range 0xbf40-0xbf5f has been reserved
[   25.089593] PCI: Bridge: 0000:00:01.0
[   25.089603]   IO window: c000-cfff
[   25.089614]   MEM window: fc000000-fdffffff
[   25.089624]   PREFETCH window: d8000000-e7ffffff
[   25.089680] PCI: Bus 3, cardbus bridge: 0000:02:01.0
[   25.089687]   IO window: 0000e000-0000e0ff
[   25.089697]   IO window: 0000e400-0000e4ff
[   25.089708]   PREFETCH window: 40000000-41ffffff
[   25.089719]   MEM window: f4000000-f5ffffff
[   25.089729] PCI: Bus 7, cardbus bridge: 0000:02:01.1
[   25.089735]   IO window: 0000e800-0000e8ff
[   25.089745]   IO window: 00001000-000010ff
[   25.089755]   PREFETCH window: 42000000-43ffffff
[   25.089765]   MEM window: f6000000-f7ffffff
[   25.089775] PCI: Bus 11, cardbus bridge: 0000:02:03.0
[   25.089781]   IO window: 00001400-000014ff
[   25.089791]   IO window: 00001800-000018ff
[   25.089801]   PREFETCH window: 44000000-45ffffff
[   25.089812]   MEM window: fa000000-fbffffff
[   25.089821] PCI: Bridge: 0000:00:1e.0
[   25.089829]   IO window: e000-ffff
[   25.089841]   MEM window: f4000000-fbffffff
[   25.089852]   PREFETCH window: 40000000-46ffffff
[   25.089888] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[   25.089916] PCI: Enabling device 0000:02:01.0 (0000 -> 0003)
[   25.090851] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
[   25.090860] PCI: setting IRQ 11 as level-triggered
[   25.090865] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[   25.090903] PCI: Enabling device 0000:02:01.1 (0000 -> 0003)
[   25.090912] ACPI: PCI Interrupt 0000:02:01.1[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[   25.090947] ACPI: PCI Interrupt 0000:02:03.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
[   25.090997] NET: Registered protocol family 2
[   25.100721] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[   25.101037] TCP established hash table entries: 131072 (order: 7, 524288 bytes)
[   25.101582] TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
[   25.102109] TCP: Hash tables configured (established 131072 bind 65536)
[   25.102118] TCP reno registered
[   25.103491] Machine check exception polling timer started.
[   25.103629] speedstep: frequency transition measured seems out of range (0 nSec), falling back to a safe one of 500000 nSec.
[   25.115284] audit: initializing netlink socket (disabled)
[   25.115311] audit(1152053784.178:1): initialized
[   25.115507] VFS: Disk quotas dquot_6.5.1
[   25.115537] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[   25.115658] SELinux:  Registering netfilter hooks
[   25.121372] Initializing Cryptographic API
[   25.121385] io scheduler noop registered
[   25.121400] io scheduler anticipatory registered (default)
[   25.121414] io scheduler deadline registered
[   25.121434] io scheduler cfq registered
[   25.122236] vesafb: framebuffer at 0xe0000000, mapped to 0xf0880000, using 5120k, total 32768k
[   25.122249] vesafb: mode is 1280x1024x16, linelength=2560, pages=1
[   25.122256] vesafb: protected mode interface info at c000:e140
[   25.122262] vesafb: scrolling: redraw
[   25.122269] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[   25.278897] Console: switching to colour frame buffer device 160x64
[   25.279483] fb0: VESA VGA frame buffer device
[   25.281108] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[   25.299034] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
[   25.299873] Hangcheck: Using get_cycles().
[   25.300277] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[   25.301635] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   25.304229] 00:0d: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   25.306284] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 5
[   25.306809] PCI: setting IRQ 5 as level-triggered
[   25.306815] ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
[   25.307648] ACPI: PCI interrupt for device 0000:00:1f.6 disabled
[   25.312431] RAMDISK driver initialized: 16 RAM disks of 10240K size 1024 blocksize
[   25.315146] loop: loaded (max 8 devices)
[   25.316718] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
[   25.317257] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[   25.318098] 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
[   25.318763] 0000:02:00.0: 3Com PCI 3c905C Tornado at f0804c00.
[   25.342167] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   25.342758] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[   25.343543] ICH3M: IDE controller at PCI slot 0000:00:1f.1
[   25.344068] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
[   25.345514] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
[   25.346049] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[   25.346888] ICH3M: chipset revision 2
[   25.347232] ICH3M: not 100% native mode: will probe irqs later
[   25.347780]     ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:DMA
[   25.348499]     ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:pio, hdd:pio
[   25.349211] Probing IDE interface ide0...
[   25.612743] hda: FUJITSU MHV2060AH, ATA DISK drive
[   26.020116] hdb: TOSHIBA CD-RW/DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive
[   26.075258] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[   26.076319] Probing IDE interface ide1...
[   26.594608] hda: max request size: 128KiB
[   26.622741] hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100)
[   26.628219] hda: cache flushes supported
[   26.628628]  hda: hda1 hda2
[   26.638796] hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
[   26.666022] Uniform CD-ROM driver Revision: 3.20
[   26.698666] ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
[   26.698726] USB Universal Host Controller Interface driver v3.0
[   26.726063] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[   26.753390] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[   26.753398] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   26.780846] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
[   26.808385] uhci_hcd 0000:00:1d.0: irq 11, io base 0x0000bf80
[   26.835528] usb usb1: new device found, idVendor=0000, idProduct=0000
[   26.862572] usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
[   26.889563] usb usb1: Product: UHCI Host Controller
[   26.916458] usb usb1: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd
[   26.943542] usb usb1: SerialNumber: 0000:00:1d.0
[   26.971026] usb usb1: configuration #1 chosen from 1 choice
[   26.998438] hub 1-0:1.0: USB hub found
[   27.025153] hub 1-0:1.0: 2 ports detected
[   27.152792] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[   27.180293] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[   27.180301] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   27.207849] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 2
[   27.235744] uhci_hcd 0000:00:1d.2: irq 11, io base 0x0000bf20
[   27.263385] usb usb2: new device found, idVendor=0000, idProduct=0000
[   27.290913] usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
[   27.318344] usb usb2: Product: UHCI Host Controller
[   27.345662] usb usb2: Manufacturer: Linux 2.6.17-mm2-test uhci_hcd
[   27.373143] usb usb2: SerialNumber: 0000:00:1d.2
[   27.401348] usb usb2: configuration #1 chosen from 1 choice
[   27.429047] hub 2-0:1.0: USB hub found
[   27.456193] hub 2-0:1.0: 2 ports detected
[   27.789215] usb 2-1: new low speed USB device using uhci_hcd and address 2
[   27.984255] usb 2-1: new device found, idVendor=045e, idProduct=0023
[   28.010901] usb 2-1: new device strings: Mfr=1, Product=2, SerialNumber=0
[   28.037435] usb 2-1: Product: Microsoft Trackball Optical®
[   28.063757] usb 2-1: Manufacturer: Microsoft
[   28.090448] usb 2-1: configuration #1 chosen from 1 choice
[   28.134235] input: Microsoft Microsoft Trackball Optical® as /class/input/input0
[   28.160854] input: USB HID v1.00 Mouse [Microsoft Microsoft Trackball Optical®] on usb-0000:00:1d.2-1
[   28.187866] usbcore: registered new driver usbhid
[   28.215125] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[   28.242995] PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[   28.274277] serio: i8042 AUX port at 0x60,0x64 irq 12
[   28.301472] serio: i8042 KBD port at 0x60,0x64 irq 1
[   28.328600] mice: PS/2 mouse device common for all mice
[   28.355927] input: PC Speaker as /class/input/input1
[   28.386381] input: AT Translated Set 2 keyboard as /class/input/input2
[   28.412351] i2c /dev entries driver
[   28.445100] device-mapper: 4.6.0-ioctl (2006-02-17) initialised: dm-devel@redhat.com
[   28.471229] EDAC MC: Ver: 2.0.0 Jul  4 2006
[   28.497455] Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
[   28.525942] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5 (level, low) -> IRQ 5
[   28.552844] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[   29.081381] input: DualPoint Stick as /class/input/input3
[   29.126168] input: AlpsPS/2 ALPS DualPoint TouchPad as /class/input/input4
[   29.163103] intel8x0_measure_ac97_clock: measured 50992 usecs
[   29.190075] intel8x0: measured clock 94563 rejected
[   29.216761] intel8x0: clocking to 48000
[   29.246297] ALSA device list:
[   29.272438]   #0: Intel 82801CA-ICH3 with CS4205 at 0xd800, irq 5
[   29.299153] TCP bic registered
[   29.325327] Initializing IPsec netlink socket
[   29.351386] NET: Registered protocol family 1
[   29.377536] NET: Registered protocol family 10
[   29.403357] lo: Disabled Privacy Extensions
[   29.428765] IPv6 over IPv4 tunneling driver
[   29.454410] NET: Registered protocol family 17
[   29.479450] NET: Registered protocol family 15
[   29.504193] Using IPI Shortcut mode
[   29.528533] Time: tsc clocksource has been installed.
[   29.552855] clock changed at -296333 (4294314460971008)
[   29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0
[   29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712)
[   29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936
[   29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960)
[   29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320
[   29.704510] big adj at -296330 (4294314460971008,-8192,-13067599872,-2961899520)
[   29.731241] clock tsc: m:2629481,s:22,cl:47452694348,ci:1595166,xn:580598318408480,xi:4194458688846,e:-41883408859136
[   29.758931] big adj at -296329 (4294314460971008,262144,418163195904,304081797120)
[   29.786568] clock tsc: m:2621289,s:22,cl:47538833312,ci:1595166,xn:806396399112596,xi:4181391088974,e:647244064829440
[   29.814707] big adj at -296328 (4294314460971008,-8388608,-13381222268928,-7813787025408)
[   29.843116] clock tsc: m:2883433,s:22,cl:47628162608,ci:1595166,xn:1063667357268644,xi:4599554284878,e:-22744806385192960
[   29.872317] big adj at -296327 (4294314460971008,1,1595166,446268)
[   29.901485] clock tsc: m:4289462121,s:22,cl:47720682236,ci:1595166,xn:562144401219152,xi:18446735292041567566,e:753587310949187584
[   29.931755] big adj at -296326 (4294314460971008,1,1595166,1284562)
[   29.962006] clock tsc: m:4289462122,s:22,cl:47814797030,ci:1595166,xn:44026083828728,xi:18446735292043162732,e:1537505019520821248
[   29.993322] big adj at -296325 (4294314460971008,1,1595166,734154)
[   30.024732] clock tsc: m:4289462123,s:22,cl:47913697322,ci:1595166,xn:18207168308574885266,xi:18446735292044757898,e:2361282850206533632
[   30.057404] big adj at -296324 (4294314460971008,1,1595166,1013902)
[   30.090153] clock tsc: m:4289462124,s:22,cl:48015787946,ci:1595166,xn:17938170826129443784,xi:18446735292046353064,e:3211634054207305728
[   30.124811] Freeing unused kernel memory: 192k freed
[   30.158910] Write protecting the kernel read-only data: 402k
[   30.502924] unexpected nsec: -249310867,2962848525
[   30.534582] clock tsc: m:4289462438,s:22,cl:48778277294,ci:1595166,xn:15924728282382833372,xi:18446735292547235188,e:-8884147731732662272
[   30.567853] unexpected nsec: -1962978502,1374054342
[   30.601090] clock tsc: m:4289462436,s:22,cl:48885153416,ci:1595166,xn:15654512304741409624,xi:18446735292544044856,e:-7993970621383804928
[   78.648061] kjournald starting.  Commit interval 5 seconds
[   78.681141] EXT3-fs: mounted filesystem with ordered data mode.
[   79.511997] security:  6 users, 5 roles, 1965 types, 81 bools, 1 sens, 256 cats
[   79.544616] security:  58 classes, 123884 rules
[   79.579276] SELinux:  Completing initialization.
[   79.611956] SELinux:  Setting up existing superblocks.
[   79.677464] SELinux: initialized (dev dm-0, type ext3), uses xattr
[   79.829815] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[   79.863240] SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
[   79.896423] SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
[   79.929696] SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
[   79.963020] SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
[   79.996350] SELinux: initialized (dev devpts, type devpts), uses transition SIDs
[   80.028943] SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
[   80.061259] SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
[   80.093142] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[   80.124561] SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
[   80.155563] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
[   80.186435] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
[   80.216576] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[   80.245849] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
[   80.274340] SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
[   80.302334] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
[   80.332660] audit(1152066829.655:2): policy loaded auid=4294967295
[   80.360059] audit(1152066829.642:3): avc:  granted  { load_policy } for  pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security
[   81.871761] unexpected nsec: -1188339803,701954360
[   81.897554] clock tsc: m:1965639796,s:22,cl:130830426002,ci:1595166,xn:17365880163142832508,xi:18446741971357700448,e:-6392280673125578752
[  129.407146] Real Time Clock Driver v1.12ac



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-05  4:29                           ` Valdis.Kletnieks
@ 2006-07-06  0:37                             ` Roman Zippel
  2006-07-06  0:56                               ` john stultz
  2006-07-06  6:38                               ` Valdis.Kletnieks
  2006-07-06  0:51                             ` john stultz
  1 sibling, 2 replies; 93+ messages in thread
From: Roman Zippel @ 2006-07-06  0:37 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: john stultz, Andrew Morton, linux-kernel

Hi,

On Wed, 5 Jul 2006, Valdis.Kletnieks@vt.edu wrote:

> I'll bite - what *am* I using as a timesource for those first 4 seconds? :)

Jiffies and the first few adjustments are fine, it just compensates for 
the initial difference between NSEC_PER_JIFFY and TICK_NSEC.

> [   29.528533] Time: tsc clocksource has been installed.
> [   29.552855] clock changed at -296333 (4294314460971008)
> [   29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0
> [   29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712)
> [   29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936
> [   29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960)
> [   29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320

Ok, I see now the problem, the last cycle value is always at least 50 
times incremented between adjustments and that also means any error 
adjustment is applied at least 50 times, which quickly gets out of 
control.
Is it possible that your console output is really slow? Otherwise I can't 
explain these numbers, everything looks initialized fine for a 1.6GHz 
clock, but it seems to take ages to print a single line.
I have to run some tests and later this week there should be a new patch 
compensating for this.

John, now I also know why your version survived this, it did the error 
correction in the update loop, this kept error small, but it also caused 
the time to jump around, since it changed the multiplier in the past.

bye, Roman

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-05  4:29                           ` Valdis.Kletnieks
  2006-07-06  0:37                             ` Roman Zippel
@ 2006-07-06  0:51                             ` john stultz
  2006-07-06  1:12                               ` john stultz
  2006-07-06 20:33                               ` Roman Zippel
  1 sibling, 2 replies; 93+ messages in thread
From: john stultz @ 2006-07-06  0:51 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel

On Wed, 2006-07-05 at 00:29 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 03 Jul 2006 03:13:39 +0200, Roman Zippel said:
> > Hi,
> > 
> > On Fri, 30 Jun 2006, Valdis.Kletnieks@vt.edu wrote:
> > 
> > > *AHA* I *found* the bugger, I think.
> > > 
> > > In kernel/timer.c, we have:
> > > 
> > > static void clocksource_adjust(struct clocksource *clock, s64 offset)
> > > (s64 used for offset in multiple places).
> > > 
> > > However, in other places, offset is a 'cycle_t', which is:
> > > 
> > > include/linux/clocksource.h:typedef u64 cycle_t;
> > > 
> > > So it looks like a signed/unsigned screwage.
> > 
> > It's a possibility, but the signed/unsigned usage is pretty much 
> > intentional. The assumptation is that time only goes forward so nothing 
> > there should become negative, only adjustments happen in both directions.
> > It's really weird why it's getting completely so out of control early 
> > during boot. It would be great if you could also test the patch below, it 
> > should trigger closer to when it goes wrong and help to analyze the 
> > problem (or at least rule out a number of possibilities).
> 
> Here you go.. For what it's worth, your debugging in clocksource_adjust seems
> to only pop before we start userspace, and get_realtime_clock_ts only once
> userspace starts.

Once again, thanks for the testing! My observations below...

> The dmesg, with all the suggested patches so far applied.  Looks like something
> starts off uninitialized - we get the first 'big adj' squawk right after we
> allocate the console - we don't allocate the tsc timesource for another 4
> seconds or so.
> 
> I'll bite - what *am* I using as a timesource for those first 4 seconds? :)

The jiffies clocksource.

> [    0.000000] Detected 1595.408 MHz processor.
...
>[   24.322196] CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04
...
> [   29.528533] Time: tsc clocksource has been installed.
> [   29.552855] clock changed at -296333 (4294314460971008)
> [   29.577109] clock tsc: m:2628985,s:22,cl: ,ci:1595166,xn:0,xi:4193667486510,e:0

Ok, so here's our initial TSC state:

Verify the mult/shift pair:
2^s/m = 2^22/2628985 = 1.595408113777750729 cyc/ns => 1.595 GHz

Verify the cycle_interval/xtime_interval pair:
xi = ci*m = 1595166 * 2628985 = 4193667486510

Convert xi to ns:
xi>>s = 4193667486510>>22 = 999848.2433581352234 ns/interval

Convert ntp_tick to ns:
ntp_tick>>32 = 4294314460971008>>32 = 999848 ns/tick

Ok, that all looks pretty good...


> [   29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712)
> [   29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936

Now here's where things turn odd. Note that only one jiffy has passed
(-296332 - -296333 = 1).

However, looking at the difference between cycle_last:
47288392250 - 47171945132 = 116,447,118

That's *way* larger then the 1,595,166 value expected in ci!

Same thing is seen in the later data points:

47452694348 - 47368150550 = 84,543,798
47538833312 - 47452694348 = 86,138,964
etc.

So it seems either something is causing you to take interrupts at a
lower frequency then what is expected, or your cpu is ~50x faster then
advertised :)

This is probably not an issue w/ the timekeeping code, however as a
side-effect it appears to make the clocksource_adjust function oscillate
pretty severely. I've reproduced a similar hang (not completely sure, as
it occurred while X was loading) by adding the following to the top of
update_wall_time:

	static int droptick;
	if(droptick++%60)
		return;

Roman: While I'm not 100% confident about my assessment above, I worry
this is mimicking the problems I had been seeing in my simulator w/ your
clocksource_adjustment algorithm when I simulated dropping many ticks.
While currently this behavior points to some other problem, with the
dynticks patch, its much more likely that we will see 100s of ticks
skipped.

I quickly revived my P-D adjustment patch and it does not appear to
suffer from the same problem with the above droptick change (although
its only been lightly tested). 

I realize you may have a more trivial change to this issue, but would
you consider my method again?

Vladis: Mind trying the following patch to see if it affects the
behavior.

thanks
-john


Implement P-D control for clocksource_adjust()

diff --git a/kernel/timer.c b/kernel/timer.c
index 396a3c0..f4e7681 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1007,81 +1007,108 @@ static int __init timekeeping_init_devic
 
 device_initcall(timekeeping_init_device);
 
-/*
- * If the error is already larger, we look ahead another tick,
- * to compensate for late or lost adjustments.
- */
-static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset)
+static int error_aproximation(u64 error, u64 unit, int max)
 {
-	int adj;
-
-	/*
-	 * As soon as the machine is synchronized to the external time
-	 * source this should be the common case.
-	 */
-	error >>= 2;
-	if (likely(sign > 0 ? error <= *interval : error >= *interval))
-		return sign;
-
-	/*
-	 * An extra look ahead dampens the effect of the current error,
-	 * which can grow quite large with continously late updates, as
-	 * it would dominate the adjustment value and can lead to
-	 * oscillation.
-	 */
-	error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1);
-	error -= clock->xtime_interval >> 1;
-
-	adj = 0;
+	int adj = 0;
 	while (1) {
 		error >>= 1;
-		if (sign > 0 ? error <= *interval : error >= *interval)
-			break;
-		adj++;
+		if (error <= unit)
+			return adj;
+		if (!max || adj < max)
+			adj++;
 	}
-
-	/*
-	 * Add the current adjustments to the error and take the offset
-	 * into account, the latter can cause the error to be hardly
-	 * reduced at the next tick. Check the error again if there's
-	 * room for another adjustment, thus further reducing the error
-	 * which otherwise had to be corrected at the next update.
-	 */
-	error = (error << 1) - *interval + *offset;
-	if (sign > 0 ? error > *interval : error < *interval)
-		adj++;
-
-	*interval <<= adj;
-	*offset <<= adj;
-	return sign << adj;
 }
+#define MAXOFFADJ 4 /* vary max oscillation vs convergance speed */
 
 /*
  * Adjust the multiplier to reduce the error value,
  * this is optimized for the most common adjustments of -1,0,1,
  * for other values we can do a bit more work.
  */
-static void clocksource_adjust(struct clocksource *clock, s64 offset)
+static void clocksource_adjust(struct clocksource *clock, s64 offset,
+				s64 interval_cycs, s64 interval_error)
 {
 	s64 error, interval = clock->cycle_interval;
-	int adj;
-
-	error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1);
-	if (error > interval) {
-		adj = clocksource_bigadjust(1, error, &interval, &offset);
-	} else if (error < -interval) {
-		interval = -interval;
-		offset = -offset;
-		adj = clocksource_bigadjust(-1, error, &interval, &offset);
-	} else
-		return;
+	
+	error = shift_right(clock->error, (TICK_LENGTH_SHIFT - clock->shift));
+	interval_error = shift_right(interval_error, 
+					(TICK_LENGTH_SHIFT - clock->shift));
+
+	if ((error > interval)
+		||(error < -(interval)) ) {
+
+		int adj, multadj = 0;
+		s64 offset_update = 0, snsec_update = 0;
+		
+		/* First do the frequency adjustment:
+		 *   The idea here is to look at the error 
+		 *   accumulated since the last call to 
+		 *   update_wall_time to determine the 
+		 *   frequency adjustment needed so no new
+		 *   error will be incurred in the next
+		 *   interval.
+		 *
+		 *   This is basically derivative control
+		 *   using the PID terminology (we're calculating
+		 *   the derivative of the slope and correcting it).
+		 *
+		 *   The math is basically:
+		 *      multadj = interval_error/interval_cycles
+		 *   Which we fudge using binary approximation.
+		 */
+		if(interval_error >= 0) {
+			adj = error_aproximation(interval_error,
+						interval_cycs, 0);
+			multadj += 1 << adj;
+			snsec_update += interval << adj;
+			offset_update += offset << adj;
+		} else {
+			adj = error_aproximation(-interval_error, 
+						interval_cycs, 0);
+			multadj -= 1 << adj;
+			snsec_update -= interval << adj;
+			offset_update -= offset << adj;
+	        }
+		/* Now do the offset adjustment:
+		 *   Now that the frequncy is fixed, we
+		 *   want to look at the total error accumulated
+		 *   to move us back in sync using the same method.
+		 *   However, we must be careful as if we make too 
+		 *   sudden an adjustment we might overshoot. So we 
+		 *   limit the amount of change to spread the 
+		 *   adjustment (using MAXOFFADJ) over a longer 
+		 *   period of time.
+		 *
+		 *   This is basically proportional control
+		 *   using the PID terminology.
+		 *
+		 *   We use interval_cycs here as the divisor, which
+		 *   hopes that the next sample will be similar in 
+		 *   distance from the last.
+		 */
+		if(error >= 0) {
+			adj = error_aproximation(error, 
+					interval_cycs, MAXOFFADJ);
+			multadj += 1<<adj;
+			snsec_update += interval <<adj;
+			offset_update += offset << adj;
+		} else {
+			adj = error_aproximation(-error,
+						interval_cycs, MAXOFFADJ);
+			multadj -= 1<<adj;
+			snsec_update -= interval <<adj;
+			offset_update -= offset << adj;
+		}
 
-	clock->mult += adj;
-	clock->xtime_interval += interval;
-	clock->xtime_nsec -= offset;
-	clock->error -= (interval - offset) << (TICK_LENGTH_SHIFT - clock->shift);
+		clock->mult += multadj;
+		clock->xtime_interval += snsec_update;
+		clock->xtime_nsec -= offset_update;
+		clock->error += (offset_update) 
+					<< (TICK_LENGTH_SHIFT - clock->shift);
+	}
 }
 
+
 /*
  * update_wall_time - Uses the current clocksource to increment the wall time
  *
@@ -1089,7 +1116,8 @@ static void clocksource_adjust(struct cl
  */
 static void update_wall_time(void)
 {
-	cycle_t offset;
+	cycle_t offset, interval_cycs = 0;
+	s64 interval_error = 0; 
 
 	clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift;
 
@@ -1106,8 +1134,13 @@ static void update_wall_time(void)
 		/* accumulate one interval */
 		clock->xtime_nsec += clock->xtime_interval;
 		clock->cycle_last += clock->cycle_interval;
+		interval_cycs += clock->cycle_interval;
 		offset -= clock->cycle_interval;
 
+		/* accumulate error between NTP and clock interval */
+		interval_error += current_tick_length();
+		interval_error -= clock->xtime_interval << (TICK_LENGTH_SHIFT - clock->shift);
+
 		if (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
 			clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
 			xtime.tv_sec++;
@@ -1119,14 +1152,10 @@ static void update_wall_time(void)
 						>> clock->shift);
 		/* increment the NTP state machine */
 		update_ntp_one_tick();
-
-		/* accumulate error between NTP and clock interval */
-		clock->error += current_tick_length();
-		clock->error -= clock->xtime_interval << (TICK_LENGTH_SHIFT - clock->shift);
 	}
-
+	clock->error += interval_error;
 	/* correct the clock when NTP error is too big */
-	clocksource_adjust(clock, offset);
+	clocksource_adjust(clock, offset, interval_cycs, interval_error);
 
 	/* store full nanoseconds into xtime */
 	xtime.tv_nsec = clock->xtime_nsec >> clock->shift;



^ permalink raw reply related	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06  0:37                             ` Roman Zippel
@ 2006-07-06  0:56                               ` john stultz
  2006-07-06  6:38                               ` Valdis.Kletnieks
  1 sibling, 0 replies; 93+ messages in thread
From: john stultz @ 2006-07-06  0:56 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

On Thu, 2006-07-06 at 02:37 +0200, Roman Zippel wrote:
> Hi,
> 
> On Wed, 5 Jul 2006, Valdis.Kletnieks@vt.edu wrote:
> > [   29.528533] Time: tsc clocksource has been installed.
> > [   29.552855] clock changed at -296333 (4294314460971008)
> > [   29.577109] clock tsc: m:2628985,s:22,cl:47171945132,ci:1595166,xn:0,xi:4193667486510,e:0
> > [   29.601869] big adj at -296332 (4294314460971008,-16,-25522656,-11031712)
> > [   29.626688] clock tsc: m:2628985,s:22,cl:47288392250,ci:1595166,xn:148610636380190,xi:4193667486510,e:-76300711936
> > [   29.652263] big adj at -296331 (4294314460971008,512,816724992,737704960)
> > [   29.677968] clock tsc: m:2628969,s:22,cl:47368150550,ci:1595166,xn:358292745604602,xi:4193641963854,e:1193037240320
> 
> Ok, I see now the problem, the last cycle value is always at least 50 
> times incremented between adjustments and that also means any error 
> adjustment is applied at least 50 times, which quickly gets out of 
> control.
> Is it possible that your console output is really slow? Otherwise I can't 
> explain these numbers, everything looks initialized fine for a 1.6GHz 
> clock, but it seems to take ages to print a single line.

Dang! You beat me to the analysis :)  I think we're on the same page
here.


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

Look forward to it.

> John, now I also know why your version survived this, it did the error 
> correction in the update loop, this kept error small, but it also caused 
> the time to jump around, since it changed the multiplier in the past.

Yep, agreed.

thanks
-john


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06  0:51                             ` john stultz
@ 2006-07-06  1:12                               ` john stultz
  2006-07-06  5:43                                 ` john stultz
  2006-07-06 20:33                               ` Roman Zippel
  1 sibling, 1 reply; 93+ messages in thread
From: john stultz @ 2006-07-06  1:12 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel

On Wed, 2006-07-05 at 17:51 -0700, john stultz wrote:
> I quickly revived my P-D adjustment patch and it does not appear to
> suffer from the same problem with the above droptick change (although
> its only been lightly tested). 
> 
> I realize you may have a more trivial change to this issue, but would
> you consider my method again?
> 
> Vladis: Mind trying the following patch to see if it affects the
> behavior.

Bah! Never mind. Don't bother, trying it.

Of course, only after I send the mail, the same problem reproduces
itself w/ my patch!

grumble.
-john


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06  1:12                               ` john stultz
@ 2006-07-06  5:43                                 ` john stultz
  0 siblings, 0 replies; 93+ messages in thread
From: john stultz @ 2006-07-06  5:43 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Roman Zippel, Andrew Morton, linux-kernel

On Wed, 2006-07-05 at 18:12 -0700, john stultz wrote:
> On Wed, 2006-07-05 at 17:51 -0700, john stultz wrote:
> > I quickly revived my P-D adjustment patch and it does not appear to
> > suffer from the same problem with the above droptick change (although
> > its only been lightly tested). 
> > 
> > I realize you may have a more trivial change to this issue, but would
> > you consider my method again?
> > 
> > Vladis: Mind trying the following patch to see if it affects the
> > behavior.
> 
> Bah! Never mind. Don't bother, trying it.

I take that back. :)

Vladis, would you still try that patch to see if it helps?


> Of course, only after I send the mail, the same problem reproduces
> itself w/ my patch!

In my rush to finish up for dinner, I fat-fingered the droptick code
(forgot the static!) so I wasn't ever get timer ticks. :(

Then after I fixed that, I noticed long-ish stalls starting X or
switching between X and VT consoles. However after digging into it I
realized the issue is that xtime is only being updated every 100 ticks,
and nanosleep used xtime (via hrtimers), so it was getting the extra
100tick latency on every call.

So just to be fair, I double checked the following patch against
mainline, saw the hang Vladis was seeing, then applied it to my earlier
patch along with this patch and the system booted fine w/ no stalls.

thanks
-john


Patch to trigger the boot hang against vanilla 2.6.18-rc1

diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index d17766d..3f516f6 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -132,7 +132,7 @@ static void hrtimer_get_softirq_time(str
 
 	do {
 		seq = read_seqbegin(&xtime_lock);
-		xtim = timespec_to_ktime(xtime);
+		xtim = ktime_get_real();
 		tomono = timespec_to_ktime(wall_to_monotonic);
 
 	} while (read_seqretry(&xtime_lock, seq));
diff --git a/kernel/timer.c b/kernel/timer.c
index 396a3c0..5394104 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1090,6 +1090,9 @@ static void clocksource_adjust(struct cl
 static void update_wall_time(void)
 {
 	cycle_t offset;
+	static int droptick;
+	if(droptick++%100)
+		return;
 
 	clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift;
 



^ permalink raw reply related	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06  0:37                             ` Roman Zippel
  2006-07-06  0:56                               ` john stultz
@ 2006-07-06  6:38                               ` Valdis.Kletnieks
  1 sibling, 0 replies; 93+ messages in thread
From: Valdis.Kletnieks @ 2006-07-06  6:38 UTC (permalink / raw)
  To: Roman Zippel; +Cc: john stultz, Andrew Morton, linux-kernel

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

On Thu, 06 Jul 2006 02:37:25 +0200, Roman Zippel said:

> Ok, I see now the problem, the last cycle value is always at least 50 
> times incremented between adjustments and that also means any error 
> adjustment is applied at least 50 times, which quickly gets out of 
> control.
> Is it possible that your console output is really slow? Otherwise I can't 
> explain these numbers, everything looks initialized fine for a 1.6GHz 
> clock, but it seems to take ages to print a single line.

Oh.. this is a real Homer Simpson moment.... "D'Oh!" :)

The grub definition:

title 2.6.17-mm2 testing
        kernel /vmlinuz-2.6.17-mm2-test single console=tty0 vga=794
        initrd /initrd-selinux.img

Yes, this laptop has a real actual DB-9 serial port on the back, and I've had
it defined as a console for forever (since trying to debug a problem against
2.5.60 or so).  So maybe that's where it's coming from.  But a quick boot
test or 3 shows the console=tty0 isn't the problem.  It turns out to be
the 'vga=794', which selects this mode:

[   16.633604] Console: colour dummy device 80x25
[   17.685983] Console: switching to colour frame buffer device 160x64

And we promptly get a timing problem.  I tried booting with 'vga=ask' and
choosing mode 1, and got this mode instead:

[   31.003715] Console: colour VGA+ 80x50

And things came up fine at that point.  Apparently, trying to scroll a big
160x64 is sufficiently slower than scrolling an 80x50 to trigger the problem.

I'd look at John's patch in the morning:

> Implement P-D control for clocksource_adjust()

> diff --git a/kernel/timer.c b/kernel/timer.c
> index 396a3c0..f4e7681 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -1007,81 +1007,108 @@ static int __init timekeeping_init_devic

Too many 2:30AM's in the past 2 weeks for a guy my age.. (Actually, the
2:30AM isn't the problem - it's the office hours 7 hours later. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06  0:51                             ` john stultz
  2006-07-06  1:12                               ` john stultz
@ 2006-07-06 20:33                               ` Roman Zippel
  2006-07-06 22:05                                 ` john stultz
  1 sibling, 1 reply; 93+ messages in thread
From: Roman Zippel @ 2006-07-06 20:33 UTC (permalink / raw)
  To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

Hi,

On Wed, 5 Jul 2006, john stultz wrote:

> Roman: While I'm not 100% confident about my assessment above, I worry
> this is mimicking the problems I had been seeing in my simulator w/ your
> clocksource_adjustment algorithm when I simulated dropping many ticks.
> While currently this behavior points to some other problem, with the
> dynticks patch, its much more likely that we will see 100s of ticks
> skipped.
> 
> I quickly revived my P-D adjustment patch and it does not appear to
> suffer from the same problem with the above droptick change (although
> its only been lightly tested). 

The PID concept had me confused for a while and I'm still not sure it 
really applies, but there are similarities and what I want to do is not 
that different from yours (limiting then the effect of the current error) 
with the biggest difference that I keep everything in the big adjust 
function, so the extra work is only done when needed.

> +		int adj, multadj = 0;
> +		s64 offset_update = 0, snsec_update = 0;
> +		
> +		/* First do the frequency adjustment:
> +		 *   The idea here is to look at the error 
> +		 *   accumulated since the last call to 
> +		 *   update_wall_time to determine the 
> +		 *   frequency adjustment needed so no new
> +		 *   error will be incurred in the next
> +		 *   interval.
> +		 *
> +		 *   This is basically derivative control
> +		 *   using the PID terminology (we're calculating
> +		 *   the derivative of the slope and correcting it).
> +		 *
> +		 *   The math is basically:
> +		 *      multadj = interval_error/interval_cycles
> +		 *   Which we fudge using binary approximation.
> +		 */
> +		if(interval_error >= 0) {
> +			adj = error_aproximation(interval_error,
> +						interval_cycs, 0);
> +			multadj += 1 << adj;
> +			snsec_update += interval << adj;
> +			offset_update += offset << adj;
> +		} else {
> +			adj = error_aproximation(-interval_error, 
> +						interval_cycs, 0);
> +			multadj -= 1 << adj;
> +			snsec_update -= interval << adj;
> +			offset_update -= offset << adj;
> +	        }

Here we actually don't derive very much, we already know how it will 
change. :)
We basically want to keep the difference between tick length and xtime 
interval as small as possible. Since most of the difference comes via 
second_overflow(), we might want to do some precalculations near there, so 
we avoid accumulating a lot of error in the first place, this is 
especially important with only rare updates.

> +		/* Now do the offset adjustment:
> +		 *   Now that the frequncy is fixed, we
> +		 *   want to look at the total error accumulated
> +		 *   to move us back in sync using the same method.
> +		 *   However, we must be careful as if we make too 
> +		 *   sudden an adjustment we might overshoot. So we 
> +		 *   limit the amount of change to spread the 
> +		 *   adjustment (using MAXOFFADJ) over a longer 
> +		 *   period of time.
> +		 *
> +		 *   This is basically proportional control
> +		 *   using the PID terminology.
> +		 *
> +		 *   We use interval_cycs here as the divisor, which
> +		 *   hopes that the next sample will be similar in 
> +		 *   distance from the last.
> +		 */
> +		if(error >= 0) {
> +			adj = error_aproximation(error, 
> +					interval_cycs, MAXOFFADJ);
> +			multadj += 1<<adj;
> +			snsec_update += interval <<adj;
> +			offset_update += offset << adj;
> +		} else {
> +			adj = error_aproximation(-error,
> +						interval_cycs, MAXOFFADJ);
> +			multadj -= 1<<adj;
> +			snsec_update -= interval <<adj;
> +			offset_update -= offset << adj;
> +		}

The limitation avoids the biggest problems, but it also may slow down the 
error reduction (the more the bigger the shift value is). The main problem 
is really that we don't know how many ticks will be skipped and with 
interval_cycs you only know what happened last and this won't help if 
ticks are skipped in irregular intervals.
Regarding dynticks it would help a lot here to know how many ticks are 
skipped so you can spread the error correction evenly over this period 
until the next adjustment and the correction is stopped in time.

bye, Roman

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06 20:33                               ` Roman Zippel
@ 2006-07-06 22:05                                 ` john stultz
  2006-07-07 23:16                                   ` Roman Zippel
  2006-07-08 20:02                                   ` [PATCH] adjust clock for lost ticks Roman Zippel
  0 siblings, 2 replies; 93+ messages in thread
From: john stultz @ 2006-07-06 22:05 UTC (permalink / raw)
  To: Roman Zippel; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel

On Thu, 2006-07-06 at 22:33 +0200, Roman Zippel wrote:
> Hi,
> 
> On Wed, 5 Jul 2006, john stultz wrote:
> 
> > Roman: While I'm not 100% confident about my assessment above, I worry
> > this is mimicking the problems I had been seeing in my simulator w/ your
> > clocksource_adjustment algorithm when I simulated dropping many ticks.
> > While currently this behavior points to some other problem, with the
> > dynticks patch, its much more likely that we will see 100s of ticks
> > skipped.
> > 
> > I quickly revived my P-D adjustment patch and it does not appear to
> > suffer from the same problem with the above droptick change (although
> > its only been lightly tested). 
> 
> The PID concept had me confused for a while and I'm still not sure it 
> really applies, but there are similarities and what I want to do is not 
> that different from yours (limiting then the effect of the current error) 
> with the biggest difference that I keep everything in the big adjust 
> function, so the extra work is only done when needed.

Yea. I've been trying to map your method to the PID concept as well
(when all you have is a hammer... ;) and they are similar, however the
"future error" aspect of yours makes it a little more difficult to
grasp, but it is more compact.


> > +		int adj, multadj = 0;
> > +		s64 offset_update = 0, snsec_update = 0;
> > +		
> > +		/* First do the frequency adjustment:
> > +		 *   The idea here is to look at the error 
> > +		 *   accumulated since the last call to 
> > +		 *   update_wall_time to determine the 
> > +		 *   frequency adjustment needed so no new
> > +		 *   error will be incurred in the next
> > +		 *   interval.
> > +		 *
> > +		 *   This is basically derivative control
> > +		 *   using the PID terminology (we're calculating
> > +		 *   the derivative of the slope and correcting it).
> > +		 *
> > +		 *   The math is basically:
> > +		 *      multadj = interval_error/interval_cycles
> > +		 *   Which we fudge using binary approximation.
> > +		 */
> > +		if(interval_error >= 0) {
> > +			adj = error_aproximation(interval_error,
> > +						interval_cycs, 0);
> > +			multadj += 1 << adj;
> > +			snsec_update += interval << adj;
> > +			offset_update += offset << adj;
> > +		} else {
> > +			adj = error_aproximation(-interval_error, 
> > +						interval_cycs, 0);
> > +			multadj -= 1 << adj;
> > +			snsec_update -= interval << adj;
> > +			offset_update -= offset << adj;
> > +	        }
> 
> Here we actually don't derive very much, we already know how it will 
> change. :)

Correct, by looking one step ahead in your method that's where you're
taking the derivative into effect. Although keeping this future
reference does require some extra mental gymnastics for me.

> We basically want to keep the difference between tick length and xtime 
> interval as small as possible. Since most of the difference comes via 
> second_overflow(), we might want to do some precalculations near there, so 
> we avoid accumulating a lot of error in the first place, this is 
> especially important with only rare updates.

I don't think I disagree here, I can see how looking ahead in the future
is helpful to correct for error when the adjustment changes.

> > +		/* Now do the offset adjustment:
> > +		 *   Now that the frequncy is fixed, we
> > +		 *   want to look at the total error accumulated
> > +		 *   to move us back in sync using the same method.
> > +		 *   However, we must be careful as if we make too 
> > +		 *   sudden an adjustment we might overshoot. So we 
> > +		 *   limit the amount of change to spread the 
> > +		 *   adjustment (using MAXOFFADJ) over a longer 
> > +		 *   period of time.
> > +		 *
> > +		 *   This is basically proportional control
> > +		 *   using the PID terminology.
> > +		 *
> > +		 *   We use interval_cycs here as the divisor, which
> > +		 *   hopes that the next sample will be similar in 
> > +		 *   distance from the last.
> > +		 */
> > +		if(error >= 0) {
> > +			adj = error_aproximation(error, 
> > +					interval_cycs, MAXOFFADJ);
> > +			multadj += 1<<adj;
> > +			snsec_update += interval <<adj;
> > +			offset_update += offset << adj;
> > +		} else {
> > +			adj = error_aproximation(-error,
> > +						interval_cycs, MAXOFFADJ);
> > +			multadj -= 1<<adj;
> > +			snsec_update -= interval <<adj;
> > +			offset_update -= offset << adj;
> > +		}
> 
> The limitation avoids the biggest problems, but it also may slow down the 
> error reduction (the more the bigger the shift value is). The main problem 
> is really that we don't know how many ticks will be skipped and with 
> interval_cycs you only know what happened last and this won't help if 
> ticks are skipped in irregular intervals.

I think one of the important parts of my method is that I've broken up
the error into two different types of error, that can be manipulated
independently:

1) Error accumulated in the last period - the derivative part.
2) Total error - the proportional part.

Taking component #1, we directly correct the frequency to flatten the
error slope so in the next tick we should not accumulate any *extra*
error (ideally, of course, since our granularity won't quite allow for
that). Note that there is no "gain" (using the PID terminology) in that
sense being applied. Its just an absolute frequency correction.

Then taking component #2, if we calculated error/interval that would be
the ideal correction to the proportional component for the next tick.
However since we don't know when the next tick will occur, we use two
methods to dampen the effect to avoid overshoot: a) Use the value
interval/interval_cycs as our "gain" factor, thus if ticks are being
lost, we assume will will continue to lose ticks. You are correct here
in that irregular tick skipping could defeat this, but if a constant
gain factor (of say, 1<<8) was used, we would have a hard time
converging because the error/(interval*gain) would goto zero early. 

So instead, keeping the non-constant gain in (a), we use b) a limiter
(MAXOFFADJ) so any proportional change is very dampened. This does have
the effect that any large error takes awhile to reduce, but since we
correct the recent (derivative error) directly, we should not be
accumulating more.

The combination of these two effects allows us to converge reasonably
quickly when we are not skipping ticks, and controls overshoot when we
are skipping ticks (proportionally to the number of ticks skipped).


> Regarding dynticks it would help a lot here to know how many ticks are 
> skipped so you can spread the error correction evenly over this period 
> until the next adjustment and the correction is stopped in time.

I've considered alternatives, where we use a constant gain with the
proportional component (so any proportional change would be spread over
one second), but to avoid constant offsets when the total error was
smaller then the gain factor, we could also calculate a non-gain'ed
adjustment w/ a limiter and include that. This would be more ideal in
your irregular ticks example, but I'm not sure its really that much more
beneficial from what I proposed.

Anyway, I'm interested in what you are thinking for a more minimal
approach to what we have in mainline, since I have a harder time
wrapping my head around the future-error part (I can intuit what you
want to accomplish, and I understand the benefit of looking ahead, but I
just haven't been able to work out a proof for it :).

thanks
-john


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2 hrtimer code wedges at boot?
  2006-07-06 22:05                                 ` john stultz
@ 2006-07-07 23:16                                   ` Roman Zippel
  2006-07-08 20:02                                   ` [PATCH] adjust clock for lost ticks Roman Zippel
  1 sibling, 0 replies; 93+ messages in thread
From: Roman Zippel @ 2006-07-07 23:16 UTC (permalink / raw)
  To: john stultz; +Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Uwe Bugla

Hi,

On Thu, 6 Jul 2006, john stultz wrote:

> Yea. I've been trying to map your method to the PID concept as well
> (when all you have is a hammer... ;) and they are similar, however the
> "future error" aspect of yours makes it a little more difficult to
> grasp, but it is more compact.

Let's take a different example model - let's take two cars, where one car 
tries to follow the other, but it's limited in how it can change the speed 
(and sometimes the driver also falls asleep :) ).
First we want to match of course the speed of both cars, so that the 
distance between the cars increases as little as possible over time. 
Second we want to decrease the distance between the cars. The problem is 
to stop the correction when the distance is near zero, which is simple 
when we know the next time, we can change the speed, but if we miss the 
point we overshoot and the distance grows again.
It's possible to keep these two parameters separate, but it's actually 
simpler to look at them together, by simply looking some time ahead and 
calculate the position of the car at this time and thus the speed of the 
other car to reach this position.

The adjustment code basically does just this by using the difference in 
speed to calculate the upcoming error. The new patch now uses the current 
error to decide by how much to look ahead, basically if we already have a 
large error, we have to be more careful, but overshooting with a small 
adjustment doesn't do much harm.
In the patch below I left some debug prints, which are useful to check how 
good the error adjustment works. It should be close to the final version 
(minus the prints and plus some more comments).

> > Regarding dynticks it would help a lot here to know how many ticks are 
> > skipped so you can spread the error correction evenly over this period 
> > until the next adjustment and the correction is stopped in time.
> 
> I've considered alternatives, where we use a constant gain with the
> proportional component (so any proportional change would be spread over
> one second), but to avoid constant offsets when the total error was
> smaller then the gain factor, we could also calculate a non-gain'ed
> adjustment w/ a limiter and include that. This would be more ideal in
> your irregular ticks example, but I'm not sure its really that much more
> beneficial from what I proposed.

The problem is we have conflicting goals, adjusting for an unknown number 
of lost ticks is bad for precise timekeeping. I prefer to assume that lost 
ticks are the exceptions and we need the help from the dynticks code to 
assure precise timekeeping.

bye, Roman


---
 kernel/timer.c |   89 +++++++++++++++++++++++++++++++++++----------------------
 1 file changed, 56 insertions(+), 33 deletions(-)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-07-07 02:51:57.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-07-07 23:58:47.000000000 +0200
@@ -1013,15 +1013,9 @@ device_initcall(timekeeping_init_device)
  */
 static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset)
 {
-	int adj;
+	s64 e, i;
+	int adj, mult;
 
-	/*
-	 * As soon as the machine is synchronized to the external time
-	 * source this should be the common case.
-	 */
-	error >>= 2;
-	if (likely(sign > 0 ? error <= *interval : error >= *interval))
-		return sign;
 
 	/*
 	 * An extra look ahead dampens the effect of the current error,
@@ -1029,33 +1023,41 @@ static __always_inline int clocksource_b
 	 * it would dominate the adjustment value and can lead to
 	 * oscillation.
 	 */
-	error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1);
-	error -= clock->xtime_interval >> 1;
-
-	adj = 0;
-	while (1) {
-		error >>= 1;
-		if (sign > 0 ? error <= *interval : error >= *interval)
-			break;
-		adj++;
+	e = (sign > 0 ? clock->error : -clock->error) >> (TICK_LENGTH_SHIFT + 20 - 2 * SHIFT_HZ);
+	for (adj = 0; (e >>= 2) > 0; adj++)
+		;
+	error >>= adj;
+	e = current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift);
+	e -= clock->xtime_interval;
+	error += e;
+	error -= e >> (adj + 1);
+
+	i = *interval;
+	mult = 1;
+	if (error < 0) {
+		error = -error;
+		*interval = -*interval;
+		*offset = -*offset;
+		mult = -1;
+	}
+
+	if (error <= i) {
+		*interval = 0;
+		*offset = 0;
+		return 0;
 	}
 
-	/*
-	 * Add the current adjustments to the error and take the offset
-	 * into account, the latter can cause the error to be hardly
-	 * reduced at the next tick. Check the error again if there's
-	 * room for another adjustment, thus further reducing the error
-	 * which otherwise had to be corrected at the next update.
-	 */
-	error = (error << 1) - *interval + *offset;
-	if (sign > 0 ? error > *interval : error < *interval)
-		adj++;
+	for (adj = 0; (error >>= 1) > i; adj++)
+		;
 
 	*interval <<= adj;
 	*offset <<= adj;
-	return sign << adj;
+	return mult << adj;
 }
 
+static unsigned long next_print = INITIAL_JIFFIES;
+static int big_cnt, one_cnt, zero_cnt;
+
 /*
  * Adjust the multiplier to reduce the error value,
  * this is optimized for the most common adjustments of -1,0,1,
@@ -1066,15 +1068,36 @@ static void clocksource_adjust(struct cl
 	s64 error, interval = clock->cycle_interval;
 	int adj;
 
+	if (time_after(jiffies, next_print)) {
+		printk("adj: %d,%d,%d\n", zero_cnt, one_cnt, big_cnt);
+		zero_cnt = one_cnt = big_cnt = 0;
+		next_print = jiffies + 10 * HZ;
+	}
 	error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1);
 	if (error > interval) {
-		adj = clocksource_bigadjust(1, error, &interval, &offset);
+		error >>= 2;
+		if (likely(error <= interval)) {
+			one_cnt++;
+			adj = 1;
+		} else {
+			big_cnt++;
+			adj = clocksource_bigadjust(1, error, &interval, &offset);
+		}
 	} else if (error < -interval) {
-		interval = -interval;
-		offset = -offset;
-		adj = clocksource_bigadjust(-1, error, &interval, &offset);
-	} else
+		error >>= 2;
+		if (likely(error >= -interval)) {
+			one_cnt++;
+			adj = -1;
+			interval = -interval;
+			offset = -offset;
+		} else {
+			big_cnt++;
+			adj = clocksource_bigadjust(-1, error, &interval, &offset);
+		}
+	} else {
+		zero_cnt++;
 		return;
+	}
 
 	clock->mult += adj;
 	clock->xtime_interval += interval;

^ permalink raw reply	[flat|nested] 93+ messages in thread

* [PATCH] adjust clock for lost ticks
  2006-07-06 22:05                                 ` john stultz
  2006-07-07 23:16                                   ` Roman Zippel
@ 2006-07-08 20:02                                   ` Roman Zippel
  2006-07-09 21:25                                     ` john stultz
  1 sibling, 1 reply; 93+ messages in thread
From: Roman Zippel @ 2006-07-08 20:02 UTC (permalink / raw)
  To: john stultz
  Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Uwe Bugla,
	James Bottomley


A large number of lost ticks can cause an overadjustment of the clock.
To compensate for this we look at the current error and the larger the
error already is the more careful we are at adjusting the error.
As small extra fix reset the error when the clock is set.

Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

---
 kernel/timer.c |   85 +++++++++++++++++++++++++++++++--------------------------
 1 file changed, 47 insertions(+), 38 deletions(-)

Index: linux-2.6-mm/kernel/timer.c
===================================================================
--- linux-2.6-mm.orig/kernel/timer.c	2006-07-07 02:51:57.000000000 +0200
+++ linux-2.6-mm/kernel/timer.c	2006-07-08 19:10:52.000000000 +0200
@@ -891,6 +891,7 @@ int do_settimeofday(struct timespec *tv)
 	set_normalized_timespec(&xtime, sec, nsec);
 	set_normalized_timespec(&wall_to_monotonic, wtm_sec, wtm_nsec);
 
+	clock->error = 0;
 	ntp_clear();
 
 	write_sequnlock_irqrestore(&xtime_lock, flags);
@@ -1008,52 +1009,52 @@ static int __init timekeeping_init_devic
 device_initcall(timekeeping_init_device);
 
 /*
- * If the error is already larger, we look ahead another tick,
+ * If the error is already larger, we look ahead even further
  * to compensate for late or lost adjustments.
  */
-static __always_inline int clocksource_bigadjust(int sign, s64 error, s64 *interval, s64 *offset)
+static __always_inline int clocksource_bigadjust(s64 error, s64 *interval, s64 *offset)
 {
-	int adj;
+	s64 tick_error, i;
+	u32 look_ahead, adj;
+	s32 error2, mult;
 
 	/*
-	 * As soon as the machine is synchronized to the external time
-	 * source this should be the common case.
+	 * Use the current error value to determine how much to look ahead.
+	 * The larger the error the slower we adjust for it to avoid problems
+	 * with losing too many ticks, otherwise we would overadjust and
+	 * produce an even larger error.  The smaller the adjustment the
+	 * faster we try to adjust for it, as lost ticks can do less harm
+	 * here.  This is tuned so that an error of about 1 msec is adusted
+	 * within about 1 sec (or 2^20 nsec in 2^SHIFT_HZ ticks).
 	 */
-	error >>= 2;
-	if (likely(sign > 0 ? error <= *interval : error >= *interval))
-		return sign;
+	error2 = clock->error >> (TICK_LENGTH_SHIFT + 22 - 2 * SHIFT_HZ);
+	error2 = abs(error2);
+	for (look_ahead = 0; error2 > 0; look_ahead++)
+		error2 >>= 2;
 
 	/*
-	 * An extra look ahead dampens the effect of the current error,
-	 * which can grow quite large with continously late updates, as
-	 * it would dominate the adjustment value and can lead to
-	 * oscillation.
+	 * Now calculate the error in (1 << look_ahead) ticks, but first
+	 * remove the single look ahead already included in the error.
 	 */
-	error += current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1);
-	error -= clock->xtime_interval >> 1;
-
-	adj = 0;
-	while (1) {
-		error >>= 1;
-		if (sign > 0 ? error <= *interval : error >= *interval)
-			break;
-		adj++;
+	tick_error = current_tick_length() >> (TICK_LENGTH_SHIFT - clock->shift + 1);
+	tick_error -= clock->xtime_interval >> 1;
+	error = ((error - tick_error) >> look_ahead) + tick_error;
+
+	/* Finally calculate the adjustment shift value.  */
+	i = *interval;
+	mult = 1;
+	if (error < 0) {
+		error = -error;
+		*interval = -*interval;
+		*offset = -*offset;
+		mult = -1;
 	}
-
-	/*
-	 * Add the current adjustments to the error and take the offset
-	 * into account, the latter can cause the error to be hardly
-	 * reduced at the next tick. Check the error again if there's
-	 * room for another adjustment, thus further reducing the error
-	 * which otherwise had to be corrected at the next update.
-	 */
-	error = (error << 1) - *interval + *offset;
-	if (sign > 0 ? error > *interval : error < *interval)
-		adj++;
+	for (adj = 0; error > i; adj++)
+		error >>= 1;
 
 	*interval <<= adj;
 	*offset <<= adj;
-	return sign << adj;
+	return mult << adj;
 }
 
 /*
@@ -1068,11 +1069,19 @@ static void clocksource_adjust(struct cl
 
 	error = clock->error >> (TICK_LENGTH_SHIFT - clock->shift - 1);
 	if (error > interval) {
-		adj = clocksource_bigadjust(1, error, &interval, &offset);
+		error >>= 2;
+		if (likely(error <= interval))
+			adj = 1;
+		else
+			adj = clocksource_bigadjust(error, &interval, &offset);
 	} else if (error < -interval) {
-		interval = -interval;
-		offset = -offset;
-		adj = clocksource_bigadjust(-1, error, &interval, &offset);
+		error >>= 2;
+		if (likely(error >= -interval)) {
+			adj = -1;
+			interval = -interval;
+			offset = -offset;
+		} else
+			adj = clocksource_bigadjust(error, &interval, &offset);
 	} else
 		return;
 
@@ -1129,7 +1138,7 @@ static void update_wall_time(void)
 	clocksource_adjust(clock, offset);
 
 	/* store full nanoseconds into xtime */
-	xtime.tv_nsec = clock->xtime_nsec >> clock->shift;
+	xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift;
 	clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift;
 
 	/* check to see if there is a new clocksource to use */

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: [PATCH] adjust clock for lost ticks
  2006-07-08 20:02                                   ` [PATCH] adjust clock for lost ticks Roman Zippel
@ 2006-07-09 21:25                                     ` john stultz
  0 siblings, 0 replies; 93+ messages in thread
From: john stultz @ 2006-07-09 21:25 UTC (permalink / raw)
  To: Roman Zippel
  Cc: Valdis.Kletnieks, Andrew Morton, linux-kernel, Uwe Bugla,
	James Bottomley

On Sat, 2006-07-08 at 22:02 +0200, Roman Zippel wrote:
> A large number of lost ticks can cause an overadjustment of the clock.
> To compensate for this we look at the current error and the larger the
> error already is the more careful we are at adjusting the error.
> As small extra fix reset the error when the clock is set.
> 
> Signed-off-by: Roman Zippel <zippel@linux-m68k.org>

Roman, 
	Spent the weekend testing this, dropping 99/100 ticks, and was able to
hold decent sync w/ ntpd. Also the softlockup hang appears resolved as
well (confirmed by Vladis). Thanks for sending this out.

I know its already in -mm, but:
Acked-by: John Stultz <johnstul@us.ibm.com>

-john


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 19:36             ` 2.6.17-mm2 Martin Bligh
@ 2006-06-29  0:17               ` Martin J. Bligh
  0 siblings, 0 replies; 93+ messages in thread
From: Martin J. Bligh @ 2006-06-29  0:17 UTC (permalink / raw)
  To: Martin Bligh
  Cc: Andrew Morton, mbligh, jeremy, linux-kernel, apw, linuxppc64-dev,
	drfickle

Martin Bligh wrote:
>>> How the hell did you figure that one out?
>>
>>
>> Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a
>> tight loop.  With that happening, a little two-way wasn't able to make
>> it through `dbench 4' without soiling the upholstery.  Then 
>> bisection-searching.
> 
> 
> Aha. we probably trigger it because the automated test harness dumps a
> bunch of crap out of /proc before and after running dbench then ;-)

OK, your patch does seem to fix it for the automated tests. Not 100%
reliable, since it was a little intermittent before, but it looks
good.

Thanks to both Andrew and Andy.

M.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 19:22             ` 2.6.17-mm2 Jeremy Fitzhardinge
@ 2006-06-28 19:49               ` Andrew Morton
  0 siblings, 0 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-28 19:49 UTC (permalink / raw)
  To: Jeremy Fitzhardinge
  Cc: mbligh, mbligh, linux-kernel, apw, linuxppc64-dev, drfickle

On Wed, 28 Jun 2006 12:22:02 -0700
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Andrew Morton wrote:
> > Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a
> > tight loop.  With that happening, a little two-way wasn't able to make
> > it through `dbench 4' without soiling the upholstery.  Then bisection-searching.
> >   
> It's surprising it was so subtle.  I'd been running with that code for a 
> month or so without a peep of problem...
> 

It'll only bite if someone does snprintf() into a too-short buffer.  That's
rare (it's usually a bug).  But it looks like the seq_file() code does it
when someone is trying to generate more than PAGE_SIZE's worth of data. 
Like /proc/slabinfo.


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 19:11           ` 2.6.17-mm2 Andrew Morton
  2006-06-28 19:22             ` 2.6.17-mm2 Jeremy Fitzhardinge
@ 2006-06-28 19:36             ` Martin Bligh
  2006-06-29  0:17               ` 2.6.17-mm2 Martin J. Bligh
  1 sibling, 1 reply; 93+ messages in thread
From: Martin Bligh @ 2006-06-28 19:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle

>>How the hell did you figure that one out?
> 
> Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a
> tight loop.  With that happening, a little two-way wasn't able to make
> it through `dbench 4' without soiling the upholstery.  Then bisection-searching.

Aha. we probably trigger it because the automated test harness dumps a
bunch of crap out of /proc before and after running dbench then ;-)

Thanks!

M.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 19:11           ` 2.6.17-mm2 Andrew Morton
@ 2006-06-28 19:22             ` Jeremy Fitzhardinge
  2006-06-28 19:49               ` 2.6.17-mm2 Andrew Morton
  2006-06-28 19:36             ` 2.6.17-mm2 Martin Bligh
  1 sibling, 1 reply; 93+ messages in thread
From: Jeremy Fitzhardinge @ 2006-06-28 19:22 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Martin J. Bligh, mbligh, linux-kernel, apw, linuxppc64-dev, drfickle

Andrew Morton wrote:
> Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a
> tight loop.  With that happening, a little two-way wasn't able to make
> it through `dbench 4' without soiling the upholstery.  Then bisection-searching.
>   
It's surprising it was so subtle.  I'd been running with that code for a 
month or so without a peep of problem...

    J

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 14:43         ` 2.6.17-mm2 Martin J. Bligh
  2006-06-28 15:06           ` 2.6.17-mm2 Andy Whitcroft
@ 2006-06-28 19:11           ` Andrew Morton
  2006-06-28 19:22             ` 2.6.17-mm2 Jeremy Fitzhardinge
  2006-06-28 19:36             ` 2.6.17-mm2 Martin Bligh
  1 sibling, 2 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-28 19:11 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle

On Wed, 28 Jun 2006 07:43:14 -0700
"Martin J. Bligh" <mbligh@google.com> wrote:

> Andrew Morton wrote:
> > On Wed, 28 Jun 2006 03:42:15 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> > 
> > 
> >>his is caused by the vsprintf() changes.  Right now, if you do
> >>
> >>	snprintf(buf, 4, "1111111111111");
> >>
> >>the memory at `buf' gets [31 31 31 31 00], which is not good.
> >>
> >>This'll plug it, but I didn't check very hard whether it still has any
> >>off-by-ones, or if breaks the intent of Jeremy's patch.  I think it's OK..
> 
> Aha, you're a genius!

That's not what my kids say.

> How the hell did you figure that one out?

Found a way to reproduce it - do `cat /proc/slabinfo > /dev/null' in a
tight loop.  With that happening, a little two-way wasn't able to make
it through `dbench 4' without soiling the upholstery.  Then bisection-searching.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 10:42     ` 2.6.17-mm2 Andrew Morton
  2006-06-28 10:47       ` 2.6.17-mm2 Andrew Morton
@ 2006-06-28 15:43       ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 93+ messages in thread
From: Jeremy Fitzhardinge @ 2006-06-28 15:43 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Martin J. Bligh, mbligh, linux-kernel, apw, linuxppc64-dev

Andrew Morton wrote:
> This is caused by the vsprintf() changes.  Right now, if you do
>
> 	snprintf(buf, 4, "1111111111111");
>
> the memory at `buf' gets [31 31 31 31 00], which is not good.
>
> This'll plug it, but I didn't check very hard whether it still has any
> off-by-ones, or if breaks the intent of Jeremy's patch.  I think it's OK..
>   
Damn.  This patch doesn't look right; the intent is that 'end' point to 
just beyond the formatted string.  I'm pretty sure I tested this, since 
its the most obvious test.  Clearly not enough.  I'll look into it.

    J


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 14:43         ` 2.6.17-mm2 Martin J. Bligh
@ 2006-06-28 15:06           ` Andy Whitcroft
  2006-06-28 19:11           ` 2.6.17-mm2 Andrew Morton
  1 sibling, 0 replies; 93+ messages in thread
From: Andy Whitcroft @ 2006-06-28 15:06 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Andrew Morton, mbligh, jeremy, linux-kernel, linuxppc64-dev, drfickle

Martin J. Bligh wrote:
> Andrew Morton wrote:
> 
>> On Wed, 28 Jun 2006 03:42:15 -0700
>> Andrew Morton <akpm@osdl.org> wrote:
>>
>>
>>> his is caused by the vsprintf() changes.  Right now, if you do
>>>
>>>     snprintf(buf, 4, "1111111111111");
>>>
>>> the memory at `buf' gets [31 31 31 31 00], which is not good.
>>>
>>> This'll plug it, but I didn't check very hard whether it still has any
>>> off-by-ones, or if breaks the intent of Jeremy's patch.  I think it's
>>> OK..
> 
> 
> Aha, you're a genius! How the hell did you figure that one out?
> 
> Andy / Steve ... any chance one of you could kick this through the
> harness? Against -git10 or so, I'd think
> 
> Thanks,


Suitibly kicked ... against 2.6.17-git10.

-apw


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 10:47       ` 2.6.17-mm2 Andrew Morton
@ 2006-06-28 14:43         ` Martin J. Bligh
  2006-06-28 15:06           ` 2.6.17-mm2 Andy Whitcroft
  2006-06-28 19:11           ` 2.6.17-mm2 Andrew Morton
  0 siblings, 2 replies; 93+ messages in thread
From: Martin J. Bligh @ 2006-06-28 14:43 UTC (permalink / raw)
  To: Andrew Morton; +Cc: mbligh, jeremy, linux-kernel, apw, linuxppc64-dev, drfickle

Andrew Morton wrote:
> On Wed, 28 Jun 2006 03:42:15 -0700
> Andrew Morton <akpm@osdl.org> wrote:
> 
> 
>>his is caused by the vsprintf() changes.  Right now, if you do
>>
>>	snprintf(buf, 4, "1111111111111");
>>
>>the memory at `buf' gets [31 31 31 31 00], which is not good.
>>
>>This'll plug it, but I didn't check very hard whether it still has any
>>off-by-ones, or if breaks the intent of Jeremy's patch.  I think it's OK..

Aha, you're a genius! How the hell did you figure that one out?

Andy / Steve ... any chance one of you could kick this through the
harness? Against -git10 or so, I'd think

Thanks,

M.

> That diff was against an older kernel and doesn't apply.  This is against
> mainline:
> 
> --- a/lib/vsprintf.c~vsnprintf-fix
> +++ a/lib/vsprintf.c
> @@ -259,7 +259,9 @@ int vsnprintf(char *buf, size_t size, co
>  	int len;
>  	unsigned long long num;
>  	int i, base;
> -	char *str, *end, c;
> +	char *str;		/* Where we're writing to */
> +	char *end;		/* The last byte we can write to */
> +	char c;
>  	const char *s;
>  
>  	int flags;		/* flags to number() */
> @@ -283,12 +285,12 @@ int vsnprintf(char *buf, size_t size, co
>  	}
>  
>  	str = buf;
> -	end = buf + size;
> +	end = buf + size - 1;
>  
>  	/* Make sure end is always >= buf */
> -	if (end < buf) {
> +	if (end < buf - 1) {
>  		end = ((void *)-1);
> -		size = end - buf;
> +		size = end - buf + 1;
>  	}
>  
>  	for (; *fmt ; ++fmt) {
> @@ -494,7 +496,6 @@ int vsnprintf(char *buf, size_t size, co
>  	/* the trailing null byte doesn't count towards the total */
>  	return str-buf;
>  }
> -
>  EXPORT_SYMBOL(vsnprintf);
>  
>  /**
> _
> 


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-28 10:42     ` 2.6.17-mm2 Andrew Morton
@ 2006-06-28 10:47       ` Andrew Morton
  2006-06-28 14:43         ` 2.6.17-mm2 Martin J. Bligh
  2006-06-28 15:43       ` 2.6.17-mm2 Jeremy Fitzhardinge
  1 sibling, 1 reply; 93+ messages in thread
From: Andrew Morton @ 2006-06-28 10:47 UTC (permalink / raw)
  To: mbligh, jeremy, mbligh, linux-kernel, apw, linuxppc64-dev

On Wed, 28 Jun 2006 03:42:15 -0700
Andrew Morton <akpm@osdl.org> wrote:

> his is caused by the vsprintf() changes.  Right now, if you do
> 
> 	snprintf(buf, 4, "1111111111111");
> 
> the memory at `buf' gets [31 31 31 31 00], which is not good.
> 
> This'll plug it, but I didn't check very hard whether it still has any
> off-by-ones, or if breaks the intent of Jeremy's patch.  I think it's OK..

That diff was against an older kernel and doesn't apply.  This is against
mainline:

--- a/lib/vsprintf.c~vsnprintf-fix
+++ a/lib/vsprintf.c
@@ -259,7 +259,9 @@ int vsnprintf(char *buf, size_t size, co
 	int len;
 	unsigned long long num;
 	int i, base;
-	char *str, *end, c;
+	char *str;		/* Where we're writing to */
+	char *end;		/* The last byte we can write to */
+	char c;
 	const char *s;
 
 	int flags;		/* flags to number() */
@@ -283,12 +285,12 @@ int vsnprintf(char *buf, size_t size, co
 	}
 
 	str = buf;
-	end = buf + size;
+	end = buf + size - 1;
 
 	/* Make sure end is always >= buf */
-	if (end < buf) {
+	if (end < buf - 1) {
 		end = ((void *)-1);
-		size = end - buf;
+		size = end - buf + 1;
 	}
 
 	for (; *fmt ; ++fmt) {
@@ -494,7 +496,6 @@ int vsnprintf(char *buf, size_t size, co
 	/* the trailing null byte doesn't count towards the total */
 	return str-buf;
 }
-
 EXPORT_SYMBOL(vsnprintf);
 
 /**
_


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-27 15:37   ` 2.6.17-mm2 Martin J. Bligh
@ 2006-06-28 10:42     ` Andrew Morton
  2006-06-28 10:47       ` 2.6.17-mm2 Andrew Morton
  2006-06-28 15:43       ` 2.6.17-mm2 Jeremy Fitzhardinge
  0 siblings, 2 replies; 93+ messages in thread
From: Andrew Morton @ 2006-06-28 10:42 UTC (permalink / raw)
  To: Martin J. Bligh, Jeremy Fitzhardinge
  Cc: mbligh, mbligh, linux-kernel, apw, linuxppc64-dev

On Tue, 27 Jun 2006 08:37:45 -0700
"Martin J. Bligh" <mbligh@mbligh.org> wrote:

> SMP NR_CPUS=32 NUMA
> Modules linked in:
> NIP: C0000000000A311C LR: C0000000000A30D4 CTR: C0000000000A3024
> REGS: c0000007725b38d0 TRAP: 0300   Not tainted  (2.6.17-mm3-autokern1)
> MSR: 8000000000001032 <ME,IR,DR>  CR: 28224424  XER: 00000000
> DAR: 000000077BCC6180, DSISR: 0000000040000000
> TASK = c00000002fc74670[29812] 'cp' THREAD: c0000007725b0000 CPU: 2
> GPR00: 0000000000000000 C0000007725B3B50 C00000000063B828 C00000001E303EC0
> GPR04: 0000000000000010 0000000000000000 0000000000000000 FFFFFFFFFFFFFFFD
> GPR08: 0000000000000001 0000000000000000 000000077BCC6180 0000000000000000
> GPR12: 0000000000000000 C00000000051FF80 0000000000000000 0000000000000001
> GPR16: 0000000000000000 0000000000000004 0000000000020000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 C0000007759F9D00 0000000000000000
> GPR24: 0000000000000E42 0000000000000000 000000000000474A C00000001E30F300
> GPR28: 0000000000000000 0000000000000000 C000000000537288 C00000001E303E80
> NIP [C0000000000A311C] .s_show+0xf8/0x364
> LR [C0000000000A30D4] .s_show+0xb0/0x364
> Call Trace:
> [C0000007725B3B50] [C0000000000A3334] .s_show+0x310/0x364 (unreliable)
> [C0000007725B3C20] [C0000000000D5E84] .seq_read+0x2f4/0x450
> [C0000007725B3D00] [C0000000000AADF8] .vfs_read+0xe0/0x1b4
> [C0000007725B3D90] [C0000000000AAFD4] .sys_read+0x54/0x98
> [C0000007725B3E30] [C00000000000871C] syscall_exit+0x0/0x40

This is caused by the vsprintf() changes.  Right now, if you do

	snprintf(buf, 4, "1111111111111");

the memory at `buf' gets [31 31 31 31 00], which is not good.

This'll plug it, but I didn't check very hard whether it still has any
off-by-ones, or if breaks the intent of Jeremy's patch.  I think it's OK..

--- a/lib/vsprintf.c~c
+++ a/lib/vsprintf.c
@@ -259,7 +259,9 @@ int vsnprintf(char *buf, size_t size, co
 	int len;
 	unsigned long long num;
 	int i, base;
-	char *str, *end, c;
+	char *str;		/* Where we're writing to */
+	char *end;		/* The last byte we can write to */
+	char c;
 	const char *s;
 
 	int flags;		/* flags to number() */
@@ -283,12 +285,12 @@ int vsnprintf(char *buf, size_t size, co
 	}
 
 	str = buf;
-	end = buf + size;
+	end = buf + size - 1;
 
 	/* Make sure end is always >= buf */
-	if (end < buf) {
+	if (end < buf - 1) {
 		end = ((void *) ~0ull);
-		size = end - buf;
+		size = end - buf + 1;
 	}
 
 	for (; *fmt ; ++fmt) {
_


^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-26 14:48 ` 2.6.17-mm2 Martin J. Bligh
@ 2006-06-27 15:37   ` Martin J. Bligh
  2006-06-28 10:42     ` 2.6.17-mm2 Andrew Morton
  0 siblings, 1 reply; 93+ messages in thread
From: Martin J. Bligh @ 2006-06-27 15:37 UTC (permalink / raw)
  To: Martin J. Bligh
  Cc: Martin J. Bligh, Andrew Morton, Linux Kernel Mailing List,
	Andy Whitcroft, linuxppc64-dev

Martin J. Bligh wrote:
> Martin J. Bligh wrote:
> 
>> Panic on PPC64. I'm guessing it's the same as the i386 panics I sent
>> you yesterday, just more cryptic ;-) But for the record ...
>>
>> http://test.kernel.org/abat/37737/debug/console.log
>>
>> cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0]
>>     pc: c0000000000c6a34: .s_show+0x178/0x364
>>     lr: c0000000000c696c: .s_show+0xb0/0x364
>>     sp: c0000000f99f7b40
>>    msr: 8000000000001032
>>    dar: fd528000
>>  dsisr: 40000000
>>   current = 0xc0000000f23e0000
>>   paca    = 0xc00000000046e300
>>     pid   = 17653, comm = cp
>> enter ? for help
>>
> 
> Eeek, this is definitely an intermittent thing. I was trawling older
> results, and it shows up (on PPC only) in 2.6.17-git10, so it's not
> just an -mm thing ;-(

OK, still happens in -mm3, though in a different workload now. I also
get a new panic, that's maybe related but more informative



cpu 0x0: Vector: 700 (Program Check) at [c0000000024938b0]
     pc: c0000000000c3218: .free_block+0xe4/0x240
     lr: c0000000000c3514: .drain_array+0xf4/0x170
     sp: c000000002493b30
    msr: 8000000000021032
   current = 0xc0000000025457f0
   paca    = 0xc0000000004f9f00
     pid   = 14, comm = events/0
kernel BUG in list_del at include/linux/list.h:160!

Plus one with an actual backtrace from PPC64 that looks more like the
i386 ones

SMP NR_CPUS=32 NUMA
Modules linked in:
NIP: C0000000000A311C LR: C0000000000A30D4 CTR: C0000000000A3024
REGS: c0000007725b38d0 TRAP: 0300   Not tainted  (2.6.17-mm3-autokern1)
MSR: 8000000000001032 <ME,IR,DR>  CR: 28224424  XER: 00000000
DAR: 000000077BCC6180, DSISR: 0000000040000000
TASK = c00000002fc74670[29812] 'cp' THREAD: c0000007725b0000 CPU: 2
GPR00: 0000000000000000 C0000007725B3B50 C00000000063B828 C00000001E303EC0
GPR04: 0000000000000010 0000000000000000 0000000000000000 FFFFFFFFFFFFFFFD
GPR08: 0000000000000001 0000000000000000 000000077BCC6180 0000000000000000
GPR12: 0000000000000000 C00000000051FF80 0000000000000000 0000000000000001
GPR16: 0000000000000000 0000000000000004 0000000000020000 0000000000000000
GPR20: 0000000000000000 0000000000000000 C0000007759F9D00 0000000000000000
GPR24: 0000000000000E42 0000000000000000 000000000000474A C00000001E30F300
GPR28: 0000000000000000 0000000000000000 C000000000537288 C00000001E303E80
NIP [C0000000000A311C] .s_show+0xf8/0x364
LR [C0000000000A30D4] .s_show+0xb0/0x364
Call Trace:
[C0000007725B3B50] [C0000000000A3334] .s_show+0x310/0x364 (unreliable)
[C0000007725B3C20] [C0000000000D5E84] .seq_read+0x2f4/0x450
[C0000007725B3D00] [C0000000000AADF8] .vfs_read+0xe0/0x1b4
[C0000007725B3D90] [C0000000000AAFD4] .sys_read+0x54/0x98
[C0000007725B3E30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump:
3b180001 7c004a78 79290020 7c0bfe70 7f5a4a14 7d600278 7c005850 54000ffe
7c094038 2c090000 41820008 ebbe80b0 <e96a0000> 2fab0000 419e0008 7c005a2c

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
  2006-06-24 15:41 2.6.17-mm2 Martin J. Bligh
@ 2006-06-26 14:48 ` Martin J. Bligh
  2006-06-27 15:37   ` 2.6.17-mm2 Martin J. Bligh
  0 siblings, 1 reply; 93+ messages in thread
From: Martin J. Bligh @ 2006-06-26 14:48 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: Andrew Morton, Linux Kernel Mailing List, Andy Whitcroft

Martin J. Bligh wrote:
> Panic on PPC64. I'm guessing it's the same as the i386 panics I sent
> you yesterday, just more cryptic ;-) But for the record ...
> 
> http://test.kernel.org/abat/37737/debug/console.log
> 
> cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0]
>     pc: c0000000000c6a34: .s_show+0x178/0x364
>     lr: c0000000000c696c: .s_show+0xb0/0x364
>     sp: c0000000f99f7b40
>    msr: 8000000000001032
>    dar: fd528000
>  dsisr: 40000000
>   current = 0xc0000000f23e0000
>   paca    = 0xc00000000046e300
>     pid   = 17653, comm = cp
> enter ? for help
> 

Eeek, this is definitely an intermittent thing. I was trawling older
results, and it shows up (on PPC only) in 2.6.17-git10, so it's not
just an -mm thing ;-(


M.

^ permalink raw reply	[flat|nested] 93+ messages in thread

* Re: 2.6.17-mm2
@ 2006-06-24 15:41 Martin J. Bligh
  2006-06-26 14:48 ` 2.6.17-mm2 Martin J. Bligh
  0 siblings, 1 reply; 93+ messages in thread
From: Martin J. Bligh @ 2006-06-24 15:41 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Linux Kernel Mailing List

Panic on PPC64. I'm guessing it's the same as the i386 panics I sent
you yesterday, just more cryptic ;-) But for the record ...

http://test.kernel.org/abat/37737/debug/console.log

cpu 0x2: Vector: 300 (Data Access) at [c0000000f99f78c0]
     pc: c0000000000c6a34: .s_show+0x178/0x364
     lr: c0000000000c696c: .s_show+0xb0/0x364
     sp: c0000000f99f7b40
    msr: 8000000000001032
    dar: fd528000
  dsisr: 40000000
   current = 0xc0000000f23e0000
   paca    = 0xc00000000046e300
     pid   = 17653, comm = cp
enter ? for help

^ permalink raw reply	[flat|nested] 93+ messages in thread

end of thread, other threads:[~2006-07-09 21:25 UTC | newest]

Thread overview: 93+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-24 13:19 2.6.17-mm2 Andrew Morton
2006-06-24 15:53 ` 2.6.17-mm2 Rafael J. Wysocki
2006-06-24 17:20   ` 2.6.17-mm2 Dave Jones
2006-06-24 21:34     ` 2.6.17-mm2 Andrew Morton
2006-06-25  8:51       ` 2.6.17-mm2 Rafael J. Wysocki
2006-06-25 10:22         ` 2.6.17-mm2 Andrew Morton
2006-06-25 15:16           ` 2.6.17-mm2 Andrew Morton
2006-06-25 18:23             ` 2.6.17-mm2 Sam Ravnborg
2006-06-25 18:40               ` 2.6.17-mm2 Andrew Morton
2006-06-25 21:21                 ` 2.6.17-mm2 Sam Ravnborg
2006-06-30  7:38             ` 2.6.17-mm2 Randy.Dunlap
2006-07-02 10:11               ` 2.6.17-mm2 Russell King
2006-07-02 18:42                 ` 2.6.17-mm2 Randy.Dunlap
2006-07-02 18:47                   ` 2.6.17-mm2 Arjan van de Ven
2006-07-02 18:47                   ` 2.6.17-mm2 Sam Ravnborg
2006-07-03  5:50                 ` 2.6.17-mm2 Randy.Dunlap
2006-07-03 13:49                   ` 2.6.17-mm2 Russell King
2006-06-25 19:19           ` 2.6.17-mm2 Rafael J. Wysocki
2006-06-26 20:13           ` 2.6.17-mm2 Chandra Seetharaman
2006-06-24 19:41 ` 2.6.17-mm2 Dominik Karall
2006-06-24 21:43   ` 2.6.17-mm2 Andrew Morton
2006-06-25  6:06 ` 2.6.17-mm2 Reuben Farrelly
2006-06-25  9:37   ` 2.6.17-mm2 Barry K. Nathan
2006-06-25 10:29     ` 2.6.17-mm2 Reuben Farrelly
2006-06-25 11:19 ` 2.6.17-mm2 Michal Piotrowski
2006-06-25 11:40   ` 2.6.17-mm2 Andrew Morton
2006-06-25 12:18     ` 2.6.17-mm2 Michal Piotrowski
2006-06-25 16:25 ` 2.6.17-mm2 (NULL pointer dereference) Dominik Karall
2006-06-25 17:18   ` Andrew Morton
2006-06-25 18:11     ` Dominik Karall
2006-06-25 16:47 ` 2.6.17-mm2: no QLA3YYY_NAPI help text Adrian Bunk
2006-06-25 19:32 ` 2.6.17-mm2: BLK_CPQ_CISS_DA=m error Adrian Bunk
2006-06-26  0:41   ` Vivek Goyal
2006-06-25 23:13 ` [-mm patch] make drivers/scsi/pata_it821x.c:it821x_passthru_dev_select() static Adrian Bunk
2006-06-25 23:27   ` Alan Cox
2006-06-27  1:03   ` Jeff Garzik
2006-06-25 23:13 ` [-mm patch] fs/cifs/cifsproto.h: remove #ifdef around small_smb_init_no_tc() prototype Adrian Bunk
2006-06-26  4:05   ` Steven French
2006-06-26 15:17 ` [-mm patch] drivers/scsi/arcmsr/: cleanups Adrian Bunk
2006-06-26 20:27 ` [-mm patch] drivers/md/raid5.c: remove an unused variable Adrian Bunk
2006-06-26 21:41 ` 2.6.17-mm2 hrtimer code wedges at boot? Valdis.Kletnieks
2006-06-26 22:50   ` Valdis.Kletnieks
2006-06-26 23:02   ` john stultz
2006-06-26 23:27   ` Thomas Gleixner
2006-06-27  2:12     ` Valdis.Kletnieks
2006-06-27  5:54       ` Thomas Gleixner
2006-06-27 10:16   ` Roman Zippel
2006-06-27 16:43     ` Valdis.Kletnieks
2006-06-27 17:10       ` Roman Zippel
2006-06-27 17:23         ` Roman Zippel
2006-06-27 19:07           ` Valdis.Kletnieks
2006-06-28  0:07             ` john stultz
2006-06-28 10:35               ` Roman Zippel
2006-06-28 11:44                 ` Roman Zippel
2006-06-29 23:07                   ` Valdis.Kletnieks
2006-06-30 19:26                     ` john stultz
2006-06-30 21:04                       ` Valdis.Kletnieks
2006-07-03  1:13                         ` Roman Zippel
2006-07-03  1:56                           ` Daniel Walker
2006-07-03  2:20                             ` Valdis.Kletnieks
2006-07-03 20:08                               ` john stultz
2006-07-03 19:59                             ` john stultz
2006-07-04 22:21                               ` Valdis.Kletnieks
2006-07-05  4:29                           ` Valdis.Kletnieks
2006-07-06  0:37                             ` Roman Zippel
2006-07-06  0:56                               ` john stultz
2006-07-06  6:38                               ` Valdis.Kletnieks
2006-07-06  0:51                             ` john stultz
2006-07-06  1:12                               ` john stultz
2006-07-06  5:43                                 ` john stultz
2006-07-06 20:33                               ` Roman Zippel
2006-07-06 22:05                                 ` john stultz
2006-07-07 23:16                                   ` Roman Zippel
2006-07-08 20:02                                   ` [PATCH] adjust clock for lost ticks Roman Zippel
2006-07-09 21:25                                     ` john stultz
2006-06-28 23:41                 ` 2.6.17-mm2 hrtimer code wedges at boot? john stultz
2006-06-29 11:24                   ` Roman Zippel
2006-06-28 16:54 ` [-mm patch] include/asm-i386/acpi.h should #include <asm/processor.h> Adrian Bunk
2006-06-28 16:54 ` [-mm patch] fix sgivwfb compile Adrian Bunk
2006-06-28 16:54 ` [-mm patch] arch/i386/mach-visws/setup.c: remove dummy function calls Adrian Bunk
2006-06-24 15:41 2.6.17-mm2 Martin J. Bligh
2006-06-26 14:48 ` 2.6.17-mm2 Martin J. Bligh
2006-06-27 15:37   ` 2.6.17-mm2 Martin J. Bligh
2006-06-28 10:42     ` 2.6.17-mm2 Andrew Morton
2006-06-28 10:47       ` 2.6.17-mm2 Andrew Morton
2006-06-28 14:43         ` 2.6.17-mm2 Martin J. Bligh
2006-06-28 15:06           ` 2.6.17-mm2 Andy Whitcroft
2006-06-28 19:11           ` 2.6.17-mm2 Andrew Morton
2006-06-28 19:22             ` 2.6.17-mm2 Jeremy Fitzhardinge
2006-06-28 19:49               ` 2.6.17-mm2 Andrew Morton
2006-06-28 19:36             ` 2.6.17-mm2 Martin Bligh
2006-06-29  0:17               ` 2.6.17-mm2 Martin J. Bligh
2006-06-28 15:43       ` 2.6.17-mm2 Jeremy Fitzhardinge

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).