2006-03-23 09:44:17

by Andrew Morton

[permalink] [raw]
Subject: 2.6.16-mm1


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/


- Added git-intelfb.patch: more fbdev drivers for Intel graphics hardware.
(David Airlie).

- Be aware that someone-who-doesn't-know-about-allmodconfig has screwed up
AGP on x86_64: if your link fails with various missing AGP symbols you'll
need to set the various CONFIG_AGP* symbols to `y' rather than `m'. Then
work out which other Kconfig rule keeps on flipping them back to `m' again,
then fix that too.

Once you've done all that, please let us know how you did it.

- John's x86 time rework patches are back again.



Boilerplate:

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

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

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

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

echo "subscribe mm-commits" | mail [email protected]

- If you hit a bug in -mm and it's 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.16-rc6-mm2:


origin.patch
git-acpi.patch
git-acpi-up-fix.patch
git-agpgart.patch
git-arm.patch
git-audit-master.patch
git-blktrace.patch
git-cfq.patch
git-cifs.patch
git-cpufreq.patch
git-drm.patch
git-ieee1394.patch
git-infiniband.patch
git-input.patch
git-intelfb.patch
git-kbuild.patch
git-libata-all.patch
git-netdev-all.patch
git-nfs.patch
git-ntfs.patch
git-ocfs2.patch
git-powerpc.patch
git-serial.patch
git-sym2.patch
git-pcmcia.patch
git-scsi-target.patch
git-sas-jg.patch
git-watchdog.patch
git-xfs.patch
git-viro-bird-m32r.patch
git-viro-bird-m68k.patch
git-viro-bird-uml.patch
git-viro-bird-frv.patch
git-viro-bird-upf.patch
git-viro-bird-volatile.patch

git trees.

-remove-sleep_avg-multiplier.patch
-dont-check_acpi_pci-on-x86-with-acpi-disabled.patch
-efi_call_phys_epilog-warning-fix.patch
-i810fb_cursor-use-gfp_atomic.patch
-v9fs-assign-dentry-ops-to-negative-dentries.patch
-mark-cyc2ns_scale-readmostly.patch
-multiple-exports-of-strpbrk.patch
-sound-core-fix-3-off-by-one-errors.patch
-sound-pci-rme9652-hdspmc-fix-off-by-one-errors.patch
-sound-pci-ice1712-deltac-make-2-functions-static.patch
-gregkh-driver-sysfs_remove_dir-needs-to-invalidate-the-dentry.patch
-gregkh-driver-kobject-fix-build-error-if-config_sysfs-n.patch
-gregkh-driver-empty_release_functions_are_broken.patch
-gregkh-driver-driver-core-platform_get_irq-return-enxio-on-error.patch
-gregkh-driver-handle-errors-returned-by-platform_get_irq.patch
-gregkh-driver-kref-avoid-an-atomic-operation-in-kref_put.patch
-gregkh-driver-kobj_map-semaphore-to-mutex-conversion.patch
-gregkh-driver-clean-up-module.c-symbol-searching-logic.patch
-gregkh-driver-export_symbol_gpl_future.patch
-gregkh-driver-export_symbol_gpl_future-rcu.patch
-gregkh-driver-export_symbol_gpl_future-usb.patch
-gregkh-driver-module_sysfs_refcount.patch
-gregkh-driver-sysfs-kzalloc-conversion.patch
-gregkh-driver-firmware-fix-bug-in-fw_realloc_buffer.patch
-gregkh-driver-driver-core-add-macros-notice-dev_notice.patch
-gregkh-driver-kobject-add-error-notify.patch
-gregkh-driver-kobject-kobject.h-fix-a-typo.patch
-gregkh-driver-sysfs-fix-problem-with-duplicate-sysfs-directories-and-files.patch
-gregkh-driver-debugfs-add-debugfs_create_blob-helper-for-exporting-binary-data.patch
-gregkh-driver-kobject_add_dir.patch
-gregkh-driver-get_cpu_sysdev-signedness-fix.patch
-gregkh-driver-unexport-sysfs-dir.patch
-gregkh-driver-sysfs_add_link-kobject-leak-fix.patch
-vr41xx-convert-to-the-new-platform-device-interface.patch
-mv64x600_wdt-convert-to-the-new-platform-device-interface.patch
-tb0219-convert-to-the-new-platform-device-interface.patch
-dcdbas-convert-to-the-new-platform-device-interface.patch
-git-dvb-build-fixes.patch
-ipw2200_txbusy.patch
-drivers-net-ns83820c-add-paramter-to-disable-auto.patch
-via-rhine-link-loss-autoneg-off-==-trouble.patch
-ipw2200-warning-fix.patch
-sky2-use-mutex.patch
-drivers-net-wireless-ipw2200c-make-ipw_qos_current_mode-static.patch
-drivers-net-wireless-ipw2200c-fix-an-array-overun.patch
-natsemi-add-support-for-using-mii-port-with-no-phy-fix.patch
-skfp-warning-fixes.patch
-git-netdev-all-tg3-warning-fix.patch
-net-allow-32-bit-socket-ioctl-in-64-bit-kernel.patch
-net-socket-timestamp-32-bit-handler-for-64-bit-kernel.patch
-x25-ioctl-conversion-32-bit-user-to-64-bit-kernel.patch
-x25-fix-kernel-error-message-64-bit-kernel.patch
-x25-allow-itu-t-dte-facilities-for-x25.patch
-x25-dte-facilities-32-64-ioctl-conversion.patch
-scm-fold-__scm_send-into-scm_send.patch
-scm_send-speedup.patch
-fix-irda-usb-use-after-use.patch
-net-bluetooth-return-negative-error-constant.patch
-sunrpc-fix-a-busy-inodes-error-in-rpc_pipefs.patch
-serial-serial_txx9-driver-update.patch
-serial-kernel-console-should-send-crlf-not-lfcr.patch
-sparc64-config_blk_dev_ram-fix.patch
-gregkh-usb-usb-add-zc0301-video4linux2-driver.patch
-gregkh-usb-usb-optimise-devio.c-usbdev_read.patch
-gregkh-usb-usb-optimise-devio.c-usbdev_read-fix.patch
-gregkh-usb-usb-mdc800.c-to-kzalloc.patch
-gregkh-usb-usb-kzalloc-for-storage.patch
-gregkh-usb-usb-kzalloc-for-hid.patch
-gregkh-usb-usb-kzalloc-in-dabusb.patch
-gregkh-usb-usb-kzalloc-in-w9968cf.patch
-gregkh-usb-usb-kzalloc-in-usbvideo.patch
-gregkh-usb-usb-kzalloc-in-cytherm.patch
-gregkh-usb-usb-kzalloc-in-idmouse.patch
-gregkh-usb-usb-kzalloc-in-ldusb.patch
-gregkh-usb-usb-kzalloc-in-phidgetinterfacekit.patch
-gregkh-usb-usb-kzalloc-in-phidgetservo.patch
-gregkh-usb-usb-kzalloc-in-usbled.patch
-gregkh-usb-usb-kzalloc-in-sisusbvga.patch
-gregkh-usb-ub-use-kzalloc.patch
-gregkh-usb-usb-remove-obsolete_oss_usb_driver-drivers.patch
-gregkh-usb-usb-drivers-usb-core-message.c-make-usb_get_string-static.patch
-gregkh-usb-usb-remove-linux_version_code-macro-usage.patch
-gregkh-usb-usb-convert-a-bunch-of-usb-semaphores-to-mutexes.patch
-gregkh-usb-usb-ehci-and-nf2-quirk.patch
-gregkh-usb-usb-ehci-full-speed-iso-bugfixes.patch
-gregkh-usb-usb-ehci-for-freescale-83xx.patch
-gregkh-usb-usb-ehci-and-freescale-83xx-quirk.patch
-gregkh-usb-usb-ehci-for-au1200.patch
-gregkh-usb-usb-ohci-for-au1200.patch
-gregkh-usb-usb-ehci-unlink-tweaks.patch
-gregkh-usb-usb-add-support-for-ochi-on-at91rm9200.patch
-gregkh-usb-usb-add-support-for-at91-gadget.patch
-gregkh-usb-usb-minor-gadget-rndis-tweak.patch
-gregkh-usb-recognize-three-more-usb-peripheral-controllers.patch
-gregkh-usb-usb-usbcore-sets-up-root-hubs-earlier.patch
-gregkh-usb-usb-ohci-uses-driver-model-wakeup-flags.patch
-gregkh-usb-usb-remove-usbcore-specific-wakeup-flags.patch
-gregkh-usb-usbhid-add-error-handling.patch
-gregkh-usb-usb-pegasus-linksys-usbvpn1-support-cleanup.patch
-gregkh-usb-usb-zero-driver-removed-duplicated-code.patch
-gregkh-usb-usb-fix-masking-bug-initialization-of-freescale-ehci-controller.patch
-gregkh-usb-uhci-use-one-qh-per-endpoint-not-per-urb.patch
-gregkh-usb-uhci-use-dummy-tds.patch
-gregkh-usb-uhci-remove-main-list-of-urbs.patch
-gregkh-usb-uhci-improve-debugging-code.patch
-gregkh-usb-uhci-don-t-log-short-transfers.patch
-gregkh-usb-uhci-hcd-fix-mistaken-usage-of-list_prepare_entry.patch
-gregkh-usb-usb-core-and-hcds-don-t-put_device-while-atomic.patch
-gregkh-usb-usbcore-fix-compile-error-with-config_usb_suspend-n.patch
-gregkh-usb-usb-gadget-driver-section-fixups.patch
-gregkh-usb-usb-ethernet-gadget-driver-section-fixups.patch
-gregkh-usb-usb-fix-warning-in-drivers-usb-media-ov511.c.patch
-gregkh-usb-usb-zc0301-driver-updates.patch
-gregkh-usb-usb-credits-add-credits-about-the-zc0301-and-et61x51-usb-drivers.patch
-gregkh-usb-usb-kzalloc-conversion-for-rest-of-drivers-usb.patch
-gregkh-usb-usb-kzalloc-conversion-in-drivers-usb-gadget.patch
-gregkh-usb-usb-sn9c10x-driver-updates.patch
-gregkh-usb-usb-et61x51-driver-updates.patch
-gregkh-usb-usb-zc0301-driver-updates-2.patch
-gregkh-usb-cypress_m8-add-support-for-the-nokia-ca42-version-2-cable.patch
-gregkh-usb-usb-pl2303-and-tiocmiwait.patch
-gregkh-usb-usb-support-for-usb-to-serial-cable-from-speed-dragon-multimedia.patch
-gregkh-usb-usb-uhci-increase-port-reset-completion-delay-for-hp-controllers.patch
-gregkh-usb-usb-ub-01-remove-first_open.patch
-gregkh-usb-usb-ub-02-remove-diag.patch
-gregkh-usb-usb-ub-03-drop-stall-clearing.patch
-gregkh-usb-usb-usbcore-don-t-assume-a-usb-configuration-includes-any-interfaces.patch
-gregkh-usb-usb-usbcore-usb_set_configuration-oops.patch
-gregkh-usb-usb-initdata-fixes.patch
-gregkh-usb-usb-storage-sandisk-unusual_devices-entry.patch
-gregkh-usb-usb-storage-another-unusual_devs.h-entry.patch
-gregkh-usb-usb-storage-new-unusual_devs.h-entry-mitsumi-7in1-card-reader.patch
-gregkh-usb-usb-add-support-for-creativelabs-silvercrest-usb-keyboard.patch
-gregkh-usb-usb-zc0301-driver-bugfix.patch
-gregkh-usb-usb-vicam.c-fix-a-null-pointer-dereference.patch
-gregkh-usb-usb-fix-check_ctrlrecip-to-allow-control-transfers-in-state-address.patch
-gregkh-usb-usb-cp2101-add-new-device-ids.patch
-gregkh-usb-usb-ftdi_sio-add-icom-id1-usb-product-and-vendor-ids.patch
-gregkh-usb-usb-rtl8150-small-fix.patch
-gregkh-usb-navman-usb-serial.patch
-gregkh-usb-omninet_debug.patch
-xfs_file_compat_invis_ioctl-fix.patch
-mm-remove-set_pgdir-leftovers.patch
-mm-never-clearpagelru-released-pages.patch
-mm-pagelru-no-testset.patch
-mm-pageactive-no-testset.patch
-mm-less-atomic-ops.patch
-mm-page_alloc-less-atomics.patch
-mm-slab-less-atomics.patch
-mm-simplify-vmscan-vs-release-refcounting.patch
-mm-de-skew-page-refcounting.patch
-xtensa-pgtable-fixes.patch
-mm-split-highorder-pages.patch
-mm-page_state-comment-more.patch
-mm-cleanup-bootmem.patch
-hugepage-allocator-cleanup.patch
-kcalloc-int_max-ulong_max.patch
-slab-object-to-index-mapping-cleanup.patch
-slab-extract-setup_cpu_cache.patch
-slab-cleanup.patch
-slab-remove-cachep-spinlock.patch
-mm-kill-kmem_cache_t-usage.patch
-slab-fix-kernel-doc-warnings.patch
-slab-remove-slab_no_reap-option.patch
-slab-remove-slab_no_reap-option-fix.patch
-on_each_cpu-disable-local-interupts.patch
-slab-use-on_each_cpu.patch
-thin-out-scan_control-remove-nr_to_scan-and-priority.patch
-vmscan-scan_control-cleanup.patch
-vmscan-scan_control-cleanup-speedup.patch
-vmscan-use-unsigned-longs.patch
-vmscan-use-unsigned-longs-shrink_all_memory-fix.patch
-vmscan-return-nr_reclaimed.patch
-vmscan-rename-functions.patch
-zone_reclaim-additional-comments-and-cleanup.patch
-mm-isolate_lru_pages-scan-count-fix.patch
-mm-shrink_inactive_lis-nr_scan-accounting-fix.patch
-remove-vm_dontcopy-bogosities.patch
-sg-use-compound-pages.patch
-i386-pageattr-remove-__put_page.patch
-i386-pageattr-remove-__put_page-fix.patch
-x86_64-pageattr-use-single-list.patch
-x86_64-pageattr-remove-__put_page.patch
-x86_64-pageattr-remove-__put_page-fix.patch
-mm-make-__put_page-internal.patch
-mm-nommu-use-compound-pages.patch
-remove-set_page_countpage-0-users-outside-mm.patch
-remove-set_page_count-outside-mm.patch
-mm-cleanup-prep_-stuff.patch
-mm-prep_zero_page-in-irq-is-a-bug.patch
-mm-more-config_debug_vm.patch
-mm-opt-page_count.patch
-uninline-sys_mmap-common-code-reduce-binary-size.patch
-vmscan-remove-obsolete-checks-from-shrink_list-and-fix-unlikely-in-refill_inactive-zone.patch
-shmem-inline-to-avoid-warning.patch
-readahead-prev_page-can-overrun-the-ahead-window.patch
-readahead-fix-initial-window-size-calculation.patch
-enable-mprotect-on-huge-pages.patch
-enable-mprotect-on-huge-pages-fix.patch
-fix-i386-x86-64-_page_pse-bit-when-changing-page-protection.patch
-hugepage-small-fixes-to-hugepage-clear-copy-path.patch
-hugepage-small-fixes-to-hugepage-clear-copy-path-tidy.patch
-hugepage-serialize-hugepage-allocation-and-instantiation.patch
-hugepage-serialize-hugepage-allocation-and-instantiation-tidy.patch
-hugepage-strict-page-reservation-for-hugepage-inodes.patch
-hugepage-strict-page-reservation-for-hugepage-inodes-fix.patch
-hugepage-make-allocfree_huge_page-local.patch
-hugepage-fix-hugepage-logic-in-free_pgtables.patch
-hugepage-fix-hugepage-logic-in-free_pgtables-harder.patch
-hugepage-move-hugetlb_free_pgd_range-prototype-to-hugetlbh.patch
-hugepage-is_aligned_hugepage_range-cleanup.patch
-convert-hugetlbfs_counter-to-atomic.patch
-optimize-follow_hugetlb_page.patch
-mm-make-shrink_all_memory-try-harder.patch
-slab-cache_reap-further-reduction-in-interrupt-holdoff.patch
-slab-cache_reap-further-reduction-in-interrupt-holdoff-fix.patch
-slab-make-drain_array-more-universal-by-adding-more-parameters.patch
-slab-remove-drain_array_locked.patch
-slab-fix-drain_array-so-that-it-works-correctly-with-the-shared_array.patch
-drain_node_pages-interrupt-latency-reduction--optimization.patch
-drain_node_pages-interrupt-latency-reduction-optimization-update.patch
-fix-swap-cluster-offset.patch
-page-migration-reorg.patch
-page-migration-reorg-fixes.patch
-page-migration-reorg-cleanup.patch
-page-migration-reorg-cleanup-fix.patch
-selinux-disable-automatic-labeling-of-new-inodes-when.patch
-sem2mutex-security.patch
-selinux-simplify-sel_read_bool.patch
-selinuxfs-cleanups-fix-hard-link-count.patch
-selinuxfs-cleanups-use-sel_make_dir.patch
-selinuxfs-cleanups-sel_fill_super-exit-path.patch
-selinuxfs-cleanups-sel_make_bools.patch
-selinuxfs-cleanups-sel_make_avc_files.patch
-selinux-fix-hard-link-count-for-selinuxfs-root-directory.patch
-selinux-cleanup-stray-variable-in-selinux_inode_init_security.patch

Merged

+proc-fix-duplicate-line-in-proc-devices.patch
+sys_alarm-unsigned-signed-conversion-fixup.patch
+sys_alarm-unsigned-signed-conversion-fixup-fix.patch
+validate-and-sanitze-itimer-timeval-from-userspace.patch
+validate-and-sanitze-itimer-timeval-from-userspace-fix.patch
+fix-scheduler-deadlock.patch
+fix-bug-bio_rw_barrier-requests-to-md-raid1-hang.patch
+fix-use-after-free-in-cciss_init_one.patch

2.6.16.1 queue.

+fix-sequencer-missing-negative-bound-check.patch
+pnp-adjust-pnp_register_card_driver-signature-ad1816a.patch
+pnp-adjust-pnp_register_card_driver-signature-als100.patch
+pnp-adjust-pnp_register_card_driver-signature-azt2320.patch
+pnp-adjust-pnp_register_card_driver-signature-cmi8330.patch
+pnp-adjust-pnp_register_card_driver-signature-dt019x.patch
+pnp-adjust-pnp_register_card_driver-signature-es18xx.patch
+pnp-adjust-pnp_register_card_driver-signature-es968.patch
+pnp-adjust-pnp_register_card_driver-signature-interwave.patch
+pnp-adjust-pnp_register_card_driver-signature-sb16.patch
+pnp-adjust-pnp_register_card_driver-signature-sb_card.patch
+pnp-adjust-pnp_register_card_driver-signature-sscape.patch
+pnp-adjust-pnp_register_card_driver-signature-wavefront.patch

pnp API cleanups

+powernow-remove-private-for_each_cpu_mask.patch
+cpufreq_conservative-aligning-of-codebase-with-ondemand.patch
+cpufreq_conservative-alter-default-responsiveness.patch
+cpufreq_conservative-make-for_each_cpu-safe.patch
+cpufreq_conservative-alternative-initialise-approach.patch

cpufreq updates

+saa7111c-fix.patch

dvb fix

+ia64-sn_check_intr-use-ia64_get_irr.patch

ia64 fix

-pc-speaker-add-snd_silent.patch

Dropped.

-git-libata-all-build-hacks.patch

Unneeded

-revert-ipw2200-Fix-WPA-network-selection-problem.patch

Unneeded

Folded into natsemi-add-support-for-using-mii-port-with-no-phy.patch

-amd-au1xx0-fix-ethernet-tx-stats-tidy.patch

Folded into amd-au1xx0-fix-ethernet-tx-stats.patch

-drivers-net-ns83820c-add-paramter-to-disable-auto-tidy-2.patch
-drivers-net-ns83820c-add-paramter-to-disable-auto-tidy-fix.patch

Folded into drivers-net-ns83820c-add-paramter-to-disable-auto.patch

+com90xx-kmalloc-fix.patch

Fix new bug in com90xx WAN driver

+remove-needless-check-in-nfs_opendir.patch

NFS cleanup

+git-powerpc-hot_add_scn_to_nid-build-fix.patch
+powerpc-add_memory-warning-fix.patch

powerpc fixes

+serial-mystery-kbuild-fix.patch

Serial fix

+mm-drivers-pci-msi-explicit-declaration-of-msi_register-fix.patch

Fix mm-drivers-pci-msi-explicit-declaration-of-msi_register.patch

+git-scsi-misc-min-warning-fix.patch

Fix warning in scsi tree

+drivers-scsi-aic7xxx-aic79xx_corec-make-ahd_match_scb-static.patch

scsi driver cleanup

+sparc64-fix-set_page_count-merge-clash.patch

sparc64 fix

+cirrus-ep93xx-watchdog-driver.patch
+cirrus-ep93xx-watchdog-driver-tidy.patch

New watchdog driver

+ipw2200-config_ipw_qos-to-config_ipw2200_qos.patch

ipw2200 cleanup

-x86_64-mm-empty-pxm.patch
-x86_64-mm-lost-ticks-dump-rip.patch
-x86_64-mm-amd-3core.patch
+x86_64-mm-amd-core-parsing.patch
+x86_64-mm-powernow-query.patch
+x86_64-mm-iret-error-code.patch
+x86_64-mm-lost-cli-debug.patch
+x86_64-mm-hotadd-reserve.patch
+x86_64-mm-srat-hotadd-reserve.patch
+x86_64-mm-empty-pxm.patch
+x86_64-mm-via-agp.patch
+x86_64-mm-sis-agp.patch

x86_64 tree updates

-x86_64-mm-timer-broadcast-amd-fix-2.patch
+x86_64-mm-timer-broadcast-amd-fix-fix.patch
+x86-64-calgary-iommu-introduce-iommu_detected.patch
+x86-64-calgary-iommu-calgary-specific-bits.patch
+x86-64-calgary-iommu-hook-it-in.patch
+x86_64-mm-hotadd-reserve-vs-arm.patch

more x86_64 things

+slab-introduce-kmem_cache_zalloc-allocator.patch
+slab-optimize-constant-size-kzalloc-calls.patch
+mm-use-kmem_cache_zalloc.patch
+slab-add-transfer_objects-function.patch
+slab-add-transfer_objects-function-fix.patch
+slab-bypass-free-lists-for-__drain_alien_cache.patch
+alloc_kmemlist-some-cleanup-in-preparation-for-a-real-memory-leak-fix.patch
+slab-fix-memory-leak-in-alloc_kmemlist.patch
+slab-fix-memory-leak-in-alloc_kmemlist-fix.patch
+add-api-for-flushing-anon-pages.patch
+add-flush_kernel_dcache_page-api.patch
+mm-make-page-migration-dependent-on-swap-and-numa.patch

MM updates

+bug-fixes-and-cleanup-for-the-bsd-secure-levels-lsm-update.patch
+bug-fixes-and-cleanup-for-the-bsd-secure-levels-lsm-update-tidy.patch

update this patch.

+x86-make-config_hotplug_cpu-depend-on-x86_pc.patch
+x86-cpu_init-avoid-gfp_kernel-allocation-while-atomic.patch
+pm-timer-dont-use-workaround-if-chipset-is-not-buggy.patch
+pm-timer-dont-use-workaround-if-chipset-is-not-buggy-tidy.patch

x86 fixes

+swsusp-add-check-for-suspension-of-x-controlled-devices.patch
+swsusp-let-userland-tools-switch-console-on-suspend.patch
+swsusp-add-s2ram-ioctl-to-userland-interface.patch

swsusp updates

+s390-wrong-interrupt-delivered-for-hsch-or-csch.patch
+s390-cio-documentation-update.patch
+s390-channel-path-measurements.patch
+s390-early-parameter-parsing.patch
+s390-proc-sys-vm-cmm_-permission-bits.patch
+s390-bug-warnings.patch
+s390-cpu-up-retries.patch
+s390-connector-support.patch
+s390-use-normal-switch-statement-for-ioctls-in-dasd_ioctlc.patch
+s390-use-normal-switch-statement-for-ioctls-in-dasd_ioctlc-2.patch
+s390-merge-cmb-into-dasdc.patch
+s390-remove-dynamic-dasd-ioctls.patch
+s390-remove-old-history-whitespave-from-partition-code.patch
+s390-remove-experimental-flag-from-dasd-diag.patch
+s390-random-values-in-result-of-biodasdinfo2.patch
+s390-dasd-extended-error-reporting.patch
+s390-tape-retry-flooding-by-deferred-cc-in-interrupt.patch
+s390-tape-operation-abortion-leads-to-panic.patch
+s390-fix-endless-retry-loop-in-tape-driver.patch
+s390-3590-tape-driver.patch
+s390-remove-support-for-ttys-over-ctc-connections.patch
+s390-cex2a-crt-message-length.patch
+s390-kzalloc-conversion-in-arch-s390.patch
+s390-kzalloc-conversion-in-drivers-s390.patch
-dasd-cleanup-dasd_ioctl.patch
-dasd-add-per-disciple-ioctl-method.patch
-dasd-merge-dasd_cmd-into-dasd_mod.patch
-dasd-kill-dynamic-ioctl-registration.patch

s390 updates

-reiser4-export-page_cache_readahead.patch

Renamed.

+cpuset-remove-unnecessary-null-check.patch
+cpuset-remove-unnecessary-null-check-comment-fix.patch
+cpuset-dont-need-to-mark-cpuset_mems_generation-atomic.patch
+cpuset-memory_spread_slab-drop-useless-pf_spread_page-check.patch
+cpuset-remove-useless-local-variable-initialization.patch
+add-gfp-flag-__gfp_policy-to-control-policies-and-cpusets-redirection.patch

cupset things

+yet-more-rio-cleaning-1-of-2.patch
+yet-more-rio-cleaning-2-of-2.patch

rio cleanups

+v9fs-update-license-boilerplate.patch
+9p-fix-name-consistency-problems.patch
+9p-update-documentation.patch

More v8fs updates

+make-address_space_operations-invalidatepage-return-void-fix.patch

Fix make-address_space_operations-invalidatepage-return-void.patch

+altix-rs422-support-for-ioc4-serial-driver-fixes.patch

Fix altix-rs422-support-for-ioc4-serial-driver.patch

+cpumask-uninline-first_cpu.patch
+cpumask-uninline-next_cpu.patch
+cpumask-uninline-highest_possible_processor_id.patch
+cpumask-uninline-any_online_cpu.patch

Code size reductions.

+oss-fix-leak-in-awe_wave-also-remove-pointless-cast.patch
+fix-memory-leak-in-isapnp.patch
+use-kzalloc-and-kcalloc-in-core-fs-code.patch
+udf-fix-uid-gid-options-and-add-uid-gid=ignore-and-forget.patch
+direct-io-bug-fix-in-dio-handling-write-error.patch
+doc-more-serial-console-info.patch
+check-if-cpu-can-be-onlined-before-calling-smp_prepare_cpu.patch
+check-if-cpu-can-be-onlined-before-calling-smp_prepare_cpu-fix.patch
+cleanup-smp_call_function-up-build.patch
+use-unsigned-int-types-for-a-faster-bsearch.patch
+eisa-ignore-generated-file-drivers-eisa-devlisth.patch
+insert-identical-resources-above-existing-resources.patch
+make-sure-nobodys-leaking-resources.patch
+udf-remove-duplicate-definitions.patch
+ipmi-add-generic-pci-handling.patch
+ipmi-add-generic-pci-handling-tidy.patch
+ipmi-add-full-sysfs-support.patch
+ipmi-add-full-sysfs-support-fixes.patch
+ipmi-add-full-sysfs-support-tidy.patch
+ipmi-add-full-sysfs-support-tidy-2.patch
+hpet-header-sanitization.patch
+doc-fix-example-firmware-source-code.patch
+use-__read_mostly-on-some-hot-fs-variables.patch
+remove-needless-check-in-binfmt_elfc.patch
+remove-needless-check-in-fs-read_writec.patch
+add-sa_percpu_irq-flag-support.patch
+kernel-timec-remove-unused-pps_-variables.patch
+vfsfs-locksc-cleanup-locks_insert_block.patch
+vfsfs-lockscnfsd4-add-race_free-posix_lock_file_conf.patch
+vfsfs-lockscnfsd4-add-race_free-posix_lock_file_conf-tidy.patch
+nfsd4-return-conflict-lock-without-races.patch
+flat-binary-loader-doesnt-check-fd-table-full.patch

Random stuff.

+time-clocksource-infrastructure.patch
+time-use-clocksource-infrastructure-for-update_wall_time.patch
+time-let-user-request-precision-from-current_tick_length.patch
+time-use-clocksource-abstraction-for-ntp-adjustments.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

x86 time management rework.

+kretprobe-kretprobe-booster-spinlock-recursive-remove.patch

Fix kretprobe-kretprobe-booster.patch

+edac-use-sysbus_message-in-e752x-code-fix.patch

Fix edac-use-sysbus_message-in-e752x-code.patch

+notifier-chain-initialization.patch

Generalise notifier chain initialisers

-rtc-subsystem-library-functions-2.patch
-rtc-subsystem-arm-cleanup-2.patch
-rtc-subsystem-arm-integrator-cleanup-2.patch
-rtc-subsystem-class-2.patch
-rtc-subsystem-i2c-cleanup-2.patch
-rtc-subsystem-sysfs-interface-2.patch
-rtc-subsystem-proc-interface-2.patch
-rtc-subsystem-dev-interface-2.patch
-rtc-subsystem-x1205-driver-2.patch
-rtc-subsystem-test-device-driver-2.patch
-rtc-subsystem-ds1672-driver-2.patch
-rtc-subsystem-pcf8563-driver-2.patch
-rtc-subsystem-rs5c372-driver-2.patch
-rtc-subsystem-ep93xx-driver-2.patch
-rtc-subsystem-sa1100-pxa2xx-driver-2.patch
+rtc-subsystem-library-functions.patch
+rtc-subsystem-library-functions-fix.patch
+rtc-subsystem-arm-cleanup.patch
+rtc-subsystem-arm-integrator-cleanup.patch
+rtc-subsystem-class.patch
+rtc-subsystem-i2c-cleanup.patch
+rtc-subsystem-i2c-driver-ids.patch
+rtc-subsystem-sysfs-interface.patch
+rtc-subsystem-proc-interface.patch
+rtc-subsystem-dev-interface.patch
+rtc-subsystem-x1205-driver.patch
+rtc-subsystem-test-device-driver.patch
+rtc-subsystem-ds1672-driver.patch
+rtc-subsystem-pcf8563-driver.patch
+rtc-subsystem-rs5c372-driver.patch
+rtc-subsystem-ep93xx-driver.patch
+rtc-subsystem-sa1100-pxa2xx-driver.patch
+rtc-subsystem-m48t86-driver.patch

Updated

+proc-remove-tasklist_lock-from-proc_pid_readdir-simply-fix-first_tgid.patch
+proc-remove-tasklist_lock-from-proc_pid_readdir-simply-fix-first_tgid-fix.patch

Fix proc-remove-tasklist_lock-from-proc_pid_readdir.patch some more

+proc-dont-lock-task_structs-indefinitely-fix-stat-on-proc-pid.patch
+simplify-fix-first_tid.patch
+simplify-fix-first_tid-fix.patch
+cleanup-next_tid.patch

More proc/task management updates.

+reiser4-export-handle_ra_miss.patch

reiser4 export.

+reiser4-cleanup_init_fake_inode.patch

reiser4 fix

+drivers-video-use-array_size-macro.patch

fbdev cleanup.



All 1535 patches:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/patch-list


2006-03-23 14:49:41

by Russell King

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Thu, Mar 23, 2006 at 03:31:45PM +0100, Michal Piotrowski wrote:
> Hi,
>
> On 23/03/06, Andrew Morton <[email protected]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
>
> Something went wrong with serial code.
>
> make
> [..]
> CC init/version.o
> LD init/built-in.o
> LD .tmp_vmlinux1
> drivers/built-in.o: In function
> `serial_pnp_probe':/usr/src/linux-mm/drivers/serial/8250_pnp.c:435:
> undefined reference to `serial8250_register_port'
> drivers/built-in.o: In function
> `serial_pnp_remove':/usr/src/linux-mm/drivers/serial/8250_pnp.c:447:
> undefined reference to `serial8250_unregister_port'
> drivers/built-in.o: In function
> `pciserial_suspend_ports':/usr/src/linux-mm/drivers/serial/8250_pci.c:1690:
> undefined reference to `serial8250_suspend_port'
> drivers/built-in.o: In function
> `pciserial_resume_ports':/usr/src/linux-mm/drivers/serial/8250_pci.c:1706:
> undefined reference to `serial8250_resume_port'
> drivers/built-in.o: In function
> `pciserial_remove_ports':/usr/src/linux-mm/drivers/serial/8250_pci.c:1665:
> undefined reference to `serial8250_unregister_port'
> drivers/built-in.o: In function
> `pciserial_init_ports':/usr/src/linux-mm/drivers/serial/8250_pci.c:1640:
> undefined reference to `serial8250_register_port'
> make[1]: *** [.tmp_vmlinux1] B??d 1
> make: *** [_all] B??d 2
>
> Here is config http://www.stardust.webpages.pl/files/mm/2.6.16-mm1/mm-config

CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y

That's an illegal configuration.

+config SERIAL_8250_PCI
+ tristate "8250/16550 PCI device support" if EMBEDDED
+ depends on SERIAL_8250 && PCI
+ default y

if SERIAL_8250 is 'm' there's no way that SERIAL_8250_PCI should be 'y'.
Maybe it's a bug in kconfig - seems like it. Let's try some experiments:

config SYM_Y
bool
default y

config SYM_M
tristate
default m

config SYM_D
tristate 'SYM_D'
depends on SYM_M && SYM_Y

With this I'm offered:

SYM_D (SYM_D) [N/m] (NEW)

so Kconfig thinks the only legal values for SYM_D are 'n' and 'm', and
the default is 'n'.

If I add a default line to SYM_D thusly:

config SYM_D
tristate 'SYM_D'
depends on SYM_M && SYM_Y
default y

I'm now offered:

SYM_D (SYM_D) [M/n] (NEW)

Okay, so the default is now 'm', but the legal values are still only 'n'
and 'm'. I can only select 'm' or 'n', and this is what I end up with in
the config file. Now, if I remove the prompt text:

config SYM_D
tristate
depends on SYM_M && SYM_Y
default y

and hey presto, suddenly 'y' becomes a legal value.

CONFIG_SYM_Y=y
CONFIG_SYM_M=m
CONFIG_SYM_D=y

So it would seem to be a Kconfig bug.

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

2006-03-23 16:11:14

by Michal Piotrowski

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Hi Russell,

On 23/03/06, Russell King <[email protected]> wrote:
> CONFIG_SERIAL_8250=m
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_PNP=y
>
> That's an illegal configuration.
>
[snip]
>
> So it would seem to be a Kconfig bug.

Thanks for explanation of the problem

Everything is ok, when I state CONFIG_SERIAL_8250=y in kernel config.

Regards,
Michal

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

2006-03-23 17:58:36

by Dave Jones

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:

> - Be aware that someone-who-doesn't-know-about-allmodconfig has screwed up
> AGP on x86_64: if your link fails with various missing AGP symbols you'll
> need to set the various CONFIG_AGP* symbols to `y' rather than `m'. Then
> work out which other Kconfig rule keeps on flipping them back to `m' again,
> then fix that too.

I haven't merged anything into agpgart-git for a week or two, so it's
more than likely..

> +x86_64-mm-via-agp.patch
> +x86_64-mm-sis-agp.patch
>
> x86_64 tree updates


whatever these are.

Dave

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

2006-03-23 21:07:24

by J.A. Magallon

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Thu, 23 Mar 2006 01:40:46 -0800, Andrew Morton <[email protected]> wrote:

>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
>

I have some patches against -mm I use and don't seem to hurt, since long
time ago. I will try to track its origin, but I'm not sure I can :(.
Anyways I will post them here, to see if someone can tell anything.

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam20 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-23 21:11:28

by J.A. Magallon

[permalink] [raw]
Subject: [PATCH] Make __get_cpu_var use raw_smp_processor_id()

On Thu, 23 Mar 2006 22:07:11 +0100, "J.A. Magallon" <[email protected]> wrote:

> On Thu, 23 Mar 2006 01:40:46 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
>

--- linux-2.6.15-rc5/include/asm-generic/percpu.h.orig 2005-12-21 15:13:27.000000000 -0600
+++ linux-2.6.15-rc5/include/asm-generic/percpu.h 2005-12-21 15:13:43.000000000 -0600
@@ -13,7 +13,7 @@ extern unsigned long __per_cpu_offset[NR

/* var is in discarded region: offset to particular copy we want */
#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
-#define __get_cpu_var(var) per_cpu(var, smp_processor_id())
+#define __get_cpu_var(var) per_cpu(var, raw_smp_processor_id())

/* A macro to avoid #include hell... */
#define percpu_modcopy(pcpudst, src, size) \

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam20 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-23 21:12:44

by J.A. Magallon

[permalink] [raw]
Subject: [PATCH] Use const* parameters in mm.h

On Thu, 23 Mar 2006 22:07:11 +0100, "J.A. Magallon" <[email protected]> wrote:

> On Thu, 23 Mar 2006 01:40:46 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
>

As they are inline, this gives the compiler wide space for optmizations.

--- linux-2.6.15-rc5-mm2.orig/include/linux/mm.h 2005-12-12 09:10:34.000000000 -0800
+++ linux-2.6.15-rc5-mm2/include/linux/mm.h 2005-12-14 14:39:50.000000000 -0800
@@ -464,7 +464,7 @@ void put_page(struct page *page);
#define SECTIONS_MASK ((1UL << SECTIONS_WIDTH) - 1)
#define ZONETABLE_MASK ((1UL << ZONETABLE_SHIFT) - 1)

-static inline unsigned long page_zonenum(struct page *page)
+static inline unsigned long page_zonenum(const struct page *page)
{
return (page->flags >> ZONES_PGSHIFT) & ZONES_MASK;
}
@@ -472,20 +472,20 @@ static inline unsigned long page_zonenum
struct zone;
extern struct zone *zone_table[];

-static inline struct zone *page_zone(struct page *page)
+static inline struct zone *page_zone(const struct page *page)
{
return zone_table[(page->flags >> ZONETABLE_PGSHIFT) &
ZONETABLE_MASK];
}

-static inline unsigned long page_to_nid(struct page *page)
+static inline unsigned long page_to_nid(const struct page *page)
{
if (FLAGS_HAS_NODE)
return (page->flags >> NODES_PGSHIFT) & NODES_MASK;
else
return page_zone(page)->zone_pgdat->node_id;
}
-static inline unsigned long page_to_section(struct page *page)
+static inline unsigned long page_to_section(const struct page *page)
{
return (page->flags >> SECTIONS_PGSHIFT) & SECTIONS_MASK;
}
@@ -519,7 +519,7 @@ static inline void set_page_links(struct
extern struct page *mem_map;
#endif

-static __always_inline void *lowmem_page_address(struct page *page)
+static __always_inline void *lowmem_page_address(const struct page *page)
{
return __va(page_to_pfn(page) << PAGE_SHIFT);
}
@@ -561,7 +561,7 @@ void page_address_init(void);
#define PAGE_MAPPING_ANON 1

extern struct address_space swapper_space;
-static inline struct address_space *page_mapping(struct page *page)
+static inline struct address_space *page_mapping(const struct page *page)
{
struct address_space *mapping = page->mapping;

@@ -572,7 +572,7 @@ static inline struct address_space *page
return mapping;
}

-static inline int PageAnon(struct page *page)
+static inline int PageAnon(const struct page *page)
{
return ((unsigned long)page->mapping & PAGE_MAPPING_ANON) != 0;
}
@@ -581,7 +581,7 @@ static inline int PageAnon(struct page *
* Return the pagecache index of the passed page. Regular pagecache pages
* use ->index whereas swapcache pages use ->private
*/
-static inline pgoff_t page_index(struct page *page)
+static inline pgoff_t page_index(const struct page *page)
{
if (unlikely(PageSwapCache(page)))
return page_private(page);
@@ -598,7 +598,7 @@ static inline void reset_page_mapcount(s
atomic_set(&(page)->_mapcount, -1);
}

-static inline int page_mapcount(struct page *page)
+static inline int page_mapcount(const struct page *page)
{
return atomic_read(&(page)->_mapcount) + 1;
}
@@ -606,7 +606,7 @@ static inline int page_mapcount(struct p
/*
* Return true if this page is mapped into pagetables.
*/
-static inline int page_mapped(struct page *page)
+static inline int page_mapped(const struct page *page)
{
return atomic_read(&(page)->_mapcount) >= 0;
}


--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam20 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-23 21:13:46

by J.A. Magallon

[permalink] [raw]
Subject: [PATCH] Lower e100 latency

On Thu, 23 Mar 2006 22:07:11 +0100, "J.A. Magallon" <[email protected]> wrote:

> On Thu, 23 Mar 2006 01:40:46 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
>

--- linux/drivers/net/e100.c.orig 2006-01-24 09:20:44.000000000 +0100
+++ linux/drivers/net/e100.c 2006-01-24 09:21:55.000000000 +0100
@@ -884,23 +884,23 @@
* procedure it should be done under lock.
*/
spin_lock_irqsave(&nic->mdio_lock, flags);
- for (i = 100; i; --i) {
+ for (i = 1000; i; --i) {
if (readl(&nic->csr->mdi_ctrl) & mdi_ready)
break;
- udelay(20);
+ udelay(2);
}
if (unlikely(!i)) {
- printk("e100.mdio_ctrl(%s) won't go Ready\n",
+ DPRINTK(PROBE, ERR, "e100.mdio_ctrl(%s) won't go Ready\n",
nic->netdev->name );
spin_unlock_irqrestore(&nic->mdio_lock, flags);
return 0; /* No way to indicate timeout error */
}
writel((reg << 16) | (addr << 21) | dir | data, &nic->csr->mdi_ctrl);

- for (i = 0; i < 100; i++) {
- udelay(20);
+ for (i = 0; i < 1000; i++) {
if ((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
break;
+ udelay(2);
}
spin_unlock_irqrestore(&nic->mdio_lock, flags);
DPRINTK(HW, DEBUG,


--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam20 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-23 21:15:28

by J.A. Magallon

[permalink] [raw]
Subject: [PATCH] Dont build altivec raid on x86

On Thu, 23 Mar 2006 22:07:11 +0100, "J.A. Magallon" <[email protected]> wrote:

> On Thu, 23 Mar 2006 01:40:46 -0800, Andrew Morton <[email protected]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
>

gcc just compiles files emptied with #ifdefs, but it looks incorrect
anyways

--- linux/drivers/md/Makefile.orig 2005-11-13 23:14:48.000000000 +0100
+++ linux/drivers/md/Makefile 2005-11-13 23:28:05.000000000 +0100
@@ -8,12 +8,21 @@
dm-snapshot-objs := dm-snap.o dm-exception-store.o
dm-mirror-objs := dm-log.o dm-raid1.o
md-mod-objs := md.o bitmap.o
+
+
+ifeq ($(CONFIG_ALTIVEC),y)
+raid6-vec-objs := \
+ raid6altivec1.o raid6altivec2.o \
+ raid6altivec4.o raid6altivec8.o
+endif
+ifeq ($(CONFIG_X86),y)
+raid6-vec-objs := \
+ raid6mmx.o raid6sse1.o raid6sse2.o
+endif
raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
raid6int1.o raid6int2.o raid6int4.o \
raid6int8.o raid6int16.o raid6int32.o \
- raid6altivec1.o raid6altivec2.o raid6altivec4.o \
- raid6altivec8.o \
- raid6mmx.o raid6sse1.o raid6sse2.o
+ $(raid6-vec-objs)
hostprogs-y := mktables

# Note: link order is important. All raid personalities


--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.15-jam20 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-23 21:21:43

by Brian Gerst

[permalink] [raw]
Subject: Re: [PATCH] Dont build altivec raid on x86

J.A. Magallon wrote:
> On Thu, 23 Mar 2006 22:07:11 +0100, "J.A. Magallon" <[email protected]> wrote:
>
>
>>On Thu, 23 Mar 2006 01:40:46 -0800, Andrew Morton <[email protected]> wrote:
>>
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
>>>
>>
>
> gcc just compiles files emptied with #ifdefs, but it looks incorrect
> anyways
>
> --- linux/drivers/md/Makefile.orig 2005-11-13 23:14:48.000000000 +0100
> +++ linux/drivers/md/Makefile 2005-11-13 23:28:05.000000000 +0100
> @@ -8,12 +8,21 @@
> dm-snapshot-objs := dm-snap.o dm-exception-store.o
> dm-mirror-objs := dm-log.o dm-raid1.o
> md-mod-objs := md.o bitmap.o
> +
> +
> +ifeq ($(CONFIG_ALTIVEC),y)
> +raid6-vec-objs := \
> + raid6altivec1.o raid6altivec2.o \
> + raid6altivec4.o raid6altivec8.o
> +endif
> +ifeq ($(CONFIG_X86),y)
> +raid6-vec-objs := \
> + raid6mmx.o raid6sse1.o raid6sse2.o
> +endif
> raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
> raid6int1.o raid6int2.o raid6int4.o \
> raid6int8.o raid6int16.o raid6int32.o \
> - raid6altivec1.o raid6altivec2.o raid6altivec4.o \
> - raid6altivec8.o \
> - raid6mmx.o raid6sse1.o raid6sse2.o
> + $(raid6-vec-objs)
> hostprogs-y := mktables
>
> # Note: link order is important. All raid personalities
>

Use raid6-$(CONFIG_FOO) instead.

--
Brian Gerst

2006-03-23 21:41:22

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Dave Jones <[email protected]> wrote:
>
> On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>
> > - Be aware that someone-who-doesn't-know-about-allmodconfig has screwed up
> > AGP on x86_64: if your link fails with various missing AGP symbols you'll
> > need to set the various CONFIG_AGP* symbols to `y' rather than `m'. Then
> > work out which other Kconfig rule keeps on flipping them back to `m' again,
> > then fix that too.
>
> I haven't merged anything into agpgart-git for a week or two, so it's
> more than likely..
>
> > +x86_64-mm-via-agp.patch
> > +x86_64-mm-sis-agp.patch
> >
> > x86_64 tree updates
>
>
> whatever these are.
>

THose patches come from someone who is pretending to be [email protected] ;)

We suspect the culprit is git-intelfb, which does

config FB_INTEL
tristate "Intel 830M/845G/852GM/855GM/865G support (EXPERIMENTAL)"
- depends on FB && EXPERIMENTAL && PCI && X86_32
+ depends on FB && EXPERIMENTAL && PCI && X86
select AGP
select AGP_INTEL
select FB_MODE_HELPERS

It's rather nasty that this can break the build.

It also seems plain wrong to me that a "select AGP" can force CONFIG_AGP=y
into CONFIG_AGP=m. There's no sense in that.

2006-03-23 22:33:06

by Jeff Garzik

[permalink] [raw]
Subject: Re: [PATCH] Lower e100 latency

J.A. Magallon wrote:
> if (unlikely(!i)) {
> - printk("e100.mdio_ctrl(%s) won't go Ready\n",
> + DPRINTK(PROBE, ERR, "e100.mdio_ctrl(%s) won't go Ready\n",
> nic->netdev->name );

NAK. Its already unlikely, and if this fails, you SHOULD print
something out. The rest seems mostly OK.

Jeff


2006-03-23 22:35:51

by David Miller

[permalink] [raw]
Subject: Re: [PATCH] Make __get_cpu_var use raw_smp_processor_id()

From: "J.A. Magallon" <[email protected]>
Date: Thu, 23 Mar 2006 22:11:25 +0100

> --- linux-2.6.15-rc5/include/asm-generic/percpu.h.orig 2005-12-21 15:13:27.000000000 -0600
> +++ linux-2.6.15-rc5/include/asm-generic/percpu.h 2005-12-21 15:13:43.000000000 -0600
> @@ -13,7 +13,7 @@ extern unsigned long __per_cpu_offset[NR
>
> /* var is in discarded region: offset to particular copy we want */
> #define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> -#define __get_cpu_var(var) per_cpu(var, smp_processor_id())
> +#define __get_cpu_var(var) per_cpu(var, raw_smp_processor_id())

I'm skeptical because this has caught real bugs in the past.

Unfortunately other platforms that hard-code the per-cpu
area into a cpu register, and thus implement __get_cpu_var()
without a smp_processor_id() call, don't get the debugging
check.

2006-03-23 22:53:14

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: 2.6.16-mm1

[I messed up this post, so I'm resending with the log trimmed etc.
Sorry for any inconvenience.]

On Thursday 23 March 2006 10:40, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/

On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
just fine):

}-- snip --{
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 1795.400 MHz processor.
disabling early console
Console: colour dummy device 80x25
time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x64/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:__do_softirq+0x66/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x46/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x49/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x4b/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:__do_softirq+0x4d/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x50/0xc0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:run_timer_softirq+0x0/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:run_timer_softirq+0x1/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:run_timer_softirq+0x4/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:run_timer_softirq+0xc/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:run_timer_softirq+0xd/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:run_timer_softirq+0x11/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:run_timer_softirq+0x18/0x1f0
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:hrtimer_run_queues+0x54/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:hrtimer_run_queues+0x54/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:hrtimer_run_queues+0x58/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:hrtimer_run_queues+0x5f/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:hrtimer_run_queues+0x65/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:hrtimer_run_queues+0x73/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:hrtimer_run_queues+0x77/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:hrtimer_run_queues+0x82/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:hrtimer_run_queues+0x86/0x120
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:_spin_lock_irq+0x0/0x30
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:_spin_lock_irq+0x1/0x30
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__local_irq_disable+0x1/0x20
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__local_irq_disable+0x1/0x20
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:__local_irq_disable+0x1/0x20
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__local_irq_disable+0xf/0x20
last cli 0x0
last cli caller 0x0
time.c: Lost 4 timer tick(s)! rip 10:__local_irq_disable+0xf/0x20
last cli 0x0
last cli caller 0x0
time.c: Lost 3 timer tick(s)! rip 10:__local_irq_disable+0x16/0x20
last cli 0x0
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:_spin_unlock_irq+0xf/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:_spin_unlock_irq+0xf/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:sub_preempt_count+0x0/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:sub_preempt_count+0x1/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:sub_preempt_count+0xd/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:sub_preempt_count+0x13/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:sub_preempt_count+0x26/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:sub_preempt_count+0x31/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:sub_preempt_count+0x38/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:sub_preempt_count+0x4d/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:sub_preempt_count+0x53/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:sub_preempt_count+0x54/0x60
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:_spin_unlock_irq+0x14/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:_spin_unlock_irq+0x31/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:_spin_unlock_irq+0x31/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:_spin_unlock_irq+0x31/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:hrtimer_run_queues+0x105/0x120
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:hrtimer_run_queues+0x73/0x120
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:hrtimer_run_queues+0x73/0x120
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:hrtimer_run_queues+0x77/0x120
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:hrtimer_run_queues+0x82/0x120
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:hrtimer_run_queues+0x86/0x120
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:_spin_lock_irq+0x0/0x30
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:_spin_lock_irq+0x1/0x30
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:__local_irq_disable+0x5/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:__local_irq_disable+0x6/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:__local_irq_disable+0x6/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:__local_irq_disable+0xf/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:__local_irq_disable+0x16/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:__local_irq_disable+0x1d/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 5 timer tick(s)! rip 10:__local_irq_disable+0x1d/0x20
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
time.c: Lost 6 timer tick(s)! rip 10:_spin_unlock_irq+0xf/0x40
last cli _spin_lock_irq+0x15/0x30
last cli caller hrtimer_run_queues+0x8e/0x120
}-- cut --{

2006-03-23 23:42:20

by Adrian Bunk

[permalink] [raw]
Subject: 2.6.16-mm1: CONFIG_HOTPLUG_CPU compile error

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> +check-if-cpu-can-be-onlined-before-calling-smp_prepare_cpu.patch
>...
> Random stuff.
>...

This patch broke compilation with CONFIG_HOTPLUG_CPU=y:

<-- snip -->

...
CC arch/i386/kernel/smpboot.o
arch/i386/kernel/smpboot.c: In function '__cpu_up':
arch/i386/kernel/smpboot.c:1429: warning: implicit declaration of function '__smp_prepare_cpu'
...
LD .tmp_vmlinux1
arch/i386/kernel/built-in.o: In function `__cpu_up': undefined reference to `__smp_prepare_cpu'
make: *** [.tmp_vmlinux1] Error 1

