2.6.13-rc3-mm3
Andrew Morton
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
- Added the anonymous pagefault scalability enhancement patches.
I remain fairly dubious about this - it seems a fairly specific and
complex piece of work to speed up one extremely specific part of one type of
computer's one type of workload. Surely there's a better way :(
The patches at present spit warnings or don't compile on lots of
architectures. x86, x86_64, ppc64 and ia64 are OK.
- There's a pretty large x86_64 update here which naughty maintainer wants
in 2.6.13. Extra testing, please.
- Dropped git-net.patch (davem's net devel tree). I'm seeing weird TCP
hangs. I'm fairly sure they're present in mainline, but was unable to
reproduce it without git-net.patch when I was actually trying.
Changes since 2.6.13-rc3-mm2:
linus.patch
git-acpi.patch
git-cryptodev.patch
git-drm.patch
git-audit.patch
git-input.patch
git-kbuild.patch
git-libata-adma-mwi.patch
git-libata-chs-support.patch
git-libata-passthru.patch
git-libata-promise-sata-pata.patch
git-netdev-chelsio.patch
git-netdev-e100.patch
git-netdev-smc91x-eeprom.patch
git-netdev-ieee80211-wifi.patch
git-ocfs2.patch
git-serial.patch
git-scsi-block.patch
git-scsi-misc-drivers-scsi-chc-remove-devfs-stuff.patch
Subsystem trees
-i2c-mpc-restore-code-removed.patch
-really-__nocast-annotate-kmalloc_node.patch
-mips-fbdev-kconfig-fix.patch
-md-when-resizing-an-array-we-need-to-update-resync_max_sectors-as-well-as-size.patch
-uml-readd-missing-define-to-arch-um-makefile-i386.patch
-uml-add-dependency-to-arch-um-makefile-for-parallel-builds.patch
-uml-add-skas0-command-line-option.patch
-uml-update-module-interface.patch
-uml-fix-misdeclared-function.patch
-x86_64-fix-smp-boot-lockup-on-some-machines.patch
-try_to_freeze-call-fixes.patch
-add-missing-tvaudio-try_to_freeze.patch
-fix-missing-refrigerator-invocation-in-jffs2.patch
-as-ioched-tunable-encoding-fix.patch
-reiserfs-fix-deadlock-in-inode-creation-failure-path-w-default-acl.patch
-ext2-drop-quota-reference-before-releasing-inode.patch
-ext3-drop-quota-references-before-releasing-inode.patch
-pnp-build-fix.patch
-address-bug-using-smp_processor_id-in-preemptible.patch
-watchdog-add-missing-0x-in-alim1535_wdtc.patch
-itimer-fixes.patch
-add-pcibios_bus_to_resource-for-parisc.patch
-autofs4-fix-infamous-busy-inodes-after-umount-message.patch
-scsi_scan-check-return-code-from-scsi_sysfs_add_sdev.patch
-i4l-add-olitec-isdn-pci-card-in-hisax-gazel-driver.patch
-jsm-use-dynamic-major-number-allocation.patch
-jsm-warning-fixes.patch
-undo-mempolicy-shared-policy-rbtree-microoptimization.patch
-ub-fix-for-blank-cds.patch
-fix-xip-sparse-file-handling-in-ext2.patch
-check_user_page_readable-deadlock-fix.patch
-mpt-fusion-free-irq-in-suspend.patch
-eurotechwdt-build-fix.patch
-softdog-build-fix.patch
-x86_64-fsnotify-build-fix.patch
-fix-warning-in-powernow-k8c.patch
-speakup-build-fix.patch
-drm-via-fix-sparse-warnings.patch
-netfilter-build-fix.patch
-ipv6_netfilter_init-warning-fix.patch
-consolidate-config_watchdog_nowayout-handling.patch
-madvise-does-not-always-return-ebadf-on-non-file.patch
-remove-bogus-warning-in-page_allocc.patch
-ppc-ppc64-use-kconfighz.patch
-ppc32-update-defconfigs.patch
-ppc32-add-proper-prototype-for-cpm2_reset.patch
-ppc32-make-the-uarts-on-mpc824x-individual-platform-devices.patch
-ppc32-8xx-update-datatlbmiss-exception-comment.patch
-ppc-fix-compilation-error-with-config_pq2fads.patch
-ppc32-fix-typo-in-setup-of-2nd-pci-bus-on-85xx.patch
-ppc32-fix-building-of-prpmc750.patch
-ppc32-fix-building-of-radstone_ppc7d.patch
-ppc32-fix-dma_map_page-to-use-page_to_bus.patch
-ppc32-fix-440sp-mal-channels-count.patch
-ppc32-fix-building-of-tqm8260-board.patch
-ppc64-update-defconfigs.patch
-ppc64-hide-config_adb.patch
-ppc64-genrtc-build-fix.patch
-make-a-few-functions-static-in-pmac_setupc.patch
-ppc64-dynamically-allocate-segment-tables.patch
-ppc64-remove-another-fixed-address-constraint.patch
-mips-remove-obsolete-giu-driver-for-vr41xx.patch
-i386-add-missing-kconfig-help-text.patch
-m32r-add-missing-kconfig-help-text.patch
-cris-update-1-17-arch-split.patch
-cris-update-2-17-configuration-and-build.patch
-cris-update-3-17-console.patch
-cris-update-4-17-debug.patch
-cris-update-5-17-drivers.patch
-cris-update-6-17-i-o-and-dma-allocator.patch
-cris-update-7-17-irq.patch
-cris-update-8-17-misc-patches.patch
-cris-update-9-17-mm.patch
-cris-update-10-17-pci.patch
-cris-update-11-17-profiler.patch
-cris-update-12-17-serial-port-driver.patch # rmk said no
-cris-update-13-17-smp.patch
-cris-update-14-17-synchronous-serial-port-driver.patch
-cris-update-15-17-updates-for-2612.patch
-cris-update-17-17-new-subarchitecture-v32.patch
-cris-update-17-17-new-subarchitecture-v32-swapped-kmalloc-args.patch
-cris-ide-driver.patch
-v850-define-pfn_valid.patch
-v850-const-qualify-first-parameter-of-find_next_zero_bit.patch
-v850-add-defconfigs.patch
-v850-update-ioremap-return-type-and-add-ioread-iowrite-functions.patch
-v850-add-pte_file.patch
-v850-update-pci-support.patch
-v850-define-l1_cache_shift-and-l1_cache_shift_max.patch
-s390-spin-lock-retry.patch
-s390-find_next_zero_bit-fixes.patch
-s390-atomic64-inline-functions.patch
-s390-external-call-performance.patch
-s390-debug-data-for-ifcc-ccc.patch
-s390-resource-accessibility-event-handling.patch
-s390-fba-dasd-i-o-errors.patch
-s390-free-dasd-slab-cache.patch
-s390-channel-tape-fixes.patch
-s390-31-bit-memory-size-limit.patch
-s390-cpu-timer-reset-in-machine-check-handler.patch
-s390-use-__cpcmd-in-vmcp_write.patch
-fortuna-random-driver-fix.patch
-stale-posix-lock-handling.patch
-cciss-per-disk-queue.patch
-kernel-capabilityc-add-kerneldoc.patch
-kernel-cpusetc-add-kerneldoc-fix-typos.patch
-kernel-crash_dumpc-add-kerneldoc.patch
-tpm-support-for-infineon-tpm.patch
-ppc64-tpm_infineon-build-fix.patch
-mbcache-remove-unused-mb_cache_shrink-parameter.patch
-documentation-changes-document-the-required-udev-version.patch
-reiserfs-doesnt-use-mbcache.patch
-ia64-halt-hangup-fix.patch
-turn-many-if-undefined_string-into-ifdef-undefined_string.patch
-riva-wundef-fix.patch
-sys_get_thread_area-does-not-clear-the-returned-argument.patch
-serial_core-whitespace-fix.patch
-add-text-for-dealing-with-dot-releases-to-readme.patch
-ib-update-fmr-functions.patch
-ib-update-mad-client-api.patch
-ib-add-mad-helper-functions.patch
-ib-combine-some-mad-routines.patch
-ib-change-saving-of-users-send-wr_id-in-mad.patch
-ib-change-ib_mad_send_wr_private-struct.patch
-ib-fix-timeout-cancelled-mad-handling.patch
-ib-minor-cleanup-during-mad-startup-and-shutdown.patch
-ib-add-ib_coalesce_recv_mad-to-mad.patch
-ib-add-automatic-retries-to-mad-layer.patch
-ib-simplify-calling-of-list_del-in-mad.patch
-ib-eliminate-mad-cache-leak-associated-with-local.patch
-ib-add-ib_modify_mad-api-to-mad.patch
-ib-optimize-canceling-a-mad.patch
-ib-fix-a-couple-of-mad-code-paths.patch
-ib-add-ib_create_ah_from_wc-to-ib-verbs.patch
-ib-a-couple-of-ib-core-bug-fixes.patch
-ib-introduce-rmpp-apis.patch
-ib-add-rmpp-implementation.patch
-ib-add-service-record-support-to-sa-client.patch
-ib-add-the-header-file-for-kernel-cm-communications.patch
-ib-add-the-kernel-cm-implementation.patch
-ib-user-mad-abi-changes-to-support-rmpp.patch
-ib-implementation-for-rmpp-support-in-user-mad.patch
-ib-add-the-header-file-for-user-space-cm.patch
-ib-add-kernel-portion-of-user-cm-implementation.patch
-ib-add-kernel-portion-of-user-cm-implementation-fix.patch
-ib-hook-up-userspace-cm-to-the-make-system.patch
-ib-eliminate-sparse-warnings-in-sa-client.patch
-ib-add-core-locking-documentation-to-infiniband.patch
-dvico-fusion-dvb-t1-tuner-lg-z201-fix.patch
-drivers-media-video-tveepromc-possible-cleanups.patch
-video_saa7134-must-depend-on-sound.patch
-v4l-fix-regression-modprobe-bttv-freezes-the-computer.patch
-dvb-v4l-lgdt3302-isolate-tuner.patch
-dvb-v4l-rf-input-selection-fix.patch
-lgdt3302-warning-fix.patch
-dvb-v4l-cx88-cleanup.patch
-v4l-hybrid-dvb-fix-warnings-with-wundef.patch
-v4l-hybrid-dvb-move-defines-to-makefile.patch
-v4l-hybrid-dvb-rename-cflags-from-config_dvb_xxxx-back.patch
-v4l-fix-tuning-with-mxb-driver.patch
-dvb-rename-lgdt3302-frontend-module-to-lgdt330x.patch
-serial-mri-mri-pcids1-dual-port-serial-card.patch
-clean-up-the-old-digi-support-and-rescue-it.patch
-cpm_uart-use-dpram-for-early-console.patch
-fbmon-horizontal-frequency-rounding-fix.patch
-fbmem-use-unregister_chrdev-on-unload.patch
-radeonfb-clean-up-edid-sysfs-attribute.patch
-fbdev-colormap-fixes.patch
-dont-repaint-the-cursor-when-it-is-disabled.patch
-fbdev-update-info-cmap-when-setting-cmap-from-user-kernelspace.patch
-clean-up-inline-static-vs-static-inline.patch
-update-credits-entry-and-listings-in-source-files-for-jesper.patch
Merged
+bio_clone-fix.patch
Fix BIO cloning bug - might be the cause of data corruption on some MD
setups.
+x86_64-always-ack-ipis-even-on-errors.patch
+x86_64-update-defconfig.patch
+x86_64-use-for_each_cpu_mask-for-clustered-ipi-flush.patch
+x86_64-i386-x86_64-remove-prototypes-for-not-existing.patch
+x86_64-move-cpu_present-possible_map-parsing-earlier.patch
+x86_64-minor-clean-up-to-cpu-setup-use-smp_processor_id-instead-of-custom-hack.patch
+x86_64-clarify-booting-processor-message.patch
+x86_64-some-cleanup-in-setup64c.patch
+x86_64-remove-unused-variable-in-delayc.patch
+x86_64-improve-config_gart_iommu-description-and-make-it-default-y.patch
+x86_64-some-updates-for-boot-optionstxt.patch
+x86_64-fix-some-comments-in-tlbflushh.patch
+x86_64-remove-obsolete-eat_key-prototype.patch
+x86_64-fix-some-typos-in-systemh-comments.patch
+x86_64-fix-incorrectly-defined-msr_k8_syscfg.patch
+x86_64-fix-overflow-in-numa-hash-function-setup.patch
+x86_64-print-a-boot-message-for-hotplug-memory-zones.patch
+x86_64-create-per-cpu-machine-check-sysfs-directories.patch
+x86_64-remove-ia32_-build-tools-in-makefile.patch
+x86_64-remove-the-broadcast-options-that-were-added-for.patch
+x86_64-support-more-than-8-cores-on-amd-systems.patch
+x86_64-icecream-has-no-way-of-detecting-assembler-level.patch
+x86_64-turn-bug-data-into-valid-instruction.patch
+x86_64-when-running-cpuid4-need-to-run-on-the-correct.patch
+x86_64-remove-unnecessary-include-in-faultc.patch
+x86_64-small-assembly-improvements.patch
+x86_64-switch-to-the-interrupt-stack-when-running-a.patch
+x86_64-fix-srat-handling-on-non-dual-core-systems.patch
+x86_64-fix-gcc-4-warning-in-sched_find_first_bit.patch
+x86_64-use-msleep-in-smpbootc.patch
+x86_64-remove-unused-variable-in-k8-busc.patch
+x86_64-fix-cpu_to_node-setup-for-sparse-apic_ids.patch
x86_64 update
+cs89x0-collect-tx_bytes-statistics.patch
net driver stats fix
+ppc32-inotify-syscalls.patch
+ppc64-inotify-syscalls.patch
ppc32/ppc64 syscall table updates
+selinux-default-labeling-of-mls-field.patch
SELinux multilevel security feature work
+pcdp-if-pcdp-contains-parity-information-use-it.patch
pcdp driver fix
+qla2xxx-mark-dependency-on-fw_loader.patch
qlogic Kconfig fix
+alpha-fix-statement-with-no-effect-warnings.patch
Alpha warning fixes
+mm-ensure-proper-alignment-for-node_remap_start_pfn.patch
memory management initialisation fix
-move-truncate_inode_pages-into-delete_inode.patch
This is in git-ocfs2.patch
+mpt-fusion-free-irq-in-suspend.patch
mpt-fusion power management fix
+gregkh-driver-stable_api_nonsense.txt-fixes.patch
+gregkh-driver-speakup-kconfig-fix.patch
+gregkh-driver-speakup-kconfig-fix-2.patch
+gregkh-driver-speakup-build-fix.patch
Greg's driver core tree
+drivers-char-drm-drm_pcic-fix-warnings.patch
Warning fixes
+gregkh-i2c-w1-netlink-callbacks.patch
Greg's i2c tree
+git-net-gregkh-i2c-w1-netlink-callbacks-fix.patch
Fix incompatibility between git-net and Greg's i2c tree
+include-net-ieee80211h-must-include-linux-wirelessh.patch
net build fix
+gregkh-pci-pci-restore-bar-values.patch
Greg's PCI tree
-revert-gregkh-pci-pci-assign-unassigned-resources.patch
Hopefully no longer needed
+mpt-fusion-dv-fixes.patch
Try to fix some mpt-fusion domain validation problems (doesn't seem to work)
+gregkh-usb-usb-ftdi_sio-new-devices.patch
+gregkh-usb-usb-ftdi_sio-rts-dtr.patch
+gregkh-usb-usb-ftdi_sio-timeout-fix.patch
+gregkh-usb-usb-usbfs-dont-leak-data.patch
+gregkh-usb-usb-usbnet-remove-unused-vars.patch
+gregkh-usb-usb-dont-delete-unregistered-interfaces.patch
+gregkh-usb-usb-usbserial-remove-unneeded-casts.patch
Greg's USB tree
-proc-pid-numa_maps-to-show-on-which-nodes-pages-reside-tidy.patch
Folded into proc-pid-numa_maps-to-show-on-which-nodes-pages-reside.patch
+vm-add-capabilites-check-to-set_zone_reclaim.patch
Make sys_set_zone_reclaim() privileged
+page-fault-patches-introduce-pte_xchg-and-pte_cmpxchg.patch
+page-fault-patches-introduce-pte_xchg-and-pte_cmpxchg-fix.patch
+page-fault-patches-optional-page_lock-acquisition-in.patch
+page-fault-patches-optional-page_lock-acquisition-in-tidy.patch
+page-fault-patches-no-pagetable-lock-in-do_anon_page.patch
anonymous pagefault scalability enhancements.
-net-add-driver-for-the-nic-on-cell-blades-kconfig-fix.patch
Folded into net-add-driver-for-the-nic-on-cell-blades.patch
-sk98lin-basic-suspend-resume-support-fix.patch
Folded into sk98lin-basic-suspend-resume-support.patch
+ppc32-mark-boards-that-dont-build-as-broken.patch
+ppc32-add-440ep-support.patch
+ppc32-add-bamboo-platform.patch
+ppc32-add-bamboo-defconfig.patch
+ppc32-remove-board-support-for-adir.patch
+ppc32-remove-board-support-for-ash.patch
+ppc32-remove-board-support-for-beech.patch
+ppc32-remove-defconfig-for-cedar.patch
+ppc32-remove-board-support-for-k2.patch
+ppc32-remove-board-support-for-mcpn765.patch
+ppc32-remove-board-support-for-menf1.patch
+ppc32-remove-board-support-for-oak.patch
+ppc32-remove-board-support-for-rainier.patch
+ppc32-remove-board-support-for-redwood.patch
+ppc32-remove-board-support-for-sm850.patch
+ppc32-remove-board-support-for-spd823ts.patch
+ppc32-remove-board-support-for-ep405.patch
+ppc32-remove-board-support-for-pcore.patch
ppc32 work
+ppc64-remove-nested-feature-sections.patch
ppc64 cleanup
+ptrace-i386-fix-syscall-audit-interaction-with-singlestep.patch
+uml-support-ptrace-adds-the-host-sysemu-support-for-uml-and-general-usage.patch
+uml-support-reorganize-ptrace_sysemu-support.patch
+uml-support-add-ptrace_sysemu_singlestep-option-to-i386.patch
+sysemu-fix-sysaudit--singlestep-interaction.patch
UML feature work
-areca-raid-linux-scsi-driver-fix.patch
Folded into areca-raid-linux-scsi-driver.patch (will be dropped from next -mm)
-relayfs-cancel-work-on-close-reset.patch
-relayfs-add-private-data-to-channel-struct.patch
-relayfs-function-docfix.patch
-relayfs-add-relayfs-website-to-documentation.patch
-avoid-lookup_hash-usage-in-relayfs.patch
Folded into relayfs.patch
-add-skip_hangcheck_timer.patch
Dropped, but will come back.
-yealink-updates.patch
-yealink-updates-0701.patch
Folded into new-driver-for-yealink-usb-p1k-phone.patch
+support-powering-sharp-zaurus-sl-5500-lcd-up-and-down.patch
Make Pavel's Zausus happier
+radix_tag_get-differentiate-between-no-present-node-and-tag-unset-cases.patch
+radix_tag_get-differentiate-between-no-present-node-and-tag-unset-cases-fix.patch
radix_tree_tag_get() API enhancement.
+aio-fix-races-in-callback-path.patch
AIO race fix
+auxiliary-vector-cleanups.patch
SHuffle the AT_* auxiliary vector defines around
+pnp-consolidate-kmalloc-wrappers.patch
PNP cleanup
-fix-race-in-do_get_write_access-warning-fix.patch
Folded into fix-race-in-do_get_write_access.patch
-kprobes-prevent-possible-race-conditions-generic-fixes.patch
Folded into kprobes-prevent-possible-race-conditions-generic.patch
-kprobes-prevent-possible-race-conditions-ia64-changes-fixes.patch
Folded into kprobes-prevent-possible-race-conditions-ia64-changes.patch
-connector-exit-notifier-fix.patch
-connector-exit-notifier-remove-the-union-declaration.patch
-connector-exit-notifier-fix-missing-dependencies-in.patch
Folded into connector-exit-notifier.patch
-connector-add-a-fork-connector-use-after-free-fix.patch
-connector-add-a-fork-connector-remove-the-union-declaration-fork.patch
-connector-fork-notifier-fix-missing-dependencies-in.patch
Folded into connector-add-a-fork-connector.patch
-jbd-split-checkpoint-lists-tweaks.patch
Folded into jbd-split-checkpoint-lists.patch
-spinlock-consolidation-m32r-fix.patch
-spinlock-consolidation-up-spinlocks-gcc-29x-fix.patch
-page_uptodate-locking-scalability-fix.patch
-spinlock-consolidation-s390-fix.patch
Folded into spinlock-consolidation.patch
-revert-fix-broken-kmalloc_node-in-rc1-rc2.patch
-numa-aware-slab-allocator-v5-fix.patch
-numa-slab-allocator-cleanups.patch
Folded into numa-aware-slab-allocator-v5.patch
-iteraid-remove-ite_ioc_get_driver_version.patch
Folded into iteraid.patch (will be dropped from next -mm)
-page-owner-tracking-leak-detector-tidy.patch
Folded into page-owner-tracking-leak-detector.patch
-perfctr-handle-non-of-ppc32-platforms.patch
-perfctr-syscall-numbering-fixups.patch
Folded into perfctr.patch
+split-general-cache-manager-from-cachefs-fs-fscache-cleanups.patch
clean up split-general-cache-manager-from-cachefs.patch
-files-break-up-files-struct-warning-fix.patch
Folded into files-break-up-files-struct.patch
-asfs-filesystem-driver-fixes.patch
Folded into asfs-filesystem-driver.patch
-v9fs-documentation-makefiles-configuration-resend-take-2.patch
Folded into v9fs-documentation-makefiles-configuration.patch
-v9fs-vfs-file-dentry-and-directory-operations-fix-fsf-postal-address-in-source-headers.patch
-v9fs-vfs-file-dentry-and-directory-operations-resend-take-2.patch
Folded into v9fs-vfs-file-dentry-and-directory-operations.patch
-v9fs-vfs-inode-operations-fix-fsf-postal-address-in-source-headers.patch
-v9fs-vfs-inode-operations-resend-take-2.patch
Folded into v9fs-vfs-inode-operations.patch
-v9fs-vfs-superblock-operations-and-glue-fix-fsf-postal-address-in-source-headers.patch
-v9fs-vfs-superblock-operations-and-glue-resend-take-2.patch
-v9fs-vfs-superblock-operations-and-glue-replace-v9fs_block_bits-with-fls.patch
Folded into v9fs-vfs-superblock-operations-and-glue.patch
-v9fs-9p-protocol-implementation-fix-fsf-postal-address-in-source-headers.patch
-v9fs-9p-protocol-implementation-resend-take-2.patch
Folded into v9fs-9p-protocol-implementation.patch
-v9fs-transport-modules-fix-fsf-postal-address-in-source-headers.patch
-v9fs-transport-modules-fix-timeout-segfault-corner-case.patch
-v9fs-transport-modules-resend-take-2.patch
Folded into v9fs-transport-modules.patch
-v9fs-debug-and-support-routines-fix.patch
-v9fs-debug-and-support-routines-fix-fsf-postal-address-in-source-headers.patch
-v9fs-debug-and-support-routines-resend-take-2.patch
Folded into v9fs-debug-and-support-routines.patch
-v9fs-clean-up-vfs_inode-and-setattr-functions-2.patch
Folded into v9fs-clean-up-vfs_inode-and-setattr-functions.patch
+serial-add-mmio-support-to-8250_pnp.patch
Add MMIO support to the UART driver
-device-mapper-fix-deadlocks-in-core-prep-fix.patch
Folded into device-mapper-fix-deadlocks-in-core-prep.patch
-timer-initialization-cleanup-define_timer-pluto-fix.patch
Folded into timer-initialization-cleanup-define_timer.patch
All 633 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/patch-list
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk
>...
> Changes since 2.6.13-rc3-mm2:
>...
> +alpha-fix-statement-with-no-effect-warnings.patch
>
> Alpha warning fixes
>...
This patch broke the compilation on i386 with CONFIG_SMP=n and
CONFIG_MTRR=y:
<-- snip -->
...
CC arch/i386/kernel/cpu/mtrr/main.o
arch/i386/kernel/cpu/mtrr/main.c: In function 'set_mtrr':
arch/i386/kernel/cpu/mtrr/main.c:225: error: 'ipi_handler' undeclared (first use in this function)
arch/i386/kernel/cpu/mtrr/main.c:225: error: (Each undeclared identifier is reported only once
arch/i386/kernel/cpu/mtrr/main.c:225: error: for each function it appears in.)
make[3]: *** [arch/i386/kernel/cpu/mtrr/main.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bu...@stusta.de>
--- linux-2.6.13-rc3-mm3/arch/i386/kernel/cpu/mtrr/main.c.old 2005-07-28 12:36:09.000000000 +0200
+++ linux-2.6.13-rc3-mm3/arch/i386/kernel/cpu/mtrr/main.c 2005-07-28 12:39:35.000000000 +0200
@@ -221,9 +221,11 @@
atomic_set(&data.count, num_booting_cpus() - 1);
atomic_set(&data.gate,0);
+#ifdef CONFIG_SMP
/* Start the ball rolling on other CPUs */
if (smp_call_function(ipi_handler, &data, 1, 0) != 0)
panic("mtrr: timed out waiting for other CPUs\n");
+#endif /* CONFIG_SMP */
local_irq_save(flags);
Alexandre Buisse
> CC arch/i386/kernel/cpu/mtrr/main.o
>arch/i386/kernel/cpu/mtrr/main.c: In Funktion »set_mtrr«:
>arch/i386/kernel/cpu/mtrr/main.c:225: error: `ipi_handler' undeclared (first use in this function)
>arch/i386/kernel/cpu/mtrr/main.c:225: error: (Each undeclared identifier is reported only once
>arch/i386/kernel/cpu/mtrr/main.c:225: error: for each function it appears in.)
>make[3]: *** [arch/i386/kernel/cpu/mtrr/main.o] Fehler 1
>make[2]: *** [arch/i386/kernel/cpu/mtrr] Fehler 2
>make[1]: *** [arch/i386/kernel/cpu] Fehler 2
>make: *** [arch/i386/kernel] Fehler 2
>
>I'm in a hurry, so I got no time to see what's causing this. Config is attached.
>
>
I have the same error here (MTRR enabled and no SMP).
I solved it by adding #ifdef CONFIG_SMP around lines 224 to 226 in this
file, but I am not sure it is totally safe.
I don't see why smp specific operations are not protected this way in
this file.
Regards,
Alexandre
Rafael J. Wysocki
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
>
> - Added the anonymous pagefault scalability enhancement patches.
>
> I remain fairly dubious about this - it seems a fairly specific and
> complex piece of work to speed up one extremely specific part of one type of
> computer's one type of workload. Surely there's a better way :(
>
> The patches at present spit warnings or don't compile on lots of
> architectures. x86, x86_64, ppc64 and ia64 are OK.
>
> - There's a pretty large x86_64 update here which naughty maintainer wants
> in 2.6.13. Extra testing, please.
There are two problems with the compilation of arch/x86_64/kernel/nmi.c.
The following patch fixes them.
Greets,
Rafael
Signed-off-by: Rafael J. Wysocki <r...@sisk.pl>
--- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/nmi.c 2005-07-28 21:05:53.000000000 +0200
+++ patched/arch/x86_64/kernel/nmi.c 2005-07-28 18:58:02.000000000 +0200
@@ -152,8 +152,10 @@ int __init check_nmi_watchdog (void)
printk(KERN_INFO "testing NMI watchdog ... ");
+#ifdef CONFIG_SMP
if (nmi_watchdog == NMI_LOCAL_APIC)
smp_call_function(nmi_cpu_busy, (void *)&endflag, 0, 0);
+#endif
for (cpu = 0; cpu < NR_CPUS; cpu++)
counts[cpu] = cpu_pda[cpu].__nmi_count;
@@ -290,7 +292,7 @@ void enable_timer_nmi_watchdog(void)
static int nmi_pm_active; /* nmi_active before suspend */
-static int lapic_nmi_suspend(struct sys_device *dev, u32 state)
+static int lapic_nmi_suspend(struct sys_device *dev, pm_message_t state)
{
nmi_pm_active = nmi_active;
disable_lapic_nmi_watchdog();
Andrew Morton
"Rafael J. Wysocki" <r...@sisk.pl> wrote:
>
> There are two problems with the compilation of arch/x86_64/kernel/nmi.c.
Thanks.
> --- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/nmi.c 2005-07-28 21:05:53.000000000 +0200
> +++ patched/arch/x86_64/kernel/nmi.c 2005-07-28 18:58:02.000000000 +0200
> @@ -152,8 +152,10 @@ int __init check_nmi_watchdog (void)
>
> printk(KERN_INFO "testing NMI watchdog ... ");
>
> +#ifdef CONFIG_SMP
> if (nmi_watchdog == NMI_LOCAL_APIC)
> smp_call_function(nmi_cpu_busy, (void *)&endflag, 0, 0);
> +#endif
>
> for (cpu = 0; cpu < NR_CPUS; cpu++)
> counts[cpu] = cpu_pda[cpu].__nmi_count;
This bit is no longer needed, since
alpha-fix-statement-with-no-effect-warnings.patch got dropped.
Christoph Lameter
> I remain fairly dubious about this - it seems a fairly specific and
> complex piece of work to speed up one extremely specific part of one type of
> computer's one type of workload. Surely there's a better way :(
The patches provide the basis for more work on this issue. But we need to
start somewhere. The specific issue addresses in the initial patchset is
becoming a common case for multi-core applications.
> The patches at present spit warnings or don't compile on lots of
> architectures. x86, x86_64, ppc64 and ia64 are OK.
I have just sent a fix to you this morning when I got your messages.
Sadly I do not have access to the architectures that failed (arm, alpha
and ppc32) but the fix simply removes code that is not used for these
arches.
Russell King
> On Thu, 28 Jul 2005, Andrew Morton wrote:
> > The patches at present spit warnings or don't compile on lots of
> > architectures. x86, x86_64, ppc64 and ia64 are OK.
>
> I have just sent a fix to you this morning when I got your messages.
> Sadly I do not have access to the architectures that failed (arm, alpha
> and ppc32) but the fix simply removes code that is not used for these
> arches.
ARM can't support atomic page table operations as such - the Linux view
of the page table is separate from the hardware view, and there's some
CPU specific code which translates from the Linux view to the hardware
view.
Looking at the actual patches, particularly pte_xchg-and-pte_cmpxchg.patch
combined with the above, the ARM solution would be to go back to using
non-atomic operations here (since we can't do this atomically.) Also,
since the MMU will only ever read from the page tables, I don't think
we need to play any games with clearing out ptes before we replace the
value.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Michael Thonke
I have some questions :-)
Reiser4:
why there are undefined functions implemented that currently not in use?
This messages appeared first time in 2.6.13-rc3-mm2.
Any why it complains even CONFIG_REISER4_DEBUG is not set?
Please have a look at the -->snip
SCSI:
CONFIG_SCSI_QLA2XXX=y ? I haven't choose that one..I never did..and
where is the config located?
In the place where it is..is no option marked.
Thanks for help,
Greets
Michael
--> snip
fs/reiser4/plugin/item/static_stat.c:1158:5: warning:
"REISER4_DEBUG_OUTPUT" is not defined
fs/reiser4/plugin/item/static_stat.c:1176:5: warning:
"REISER4_DEBUG_OUTPUT" is not defined
fs/reiser4/plugin/item/static_stat.c:1194:5: warning:
"REISER4_DEBUG_OUTPUT" is not defined
fs/reiser4/plugin/item/static_stat.c:1213:5: warning:
"REISER4_DEBUG_OUTPUT" is not defined
CC fs/reiser4/plugin/item/sde.o
In file included from fs/reiser4/plugin/item/../plugin.h:26,
from fs/reiser4/plugin/item/sde.c:11:
fs/reiser4/plugin/item/../node/node40.h:83:5: warning: "GUESS_EXISTS" is
not defined
fs/reiser4/plugin/item/sde.c:21:5: warning: "REISER4_DEBUG_OUTPUT" is
not defined
CC fs/reiser4/plugin/item/cde.o
In file included from fs/reiser4/plugin/item/../plugin.h:26,
from fs/reiser4/plugin/item/cde.c:65:
fs/reiser4/plugin/item/../node/node40.h:83:5: warning: "GUESS_EXISTS" is
not def
Andrew Morton
>
> Hello Andrew,
>
> I have some questions :-)
> Reiser4:
>
> why there are undefined functions implemented that currently not in use?
> This messages appeared first time in 2.6.13-rc3-mm2.
>
> Any why it complains even CONFIG_REISER4_DEBUG is not set?
That's due to the code using `#if CONFIG_xx' instead of `#ifdef'.
>
> SCSI:
>
> CONFIG_SCSI_QLA2XXX=y ? I haven't choose that one..I never did..and
> where is the config located?
Someone was doing wrong things in the Makefile. I think that has been
subsequently fixed.
Adrian Bunk
> Hello Andrew,
>
> I have some questions :-)
> Reiser4:
>
> why there are undefined functions implemented that currently not in use?
> This messages appeared first time in 2.6.13-rc3-mm2.
>
> Any why it complains even CONFIG_REISER4_DEBUG is not set?
> Please have a look at the -->snip
These aren't functions, these are #if FOO where FOO isn't #define'd.
In most such cases, changing the #if ti #ifdef fixes the issue (and in
some rare cases these warnings fix bugs).
Since 2.6.13-rc3-mm2 the gcc Warning for such things was activated.
> SCSI:
>
> CONFIG_SCSI_QLA2XXX=y ? I haven't choose that one..I never did..and
> where is the config located?
> In the place where it is..is no option marked.
It's located in drivers/scsi/qla2xxx/Kconfig.
It shouldn't [1] activate any code, it's simply a helper option that
tells whether the QLA* options should be shown.
> Thanks for help,
>
> Greets
> Michael
>
>
> --> snip
> fs/reiser4/plugin/item/static_stat.c:1158:5: warning:
> "REISER4_DEBUG_OUTPUT" is not defined
> fs/reiser4/plugin/item/static_stat.c:1176:5: warning:
> "REISER4_DEBUG_OUTPUT" is not defined
> fs/reiser4/plugin/item/static_stat.c:1194:5: warning:
> "REISER4_DEBUG_OUTPUT" is not defined
> fs/reiser4/plugin/item/static_stat.c:1213:5: warning:
> "REISER4_DEBUG_OUTPUT" is not defined
> CC fs/reiser4/plugin/item/sde.o
> In file included from fs/reiser4/plugin/item/../plugin.h:26,
> from fs/reiser4/plugin/item/sde.c:11:
> fs/reiser4/plugin/item/../node/node40.h:83:5: warning: "GUESS_EXISTS" is
> not defined
> fs/reiser4/plugin/item/sde.c:21:5: warning: "REISER4_DEBUG_OUTPUT" is
> not defined
> CC fs/reiser4/plugin/item/cde.o
> In file included from fs/reiser4/plugin/item/../plugin.h:26,
> from fs/reiser4/plugin/item/cde.c:65:
> fs/reiser4/plugin/item/../node/node40.h:83:5: warning: "GUESS_EXISTS" is
> not def
cu
Adrian
[1] that's currently not completely true, but the problem will soon be
fixed
--
"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
Adrian Bunk
>...
> Changes since 2.6.13-rc3-mm2:
>...
>
> qlogic Kconfig fix
>...
This patch is wrong since it adds a select to SCSI_QLA2XXX.
Please drop it.
Andrew Vasquez had a better fix and is discussing it with James.
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
-
Christoph Lameter
> ARM can't support atomic page table operations as such - the Linux view
> of the page table is separate from the hardware view, and there's some
> CPU specific code which translates from the Linux view to the hardware
> view.
Yes. The patches fall back to nonatomic operations for ARM.
> Looking at the actual patches, particularly pte_xchg-and-pte_cmpxchg.patch
> combined with the above, the ARM solution would be to go back to using
> non-atomic operations here (since we can't do this atomically.) Also,
> since the MMU will only ever read from the page tables, I don't think
> we need to play any games with clearing out ptes before we replace the
> value.
Ok. Then you can use a part of the patches. Define ptep_xchg and
ptep_cmpxchg for ARM so that you do can avoid intermittently clearing
ptes.
Here is the patch that I sent to Andrew in the morning:
Index: linux-2.6.13-rc3/mm/memory.c
===================================================================
--- linux-2.6.13-rc3.orig/mm/memory.c 2005-07-27 15:34:41.000000000 -0700
+++ linux-2.6.13-rc3/mm/memory.c 2005-07-28 09:24:05.000000000 -0700
@@ -2071,6 +2071,7 @@
*/
page_table_atomic_start(mm);
pgd = pgd_offset(mm, address);
+#ifndef __PAGETABLE_PUD_FOLDED
if (unlikely(pgd_none(*pgd))) {
pud_t *new;
@@ -2084,6 +2085,7 @@
if (!pgd_test_and_populate(mm, pgd, new))
pud_free(new);
}
+#endif
pud = pud_offset(pgd, address);
if (unlikely(pud_none(*pud))) {
Nick Sillik
> Michael Thonke <iogl...@gmail.com> wrote:
>
>>Hello Andrew,
>>
>>I have some questions :-)
>>Reiser4:
>>
>>why there are undefined functions implemented that currently not in use?
>>This messages appeared first time in 2.6.13-rc3-mm2.
>>
>>Any why it complains even CONFIG_REISER4_DEBUG is not set?
>
>
> That's due to the code using `#if CONFIG_xx' instead of `#ifdef'.
>
I previously posted a patch that got rid of one of these, find it
attached again below.
Signed-off-by: Nick Sillik <n.si...@temple.edu>
Michael Thonke
>------------------------------------------------------------------------
>
>diff -urN a/fs/reiser4/plugin/node/node40.h b/fs/reiser4/plugin/node/node40.h
>--- a/fs/reiser4/plugin/node/node40.h 2005-07-27 18:14:04.000000000 -0400
>+++ b/fs/reiser4/plugin/node/node40.h 2005-07-27 18:14:53.000000000 -0400
>@@ -80,7 +80,7 @@
> int check_node40(const znode * node, __u32 flags, const char **error);
> int parse_node40(znode * node);
> int init_node40(znode * node);
>-#if GUESS_EXISTS
>+#ifdef GUESS_EXISTS
> int guess_node40(const znode * node);
> #endif
> void change_item_size_node40(coord_t * coord, int by);
>
>
Thanks, this fixed the complains on compiling kernel :-)
Michael Thonke
here again I have two problems. With 2.6.13-rc3-mm3 I have problems
using my SATA drives on Intel ICH6.
The kernel can't route there IRQs or can't discover them. the option
irqpoll got them to work now.
The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems.
The SATA drives are Samsung HD160JJ SATAII. The mainboard I use is a
ASUS P4GPL-X.
Second one is about Intel HD-Codec (snd-hda-intel) on modprobe when
loading the module it gives me
---> snip
hda_codec: Unknown model for ALC880, trying auto-probe from BIOS...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
f88713f4
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
last sysfs file:
Modules linked in: snd_hda_intel snd_hda_codec nvidia
CPU: 0
EIP: 0060:[<f88713f4>] Tainted: P VLI
EFLAGS: 00010293 (2.6.13-rc3-mm3pm)
eax: fffffffe ebx: f3b33548 ecx: 00000000 edx: 00000000
esi: f3b33400 edi: 00000000 ebp: 00000006 esp: f0371ddc
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 7398, threadinfo=f0370000 task=f4183560)
Stack: 00000000 00000000 00000000 00000000 f3b33400 f3b33548 f0f1d000
f8871933
f3b33400 f0f1d000 f8871bbd f8875478 f88748f6 00000001 f886d77e
00000f00
00000005 00000000 f0f1d000 f54d04c0 00000000 f886d984 00000f00
00000002
Call Trace:
[<f8871933>]
[<f8871bbd>]
[<f886d77e>]
[<f886d984>]
[<f886d592>]
[<c025b87e>]
[<f8f5c871>]
[<f8f5c100>]
[<f8f5c220>]
[<f8f5d533>]
[<c026866a>]
[<c02686be>]
[<c02686f6>]
[<c02bf763>]
[<c02bf899>]
[<c02bee1a>]
[<c02bf8b6>]
[<c02bf860>]
[<c02bf30c>]
[<c02bfc85>]
[<c0268958>]
[<c013b5c9>]
[<c0102fcb>]
Code: 31 c0 53 83 ec 10 89 d3 89 e7 f3 ab 8b 12 31 ff 83 fa 00 7e 45 89
f6 0f b7 44 7b 04 8d 48 ec 66 83 f9 03 77 13 8b 56 3c 83 e8 16 <66> 89
04 7a 8b 13 c7 04 8c 01 00 00 00 47 39 fa 7f da 31 ff 83
--> snip
I also attached the kernel-config and the lspci -vv output.
Thanks again for the patience and the help.
Best regards
Michael
Rafael J. Wysocki
>
> "Rafael J. Wysocki" <r...@sisk.pl> wrote:
> >
> > There are two problems with the compilation of arch/x86_64/kernel/nmi.c.
>
> Thanks.
>
> > --- linux-2.6.13-rc3-mm3/arch/x86_64/kernel/nmi.c 2005-07-28 21:05:53.000000000 +0200
> > +++ patched/arch/x86_64/kernel/nmi.c 2005-07-28 18:58:02.000000000 +0200
> > @@ -152,8 +152,10 @@ int __init check_nmi_watchdog (void)
> >
> > printk(KERN_INFO "testing NMI watchdog ... ");
> >
> > +#ifdef CONFIG_SMP
> > if (nmi_watchdog == NMI_LOCAL_APIC)
> > smp_call_function(nmi_cpu_busy, (void *)&endflag, 0, 0);
> > +#endif
> >
> > for (cpu = 0; cpu < NR_CPUS; cpu++)
> > counts[cpu] = cpu_pda[cpu].__nmi_count;
>
> This bit is no longer needed, since
> alpha-fix-statement-with-no-effect-warnings.patch got dropped.
OK
BTW, -mm3 works fine for me on two AMD64 boxes except for one thing:
On Asus L5D, if I resume the box from disk on battery power (ie the box is started
on battery power and resumes from disk), it hangs solid right after copying
the image (100% of the time). If it is resumed on AC power, everything is fine.
Well, -mm1[1-2] did the same thing so I think I'll create a Bugzilla entry and
start a binary search. :-( The -git[5-9] kernels are not affected by this issue.
Greets,
Rafael
PS
Could you please tell me how I can figure out the order in which the individual
patches in -mm have been applied?
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
Dirk
> Hello Andrew,
>
> here again I have two problems. With 2.6.13-rc3-mm3 I have problems
> using my SATA drives on Intel ICH6.
> The kernel can't route there IRQs or can't discover them. the option
> irqpoll got them to work now.
> The problem is new because 2.6.13-rc3[-mm1,mm2] work without any
> problems.
>
> The SATA drives are Samsung HD160JJ SATAII. The mainboard I use is a
> ASUS P4GPL-X.
>
> Second one is about Intel HD-Codec (snd-hda-intel) on modprobe when
> loading the module it gives me
>
> ---> snip
> hda_codec: Unknown model for ALC880, trying auto-probe from BIOS...
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
Hi!
Sorry for interfering but I have the Asus P5RD1-VD with the Realtek
ALC861 (10b9:5461) and with 2.6.13.3 I've got the problem that he
doesn't find /dev/mixer or anything after modprobe snd-hda-intel...
After I attached
http://dlsvr01.asus.com/pub/ASUS/mb/socket775/P5RD1-V/Audio_Linux.zip
(which doesn't work) to a mail in alsa-devel they told me...
"[...]
It tries to access the ALi controller in the same way as the Intel
controller.
It may be possible that the ALi chip was designed to be compatible
with Intel's, but that they got some detail wrong. Or that the driver
gets some detail wrong. There's no way to know without docs[...]"
(not in the archive, yet...)
Dirk
Andrew Morton
>
> Could you please tell me how I can figure out the order in which the individual
> patches in -mm have been applied?
It's all in the series file:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/patch-series
The simplest way to do a binary search is to grab
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/2.6.13-rc3-mm3-broken-out.tar.bz2
and to place all the patches in ./patches/, place the series file in
./series, download and install https://savannah.nongnu.org/projects/quilt/
and do the binary search with `quilt push' and `quilt pop'.
It's pretty simple - it'll take ten minutes to get the hang of it. You
need to create a separate copy of the series file and edit it to record
where you're up to in the search. From experience ;)
Andrew Morton
>
> here again I have two problems. With 2.6.13-rc3-mm3 I have problems
> using my SATA drives on Intel ICH6.
> The kernel can't route there IRQs or can't discover them. the option
> irqpoll got them to work now.
> The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems.
OK. Please generate the full dmesg output for -mm2 and for -mm3 and run
`diff -u dmesg.mm2 dmesg.mm3' and send it? And keep those files because we
may end up needing to add them to an acpi bugzilla entry ;)
> The SATA drives are Samsung HD160JJ SATAII. The mainboard I use is a
> ASUS P4GPL-X.
>
> Second one is about Intel HD-Codec (snd-hda-intel) on modprobe when
> loading the module it gives me
>
> ---> snip
> hda_codec: Unknown model for ALC880, trying auto-probe from BIOS...
Does -mm2 print that `unknown model' message?
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> printing eip:
> f88713f4
> *pde = 00000000
> Oops: 0002 [#1]
> PREEMPT
> last sysfs file:
> Modules linked in: snd_hda_intel snd_hda_codec nvidia
> CPU: 0
> EIP: 0060:[<f88713f4>] Tainted: P VLI
Please verify that it happens without the nvidia module loaded.
> EFLAGS: 00010293 (2.6.13-rc3-mm3pm)
> eax: fffffffe ebx: f3b33548 ecx: 00000000 edx: 00000000
> esi: f3b33400 edi: 00000000 ebp: 00000006 esp: f0371ddc
> ds: 007b es: 007b ss: 0068
> Process modprobe (pid: 7398, threadinfo=f0370000 task=f4183560)
> Stack: 00000000 00000000 00000000 00000000 f3b33400 f3b33548 f0f1d000
> f8871933
> f3b33400 f0f1d000 f8871bbd f8875478 f88748f6 00000001 f886d77e
> 00000f00
> 00000005 00000000 f0f1d000 f54d04c0 00000000 f886d984 00000f00
> 00000002
> Call Trace:
> [<f8871933>]
> [<f8871bbd>]
Odd trace. Do you have CONFIG_KALLSYMS enabled? If not, please turn it on.
Martin J. Bligh
> - There's a pretty large x86_64 update here which naughty maintainer wants
> in 2.6.13. Extra testing, please.
Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
Talked to Andi about it at OLS, but then drank too much to remember the
conclusion ... however, it's still broken ;-)
Matrix is here (see left hand column).
Example boot log is here:
http://test.kernel.org/9447/debug/console.log
Martin J. Bligh
identified earlier with the sched patches ...
http://test.kernel.org/9398/debug/console.log
Works with mainline still (including -rc4) ... hopefully those patches
aren't on their way upstream anytime soon ;-)
M.
Martin J. Bligh
the problems crashing on boot I was having on PPC64 with -rc3-mm2. I'll
close the bugzilla bug.
Thanks!
M.
Andrew Morton
>
>
> > - There's a pretty large x86_64 update here which naughty maintainer wants
> > in 2.6.13. Extra testing, please.
>
> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
> Talked to Andi about it at OLS, but then drank too much to remember the
> conclusion ... however, it's still broken ;-)
>
> Matrix is here (see left hand column).
>
> http://test.kernel.org/
>
> Example boot log is here:
>
> http://test.kernel.org/9447/debug/console.log
Does Eric's recent fix fix it?
From: Eric W. Biederman <ebie...@xmission.com>
sync_tsc was using smp_call_function to ask the boot processor to report
it's tsc value. smp_call_function performs an IPI_send_allbutself which is
a broadcast ipi. There is a window during processor startup during which
the target cpu has started and before it has initialized it's interrupt
vectors so it can properly process an interrupt. Receveing an interrupt
during that window will triple fault the cpu and do other nasty things.
Why cli does not protect us from that is beyond me.
The simple fix is to match ia64 and provide a smp_call_function_single.
Which avoids the broadcast and is more efficient.
This certainly fixes the problem of getting stuck on boot which was very
easy to trigger on my SMP Hyperthreaded Xeon, and I think it fixes it for
the right reasons.
I believe this patch suffers from apicid versus logical cpu number
confusion. I copied the basic logic from smp_send_reschedule and I can't
find where that translates from the logical cpuid to apicid. So it isn't
quite correct yet. It should be close enough that it shouldn't be too hard
to finish it up.
More bug fixes after I have slept but I figured I needed to get this
one out for review.
Signed-off-by: Eric W. Biederman <ebie...@xmission.com>
Signed-off-by: Andrew Morton <ak...@osdl.org>
---
arch/x86_64/kernel/smp.c | 65 +++++++++++++++++++++++++++++++++++++++++++
arch/x86_64/kernel/smpboot.c | 18 +++++++----
include/asm-x86_64/smp.h | 2 +
3 files changed, 79 insertions(+), 6 deletions(-)
diff -puN arch/x86_64/kernel/smpboot.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot arch/x86_64/kernel/smpboot.c
--- devel/arch/x86_64/kernel/smpboot.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot 2005-07-28 22:07:55.000000000 -0700
+++ devel-akpm/arch/x86_64/kernel/smpboot.c 2005-07-28 22:07:55.000000000 -0700
@@ -280,7 +280,7 @@ get_delta(long *rt, long *master)
return tcenter - best_tm;
}
-static __cpuinit void sync_tsc(void)
+static __cpuinit void sync_tsc(unsigned int master)
{
int i, done = 0;
long delta, adj, adjust_latency = 0;
@@ -294,9 +294,17 @@ static __cpuinit void sync_tsc(void)
} t[NUM_ROUNDS] __cpuinitdata;
#endif
+ printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n",
+ smp_processor_id(), master);
+
go[MASTER] = 1;
- smp_call_function(sync_master, NULL, 1, 0);
+ /* It is dangerous to broadcast IPI as cpus are coming up,
+ * as they may not be ready to accept them. So since
+ * we only need to send the ipi to the boot cpu direct
+ * the message, and avoid the race.
+ */
+ smp_call_function_single(master, sync_master, NULL, 1, 0);
while (go[MASTER]) /* wait for master to be ready */
no_cpu_relax();
@@ -340,16 +348,14 @@ static __cpuinit void sync_tsc(void)
printk(KERN_INFO
"CPU %d: synchronized TSC with CPU %u (last diff %ld cycles, "
"maxerr %lu cycles)\n",
- smp_processor_id(), boot_cpu_id, delta, rt);
+ smp_processor_id(), master, delta, rt);
}
static void __cpuinit tsc_sync_wait(void)
{
if (notscsync || !cpu_has_tsc)
return;
- printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
- boot_cpu_id);
- sync_tsc();
+ sync_tsc(boot_cpu_id);
}
static __init int notscsync_setup(char *s)
diff -puN arch/x86_64/kernel/smp.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot arch/x86_64/kernel/smp.c
--- devel/arch/x86_64/kernel/smp.c~x86_64-sync_tsc-fix-the-race-so-we-can-boot 2005-07-28 22:07:55.000000000 -0700
+++ devel-akpm/arch/x86_64/kernel/smp.c 2005-07-28 22:07:55.000000000 -0700
@@ -294,6 +294,71 @@ void unlock_ipi_call_lock(void)
}
/*
+ * this function sends a 'generic call function' IPI to one other CPU
+ * in the system.
+ */
+static void __smp_call_function_single (int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
+{
+ struct call_data_struct data;
+ int cpus = 1;
+
+ data.func = func;
+ data.info = info;
+ atomic_set(&data.started, 0);
+ data.wait = wait;
+ if (wait)
+ atomic_set(&data.finished, 0);
+
+ call_data = &data;
+ wmb();
+ /* Send a message to all other CPUs and wait for them to respond */
+ send_IPI_mask(cpumask_of_cpu(cpu), CALL_FUNCTION_VECTOR);
+
+ /* Wait for response */
+ while (atomic_read(&data.started) != cpus)
+ cpu_relax();
+
+ if (!wait)
+ return;
+
+ while (atomic_read(&data.finished) != cpus)
+ cpu_relax();
+}
+
+/*
+ * Run a function on another CPU
+ * <func> The function to run. This must be fast and non-blocking.
+ * <info> An arbitrary pointer to pass to the function.
+ * <nonatomic> Currently unused.
+ * <wait> If true, wait until function has completed on other CPUs.
+ * [RETURNS] 0 on success, else a negative status code.
+ *
+ * Does not return until the remote CPU is nearly ready to execute <func>
+ * or is or has executed.
+ */
+
+int smp_call_function_single (int cpu, void (*func) (void *info), void *info,
+ int nonatomic, int wait)
+{
+
+ int me = get_cpu(); /* prevent preemption and reschedule on another processor */
+
+ if (cpu == me) {
+ printk("%s: trying to call self\n", __func__);
+ put_cpu();
+ return -EBUSY;
+ }
+ spin_lock_bh(&call_lock);
+
+ __smp_call_function_single(cpu, func,info,nonatomic,wait);
+
+ spin_unlock_bh(&call_lock);
+ put_cpu();
+ return 0;
+}
+
+/*
* this function sends a 'generic call function' IPI to all other CPUs
* in the system.
*/
diff -puN include/asm-x86_64/smp.h~x86_64-sync_tsc-fix-the-race-so-we-can-boot include/asm-x86_64/smp.h
--- devel/include/asm-x86_64/smp.h~x86_64-sync_tsc-fix-the-race-so-we-can-boot 2005-07-28 22:07:55.000000000 -0700
+++ devel-akpm/include/asm-x86_64/smp.h 2005-07-28 22:07:55.000000000 -0700
@@ -48,6 +48,8 @@ extern void unlock_ipi_call_lock(void);
extern int smp_num_siblings;
extern void smp_flush_tlb(void);
extern void smp_message_irq(int cpl, void *dev_id, struct pt_regs *regs);
+extern int smp_call_function_single (int cpuid, void (*func) (void *info), void *info,
+ int retry, int wait);
extern void smp_send_reschedule(int cpu);
extern void smp_invalidate_rcv(void); /* Process an NMI */
extern void zap_low_mappings(void);
_
Andrew Morton
> identified earlier with the sched patches ...
>
> http://test.kernel.org/9398/debug/console.log
Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
> Works with mainline still (including -rc4) ... hopefully those patches
> aren't on their way upstream anytime soon ;-)
Well can you identify the offending patch(es)? If so, I'll exterminate them.
Matthias Urlichs
> start a binary search
Note that if you work from my git import, git has a nice tree bisection
option.
That tree may be very helpful if the regression is hidden in one of the
git trees imported into -mm, as it allows you to pinpoint the exact change
-- as opposed to "it happened somewhere in git-large-foobar-update.patch".
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
British education is probably the best in the world, if you can survive
it. If you can't there is nothing left for you but the diplomatic corps.
-- Peter Ustinov
Andrew Morton
>
> Hi, Rafael J. Wysocki wrote:
>
> > start a binary search
>
> Note that if you work from my git import, git has a nice tree bisection
> option.
Is that documented anywhere?
Matthias Urlichs
Andrew Morton:
> Matthias Urlichs <sm...@smurf.noris.de> wrote:
> > Note that if you work from my git import, git has a nice tree bisection
> > option.
>
> Is that documented anywhere?
*checking* Apparently not, not unless you count the git list's archive.
(It's git-rev-list.)
I'll fix that.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The makers may make
and the users may use,
but the fixers must fix
with but minimal clues
Matthias Urlichs
Andrew Morton:
> > Note that if you work from my git import, git has a nice tree bisection
> > option.
>
> Is that documented anywhere?
http://lkml.org/lkml/2005/6/24/234
Basically, you do this:
$ set -o noclobber
$ git-rev-tree --bisect ^good1 ^good2 bad > .git/refs/heads/tryN
$ git checkout tryN
(Initially, "good" is v2.6.12 or whatever version last worked for you;
"bad" is "master", thus:
$ git-rev-tree --bisect ^v2.6.12 master > .git/refs/heads/tryN
)
Build kernel, test. If good, add tryN to the list of good kernels, above;
if bad, replace "bad" with "tryN". N += 1. Repeat.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
IT'S HERE AT LAST: Rush job; nobody knew it was coming
Martin J. Bligh
>> > in 2.6.13. Extra testing, please.
>>
>> Is still regressed as of 2.6.12 for me, at least. Crashes in TSC sync.
>> Talked to Andi about it at OLS, but then drank too much to remember the
>> conclusion ... however, it's still broken ;-)
>>
>> Matrix is here (see left hand column).
>>
>> http://test.kernel.org/
>>
>> Example boot log is here:
>>
>> http://test.kernel.org/9447/debug/console.log
>
> Does Eric's recent fix fix it?
>
>
> From: Eric W. Biederman <ebie...@xmission.com>
>
> sync_tsc was using smp_call_function to ask the boot processor to report
> it's tsc value. smp_call_function performs an IPI_send_allbutself which is
> a broadcast ipi. There is a window during processor startup during which
> the target cpu has started and before it has initialized it's interrupt
> vectors so it can properly process an interrupt. Receveing an interrupt
> during that window will triple fault the cpu and do other nasty things.
Wheeeeeeee! that does indeed seem to work. Nice job.
> I believe this patch suffers from apicid versus logical cpu number
> confusion. I copied the basic logic from smp_send_reschedule and I can't
> find where that translates from the logical cpuid to apicid. So it isn't
> quite correct yet. It should be close enough that it shouldn't be too hard
> to finish it up.
>
> More bug fixes after I have slept but I figured I needed to get this
> one out for review.
Eric, when you have a final version, throw it over to me, and I'll give
that one a spin-test too ...
Thanks!
M.
Eric W. Biederman
>> From: Eric W. Biederman <ebie...@xmission.com>
>>
>> sync_tsc was using smp_call_function to ask the boot processor to report
>> it's tsc value. smp_call_function performs an IPI_send_allbutself which is
>> a broadcast ipi. There is a window during processor startup during which
>> the target cpu has started and before it has initialized it's interrupt
>> vectors so it can properly process an interrupt. Receveing an interrupt
>> during that window will triple fault the cpu and do other nasty things.
>
> Wheeeeeeee! that does indeed seem to work. Nice job.
Welcome. I hadn't how many people were tracking this.
>> I believe this patch suffers from apicid versus logical cpu number
>> confusion. I copied the basic logic from smp_send_reschedule and I can't
>> find where that translates from the logical cpuid to apicid. So it isn't
>> quite correct yet. It should be close enough that it shouldn't be too hard
>> to finish it up.
>>
>> More bug fixes after I have slept but I figured I needed to get this
>> one out for review.
>
> Eric, when you have a final version, throw it over to me, and I'll give
> that one a spin-test too ...
With respect to the fix that is final. The rest of the bug
fixes in my queue are for other problems.
Mostly my concerns are with respect to apicid vs logical cpu
numbers that I'm not certain are handled properly in the code.
genapic_flat doesn't seem to do any translation. And I don't
recall if boot_cpu_id is an apic_id or a logical cpu number.
On most hardware it is 0 in either case so it doesn't matter.
Eric
Andrew Morton
>
> Andrew Morton schrieb:
> > Michael Thonke <iogl...@gmail.com> wrote:
> >> here again I have two problems. With 2.6.13-rc3-mm3 I have problems
> >> using my SATA drives on Intel ICH6.
> >> The kernel can't route there IRQs or can't discover them. the option
> >> irqpoll got them to work now.
> >> The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems.
> >
> > OK. Please generate the full dmesg output for -mm2 and for -mm3 and run
> > `diff -u dmesg.mm2 dmesg.mm3' and send it? And keep those files because we
> > may end up needing to add them to an acpi bugzilla entry ;)
>
> 2.6.13-rc3-mm1 but this dmesg output I have.
>
> Well as I save mm[2,3] are unable to setup the correct IRQs for the
> devices..and please note that 2.6.13-rc3-mm3 only booted with irqpoll so
> its in the dmesg output "dmesg.mm3"
> Normaly the IRQ routed to something about 1xx now they are 1-21?! Caused
> by irqpoll?
>
Are these problems only present in -mm kernels? Does 2.6.13-rc4 work OK?
> > Odd trace. Do you have CONFIG_KALLSYMS enabled? If not, please turn it on.
>
> Mh I tried but my system freezes on boot then. And screen leaves blank.
> >
Oh geeze.
@@ -53,10 +23,18 @@
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
+ ACPI-0287: *** Error: Region SystemMemory(0) has no handler
+ ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: AE_NOT_EXIST
+ ACPI-0136: *** Error: acpi_load_tables: Could not load tables: AE_NOT_EXIST
+ACPI: Unable to load the System Description Tables
ENABLING IO-APIC IRQs
-..TIMER: vector=0x31 pin1=2 pin2=0
+..TIMER: vector=0x31 pin1=2 pin2=-1
NET: Registered protocol family 16
PCI: Using configuration type 1
+ACPI: Subsystem revision 20050708
+ACPI: Interpreter disabled.
Well it looks like ACPI committed suicide, so there's probably not much
point looking at the other things until that gets addressed.
Would you have time to raise a kernel bugzilla entry for this? Raise it
against the ACPI AML interpreter, version 20050708 and mention the above
failure. The output of acpidump (from
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050727.tar.gz)
will probably be asked for.
Thanks.
Moore, Robert
+ ACPI-0127: *** Error: acpi_load_tables: Could not load namespace:
AE_NOT_EXIST
+ ACPI-0136: *** Error: acpi_load_tables: Could not load tables:
This looks like a nasty case where some executable code in the table is
attempting to access a SystemMemory operation region before any OpRegion
handlers are initialized.
We certainly want to see the output of acpidump to attempt to diagnose
and/or reproduce the problem.
Bob
Michael Thonke
>Michael Thonke <tk-sho...@web.de> wrote:
>
>
>>Andrew Morton schrieb:
>>
>>
>>>Michael Thonke <iogl...@gmail.com> wrote:
>>>
>>>
>>>>here again I have two problems. With 2.6.13-rc3-mm3 I have problems
>>>> using my SATA drives on Intel ICH6.
>>>> The kernel can't route there IRQs or can't discover them. the option
>>>> irqpoll got them to work now.
>>>> The problem is new because 2.6.13-rc3[-mm1,mm2] work without any problems.
>>>>
>>>>
>>>OK. Please generate the full dmesg output for -mm2 and for -mm3 and run
>>>`diff -u dmesg.mm2 dmesg.mm3' and send it? And keep those files because we
>>>may end up needing to add them to an acpi bugzilla entry ;)
>>>
>>>
>>Well I did a little mistake..it only worked correctly up to
>>2.6.13-rc3-mm1 but this dmesg output I have.
>>
>>Well as I save mm[2,3] are unable to setup the correct IRQs for the
>>devices..and please note that 2.6.13-rc3-mm3 only booted with irqpoll so
>>its in the dmesg output "dmesg.mm3"
>>Normaly the IRQ routed to something about 1xx now they are 1-21?! Caused
>>by irqpoll?
>>
>>
>>
>
>Are these problems only present in -mm kernels? Does 2.6.13-rc4 work OK?
>
>
I'm sorry to say that, Yes.
I finially compiled a fresh 2.6.13-rc4-git1 kernel with ck-patch and
Gregh-kh patches.
With this kernel non of the problems I had with mm-kernel are present.
Here is everthing just perfect..now
I attached a dmesg output for review :-)
The Oops on probing snd-hda-intel gone. It works now ... Mozart rocks :-)
I look at the CVS tree of Alsa later.
I finialy converted my reiser4 root to reiser 3.6.
Where I can get acpidumb or what it is called?
>
>
>>>Odd trace. Do you have CONFIG_KALLSYMS enabled? If not, please turn it on.
>>>
>>>
Okay, i will do so ... what else we need to back that out.
>>Mh I tried but my system freezes on boot then. And screen leaves blank.
>>
>>
>
>Oh geeze.
>
>
Like oh my god? ;-)
>@@ -53,10 +23,18 @@
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Checking 'hlt' instruction... OK.
>+ ACPI-0287: *** Error: Region SystemMemory(0) has no handler
>+ ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: AE_NOT_EXIST
>+ ACPI-0136: *** Error: acpi_load_tables: Could not load tables: AE_NOT_EXIST
>+ACPI: Unable to load the System Description Tables
> ENABLING IO-APIC IRQs
>-..TIMER: vector=0x31 pin1=2 pin2=0
>+..TIMER: vector=0x31 pin1=2 pin2=-1
>
>
The pin2=-1 is wrong I think, right?
> NET: Registered protocol family 16
> PCI: Using configuration type 1
>+ACPI: Subsystem revision 20050708
>+ACPI: Interpreter disabled.
>
>Well it looks like ACPI committed suicide, so there's probably not much
>point looking at the other things until that gets addressed.
>
>Would you have time to raise a kernel bugzilla entry for this? Raise it
>against the ACPI AML interpreter, version 20050708 and mention the above
>failure. The output of acpidump (from
>ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050727.tar.gz)
>will probably be asked for.
>
>Thanks.
>
>
>
Sorry for my different mail accounts, gmail have some problems.
Let me say, Thanks again for the help Andrew and all others.
Khalid Aziz
2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
output ever appears on the console and system is hung. So I booted the
kernel with "console=uart,mmio,0xff5e0000" to enable early console and
here is how far the kernel got before hanging:
-------
Linux version 2.6.13-rc3-mm3 (root@mars) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #4 SMP Fri Jul 29 16:30:41 MDT 2005
EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000
booting generic kernel on platform hpzx1
PCDP: v0 at 0x3fb2c000
Explicit "console="; ignoring PCDP
Early serial console at MMIO 0xff5e0000 (options '115200')
efi.trim_top: ignoring 4KB of memory at 0x0 due to granule hole at 0x0
efi.trim_top: ignoring 636KB of memory at 0x1000 due to granule hole at 0x0
efi.trim_bottom: ignoring 15360KB of memory at 0x100000 due to granule hole at 0x0
SAL 3.1: HP version 2.31
SAL Platform features: None
SAL: AP wakeup using external interrupt vector 0xff
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
GSI 36 (level, low) -> CPU 0 (0x0000) vector 48
2 CPUs available, 2 CPUs total
MCA related initialization done
Virtual mem_map starts at 0xa0007fffc7200000
Built 1 zonelists
Kernel command line: BOOT_IMAGE=scsi1:/EFI/debian/boot/vmlinuz-2.6.13-rc3-mm3 root=/dev/sdb2 console=uart,mmio,0xff5e0000 ro
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour VGA+ 80x25
Memory: 12439136k/12542128k available (7051k code, 116240k reserved, 3406k data, 352k init)
Leaving McKinley Errata 9 workaround enabled
Dentry cache hash table entries: 2097152 (order: 10, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 9, 8388608 bytes)
Mount-cache hash table entries: 1024
Boot processor id 0x0/0x0
CPU 1: synchronized ITC with CPU 0 (last diff -5 cycles, maxerr 433 cycles)
Brought up 2 CPUs
Total of 2 processors activated (2695.16 BogoMIPS).
-> [0][1][ 786432] 0.5 [ 0.5] (0): ( 500513 250256)
-> [0][1][ 827823] 0.5 [ 0.5] (0): ( 529015 139379)
-> [0][1][ 871392] 0.5 [ 0.5] (0): ( 557119 83741)
-> [0][1][ 917254] 0.5 [ 0.5] (0): ( 585481 56051)
-> [0][1][ 965530] 0.6 [ 0.6] (0): ( 615654 43112)
-> [0][1][1016347] 0.6 [ 0.6] (0): ( 653296 40377)
-> [0][1][1069838] 0.6 [ 0.6] (0): ( 681359 34220)
-> [0][1][1126145] 0.7 [ 0.7] (0): ( 706209 29535)
-> [0][1][1185415] 0.7 [ 0.7] (0): ( 754788 39057)
-> [0][1][1247805] 0.7 [ 0.7] (0): ( 788675 36472)
-> [0][1][1313478] 0.8 [ 0.8] (0): ( 840102 43949)
-> [0][1][1382608] 0.7 [ 0.8] (0): ( 742042 71004)
-> [0][1][1455376] 0.6 [ 0.8] (0): ( 653934 79556)
-> [0][1][1531974] 0.7 [ 0.8] (0): ( 766991 96306)
-> [0][1][1612604] 0.7 [ 0.8] (0): ( 779253 54284)
-> [0][1][1697477] 0.5 [ 0.8] (0): ( 534912 149312)
-> [0][1][1786817] 0.5 [ 0.8] (0): ( 503106 90559)
-> found max.
[0][1] working set size found: 1313478, cost: 840102
---------------------
| migration cost matrix (max_cache_size: 1572864, cpu: -1 MHz):
---------------------
[00] [01]
[00]: - 1.6(0)
[01]: 1.6(0) -
--------------------------------
| cacheflush times [1]: 1.6 (1680204)
| calibration delay: 1 seconds
--------------------------------
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Subsystem revision 20050708
ACPI-0509: *** Error: Method execution failed [\PARS.GFIT] (Node e0000002ffff8a00), AE_BAD_PARAMETER
ACPI-0509: *** Error: Method execution failed [\_SB_.SBA0._INI] (Node e0000002ffffa780), AE_BAD_PARAMETER
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
SCSI subsystem initialized
perfmon: version 2.0 IRQ 238
perfmon: Itanium 2 PMU detected, 16 PMCs, 18 PMDs, 4 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
Total HugeTLB memory allocated, 0
SGI XFS with large block/inode numbers, no debug enabled
Initializing Cryptographic API
EFI Time Services Driver v0.4
i8042.c: No controller found.
Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
mice: PS/2 mouse device common for all mice
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Intel(R) PRO/1000 Network Driver - version 6.0.60-k2
Copyright (c) 1999-2005 Intel Corporation.
e100: Intel(R) PRO/100 Network Driver, 3.4.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
ide-floppy driver 0.99.newide
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
EFI Variables Facility v0.08 2004-May-17
NET: Registered protocol family 2
IP route cache hash table entries: 2097152 (order: 10, 16777216 bytes)
TCP established hash table entries: 8388608 (order: 13, 134217728 bytes)
TCP bind hash table entries: 65536 (order: 6, 1048576 bytes)
TCP: Hash tables configured (established 8388608 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
No ttyS device at MMIO 0xff5e0000 for console
-------
Serial driver failed to find any serial ports. I am using defconfig. A
2.6.13-rc3 kernel (no mm3 patch) compiled with defconfig boots up fine
and finds all serial ports.
--
Khalid
On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
>
> - Added the anonymous pagefault scalability enhancement patches.
>
> I remain fairly dubious about this - it seems a fairly specific and
> complex piece of work to speed up one extremely specific part of one type of
> computer's one type of workload. Surely there's a better way :(
>
> The patches at present spit warnings or don't compile on lots of
> architectures. x86, x86_64, ppc64 and ia64 are OK.
>
> - There's a pretty large x86_64 update here which naughty maintainer wants
> in 2.6.13. Extra testing, please.
>
> - Dropped git-net.patch (davem's net devel tree). I'm seeing weird TCP
> hangs. I'm fairly sure they're present in mainline, but was unable to
> reproduce it without git-net.patch when I was actually trying.
>
>
>
> Changes since 2.6.13-rc3-mm2:
>
>
> linus.patch
> git-acpi.patch
> git-cryptodev.patch
> git-drm.patch
> git-audit.patch
> git-input.patch
> git-kbuild.patch
> git-libata-adma-mwi.patch
> git-libata-chs-support.patch
> git-libata-passthru.patch
> git-libata-promise-sata-pata.patch
> git-netdev-chelsio.patch
> git-netdev-e100.patch
> git-netdev-smc91x-eeprom.patch
> git-netdev-ieee80211-wifi.patch
> git-ocfs2.patch
> git-serial.patch
> git-scsi-block.patch
> git-scsi-misc-drivers-scsi-chc-remove-devfs-stuff.patch
>
> Subsystem trees
>
> -i2c-mpc-restore-code-removed.patch
> -really-__nocast-annotate-kmalloc_node.patch
> -mips-fbdev-kconfig-fix.patch
> -md-when-resizing-an-array-we-need-to-update-resync_max_sectors-as-well-as-size.patch
> -uml-readd-missing-define-to-arch-um-makefile-i386.patch
> -uml-add-dependency-to-arch-um-makefile-for-parallel-builds.patch
> -uml-add-skas0-command-line-option.patch
> -uml-update-module-interface.patch
> -uml-fix-misdeclared-function.patch
> -x86_64-fix-smp-boot-lockup-on-some-machines.patch
> -try_to_freeze-call-fixes.patch
> -add-missing-tvaudio-try_to_freeze.patch
> -fix-missing-refrigerator-invocation-in-jffs2.patch
> -as-ioched-tunable-encoding-fix.patch
> -reiserfs-fix-deadlock-in-inode-creation-failure-path-w-default-acl.patch
> -ext2-drop-quota-reference-before-releasing-inode.patch
> -ext3-drop-quota-references-before-releasing-inode.patch
> -pnp-build-fix.patch
> -address-bug-using-smp_processor_id-in-preemptible.patch
> -watchdog-add-missing-0x-in-alim1535_wdtc.patch
> -itimer-fixes.patch
> -add-pcibios_bus_to_resource-for-parisc.patch
> -autofs4-fix-infamous-busy-inodes-after-umount-message.patch
> -scsi_scan-check-return-code-from-scsi_sysfs_add_sdev.patch
> -i4l-add-olitec-isdn-pci-card-in-hisax-gazel-driver.patch
> -jsm-use-dynamic-major-number-allocation.patch
> -jsm-warning-fixes.patch
> -undo-mempolicy-shared-policy-rbtree-microoptimization.patch
> -ub-fix-for-blank-cds.patch
> -fix-xip-sparse-file-handling-in-ext2.patch
> -check_user_page_readable-deadlock-fix.patch
> -mpt-fusion-free-irq-in-suspend.patch
> -eurotechwdt-build-fix.patch
> -softdog-build-fix.patch
> -x86_64-fsnotify-build-fix.patch
> -fix-warning-in-powernow-k8c.patch
> -speakup-build-fix.patch
> -drm-via-fix-sparse-warnings.patch
> -netfilter-build-fix.patch
> -ipv6_netfilter_init-warning-fix.patch
> -consolidate-config_watchdog_nowayout-handling.patch
> -madvise-does-not-always-return-ebadf-on-non-file.patch
> -remove-bogus-warning-in-page_allocc.patch
> -ppc-ppc64-use-kconfighz.patch
> -ppc32-update-defconfigs.patch
> -ppc32-add-proper-prototype-for-cpm2_reset.patch
> -ppc32-make-the-uarts-on-mpc824x-individual-platform-devices.patch
> -ppc32-8xx-update-datatlbmiss-exception-comment.patch
> -ppc-fix-compilation-error-with-config_pq2fads.patch
> -ppc32-fix-typo-in-setup-of-2nd-pci-bus-on-85xx.patch
> -ppc32-fix-building-of-prpmc750.patch
> -ppc32-fix-building-of-radstone_ppc7d.patch
> -ppc32-fix-dma_map_page-to-use-page_to_bus.patch
> -ppc32-fix-440sp-mal-channels-count.patch
> -ppc32-fix-building-of-tqm8260-board.patch
> -ppc64-update-defconfigs.patch
> -ppc64-hide-config_adb.patch
> -ppc64-genrtc-build-fix.patch
> -make-a-few-functions-static-in-pmac_setupc.patch
> -ppc64-dynamically-allocate-segment-tables.patch
> -ppc64-remove-another-fixed-address-constraint.patch
> -mips-remove-obsolete-giu-driver-for-vr41xx.patch
> -i386-add-missing-kconfig-help-text.patch
> -m32r-add-missing-kconfig-help-text.patch
> -cris-update-1-17-arch-split.patch
> -cris-update-2-17-configuration-and-build.patch
> -cris-update-3-17-console.patch
> -cris-update-4-17-debug.patch
> -cris-update-5-17-drivers.patch
> -cris-update-6-17-i-o-and-dma-allocator.patch
> -cris-update-7-17-irq.patch
> -cris-update-8-17-misc-patches.patch
> -cris-update-9-17-mm.patch
> -cris-update-10-17-pci.patch
> -cris-update-11-17-profiler.patch
> -cris-update-12-17-serial-port-driver.patch # rmk said no
> -cris-update-13-17-smp.patch
> -cris-update-14-17-synchronous-serial-port-driver.patch
> -cris-update-15-17-updates-for-2612.patch
> -cris-update-17-17-new-subarchitecture-v32.patch
> -cris-update-17-17-new-subarchitecture-v32-swapped-kmalloc-args.patch
> -cris-ide-driver.patch
> -v850-define-pfn_valid.patch
> -v850-const-qualify-first-parameter-of-find_next_zero_bit.patch
> -v850-add-defconfigs.patch
> -v850-update-ioremap-return-type-and-add-ioread-iowrite-functions.patch
> -v850-add-pte_file.patch
> -v850-update-pci-support.patch
> -v850-define-l1_cache_shift-and-l1_cache_shift_max.patch
> -s390-spin-lock-retry.patch
> -s390-find_next_zero_bit-fixes.patch
> -s390-atomic64-inline-functions.patch
> -s390-external-call-performance.patch
> -s390-debug-data-for-ifcc-ccc.patch
> -s390-resource-accessibility-event-handling.patch
> -s390-fba-dasd-i-o-errors.patch
> -s390-free-dasd-slab-cache.patch
> -s390-channel-tape-fixes.patch
> -s390-31-bit-memory-size-limit.patch
> -s390-cpu-timer-reset-in-machine-check-handler.patch
> -s390-use-__cpcmd-in-vmcp_write.patch
> -fortuna-random-driver-fix.patch
> -stale-posix-lock-handling.patch
> -cciss-per-disk-queue.patch
> -kernel-capabilityc-add-kerneldoc.patch
> -kernel-cpusetc-add-kerneldoc-fix-typos.patch
> -kernel-crash_dumpc-add-kerneldoc.patch
> -tpm-support-for-infineon-tpm.patch
> -ppc64-tpm_infineon-build-fix.patch
> -mbcache-remove-unused-mb_cache_shrink-parameter.patch
> -documentation-changes-document-the-required-udev-version.patch
> -reiserfs-doesnt-use-mbcache.patch
> -ia64-halt-hangup-fix.patch
> -turn-many-if-undefined_string-into-ifdef-undefined_string.patch
> -riva-wundef-fix.patch
> -sys_get_thread_area-does-not-clear-the-returned-argument.patch
> -serial_core-whitespace-fix.patch
> -add-text-for-dealing-with-dot-releases-to-readme.patch
> -ib-update-fmr-functions.patch
> -ib-update-mad-client-api.patch
> -ib-add-mad-helper-functions.patch
> -ib-combine-some-mad-routines.patch
> -ib-change-saving-of-users-send-wr_id-in-mad.patch
> -ib-change-ib_mad_send_wr_private-struct.patch
> -ib-fix-timeout-cancelled-mad-handling.patch
> -ib-minor-cleanup-during-mad-startup-and-shutdown.patch
> -ib-add-ib_coalesce_recv_mad-to-mad.patch
> -ib-add-automatic-retries-to-mad-layer.patch
> -ib-simplify-calling-of-list_del-in-mad.patch
> -ib-eliminate-mad-cache-leak-associated-with-local.patch
> -ib-add-ib_modify_mad-api-to-mad.patch
> -ib-optimize-canceling-a-mad.patch
> -ib-fix-a-couple-of-mad-code-paths.patch
> -ib-add-ib_create_ah_from_wc-to-ib-verbs.patch
> -ib-a-couple-of-ib-core-bug-fixes.patch
> -ib-introduce-rmpp-apis.patch
> -ib-add-rmpp-implementation.patch
> -ib-add-service-record-support-to-sa-client.patch
> -ib-add-the-header-file-for-kernel-cm-communications.patch
> -ib-add-the-kernel-cm-implementation.patch
> -ib-user-mad-abi-changes-to-support-rmpp.patch
> -ib-implementation-for-rmpp-support-in-user-mad.patch
> -ib-add-the-header-file-for-user-space-cm.patch
> -ib-add-kernel-portion-of-user-cm-implementation.patch
> -ib-add-kernel-portion-of-user-cm-implementation-fix.patch
> -ib-hook-up-userspace-cm-to-the-make-system.patch
> -ib-eliminate-sparse-warnings-in-sa-client.patch
> -ib-add-core-locking-documentation-to-infiniband.patch
> -dvico-fusion-dvb-t1-tuner-lg-z201-fix.patch
> -drivers-media-video-tveepromc-possible-cleanups.patch
> -video_saa7134-must-depend-on-sound.patch
> -v4l-fix-regression-modprobe-bttv-freezes-the-computer.patch
> -dvb-v4l-lgdt3302-isolate-tuner.patch
> -dvb-v4l-rf-input-selection-fix.patch
> -lgdt3302-warning-fix.patch
> -dvb-v4l-cx88-cleanup.patch
> -v4l-hybrid-dvb-fix-warnings-with-wundef.patch
> -v4l-hybrid-dvb-move-defines-to-makefile.patch
> -v4l-hybrid-dvb-rename-cflags-from-config_dvb_xxxx-back.patch
> -v4l-fix-tuning-with-mxb-driver.patch
> -dvb-rename-lgdt3302-frontend-module-to-lgdt330x.patch
> -serial-mri-mri-pcids1-dual-port-serial-card.patch
> -clean-up-the-old-digi-support-and-rescue-it.patch
> -cpm_uart-use-dpram-for-early-console.patch
> -fbmon-horizontal-frequency-rounding-fix.patch
> -fbmem-use-unregister_chrdev-on-unload.patch
> -radeonfb-clean-up-edid-sysfs-attribute.patch
> -fbdev-colormap-fixes.patch
> -dont-repaint-the-cursor-when-it-is-disabled.patch
> -fbdev-update-info-cmap-when-setting-cmap-from-user-kernelspace.patch
> -clean-up-inline-static-vs-static-inline.patch
> -update-credits-entry-and-listings-in-source-files-for-jesper.patch
>
> Merged
>
> +bio_clone-fix.patch
>
> Fix BIO cloning bug - might be the cause of data corruption on some MD
> setups.
>
> +x86_64-always-ack-ipis-even-on-errors.patch
> +x86_64-update-defconfig.patch
> +x86_64-use-for_each_cpu_mask-for-clustered-ipi-flush.patch
> +x86_64-i386-x86_64-remove-prototypes-for-not-existing.patch
> +x86_64-move-cpu_present-possible_map-parsing-earlier.patch
> +x86_64-minor-clean-up-to-cpu-setup-use-smp_processor_id-instead-of-custom-hack.patch
> +x86_64-clarify-booting-processor-message.patch
> +x86_64-some-cleanup-in-setup64c.patch
> +x86_64-remove-unused-variable-in-delayc.patch
> +x86_64-improve-config_gart_iommu-description-and-make-it-default-y.patch
> +x86_64-some-updates-for-boot-optionstxt.patch
> +x86_64-fix-some-comments-in-tlbflushh.patch
> +x86_64-remove-obsolete-eat_key-prototype.patch
> +x86_64-fix-some-typos-in-systemh-comments.patch
> +x86_64-fix-incorrectly-defined-msr_k8_syscfg.patch
> +x86_64-fix-overflow-in-numa-hash-function-setup.patch
> +x86_64-print-a-boot-message-for-hotplug-memory-zones.patch
> +x86_64-create-per-cpu-machine-check-sysfs-directories.patch
> +x86_64-remove-ia32_-build-tools-in-makefile.patch
> +x86_64-remove-the-broadcast-options-that-were-added-for.patch
> +x86_64-support-more-than-8-cores-on-amd-systems.patch
> +x86_64-icecream-has-no-way-of-detecting-assembler-level.patch
> +x86_64-turn-bug-data-into-valid-instruction.patch
> +x86_64-when-running-cpuid4-need-to-run-on-the-correct.patch
> +x86_64-remove-unnecessary-include-in-faultc.patch
> +x86_64-small-assembly-improvements.patch
> +x86_64-switch-to-the-interrupt-stack-when-running-a.patch
> +x86_64-fix-srat-handling-on-non-dual-core-systems.patch
> +x86_64-fix-gcc-4-warning-in-sched_find_first_bit.patch
> +x86_64-use-msleep-in-smpbootc.patch
> +x86_64-remove-unused-variable-in-k8-busc.patch
> +x86_64-fix-cpu_to_node-setup-for-sparse-apic_ids.patch
>
> x86_64 update
>
> +cs89x0-collect-tx_bytes-statistics.patch
>
> net driver stats fix
>
> +ppc32-inotify-syscalls.patch
> +ppc64-inotify-syscalls.patch
>
> ppc32/ppc64 syscall table updates
>
> +selinux-default-labeling-of-mls-field.patch
>
> SELinux multilevel security feature work
>
> +pcdp-if-pcdp-contains-parity-information-use-it.patch
>
> pcdp driver fix
>
> +qla2xxx-mark-dependency-on-fw_loader.patch
>
> qlogic Kconfig fix
>
> +alpha-fix-statement-with-no-effect-warnings.patch
>
> Alpha warning fixes
>
> +mm-ensure-proper-alignment-for-node_remap_start_pfn.patch
>
> memory management initialisation fix
>
> -move-truncate_inode_pages-into-delete_inode.patch
>
> This is in git-ocfs2.patch
>
> +mpt-fusion-free-irq-in-suspend.patch
>
> mpt-fusion power management fix
>
> +gregkh-driver-stable_api_nonsense.txt-fixes.patch
> +gregkh-driver-speakup-kconfig-fix.patch
> +gregkh-driver-speakup-kconfig-fix-2.patch
> +gregkh-driver-speakup-build-fix.patch
>
> Greg's driver core tree
>
> +drivers-char-drm-drm_pcic-fix-warnings.patch
>
> Warning fixes
>
> +gregkh-i2c-w1-netlink-callbacks.patch
>
> Greg's i2c tree
>
> +git-net-gregkh-i2c-w1-netlink-callbacks-fix.patch
>
> Fix incompatibility between git-net and Greg's i2c tree
>
> +include-net-ieee80211h-must-include-linux-wirelessh.patch
>
> net build fix
>
> +gregkh-pci-pci-restore-bar-values.patch
>
> Greg's PCI tree
>
> -revert-gregkh-pci-pci-assign-unassigned-resources.patch
>
> Hopefully no longer needed
>
> +mpt-fusion-dv-fixes.patch
>
> Try to fix some mpt-fusion domain validation problems (doesn't seem to work)
>
> +gregkh-usb-usb-ftdi_sio-new-devices.patch
> +gregkh-usb-usb-ftdi_sio-rts-dtr.patch
> +gregkh-usb-usb-ftdi_sio-timeout-fix.patch
> +gregkh-usb-usb-usbfs-dont-leak-data.patch
> +gregkh-usb-usb-usbnet-remove-unused-vars.patch
> +gregkh-usb-usb-dont-delete-unregistered-interfaces.patch
> +gregkh-usb-usb-usbserial-remove-unneeded-casts.patch
>
> Greg's USB tree
>
> -proc-pid-numa_maps-to-show-on-which-nodes-pages-reside-tidy.patch
>
> Folded into proc-pid-numa_maps-to-show-on-which-nodes-pages-reside.patch
>
> +vm-add-capabilites-check-to-set_zone_reclaim.patch
>
> Make sys_set_zone_reclaim() privileged
>
> +page-fault-patches-introduce-pte_xchg-and-pte_cmpxchg.patch
> +page-fault-patches-introduce-pte_xchg-and-pte_cmpxchg-fix.patch
> +page-fault-patches-optional-page_lock-acquisition-in.patch
> +page-fault-patches-optional-page_lock-acquisition-in-tidy.patch
> +page-fault-patches-no-pagetable-lock-in-do_anon_page.patch
>
> anonymous pagefault scalability enhancements.
>
> -net-add-driver-for-the-nic-on-cell-blades-kconfig-fix.patch
>
> Folded into net-add-driver-for-the-nic-on-cell-blades.patch
>
> -sk98lin-basic-suspend-resume-support-fix.patch
>
> Folded into sk98lin-basic-suspend-resume-support.patch
>
> +ppc32-mark-boards-that-dont-build-as-broken.patch
> +ppc32-add-440ep-support.patch
> +ppc32-add-bamboo-platform.patch
> +ppc32-add-bamboo-defconfig.patch
> +ppc32-remove-board-support-for-adir.patch
> +ppc32-remove-board-support-for-ash.patch
> +ppc32-remove-board-support-for-beech.patch
> +ppc32-remove-defconfig-for-cedar.patch
> +ppc32-remove-board-support-for-k2.patch
> +ppc32-remove-board-support-for-mcpn765.patch
> +ppc32-remove-board-support-for-menf1.patch
> +ppc32-remove-board-support-for-oak.patch
> +ppc32-remove-board-support-for-rainier.patch
> +ppc32-remove-board-support-for-redwood.patch
> +ppc32-remove-board-support-for-sm850.patch
> +ppc32-remove-board-support-for-spd823ts.patch
> +ppc32-remove-board-support-for-ep405.patch
> +ppc32-remove-board-support-for-pcore.patch
>
> ppc32 work
>
> +ppc64-remove-nested-feature-sections.patch
>
> ppc64 cleanup
>
> +ptrace-i386-fix-syscall-audit-interaction-with-singlestep.patch
> +uml-support-ptrace-adds-the-host-sysemu-support-for-uml-and-general-usage.patch
> +uml-support-reorganize-ptrace_sysemu-support.patch
> +uml-support-add-ptrace_sysemu_singlestep-option-to-i386.patch
> +sysemu-fix-sysaudit--singlestep-interaction.patch
>
> UML feature work
>
> -areca-raid-linux-scsi-driver-fix.patch
>
> Folded into areca-raid-linux-scsi-driver.patch (will be dropped from next -mm)
>
> -relayfs-cancel-work-on-close-reset.patch
> -relayfs-add-private-data-to-channel-struct.patch
> -relayfs-function-docfix.patch
> -relayfs-add-relayfs-website-to-documentation.patch
> -avoid-lookup_hash-usage-in-relayfs.patch
>
> Folded into relayfs.patch
>
> -add-skip_hangcheck_timer.patch
>
> Dropped, but will come back.
>
> -yealink-updates.patch
> -yealink-updates-0701.patch
>
> Folded into new-driver-for-yealink-usb-p1k-phone.patch
>
> +support-powering-sharp-zaurus-sl-5500-lcd-up-and-down.patch
>
> Make Pavel's Zausus happier
>
> +radix_tag_get-differentiate-between-no-present-node-and-tag-unset-cases.patch
> +radix_tag_get-differentiate-between-no-present-node-and-tag-unset-cases-fix.patch
>
> radix_tree_tag_get() API enhancement.
>
> +aio-fix-races-in-callback-path.patch
>
> AIO race fix
>
> +auxiliary-vector-cleanups.patch
>
> SHuffle the AT_* auxiliary vector defines around
>
> +pnp-consolidate-kmalloc-wrappers.patch
>
> PNP cleanup
>
> -fix-race-in-do_get_write_access-warning-fix.patch
>
> Folded into fix-race-in-do_get_write_access.patch
>
> -kprobes-prevent-possible-race-conditions-generic-fixes.patch
>
> Folded into kprobes-prevent-possible-race-conditions-generic.patch
>
> -kprobes-prevent-possible-race-conditions-ia64-changes-fixes.patch
>
> Folded into kprobes-prevent-possible-race-conditions-ia64-changes.patch
>
> -connector-exit-notifier-fix.patch
> -connector-exit-notifier-remove-the-union-declaration.patch
> -connector-exit-notifier-fix-missing-dependencies-in.patch
>
> Folded into connector-exit-notifier.patch
>
> -connector-add-a-fork-connector-use-after-free-fix.patch
> -connector-add-a-fork-connector-remove-the-union-declaration-fork.patch
> -connector-fork-notifier-fix-missing-dependencies-in.patch
>
> Folded into connector-add-a-fork-connector.patch
>
> -jbd-split-checkpoint-lists-tweaks.patch
>
> Folded into jbd-split-checkpoint-lists.patch
>
> -spinlock-consolidation-m32r-fix.patch
> -spinlock-consolidation-up-spinlocks-gcc-29x-fix.patch
> -page_uptodate-locking-scalability-fix.patch
> -spinlock-consolidation-s390-fix.patch
>
> Folded into spinlock-consolidation.patch
>
> -revert-fix-broken-kmalloc_node-in-rc1-rc2.patch
> -numa-aware-slab-allocator-v5-fix.patch
> -numa-slab-allocator-cleanups.patch
>
> Folded into numa-aware-slab-allocator-v5.patch
>
> -iteraid-remove-ite_ioc_get_driver_version.patch
>
> Folded into iteraid.patch (will be dropped from next -mm)
>
> -page-owner-tracking-leak-detector-tidy.patch
>
> Folded into page-owner-tracking-leak-detector.patch
>
> -perfctr-handle-non-of-ppc32-platforms.patch
> -perfctr-syscall-numbering-fixups.patch
>
> Folded into perfctr.patch
>
> +split-general-cache-manager-from-cachefs-fs-fscache-cleanups.patch
>
> clean up split-general-cache-manager-from-cachefs.patch
>
> -files-break-up-files-struct-warning-fix.patch
>
> Folded into files-break-up-files-struct.patch
>
> -asfs-filesystem-driver-fixes.patch
>
> Folded into asfs-filesystem-driver.patch
>
> -v9fs-documentation-makefiles-configuration-resend-take-2.patch
>
> Folded into v9fs-documentation-makefiles-configuration.patch
>
> -v9fs-vfs-file-dentry-and-directory-operations-fix-fsf-postal-address-in-source-headers.patch
> -v9fs-vfs-file-dentry-and-directory-operations-resend-take-2.patch
>
> Folded into v9fs-vfs-file-dentry-and-directory-operations.patch
>
> -v9fs-vfs-inode-operations-fix-fsf-postal-address-in-source-headers.patch
> -v9fs-vfs-inode-operations-resend-take-2.patch
>
> Folded into v9fs-vfs-inode-operations.patch
>
> -v9fs-vfs-superblock-operations-and-glue-fix-fsf-postal-address-in-source-headers.patch
> -v9fs-vfs-superblock-operations-and-glue-resend-take-2.patch
> -v9fs-vfs-superblock-operations-and-glue-replace-v9fs_block_bits-with-fls.patch
>
> Folded into v9fs-vfs-superblock-operations-and-glue.patch
>
> -v9fs-9p-protocol-implementation-fix-fsf-postal-address-in-source-headers.patch
> -v9fs-9p-protocol-implementation-resend-take-2.patch
>
> Folded into v9fs-9p-protocol-implementation.patch
>
> -v9fs-transport-modules-fix-fsf-postal-address-in-source-headers.patch
> -v9fs-transport-modules-fix-timeout-segfault-corner-case.patch
> -v9fs-transport-modules-resend-take-2.patch
>
> Folded into v9fs-transport-modules.patch
>
> -v9fs-debug-and-support-routines-fix.patch
> -v9fs-debug-and-support-routines-fix-fsf-postal-address-in-source-headers.patch
> -v9fs-debug-and-support-routines-resend-take-2.patch
>
> Folded into v9fs-debug-and-support-routines.patch
>
> -v9fs-clean-up-vfs_inode-and-setattr-functions-2.patch
>
> Folded into v9fs-clean-up-vfs_inode-and-setattr-functions.patch
>
> +serial-add-mmio-support-to-8250_pnp.patch
>
> Add MMIO support to the UART driver
>
> -device-mapper-fix-deadlocks-in-core-prep-fix.patch
>
> Folded into device-mapper-fix-deadlocks-in-core-prep.patch
>
> -timer-initialization-cleanup-define_timer-pluto-fix.patch
>
> Folded into timer-initialization-cleanup-define_timer.patch
>
>
>
> All 633 patches:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/patch-list
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
====================================================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khali...@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
Andrew Morton
>
> Serial console is broken on ia64 on an HP rx2600 machine on
> 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> output ever appears on the console and system is hung. So I booted the
> kernel with "console=uart,mmio,0xff5e0000" to enable early console and
> here is how far the kernel got before hanging:
(cc the ia64 and acpi lists)
OK, thanks. There have been a few serial driver changes recently, but
there's also a tremendous ACPI patch in -mm. I'm wondering about those
ACPI error messages:
Does the above happen on 2.6.13-rc3 or 2.6.13-rc4?
Well it did claim to find an 8250 controller.
If you have time, it would be useful if you could obtain the 2.6.13-rc3 dmesg
output and do
diff -u dmesg-2.6.13-rc3 dmesg-2.6.13-rc3-mm3
and send it, thanks.
Richard Purdie
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
>
> in 2.6.13. Extra testing, please.
>
The above patch causes the BUG below on the Zaurus (arm pxa255 with
preempt enabled). This can only be due to the suspicious looking changes
to kernel/softirq.c in that patch...
Richard
kernel BUG at kernel/sched.c:2988!
kernel BUG at kernel/sched.c:2988!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 8f5 [#1]
Modules linked in:
CPU: 0
PC is at __bug+0x40/0x54
LR is at 0x60000013
pc : [<c0021290>] lr : [<60000013>] Not tainted
sp : c3c0dc6c ip : 00000001 fp : c3c0dc7c
r10: fffff920 r9 : c3c0c000 r8 : 00000000
r7 : 00000000 r6 : c0271a00 r5 : f2d00000 r4 : 00000000
r3 : 00000000 r2 : 00000000 r1 : 00000026 r0 : 00000001
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: 397F Table: A0004000 DAC: 00000017
Process khelper (pid: 94, stack limit = 0xc3c0c194)
Backtrace:
[<c0021250>] (__bug+0x0/0x54) from [<c01f01a8>] (preempt_schedule_irq+0x84/0x8c)
r4 = C3C0C000
[<c01f0124>] (preempt_schedule_irq+0x0/0x8c) from [<c001ba3c>] (svc_preempt+0x28/0x4c)
r4 = FFFFFFFF
[<c0037618>] (release_console_sem+0x0/0x27c) from [<c0037a48>] (vprintk+0x1b4/0x344)
[<c0037894>] (vprintk+0x0/0x344) from [<c0037bf4>] (printk+0x1c/0x20)
[<c0037bd8>] (printk+0x0/0x20) from [<c002128c>] (__bug+0x3c/0x54)
r3 = C022716C r2 = 00000000 r1 = 00000000 r0 = C02043C8
[<c0021250>] (__bug+0x0/0x54) from [<c01f01a8>] (preempt_schedule_irq+0x84/0x8c)
r4 = C3C0C000
[<c01f0124>] (preempt_schedule_irq+0x0/0x8c) from [<c001ba3c>] (svc_preempt+0x28/0x4c)
r4 = FFFFFFFF
[<c0098ee8>] (dput+0x0/0x308) from [<c008e9ec>] (__link_path_walk+0xc00/0x1280)
r6 = 00000000 r5 = C022EA7E r4 = FFFFFFFE
[<c008ddec>] (__link_path_walk+0x0/0x1280) from [<c008f118>] (link_path_walk+0xac/0x1dc)
[<c008f06c>] (link_path_walk+0x0/0x1dc) from [<c008f334>] (path_lookup+0xec/0x260)
r7 = 00000000 r6 = C3C0DEEC r5 = C3C0C000 r4 = C03327FC
[<c008f248>] (path_lookup+0x0/0x260) from [<c0089f24>] (open_exec+0x2c/0xe0)
r8 = C034FE78 r7 = 00000001 r6 = C3C0DEEC r5 = C3C0AA20
r4 = C022EA78
[<c0089ef8>] (open_exec+0x0/0xe0) from [<c008b224>] (do_execve+0x48/0x1f4)
r7 = FFFFFFF4 r6 = C3C08E00 r5 = C3C0AA20 r4 = C022EA78
[<c008b1dc>] (do_execve+0x0/0x1f4) from [<c0020bfc>] (execve+0x40/0x88)
[<c0020bbc>] (execve+0x0/0x88) from [<c004938c>] (____call_usermodehelper+0xa8/0xb4)
r7 = 00000000 r6 = 00000000 r5 = C034FE14 r4 = C3C0C000
[<c00492e4>] (____call_usermodehelper+0x0/0xb4) from [<c0039604>] (do_exit+0x0/0xd90)
r6 = 00000000 r5 = 00000000 r4 = 00000000
Code: 1b005a54 e59f0014 eb005a52 e3a03000 (e5833000)
Khalid Aziz
> Khalid Aziz <khali...@hp.com> wrote:
> >
> > Serial console is broken on ia64 on an HP rx2600 machine on
> > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > output ever appears on the console and system is hung. So I booted the
> > kernel with "console=uart,mmio,0xff5e0000" to enable early console and
> > here is how far the kernel got before hanging:
>
> (cc the ia64 and acpi lists)
>
> OK, thanks. There have been a few serial driver changes recently, but
> there's also a tremendous ACPI patch in -mm. I'm wondering about those
> ACPI error messages:
>
> > -------
> > Linux version 2.6.13-rc3-mm3 (root@mars) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #4 SMP Fri Jul 29 16:30:41 MDT 2005
> > EFI v1.10 by HP: SALsystab=0x3fb38000 ACPI 2.0=0x3fb2e000 SMBIOS=0x3fb3a000 HCDP=0x3fb2c000
> > booting generic kernel on platform hpzx1
> > PCDP: v0 at 0x3fb2c000
> > Explicit "console="; ignoring PCDP
> > NET: Registered protocol family 16
> > ACPI: bus type pci registered
> > ACPI: Subsystem revision 20050708
> > ACPI-0509: *** Error: Method execution failed [\PARS.GFIT] (Node e0000002ffff8a00), AE_BAD_PARAMETER
> > ACPI-0509: *** Error: Method execution failed [\_SB_.SBA0._INI] (Node e0000002ffffa780), AE_BAD_PARAMETER
> > ACPI: Interpreter enabled
> > ACPI: Using IOSAPIC for interrupt routing
>
> Does the above happen on 2.6.13-rc3 or 2.6.13-rc4?
No, I do not see this on 2.6.13-rc3. It does seem ACPI is busted on
2.6.13-rc3-mm3 which is leading to kernel not being able to scan PCI bus
and set up IRQ routing.
> Well it did claim to find an 8250 controller.
>
> If you have time, it would be useful if you could obtain the 2.6.13-rc3 dmesg
> output and do
> diff -u dmesg-2.6.13-rc3 dmesg-2.6.13-rc3-mm3
>
> and send it, thanks.
Here is the diff:
1c1
< Linux version 2.6.13-rc3 (root@mars) (gcc version 3.3.5 (Debian
1:3.3.5-12)) #
3 SMP Fri Jul 29 16:07:24 MDT 2005
---
> Linux version 2.6.13-rc3-mm3 (root@mars) (gcc version 3.3.5 (Debian
1:3.3.5-12
)) #4 SMP Fri Jul 29 16:30:41 MDT 2005
5a6
> Early serial console at MMIO 0xff5e0000 (options '115200')
19c20
< Kernel command line:
BOOT_IMAGE=scsi1:/EFI/debian/boot/vmlinuz-2.6.13-rc3 root
=/dev/sdb2 console=ttyS0,115200n8 ro
---
> Kernel command line:
BOOT_IMAGE=scsi1:/EFI/debian/boot/vmlinuz-2.6.13-rc3-mm3
root=/dev/sdb2 console=uart,mmio,0xff5e0000 ro
22c23
< Memory: 12438928k/12541920k available (6951k code, 116448k reserved,
3697k dat
a, 288k init)
---
> Memory: 12439136k/12542128k available (7051k code, 116240k reserved,
3406k dat
a, 352k init)
28c29
< CPU 1: synchronized ITC with CPU 0 (last diff 0 cycles, maxerr 433
cycles)
---
> CPU 1: synchronized ITC with CPU 0 (last diff -5 cycles, maxerr 433
cycles)
30a32,60
33c63,65
< ACPI: Subsystem revision 20050408
---
> ACPI: Subsystem revision 20050708
> ACPI-0509: *** Error: Method execution failed [\PARS.GFIT] (Node
e0000002f
fff8a00), AE_BAD_PARAMETER
> ACPI-0509: *** Error: Method execution failed [\_SB_.SBA0._INI]
(Node e000
0002ffffa780), AE_BAD_PARAMETER
36,91d67
< ACPI: PCI Root Bridge [PCI0] (0000:00)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
< ACPI: PCI Root Bridge [PCI1] (0000:20)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
< ACPI: PCI Root Bridge [PCI2] (0000:40)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
< ACPI: PCI Root Bridge [PCI3] (0000:60)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
< ACPI: PCI Root Bridge [PCI4] (0000:80)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
< ACPI: PCI Root Bridge [PCI6] (0000:c0)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
< ACPI: PCI Root Bridge [PCI7] (0000:e0)
< ACPI: Assume root bridge [\_SB_.SBA0.PCI0] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI1] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI2] segment is 0
ACPI: Assume root bridge [\_SB_.SBA0.PCI3] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI4] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI6] segment is 0
< ACPI: Assume root bridge [\_SB_.SBA0.PCI7] segment is 0
93d68
< IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x40000000
100d74
< inotify syscall
106,116c80
< GSI 34 (edge, high) -> CPU 0 (0x0000) vector 49
< ttyS0 at MMIO 0xff5e0000 (irq = 49) is a 16550A
< GSI 35 (edge, high) -> CPU 1 (0x0100) vector 50
< ttyS1 at MMIO 0xff5e2000 (irq = 50) is a 16550A
< GSI 82 (level, low) -> CPU 0 (0x0000) vector 51
< ACPI: PCI Interrupt 0000:e0:01.0[A] -> GSI 82 (level, low) -> IRQ 51
< ttyS2 at MMIO 0xf8031000 (irq = 51) is a 16450
< ACPI: PCI Interrupt 0000:e0:01.1[A] -> GSI 82 (level, low) -> IRQ 51
< ttyS3 at MMIO 0xf8030000 (irq = 51) is a 16550A
< ttyS4 at MMIO 0xf8030010 (irq = 51) is a 16550A
< ttyS5 at MMIO 0xf8030038 (irq = 51) is a 16550A
---
> mice: PS/2 mouse device common for all mice
124c88
< e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI
---
> e100: Intel(R) PRO/100 Network Driver, 3.4.10-k2-NAPI
126,134d89
< GSI 20 (level, low) -> CPU 1 (0x0100) vector 52
< ACPI: PCI Interrupt 0000:00:03.0[A] -> GSI 20 (level, low) -> IRQ 52
< e100: eth0: e100_probe: addr 0x80020000, irq 52, MAC addr
00:30:6E:39:C6:60
< tg3.c:v3.33 (July 5, 2005)
< GSI 29 (level, low) -> CPU 0 (0x0000) vector 53
< ACPI: PCI Interrupt 0000:20:02.0[A] -> GSI 29 (level, low) -> IRQ 53
< eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)]
(PCI:66MHz:64-bit) 10/100
/1000BaseT Ethernet 00:30:6e:39:16:c0
< eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1]
TSOcap[0]
< eth1: dma_rwctrl[76ff2d0f]
137,148c92
< ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
< CMD649: IDE controller at PCI slot 0000:00:02.0
< GSI 21 (level, low) -> CPU 1 (0x0100) vector 54
< ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 21 (level, low) -> IRQ 54
< CMD649: chipset revision 2
< CMD649: 100% native mode on irq 54
< ide0: BM-DMA at 0x0d40-0x0d47, BIOS settings: hda:pio, hdb:pio
< ide1: BM-DMA at 0x0d48-0x0d4f, BIOS settings: hdc:pio, hdd:pio
< hda: DW-28E, ATAPI CD/DVD-ROM drive
< ide0 at 0xd58-0xd5f,0xd66 on irq 54
< hda: ATAPI 24X DVD-ROM CD-R/RW drive, 1698kB Cache, UDMA(33)
< Uniform CD-ROM driver Revision: 3.20
---
> ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
150,167d93
< GSI 38 (level, low) -> CPU 0 (0x0000) vector 55
< ACPI: PCI Interrupt 0000:40:01.0[A] -> GSI 38 (level, low) -> IRQ 55
< sym0: <1010-66> rev 0x1 at pci 0000:40:01.0 irq 55
< sym0: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking
< sym0: open drain IRQ line driver, using on-chip SRAM
< sym0: using LOAD/STORE-based firmware.
< sym0: handling phase mismatch from SCRIPTS.
< sym0: SCSI BUS has been reset.
< scsi0 : sym-2.2.1
< GSI 39 (level, low) -> CPU 1 (0x0100) vector 56
< ACPI: PCI Interrupt 0000:40:01.1[B] -> GSI 39 (level, low) -> IRQ 56
< sym1: <1010-66> rev 0x1 at pci 0000:40:01.1 irq 56
< sym1: Symbios NVRAM, ID 7, Fast-80, LVD, parity checking
< sym1: open drain IRQ line driver, using on-chip SRAM
< sym1: using LOAD/STORE-based firmware.
< sym1: handling phase mismatch from SCRIPTS.
< sym1: SCSI BUS has been reset.
< scsi1 : sym-2.2.1
171,205d96
< GSI 27 (level, low) -> CPU 0 (0x0000) vector 57
< ACPI: PCI Interrupt 0000:20:01.0[A] -> GSI 27 (level, low) -> IRQ 57
< mptbase: Initiating ioc0 bringup
< ioc0: 53C1030: Capabilities={Initiator,Target}
< scsi2 : ioc0: LSI53C1030, FwRev=01032300h, Ports=1, MaxQ=255, IRQ=57
< Vendor: HP 36.4G Model: ST336706LC Rev: HP05
< Type: Direct-Access ANSI SCSI revision: 02
< SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB)
< SCSI device sda: drive cache: write through
< SCSI device sda: 71132960 512-byte hdwr sectors (36420 MB)
< SCSI device sda: drive cache: write through
< sda: sda1 sda2 sda3
< Attached scsi disk sda at scsi2, channel 0, id 0, lun 0
< Vendor: HP 36.4G Model: ST336706LC Rev: HP05
< Type: Direct-Access ANSI SCSI revision: 02
< SCSI device sdb: 71132960 512-byte hdwr sectors (36420 MB)
< SCSI device sdb: drive cache: write through
< SCSI device sdb: 71132960 512-byte hdwr sectors (36420 MB)
< SCSI device sdb: drive cache: write through
< sdb: sdb1 sdb2 sdb3 sdb4
< Attached scsi disk sdb at scsi2, channel 0, id 1, lun 0
< GSI 28 (level, low) -> CPU 1 (0x0100) vector 58
< ACPI: PCI Interrupt 0000:20:01.1[B] -> GSI 28 (level, low) -> IRQ 58
< mptbase: Initiating ioc1 bringup
< mptscsih: ioc0: DV: Release failed. id 0<6>ioc1: 53C1030:
Capabilities={Initia
tor,Target}
< scsi3 : ioc1: LSI53C1030, FwRev=01032300h, Ports=1, MaxQ=255, IRQ=58
< Vendor: HP 36.4G Model: ST336706LC Rev: HP04
< Type: Direct-Access ANSI SCSI revision: 02
< SCSI device sdc: 71132960 512-byte hdwr sectors (36420 MB)
< SCSI device sdc: drive cache: write through
< SCSI device sdc: 71132960 512-byte hdwr sectors (36420 MB)
< SCSI device sdc: drive cache: write through
< sdc: sdc1 sdc2 sdc3
< Attached scsi disk sdc at scsi3, channel 0, id 2, lun 0
< mice: PS/2 mouse device common for all mice
216,220c107
< kjournald starting. Commit interval 5 seconds
< EXT3-fs: mounted filesystem with ordered data mode.
< VFS: Mounted root (ext3 filesystem) readonly.
< Freeing unused kernel memory: 288kB freed
< INIT: version 2.86 booting
---
> No ttyS device at MMIO 0xff5e0000 for console
I have also attached the bootup logs for 2.6.13-rc3 and 2.6.13-rc3-mm3.
--
Khalid
Andrew Morton
>
> On Thu, 2005-07-28 at 02:58 -0700, Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
> >
> > - There's a pretty large x86_64 update here which naughty maintainer wants
> > in 2.6.13. Extra testing, please.
> >
> > +x86_64-switch-to-the-interrupt-stack-when-running-a.patch
>
> The above patch causes the BUG below on the Zaurus (arm pxa255 with
> preempt enabled). This can only be due to the suspicious looking changes
> to kernel/softirq.c in that patch...
err, yes. I assume this was some debugging stuff which leaked through. I
hope x86_64 still works after we fix it...
--- devel/kernel/softirq.c~revert-bogus-softirq-changes 2005-07-30 10:03:12.000000000 -0700
+++ devel-akpm/kernel/softirq.c 2005-07-30 10:03:21.000000000 -0700
@@ -86,7 +86,7 @@ restart:
/* Reset the pending bitmask before enabling irqs */
local_softirq_pending() = 0;
- //local_irq_enable();
+ local_irq_enable();
h = softirq_vec;
@@ -99,7 +99,7 @@ restart:
pending >>= 1;
} while (pending);
- //local_irq_disable();
+ local_irq_disable();
pending = local_softirq_pending();
if (pending && --max_restart)
_
Andrew Morton
OK, thanks. Could I suggest that you raise a bug against ACPI 20050708 at
bugzilla.kernel.org containing the info we've generated thus far?
And thanks for testing -mm: we really don't want to permit this to leak
into mainline...
Manuel Lauss
something broke the sonypi driver a bit after -mm2:
I can no longer set bluetooth-power for instance, and it logs these
messages:
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
setting/getting brightness, getting battery/ac status still work.
The ioports assignments have changed a bit between -mm2 and -mm3:
/proc/ioports on -mm2:
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03f6-03f6 : ide0
0400-047f : 0000:00:1f.0
0400-0403 : PM1a_EVT_BLK
0404-0405 : PM1a_CNT_BLK
0408-040b : PM_TMR
0410-0415 : ACPI CPU throttle
0420-0420 : PM2_CNT_BLK
0428-042f : GPE0_BLK
0500-053f : 0000:00:1f.0
0500-053f : pnp 00:08
0540-055f : 0000:00:1f.3
0540-054f : i801-smbus
0cf8-0cff : PCI conf1
1080-109f : Sony Programable I/O Device
c000-cfff : PCI Bus #01
c800-c8ff : 0000:01:00.0
c800-c8ff : radeonfb
d000-dfff : PCI Bus #02
d000-d1ff : PCI CardBus #03
d400-d5ff : PCI CardBus #03
dc00-dc3f : 0000:02:03.0
dc00-dc3f : e1000
e000-e03f : 0000:00:1f.5
e000-e03f : Intel 82801DB-ICH4
e080-e0ff : 0000:00:1f.6
e400-e4ff : 0000:00:1f.6
e800-e81f : 0000:00:1d.0
e800-e81f : uhci_hcd
e880-e89f : 0000:00:1d.1
e880-e89f : uhci_hcd
ec00-ec1f : 0000:00:1d.2
ec00-ec1f : uhci_hcd
ee00-eeff : 0000:00:1f.5
ee00-eeff : Intel 82801DB-ICH4
fe00-fe01 : motherboard
ffa0-ffaf : 0000:00:1f.1
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
/proc/ioports on -mm3:
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03f6-03f6 : ide0
0400-047f : 0000:00:1f.0
0400-0403 : PM1a_EVT_BLK
0404-0405 : PM1a_CNT_BLK
0408-040b : PM_TMR
0410-0415 : ACPI CPU throttle
0420-0420 : PM2_CNT_BLK
0428-042f : GPE0_BLK
0500-053f : 0000:00:1f.0
0500-053f : pnp 00:08
0540-055f : 0000:00:1f.3
0540-054f : i801-smbus
0cf8-0cff : PCI conf1
1000-1fff : PCI CardBus #03
1080-109f : Sony Programable I/O Device
2000-2fff : PCI CardBus #03
c000-cfff : PCI Bus #01
c800-c8ff : 0000:01:00.0
c800-c8ff : radeonfb
d000-dfff : PCI Bus #02
dc00-dc3f : 0000:02:03.0
dc00-dc3f : e1000
e000-e03f : 0000:00:1f.5
e000-e03f : Intel 82801DB-ICH4
e080-e0ff : 0000:00:1f.6
e400-e4ff : 0000:00:1f.6
e800-e81f : 0000:00:1d.0
e800-e81f : uhci_hcd
e880-e89f : 0000:00:1d.1
e880-e89f : uhci_hcd
ec00-ec1f : 0000:00:1d.2
ec00-ec1f : uhci_hcd
ee00-eeff : 0000:00:1f.5
ee00-eeff : Intel 82801DB-ICH4
fe00-fe01 : motherboard
ffa0-ffaf : 0000:00:1f.1
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
I'd appreciate any hints
Thanks,
--
Manuel Lauss
Andrew Morton
>
> something broke the sonypi driver a bit after -mm2:
> I can no longer set bluetooth-power for instance, and it logs these
> messages:
>
> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
> sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
>
> setting/getting brightness, getting battery/ac status still work.
>
Can you do a `patch -p1 -R' of the below, see if it fixes it? It probably
won't.
Also please test 2.6.13-rc4-mm1 which is missing the acpi tree...
Thanks.
From: Dmitry Torokhov <dtor...@ameritech.net>
Make sure that input_work is not running when unloading the module;
submit/retrieve key release data into/from input_fifo in one shot.
Signed-off-by: Dmitry Torokhov <dt...@mail.ru>
Cc: Stelian Pop <ste...@popies.net>
Signed-off-by: Andrew Morton <ak...@osdl.org>
---
drivers/char/sonypi.c | 122 +++++++++++++++++++++++++-------------------------
1 files changed, 63 insertions(+), 59 deletions(-)
diff -puN drivers/char/sonypi.c~sonypi-make-sure-that-input_work-is-not-running-when-unloading drivers/char/sonypi.c
--- 25/drivers/char/sonypi.c~sonypi-make-sure-that-input_work-is-not-running-when-unloading 2005-06-03 02:13:08.000000000 -0700
+++ 25-akpm/drivers/char/sonypi.c 2005-06-03 02:13:08.000000000 -0700
@@ -439,6 +439,11 @@ static struct {
{ 0, 0 },
};
+struct sonypi_keypress {
+ struct input_dev *dev;
+ int key;
+};
+
static struct sonypi_device {
struct pci_dev *dev;
struct platform_device *pdev;
@@ -710,22 +715,61 @@ static void sonypi_setbluetoothpower(u8
static void input_keyrelease(void *data)
{
- struct input_dev *input_dev;
- int key;
-
- while (1) {
- if (kfifo_get(sonypi_device.input_fifo,
- (unsigned char *)&input_dev,
- sizeof(input_dev)) != sizeof(input_dev))
- return;
- if (kfifo_get(sonypi_device.input_fifo,
- (unsigned char *)&key,
- sizeof(key)) != sizeof(key))
- return;
+ struct sonypi_keypress kp;
+ while (kfifo_get(sonypi_device.input_fifo, (unsigned char *)&kp,
+ sizeof(kp)) == sizeof(kp)) {
msleep(10);
- input_report_key(input_dev, key, 0);
- input_sync(input_dev);
+ input_report_key(kp.dev, kp.key, 0);
+ input_sync(kp.dev);
+ }
+}
+
+static void sonypi_report_input_event(u8 event)
+{
+ struct input_dev *jog_dev = &sonypi_device.input_jog_dev;
+ struct input_dev *key_dev = &sonypi_device.input_key_dev;
+ struct sonypi_keypress kp = { NULL };
+ int i;
+
+ switch (event) {
+ case SONYPI_EVENT_JOGDIAL_UP:
+ case SONYPI_EVENT_JOGDIAL_UP_PRESSED:
+ input_report_rel(jog_dev, REL_WHEEL, 1);
+ input_sync(jog_dev);
+ break;
+
+ case SONYPI_EVENT_JOGDIAL_DOWN:
+ case SONYPI_EVENT_JOGDIAL_DOWN_PRESSED:
+ input_report_rel(jog_dev, REL_WHEEL, -1);
+ input_sync(jog_dev);
+ break;
+
+ case SONYPI_EVENT_JOGDIAL_PRESSED:
+ kp.key = BTN_MIDDLE;
+ kp.dev = jog_dev;
+ break;
+
+ case SONYPI_EVENT_FNKEY_RELEASED:
+ /* Nothing, not all VAIOs generate this event */
+ break;
+
+ default:
+ for (i = 0; sonypi_inputkeys[i].sonypiev; i++)
+ if (event == sonypi_inputkeys[i].sonypiev) {
+ kp.dev = key_dev;
+ kp.key = sonypi_inputkeys[i].inputev;
+ break;
+ }
+ break;
+ }
+
+ if (kp.dev) {
+ input_report_key(kp.dev, kp.key, 1);
+ input_sync(kp.dev);
+ kfifo_put(sonypi_device.input_fifo,
+ (unsigned char *)&kp, sizeof(kp));
+ schedule_work(&sonypi_device.input_work);
}
}
@@ -768,51 +812,8 @@ found:
printk(KERN_INFO
"sonypi: event port1=0x%02x,port2=0x%02x\n", v1, v2);
- if (useinput) {
- struct input_dev *input_jog_dev = &sonypi_device.input_jog_dev;
- struct input_dev *input_key_dev = &sonypi_device.input_key_dev;
- switch (event) {
- case SONYPI_EVENT_JOGDIAL_UP:
- case SONYPI_EVENT_JOGDIAL_UP_PRESSED:
- input_report_rel(input_jog_dev, REL_WHEEL, 1);
- break;
- case SONYPI_EVENT_JOGDIAL_DOWN:
- case SONYPI_EVENT_JOGDIAL_DOWN_PRESSED:
- input_report_rel(input_jog_dev, REL_WHEEL, -1);
- break;
- case SONYPI_EVENT_JOGDIAL_PRESSED: {
- int key = BTN_MIDDLE;
- input_report_key(input_jog_dev, key, 1);
- kfifo_put(sonypi_device.input_fifo,
- (unsigned char *)&input_jog_dev,
- sizeof(input_jog_dev));
- kfifo_put(sonypi_device.input_fifo,
- (unsigned char *)&key, sizeof(key));
- break;
- }
- case SONYPI_EVENT_FNKEY_RELEASED:
- /* Nothing, not all VAIOs generate this event */
- break;
- }
- input_sync(input_jog_dev);
-
- for (i = 0; sonypi_inputkeys[i].sonypiev; i++) {
- int key;
-
- if (event != sonypi_inputkeys[i].sonypiev)
- continue;
-
- key = sonypi_inputkeys[i].inputev;
- input_report_key(input_key_dev, key, 1);
- kfifo_put(sonypi_device.input_fifo,
- (unsigned char *)&input_key_dev,
- sizeof(input_key_dev));
- kfifo_put(sonypi_device.input_fifo,
- (unsigned char *)&key, sizeof(key));
- }
- input_sync(input_key_dev);
- schedule_work(&sonypi_device.input_work);
- }
+ if (useinput)
+ sonypi_report_input_event(event);
kfifo_put(sonypi_device.fifo, (unsigned char *)&event, sizeof(event));
kill_fasync(&sonypi_device.fifo_async, SIGIO, POLL_IN);
@@ -1337,6 +1338,9 @@ static void __devexit sonypi_remove(void
{
sonypi_disable();
+ synchronize_sched(); /* Allow sonypi interrupt to complete. */
+ flush_scheduled_work();
+
platform_device_unregister(sonypi_device.pdev);
if (useinput) {
_
Manuel Lauss
> Manuel Lauss <ma...@roarinelk.homelinux.net> wrote:
>
>>something broke the sonypi driver a bit after -mm2:
>> I can no longer set bluetooth-power for instance, and it logs these
>> messages:
>>
>> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
>> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
>> sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
>>
>> setting/getting brightness, getting battery/ac status still work.
>>
>
>
> Can you do a `patch -p1 -R' of the below, see if it fixes it? It probably
> won't.
>
> Also please test 2.6.13-rc4-mm1 which is missing the acpi tree...
>
> Thanks.
Didn't help, and -rc4-mm1 has the same problem.
Also tried with CONFIG_ACPI=n and with cardbus disabled, no change.
Added a few debug lines to the module:
sonypi_call1(82) enter
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 595)
sonypi_call1() leave
sonypi_call2(81, ff) enter
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 608)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 610)
sonypi_call2() leave
sonypi_call1(82) enter
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 595)
sonypi_call1() leave
sonypi: Sony Programmable I/O Controller Driverv1.26.
sonypi: detected type2 model, verbose = 1, fnkeyinit = off, camera = off, compat = off, mask = 0xffffffff, useinput = off, acpi = on
sonypi: enabled at irq=11, port1=0x1080, port2=0x1084
sonypi: device allocated minor is 63
sonypi: setbluetoothpower enter
sonypi_call2(96, 00) enter
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 608)
sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 610)
sonypi_call2() leave
sonypi_call1(82) enter
sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 595)
sonypi_call1() leave
sonypi: setbluetoothpower leave
brightness for instance does not use the sonypi_callX() functions, and it works.
cat /dev/sonypi produces no more output either, and interrupt count for sonypi does
no longer increase when I press a hotkey or close the lid.
Thanks,
--
Manuel Lauss
Manuel Lauss
> Manuel Lauss <ma...@roarinelk.homelinux.net> wrote:
>
>>something broke the sonypi driver a bit after -mm2:
>> I can no longer set bluetooth-power for instance, and it logs these
>> messages:
>>
>> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
>> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
>> sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
>>
>> setting/getting brightness, getting battery/ac status still work.
>>
>
>
> Can you do a `patch -p1 -R' of the below, see if it fixes it? It probably
> won't.
>
> Also please test 2.6.13-rc4-mm1 which is missing the acpi tree...
>
> Thanks.
Found the cause:
> -revert-gregkh-pci-pci-assign-unassigned-resources.patch
>
> Hopefully no longer needed
Applying this dropped patch to -rc3-mm3 and -rc4-mm1 fixes
it.
Thanks,
--
Manuel Lauss
Andrew Morton
>
> Andrew Morton wrote:
> > Manuel Lauss <ma...@roarinelk.homelinux.net> wrote:
> >
> >>something broke the sonypi driver a bit after -mm2:
> >> I can no longer set bluetooth-power for instance, and it logs these
> >> messages:
> >>
> >> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
> >> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
> >> sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
> >>
> >> setting/getting brightness, getting battery/ac status still work.
> >>
> >
> >
> > Can you do a `patch -p1 -R' of the below, see if it fixes it? It probably
> > won't.
> >
> > Also please test 2.6.13-rc4-mm1 which is missing the acpi tree...
> >
> > Thanks.
>
>
> Found the cause:
Wonderful, thanks. So does that mean that 2.6.13-rc4 doesn't work?
> > -revert-gregkh-pci-pci-assign-unassigned-resources.patch
> >
> > Hopefully no longer needed
>
> Applying this dropped patch to -rc3-mm3 and -rc4-mm1 fixes
> it.
OK, I'll bring it back again.
Manuel Lauss
> Manuel Lauss <ma...@roarinelk.homelinux.net> wrote:
> >
> > Andrew Morton wrote:
> > > Manuel Lauss <ma...@roarinelk.homelinux.net> wrote:
> > >
> > >>something broke the sonypi driver a bit after -mm2:
> > >> I can no longer set bluetooth-power for instance, and it logs these
> > >> messages:
> > >>
> > >> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
> > >> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
> > >> sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
> > >>
> > >> setting/getting brightness, getting battery/ac status still work.
> > >>
> > >
> > >
> > > Can you do a `patch -p1 -R' of the below, see if it fixes it? It probably
> > > won't.
> > >
> > > Also please test 2.6.13-rc4-mm1 which is missing the acpi tree...
> > >
> > > Thanks.
> >
> >
> > Found the cause:
>
> Wonderful, thanks. So does that mean that 2.6.13-rc4 doesn't work?
Yes, sonypi is busted in -rc4 also.
--
Manuel Lauss
Linus Torvalds
On Sun, 31 Jul 2005, Manuel Lauss wrote:
>
> something broke the sonypi driver a bit after -mm2:
> I can no longer set bluetooth-power for instance, and it logs these
> messages:
>
> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 605)
> sonypi command failed at drivers/char/sonypi.c : sonypi_call2 (line 607)
> sonypi command failed at drivers/char/sonypi.c : sonypi_call1 (line 594)
>
> setting/getting brightness, getting battery/ac status still work.
>
>
> The ioports assignments have changed a bit between -mm2 and -mm3:
The diff shows:
-/proc/ioports on -mm2:
+/proc/ioports on -mm3:
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
@@ -25,13 +25,13 @@
0540-055f : 0000:00:1f.3
0540-054f : i801-smbus
0cf8-0cff : PCI conf1
-1080-109f : Sony Programable I/O Device
+1000-1fff : PCI CardBus #03
+ 1080-109f : Sony Programable I/O Device
+2000-2fff : PCI CardBus #03
c000-cfff : PCI Bus #01
c800-c8ff : 0000:01:00.0
c800-c8ff : radeonfb
d000-dfff : PCI Bus #02
- d000-d1ff : PCI CardBus #03
- d400-d5ff : PCI CardBus #03
dc00-dc3f : 0000:02:03.0
dc00-dc3f : e1000
e000-e03f : 0000:00:1f.5
ie the difference is that the PCI cardbus resources have been moved from
inside PCI Bus #2 to outside of it, and as a side effect the sonypi
device just happened to be allocated inside the Cardbus IO space.
Now, this is really unlucky. There are two issues here:
- the -mm2 iomap just _looks_ better. I can't tell what the exact
difference is, but it looks like one of the PCI resource allocation
patches got reverted or re-applied.
However, I'm almost positive that this is the Intel transparent bridge
thing, and it doesn't really matter where the CardBus resources got
allocated. So the _real_ breakage is probably due to a totally
unrelated issue:
- The SonyPI driver just allocates IO regions in random areas. It's got a
list of places to try allocating in, and the 1080 area just happens to
be the first on the list, and since it's not used by anything else, it
succeeds (never mind that it's on totally the wrong bus).
and I think the real bug here is the SonyPI driver.
It should either use an IO port in the legacy motherboard resource area
(ie allocate itself somewhere in IO ports 0x100-0x3ff), _or_ it should
play well as a PCI device, and actually try to work with the PCI IO port
allocation layer.
So instead of just saying "I want port 1080" (which may be on some other
bus entirely), it _could_ (and should) do something like
/*
* Use "device resource 6" for this: it's traditionally
* the PCI ROM resource, but we don't have a ROM, so we take it
* over for our special IO region.
*/
struct resource *res = dev->resource + 6;
int ret;
res->flags = IORESOURCE_IO;
ret = pci_bus_alloc_resource(dev->bus, /* bus */
res, /* resource */
SONYPI_TYPE2_REGION_SIZE, /* size */,
SONYPI_TYPE2_REGION_SIZE, /* alignment */,
PCIBIOS_MIN_IO, /* Min starting pos */
IORESOURCE_IO, /* IO type */
pcibios_align_resource, /* Standard alignment */
dev);
if (ret < 0)
return -ENODEV;
.. use port "res->start" ..
which should do the right thing.
Stelian? The above is untested, but it should give roughly the right
behaviour - you might need to tweak it a bit, but I think it should be a
lot better than just picking random IO ports out of your hat and seeing if
they are already used by something else...
Linus
Manuel Lauss
>
> - The SonyPI driver just allocates IO regions in random areas. It's got a
> list of places to try allocating in, and the 1080 area just happens to
> be the first on the list, and since it's not used by anything else, it
> succeeds (never mind that it's on totally the wrong bus).
On three different intel-vaios, I've seen the sonypi device always
located at ioport 0x1080. Even the windows driver on these models
always allocates the 0x1080-0x109f io-range for it.
--
Manuel Lauss
Linus Torvalds
On Sun, 31 Jul 2005, Manuel Lauss wrote:
>
> Linus Torvalds wrote:
>
> >
> > - The SonyPI driver just allocates IO regions in random areas. It's got a
> > list of places to try allocating in, and the 1080 area just happens to
> > be the first on the list, and since it's not used by anything else, it
> > succeeds (never mind that it's on totally the wrong bus).
>
> On three different intel-vaios, I've seen the sonypi device always
> located at ioport 0x1080. Even the windows driver on these models
> always allocates the 0x1080-0x109f io-range for it.
I think that's how the Linux driver IO list was gathered - looking at
where it tends to sit by default.
And the thing is, that would actually be ok too (as I sent in a separate
email to Stelian later) - if the BIOS actually sets it up at 1080, we
could easily just make a PCI quirk that marks that region _early_ in the
bootup sequence as being reserved for SonyPI. That would make any later
PCI allocation requests know to avoid it.
The problem with the current setup is that the SonyPI driver is a
perfectly regular driver, and thus obviously loads _after_ a number of
other drivers, and the PCI setup code in particular. So what has happened
is that we've set up other PCI IO regious without knowing - or caring -
about the SonyPI driver, and then the SonyPI driver comes along and says
"oh, btw, I want that region".
And _that_ cannot work reliably. If you have a specific pre-allocated
region that you want (or must have - some regions are fixed because of
things like ACPI tables or SMM etc that depend on them), then you need to
tell the world about it _before_ it starts allocating anything else,
because otherwise the allocation routines obviously cannot know about that
fixed thing.
So what the sonypi driver does now is wrong, but there are two choices to
do it right: tell the PCI subsystem early (traditionally done as a PCI
quirk in drivers/pci/quirks.c, but you could possibly also make it as a
driver-specific "subsys_initcall()" - but only if your driver is always
compiled in, which sonypi isn't), or then allocate it nicely later.
It's the combination of the two that is bad: "just tell somebody later"
doesn't work. They may say that it's easier to get forgiveness than ask
for permission, but that's not true in kernels. Because if you do
something wrong, the device simply won't _work_, which is exactly what
happened here ;).
Linus
Stelian Pop
> - The SonyPI driver just allocates IO regions in random areas.
Those are not really random, the list of IO regions available is given
in the ACPI SPIC device specification. The list is hardcoded here
because the driver does not (yet ?) use the ACPI services for
initializing the device, and experience has shown that the list does not
vary with different models.
> and I think the real bug here is the SonyPI driver.
>
> It should either use an IO port in the legacy motherboard resource area
> (ie allocate itself somewhere in IO ports 0x100-0x3ff),
this cannot be done, because the regions are already defined, and are
not in the legacy area.
> _or_ it should
> play well as a PCI device, and actually try to work with the PCI IO port
> allocation layer.
sure, but the SPIC device is not really tied to a specific PCI device
(it is for the 'type1' models, but not for the 'type2' ones). That's why
the sonypi driver is not a PCI driver but relies on a DMI ident to
detect each and every Vaio laptop out there.
Stelian.
--
Stelian Pop <ste...@popies.net>
Richard Purdie
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/
I'm seeing a problem on ARM with -rc3-mm3 and -rc4-mm1. -rc3-mm2 and
-rc4 are fine and looking for the problem reveals the problems start
after these patches are applied:
> +page-fault-patches-optional-page_lock-acquisition-in.patch
> +page-fault-patches-optional-page_lock-acquisition-in-tidy.patch
The system appears to be ok and boots happily to a console but if you
load any graphical UI, the screen will blank and the process stops
working (tested with opie and and xserver+GPE). You can kill -9 the
process but you can't regain the console without a suspend/resume cycle
which performs enough of a reset to get it back. chvt and the console
switching keys don't respond.
I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it
makes no difference.
Richard
Stelian Pop
Le dimanche 31 juillet 2005 à 16:22 -0700, Linus Torvalds a écrit :
> Also, it looks like sonypi really is pretty nasty to probe for, so it's
> not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> Otherwise I'd just suggest adding a "dmi_check_system()" table to
> arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> then you could just allocate things based on DMI information.
Since every Vaio laptop out there seems indeed to use only the first IO
port range in the list, we can de-nastyify the probe. And if we don't
even bother to check for Type1 vs. Type2 devices and we reserve both,
then it may be acceptable to do the above.
See the attached patch below which does just that. This has NOT been
tested (only compile-tested), and moreover it has a high breakage
probability in case some Vaios cannot live with the fixed ioport choice.
Note that this patch will conflict with the recent Eric's one (added in
CC:), he may want to rediff his Type3 changes in case this patch gets
in.
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop <ste...@popies.net>
arch/i386/pci/i386.c | 42 +++++++++++++++++++++++++++++++++++
drivers/char/sonypi.c | 60 ++++++++------------------------------------------
2 files changed, 52 insertions(+), 50 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===================================================================
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-07-08 14:08:10.000000000 +0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-01 15:46:06.000000000 +0200
@@ -30,6 +30,7 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/errno.h>
+#include <linux/dmi.h>
#include "pci.h"
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, "Sony Programable I/O Type1 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type1 IO region\n");
+
+ /* IO ports for 'type2' device */
+ if (!request_region(0x1080, 0x20, "Sony Programable I/O Type2 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type2 IO region\n");
+
+ printk(KERN_INFO "Sony Vaio: pre-reserved IO ports\n");
+
+ return 0;
+}
+
+static struct dmi_system_id __initdata sonyvaioio_dmi_table[] = {
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PCG-"),
+ },
+ },
+ {
+ .callback = sonyvaio_reserve_ioports,
+ .ident = "Sony Vaio Laptop",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "VGN-"),
+ },
+ },
+ { }
+};
+
static int __init pcibios_assign_resources(void)
{
struct pci_dev *dev = NULL;
int idx;
struct resource *r;
+ dmi_check_system(sonyvaioio_dmi_table);
+
for_each_pci_dev(dev) {
int class = dev->class >> 8;
Index: linux-2.6.git/drivers/char/sonypi.c
===================================================================
--- linux-2.6.git.orig/drivers/char/sonypi.c 2005-08-01 11:06:47.000000000 +0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-01 15:45:27.000000000 +0200
@@ -104,14 +104,18 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_BASE 0x50
#define SONYPI_G10A (SONYPI_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
#define SONYPI_SIRQ 0x9b
#define SONYPI_SLOB 0x9c
#define SONYPI_SHIB 0x9d
-#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* battery / brightness addresses */
@@ -136,29 +140,6 @@
#define SONYPI_DATA_IOPORT 0x62
#define SONYPI_CST_IOPORT 0x66
-/* The set of possible ioports */
-struct sonypi_ioport_list {
- u16 port1;
- u16 port2;
-};
-
-static struct sonypi_ioport_list sonypi_type1_ioport_list[] = {
- { 0x10c0, 0x10c4 }, /* looks like the default on C1Vx */
- { 0x1080, 0x1084 },
- { 0x1090, 0x1094 },
- { 0x10a0, 0x10a4 },
- { 0x10b0, 0x10b4 },
- { 0x0, 0x0 }
-};
-
-static struct sonypi_ioport_list sonypi_type2_ioport_list[] = {
- { 0x1080, 0x1084 },
- { 0x10a0, 0x10a4 },
- { 0x10c0, 0x10c4 },
- { 0x10e0, 0x10e4 },
- { 0x0, 0x0 }
-};
-
/* The set of possible interrupts */
struct sonypi_irq_list {
u16 irq;
@@ -451,7 +432,6 @@
u16 bits;
u16 ioport1;
u16 ioport2;
- u16 region_size;
u16 evtype_offset;
int camera_power;
int bluetooth_power;
@@ -1139,7 +1119,6 @@
static int __devinit sonypi_probe(void)
{
int i, ret;
- struct sonypi_ioport_list *ioport_list;
struct sonypi_irq_list *irq_list;
struct pci_dev *pcidev;
@@ -1177,33 +1156,17 @@
}
if (sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE2) {
- ioport_list = sonypi_type2_ioport_list;
- sonypi_device.region_size = SONYPI_TYPE2_REGION_SIZE;
+ sonypi_device.ioport1 = SONYPI_TYPE2_IOPORT1;
+ sonypi_device.ioport2 = SONYPI_TYPE2_IOPORT2;
sonypi_device.evtype_offset = SONYPI_TYPE2_EVTYPE_OFFSET;
irq_list = sonypi_type2_irq_list;
} else {
- ioport_list = sonypi_type1_ioport_list;
- sonypi_device.region_size = SONYPI_TYPE1_REGION_SIZE;
+ sonypi_device.ioport1 = SONYPI_TYPE1_IOPORT1;
+ sonypi_device.ioport2 = SONYPI_TYPE1_IOPORT2;
sonypi_device.evtype_offset = SONYPI_TYPE1_EVTYPE_OFFSET;
irq_list = sonypi_type1_irq_list;
}
- for (i = 0; ioport_list[i].port1; i++) {
- if (request_region(ioport_list[i].port1,
- sonypi_device.region_size,
- "Sony Programable I/O Device")) {
- /* get the ioport */
- sonypi_device.ioport1 = ioport_list[i].port1;
- sonypi_device.ioport2 = ioport_list[i].port2;
- break;
- }
- }
- if (!sonypi_device.ioport1) {
- printk(KERN_ERR "sonypi: request_region failed\n");
- ret = -ENODEV;
- goto out_reqreg;
- }
-
for (i = 0; irq_list[i].irq; i++) {
sonypi_device.irq = irq_list[i].irq;
@@ -1303,8 +1266,6 @@
input_unregister_device(&sonypi_device.input_jog_dev);
free_irq(sonypi_device.irq, sonypi_irq);
out_reqirq:
- release_region(sonypi_device.ioport1, sonypi_device.region_size);
-out_reqreg:
misc_deregister(&sonypi_misc_device);
out_miscreg:
if (pcidev)
@@ -1332,7 +1293,6 @@
}
free_irq(sonypi_device.irq, sonypi_irq);
- release_region(sonypi_device.ioport1, sonypi_device.region_size);
misc_deregister(&sonypi_misc_device);
if (sonypi_device.dev)
pci_disable_device(sonypi_device.dev);
--
Stelian Pop <ste...@popies.net>
Bjorn Helgaas
> Khalid Aziz <khali...@hp.com> wrote:
> >
> > Serial console is broken on ia64 on an HP rx2600 machine on
> > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > output ever appears on the console and system is hung. So I booted the
> > kernel with "console=uart,mmio,0xff5e0000" to enable early console and
> > here is how far the kernel got before hanging:
> > Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing enabled
> > ...
> > No ttyS device at MMIO 0xff5e0000 for console
> >
> > Serial driver failed to find any serial ports. I am using defconfig. A
> > 2.6.13-rc3 kernel (no mm3 patch) compiled with defconfig boots up fine
> > and finds all serial ports.
Your rc3-mm3 boot is also missing this:
IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x40000000
So something's busted with ACPI. Both the IOC and the rx2600 serial
ports should be discovered via ACPI.
Christoph Lameter
> The system appears to be ok and boots happily to a console but if you
> load any graphical UI, the screen will blank and the process stops
> working (tested with opie and and xserver+GPE). You can kill -9 the
> process but you can't regain the console without a suspend/resume cycle
> which performs enough of a reset to get it back. chvt and the console
> switching keys don't respond.
Is this related to the size of the process? Can you do a successful kernel
compile w/o X?
> I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it
> makes no difference.
Yes that only helps if compilation fails and its alread in rc4-mm1 AFAIK.
Richard Purdie
> On Mon, 1 Aug 2005, Richard Purdie wrote:
>
> > The system appears to be ok and boots happily to a console but if you
> > load any graphical UI, the screen will blank and the process stops
> > working (tested with opie and and xserver+GPE). You can kill -9 the
> > process but you can't regain the console without a suspend/resume cycle
> > which performs enough of a reset to get it back. chvt and the console
> > switching keys don't respond.
>
> Is this related to the size of the process? Can you do a successful kernel
> compile w/o X?
Its an embedded device and lacks development tools to test that. I ran
some programs which abuse malloc and the process would quite happily hit
oom so it looks like something more is needed to trigger the bug...
> > I tried the patch mentioned in http://lkml.org/lkml/2005/7/28/304 but it
> > makes no difference.
>
> Yes that only helps if compilation fails and its alread in rc4-mm1 AFAIK.
I thought that might be the case.
Richard
Christoph Lameter
> > Is this related to the size of the process? Can you do a successful kernel
> > compile w/o X?
>
> Its an embedded device and lacks development tools to test that. I ran
> some programs which abuse malloc and the process would quite happily hit
> oom so it looks like something more is needed to trigger the bug...
Could you get me some more information about the hang? A stacktrace would
be useful.
Well the device is able to run X so I guess that a slow kernel compile
would work. At least the embedded device that I used to work on was
capable of doing that (but then we had Debian on that thing which made
doing stuff like that very easy).
Christoph Lameter
> On Mon, 2005-08-01 at 13:36 -0700, Christoph Lameter wrote:
> > Could you get me some more information about the hang? A stacktrace would
> > be useful.
>
> I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> of the trace is junk as glibc's arm memcpy implementation will have
> destroyed the frame pointer. The current instruction is a store to
> memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
> changing...
IP Not changing? Could it be in a loop doing faults for the same memory
location that you cannot observe with gdb? Or is there some hardware fault
that has stopped the processor?
Richard Purdie
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > I've attached gdb to it and its stuck in memcpy (from glibc). The rest
> > of the trace is junk as glibc's arm memcpy implementation will have
> > destroyed the frame pointer. The current instruction is a store to
> > memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
> > changing...
>
> IP Not changing? Could it be in a loop doing faults for the same memory
> location that you cannot observe with gdb? Or is there some hardware fault
> that has stopped the processor?
I'm not the worlds most experienced user of gdb but I can't see any
evidence of a hardware fault and the processor shows all indications of
running. It seems likely to be looping with memory faults or otherwise
jammed somehow.
Is there anything I can use in /proc to monitor page faults or anything
I can do with gdb to help narrow this down?
Richard
Christoph Lameter
> > IP Not changing? Could it be in a loop doing faults for the same memory
> > location that you cannot observe with gdb? Or is there some hardware fault
> > that has stopped the processor?
>
> I'm not the worlds most experienced user of gdb but I can't see any
> evidence of a hardware fault and the processor shows all indications of
> running. It seems likely to be looping with memory faults or otherwise
> jammed somehow.
Can you run kgdb on it to figure out what is going on?
> Is there anything I can use in /proc to monitor page faults or anything
> I can do with gdb to help narrow this down?
Run kgdb and see what is going on in the fault handler.
There are some variables in /proc/vmstat that may help:
spurious_page_faults 0
cmpxchg_fail_flag_update 0
cmpxchg_fail_flag_reuse 0
cmpxchg_fail_anon_read 0
cmpxchg_fail_anon_write 0
etc.
Christoph Lameter
> cmpxchg_fail_flag_update 1359210189
>
> That number rapidly increases and so it looks like something is failing
> and looping...
That looks like some trouble with the MMU. The time between pte read and
write has been shortened through the page fault scalability patches.
Does this patch fix it?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-01 15:02:19.000000000 -0700
@@ -2105,6 +2105,7 @@
lazy_mmu_prot_update(entry);
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
pte_unmap(pte);
Richard Purdie
> Can you run kgdb on it to figure out what is going on?
Maybe, depending on how easily kgdb cross compiles and how quickly I can
learn to use it...
> There are some variables in /proc/vmstat that may help:
>
> spurious_page_faults 0
> cmpxchg_fail_flag_update 0
> cmpxchg_fail_flag_reuse 0
> cmpxchg_fail_anon_read 0
> cmpxchg_fail_anon_write 0
In my case:
spurious_page_faults 0
cmpxchg_fail_flag_update 1359210189
cmpxchg_fail_flag_reuse 0
cmpxchg_fail_anon_read 0
cmpxchg_fail_anon_write 0
That number rapidly increases and so it looks like something is failing
and looping...
Richard
Christoph Lameter
> and looping...
Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two different handle_pte_fault functions to get rid of the
macro mess:
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-01 15:08:31.000000000 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, entry, write_access);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
Index: linux-2.6.13-rc4-mm1/mm/memory.o
===================================================================
Binary files linux-2.6.13-rc4-mm1.orig/mm/memory.o 2005-08-01 15:03:10.000000000 -0700 and linux-2.6.13-rc4-mm1/mm/memory.o 2005-08-01 15:09:50.000000000 -0700 differ
Richard Purdie
> be useful.
I've attached gdb to it and its stuck in memcpy (from glibc). The rest
of the trace is junk as glibc's arm memcpy implementation will have
destroyed the frame pointer. The current instruction is a store to
memory (stmneia r0!, {r3,r4} ) and the instruction pointer isn't
changing...
> Well the device is able to run X so I guess that a slow kernel compile
> would work. At least the embedded device that I used to work on was
> capable of doing that (but then we had Debian on that thing which made
> doing stuff like that very easy).
I agree, it would probably do a slow compile. I have no compiler or
development tools on it though and only slow vfat disks other than the
internal flash. There are plenty of options to get such things working
but it will take me a while to setup.
Hopefully the memcpy clue will mean something?
Richard
Richard Purdie
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > That number rapidly increases and so it looks like something is failing
> > and looping...
>
> Maybe we better restore the pte flags changes the way they were if
> CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
> then we need two different handle_pte_fault functions to get rid of the
> macro mess:
>
> /*
> * If the cmpxchg fails then another processor may have done
> * the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
> } else {
> inc_page_state(cmpxchg_fail_flag_update);
> }
> +#else
> + ptep_set_access_flags(vma, address, pte, entry, write_access);
> + update_mmu_cache(vma, address, entry);
> + lazy_mmu_prot_update(entry);
> +#endif
This locks the system up after the "INIT: version 2.86 booting" message.
SysRq still responds but that's about it.
The system also feels/looks extremely sluggish after this change (more
looping?).
With your previously suggested change:
} else {
inc_page_state(cmpxchg_fail_flag_update);
+ set_pte_at(mm, address, pte, new_entry);
}
the system proceeds past INIT and boots normally but X still locks up...
Richard
Christoph Lameter
> > + update_mmu_cache(vma, address, entry);
> > + lazy_mmu_prot_update(entry);
> > +#endif
>
> This locks the system up after the "INIT: version 2.86 booting" message.
> SysRq still responds but that's about it.
Hmmm. this should have returned the behavior to normal. Ah. Need to use
new_entry instead of entry. Try this (is there any way that I could get
access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 16:11:45.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-01 16:15:35.000000000 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}
+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, new_entry, write_access);
+ update_mmu_cache(vma, address, new_entry);
+ lazy_mmu_prot_update(new_entry);
+#endif
pte_unmap(pte);
page_table_atomic_stop(mm);
Richard Purdie
> Hmmm. this should have returned the behavior to normal. Ah. Need to use
> new_entry instead of entry. Try this (is there any way that I could get
> access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
>
> /*
> * If the cmpxchg fails then another processor may have done
> * the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
> } else {
> inc_page_state(cmpxchg_fail_flag_update);
> }
> +#else
> + ptep_set_access_flags(vma, address, pte, new_entry, write_access);
> + update_mmu_cache(vma, address, new_entry);
> + lazy_mmu_prot_update(new_entry);
> +#endif
With this applied, the system boots then X locks up in memcpy as before.
The cmpxchg_fail_flag_update remains at zero but given the above patch,
that's to be expected...
Sadly, remote access to the system isn't really much use as there is no
compiler on the device and flashing a new kernel is a manual procedure
involving pressing buttons.
Richard
Stelian Pop
> > Also, it looks like sonypi really is pretty nasty to probe for, so it's
> > not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> > Otherwise I'd just suggest adding a "dmi_check_system()" table to
> > arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> > then you could just allocate things based on DMI information.
> Since every Vaio laptop out there seems indeed to use only the first IO
> port range in the list, we can de-nastyify the probe. And if we don't
> even bother to check for Type1 vs. Type2 devices and we reserve both,
> then it may be acceptable to do the above.
>
> See the attached patch below which does just that. This has NOT been
> tested (only compile-tested), and moreover it has a high breakage
> probability in case some Vaios cannot live with the fixed ioport choice.
>
> Note that this patch will conflict with the recent Eric's one (added in
> CC:), he may want to rediff his Type3 changes in case this patch gets
> in.
I had no feedback at all on the patch so I have no idea if this will go
in or not, but since Eric's patch was accepted into -mm I rediffed the
patch in order to ease the testing (in case someone is willing to test
it).
Stelian.
Mark some IO regions reserved on Sony Vaio laptops because the sonypi
driver will need them later, and we don't want another driver to reserve
them before the sonypi driver starts.
Signed-off-by: Stelian Pop <ste...@popies.net>
arch/i386/pci/i386.c | 42 +++++++++++++++++++++++++++++
drivers/char/sonypi.c | 71 ++++++++++----------------------------------------
2 files changed, 57 insertions(+), 56 deletions(-)
Index: linux-2.6.git/arch/i386/pci/i386.c
===================================================================
--- linux-2.6.git.orig/arch/i386/pci/i386.c 2005-08-02 10:21:58.000000000 +0200
+++ linux-2.6.git/arch/i386/pci/i386.c 2005-08-02 10:28:26.000000000 +0200
@@ -30,6 +30,7 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/errno.h>
+#include <linux/dmi.h>
#include "pci.h"
@@ -167,12 +168,53 @@
}
}
+/*
+ * Reserve IO ports used later by the sonypi driver, or they may got used
+ * by other devices.
+ */
+static int __init sonyvaio_reserve_ioports(struct dmi_system_id *d)
+{
+ /* IO ports for 'type1' device */
+ if (!request_region(0x10c0, 0x08, "Sony Programable I/O Type1 Device"))
+ printk(KERN_ERR "Sony Vaio: cannot reserve Type1 IO region\n");
+
+ /* IO ports for 'type2' and 'type3' devices */
--- linux-2.6.git.orig/drivers/char/sonypi.c 2005-08-02 10:22:18.000000000 +0200
+++ linux-2.6.git/drivers/char/sonypi.c 2005-08-02 10:27:28.000000000 +0200
@@ -105,7 +105,9 @@
#define SONYPI_IRQ_SHIFT 22
#define SONYPI_TYPE1_BASE 0x50
#define SONYPI_G10A (SONYPI_TYPE1_BASE+0x14)
-#define SONYPI_TYPE1_REGION_SIZE 0x08
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE1_IOPORT1 0x10c0
+#define SONYPI_TYPE1_IOPORT2 0x10c4
#define SONYPI_TYPE1_EVTYPE_OFFSET 0x04
/* type2 series specifics */
@@ -113,13 +115,18 @@
#define SONYPI_SLOB 0x9c
#define SONYPI_SHIB 0x9d
#define SONYPI_TYPE2_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE2_IOPORT1 0x1080
+#define SONYPI_TYPE2_IOPORT2 0x1084
#define SONYPI_TYPE2_EVTYPE_OFFSET 0x12
/* type3 series specifics */
#define SONYPI_TYPE3_BASE 0x40
#define SONYPI_TYPE3_GID2 (SONYPI_TYPE3_BASE+0x48) /* 16 bits */
#define SONYPI_TYPE3_MISC (SONYPI_TYPE3_BASE+0x6d) /* 8 bits */
-#define SONYPI_TYPE3_REGION_SIZE 0x20
+/* those ports are reserved in arch/i386/pci/i386.c */
+#define SONYPI_TYPE3_IOPORT1 SONYPI_TYPE2_IOPORT1
+#define SONYPI_TYPE3_IOPORT2 SONYPI_TYPE2_IOPORT2
#define SONYPI_TYPE3_EVTYPE_OFFSET 0x12
/* battery / brightness addresses */
@@ -144,33 +151,6 @@
-/* same as in type 2 models */
-static struct sonypi_ioport_list *sonypi_type3_ioport_list =
- sonypi_type2_ioport_list;
-
/* The set of possible interrupts */
struct sonypi_irq_list {
u16 irq;
@@ -479,7 +459,6 @@
u16 bits;
u16 ioport1;
u16 ioport2;
- u16 region_size;
u16 evtype_offset;
int camera_power;
int bluetooth_power;
@@ -1206,7 +1185,6 @@
static int __devinit sonypi_probe(void)
{
int i, ret;
- struct sonypi_ioport_list *ioport_list;
struct sonypi_irq_list *irq_list;
struct pci_dev *pcidev;
@@ -1249,38 +1227,22 @@
if (sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE1) {
- ioport_list = sonypi_type1_ioport_list;
- sonypi_device.region_size = SONYPI_TYPE1_REGION_SIZE;
+ sonypi_device.ioport1 = SONYPI_TYPE1_IOPORT1;
+ sonypi_device.ioport2 = SONYPI_TYPE1_IOPORT2;
sonypi_device.evtype_offset = SONYPI_TYPE1_EVTYPE_OFFSET;
irq_list = sonypi_type1_irq_list;
} else if (sonypi_device.model == SONYPI_DEVICE_MODEL_TYPE2) {
- ioport_list = sonypi_type2_ioport_list;
- sonypi_device.region_size = SONYPI_TYPE2_REGION_SIZE;
+ sonypi_device.ioport1 = SONYPI_TYPE2_IOPORT1;
+ sonypi_device.ioport2 = SONYPI_TYPE2_IOPORT2;
sonypi_device.evtype_offset = SONYPI_TYPE2_EVTYPE_OFFSET;
irq_list = sonypi_type2_irq_list;
} else {
- ioport_list = sonypi_type3_ioport_list;
- sonypi_device.region_size = SONYPI_TYPE3_REGION_SIZE;
+ sonypi_device.ioport1 = SONYPI_TYPE3_IOPORT1;
+ sonypi_device.ioport2 = SONYPI_TYPE3_IOPORT2;
sonypi_device.evtype_offset = SONYPI_TYPE3_EVTYPE_OFFSET;
irq_list = sonypi_type3_irq_list;
}
- for (i = 0; ioport_list[i].port1; i++) {
- if (request_region(ioport_list[i].port1,
- sonypi_device.region_size,
- "Sony Programable I/O Device")) {
- /* get the ioport */
- sonypi_device.ioport1 = ioport_list[i].port1;
- sonypi_device.ioport2 = ioport_list[i].port2;
- break;
- }
- }
- if (!sonypi_device.ioport1) {
- printk(KERN_ERR "sonypi: request_region failed\n");
- ret = -ENODEV;
- goto out_reqreg;
- }
-
for (i = 0; irq_list[i].irq; i++) {
sonypi_device.irq = irq_list[i].irq;
@@ -1379,8 +1341,6 @@
input_unregister_device(&sonypi_device.input_jog_dev);
free_irq(sonypi_device.irq, sonypi_irq);
out_reqirq:
- release_region(sonypi_device.ioport1, sonypi_device.region_size);
-out_reqreg:
misc_deregister(&sonypi_misc_device);
out_miscreg:
if (pcidev)
@@ -1408,7 +1368,6 @@
Manuel Lauss
> Le lundi 01 ao??t 2005 ?? 16:37 +0200, Stelian Pop a ??crit :
>
> > > Also, it looks like sonypi really is pretty nasty to probe for, so it's
> > > not enough to just say "oh, it's a sony VAIO, let's reserve that region".
> > > Otherwise I'd just suggest adding a "dmi_check_system()" table to
> > > arch/i386/pci/i386.c, at the top of "pcibios_assign_resources()", and
> > > then you could just allocate things based on DMI information.
>
> > Since every Vaio laptop out there seems indeed to use only the first IO
> > port range in the list, we can de-nastyify the probe. And if we don't
> > even bother to check for Type1 vs. Type2 devices and we reserve both,
> > then it may be acceptable to do the above.
> >
> > See the attached patch below which does just that. This has NOT been
> > tested (only compile-tested), and moreover it has a high breakage
> > probability in case some Vaios cannot live with the fixed ioport choice.
> >
> > Note that this patch will conflict with the recent Eric's one (added in
> > CC:), he may want to rediff his Type3 changes in case this patch gets
> > in.
>
> I had no feedback at all on the patch so I have no idea if this will go
> in or not, but since Eric's patch was accepted into -mm I rediffed the
> patch in order to ease the testing (in case someone is willing to test
> it).
Does not work on -rc4-mm1. The IO-ports pre-reserved message appears,
though. The 2 io-regions are still located under the "CardBus #03"
device. Re-Applying
"revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it
work again.
--
Manuel Lauss
Ivan Kokshaysky
> Does not work on -rc4-mm1. The IO-ports pre-reserved message appears,
> though. The 2 io-regions are still located under the "CardBus #03"
> device. Re-Applying
> "revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it
> work again.
Does the patch in appended message fix that?
Ivan.
----- Forwarded message from Ivan Kokshaysky <i...@jurassic.park.msu.ru> -----
Date: Mon, 1 Aug 2005 11:22:45 +0400
From: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
To: Andrew Morton <ak...@osdl.org>
Cc: Tero Roponen <tean...@cc.jyu.fi>, jons...@gmail.com,
gre...@suse.de, linux-...@vger.kernel.org,
Mikael Pettersson <mi...@csd.uu.se>
Subject: Re: 2.6.14-rc4: dma_timer_expiry [was 2.6.13-rc2 hangs at boot]
User-Agent: Mutt/1.2.5i
In-Reply-To: <20050729023921...@osdl.org>; from ak...@osdl.org on Fri, Jul 29, 2005 at 02:39:21AM -0700
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on jurassic.park.msu.ru
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_00 autolearn=ham
version=2.64
X-Spam-Level:
On Fri, Jul 29, 2005 at 02:39:21AM -0700, Andrew Morton wrote:
> Tero Roponen <tean...@cc.jyu.fi> wrote:
> > My original report is here: http://lkml.org/lkml/2005/7/6/174
>
> I see. Ivan, do we know what's going on here?
Sort of. The 4K cardbus windows are working fine for non-x86
architectures where all IO resources are usually well known
and added to the resource tree properly.
However, on x86 there are sometimes "hidden" system IO port
ranges that aren't reported by BIOS, so the large (4K) cardbus
windows overlap these ranges.
Actually I don't like reducing CARDBUS_IO_SIZE to 256 bytes, because
we lose an ability to handle cards with built-in p2p bridges (which
require 4K for IO), plus it won't fix Sony VAIO problem.
Tero and Mikael, can you try this one-liner instead?
Ivan.
--- 2.6.13-rc4/include/asm-i386/pci.h Sun Jul 31 14:32:09 2005
+++ linux/include/asm-i386/pci.h Mon Aug 1 08:29:18 2005
@@ -18,7 +18,7 @@ extern unsigned int pcibios_assign_all_b
#define pcibios_scan_all_fns(a, b) 0
extern unsigned long pci_mem_start;
-#define PCIBIOS_MIN_IO 0x1000
+#define PCIBIOS_MIN_IO 0x2000
#define PCIBIOS_MIN_MEM (pci_mem_start)
#define PCIBIOS_MIN_CARDBUS_IO 0x4000
----- End forwarded message -----
Manuel Lauss
> On Tue, Aug 02, 2005 at 12:32:26PM +0200, Manuel Lauss wrote:
> > Does not work on -rc4-mm1. The IO-ports pre-reserved message appears,
> > though. The 2 io-regions are still located under the "CardBus #03"
> > device. Re-Applying
> > "revert-gregkh-pci-pci-assign-unassigned-resources.patch" makes it
> > work again.
>
> Does the patch in appended message fix that?
Indeed, it does fix it (vanilla -rc4-mm1 and your patch)
Thanks!
--
Manuel Lauss
Linus Torvalds
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote:
>
> Does the patch in appended message fix that?
The problem with this is that it only papers over the bug.
I don't mind trying to allocate at higher addresses per se: we used to
have the starting point be 0x4000 at some point, and that part is fine.
The problem is that this also screws us if somebody has a PCI bridge with
an IO window that is at a lower address than 0x2000 - now the PCI layer
will refuse to try to allocate within it, and you'll replace one bug by
another.
Linus
Ivan Kokshaysky
> The problem with this is that it only papers over the bug.
>
> I don't mind trying to allocate at higher addresses per se: we used to
> have the starting point be 0x4000 at some point, and that part is fine.
> The problem is that this also screws us if somebody has a PCI bridge with
> an IO window that is at a lower address than 0x2000 - now the PCI layer
> will refuse to try to allocate within it, and you'll replace one bug by
> another.
Right, and this hurts the cardbus as well...
But it should be pretty easy to learn the PCI layer to allocate above
PCIBIOS_MIN_IO _only_ when we allocate on the root bus.
Something like this (completely untested)?
Ivan.
--- linux/drivers/pci/setup-res.c.orig Fri Jun 17 23:48:29 2005
+++ linux/drivers/pci/setup-res.c Tue Aug 2 20:44:59 2005
@@ -113,11 +113,12 @@ int pci_assign_resource(struct pci_dev *
{
struct pci_bus *bus = dev->bus;
struct resource *res = dev->resource + resno;
- unsigned long size, min, align;
+ unsigned long size, min, align, min_io;
int ret;
+ min_io = (bus->self && !bus->self->transparent) ? 0 : PCIBIOS_MIN_IO;
size = res->end - res->start + 1;
- min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
+ min = (res->flags & IORESOURCE_IO) ? min_io : PCIBIOS_MIN_MEM;
/* The bridge resources are special, as their
size != alignment. Sizing routines return
required alignment in the "start" field. */
Linus Torvalds
On Tue, 2 Aug 2005, Ivan Kokshaysky wrote:
>
> Right, and this hurts the cardbus as well...
> But it should be pretty easy to learn the PCI layer to allocate above
> PCIBIOS_MIN_IO _only_ when we allocate on the root bus.
> Something like this (completely untested)?
I think you'd have to follow the "transparent" case down.. And even then
you'd have the half-transparent case to worry about it.
So I think it would be much easier to just make the change in
"pci_bus_alloc_resource()", and say that if the parent resource that we're
testing starts at some non-zero value, we just use that instead of "min"
when we call down to allocate_resource(). That gets it for MEM resources
too.
Something like the following (also _totally_ untested, but even simpler
than yours). It basically says: if the parent resource starts at non-zero,
we use that as the starting point for allocations, otherwise the passed-in
value.
That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000)
might be the ticket...
Linus
----
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -60,7 +60,9 @@ pci_bus_alloc_resource(struct pci_bus *b
continue;
/* Ok, try it out.. */
- ret = allocate_resource(r, res, size, min, -1, align,
+ ret = allocate_resource(r, res, size,
+ r->start ? : min,
+ -1, align,
alignf, alignf_data);
if (ret == 0)
break;
Ivan Kokshaysky
> So I think it would be much easier to just make the change in
> "pci_bus_alloc_resource()", and say that if the parent resource that we're
> testing starts at some non-zero value, we just use that instead of "min"
> when we call down to allocate_resource(). That gets it for MEM resources
> too.
Cool! I think it's the way to go.
> Something like the following (also _totally_ untested, but even simpler
> than yours). It basically says: if the parent resource starts at non-zero,
> we use that as the starting point for allocations, otherwise the passed-in
> value.
Tested on alpha. Initially I was concerned a bit about architectures
where resources _never_ start at zero (due to some specific bus to
resource conversions), but this change is just a no-op for them.
> That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000)
> might be the ticket...
Definitely 0x4000. Then we can get rid of PCIBIOS_MIN_CARDBUS_IO which
was introduced exactly for this reason, I guess.
Ivan.
Greg KH
> On Tue, Aug 02, 2005 at 10:11:40AM -0700, Linus Torvalds wrote:
> > So I think it would be much easier to just make the change in
> > "pci_bus_alloc_resource()", and say that if the parent resource that we're
> > testing starts at some non-zero value, we just use that instead of "min"
> > when we call down to allocate_resource(). That gets it for MEM resources
> > too.
>
> Cool! I think it's the way to go.
>
> > Something like the following (also _totally_ untested, but even simpler
> > than yours). It basically says: if the parent resource starts at non-zero,
> > we use that as the starting point for allocations, otherwise the passed-in
> > value.
>
> Tested on alpha. Initially I was concerned a bit about architectures
> where resources _never_ start at zero (due to some specific bus to
> resource conversions), but this change is just a no-op for them.
>
> > That, together with changing PCIBIOS_MIN_IO to 0x2000 (or even 0x4000)
> > might be the ticket...
>
> Definitely 0x4000. Then we can get rid of PCIBIOS_MIN_CARDBUS_IO which
> was introduced exactly for this reason, I guess.
Nice, care to make up a single patch with these two changes in it?
thanks,
greg k-h
Ivan Kokshaysky
> Nice, care to make up a single patch with these two changes in it?
Yep, I'll do it shortly, plus some minor additions as separate
patches.
Ivan.
Linus Torvalds
On Wed, 3 Aug 2005, Ivan Kokshaysky wrote:
>
> On Tue, Aug 02, 2005 at 02:21:44PM -0700, Greg KH wrote:
> > Nice, care to make up a single patch with these two changes in it?
>
> Yep, I'll do it shortly, plus some minor additions as separate
> patches.
Actually, since everybody seems to like the "ignore 'min' if we have a
known bus resource" patch, and it was already in my tree, I just committed
it.
But you don't need to split up any patches you've already prepared: I can
easily just edit away the part I already committed.
Linus
Ivan Kokshaysky
> But you don't need to split up any patches you've already prepared: I can
> easily just edit away the part I already committed.
OK, I keep your change here - mostly for Mikael, so he can try that ASAP.
There is a number of x86 laptops that have some non-PCI IO ports
in the 0x1000-0x1fff range, and it's quite hard to control the correct
order of resource allocation between PCI and other subsystems controlling
these ports. Especially with modular kernel. So just increase
PCIBIOS_MIN_IO to 0x4000 to prevent any new PCI resource allocations
in the problematic range (this limitation must apply _only_ to the
root bus resources - see Linus' change in pci_bus_alloc_resource).
As PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO are the same now on i386
and x86-64, we can remove the latter.
Signed-off-by: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
--- 2.6.13-rc5/drivers/pci/bus.c Wed Aug 3 00:11:42 2005
+++ linux/drivers/pci/bus.c Wed Aug 3 00:19:41 2005
@@ -60,7 +60,9 @@ pci_bus_alloc_resource(struct pci_bus *b
continue;
/* Ok, try it out.. */
- ret = allocate_resource(r, res, size, min, -1, align,
+ ret = allocate_resource(r, res, size,
+ r->start ? : min,
+ -1, align,
alignf, alignf_data);
if (ret == 0)
break;
--- 2.6.13-rc5/include/asm-i386/pci.h Wed Aug 3 00:11:55 2005
+++ linux/include/asm-i386/pci.h Wed Aug 3 02:51:00 2005
@@ -18,10 +18,8 @@ extern unsigned int pcibios_assign_all_b
#define pcibios_scan_all_fns(a, b) 0
extern unsigned long pci_mem_start;
-#define PCIBIOS_MIN_IO 0x1000
+#define PCIBIOS_MIN_IO 0x4000
#define PCIBIOS_MIN_MEM (pci_mem_start)
-
-#define PCIBIOS_MIN_CARDBUS_IO 0x4000
void pcibios_config_init(void);
struct pci_bus * pcibios_scan_root(int bus);
--- 2.6.13-rc5/include/asm-x86_64/pci.h Wed Aug 3 00:11:58 2005
+++ linux/include/asm-x86_64/pci.h Wed Aug 3 02:51:33 2005
@@ -22,10 +22,8 @@ extern unsigned int pcibios_assign_all_b
extern int no_iommu, force_iommu;
extern unsigned long pci_mem_start;
-#define PCIBIOS_MIN_IO 0x1000
+#define PCIBIOS_MIN_IO 0x4000
#define PCIBIOS_MIN_MEM (pci_mem_start)
-
-#define PCIBIOS_MIN_CARDBUS_IO 0x4000
void pcibios_config_init(void);
struct pci_bus * pcibios_scan_root(int bus);
Ivan Kokshaysky
motherboard resources to be allocated properly. So we need
to state 0x1000 (according to the comment) limit explicitely.
Signed-off-by: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
--- 2.5.13-rc5/drivers/acpi/motherboard.c Fri Jun 17 23:48:29 2005
+++ linux/drivers/acpi/motherboard.c Wed Aug 3 02:54:05 2005
@@ -43,7 +43,7 @@ ACPI_MODULE_NAME ("acpi_motherboard")
*/
#define IS_RESERVED_ADDR(base, len) \
(((len) > 0) && ((base) > 0) && ((base) + (len) < IO_SPACE_LIMIT) \
- && ((base) + (len) > PCIBIOS_MIN_IO))
+ && ((base) + (len) > 0x1000))
/*
* Clearing the flag (IORESOURCE_BUSY) allows drivers to use
Martin J. Bligh
--Andrew Morton <ak...@osdl.org> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
> "Martin J. Bligh" <mbl...@mbligh.org> wrote:
>>
>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>> identified earlier with the sched patches ...
>>
>> http://test.kernel.org/9398/debug/console.log
>
> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
>
>> Works with mainline still (including -rc4) ... hopefully those patches
>> aren't on their way upstream anytime soon ;-)
>
> Well can you identify the offending patch(es)? If so, I'll exterminate them.
>
>
>
scheduler-cache-hot-autodetect.patch, I think.
will double-check.
M.
Martin J. Bligh
> --Andrew Morton <ak...@osdl.org> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
>
>> "Martin J. Bligh" <mbl...@mbligh.org> wrote:
>>>
>>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>>> identified earlier with the sched patches ...
>>>
>>> http://test.kernel.org/9398/debug/console.log
>>
>> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
>>
>>> Works with mainline still (including -rc4) ... hopefully those patches
>>> aren't on their way upstream anytime soon ;-)
>>
>> Well can you identify the offending patch(es)? If so, I'll exterminate them.
>
> scheduler-cache-hot-autodetect.patch, I think.
>
> will double-check.
Yup, backing out that one patch definitely fixes it. There was an earlier
thread with Ingo about doing some possible debug on it, but to be honest,
I haven't had time to play much beyond the initial ideas we tried.
Christoph Lameter
addressses were not mappable via the page fault handler. This patch
inserts the pmd entry into the pgd as necessary if the pud level is
folded.
Signed-off-by: Christoph Lameter <chri...@lameter.com>
Index: linux-2.6.13-rc4/mm/memory.c
===================================================================
--- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:08:29.000000000 -0700
+++ linux-2.6.13-rc4/mm/memory.c 2005-08-03 17:15:22.000000000 -0700
@@ -2144,9 +2144,16 @@
*/
page_table_atomic_start(mm);
pgd = pgd_offset(mm, address);
-#ifndef __PAGETABLE_PUD_FOLDED
if (unlikely(pgd_none(*pgd))) {
+#ifdef __PAGETABLE_PUD_FOLDED
+ /* If the pud is folded then we need to insert a pmd entry into
+ * a pgd. pud_none(pgd) == 0 so the next if statement will never
+ * be taken
+ */
+ pmd_t *new;
+#else
pud_t *new;
+#endif
page_table_atomic_stop(mm);
new = pud_alloc_one(mm, address);
@@ -2158,7 +2165,6 @@
if (!pgd_test_and_populate(mm, pgd, new))
pud_free(new);
}
-#endif
pud = pud_offset(pgd, address);
if (unlikely(pud_none(*pud))) {
Index: linux-2.6.13-rc4/include/asm-generic/4level-fixup.h
===================================================================
--- linux-2.6.13-rc4.orig/include/asm-generic/4level-fixup.h 2005-08-03 17:06:01.000000000 -0700
+++ linux-2.6.13-rc4/include/asm-generic/4level-fixup.h 2005-08-03 17:09:38.000000000 -0700
@@ -27,6 +27,7 @@
#define pud_ERROR(pud) do { } while (0)
#define pud_clear(pud) pgd_clear(pud)
#define pud_populate pgd_populate
+#define pud_alloc_one pmd_alloc_one
#undef pud_free_tlb
#define pud_free_tlb(tlb, x) do { } while (0)
Richard Purdie
> Could you try the following patch? I think the problem was that higher
> addressses were not mappable via the page fault handler. This patch
> inserts the pmd entry into the pgd as necessary if the pud level is
> folded.
I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
still hung in memcpy as before and the cmpxchg_fail_flag_update just
increases...
Richard
Christoph Lameter
> On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > Could you try the following patch? I think the problem was that higher
> > addressses were not mappable via the page fault handler. This patch
> > inserts the pmd entry into the pgd as necessary if the pud level is
> > folded.
>
> I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
> still hung in memcpy as before and the cmpxchg_fail_flag_update just
> increases...
Is there some way you can give us more information about the problem?
Something that would allow us to determine where the thing is looping?
Richard Purdie
> On Thu, 4 Aug 2005, Richard Purdie wrote:
>
> > On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > > Could you try the following patch? I think the problem was that higher
> > > addressses were not mappable via the page fault handler. This patch
> > > inserts the pmd entry into the pgd as necessary if the pud level is
> > > folded.
> >
> > I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
> > still hung in memcpy as before and the cmpxchg_fail_flag_update just
> > increases...
>
> Is there some way you can give us more information about the problem?
> Something that would allow us to determine where the thing is looping?
I'm at a disadvantage here as the linux mm system is one area I've
avoided getting too deeply involved with so far. My knowledge is
therefore limited and I won't know what correct or incorrect behaviour
would look like.
We know the the failure case can be identified by the
cmpxchg_fail_flag_update condition being met. Can you provide me with a
patch to dump useful debugging information when that occurs?
Richard
Andrew Morton
>
> Moore, Robert schrieb:
>
> >+ ACPI-0287: *** Error: Region SystemMemory(0) has no handler
> >+ ACPI-0127: *** Error: acpi_load_tables: Could not load namespace:
> >AE_NOT_EXIST
> >+ ACPI-0136: *** Error: acpi_load_tables: Could not load tables:
> >
> >This looks like a nasty case where some executable code in the table is
> >attempting to access a SystemMemory operation region before any OpRegion
> >handlers are initialized.
> >
> >We certainly want to see the output of acpidump to attempt to diagnose
> >and/or reproduce the problem.
> >
> >Bob
> >
> >
> >
> >
> Sorry for double post.
>
> With this mail I hand over the acpidump output with the pmtools
> Andrew pointed me to.
>
> And a dmesg output with CONFIG_KALLSYMS=y.
>
>
> I attached them in bz2 format, because of the length.
>
> I hope we find the problem.
>
Michael, I'm assuming that a) this problem remains in those -mm kernels
which include git-acpi.patch and that b) the problems are not present in
2.6.13-rc5 or 2.6.13-rc6, yes?
So I think we have a bug in git-acpi.patch?
If that's all correct then can you please test the next -mm (which will
include git-acpi.patch - the most recent -mm did not) and if the bug's
still there can you raise a bugzilla.kernel.org entry for it?
We seem to have a handful of bug reports against the -mm acpi patch.
Thanks.
Michael Thonke
Hello Andrew,
> Andrew Morton wrote:
> Michael, I'm assuming that a) this problem remains in those -mm kernels
> which include git-acpi.patch and that b) the problems are not present in
> 2.6.13-rc5 or 2.6.13-rc6, yes?
>
a.) I don't have any problems in 2.6.13-rc5-git[1-3] and 2.6.13-rc4-mm1
they are working quite fantastic.
Good work :-)
> So I think we have a bug in git-acpi.patch?
>
I reverted them and left them in..no problems with kernels I said above.
Again good work :-)
> If that's all correct then can you please test the next -mm (which will
> include git-acpi.patch - the most recent -mm did not) and if the bug's
> still there can you raise a bugzilla.kernel.org entry for it?
>
I would, but the motherboard is dropped from my hardware test approval.
Maybe I can get it back to test again
if it helps to solve some acpi issues.
> We seem to have a handful of bug reports against the -mm acpi patch.
>
Well, I noticed that there are a lots of bugs and I'm willing to find
search and reproduce them.
> Thanks.
I have to say thanks for the great help/feedback.
Greets and
Best regards
--
_Michael Thonke
IT-Systemintegrator /
System- and Softwareanalyist
Christoph Lameter
> I'm at a disadvantage here as the linux mm system is one area I've
> avoided getting too deeply involved with so far. My knowledge is
> therefore limited and I won't know what correct or incorrect behaviour
> would look like.
>
> We know the the failure case can be identified by the
> cmpxchg_fail_flag_update condition being met. Can you provide me with a
> patch to dump useful debugging information when that occurs?
Well yes simply print out the information available in that context.
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-03 17:02:29.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-05 08:17:14.000000000 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT "cmpxchg fail mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx\n",
+ mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry));
inc_page_state(cmpxchg_fail_flag_update);
Richard Purdie
> On Thu, 4 Aug 2005, Richard Purdie wrote:
> >
> > We know the the failure case can be identified by the
> > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > patch to dump useful debugging information when that occurs?
>
> Well yes simply print out the information available in that context.
>
> + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry));
Ok, this results in an infinite loop of one message with no change to
the numbers:
cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077
Richard
Martin J. Bligh
--"Martin J. Bligh" <mbl...@mbligh.org> wrote (on Tuesday, August 02, 2005 21:21:30 -0700):
> --"Martin J. Bligh" <mbl...@mbligh.org> wrote (on Tuesday, August 02, 2005 18:17:33 -0700):
>> --Andrew Morton <ak...@osdl.org> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
>>
>>> "Martin J. Bligh" <mbl...@mbligh.org> wrote:
>>>>
>>>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>>>> identified earlier with the sched patches ...
>>>>
>>>> http://test.kernel.org/9398/debug/console.log
>>>
>>> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
>>>
>>>> Works with mainline still (including -rc4) ... hopefully those patches
>>>> aren't on their way upstream anytime soon ;-)
>>>
>>> Well can you identify the offending patch(es)? If so, I'll exterminate them.
>>
>> scheduler-cache-hot-autodetect.patch, I think.
>>
>> will double-check.
>
> Yup, backing out that one patch definitely fixes it. There was an earlier
> thread with Ingo about doing some possible debug on it, but to be honest,
> I haven't had time to play much beyond the initial ideas we tried.
Still broken in 2.6.13-rc5-mm1, any chance you could back this one out
until it gets fixed? that way I can still test with that platform (plus
it'll stop it from getting accidentally merged ;-))
Thanks,
Christoph Lameter
> > > We know the the failure case can be identified by the
> > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > patch to dump useful debugging information when that occurs?
>
> Ok, this results in an infinite loop of one message with no change to
> the numbers:
>
> cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
> ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077
Ok. So we cannot set the dirty bit.
Here is a patch that also prints the pte status immediately before
ptep_cmpxchg. I guess this will show that dirty bit is already set.
Does the ARM have some hardware capability to set dirty bits?
Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-05 08:38:10.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-08 09:46:12.000000000 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT "cmpxchg fail fault mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n",
+ mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry), *pte);
inc_page_state(cmpxchg_fail_flag_update);
Christoph Lameter
> ARM doesn't have cmpxchg nor does it have hardware access nor dirty
> bits. They're simulated in software.
Even the cmpxchg is simulated.
> What's the problem you're trying to solve?
A hang when starting X on ARM with rc4-mm1 which contains the page fault
patches. But I have no access to the platform.
Russell King
> On Sun, 7 Aug 2005, Richard Purdie wrote:
>
> > > > We know the the failure case can be identified by the
> > > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > > patch to dump useful debugging information when that occurs?
> >
> > Ok, this results in an infinite loop of one message with no change to
> > the numbers:
> >
> > cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
> > ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077
>
> Ok. So we cannot set the dirty bit.
>
> Here is a patch that also prints the pte status immediately before
> ptep_cmpxchg. I guess this will show that dirty bit is already set.
>
> Does the ARM have some hardware capability to set dirty bits?
ARM doesn't have cmpxchg nor does it have hardware access nor dirty
bits. They're simulated in software.
What's the problem you're trying to solve?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Richard Purdie
> Ok. So we cannot set the dirty bit.
>
> Here is a patch that also prints the pte status immediately before
> ptep_cmpxchg. I guess this will show that dirty bit is already set.
>
> Does the ARM have some hardware capability to set dirty bits?
>
> + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry), *pte);
Ok, this results in:
cmpxchg fail fault mm=c39fc4e0 vma=c2a37bcc addr=4025f000 write=2048
ptep=c2fc197c pmd=c2b91008 entry=88000f7 new=8800077 current=8800077
I'm beginning to understand this code a bit more so I'll see if I can
work out anything myself as well...
Richard
Richard Purdie
cmpxchg fail fault mm=c3945b20 vma=c304ad84 addr=402cb000 write=2048
ptep=c2af5b2c pmd=c2bc5008 entry=886c0f7 new=886c077 current=886c077
Note the Dirty bit is set on entry and not new where it probably should
be...
ptep_cmpxchg(mm, address, pte, entry, new_entry)
This will compare "current"(886c077) with "entry"(886c0f7) which are not
equal and the whole thing therefore correctly fails leading to the loop.
The following patch (against -mm) cleared the problem up but I'm not
sure how correct it is:
Index: linux-2.6.12/mm/memory.c
===================================================================
--- linux-2.6.12.orig/mm/memory.c 2005-08-08 23:03:45.000000000 +0100
+++ linux-2.6.12/mm/memory.c 2005-08-08 23:04:02.000000000 +0100
@@ -2046,7 +2046,7 @@
return do_wp_page(mm, vma, address, pte, pmd, entry);
#endif
}
- entry = pte_mkdirty(entry);
+ new_entry = pte_mkdirty(entry);
}
/*
Christoph Lameter
> The following patch (against -mm) cleared the problem up but I'm not
> sure how correct it is:
Almost. The new entry needs to be made dirty. new_entry is already made
young. entry is not.
---
Set dirty bit correctly in handle_pte_fault
new_entry is used for the new pte entry. handle_mm_fault must dirty
new_entry and not "entry". entry is only used for comparison. The current
version does not set the dirty bit.
Signed-off-by: Christoph Lameter <clam...@sgi.com>
Index: linux-2.6.13-rc4/mm/memory.c
===================================================================
--- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:15:22.000000000 -0700
+++ linux-2.6.13-rc4/mm/memory.c 2005-08-08 17:54:53.000000000 -0700
@@ -2091,7 +2091,7 @@
return do_wp_page(mm, vma, address, pte, pmd, entry);
#endif
}
- entry = pte_mkdirty(entry);
+ new_entry = pte_mkdirty(new_entry);
Martin J. Bligh
I spoke too soon.
It's now broken in both -mm3 and -git
Some scsi problem on one of hte power boxes:
http://test.kernel.org/12729/debug/console.log
Attached scsi disk sdb at scsi0, channel 0, id 9, lun 0
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
sdc: Spinning up disk....<6> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
( ... repeated forever)
2.6.13-git11 worked.
Anton Blanchard
Hi,
> Heh, when I said "wheeeeeee - it all works" (with flip fixes) ...
> I spoke too soon.
>
> It's now broken in both -mm3 and -git
> Some scsi problem on one of hte power boxes:
>
> http://test.kernel.org/12729/debug/console.log
>
> Attached scsi disk sdb at scsi0, channel 0, id 9, lun 0
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> sdc: Spinning up disk....<6> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
> target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns, offset 31)
Try this dodgy workaround.
Anton
Index: build/drivers/scsi/scsi_lib.c
===================================================================
--- build.orig/drivers/scsi/scsi_lib.c 2005-09-14 18:23:34.000000000 +1000
+++ build/drivers/scsi/scsi_lib.c 2005-09-14 18:27:33.000000000 +1000
@@ -188,7 +188,7 @@
* function. The SCSI request function detects the blocked condition
* and plugs the queue appropriately.
*/
- scsi_unprep_request(req);
+ //scsi_unprep_request(req);
spin_lock_irqsave(q->queue_lock, flags);
blk_requeue_request(q, req);
spin_unlock_irqrestore(q->queue_lock, flags);