<-- snip -->

cu
Adrian

--

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

2006-03-23 23:55:28

by Adrian Bunk

[permalink] [raw]
Subject: [RFC: -mm patch] remove drm_{alloc,free}_pages

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> git-drm.patch
>...
> git trees.
>...

drm_alloc_pages and drm_free_pages can now be removed.

Signed-off-by: Adrian Bunk <[email protected]>

---

drivers/char/drm/drmP.h | 2
drivers/char/drm/drm_memory.c | 59 -----------------------
drivers/char/drm/drm_memory_debug.h | 70 ----------------------------
3 files changed, 131 deletions(-)

--- linux-2.6.16-mm1-full/drivers/char/drm/drmP.h.old 2006-03-23 23:05:06.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/char/drm/drmP.h 2006-03-23 23:05:37.000000000 +0100
@@ -813,8 +813,6 @@
extern int drm_mem_info(char *buf, char **start, off_t offset,
int request, int *eof, void *data);
extern void *drm_realloc(void *oldpt, size_t oldsize, size_t size, int area);
-extern unsigned long drm_alloc_pages(int order, int area);
-extern void drm_free_pages(unsigned long address, int order, int area);
extern void *drm_ioremap(unsigned long offset, unsigned long size,
drm_device_t * dev);
extern void *drm_ioremap_nocache(unsigned long offset, unsigned long size,
--- linux-2.6.16-mm1-full/drivers/char/drm/drm_memory_debug.h.old 2006-03-23 23:05:19.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/char/drm/drm_memory_debug.h 2006-03-23 23:05:30.000000000 +0100
@@ -206,76 +206,6 @@
}
}

-unsigned long drm_alloc_pages (int order, int area) {
- unsigned long address;
- unsigned long bytes = PAGE_SIZE << order;
- unsigned long addr;
- unsigned int sz;
-
- spin_lock(&drm_mem_lock);
- if ((drm_ram_used >> PAGE_SHIFT)
- > (DRM_RAM_PERCENT * drm_ram_available) / 100) {
- spin_unlock(&drm_mem_lock);
- return 0;
- }
- spin_unlock(&drm_mem_lock);
-
- address = __get_free_pages(GFP_KERNEL|__GFP_COMP, order);
- if (!address) {
- spin_lock(&drm_mem_lock);
- ++drm_mem_stats[area].fail_count;
- spin_unlock(&drm_mem_lock);
- return 0;
- }
- spin_lock(&drm_mem_lock);
- ++drm_mem_stats[area].succeed_count;
- drm_mem_stats[area].bytes_allocated += bytes;
- drm_ram_used += bytes;
- spin_unlock(&drm_mem_lock);
-
- /* Zero outside the lock */
- memset((void *)address, 0, bytes);
-
- /* Reserve */
- for (addr = address, sz = bytes;
- sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- SetPageReserved(virt_to_page(addr));
- }
-
- return address;
-}
-
-void drm_free_pages (unsigned long address, int order, int area) {
- unsigned long bytes = PAGE_SIZE << order;
- int alloc_count;
- int free_count;
- unsigned long addr;
- unsigned int sz;
-
- if (!address) {
- DRM_MEM_ERROR(area, "Attempt to free address 0\n");
- } else {
- /* Unreserve */
- for (addr = address, sz = bytes;
- sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- ClearPageReserved(virt_to_page(addr));
- }
- free_pages(address, order);
- }
-
- spin_lock(&drm_mem_lock);
- free_count = ++drm_mem_stats[area].free_count;
- alloc_count = drm_mem_stats[area].succeed_count;
- drm_mem_stats[area].bytes_freed += bytes;
- drm_ram_used -= bytes;
- spin_unlock(&drm_mem_lock);
- if (free_count > alloc_count) {
- DRM_MEM_ERROR(area,
- "Excess frees: %d frees, %d allocs\n",
- free_count, alloc_count);
- }
-}
-
void *drm_ioremap (unsigned long offset, unsigned long size,
drm_device_t * dev) {
void *pt;
--- linux-2.6.16-mm1-full/drivers/char/drm/drm_memory.c.old 2006-03-23 23:05:54.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/char/drm/drm_memory.c 2006-03-23 23:06:11.000000000 +0100
@@ -79,65 +79,6 @@
return pt;
}

-/**
- * Allocate pages.
- *
- * \param order size order.
- * \param area memory area. (Not used.)
- * \return page address on success, or zero on failure.
- *
- * Allocate and reserve free pages.
- */
-unsigned long drm_alloc_pages(int order, int area)
-{
- unsigned long address;
- unsigned long bytes = PAGE_SIZE << order;
- unsigned long addr;
- unsigned int sz;
-
- address = __get_free_pages(GFP_KERNEL|__GFP_COMP, order);
- if (!address)
- return 0;
-
- /* Zero */
- memset((void *)address, 0, bytes);
-
- /* Reserve */
- for (addr = address, sz = bytes;
- sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- SetPageReserved(virt_to_page(addr));
- }
-
- return address;
-}
-
-/**
- * Free pages.
- *
- * \param address address of the pages to free.
- * \param order size order.
- * \param area memory area. (Not used.)
- *
- * Unreserve and free pages allocated by alloc_pages().
- */
-void drm_free_pages(unsigned long address, int order, int area)
-{
- unsigned long bytes = PAGE_SIZE << order;
- unsigned long addr;
- unsigned int sz;
-
- if (!address)
- return;
-
- /* Unreserve */
- for (addr = address, sz = bytes;
- sz > 0; addr += PAGE_SIZE, sz -= PAGE_SIZE) {
- ClearPageReserved(virt_to_page(addr));
- }
-
- free_pages(address, order);
-}
-
#if __OS_HAS_AGP
/** Wrapper around agp_allocate_memory() */
DRM_AGP_MEM *drm_alloc_agp(drm_device_t * dev, int pages, u32 type)

2006-03-23 23:57:27

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] drivers/video/intelfb/intelfbhw.c: make struct plls static

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> git-intelfb.patch
>...
> git trees.
>...

This patch makes a needlessly global struct static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.16-mm1-full/drivers/video/intelfb/intelfbhw.c.old 2006-03-23 23:12:20.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/video/intelfb/intelfbhw.c 2006-03-23 23:12:30.000000000 +0100
@@ -56,7 +56,7 @@
#define PLLS_I9xx 1
#define PLLS_MAX 2

-struct pll_min_max plls[PLLS_MAX] = {
+static struct pll_min_max plls[PLLS_MAX] = {
{ 108, 140, 18, 26, 6, 16, 3, 16, 4, 128, 0, 31, 930000, 1400000, 165000, 4, 22 }, //I8xx
{ 75, 120, 10, 20, 5, 9, 4, 7, 5, 80, 1, 8, 930000, 2800000, 200000, 10, 5 } //I9xx
};

2006-03-24 00:00:08

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] make drivers/char/ipmi/ipmi_msghandler.c:ipmi_find_bmc_guid() static

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> +ipmi-add-full-sysfs-support.patch
>...
> Random stuff.
>...


This patch makes a needlessly global function static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.16-mm1-full/drivers/char/ipmi/ipmi_msghandler.c.old 2006-03-23 23:10:10.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/char/ipmi/ipmi_msghandler.c 2006-03-23 23:10:30.000000000 +0100
@@ -1754,8 +1754,8 @@
return memcmp(bmc->guid, id, 16) == 0;
}

-struct bmc_device * ipmi_find_bmc_guid(struct device_driver *drv,
- unsigned char *guid)
+static struct bmc_device *ipmi_find_bmc_guid(struct device_driver *drv,
+ unsigned char *guid)
{
struct device *dev;


2006-03-24 00:02:45

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

"R. J. Wysocki" <[email protected]> wrote:
>
> On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
>
> On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> just fine, .config attached):

hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.

> }-- snip --{
> PID hash table entries: 4096 (order: 12, 32768 bytes)
> time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> time.c: Detected 1795.400 MHz processor.
> disabling early console
> Console: colour dummy device 80x25
> time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> last cli 0x0
> last cli caller 0x0
> time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> last cli 0x0
> last cli caller 0x0
> time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0

Hi, John.

2006-03-24 00:02:25

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] drivers/char/ipmi/ipmi_si_intf.c: make a struct static

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> +ipmi-add-generic-pci-handling.patch
>...
> Random stuff.
>...

This patch makes a needlessly global struct static.

Signed-off-by: Adrian Bunk <[email protected]>

--- linux-2.6.16-mm1-full/drivers/char/ipmi/ipmi_si_intf.c.old 2006-03-23 23:10:58.000000000 +0100
+++ linux-2.6.16-mm1-full/drivers/char/ipmi/ipmi_si_intf.c 2006-03-23 23:11:10.000000000 +0100
@@ -2167,7 +2167,7 @@
del_timer_sync(&smi_info->si_timer);
}

-struct ipmi_default_vals
+static struct ipmi_default_vals
{
int type;
int port;

2006-03-24 00:17:38

by john stultz

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Thu, 2006-03-23 at 16:04 -0800, Andrew Morton wrote:
> "R. J. Wysocki" <[email protected]> wrote:
> >
> > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
> > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > just fine, .config attached):
>
> hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.
>
> > }-- snip --{
> > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> > time.c: Detected 1795.400 MHz processor.
> > disabling early console
> > Console: colour dummy device 80x25
> > time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> > last cli 0x0
> > last cli caller 0x0
> > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > last cli 0x0
> > last cli caller 0x0
> > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
>
> Hi, John.

Hi. :)

Hmmmm. Not sure how this would relate to the TOD bits, but they might be
somehow causing it.

Rafael, could you send me the full dmesg and .config info and I'll try
to find a box to reproduce this on?

thanks
-john


2006-03-24 00:39:07

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Friday 24 March 2006 01:04, Andrew Morton wrote:
> "R. J. Wysocki" <[email protected]> wrote:
> >
> > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
> > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > just fine, .config attached):
>
> hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.

Well, I'll be doing this anyway. ;-)

2006-03-24 00:50:13

by john stultz

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Thu, 2006-03-23 at 16:04 -0800, Andrew Morton wrote:
> "R. J. Wysocki" <[email protected]> wrote:
> >
> > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> >
> > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > just fine, .config attached):
>
> hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.
>
> > }-- snip --{
> > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> > time.c: Detected 1795.400 MHz processor.
> > disabling early console
> > Console: colour dummy device 80x25
> > time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> > last cli 0x0
> > last cli caller 0x0
> > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > last cli 0x0
> > last cli caller 0x0
> > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0

It seems report_lost_ticks has been set to one w/ 2.6.16-mm1, thus these
debug messages will be shown.

Rafael: To properly compare, could you boot 2.6.16-rc6-mm2 w/ the
"report_lost_ticks" boot option and see if the same sort of messages do
not appear?

thanks
-john

2006-03-24 01:01:23

by Raj, Ashok

[permalink] [raw]
Subject: Re: 2.6.16-mm1: CONFIG_HOTPLUG_CPU compile error

On Fri, Mar 24, 2006 at 12:42:17AM +0100, Adrian Bunk wrote:
> arch/i386/kernel/smpboot.c:1429: warning: implicit declaration of function '__smp_prepare_cpu'
> ...
> LD .tmp_vmlinux1
> arch/i386/kernel/built-in.o: In function `__cpu_up': undefined reference to `__smp_prepare_cpu'
> make: *** [.tmp_vmlinux1] Error 1
>
yes,

apparently the one that was sent to andrew and i got a confirmation for -mm is different
from whats on the broken-out patches.

I sent an email about it this mornig, havent heard from andrew yet.



ashok

2006-03-24 01:06:12

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Friday 24 March 2006 01:49, john stultz wrote:
> On Thu, 2006-03-23 at 16:04 -0800, Andrew Morton wrote:
> > "R. J. Wysocki" <[email protected]> wrote:
> > >
> > > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> > >
> > > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > > just fine, .config attached):
> >
> > hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.
> >
> > > }-- snip --{
> > > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > > time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> > > time.c: Detected 1795.400 MHz processor.
> > > disabling early console
> > > Console: colour dummy device 80x25
> > > time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> > > last cli 0x0
> > > last cli caller 0x0
> > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > > last cli 0x0
> > > last cli caller 0x0
> > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
>
> It seems report_lost_ticks has been set to one w/ 2.6.16-mm1, thus these
> debug messages will be shown.
>
> Rafael: To properly compare, could you boot 2.6.16-rc6-mm2 w/ the
> "report_lost_ticks" boot option and see if the same sort of messages do
> not appear?

It looks similar but not the same:

}-- snip --{
Kernel command line: root=/dev/hdc6 vga=792 selinux=0 noapic resume=/dev/hdc3 console=ttyS0,57600 console=tty0 earlyprintk=serial,ttyS0,5760
0 debug report_lost_ticks init=/bin/bash
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
time.c: Detected 1795.371 MHz processor.
disabling early console
Console: colour dummy device 80x25
time.c: Lost 104 timer tick(s)! rip start_kernel+0x11d/0x210)
time.c: Lost 2 timer tick(s)! rip __do_softirq+0x44/0xb0)
time.c: Lost 2 timer tick(s)! rip __do_softirq+0x44/0xb0)
time.c: Lost 1 timer tick(s)! rip __do_softirq+0x50/0xb0)
time.c: Lost 2 timer tick(s)! rip run_timer_softirq+0x0/0x1f0)
time.c: Lost 2 timer tick(s)! rip run_timer_softirq+0x1/0x1f0)
time.c: Lost 1 timer tick(s)! rip hrtimer_run_queues+0x1/0x120)
time.c: Lost 2 timer tick(s)! rip hrtimer_run_queues+0x43/0x120)
time.c: Lost 2 timer tick(s)! rip hrtimer_run_queues+0x58/0x120)
time.c: Lost 2 timer tick(s)! rip _spin_lock_irq+0x1/0x30)
time.c: Lost 2 timer tick(s)! rip _spin_lock_irq+0x1/0x30)
time.c: Lost 1 timer tick(s)! rip _spin_lock_irq+0x4/0x30)
time.c: Lost 2 timer tick(s)! rip _spin_unlock_irq+0xf/0x40)
time.c: Lost 2 timer tick(s)! rip _spin_unlock_irq+0x30/0x40)
time.c: Lost 1 timer tick(s)! rip hrtimer_run_queues+0x77/0x120)
time.c: Lost 2 timer tick(s)! rip hrtimer_run_queues+0x77/0x120)
time.c: Lost 2 timer tick(s)! rip _spin_lock_irq+0x8/0x30)
time.c: Lost 2 timer tick(s)! rip _spin_unlock_irq+0xf/0x40)
time.c: Lost 1 timer tick(s)! rip sub_preempt_count+0x26/0x60)
time.c: Lost 2 timer tick(s)! rip _spin_unlock_irq+0x31/0x40)
time.c: Lost 2 timer tick(s)! rip hrtimer_run_queues+0x112/0x120)
time.c: Lost 2 timer tick(s)! rip _spin_lock_irq+0x1/0x30)
time.c: Lost 1 timer tick(s)! rip _spin_unlock_irq+0xf/0x40)
time.c: Lost 2 timer tick(s)! rip run_timer_softirq+0x1da/0x1f0)
time.c: Lost 2 timer tick(s)! rip __do_softirq+0x44/0xb0)
time.c: Lost 2 timer tick(s)! rip __do_softirq+0x50/0xb0)
time.c: Lost 1 timer tick(s)! rip hrtimer_run_queues+0x58/0x120)
}-- cut --{

Rafael

2006-03-24 01:12:57

by john stultz

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Fri, 2006-03-24 at 02:04 +0100, Rafael J. Wysocki wrote:
> On Friday 24 March 2006 01:49, john stultz wrote:
> > On Thu, 2006-03-23 at 16:04 -0800, Andrew Morton wrote:
> > > "R. J. Wysocki" <[email protected]> wrote:
> > > >
> > > > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> > > >
> > > > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > > > just fine, .config attached):
> > >
> > > hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.
> > >
> > > > }-- snip --{
> > > > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > > > time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> > > > time.c: Detected 1795.400 MHz processor.
> > > > disabling early console
> > > > Console: colour dummy device 80x25
> > > > time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> > > > last cli 0x0
> > > > last cli caller 0x0
> > > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > > > last cli 0x0
> > > > last cli caller 0x0
> > > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> >
> > It seems report_lost_ticks has been set to one w/ 2.6.16-mm1, thus these
> > debug messages will be shown.
> >
> > Rafael: To properly compare, could you boot 2.6.16-rc6-mm2 w/ the
> > "report_lost_ticks" boot option and see if the same sort of messages do
> > not appear?
>
> It looks similar but not the same:

Yea, I think thats due to some new code from Andi.

The lost tick issue should be looked into (might be hardware SMIs), but
it seems this is not caused by my patches.

thanks
-john

2006-03-24 01:24:34

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Friday 24 March 2006 02:12, john stultz wrote:
> On Fri, 2006-03-24 at 02:04 +0100, Rafael J. Wysocki wrote:
> > On Friday 24 March 2006 01:49, john stultz wrote:
> > > On Thu, 2006-03-23 at 16:04 -0800, Andrew Morton wrote:
> > > > "R. J. Wysocki" <[email protected]> wrote:
> > > > >
> > > > > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > > > > >
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> > > > >
> > > > > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > > > > just fine, .config attached):
> > > >
> > > > hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.
> > > >
> > > > > }-- snip --{
> > > > > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > > > > time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> > > > > time.c: Detected 1795.400 MHz processor.
> > > > > disabling early console
> > > > > Console: colour dummy device 80x25
> > > > > time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> > > > > last cli 0x0
> > > > > last cli caller 0x0
> > > > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > > > > last cli 0x0
> > > > > last cli caller 0x0
> > > > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > >
> > > It seems report_lost_ticks has been set to one w/ 2.6.16-mm1, thus these
> > > debug messages will be shown.
> > >
> > > Rafael: To properly compare, could you boot 2.6.16-rc6-mm2 w/ the
> > > "report_lost_ticks" boot option and see if the same sort of messages do
> > > not appear?
> >
> > It looks similar but not the same:
>
> Yea, I think thats due to some new code from Andi.
>
> The lost tick issue should be looked into (might be hardware SMIs), but
> it seems this is not caused by my patches.

You are right. All of this is caused by report_lost_ticks set to 1.
The appended patch helps.

Thanks,
Rafael

---
arch/x86_64/kernel/time.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.16-mm1/arch/x86_64/kernel/time.c
===================================================================
--- linux-2.6.16-mm1.orig/arch/x86_64/kernel/time.c
+++ linux-2.6.16-mm1/arch/x86_64/kernel/time.c
@@ -63,7 +63,7 @@ static unsigned long hpet_period; /* f
unsigned long hpet_tick; /* HPET clocks / interrupt */
int hpet_use_timer; /* Use counter of hpet for time keeping, otherwise PIT */
unsigned long vxtime_hz = PIT_TICK_RATE;
-int report_lost_ticks = 1; /* command line option */
+int report_lost_ticks; /* command line option */
unsigned long long monotonic_base;

struct vxtime_data __vxtime __section_vxtime; /* for vsyscalls */

2006-03-24 01:26:06

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

john stultz <[email protected]> wrote:
>
> On Thu, 2006-03-23 at 16:04 -0800, Andrew Morton wrote:
> > "R. J. Wysocki" <[email protected]> wrote:
> > >
> > > On Thursday 23 March 2006 10:40, Andrew Morton wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/
> > >
> > > On a uniprocessor AMD64 w/ CONFIG_SMP unset (2.6.16-rc6-mm2 works on this box
> > > just fine, .config attached):
> >
> > hm, uniproc x86_64 seems to cause problems sometimes. I should test it more.
> >
> > > }-- snip --{
> > > PID hash table entries: 4096 (order: 12, 32768 bytes)
> > > time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer.
> > > time.c: Detected 1795.400 MHz processor.
> > > disabling early console
> > > Console: colour dummy device 80x25
> > > time.c: Lost 103 timer tick(s)! rip 10:start_kernel+0x121/0x220
> > > last cli 0x0
> > > last cli caller 0x0
> > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
> > > last cli 0x0
> > > last cli caller 0x0
> > > time.c: Lost 3 timer tick(s)! rip 10:__do_softirq+0x44/0xc0
>
> It seems report_lost_ticks has been set to one w/ 2.6.16-mm1, thus these
> debug messages will be shown.
>
> Rafael: To properly compare, could you boot 2.6.16-rc6-mm2 w/ the
> "report_lost_ticks" boot option and see if the same sort of messages do
> not appear?

<looks>

OK, we have an andi-easter-egg:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/x86_64-mm-lost-cli-debug.patch.

So you're right, it's not the time patches. I just blame you whenever anything
time-related goes wrong - who else is there? ;)

The above patch records the most-recent caller of local_irq_disable() in a
global variable, then prints that out in the lost-ticks handler. But how
do we know that the global didn't get overwritten between the most-recent
local_irq_enable() and the call to handle_lost_ticks()?

I guess the code assumes that the local_irq_enable() will result in
insta-entry into the timer IRQ handler. Which is probably good enough, as
interrupts from other sources won't be pending most times.

So why did we lose three ticks after __do_sortirq()'s local_irq_disable()?
Dunno.

I think a better debugging patch would be:

u64 timestamp[NR_CPUS];

local_irq_disable()
{
cli;
timestamp[me] = rdtslcc();
}

local_irq_enable()
{
if (rdtscll() - timestamp[me] > enough)
whine();
sti;
}

(Is there any point in do_softirq() doing local_irq_save() instead of
local_irq_disable()? __do_softirq() will unconditionally enable anyway..)


2006-03-24 02:17:32

by Brandon Low

[permalink] [raw]
Subject: Re: 2.6.16-mm1

I'm getting a repeatable oops regardless of io scheduler (it looks like
it's in cfq code so I first tried changing schedulers) on USB
disconnect.

Kernel is built for athlon k8, but running in 32 bit mode. Tainted by a
madwifi driver which should have no impact on the problem area.

Oops follows, and kernel config attached.

Brandon

usb 1-8: USB disconnect, address 6
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000102
printing eip:
c023e447
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /block/sda/sda2/size
Modules linked in: nls_cp437 deadline_iosched sd_mod vfat fat wlan_tkip wlan_scan_sta ath_pci ath_rate_sample wlan ath_hal w83627hf
hwmon_vid eeprom i2c_isa i2c_ali1563 i2c_core snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_ali5451 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc rtc pcspkr
CPU: 1
EIP: 0060:[<c023e447>] Tainted: PF VLI
EFLAGS: 00010046 (2.6.16-mm1 #1)
EIP is at cfq_exit_single_io_context+0x27/0x110
eax: 00000086 ebx: f7dcc124 ecx: f7dcc124 edx: f7dcc124
esi: f645b200 edi: 00000006 ebp: 0000000f esp: f6a99e44
ds: 007b es: 007b ss: 0068
Process hald-addon-stor (pid: 11786, threadinfo=f6a99000 task=f6546030)
Stack: <0>f65460e8 00000001 f6c1c070 f6546030 f7dcc124 00000282 c1b4d384 c023e55a
f7dcc124 f6a99000 00000286 c02398c7 c1b4d384 c18de960 f6546030 c1b4d384
c01213f6 f6546030 c0452b40 f654649c f6a99f24 00000001 f7e66500 f6a99000
Call Trace:
<c023e55a> cfq_exit_io_context+0x2a/0x50 <c02398c7> exit_io_context+0x87/0xb0
<c01213f6> do_exit+0x2a6/0x460 <c012161c> do_group_exit+0x3c/0x90
<c012c6c9> get_signal_to_deliver+0x229/0x300 <c0102da9> do_signal+0x69/0x160
<c013781e> ktime_get_ts+0x5e/0x70 <c0246ca2> copy_to_user+0x42/0x60
<c013807e> hrtimer_nanosleep+0xce/0x150 <c0137f90> nanosleep_wakeup+0x0/0x20
<c0138167> sys_nanosleep+0x67/0x70 <c0102ed8> do_notify_resume+0x38/0x3c
<c0103076> work_notifysig+0x13/0x19
Code: 00 00 00 00 83 ec 1c 89 5c 24 10 8b 5c 24 20 89 74 24 14 89 7c 24 18 8b 73 10 85 f6 74 65 8b 3e 9c 58 f6 c4 02 0f 85 82 00 00
00 <8b> 87 fc 00 00 00 e8 0e 3b 15 00 8b 43 14 85 c0 75 57 8b 43 18
<1>Fixing recursive fault but reboot is needed!



Attachments:
(No filename) (2.22 kB)
kernel.config (36.51 kB)
Download all attachments

2006-03-24 02:27:39

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Brandon Low <[email protected]> wrote:
>
> I'm getting a repeatable oops regardless of io scheduler (it looks like
> it's in cfq code so I first tried changing schedulers) on USB
> disconnect.
>
> Kernel is built for athlon k8, but running in 32 bit mode. Tainted by a
> madwifi driver which should have no impact on the problem area.
>
> Oops follows, and kernel config attached.
>
> Brandon
>
> usb 1-8: USB disconnect, address 6
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000102
> printing eip:
> c023e447
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> last sysfs file: /block/sda/sda2/size
> Modules linked in: nls_cp437 deadline_iosched sd_mod vfat fat wlan_tkip wlan_scan_sta ath_pci ath_rate_sample wlan ath_hal w83627hf
> hwmon_vid eeprom i2c_isa i2c_ali1563 i2c_core snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_ali5451 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc rtc pcspkr
> CPU: 1
> EIP: 0060:[<c023e447>] Tainted: PF VLI
> EFLAGS: 00010046 (2.6.16-mm1 #1)
> EIP is at cfq_exit_single_io_context+0x27/0x110
> eax: 00000086 ebx: f7dcc124 ecx: f7dcc124 edx: f7dcc124
> esi: f645b200 edi: 00000006 ebp: 0000000f esp: f6a99e44
> ds: 007b es: 007b ss: 0068
> Process hald-addon-stor (pid: 11786, threadinfo=f6a99000 task=f6546030)
> Stack: <0>f65460e8 00000001 f6c1c070 f6546030 f7dcc124 00000282 c1b4d384 c023e55a
> f7dcc124 f6a99000 00000286 c02398c7 c1b4d384 c18de960 f6546030 c1b4d384
> c01213f6 f6546030 c0452b40 f654649c f6a99f24 00000001 f7e66500 f6a99000
> Call Trace:
> <c023e55a> cfq_exit_io_context+0x2a/0x50 <c02398c7> exit_io_context+0x87/0xb0
> <c01213f6> do_exit+0x2a6/0x460 <c012161c> do_group_exit+0x3c/0x90
> <c012c6c9> get_signal_to_deliver+0x229/0x300 <c0102da9> do_signal+0x69/0x160
> <c013781e> ktime_get_ts+0x5e/0x70 <c0246ca2> copy_to_user+0x42/0x60
> <c013807e> hrtimer_nanosleep+0xce/0x150 <c0137f90> nanosleep_wakeup+0x0/0x20
> <c0138167> sys_nanosleep+0x67/0x70 <c0102ed8> do_notify_resume+0x38/0x3c
> <c0103076> work_notifysig+0x13/0x19
> Code: 00 00 00 00 83 ec 1c 89 5c 24 10 8b 5c 24 20 89 74 24 14 89 7c 24 18 8b 73 10 85 f6 74 65 8b 3e 9c 58 f6 c4 02 0f 85 82 00 00
> 00 <8b> 87 fc 00 00 00 e8 0e 3b 15 00 8b 43 14 85 c0 75 57 8b 43 18
> <1>Fixing recursive fault but reboot is needed!
>

OK, thanks. There have been some recent changes affecting iosched context
lifetime management, which might be causing this.

If you have time, it'd be useful if you could retest with
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.16-git6.gz -
that'll tell us whether it's that code or if it's something which is only
in -mm.

2006-03-24 02:45:42

by Brandon Low

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Thu, 03/23/06 at 18:24:11 -0800, Andrew Morton wrote:
> Brandon Low <[email protected]> wrote:
> >
> > I'm getting a repeatable oops regardless of io scheduler (it looks like
> > it's in cfq code so I first tried changing schedulers) on USB
> > disconnect.
> >
> OK, thanks. There have been some recent changes affecting iosched context
> lifetime management, which might be causing this.
>
> If you have time, it'd be useful if you could retest with
> ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.16-git6.gz -
> that'll tell us whether it's that code or if it's something which is only
> in -mm.

Unable to reproduce with identical steps on git6. Thanks for the
amazingly quick response!

Brandon

2006-03-24 03:01:38

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Brandon Low <[email protected]> wrote:
>
> On Thu, 03/23/06 at 18:24:11 -0800, Andrew Morton wrote:
> > Brandon Low <[email protected]> wrote:
> > >
> > > I'm getting a repeatable oops regardless of io scheduler (it looks like
> > > it's in cfq code so I first tried changing schedulers) on USB
> > > disconnect.
> > >
> > OK, thanks. There have been some recent changes affecting iosched context
> > lifetime management, which might be causing this.
> >
> > If you have time, it'd be useful if you could retest with
> > ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.16-git6.gz -
> > that'll tell us whether it's that code or if it's something which is only
> > in -mm.
>
> Unable to reproduce with identical steps on git6.

ok..

I tried various combinations of plugging, mounting, unmounting and
unplugging a USB memory stick. No problems.

Can you prepare a step-by-step guide to making this happen?

Thanks.

2006-03-24 03:21:27

by Brandon Low

[permalink] [raw]
Subject: Re: 2.6.16-mm1

I hadn't noticed immediately in the ooops, but it is something to do
with the Hardware Abstraction Layer Daemon from http://freedesktop.org/Software/hal
I can't reproduce it without that daemon loaded either. I wonder if the
last accessed sysfs file mentioned in the oops (sda/size) is relevent
also.

My exact steps (with hald loaded) are:
plug in ipod
mount /mnt/ipod
unzip -d /mnt/ipod rockbox.zip
eject /dev/sda
unplug ipod
immediately here, the oops prints.

Interestingly after this happens, the system remains at a pretty high
level of functioning, and further mounts and unmounts and ejects of the
ipod do not cause another oops.

On Thu, 03/23/06 at 18:58:10 -0800, Andrew Morton wrote:
> Brandon Low <[email protected]> wrote:
> >
> > On Thu, 03/23/06 at 18:24:11 -0800, Andrew Morton wrote:
> > > Brandon Low <[email protected]> wrote:
> > > >
> > > > I'm getting a repeatable oops regardless of io scheduler (it looks like
> > > > it's in cfq code so I first tried changing schedulers) on USB
> > > > disconnect.
> > > >
> > > OK, thanks. There have been some recent changes affecting iosched context
> > > lifetime management, which might be causing this.
> > >
> > > If you have time, it'd be useful if you could retest with
> > > ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.16-git6.gz -
> > > that'll tell us whether it's that code or if it's something which is only
> > > in -mm.
> >
> > Unable to reproduce with identical steps on git6.
>
> ok..
>
> I tried various combinations of plugging, mounting, unmounting and
> unplugging a USB memory stick. No problems.
>
> Can you prepare a step-by-step guide to making this happen?
>
> Thanks.

2006-03-24 03:47:47

by Andi Kleen

[permalink] [raw]
Subject: Re: 2.6.16-mm1

> The above patch records the most-recent caller of local_irq_disable() in a
> global variable, then prints that out in the lost-ticks handler. But how
> do we know that the global didn't get overwritten between the most-recent
> local_irq_enable() and the call to handle_lost_ticks()?

Because the overdue timer interrupt will trigger one instruction later.

>
> I guess the code assumes that the local_irq_enable() will result in
> insta-entry into the timer IRQ handler. Which is probably good enough, as
> interrupts from other sources won't be pending most times.

Yes. Actually irq 0 has higher priority than most interrupts,
but not all.


>
> So why did we lose three ticks after __do_sortirq()'s local_irq_disable()?
> Dunno.

It's a mistery. I put the patches in to trace a pattern.

But you're right they should at least be using per cpu variables
instead of globals which can be corrupted by other CPUs.

> (Is there any point in do_softirq() doing local_irq_save() instead of
> local_irq_disable()? __do_softirq() will unconditionally enable anyway..)

The interrupt handling in there is quite messy and has some other
wards too. Could probably take a good cleanup. Problem is that
it will need a lot of editing of architectures to do properly.

-Andi

2006-03-24 11:28:44

by Roman Zippel

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Hi,

On Thu, 23 Mar 2006, Russell King wrote:

> Okay, so the default is now 'm', but the legal values are still only 'n'
> and 'm'. I can only select 'm' or 'n', and this is what I end up with in
> the config file. Now, if I remove the prompt text:
>
> config SYM_D
> tristate
> depends on SYM_M && SYM_Y
> default y
>
> and hey presto, suddenly 'y' becomes a legal value.
>
> CONFIG_SYM_Y=y
> CONFIG_SYM_M=m
> CONFIG_SYM_D=y
>
> So it would seem to be a Kconfig bug.

No, it's not a bug, that's really the correct behaviour. It has its roots
in the cml1 converter, where statements like this:

if [ "$CONFIG_FOO" = "y" ]; then
define_tristate CONFIG_BAR y
fi

would become:

config BAR
default y
depends on FOO=y

The basic idea is that the dependency only enables the default and the
default sets the symbol to whatever you want.

I thought about the other behaviour, but at that time the if syntax or
select didn't exists yet, so it really wasn't a problem yet and I decided
to keep it closer to cml1 instead.

In the meantime the Kconfig syntax has grown and this is not the first
time this has come up. I'm not completely opposed against changing the
behaviour, but I don't want to do it just for fun either. It would require
at least to grep through the current Kconfig rules to check whether
something depends on the current behaviour.

As alternative you can change the default to "SYM_M" (basically repeating
the dependency without the booleans).

bye, Roman

2006-03-24 11:43:08

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Brandon Low <[email protected]> wrote:
>
> I hadn't noticed immediately in the ooops, but it is something to do
> with the Hardware Abstraction Layer Daemon from http://freedesktop.org/Software/hal
> I can't reproduce it without that daemon loaded either. I wonder if the
> last accessed sysfs file mentioned in the oops (sda/size) is relevent
> also.
>
> My exact steps (with hald loaded) are:
> plug in ipod
> mount /mnt/ipod
> unzip -d /mnt/ipod rockbox.zip
> eject /dev/sda
> unplug ipod
> immediately here, the oops prints.

Still no joy, alas.

git-cfq.patch plays with the elevator exit code for all IO schedulers.
Would you be able to do

wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/git-cfq.patch
patch -p1 -R < git-cfq.patch

and retest?

Thanks.

2006-03-24 11:56:08

by Mike Galbraith

[permalink] [raw]
Subject: 2.6.16-mm1 grub oddness

Greetings,

I'm seeing strange things with grub with this kernel. After my box has
been up for a while, and I reboot, selecting a kernel to restart, upon
reboot, I sometimes (fairly often) get a blank screen staring at me
though I see grub doing it's thing. Poking the power button results in
an immediate poweroff, not as if the kernel had panicked or whatnot very
early in boot. Very odd, and never before seen.

(I was worried that my scheduler stuff was causing weird interactions,
but after testing, it's not me, it's there in virgin source.)

-Mike

2006-03-24 12:10:12

by Roman Zippel

[permalink] [raw]
Subject: [PATCH] use select for GART_IOMMU to enable AGP

Hi,

On Thu, 23 Mar 2006, Andrew Morton wrote:

> We suspect the culprit is git-intelfb, which does
>
> config FB_INTEL
> tristate "Intel 830M/845G/852GM/855GM/865G support (EXPERIMENTAL)"
> - depends on FB && EXPERIMENTAL && PCI && X86_32
> + depends on FB && EXPERIMENTAL && PCI && X86
> select AGP
> select AGP_INTEL
> select FB_MODE_HELPERS
>
> It's rather nasty that this can break the build.
>
> It also seems plain wrong to me that a "select AGP" can force CONFIG_AGP=y
> into CONFIG_AGP=m. There's no sense in that.

select and default don't really mix very well, a default is only active if
nothing else enables the symbol, but select already enables here AGP, so
the AGP default isn't needed/used anymore.
It's somewhat related to the other default behaviour, without changing
that I don't see a clean and simple way to change this right now.
The easiest solution is to simply remove the default and let GART_IOMMU
select AGP too.

bye, Roman




The AGP default doesn't work well with other selects, so use a select for
GART_IOMMU as well. Remove a redundant default for SWIOTLB as well.

Signed-off-by: Roman Zippel <[email protected]>

---

arch/x86_64/Kconfig | 5 ++---
drivers/char/agp/Kconfig | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)

Index: linux-2.6-mm/arch/x86_64/Kconfig
===================================================================
--- linux-2.6-mm.orig/arch/x86_64/Kconfig 2006-03-24 01:58:56.000000000 +0100
+++ linux-2.6-mm/arch/x86_64/Kconfig 2006-03-24 12:58:23.000000000 +0100
@@ -389,6 +389,7 @@ config GART_IOMMU
bool "K8 GART IOMMU support"
default y
select SWIOTLB
+ select AGP
depends on PCI
help
Support for hardware IOMMU in AMD's Opteron/Athlon64 Processors
@@ -414,11 +415,9 @@ config CALGARY_IOMMU
will make the right choice by iteself.
If unsure, say Y.

-# need this always enabled with GART_IOMMU for the VIA workaround
+# need this always selected by GART_IOMMU for the VIA workaround
config SWIOTLB
bool
- default y
- depends on GART_IOMMU

config X86_MCE
bool "Machine check support" if EMBEDDED
Index: linux-2.6-git/drivers/char/agp/Kconfig
===================================================================
--- linux-2.6-git.orig/drivers/char/agp/Kconfig 2006-03-24 01:59:00.000000000 +0100
+++ linux-2.6-git/drivers/char/agp/Kconfig 2006-03-24 12:59:27.000000000 +0100
@@ -1,7 +1,6 @@
config AGP
- tristate "/dev/agpgart (AGP Support)" if !GART_IOMMU
+ tristate "/dev/agpgart (AGP Support)"
depends on ALPHA || IA64 || PPC || X86
- default y if GART_IOMMU
---help---
AGP (Accelerated Graphics Port) is a bus system mainly used to
connect graphics cards to the rest of the system.

2006-03-24 12:13:27

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] use select for GART_IOMMU to enable AGP

Roman Zippel <[email protected]> writes:

> The easiest solution is to simply remove the default and let GART_IOMMU
> select AGP too.

GART_IOMMU works without AGP driver too. It just has the requirement
that the AMD64 AGP driver is either builtin or not enabled at all.

-Andi

2006-03-24 12:45:15

by Roman Zippel

[permalink] [raw]
Subject: Re: [PATCH] use select for GART_IOMMU to enable AGP

Hi,

On Fri, 24 Mar 2006, Andi Kleen wrote:

> > The easiest solution is to simply remove the default and let GART_IOMMU
> > select AGP too.
>
> GART_IOMMU works without AGP driver too. It just has the requirement
> that the AMD64 AGP driver is either builtin or not enabled at all.

I don't see how this is/was possible, if GART_IOMMU was enabled so was AGP
(and AGP_AMD64). That hasn't changed with the patch.

bye, Roman

2006-03-24 12:51:35

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] use select for GART_IOMMU to enable AGP

On Friday 24 March 2006 13:45, Roman Zippel wrote:
> Hi,
>
> On Fri, 24 Mar 2006, Andi Kleen wrote:
>
> > > The easiest solution is to simply remove the default and let GART_IOMMU
> > > select AGP too.
> >
> > GART_IOMMU works without AGP driver too. It just has the requirement
> > that the AMD64 AGP driver is either builtin or not enabled at all.
>
> I don't see how this is/was possible, if GART_IOMMU was enabled so was AGP
> (and AGP_AMD64). That hasn't changed with the patch.

That was/is a bug that was originally introduced in the 2.4->2.6 Kconfig conversion.
The code was designed to handle it and did in 2.4.

-Andi

2006-03-24 12:58:19

by Brandon Low

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Fri, 03/24/06 at 03:39:34 -0800, Andrew Morton wrote:
> Brandon Low <[email protected]> wrote:
> >
> > I hadn't noticed immediately in the ooops, but it is something to do
> > with the Hardware Abstraction Layer Daemon from http://freedesktop.org/Software/hal
> > I can't reproduce it without that daemon loaded either. I wonder if the
> > last accessed sysfs file mentioned in the oops (sda/size) is relevent
> > also.
> >
> > My exact steps (with hald loaded) are:
> > plug in ipod
> > mount /mnt/ipod
> > unzip -d /mnt/ipod rockbox.zip
> > eject /dev/sda
> > unplug ipod
> > immediately here, the oops prints.
>
> Still no joy, alas.
>
> git-cfq.patch plays with the elevator exit code for all IO schedulers.
> Would you be able to do
>
> wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/git-cfq.patch
> patch -p1 -R < git-cfq.patch
>
> and retest?
>
> Thanks.

It is definitely this patch. Identical steps (also used an untainted
kernel for both tests) on -mm1 with and without that patch, and when the
patch is reversed, I cannot cause the oops. I booted into single user
mode (to dodge tainting and any other weirdness), started the dbus
system message daemon and hald (which depends on dbus), then performed
the steps mentioned above.

Thanks!

2006-03-24 13:49:30

by Roman Zippel

[permalink] [raw]
Subject: Re: [PATCH] use select for GART_IOMMU to enable AGP

Hi,

On Fri, 24 Mar 2006, Andi Kleen wrote:

> > I don't see how this is/was possible, if GART_IOMMU was enabled so was AGP
> > (and AGP_AMD64). That hasn't changed with the patch.
>
> That was/is a bug that was originally introduced in the 2.4->2.6 Kconfig conversion.
> The code was designed to handle it and did in 2.4.

It's debatable whether it's really a bug in the conversion.

2.4 does this:

if [ "$CONFIG_GART_IOMMU" = "y" ]; then
bool '/dev/agpgart (AGP Support)' CONFIG_AGP
else
tristate '/dev/agpgart (AGP Support)' CONFIG_AGP
fi

Dynamically changing the symbol type isn't supported anymore and it works
in 2.4 only by accident (e.g. it breaks the old xconfig).

If we really want to do something like this we had to introduce two
different symbols. Something like:

config GART_IOMMU
....

config AGP_BOOL
bool "builtin AGP support"
depends on GART_IOMMU
select AGP
select AGP_AMD64
help
Our IOMMU code sucks. :-)

We could also just remove the select/default and add a comment after
AGP_AMD64 depending on "AGP && GART_IOMMU && AGP_AMD64=m" saying that this
configuration disables IOMMU support for it and be done with it.
Another alternative is to fix the code to reinitialize the iommu stuff
when agp module is loaded.

bye, Roman

2006-03-24 18:29:12

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

Mike Galbraith <[email protected]> wrote:
>
> Greetings,
>
> I'm seeing strange things with grub with this kernel. After my box has
> been up for a while, and I reboot, selecting a kernel to restart, upon
> reboot, I sometimes (fairly often) get a blank screen staring at me
> though I see grub doing it's thing. Poking the power button results in
> an immediate poweroff, not as if the kernel had panicked or whatnot very
> early in boot. Very odd, and never before seen.
>

Do you mean that grub is actually proceeding as expected, just that the
display is off? If so, does it ever come back on?

Would it be reasonable to guess that some piece of code on the reboot path
is now poking the display hardware in a manner which shuts it off?

Are you using an fbdev driver? If so, which?

2006-03-24 18:36:37

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Brandon Low <[email protected]> wrote:
>
> On Fri, 03/24/06 at 03:39:34 -0800, Andrew Morton wrote:
> > Brandon Low <[email protected]> wrote:
> > >
> > > I hadn't noticed immediately in the ooops, but it is something to do
> > > with the Hardware Abstraction Layer Daemon from http://freedesktop.org/Software/hal
> > > I can't reproduce it without that daemon loaded either. I wonder if the
> > > last accessed sysfs file mentioned in the oops (sda/size) is relevent
> > > also.
> > >
> > > My exact steps (with hald loaded) are:
> > > plug in ipod
> > > mount /mnt/ipod
> > > unzip -d /mnt/ipod rockbox.zip
> > > eject /dev/sda
> > > unplug ipod
> > > immediately here, the oops prints.
> >
> > Still no joy, alas.
> >
> > git-cfq.patch plays with the elevator exit code for all IO schedulers.
> > Would you be able to do
> >
> > wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/git-cfq.patch
> > patch -p1 -R < git-cfq.patch
> >
> > and retest?
> >
> > Thanks.
>
> It is definitely this patch. Identical steps (also used an untainted
> kernel for both tests) on -mm1 with and without that patch, and when the
> patch is reversed, I cannot cause the oops. I booted into single user
> mode (to dodge tainting and any other weirdness), started the dbus
> system message daemon and hald (which depends on dbus), then performed
> the steps mentioned above.
>

Great. Thanks for working that out. It's time to add the dreaded Cc.

2006-03-24 18:37:36

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Fri, Mar 24 2006, Andrew Morton wrote:
> Brandon Low <[email protected]> wrote:
> >
> > On Fri, 03/24/06 at 03:39:34 -0800, Andrew Morton wrote:
> > > Brandon Low <[email protected]> wrote:
> > > >
> > > > I hadn't noticed immediately in the ooops, but it is something to do
> > > > with the Hardware Abstraction Layer Daemon from http://freedesktop.org/Software/hal
> > > > I can't reproduce it without that daemon loaded either. I wonder if the
> > > > last accessed sysfs file mentioned in the oops (sda/size) is relevent
> > > > also.
> > > >
> > > > My exact steps (with hald loaded) are:
> > > > plug in ipod
> > > > mount /mnt/ipod
> > > > unzip -d /mnt/ipod rockbox.zip
> > > > eject /dev/sda
> > > > unplug ipod
> > > > immediately here, the oops prints.
> > >
> > > Still no joy, alas.
> > >
> > > git-cfq.patch plays with the elevator exit code for all IO schedulers.
> > > Would you be able to do
> > >
> > > wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/git-cfq.patch
> > > patch -p1 -R < git-cfq.patch
> > >
> > > and retest?
> > >
> > > Thanks.
> >
> > It is definitely this patch. Identical steps (also used an untainted
> > kernel for both tests) on -mm1 with and without that patch, and when the
> > patch is reversed, I cannot cause the oops. I booted into single user
> > mode (to dodge tainting and any other weirdness), started the dbus
> > system message daemon and hald (which depends on dbus), then performed
> > the steps mentioned above.
> >
>
> Great. Thanks for working that out. It's time to add the dreaded Cc.

Can I see that oops?

--
Jens Axboe

2006-03-24 19:15:09

by Brandon Low

[permalink] [raw]
Subject: Re: 2.6.16-mm1

I recreated the oops with an untainted kernel, but didn't manage to copy that one down.

Brandon

usb 1-8: USB disconnect, address 6
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000102
printing eip:
c023e447
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file: /block/sda/sda2/size
Modules linked in: nls_cp437 deadline_iosched sd_mod vfat fat wlan_tkip wlan_scan_sta ath_pci ath_rate_sample wlan ath_hal w83627hf
hwmon_vid eeprom i2c_isa i2c_ali1563 i2c_core snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_ali5451 snd_ac97_codec
+snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc rtc pcspkr
CPU: 1
EIP: 0060:[<c023e447>] Tainted: PF VLI
EFLAGS: 00010046 (2.6.16-mm1 #1)
EIP is at cfq_exit_single_io_context+0x27/0x110
eax: 00000086 ebx: f7dcc124 ecx: f7dcc124 edx: f7dcc124
esi: f645b200 edi: 00000006 ebp: 0000000f esp: f6a99e44
ds: 007b es: 007b ss: 0068
Process hald-addon-stor (pid: 11786, threadinfo=f6a99000 task=f6546030)
Stack: <0>f65460e8 00000001 f6c1c070 f6546030 f7dcc124 00000282 c1b4d384 c023e55a
f7dcc124 f6a99000 00000286 c02398c7 c1b4d384 c18de960 f6546030 c1b4d384
c01213f6 f6546030 c0452b40 f654649c f6a99f24 00000001 f7e66500 f6a99000
Call Trace:
<c023e55a> cfq_exit_io_context+0x2a/0x50 <c02398c7> exit_io_context+0x87/0xb0
<c01213f6> do_exit+0x2a6/0x460 <c012161c> do_group_exit+0x3c/0x90
<c012c6c9> get_signal_to_deliver+0x229/0x300 <c0102da9> do_signal+0x69/0x160
<c013781e> ktime_get_ts+0x5e/0x70 <c0246ca2> copy_to_user+0x42/0x60
<c013807e> hrtimer_nanosleep+0xce/0x150 <c0137f90> nanosleep_wakeup+0x0/0x20
<c0138167> sys_nanosleep+0x67/0x70 <c0102ed8> do_notify_resume+0x38/0x3c
<c0103076> work_notifysig+0x13/0x19
Code: 00 00 00 00 83 ec 1c 89 5c 24 10 8b 5c 24 20 89 74 24 14 89 7c 24 18 8b 73 10 85 f6 74 65 8b 3e 9c 58 f6 c4 02 0f 85 82 00 00
00 <8b> 87 fc 00 00 00 e8 0e 3b 15 00 8b 43 14 85 c0 75 57 8b 43 18
<1>Fixing recursive fault but reboot is needed!

On Fri, 03/24/06 at 19:37:34 +0100, Jens Axboe wrote:
> On Fri, Mar 24 2006, Andrew Morton wrote:
> > Brandon Low <[email protected]> wrote:
> > >
> > > On Fri, 03/24/06 at 03:39:34 -0800, Andrew Morton wrote:
> > > > Brandon Low <[email protected]> wrote:
> > > > >
> > > > > I hadn't noticed immediately in the ooops, but it is something to do
> > > > > with the Hardware Abstraction Layer Daemon from http://freedesktop.org/Software/hal
> > > > > I can't reproduce it without that daemon loaded either. I wonder if the
> > > > > last accessed sysfs file mentioned in the oops (sda/size) is relevent
> > > > > also.
> > > > >
> > > > > My exact steps (with hald loaded) are:
> > > > > plug in ipod
> > > > > mount /mnt/ipod
> > > > > unzip -d /mnt/ipod rockbox.zip
> > > > > eject /dev/sda
> > > > > unplug ipod
> > > > > immediately here, the oops prints.
> > > >
> > > > Still no joy, alas.
> > > >
> > > > git-cfq.patch plays with the elevator exit code for all IO schedulers.
> > > > Would you be able to do
> > > >
> > > > wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16/2.6.16-mm1/broken-out/git-cfq.patch
> > > > patch -p1 -R < git-cfq.patch
> > > >
> > > > and retest?
> > > >
> > > > Thanks.
> > >
> > > It is definitely this patch. Identical steps (also used an untainted
> > > kernel for both tests) on -mm1 with and without that patch, and when the
> > > patch is reversed, I cannot cause the oops. I booted into single user
> > > mode (to dodge tainting and any other weirdness), started the dbus
> > > system message daemon and hald (which depends on dbus), then performed
> > > the steps mentioned above.
> > >
> >
> > Great. Thanks for working that out. It's time to add the dreaded Cc.
>
> Can I see that oops?
>
> --
> Jens Axboe
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2006-03-24 19:59:29

by Russell King

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Fri, Mar 24, 2006 at 12:28:27PM +0100, Roman Zippel wrote:
> Hi,
>
> On Thu, 23 Mar 2006, Russell King wrote:
>
> > Okay, so the default is now 'm', but the legal values are still only 'n'
> > and 'm'. I can only select 'm' or 'n', and this is what I end up with in
> > the config file. Now, if I remove the prompt text:
> >
> > config SYM_D
> > tristate
> > depends on SYM_M && SYM_Y
> > default y
> >
> > and hey presto, suddenly 'y' becomes a legal value.
> >
> > CONFIG_SYM_Y=y
> > CONFIG_SYM_M=m
> > CONFIG_SYM_D=y
> >
> > So it would seem to be a Kconfig bug.
>
> No, it's not a bug, that's really the correct behaviour. It has its roots
> in the cml1 converter, where statements like this:
>
> if [ "$CONFIG_FOO" = "y" ]; then
> define_tristate CONFIG_BAR y
> fi
>
> would become:
>
> config BAR
> default y
> depends on FOO=y

Okay, so going to the exact problem case, the behaviour we require is:

SERIAL_8250 PCI EMBEDDED gives SERIAL_8250_PCI
n X X n
X n X n
m y n m
y y n y
m y y user selects 'm' or 'n'
y y y user selects 'y', 'm' or 'n'

the correct way to tell Kconfig to give us that is:

+config SERIAL_8250_PCI
+ tristate "8250/16550 PCI device support" if EMBEDDED
+ depends on SERIAL_8250 && PCI
+ default SERIAL_8250
+ help
+ This builds standard PCI serial support. You may be able to
+ disable this feature if you only need legacy serial support.
+ Saves about 9K.

?

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

2006-03-24 21:33:13

by Andrew Morton

[permalink] [raw]
Subject: Re: [PATCH] Use const* parameters in mm.h

"J.A. Magallon" <[email protected]> wrote:
>
> As they are inline, this gives the compiler wide space for optmizations.
>
> --- linux-2.6.15-rc5-mm2.orig/include/linux/mm.h 2005-12-12 09:10:34.000000000 -0800
> +++ linux-2.6.15-rc5-mm2/include/linux/mm.h 2005-12-14 14:39:50.000000000 -0800
> @@ -464,7 +464,7 @@ void put_page(struct page *page);
> #define SECTIONS_MASK ((1UL << SECTIONS_WIDTH) - 1)
> #define ZONETABLE_MASK ((1UL << ZONETABLE_SHIFT) - 1)
>
> -static inline unsigned long page_zonenum(struct page *page)
> +static inline unsigned long page_zonenum(const struct page *page)
> ...

This makes zero difference in x86 allnoconfig code size with both gcc-3.2.1
and gcc-4.1.

2006-03-25 04:54:16

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

On Fri, 2006-03-24 at 10:25 -0800, Andrew Morton wrote:
> Mike Galbraith <[email protected]> wrote:
> >
> > Greetings,
> >
> > I'm seeing strange things with grub with this kernel. After my box has
> > been up for a while, and I reboot, selecting a kernel to restart, upon
> > reboot, I sometimes (fairly often) get a blank screen staring at me
> > though I see grub doing it's thing. Poking the power button results in
> > an immediate poweroff, not as if the kernel had panicked or whatnot very
> > early in boot. Very odd, and never before seen.
> >
>
> Do you mean that grub is actually proceeding as expected, just that the
> display is off? If so, does it ever come back on?

No, the box just sits there and does nada.

-Mike

2006-03-25 04:56:45

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

Mike Galbraith <[email protected]> wrote:
>
> On Fri, 2006-03-24 at 10:25 -0800, Andrew Morton wrote:
> > Mike Galbraith <[email protected]> wrote:
> > >
> > > Greetings,
> > >
> > > I'm seeing strange things with grub with this kernel. After my box has
> > > been up for a while, and I reboot, selecting a kernel to restart, upon
> > > reboot, I sometimes (fairly often) get a blank screen staring at me
> > > though I see grub doing it's thing. Poking the power button results in
> > > an immediate poweroff, not as if the kernel had panicked or whatnot very
> > > early in boot. Very odd, and never before seen.
> > >
> >
> > Do you mean that grub is actually proceeding as expected, just that the
> > display is off? If so, does it ever come back on?
>
> No, the box just sits there and does nada.
>

Did you try disabling fbdev?

2006-03-25 05:14:12

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

On Fri, 2006-03-24 at 20:53 -0800, Andrew Morton wrote:
> Mike Galbraith <[email protected]> wrote:
> >
> > On Fri, 2006-03-24 at 10:25 -0800, Andrew Morton wrote:
> > > Mike Galbraith <[email protected]> wrote:
> > > >
> > > > Greetings,
> > > >
> > > > I'm seeing strange things with grub with this kernel. After my box has
> > > > been up for a while, and I reboot, selecting a kernel to restart, upon
> > > > reboot, I sometimes (fairly often) get a blank screen staring at me
> > > > though I see grub doing it's thing. Poking the power button results in
> > > > an immediate poweroff, not as if the kernel had panicked or whatnot very
> > > > early in boot. Very odd, and never before seen.
> > > >
> > >
> > > Do you mean that grub is actually proceeding as expected, just that the
> > > display is off? If so, does it ever come back on?
> >
> > No, the box just sits there and does nada.
> >
>
> Did you try disabling fbdev?
>

No, but I will.

-Mike

2006-03-25 12:43:19

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

On Sat, 2006-03-25 at 06:14 +0100, Mike Galbraith wrote:
> On Fri, 2006-03-24 at 20:53 -0800, Andrew Morton wrote:
> >
> > Did you try disabling fbdev?
> >
>
> No, but I will.

No dice, I just had another dead reboot. Nobody else seems to be seeing
this, so maybe my box is going south. A single bit error the other day,
and now this. Maybe it's not the kernel, just a coincidence that I've
only seen it with 2.6.16-mm1. Maybe I've got dust crawling into memory
sockets or whatnot. Memtest86 time.

-Mike

2006-03-26 10:08:57

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

On Sat, 2006-03-25 at 13:44 +0100, Mike Galbraith wrote:
> On Sat, 2006-03-25 at 06:14 +0100, Mike Galbraith wrote:
> > On Fri, 2006-03-24 at 20:53 -0800, Andrew Morton wrote:
> > >
> > > Did you try disabling fbdev?
> > >
> >
> > No, but I will.
>
> No dice, I just had another dead reboot. Nobody else seems to be seeing
> this, so maybe my box is going south. A single bit error the other day,
> and now this. Maybe it's not the kernel, just a coincidence that I've
> only seen it with 2.6.16-mm1. Maybe I've got dust crawling into memory
> sockets or whatnot. Memtest86 time.

It's apparently not my hardware btw. If I find out what it is that's
causing this, I'll holler.

-Mike

2006-03-26 12:25:20

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] fix nfs PROC_FS=n compile error

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Boilerplate:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> git-nfs.patch
>...
> git trees.
>...


This patch fixes the following compile error with CONFIG_PROC_FS=n:

<-- snip -->

...
LD .tmp_vmlinux1
fs/built-in.o: In function `nfs_show_stats':inode.c:(.text+0x15481a): undefined reference to `rpc_print_iostats'
net/built-in.o: In function `rpc_destroy_client': undefined reference to `rpc_free_iostats'
net/built-in.o: In function `rpc_clone_client': undefined reference to `rpc_alloc_iostats'
net/built-in.o: In function `rpc_new_client': undefined reference to `rpc_alloc_iostats'
net/built-in.o: In function `xprt_release': undefined reference to `rpc_count_iostats'
make: *** [.tmp_vmlinux1] Error 1

<-- snip -->

Signed-off-by: Adrian Bunk <[email protected]>

---

include/linux/sunrpc/metrics.h | 12 ++++++++++++
1 file changed, 12 insertions(+)

--- linux-2.6.16-mm1-full/include/linux/sunrpc/metrics.h.old 2006-03-26 00:05:50.000000000 +0100
+++ linux-2.6.16-mm1-full/include/linux/sunrpc/metrics.h 2006-03-26 00:13:46.000000000 +0100
@@ -69,9 +69,21 @@
/*
* EXPORTed functions for managing rpc_iostats structures
*/
+
+#ifdef CONFIG_PROC_FS
+
struct rpc_iostats * rpc_alloc_iostats(struct rpc_clnt *);
void rpc_count_iostats(struct rpc_task *);
void rpc_print_iostats(struct seq_file *, struct rpc_clnt *);
void rpc_free_iostats(struct rpc_iostats *);

+#else /* CONFIG_PROC_FS */
+
+static inline struct rpc_iostats *rpc_alloc_iostats(struct rpc_clnt *clnt) { return NULL; }
+static inline void rpc_count_iostats(struct rpc_task *task) {}
+static inline void rpc_print_iostats(struct seq_file *seq, struct rpc_clnt *clnt) {}
+static inline void rpc_free_iostats(struct rpc_iostats *stats) {}
+
+#endif /* CONFIG_PROC_FS */
+
#endif /* _LINUX_SUNRPC_METRICS_H */

2006-03-26 12:25:51

by Adrian Bunk

[permalink] [raw]
Subject: [-mm patch] BLK_DEV_IO_TRACE Kconfig fixes

On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc6-mm2:
>...
> git-blktrace.patch
>...
> git trees.
>...

BLK_DEV_IO_TRACE breaks the rule "If you select something, you must
endure that the dependencies of what you are select'ing are fulfilled."
resulting in the following compile error with CONFIG_SYSFS=n:

<-- snip -->

...
LD .tmp_vmlinux1
fs/built-in.o: In function `debugfs_init':inode.c:(.init.text+0x3d35):
undefined reference to `kernel_subsys'
make: *** [.tmp_vmlinux1] Error 1

<-- snip -->

This patch fixes this bug.

Additionally, it moves the BLK_DEV_IO_TRACE option that now depends on
DEBUG_KERNEL into the menu with the other DEBUG_KERNEL options.

Signed-off-by: Adrian Bunk <[email protected]>

---

block/Kconfig | 12 ------------
lib/Kconfig.debug | 13 +++++++++++++
2 files changed, 13 insertions(+), 12 deletions(-)

--- linux-2.6.16-mm1-full/block/Kconfig.old 2006-03-26 01:49:51.000000000 +0100
+++ linux-2.6.16-mm1-full/block/Kconfig 2006-03-26 01:55:28.000000000 +0100
@@ -11,18 +11,6 @@
your machine, or if you want to have a raid or loopback device
bigger than 2TB. Otherwise say N.

-config BLK_DEV_IO_TRACE
- bool "Support for tracing block io actions"
- select RELAY
- select DEBUG_FS
- help
- Say Y here, if you want to be able to trace the block layer actions
- on a given queue. Tracing allows you to see any traffic happening
- on a block device queue. For more information (and the user space
- support tools needed), fetch the blktrace app from:
-
- git://brick.kernel.dk/data/git/blktrace.git
-
config LSF
bool "Support for Large Single Files"
depends on X86 || (MIPS && 32BIT) || PPC32 || ARCH_S390_31 || SUPERH || UML
--- linux-2.6.16-mm1-full/lib/Kconfig.debug.old 2006-03-26 01:51:40.000000000 +0100
+++ linux-2.6.16-mm1-full/lib/Kconfig.debug 2006-03-26 01:55:42.000000000 +0100
@@ -213,6 +213,19 @@

If unsure, say N.

+config BLK_DEV_IO_TRACE
+ bool "Support for tracing block io actions"
+ depends on DEBUG_KERNEL && SYSFS
+ select RELAY
+ select DEBUG_FS
+ help
+ Say Y here, if you want to be able to trace the block layer actions
+ on a given queue. Tracing allows you to see any traffic happening
+ on a block device queue. For more information (and the user space
+ support tools needed), fetch the blktrace app from:
+
+ git://brick.kernel.dk/data/git/blktrace.git
+
config FRAME_POINTER
bool "Compile the kernel with frame pointers"
depends on DEBUG_KERNEL && (X86 || CRIS || M68K || M68KNOMMU || FRV || UML)

2006-03-26 12:30:49

by Jens Axboe

[permalink] [raw]
Subject: Re: [-mm patch] BLK_DEV_IO_TRACE Kconfig fixes

On Sun, Mar 26 2006, Adrian Bunk wrote:
> On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-rc6-mm2:
> >...
> > git-blktrace.patch
> >...
> > git trees.
> >...
>
> BLK_DEV_IO_TRACE breaks the rule "If you select something, you must
> endure that the dependencies of what you are select'ing are fulfilled."
> resulting in the following compile error with CONFIG_SYSFS=n:
>
> <-- snip -->
>
> ...
> LD .tmp_vmlinux1
> fs/built-in.o: In function `debugfs_init':inode.c:(.init.text+0x3d35):
> undefined reference to `kernel_subsys'
> make: *** [.tmp_vmlinux1] Error 1
>
> <-- snip -->
>
> This patch fixes this bug.
>
> Additionally, it moves the BLK_DEV_IO_TRACE option that now depends on
> DEBUG_KERNEL into the menu with the other DEBUG_KERNEL options.

Thanks for the sysfs fix, however don't move the kconfig entry, this
isn't a debug option.

--
Jens Axboe

2006-03-26 12:33:31

by Adrian Bunk

[permalink] [raw]
Subject: Re: [-mm patch] BLK_DEV_IO_TRACE Kconfig fixes

On Sun, Mar 26, 2006 at 02:27:44PM +0200, Jens Axboe wrote:
> On Sun, Mar 26 2006, Adrian Bunk wrote:
> > On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.16-rc6-mm2:
> > >...
> > > git-blktrace.patch
> > >...
> > > git trees.
> > >...
> >
> > BLK_DEV_IO_TRACE breaks the rule "If you select something, you must
> > endure that the dependencies of what you are select'ing are fulfilled."
> > resulting in the following compile error with CONFIG_SYSFS=n:
> >
> > <-- snip -->
> >
> > ...
> > LD .tmp_vmlinux1
> > fs/built-in.o: In function `debugfs_init':inode.c:(.init.text+0x3d35):
> > undefined reference to `kernel_subsys'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > <-- snip -->
> >
> > This patch fixes this bug.
> >
> > Additionally, it moves the BLK_DEV_IO_TRACE option that now depends on
> > DEBUG_KERNEL into the menu with the other DEBUG_KERNEL options.
>
> Thanks for the sysfs fix, however don't move the kconfig entry, this
> isn't a debug option.

It select's an option depending on DEBUG_KERNEL, and therefore also has
to depend on DEBUG_KERNEL.

> Jens Axboe

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

2006-03-26 12:37:49

by Jens Axboe

[permalink] [raw]
Subject: Re: [-mm patch] BLK_DEV_IO_TRACE Kconfig fixes

On Sun, Mar 26 2006, Adrian Bunk wrote:
> On Sun, Mar 26, 2006 at 02:27:44PM +0200, Jens Axboe wrote:
> > On Sun, Mar 26 2006, Adrian Bunk wrote:
> > > On Thu, Mar 23, 2006 at 01:40:46AM -0800, Andrew Morton wrote:
> > > >...
> > > > Changes since 2.6.16-rc6-mm2:
> > > >...
> > > > git-blktrace.patch
> > > >...
> > > > git trees.
> > > >...
> > >
> > > BLK_DEV_IO_TRACE breaks the rule "If you select something, you must
> > > endure that the dependencies of what you are select'ing are fulfilled."
> > > resulting in the following compile error with CONFIG_SYSFS=n:
> > >
> > > <-- snip -->
> > >
> > > ...
> > > LD .tmp_vmlinux1
> > > fs/built-in.o: In function `debugfs_init':inode.c:(.init.text+0x3d35):
> > > undefined reference to `kernel_subsys'
> > > make: *** [.tmp_vmlinux1] Error 1
> > >
> > > <-- snip -->
> > >
> > > This patch fixes this bug.
> > >
> > > Additionally, it moves the BLK_DEV_IO_TRACE option that now depends on
> > > DEBUG_KERNEL into the menu with the other DEBUG_KERNEL options.
> >
> > Thanks for the sysfs fix, however don't move the kconfig entry, this
> > isn't a debug option.
>
> It select's an option depending on DEBUG_KERNEL, and therefore also has
> to depend on DEBUG_KERNEL.

IMHO that should be removed, debugfs should be generally available. At
least with blktrace, it's not necessarily a debug feature.

--
Jens Axboe

2006-03-26 17:00:10

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

On Sun, 2006-03-26 at 11:10 +0200, Mike Galbraith wrote:
> On Sat, 2006-03-25 at 13:44 +0100, Mike Galbraith wrote:
> > On Sat, 2006-03-25 at 06:14 +0100, Mike Galbraith wrote:
> > > On Fri, 2006-03-24 at 20:53 -0800, Andrew Morton wrote:
> > > >
> > > > Did you try disabling fbdev?
> > > >
> > >
> > > No, but I will.
> >
> > No dice, I just had another dead reboot. Nobody else seems to be seeing
> > this, so maybe my box is going south. A single bit error the other day,
> > and now this. Maybe it's not the kernel, just a coincidence that I've
> > only seen it with 2.6.16-mm1. Maybe I've got dust crawling into memory
> > sockets or whatnot. Memtest86 time.
>
> It's apparently not my hardware btw. If I find out what it is that's
> causing this, I'll holler.

The tentative winner for my reboot (and boot) problems appears to be
frequency scaling changes between 2.6.16-rc6-mm2, which worked fine,
and 2.6.16-mm1. Disabling frequency scaling appears to fix my troubles.
Caveat emptor: intermittent.

(Difficult for me to believe that having this compiled in could do a
number on my p4. Reverting the hotplug thingie gave me suspend back and
nothing more [as expected]. Color me befuddled.)

diff -urN linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
--- linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-26 12:13:21.000000000 +0200
+++ linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-23 14:58:44.000000000 +0100
@@ -225,9 +225,11 @@
freqs.old = data->freq_table[cur_state].frequency;
freqs.new = data->freq_table[next_state].frequency;

-#ifdef CONFIG_SMP
+#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
+#else
+ online_policy_cpus = policy->cpus;
#endif

for_each_cpu_mask(j, online_policy_cpus) {
diff -urN linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/powernow-k8.c linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c
--- linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2006-03-26 12:13:21.000000000 +0200
+++ linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.c 2006-03-23 14:58:44.000000000 +0100
@@ -55,7 +55,7 @@
static struct powernow_k8_data *powernow_data[NR_CPUS];

#ifndef CONFIG_SMP
-static cpumask_t cpu_core_map[1];
+static cpumask_t cpu_core_map[1] = { CPU_MASK_ALL };
#endif

/* Return a frequency in MHz, given an input fid */
@@ -977,7 +977,7 @@
{
struct powernow_k8_data *data;
cpumask_t oldmask = CPU_MASK_ALL;
- int rc;
+ int rc, i;

if (!cpu_online(pol->cpu))
return -ENODEV;
@@ -1063,7 +1063,8 @@
printk("cpu_init done, current fid 0x%x, vid 0x%x\n",
data->currfid, data->currvid);

- powernow_data[pol->cpu] = data;
+ for_each_cpu_mask(i, cpu_core_map[pol->cpu])
+ powernow_data[i] = data;

return 0;

diff -urN linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/powernow-k8.h linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.h
--- linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/powernow-k8.h 2006-03-26 12:13:21.000000000 +0200
+++ linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/powernow-k8.h 2006-03-23 14:58:44.000000000 +0100
@@ -182,10 +182,6 @@

static void powernow_k8_acpi_pst_values(struct powernow_k8_data *data, unsigned int index);

-#ifndef for_each_cpu_mask
-#define for_each_cpu_mask(i,mask) for (i=0;i<1;i++)
-#endif
-
#ifdef CONFIG_SMP
static inline void define_siblings(int cpu, cpumask_t cpu_sharedcore_mask[])
{
diff -urN linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-26 12:13:21.000000000 +0200
+++ linux-2.6.16-mm1/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-23 14:58:44.000000000 +0100
@@ -652,9 +652,11 @@
return -EINVAL;
}

-#ifdef CONFIG_SMP
+#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
+#else
+ online_policy_cpus = policy->cpus;
#endif

saved_mask = current->cpus_allowed;
diff -urN linux-2.6.16-rc6-mm2/drivers/cpufreq/cpufreq_conservative.c linux-2.6.16-mm1/drivers/cpufreq/cpufreq_conservative.c
--- linux-2.6.16-rc6-mm2/drivers/cpufreq/cpufreq_conservative.c 2006-03-26 12:13:02.000000000 +0200
+++ linux-2.6.16-mm1/drivers/cpufreq/cpufreq_conservative.c 2006-03-23 14:58:45.000000000 +0100
@@ -35,12 +35,7 @@
*/

#define DEF_FREQUENCY_UP_THRESHOLD (80)
-#define MIN_FREQUENCY_UP_THRESHOLD (0)
-#define MAX_FREQUENCY_UP_THRESHOLD (100)
-
#define DEF_FREQUENCY_DOWN_THRESHOLD (20)
-#define MIN_FREQUENCY_DOWN_THRESHOLD (0)
-#define MAX_FREQUENCY_DOWN_THRESHOLD (100)

/*
* The polling frequency of this governor depends on the capability of
@@ -53,10 +48,14 @@
* All times here are in uS.
*/
static unsigned int def_sampling_rate;
-#define MIN_SAMPLING_RATE (def_sampling_rate / 2)
+#define MIN_SAMPLING_RATE_RATIO (2)
+/* for correct statistics, we need at least 10 ticks between each measure */
+#define MIN_STAT_SAMPLING_RATE (MIN_SAMPLING_RATE_RATIO * jiffies_to_usecs(10))
+#define MIN_SAMPLING_RATE (def_sampling_rate / MIN_SAMPLING_RATE_RATIO)
#define MAX_SAMPLING_RATE (500 * def_sampling_rate)
-#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (100000)
-#define DEF_SAMPLING_DOWN_FACTOR (5)
+#define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER (1000)
+#define DEF_SAMPLING_DOWN_FACTOR (1)
+#define MAX_SAMPLING_DOWN_FACTOR (10)
#define TRANSITION_LATENCY_LIMIT (10 * 1000)

static void do_dbs_timer(void *data);
@@ -66,6 +65,8 @@
unsigned int prev_cpu_idle_up;
unsigned int prev_cpu_idle_down;
unsigned int enable;
+ unsigned int down_skip;
+ unsigned int requested_freq;
};
static DEFINE_PER_CPU(struct cpu_dbs_info_s, cpu_dbs_info);

@@ -136,7 +137,7 @@
unsigned int input;
int ret;
ret = sscanf (buf, "%u", &input);
- if (ret != 1 )
+ if (ret != 1 || input > MAX_SAMPLING_DOWN_FACTOR || input < 1)
return -EINVAL;

mutex_lock(&dbs_mutex);
@@ -173,8 +174,7 @@
ret = sscanf (buf, "%u", &input);

mutex_lock(&dbs_mutex);
- if (ret != 1 || input > MAX_FREQUENCY_UP_THRESHOLD ||
- input < MIN_FREQUENCY_UP_THRESHOLD ||
+ if (ret != 1 || input > 100 || input < 0 ||
input <= dbs_tuners_ins.down_threshold) {
mutex_unlock(&dbs_mutex);
return -EINVAL;
@@ -194,8 +194,7 @@
ret = sscanf (buf, "%u", &input);

mutex_lock(&dbs_mutex);
- if (ret != 1 || input > MAX_FREQUENCY_DOWN_THRESHOLD ||
- input < MIN_FREQUENCY_DOWN_THRESHOLD ||
+ if (ret != 1 || input > 100 || input < 0 ||
input >= dbs_tuners_ins.up_threshold) {
mutex_unlock(&dbs_mutex);
return -EINVAL;
@@ -297,31 +296,17 @@
static void dbs_check_cpu(int cpu)
{
unsigned int idle_ticks, up_idle_ticks, down_idle_ticks;
+ unsigned int tmp_idle_ticks, total_idle_ticks;
unsigned int freq_step;
unsigned int freq_down_sampling_rate;
- static int down_skip[NR_CPUS];
- static int requested_freq[NR_CPUS];
- static unsigned short init_flag = 0;
- struct cpu_dbs_info_s *this_dbs_info;
- struct cpu_dbs_info_s *dbs_info;
-
+ struct cpu_dbs_info_s *this_dbs_info = &per_cpu(cpu_dbs_info, cpu);
struct cpufreq_policy *policy;
- unsigned int j;

- this_dbs_info = &per_cpu(cpu_dbs_info, cpu);
if (!this_dbs_info->enable)
return;

policy = this_dbs_info->cur_policy;

- if ( init_flag == 0 ) {
- for_each_online_cpu(j) {
- dbs_info = &per_cpu(cpu_dbs_info, j);
- requested_freq[j] = dbs_info->cur_policy->cur;
- }
- init_flag = 1;
- }
-
/*
* The default safe range is 20% to 80%
* Every sampling_rate, we check
@@ -337,39 +322,29 @@
*/

/* Check for frequency increase */
-
idle_ticks = UINT_MAX;
- for_each_cpu_mask(j, policy->cpus) {
- unsigned int tmp_idle_ticks, total_idle_ticks;
- struct cpu_dbs_info_s *j_dbs_info;

- j_dbs_info = &per_cpu(cpu_dbs_info, j);
- /* Check for frequency increase */
- total_idle_ticks = get_cpu_idle_time(j);
- tmp_idle_ticks = total_idle_ticks -
- j_dbs_info->prev_cpu_idle_up;
- j_dbs_info->prev_cpu_idle_up = total_idle_ticks;
+ /* Check for frequency increase */
+ total_idle_ticks = get_cpu_idle_time(cpu);
+ tmp_idle_ticks = total_idle_ticks -
+ this_dbs_info->prev_cpu_idle_up;
+ this_dbs_info->prev_cpu_idle_up = total_idle_ticks;

- if (tmp_idle_ticks < idle_ticks)
- idle_ticks = tmp_idle_ticks;
- }
+ if (tmp_idle_ticks < idle_ticks)
+ idle_ticks = tmp_idle_ticks;

/* Scale idle ticks by 100 and compare with up and down ticks */
idle_ticks *= 100;
up_idle_ticks = (100 - dbs_tuners_ins.up_threshold) *
- usecs_to_jiffies(dbs_tuners_ins.sampling_rate);
+ usecs_to_jiffies(dbs_tuners_ins.sampling_rate);

if (idle_ticks < up_idle_ticks) {
- down_skip[cpu] = 0;
- for_each_cpu_mask(j, policy->cpus) {
- struct cpu_dbs_info_s *j_dbs_info;
+ this_dbs_info->down_skip = 0;
+ this_dbs_info->prev_cpu_idle_down =
+ this_dbs_info->prev_cpu_idle_up;

- j_dbs_info = &per_cpu(cpu_dbs_info, j);
- j_dbs_info->prev_cpu_idle_down =
- j_dbs_info->prev_cpu_idle_up;
- }
/* if we are already at full speed then break out early */
- if (requested_freq[cpu] == policy->max)
+ if (this_dbs_info->requested_freq == policy->max)
return;

freq_step = (dbs_tuners_ins.freq_step * policy->max) / 100;
@@ -378,49 +353,45 @@
if (unlikely(freq_step == 0))
freq_step = 5;

- requested_freq[cpu] += freq_step;
- if (requested_freq[cpu] > policy->max)
- requested_freq[cpu] = policy->max;
+ this_dbs_info->requested_freq += freq_step;
+ if (this_dbs_info->requested_freq > policy->max)
+ this_dbs_info->requested_freq = policy->max;

- __cpufreq_driver_target(policy, requested_freq[cpu],
+ __cpufreq_driver_target(policy, this_dbs_info->requested_freq,
CPUFREQ_RELATION_H);
return;
}

/* Check for frequency decrease */
- down_skip[cpu]++;
- if (down_skip[cpu] < dbs_tuners_ins.sampling_down_factor)
+ this_dbs_info->down_skip++;
+ if (this_dbs_info->down_skip < dbs_tuners_ins.sampling_down_factor)
return;

- idle_ticks = UINT_MAX;
- for_each_cpu_mask(j, policy->cpus) {
- unsigned int tmp_idle_ticks, total_idle_ticks;
- struct cpu_dbs_info_s *j_dbs_info;
-
- j_dbs_info = &per_cpu(cpu_dbs_info, j);
- total_idle_ticks = j_dbs_info->prev_cpu_idle_up;
- tmp_idle_ticks = total_idle_ticks -
- j_dbs_info->prev_cpu_idle_down;
- j_dbs_info->prev_cpu_idle_down = total_idle_ticks;
+ /* Check for frequency decrease */
+ total_idle_ticks = this_dbs_info->prev_cpu_idle_up;
+ tmp_idle_ticks = total_idle_ticks -
+ this_dbs_info->prev_cpu_idle_down;
+ this_dbs_info->prev_cpu_idle_down = total_idle_ticks;

- if (tmp_idle_ticks < idle_ticks)
- idle_ticks = tmp_idle_ticks;
- }
+ if (tmp_idle_ticks < idle_ticks)
+ idle_ticks = tmp_idle_ticks;

/* Scale idle ticks by 100 and compare with up and down ticks */
idle_ticks *= 100;
- down_skip[cpu] = 0;
+ this_dbs_info->down_skip = 0;

freq_down_sampling_rate = dbs_tuners_ins.sampling_rate *
dbs_tuners_ins.sampling_down_factor;
down_idle_ticks = (100 - dbs_tuners_ins.down_threshold) *
- usecs_to_jiffies(freq_down_sampling_rate);
+ usecs_to_jiffies(freq_down_sampling_rate);

if (idle_ticks > down_idle_ticks) {
- /* if we are already at the lowest speed then break out early
+ /*
+ * if we are already at the lowest speed then break out early
* or if we 'cannot' reduce the speed as the user might want
- * freq_step to be zero */
- if (requested_freq[cpu] == policy->min
+ * freq_step to be zero
+ */
+ if (this_dbs_info->requested_freq == policy->min
|| dbs_tuners_ins.freq_step == 0)
return;

@@ -430,13 +401,12 @@
if (unlikely(freq_step == 0))
freq_step = 5;

- requested_freq[cpu] -= freq_step;
- if (requested_freq[cpu] < policy->min)
- requested_freq[cpu] = policy->min;
+ this_dbs_info->requested_freq -= freq_step;
+ if (this_dbs_info->requested_freq < policy->min)
+ this_dbs_info->requested_freq = policy->min;

- __cpufreq_driver_target(policy,
- requested_freq[cpu],
- CPUFREQ_RELATION_H);
+ __cpufreq_driver_target(policy, this_dbs_info->requested_freq,
+ CPUFREQ_RELATION_H);
return;
}
}
@@ -493,11 +463,13 @@
j_dbs_info = &per_cpu(cpu_dbs_info, j);
j_dbs_info->cur_policy = policy;

- j_dbs_info->prev_cpu_idle_up = get_cpu_idle_time(j);
+ j_dbs_info->prev_cpu_idle_up = get_cpu_idle_time(cpu);
j_dbs_info->prev_cpu_idle_down
= j_dbs_info->prev_cpu_idle_up;
}
this_dbs_info->enable = 1;
+ this_dbs_info->down_skip = 0;
+ this_dbs_info->requested_freq = policy->cur;
sysfs_create_group(&policy->kobj, &dbs_attr_group);
dbs_enable++;
/*
@@ -507,13 +479,16 @@
if (dbs_enable == 1) {
unsigned int latency;
/* policy latency is in nS. Convert it to uS first */
+ latency = policy->cpuinfo.transition_latency / 1000;
+ if (latency == 0)
+ latency = 1;

- latency = policy->cpuinfo.transition_latency;
- if (latency < 1000)
- latency = 1000;
-
- def_sampling_rate = (latency / 1000) *
+ def_sampling_rate = 10 * latency *
DEF_SAMPLING_RATE_LATENCY_MULTIPLIER;
+
+ if (def_sampling_rate < MIN_STAT_SAMPLING_RATE)
+ def_sampling_rate = MIN_STAT_SAMPLING_RATE;
+
dbs_tuners_ins.sampling_rate = def_sampling_rate;
dbs_tuners_ins.ignore_nice = 0;
dbs_tuners_ins.freq_step = 5;


2006-03-26 17:46:40

by Mike Galbraith

[permalink] [raw]
Subject: Re: 2.6.16-mm1 grub oddness

On Sun, 2006-03-26 at 18:01 +0200, Mike Galbraith wrote:

> (Difficult for me to believe that having this compiled in could do a
> number on my p4. Reverting the hotplug thingie gave me suspend back and
> nothing more [as expected]. Color me befuddled.)

Bah. A few boots later, back to square one. Maybe I should ignore this
darn thing and just hope it goes away.

Ciao,

-Mike

2006-03-27 10:58:08

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Fri, Mar 24 2006, Brandon Low wrote:
> I recreated the oops with an untainted kernel, but didn't manage to copy that one down.
>
> Brandon
>
> usb 1-8: USB disconnect, address 6
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000102
> printing eip:
> c023e447
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> last sysfs file: /block/sda/sda2/size
> Modules linked in: nls_cp437 deadline_iosched sd_mod vfat fat wlan_tkip wlan_scan_sta ath_pci ath_rate_sample wlan ath_hal w83627hf
> hwmon_vid eeprom i2c_isa i2c_ali1563 i2c_core snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_ali5451 snd_ac97_codec
> +snd_ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc rtc pcspkr
> CPU: 1
> EIP: 0060:[<c023e447>] Tainted: PF VLI
> EFLAGS: 00010046 (2.6.16-mm1 #1)
> EIP is at cfq_exit_single_io_context+0x27/0x110
> eax: 00000086 ebx: f7dcc124 ecx: f7dcc124 edx: f7dcc124
> esi: f645b200 edi: 00000006 ebp: 0000000f esp: f6a99e44
> ds: 007b es: 007b ss: 0068
> Process hald-addon-stor (pid: 11786, threadinfo=f6a99000 task=f6546030)
> Stack: <0>f65460e8 00000001 f6c1c070 f6546030 f7dcc124 00000282 c1b4d384 c023e55a
> f7dcc124 f6a99000 00000286 c02398c7 c1b4d384 c18de960 f6546030 c1b4d384
> c01213f6 f6546030 c0452b40 f654649c f6a99f24 00000001 f7e66500 f6a99000
> Call Trace:
> <c023e55a> cfq_exit_io_context+0x2a/0x50 <c02398c7> exit_io_context+0x87/0xb0
> <c01213f6> do_exit+0x2a6/0x460 <c012161c> do_group_exit+0x3c/0x90
> <c012c6c9> get_signal_to_deliver+0x229/0x300 <c0102da9> do_signal+0x69/0x160
> <c013781e> ktime_get_ts+0x5e/0x70 <c0246ca2> copy_to_user+0x42/0x60
> <c013807e> hrtimer_nanosleep+0xce/0x150 <c0137f90> nanosleep_wakeup+0x0/0x20
> <c0138167> sys_nanosleep+0x67/0x70 <c0102ed8> do_notify_resume+0x38/0x3c
> <c0103076> work_notifysig+0x13/0x19
> Code: 00 00 00 00 83 ec 1c 89 5c 24 10 8b 5c 24 20 89 74 24 14 89 7c 24 18 8b 73 10 85 f6 74 65 8b 3e 9c 58 f6 c4 02 0f 85 82 00 00
> 00 <8b> 87 fc 00 00 00 e8 0e 3b 15 00 8b 43 14 85 c0 75 57 8b 43 18
> <1>Fixing recursive fault but reboot is needed!

Hmm, no luck reproducing this so far, strange. I'm using
2.6.16-block.git cfq branch exclusively, which is the patch you backed
out. I guess I'll try 2.6.16-mm1 on the same box next.

Can you try 2.6.16-mm1 with this patch applied on top?

diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 81edf51..89fcc2c 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1516,6 +1516,7 @@ cfq_cic_rb_add(struct cfq_data *cfqd, st

rb_link_node(&cic->rb_node, parent, p);
rb_insert_color(&cic->rb_node, &ioc->cic_root);
+ list_add(&cic->queue_list, &cfqd->cic_list);
read_unlock(&cfq_exit_lock);
}


--
Jens Axboe

2006-03-27 16:24:47

by OGAWA Hirofumi

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Jens Axboe <[email protected]> writes:

> On Fri, Mar 24 2006, Brandon Low wrote:
>
> Hmm, no luck reproducing this so far, strange. I'm using
> 2.6.16-block.git cfq branch exclusively, which is the patch you backed
> out. I guess I'll try 2.6.16-mm1 on the same box next.
>
> Can you try 2.6.16-mm1 with this patch applied on top?
>
> diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> index 81edf51..89fcc2c 100644
> --- a/block/cfq-iosched.c
> +++ b/block/cfq-iosched.c
> @@ -1516,6 +1516,7 @@ cfq_cic_rb_add(struct cfq_data *cfqd, st
>
> rb_link_node(&cic->rb_node, parent, p);
> rb_insert_color(&cic->rb_node, &ioc->cic_root);
> + list_add(&cic->queue_list, &cfqd->cic_list);
> read_unlock(&cfq_exit_lock);
> }

I've got a same oops in 2.6.16-mm1, and this patch seems to fix it at
least in my case.

Thanks.
--
OGAWA Hirofumi <[email protected]>

2006-03-27 17:15:20

by Jens Axboe

[permalink] [raw]
Subject: Re: 2.6.16-mm1

On Tue, Mar 28 2006, OGAWA Hirofumi wrote:
> Jens Axboe <[email protected]> writes:
>
> > On Fri, Mar 24 2006, Brandon Low wrote:
> >
> > Hmm, no luck reproducing this so far, strange. I'm using
> > 2.6.16-block.git cfq branch exclusively, which is the patch you backed
> > out. I guess I'll try 2.6.16-mm1 on the same box next.
> >
> > Can you try 2.6.16-mm1 with this patch applied on top?
> >
> > diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
> > index 81edf51..89fcc2c 100644
> > --- a/block/cfq-iosched.c
> > +++ b/block/cfq-iosched.c
> > @@ -1516,6 +1516,7 @@ cfq_cic_rb_add(struct cfq_data *cfqd, st
> >
> > rb_link_node(&cic->rb_node, parent, p);
> > rb_insert_color(&cic->rb_node, &ioc->cic_root);
> > + list_add(&cic->queue_list, &cfqd->cic_list);
> > read_unlock(&cfq_exit_lock);
> > }
>
> I've got a same oops in 2.6.16-mm1, and this patch seems to fix it at
> least in my case.

Super, it should fix it afaict, but not being able to reproduce I could
not say for sure. Thanks very much for testing and reporting back.

Andrew, can you enable cfq pull again? Thanks.

--
Jens Axboe

2006-03-27 20:28:55

by J.A. Magallon

[permalink] [raw]
Subject: Re: [PATCH] Dont build altivec raid on x86

Somenthing like this ?

--- linux/drivers/md/Makefile 2005-09-01 19:34:55.000000000 +0200
+++ linux/drivers/md/Makefile.new 2006-03-27 22:15:00.000000000 +0200
@@ -10,10 +10,10 @@
md-mod-objs := md.o bitmap.o
raid6-objs := raid6main.o raid6algos.o raid6recov.o raid6tables.o \
raid6int1.o raid6int2.o raid6int4.o \
- raid6int8.o raid6int16.o raid6int32.o \
- raid6altivec1.o raid6altivec2.o raid6altivec4.o \
- raid6altivec8.o \
- raid6mmx.o raid6sse1.o raid6sse2.o
+ raid6int8.o raid6int16.o raid6int32.o
+raid6-$(CONFIG_ALTIVEC) := raid6altivec1.o raid6altivec2.o \
+ raid6altivec4.o raid6altivec8.o
+raid6-$(CONFIG_X86) := raid6mmx.o raid6sse1.o raid6sse2.o
hostprogs-y := mktables

# Note: link order is important. All raid personalities


--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam1 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-27 20:30:22

by J.A. Magallon

[permalink] [raw]
Subject: Re: [PATCH] Lower e100 latency

Corrected:

--- linux/drivers/net/e100.c.orig 2006-01-24 09:20:44.000000000 +0100
+++ linux/drivers/net/e100.c 2006-01-24 09:21:55.000000000 +0100
@@ -884,10 +884,10 @@
* procedure it should be done under lock.
*/
spin_lock_irqsave(&nic->mdio_lock, flags);
- for (i = 100; i; --i) {
+ for (i = 1000; i; --i) {
if (readl(&nic->csr->mdi_ctrl) & mdi_ready)
break;
- udelay(20);
+ udelay(2);
}
if (unlikely(!i)) {
printk("e100.mdio_ctrl(%s) won't go Ready\n",
@@ -897,10 +897,10 @@
}
writel((reg << 16) | (addr << 21) | dir | data, &nic->csr->mdi_ctrl);

- for (i = 0; i < 100; i++) {
- udelay(20);
+ for (i = 0; i < 1000; i++) {
if ((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready)
break;
+ udelay(2);
}
spin_unlock_irqrestore(&nic->mdio_lock, flags);
DPRINTK(HW, DEBUG,

--
J.A. Magallon <jamagallon()able!es> \ Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.1 (Cooker) for i586
Linux 2.6.16-jam1 (gcc 4.0.3 (4.0.3-1mdk for Mandriva Linux release 2006.1))


Attachments:
signature.asc (191.00 B)

2006-03-27 20:57:43

by Jesse Brandeburg

[permalink] [raw]
Subject: Re: [PATCH] Lower e100 latency

On 3/27/06, J.A. Magallon <[email protected]> wrote:
> Corrected:
>
> --- linux/drivers/net/e100.c.orig 2006-01-24 09:20:44.000000000 +0100
> +++ linux/drivers/net/e100.c 2006-01-24 09:21:55.000000000 +0100
> @@ -884,10 +884,10 @@
> * procedure it should be done under lock.
> */
> spin_lock_irqsave(&nic->mdio_lock, flags);
> - for (i = 100; i; --i) {
> + for (i = 1000; i; --i) {
> if (readl(&nic->csr->mdi_ctrl) & mdi_ready)
> break;
> - udelay(20);
> + udelay(2);

what is the purpose of this patch? what bug is it solving? Are we
trying to achieve some goal? A comment at the very least is
necessary. I don't like changing timing stuff unless we have some
clear reason. In fact I sent a patch a while back to a guy who was
complaining about latency in a -RT kernel with e100 and he said this
kind of change made things worse: see the end of:

http://marc.theaimsgroup.com/?l=linux-kernel&m=113808831932769&w=2

The problem in this case is the mii library calling back into our
mdio_read. eepro100's mdio read hard spins with no delay besides the
ioread32 delay created by reading from an i/o port. This could
explain the glitching in an RT kernel.

Is this the kind of problem this patch tries to solve?

Thanks,
Jesse

2006-03-28 09:18:55

by Roman Zippel

[permalink] [raw]
Subject: Re: 2.6.16-mm1

Hi,

On Fri, 24 Mar 2006, Russell King wrote:

> the correct way to tell Kconfig to give us that is:
>
> +config SERIAL_8250_PCI
> + tristate "8250/16550 PCI device support" if EMBEDDED
> + depends on SERIAL_8250 && PCI
> + default SERIAL_8250
> + help
> + This builds standard PCI serial support. You may be able to
> + disable this feature if you only need legacy serial support.
> + Saves about 9K.
>
> ?

Yes, this should do it.

bye, Roman