* 2.6.13-rc3-mm3
@ 2005-07-28 9:58 Andrew Morton
2005-07-28 10:44 ` [-mm patch] fix MTRR compilation with SMP=n Adrian Bunk
` (13 more replies)
0 siblings, 14 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-28 9:58 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* [-mm patch] fix MTRR compilation with SMP=n
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-28 10:44 ` Adrian Bunk
2005-07-28 17:11 ` 2.6.13-rc3-mm3 Christoph Lameter
` (12 subsequent siblings)
13 siblings, 0 replies; 94+ messages in thread
From: Adrian Bunk @ 2005-07-28 10:44 UTC (permalink / raw)
To: Andrew Morton, Richard Henderson, rgooch; +Cc: linux-kernel
On Thu, Jul 28, 2005 at 02:58:40AM -0700, Andrew Morton wrote:
>...
> 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 <bunk@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);
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 10:44 ` [-mm patch] fix MTRR compilation with SMP=n Adrian Bunk
@ 2005-07-28 17:11 ` Christoph Lameter
2005-07-28 19:52 ` 2.6.13-rc3-mm3 Russell King
2005-07-28 19:11 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
` (11 subsequent siblings)
13 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-07-28 17:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Thu, 28 Jul 2005, Andrew Morton wrote:
> 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 10:44 ` [-mm patch] fix MTRR compilation with SMP=n Adrian Bunk
2005-07-28 17:11 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-07-28 19:11 ` Rafael J. Wysocki
2005-07-28 19:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 20:34 ` 2.6.13-rc3-mm3 Adrian Bunk
` (10 subsequent siblings)
13 siblings, 1 reply; 94+ messages in thread
From: Rafael J. Wysocki @ 2005-07-28 19:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Andi Kleen
On Thursday, 28 of July 2005 11:58, 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.
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 <rjw@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();
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 19:11 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
@ 2005-07-28 19:16 ` Andrew Morton
2005-07-28 21:40 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
0 siblings, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-28 19:16 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, ak
"Rafael J. Wysocki" <rjw@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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 17:11 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-07-28 19:52 ` Russell King
2005-07-28 20:06 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Russell King @ 2005-07-28 19:52 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
On Thu, Jul 28, 2005 at 10:11:18AM -0700, Christoph Lameter wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 19:52 ` 2.6.13-rc3-mm3 Russell King
@ 2005-07-28 20:06 ` Christoph Lameter
0 siblings, 0 replies; 94+ messages in thread
From: Christoph Lameter @ 2005-07-28 20:06 UTC (permalink / raw)
To: Russell King; +Cc: Andrew Morton, linux-kernel
On Thu, 28 Jul 2005, Russell King wrote:
> 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))) {
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 22:09 ` 2.6.13-rc3-mm3 Michael Thonke
@ 2005-07-28 20:15 ` Andrew Morton
2005-07-28 20:56 ` 2.6.13-rc3-mm3 Nick Sillik
2005-07-28 20:29 ` 2.6.13-rc3-mm3 Adrian Bunk
1 sibling, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-28 20:15 UTC (permalink / raw)
To: Michael Thonke; +Cc: linux-kernel
Michael Thonke <iogl64nx@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'.
>
> 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 22:09 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 20:15 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-28 20:29 ` Adrian Bunk
1 sibling, 0 replies; 94+ messages in thread
From: Adrian Bunk @ 2005-07-28 20:29 UTC (permalink / raw)
To: Michael Thonke; +Cc: Andrew Morton, linux-kernel
On Thu, Jul 28, 2005 at 10:09:57PM +0000, Michael Thonke 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?
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (2 preceding siblings ...)
2005-07-28 19:11 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
@ 2005-07-28 20:34 ` Adrian Bunk
2005-07-28 22:09 ` 2.6.13-rc3-mm3 Michael Thonke
` (9 subsequent siblings)
13 siblings, 0 replies; 94+ messages in thread
From: Adrian Bunk @ 2005-07-28 20:34 UTC (permalink / raw)
To: Andrew Morton, Tony Luck; +Cc: linux-kernel, James Bottomley, andrew.vasquez
On Thu, Jul 28, 2005 at 02:58:40AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.13-rc3-mm2:
>...
> +qla2xxx-mark-dependency-on-fw_loader.patch
>
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 20:15 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-28 20:56 ` Nick Sillik
2005-07-28 23:16 ` 2.6.13-rc3-mm3 Michael Thonke
0 siblings, 1 reply; 94+ messages in thread
From: Nick Sillik @ 2005-07-28 20:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michael Thonke, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
Andrew Morton wrote:
> Michael Thonke <iogl64nx@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.sillik@temple.edu>
[-- Attachment #2: reiser_node40_wundef.patch --]
[-- Type: text/plain, Size: 523 bytes --]
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);
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 19:16 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-28 21:40 ` Rafael J. Wysocki
2005-07-28 23:31 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 7:06 ` 2.6.13-rc3-mm3 Matthias Urlichs
0 siblings, 2 replies; 94+ messages in thread
From: Rafael J. Wysocki @ 2005-07-28 21:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ak
On Thursday, 28 of July 2005 21:16, Andrew Morton wrote:
>
> "Rafael J. Wysocki" <rjw@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"
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 23:29 ` 2.6.13-rc3-mm3 Michael Thonke
@ 2005-07-28 22:02 ` Dirk
2005-07-28 23:46 ` 2.6.13-rc3-mm3 Andrew Morton
1 sibling, 0 replies; 94+ messages in thread
From: Dirk @ 2005-07-28 22:02 UTC (permalink / raw)
To: Michael Thonke; +Cc: Andrew Morton, linux-kernel
Michael Thonke wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (3 preceding siblings ...)
2005-07-28 20:34 ` 2.6.13-rc3-mm3 Adrian Bunk
@ 2005-07-28 22:09 ` Michael Thonke
2005-07-28 20:15 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 20:29 ` 2.6.13-rc3-mm3 Adrian Bunk
2005-07-28 23:29 ` 2.6.13-rc3-mm3 Michael Thonke
` (8 subsequent siblings)
13 siblings, 2 replies; 94+ messages in thread
From: Michael Thonke @ 2005-07-28 22:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 20:56 ` 2.6.13-rc3-mm3 Nick Sillik
@ 2005-07-28 23:16 ` Michael Thonke
0 siblings, 0 replies; 94+ messages in thread
From: Michael Thonke @ 2005-07-28 23:16 UTC (permalink / raw)
To: Nick Sillik; +Cc: Andrew Morton, linux-kernel
Nick Sillik schrieb:
> Andrew Morton wrote:
>
>> Michael Thonke <iogl64nx@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.sillik@temple.edu>
>
>------------------------------------------------------------------------
>
>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 :-)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (4 preceding siblings ...)
2005-07-28 22:09 ` 2.6.13-rc3-mm3 Michael Thonke
@ 2005-07-28 23:29 ` Michael Thonke
2005-07-28 22:02 ` 2.6.13-rc3-mm3 Dirk
2005-07-28 23:46 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 5:58 ` 2.6.13-rc3-mm3 Martin J. Bligh
` (7 subsequent siblings)
13 siblings, 2 replies; 94+ messages in thread
From: Michael Thonke @ 2005-07-28 23:29 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 21:40 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
@ 2005-07-28 23:31 ` Andrew Morton
2005-07-29 7:06 ` 2.6.13-rc3-mm3 Matthias Urlichs
1 sibling, 0 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-28 23:31 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-kernel, ak
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> 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 ;)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 23:29 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 22:02 ` 2.6.13-rc3-mm3 Dirk
@ 2005-07-28 23:46 ` Andrew Morton
2005-07-29 15:48 ` 2.6.13-rc3-mm3 Michael Thonke
1 sibling, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-28 23:46 UTC (permalink / raw)
To: Michael Thonke; +Cc: linux-kernel
Michael Thonke <iogl64nx@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 ;)
> 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (5 preceding siblings ...)
2005-07-28 23:29 ` 2.6.13-rc3-mm3 Michael Thonke
@ 2005-07-29 5:58 ` Martin J. Bligh
2005-07-29 6:08 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 6:01 ` 2.6.13-rc3-mm3 Martin J. Bligh
` (6 subsequent siblings)
13 siblings, 1 reply; 94+ messages in thread
From: Martin J. Bligh @ 2005-07-29 5:58 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
> - 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (6 preceding siblings ...)
2005-07-29 5:58 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-07-29 6:01 ` Martin J. Bligh
2005-07-29 6:10 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 6:02 ` 2.6.13-rc3-mm3 Martin J. Bligh
` (5 subsequent siblings)
13 siblings, 1 reply; 94+ messages in thread
From: Martin J. Bligh @ 2005-07-29 6:01 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
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
Works with mainline still (including -rc4) ... hopefully those patches
aren't on their way upstream anytime soon ;-)
M.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (7 preceding siblings ...)
2005-07-29 6:01 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-07-29 6:02 ` Martin J. Bligh
2005-07-29 23:05 ` 2.6.13-rc3-mm3 Khalid Aziz
` (4 subsequent siblings)
13 siblings, 0 replies; 94+ messages in thread
From: Martin J. Bligh @ 2005-07-29 6:02 UTC (permalink / raw)
To: Andrew Morton, linux-kernel
OK, and one last one ... on a more postitive note. rc3-mm3 does indeed fix
the problems crashing on boot I was having on PPC64 with -rc3-mm2. I'll
close the bugzilla bug.
Thanks!
M.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 5:58 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-07-29 6:08 ` Andrew Morton
2005-07-29 15:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
0 siblings, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-29 6:08 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linux-kernel
"Martin J. Bligh" <mbligh@mbligh.org> wrote:
>
>
> > - 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 <ebiederm@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 <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@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);
_
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 6:01 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-07-29 6:10 ` Andrew Morton
2005-08-03 1:17 ` 2.6.13-rc3-mm3 Martin J. Bligh
0 siblings, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-29 6:10 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linux-kernel
"Martin J. Bligh" <mbligh@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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 21:40 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
2005-07-28 23:31 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-29 7:06 ` Matthias Urlichs
2005-07-29 9:27 ` 2.6.13-rc3-mm3 Andrew Morton
1 sibling, 1 reply; 94+ messages in thread
From: Matthias Urlichs @ 2005-07-29 7:06 UTC (permalink / raw)
To: linux-kernel
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.
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 | smurf@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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 7:06 ` 2.6.13-rc3-mm3 Matthias Urlichs
@ 2005-07-29 9:27 ` Andrew Morton
2005-07-29 12:01 ` 2.6.13-rc3-mm3 Matthias Urlichs
2005-07-29 14:12 ` Regression hunting with git (was: Re: 2.6.13-rc3-mm3) Matthias Urlichs
0 siblings, 2 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-29 9:27 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: linux-kernel
Matthias Urlichs <smurf@smurf.noris.de> wrote:
>
> 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?
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 9:27 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-29 12:01 ` Matthias Urlichs
2005-07-29 14:12 ` Regression hunting with git (was: Re: 2.6.13-rc3-mm3) Matthias Urlichs
1 sibling, 0 replies; 94+ messages in thread
From: Matthias Urlichs @ 2005-07-29 12:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi,
Andrew Morton:
> Matthias Urlichs <smurf@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 | smurf@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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Regression hunting with git (was: Re: 2.6.13-rc3-mm3)
2005-07-29 9:27 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 12:01 ` 2.6.13-rc3-mm3 Matthias Urlichs
@ 2005-07-29 14:12 ` Matthias Urlichs
1 sibling, 0 replies; 94+ messages in thread
From: Matthias Urlichs @ 2005-07-29 14:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
Hi,
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 | smurf@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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 6:08 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-29 15:21 ` Martin J. Bligh
2005-07-29 16:15 ` 2.6.13-rc3-mm3 Eric W. Biederman
0 siblings, 1 reply; 94+ messages in thread
From: Martin J. Bligh @ 2005-07-29 15:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ebiederm
>> > - 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 <ebiederm@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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 23:46 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-29 15:48 ` Michael Thonke
2005-07-29 19:33 ` 2.6.13-rc3-mm3 Andrew Morton
0 siblings, 1 reply; 94+ messages in thread
From: Michael Thonke @ 2005-07-29 15:48 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michael Thonke, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]
Andrew Morton schrieb:
> Michael Thonke <iogl64nx@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?
>
>> 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?
Yes and mm1 it's a wide problem as I found many posts on ALSA Forums
But the big problem behind is...after it oops
My Linux Raid (md) goes bad then..at reboot it gives me more oops and
all changes on FS (reiser4) lost..and if I wouldn't use snd-hda-intel as
modul the hole system hung at boot.
>
>> 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.
Mh I tried but my system freezes on boot then. And screen leaves blank.
>
Thank you Andrew and the other for the great help up to here.
Greets
Best regards
Michael
[-- Attachment #2: dmesg-mm1-mm3.diif --]
[-- Type: text/plain, Size: 13827 bytes --]
--- dmesg.mm1 2005-07-29 13:47:58.878442480 +0000
+++ dmesg.mm3 2005-07-29 13:54:03.272355896 +0000
@@ -1,43 +1,13 @@
-Linux version 2.6.13-rc3-mm1pm (root@ioGL64NX_32) (gcc-Version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)) #1 PREEMPT Fri Jul 29 13:34:49 Local time zone must be set--see
-BIOS-provided physical RAM map:
- BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
- BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
- BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
- BIOS-e820: 0000000000100000 - 000000003ffb0000 (usable)
- BIOS-e820: 000000003ffb0000 - 000000003ffbe000 (ACPI data)
- BIOS-e820: 000000003ffbe000 - 000000003fff0000 (ACPI NVS)
- BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
- BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
-127MB HIGHMEM available.
-896MB LOWMEM available.
-found SMP MP-table at 000ff780
-On node 0 totalpages: 262064
- DMA zone: 4096 pages, LIFO batch:1
- Normal zone: 225280 pages, LIFO batch:31
- HighMem zone: 32688 pages, LIFO batch:15
-DMI 2.3 present.
-Intel MultiProcessor Specification v1.1
- Virtual Wire compatibility mode.
-OEM ID: INTEL Product ID: APIC at: 0xFEE00000
-Processor #0 6:13 APIC version 20
-I/O APIC #1 Version 32 at 0xFEC00000.
-Enabling APIC mode: Flat. Using 1 I/O APICs
-Processors: 1
-Allocating PCI resources starting at 40000000 (gap: 40000000:bfb80000)
-Built 1 zonelists
-mapped APIC to ffffd000 (fee00000)
-mapped IOAPIC to ffffc000 (fec00000)
-Initializing CPU#0
-Kernel command line: root=/dev/md1 vga=794 quiet
+ormance
PID hash table entries: 4096 (order: 12, 65536 bytes)
-Detected 1605.958 MHz processor.
-Using tsc for high-res timesource
+Detected 1605.994 MHz processor.
+Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 1034508k/1048256k available (2702k kernel code, 12980k reserved, 839k data, 168k init, 130752k highmem)
+Memory: 1034260k/1048256k available (3050k kernel code, 13228k reserved, 670k data, 200k init, 130752k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
-Calibrating delay using timer specific routine.. 3214.33 BogoMIPS (lpj=1607165)
+Calibrating delay using timer specific routine.. 3215.31 BogoMIPS (lpj=1607658)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
@@ -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.
+Linux Plug and Play Support v0.97 (c) Adam Belay
+pnp: PnP ACPI: disabled
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
@@ -67,31 +45,70 @@
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
-PCI->APIC IRQ transform: 0000:00:01.0[A] -> IRQ 129
-PCI->APIC IRQ transform: 0000:00:1c.0[A] -> IRQ 129
-PCI->APIC IRQ transform: 0000:00:1c.1[B] -> IRQ 137
-PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 161
-PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 153
-PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 145
-PCI->APIC IRQ transform: 0000:00:1d.3[D] -> IRQ 129
-PCI->APIC IRQ transform: 0000:00:1d.7[A] -> IRQ 161
-PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 145
-PCI->APIC IRQ transform: 0000:00:1f.2[B] -> IRQ 153
-PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 153
-PCI->APIC IRQ transform: 0000:04:00.0[A] -> IRQ 129
-PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 137
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 4!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI BIOS passed nonexistent PCI bus 2!
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: Bridge: 0000:00:01.0
+ IO window: e000-efff
+ MEM window: d2f00000-d7ffffff
+ PREFETCH window: d8000000-dfffffff
+PCI: Bridge: 0000:00:1c.0
+ IO window: d000-dfff
+ MEM window: disabled.
+ PREFETCH window: disabled.
+PCI: Bridge: 0000:00:1c.1
+ IO window: c000-cfff
+ MEM window: d2e00000-d2efffff
+ PREFETCH window: 40000000-400fffff
+PCI: Bridge: 0000:00:1e.0
+ IO window: b000-bfff
+ MEM window: disabled.
+ PREFETCH window: disabled.
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: No IRQ known for interrupt pin A of device 0000:00:01.0. Probably buggy MP table.
+PCI: Setting latency timer of device 0000:00:01.0 to 64
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: No IRQ known for interrupt pin A of device 0000:00:1c.0. Probably buggy MP table.
+PCI: Setting latency timer of device 0000:00:1c.0 to 64
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: No IRQ known for interrupt pin B of device 0000:00:1c.1. Probably buggy MP table.
+PCI: Setting latency timer of device 0000:00:1c.1 to 64
+PCI: Setting latency timer of device 0000:00:1e.0 to 64
Machine check exception polling timer started.
+apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
highmem bounce pool size: 64 pages
fuse init (API version 7.1)
Initializing Cryptographic API
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: No IRQ known for interrupt pin A of device 0000:00:01.0. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:01.0 to 64
+pcie_portdrv_probe->Dev[2581:8086] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: No IRQ known for interrupt pin A of device 0000:00:1c.0. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:1c.0 to 64
+pcie_portdrv_probe->Dev[2660:8086] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
+PCI BIOS passed nonexistent PCI bus 0!
+PCI: No IRQ known for interrupt pin B of device 0000:00:1c.1. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:1c.1 to 64
+pcie_portdrv_probe->Dev[2662:8086] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
@@ -100,6 +117,7 @@
vesafb: protected mode interface info at c000:d620
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
+vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
fb1: Virtual frame buffer device, using 1024K of video memory
@@ -115,7 +133,7 @@
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 2 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
-ub: sizeof ub_scsi_cmd 68 ub_dev 2384 ub_lun 140
+ub: sizeof ub_scsi_cmd 68 ub_dev 2388 ub_lun 140
usbcore: registered new driver ub
sk98lin: Network Device Driver v8.23.1.3
(C)Copyright 1999-2005 Marvell(R).
@@ -126,6 +144,7 @@
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
+PCI BIOS passed nonexistent PCI bus 0!
ICH6: chipset revision 5
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
@@ -141,8 +160,8 @@
libata version 1.11 loaded.
ata_piix version 1.03
PCI: Setting latency timer of device 0000:00:1f.2 to 64
-ata1: SATA max UDMA/133 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 153
-ata2: SATA max UDMA/133 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 153
+ata1: SATA max UDMA/133 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 3
+ata2: SATA max UDMA/133 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 3
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata1: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata1: dev 0 configured for UDMA/133
@@ -171,39 +190,39 @@
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
usbmon: debugs is not available
PCI: Setting latency timer of device 0000:00:1d.7 to 64
-ehci_hcd 0000:00:1d.7: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller
+ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: BIOS handoff failed (104, 01010001)
ehci_hcd 0000:00:1d.7: continuing after BIOS bug...
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
-ehci_hcd 0000:00:1d.7: irq 161, io mem 0xd2dffc00
+ehci_hcd 0000:00:1d.7: irq 11, io mem 0xd2dffc00
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.3
PCI: Setting latency timer of device 0000:00:1d.0 to 64
-uhci_hcd 0000:00:1d.0: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1
+uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
-uhci_hcd 0000:00:1d.0: irq 161, io base 0x00009880
+uhci_hcd 0000:00:1d.0: irq 11, io base 0x00009880
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.1 to 64
-uhci_hcd 0000:00:1d.1: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2
+uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
-uhci_hcd 0000:00:1d.1: irq 153, io base 0x00009c00
+uhci_hcd 0000:00:1d.1: irq 3, io base 0x00009c00
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.2 to 64
-uhci_hcd 0000:00:1d.2: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3
+uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
-uhci_hcd 0000:00:1d.2: irq 145, io base 0x0000a000
+uhci_hcd 0000:00:1d.2: irq 5, io base 0x0000a000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.3 to 64
-uhci_hcd 0000:00:1d.3: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4
+uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
-uhci_hcd 0000:00:1d.3: irq 129, io base 0x0000a080
+uhci_hcd 0000:00:1d.3: irq 10, io base 0x0000a080
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
@@ -213,16 +232,28 @@
usb 2-2: new low speed USB device using uhci_hcd and address 3
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
-usb 4-1: new full speed USB device using uhci_hcd and address 2
input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Genius NetScroll+Mini Traveler] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
+usb 4-1: new full speed USB device using uhci_hcd and address 2
+usbcore: registered new driver usbserial
+drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
+usbcore: registered new driver usbserial_generic
+drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
+drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
+pl2303 4-1:1.0: PL-2303 converter detected
+usb 4-1: PL-2303 converter now attached to ttyUSB0
+usbcore: registered new driver pl2303
+drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.12
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
+Advanced Linux Sound Architecture Driver Version 1.0.9 (Sun May 29 07:31:02 2005 UTC).
+ALSA device list:
+ No soundcards found.
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
@@ -309,7 +340,7 @@
raid0 : Allocating 4 bytes for hash.
md: ... autorun DONE.
VFS: Mounted root (reiser4 filesystem) readonly.
-Freeing unused kernel memory: 168k freed
+Freeing unused kernel memory: 200k freed
ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
ReiserFS: sdb1: using ordered data mode
ReiserFS: sdb1: journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
[-- Attachment #3: dmesg.mm1 --]
[-- Type: text/plain, Size: 14529 bytes --]
Linux version 2.6.13-rc3-mm1pm (root@ioGL64NX_32) (gcc-Version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)) #1 PREEMPT Fri Jul 29 13:34:49 Local time zone must be set--see
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003ffb0000 (usable)
BIOS-e820: 000000003ffb0000 - 000000003ffbe000 (ACPI data)
BIOS-e820: 000000003ffbe000 - 000000003fff0000 (ACPI NVS)
BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 262064
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:31
HighMem zone: 32688 pages, LIFO batch:15
DMI 2.3 present.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: INTEL Product ID: APIC at: 0xFEE00000
Processor #0 6:13 APIC version 20
I/O APIC #1 Version 32 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 40000000 (gap: 40000000:bfb80000)
Built 1 zonelists
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
Kernel command line: root=/dev/md1 vga=794 quiet
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1605.958 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034508k/1048256k available (2702k kernel code, 12980k reserved, 839k data, 168k init, 130752k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3214.33 BogoMIPS (lpj=1607165)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 00000000 00000000 00000000 00000180 00000000 00000000
CPU: After vendor identify, caps: afe9fbff 00000000 00000000 00000000 00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 00000000 00000000 00000040 00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 08
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
NET: Registered protocol family 16
PCI: Using configuration type 1
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:04:00.0
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:01.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1c.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1c.1[B] -> IRQ 137
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 153
PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 145
PCI->APIC IRQ transform: 0000:00:1d.3[D] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1d.7[A] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 145
PCI->APIC IRQ transform: 0000:00:1f.2[B] -> IRQ 153
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 153
PCI->APIC IRQ transform: 0000:04:00.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 137
Machine check exception polling timer started.
highmem bounce pool size: 64 pages
fuse init (API version 7.1)
Initializing Cryptographic API
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
vesafb: framebuffer at 0xd8000000, mapped to 0xf8880000, using 5120k, total 131072k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:d620
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
fb1: Virtual frame buffer device, using 1024K of video memory
Real Time Clock Driver v1.12
i8xx TCO timer: heartbeat value must be 2<heartbeat<39, using 30
i8xx TCO timer: initialized (0x0860). heartbeat=30 sec (nowayout=0)
cn_fork is registered
cn_exit is registered
mice: PS/2 mouse device common for all mice
io scheduler noop registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 2 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
ub: sizeof ub_scsi_cmd 68 ub_dev 2384 ub_lun 140
usbcore: registered new driver ub
sk98lin: Network Device Driver v8.23.1.3
(C)Copyright 1999-2005 Marvell(R).
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Marvell Yukon 88E8053 Gigabit Ethernet Controller
PrefPort:A RlmtMode:Check Link State
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ICH6: chipset revision 5
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
hdb: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
libata version 1.11 loaded.
ata_piix version 1.03
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 153
ata2: SATA max UDMA/133 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 153
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata1: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata2: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ata_piix
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
usbmon: debugs is not available
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: BIOS handoff failed (104, 01010001)
ehci_hcd 0000:00:1d.7: continuing after BIOS bug...
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 161, io mem 0xd2dffc00
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.3
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 161, io base 0x00009880
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 153, io base 0x00009c00
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 145, io base 0x0000a000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 129, io base 0x0000a080
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb 2-1: new low speed USB device using uhci_hcd and address 2
usb 2-2: new low speed USB device using uhci_hcd and address 3
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb 4-1: new full speed USB device using uhci_hcd and address 2
input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Genius NetScroll+Mini Traveler] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb7 ...
md: adding sdb7 ...
md: sdb6 has different UUID to sdb7
md: sdb5 has different UUID to sdb7
md: sda7 has different UUID to sdb7
md: adding sda6 ...
md: sda5 has different UUID to sdb7
md: created md2
md: bind<sda6>
md: bind<sdb7>
md: running: <sdb7><sda6>
md2: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb7
raid0: comparing sdb7(20000768) with sdb7(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda6
raid0: comparing sda6(20000768) with sdb7(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb6 ...
md: adding sdb6 ...
md: sdb5 has different UUID to sdb6
md: sda7 has different UUID to sdb6
md: adding sda5 ...
md: created md0
md: bind<sda5>
md: bind<sdb6>
md: running: <sdb6><sda5>
md0: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb6
raid0: comparing sdb6(20000768) with sdb6(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda5
raid0: comparing sda5(20000768) with sdb6(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb5 ...
md: adding sdb5 ...
md: adding sda7 ...
md: created md1
md: bind<sda7>
md: bind<sdb5>
md: running: <sdb5><sda7>
md1: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb5
raid0: comparing sdb5(20000768) with sdb5(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda7
raid0: comparing sda7(20000768) with sdb5(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: ... autorun DONE.
VFS: Mounted root (reiser4 filesystem) readonly.
Freeing unused kernel memory: 168k freed
ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
ReiserFS: sdb1: using ordered data mode
ReiserFS: sdb1: journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb1: checking transaction log (sdb1)
ReiserFS: sdb1: Using r5 hash to sort names
eth0: network connection up using port A
speed: 100
autonegotiation: yes
duplex mode: full
flowctrl: symmetric
irq moderation: disabled
tcp offload: enabled
scatter-gather: enabled
tx-checksum: enabled
rx-checksum: enabled
rx-polling: enabled
[-- Attachment #4: dmesg.mm3 --]
[-- Type: text/plain, Size: 15671 bytes --]
ormance
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1605.994 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034260k/1048256k available (3050k kernel code, 13228k reserved, 670k data, 200k init, 130752k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3215.31 BogoMIPS (lpj=1607658)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 00000000 00000000 00000000 00000180 00000000 00000000
CPU: After vendor identify, caps: afe9fbff 00000000 00000000 00000000 00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 00000000 00000000 00000040 00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 08
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=-1
NET: Registered protocol family 16
PCI: Using configuration type 1
ACPI: Subsystem revision 20050708
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:04:00.0
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 4!
PCI BIOS passed nonexistent PCI bus 0!
PCI BIOS passed nonexistent PCI bus 2!
PCI BIOS passed nonexistent PCI bus 0!
PCI: Bridge: 0000:00:01.0
IO window: e000-efff
MEM window: d2f00000-d7ffffff
PREFETCH window: d8000000-dfffffff
PCI: Bridge: 0000:00:1c.0
IO window: d000-dfff
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
IO window: c000-cfff
MEM window: d2e00000-d2efffff
PREFETCH window: 40000000-400fffff
PCI: Bridge: 0000:00:1e.0
IO window: b000-bfff
MEM window: disabled.
PREFETCH window: disabled.
PCI BIOS passed nonexistent PCI bus 0!
PCI: No IRQ known for interrupt pin A of device 0000:00:01.0. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI BIOS passed nonexistent PCI bus 0!
PCI: No IRQ known for interrupt pin A of device 0000:00:1c.0. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI BIOS passed nonexistent PCI bus 0!
PCI: No IRQ known for interrupt pin B of device 0000:00:1c.1. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
highmem bounce pool size: 64 pages
fuse init (API version 7.1)
Initializing Cryptographic API
PCI BIOS passed nonexistent PCI bus 0!
PCI: No IRQ known for interrupt pin A of device 0000:00:01.0. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:01.0 to 64
pcie_portdrv_probe->Dev[2581:8086] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
PCI BIOS passed nonexistent PCI bus 0!
PCI: No IRQ known for interrupt pin A of device 0000:00:1c.0. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:1c.0 to 64
pcie_portdrv_probe->Dev[2660:8086] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
PCI BIOS passed nonexistent PCI bus 0!
PCI: No IRQ known for interrupt pin B of device 0000:00:1c.1. Probably buggy MP table.
PCI: Setting latency timer of device 0000:00:1c.1 to 64
pcie_portdrv_probe->Dev[2662:8086] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
vesafb: framebuffer at 0xd8000000, mapped to 0xf8880000, using 5120k, total 131072k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:d620
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
vesafb: Mode is VGA compatible
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
fb1: Virtual frame buffer device, using 1024K of video memory
Real Time Clock Driver v1.12
i8xx TCO timer: heartbeat value must be 2<heartbeat<39, using 30
i8xx TCO timer: initialized (0x0860). heartbeat=30 sec (nowayout=0)
cn_fork is registered
cn_exit is registered
mice: PS/2 mouse device common for all mice
io scheduler noop registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 2 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
ub: sizeof ub_scsi_cmd 68 ub_dev 2388 ub_lun 140
usbcore: registered new driver ub
sk98lin: Network Device Driver v8.23.1.3
(C)Copyright 1999-2005 Marvell(R).
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Marvell Yukon 88E8053 Gigabit Ethernet Controller
PrefPort:A RlmtMode:Check Link State
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
PCI BIOS passed nonexistent PCI bus 0!
ICH6: chipset revision 5
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
hdb: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
libata version 1.11 loaded.
ata_piix version 1.03
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 3
ata2: SATA max UDMA/133 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 3
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata1: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata2: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ata_piix
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
usbmon: debugs is not available
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: BIOS handoff failed (104, 01010001)
ehci_hcd 0000:00:1d.7: continuing after BIOS bug...
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 11, io mem 0xd2dffc00
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.3
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 11, io base 0x00009880
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 3, io base 0x00009c00
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 5, io base 0x0000a000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 10, io base 0x0000a080
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb 2-1: new low speed USB device using uhci_hcd and address 2
usb 2-2: new low speed USB device using uhci_hcd and address 3
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Genius NetScroll+Mini Traveler] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
usb 4-1: new full speed USB device using uhci_hcd and address 2
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
pl2303 4-1:1.0: PL-2303 converter detected
usb 4-1: PL-2303 converter now attached to ttyUSB0
usbcore: registered new driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.12
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
Advanced Linux Sound Architecture Driver Version 1.0.9 (Sun May 29 07:31:02 2005 UTC).
ALSA device list:
No soundcards found.
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb7 ...
md: adding sdb7 ...
md: sdb6 has different UUID to sdb7
md: sdb5 has different UUID to sdb7
md: sda7 has different UUID to sdb7
md: adding sda6 ...
md: sda5 has different UUID to sdb7
md: created md2
md: bind<sda6>
md: bind<sdb7>
md: running: <sdb7><sda6>
md2: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb7
raid0: comparing sdb7(20000768) with sdb7(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda6
raid0: comparing sda6(20000768) with sdb7(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb6 ...
md: adding sdb6 ...
md: sdb5 has different UUID to sdb6
md: sda7 has different UUID to sdb6
md: adding sda5 ...
md: created md0
md: bind<sda5>
md: bind<sdb6>
md: running: <sdb6><sda5>
md0: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb6
raid0: comparing sdb6(20000768) with sdb6(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda5
raid0: comparing sda5(20000768) with sdb6(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb5 ...
md: adding sdb5 ...
md: adding sda7 ...
md: created md1
md: bind<sda7>
md: bind<sdb5>
md: running: <sdb5><sda7>
md1: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb5
raid0: comparing sdb5(20000768) with sdb5(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda7
raid0: comparing sda7(20000768) with sdb5(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: ... autorun DONE.
VFS: Mounted root (reiser4 filesystem) readonly.
Freeing unused kernel memory: 200k freed
ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
ReiserFS: sdb1: using ordered data mode
ReiserFS: sdb1: journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb1: checking transaction log (sdb1)
ReiserFS: sdb1: Using r5 hash to sort names
eth0: network connection up using port A
speed: 100
autonegotiation: yes
duplex mode: full
flowctrl: symmetric
irq moderation: disabled
tcp offload: enabled
scatter-gather: enabled
tx-checksum: enabled
rx-checksum: enabled
rx-polling: enabled
[-- Attachment #5: dmesg.oops_mm1 --]
[-- Type: text/plain, Size: 15652 bytes --]
fb0000 (usable)
BIOS-e820: 000000003ffb0000 - 000000003ffbe000 (ACPI data)
BIOS-e820: 000000003ffbe000 - 000000003fff0000 (ACPI NVS)
BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 262064
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:31
HighMem zone: 32688 pages, LIFO batch:15
DMI 2.3 present.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: INTEL Product ID: APIC at: 0xFEE00000
Processor #0 6:13 APIC version 20
I/O APIC #1 Version 32 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
Allocating PCI resources starting at 40000000 (gap: 40000000:bfb80000)
Built 1 zonelists
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Initializing CPU#0
Kernel command line: root=/dev/md1 vga=794 quiet
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1606.130 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034508k/1048256k available (2702k kernel code, 12980k reserved, 839k data, 168k init, 130752k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3214.30 BogoMIPS (lpj=1607154)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 00000000 00000000 00000000 00000180 00000000 00000000
CPU: After vendor identify, caps: afe9fbff 00000000 00000000 00000000 00000180 00000000 00000000
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 00000000 00000000 00000040 00000180 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel(R) Pentium(R) M processor 1.60GHz stepping 08
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
NET: Registered protocol family 16
PCI: Using configuration type 1
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:04:00.0
PCI: Transparent bridge - 0000:00:1e.0
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX/ICH [8086/2640] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:01.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1b.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1c.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1c.1[B] -> IRQ 137
PCI->APIC IRQ transform: 0000:00:1d.0[A] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:1d.1[B] -> IRQ 153
PCI->APIC IRQ transform: 0000:00:1d.2[C] -> IRQ 145
PCI->APIC IRQ transform: 0000:00:1d.3[D] -> IRQ 129
PCI->APIC IRQ transform: 0000:00:1d.7[A] -> IRQ 161
PCI->APIC IRQ transform: 0000:00:1f.1[A] -> IRQ 145
PCI->APIC IRQ transform: 0000:00:1f.2[B] -> IRQ 153
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 153
PCI->APIC IRQ transform: 0000:04:00.0[A] -> IRQ 129
PCI->APIC IRQ transform: 0000:02:00.0[A] -> IRQ 137
Machine check exception polling timer started.
highmem bounce pool size: 64 pages
fuse init (API version 7.1)
Initializing Cryptographic API
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
vesafb: framebuffer at 0xd8000000, mapped to 0xf8880000, using 5120k, total 131072k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:d620
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
fb1: Virtual frame buffer device, using 1024K of video memory
Real Time Clock Driver v1.12
i8xx TCO timer: heartbeat value must be 2<heartbeat<39, using 30
i8xx TCO timer: initialized (0x0860). heartbeat=30 sec (nowayout=0)
cn_fork is registered
cn_exit is registered
mice: PS/2 mouse device common for all mice
io scheduler noop registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 2 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
ub: sizeof ub_scsi_cmd 68 ub_dev 2384 ub_lun 140
usbcore: registered new driver ub
sk98lin: Network Device Driver v8.23.1.3
(C)Copyright 1999-2005 Marvell(R).
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Marvell Yukon 88E8053 Gigabit Ethernet Controller
PrefPort:A RlmtMode:Check Link State
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ICH6: chipset revision 5
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
hdb: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
libata version 1.11 loaded.
ata_piix version 1.03
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 153
ata2: SATA max UDMA/133 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 153
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata1: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata2: dev 0 ATA-7, max UDMA7, 312581808 sectors: LBA48
ata2: dev 0 configured for UDMA/133
scsi1 : ata_piix
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
usbmon: debugs is not available
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: BIOS handoff failed (104, 01010001)
ehci_hcd 0000:00:1d.7: continuing after BIOS bug...
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 161, io mem 0xd2dffc00
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.3
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 161, io base 0x00009880
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 153, io base 0x00009c00
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 145, io base 0x0000a000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 129, io base 0x0000a080
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb 2-1: new low speed USB device using uhci_hcd and address 2
usb 2-2: new low speed USB device using uhci_hcd and address 3
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb 4-1: new full speed USB device using uhci_hcd and address 2
input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Genius NetScroll+Mini Traveler] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb7 ...
md: adding sdb7 ...
md: sdb6 has different UUID to sdb7
md: sdb5 has different UUID to sdb7
md: sda7 has different UUID to sdb7
md: adding sda6 ...
md: sda5 has different UUID to sdb7
md: created md2
md: bind<sda6>
md: bind<sdb7>
md: running: <sdb7><sda6>
md2: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb7
raid0: comparing sdb7(20000768) with sdb7(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda6
raid0: comparing sda6(20000768) with sdb7(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb6 ...
md: adding sdb6 ...
md: sdb5 has different UUID to sdb6
md: sda7 has different UUID to sdb6
md: adding sda5 ...
md: created md0
md: bind<sda5>
md: bind<sdb6>
md: running: <sdb6><sda5>
md0: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb6
raid0: comparing sdb6(20000768) with sdb6(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda5
raid0: comparing sda5(20000768) with sdb6(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb5 ...
md: adding sdb5 ...
md: adding sda7 ...
md: created md1
md: bind<sda7>
md: bind<sdb5>
md: running: <sdb5><sda7>
md1: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb5
raid0: comparing sdb5(20000768) with sdb5(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda7
raid0: comparing sda7(20000768) with sdb5(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: ... autorun DONE.
VFS: Mounted root (reiser4 filesystem) readonly.
Freeing unused kernel memory: 168k freed
ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
ReiserFS: sdb1: using ordered data mode
ReiserFS: sdb1: journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb1: checking transaction log (sdb1)
ReiserFS: sdb1: Using r5 hash to sort names
eth0: network connection up using port A
speed: 100
autonegotiation: yes
duplex mode: full
flowctrl: symmetric
irq moderation: disabled
tcp offload: enabled
scatter-gather: enabled
tx-checksum: enabled
rx-checksum: enabled
rx-polling: enabled
PCI: Setting latency timer of device 0000:00:1b.0 to 64
hda_codec: Unknown model for ALC880, trying auto-probe from BIOS...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
f8f421d4
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
last sysfs file:
Modules linked in: snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc
CPU: 0
EIP: 0060:[<f8f421d4>] Not tainted VLI
EFLAGS: 00010293 (2.6.13-rc3-mm1pm)
eax: fffffffe ebx: f7bf6748 ecx: 00000000 edx: 00000000
esi: f7bf6600 edi: 00000000 ebp: 00000006 esp: f718fde4
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 6993, threadinfo=f718e000 task=f74d7a90)
Stack: 00000000 00000000 00000000 00000000 f7bf6600 f7bf6748 f7689000 f8f42713
f7bf6600 f7689000 f8f4298d f8f460d8 f8f45556 00000001 f8f3e77e 00000f00
00000005 00000000 f7689000 f753b240 00000000 f8f3e984 00000f00 00000002
Call Trace:
[<f8f42713>]
[<f8f4298d>]
[<f8f3e77e>]
[<f8f3e984>]
[<f8f3e592>]
[<c0254b3e>]
[<f8851871>]
[<f8851100>]
[<f8851220>]
[<f88524a3>]
[<c02619ca>]
[<c0261a06>]
[<c0293273>]
[<c02933a9>]
[<c029292a>]
[<c02933c6>]
[<c0293370>]
[<c0292e1c>]
[<c0293795>]
[<c0261c68>]
[<c0135be9>]
[<c0102c7b>]
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 15:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-07-29 16:15 ` Eric W. Biederman
0 siblings, 0 replies; 94+ messages in thread
From: Eric W. Biederman @ 2005-07-29 16:15 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel
"Martin J. Bligh" <mbligh@mbligh.org> writes:
>> From: Eric W. Biederman <ebiederm@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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 15:48 ` 2.6.13-rc3-mm3 Michael Thonke
@ 2005-07-29 19:33 ` Andrew Morton
2005-07-30 0:00 ` 2.6.13-rc3-mm3 Michael Thonke
0 siblings, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-29 19:33 UTC (permalink / raw)
To: Michael Thonke; +Cc: iogl64nx, linux-kernel, acpi-devel
Michael Thonke <tk-shockwave@web.de> wrote:
>
> Andrew Morton schrieb:
> > Michael Thonke <iogl64nx@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?
> > 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (8 preceding siblings ...)
2005-07-29 6:02 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-07-29 23:05 ` Khalid Aziz
2005-07-29 23:17 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-30 10:27 ` 2.6.13-rc3-mm3 Richard Purdie
` (3 subsequent siblings)
13 siblings, 1 reply; 94+ messages in thread
From: Khalid Aziz @ 2005-07-29 23:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: LKML
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:
-------
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 majordomo@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
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 23:05 ` 2.6.13-rc3-mm3 Khalid Aziz
@ 2005-07-29 23:17 ` Andrew Morton
2005-07-30 15:33 ` 2.6.13-rc3-mm3 Khalid Aziz
2005-08-01 15:36 ` 2.6.13-rc3-mm3 Bjorn Helgaas
0 siblings, 2 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-29 23:17 UTC (permalink / raw)
To: Khalid Aziz; +Cc: linux-kernel, linux-ia64, linux-acpi
Khalid Aziz <khalid_aziz@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
> 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
Does the above happen on 2.6.13-rc3 or 2.6.13-rc4?
> 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.
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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 19:33 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-30 0:00 ` Michael Thonke
0 siblings, 0 replies; 94+ messages in thread
From: Michael Thonke @ 2005-07-30 0:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Michael Thonke, linux-kernel, acpi-devel
[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]
Andrew Morton schrieb:
>Michael Thonke <tk-shockwave@web.de> wrote:
>
>
>>Andrew Morton schrieb:
>>
>>
>>>Michael Thonke <iogl64nx@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.
[-- Attachment #2: dmesg.2613rc4git1 --]
[-- Type: text/plain, Size: 15340 bytes --]
IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=-1
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20050408
ACPI-0362: *** Error: Looking up [CHAF] in namespace, AE_NOT_FOUND
search_node b1994240 start_node b1994240 return_node 00000000
ACPI-0362: *** Error: Looking up [OC06] in namespace, AE_NOT_FOUND
search_node b1994f60 start_node b1994f60 return_node 00000000
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:04:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 14 devices
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
PCI: Bridge: 0000:00:01.0
IO window: e000-efff
MEM window: d2f00000-d7ffffff
PREFETCH window: d8000000-dfffffff
PCI: Bridge: 0000:00:1c.0
IO window: d000-dfff
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
IO window: c000-cfff
MEM window: d2e00000-d2efffff
PREFETCH window: 40000000-400fffff
PCI: Bridge: 0000:00:1e.0
IO window: b000-bfff
MEM window: disabled.
PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
pnp: 00:06: ioport range 0x290-0x297 has been reserved
Machine check exception polling timer started.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
Initializing Cryptographic API
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[pcie00]
Allocate Port Service[pcie02]
vesafb: framebuffer at 0xd8000000, mapped to 0xf0880000, using 5120k, total 131072k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:d620
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 160x64
fb0: VESA VGA frame buffer device
fb1: Virtual frame buffer device, using 1024K of video memory
ACPI: CPU0 (power states: C1[C1])
ACPI: Processor [CPU1] (supports 8 throttling states)
Real Time Clock Driver v1.12
i8xx TCO timer: heartbeat value must be 2<heartbeat<39, using 30
i8xx TCO timer: initialized (0x0860). heartbeat=30 sec (nowayout=0)
mice: PS/2 mouse device common for all mice
io scheduler noop registered
io scheduler cfq registered
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 2 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
ub: sizeof ub_scsi_cmd 68 ub_dev 2388 ub_lun 140
usbcore: registered new driver ub
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
sk98lin: Network Device Driver v8.23.1.3
(C)Copyright 1999-2005 Marvell(R).
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Marvell Yukon 88E8053 Gigabit Ethernet Controller
PrefPort:A RlmtMode:Check Link State
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH6: chipset revision 5
ICH6: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HL-DT-ST DVDRAM GSA-4163B, ATAPI CD/DVD-ROM drive
hdb: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hda: ATAPI 63X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
libata version 1.11 loaded.
ata_piix version 1.03
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xAC00 ctl 0xA882 bmdma 0xA400 irq 19
ata2: SATA max UDMA/133 cmd 0xA800 ctl 0xA482 bmdma 0xA408 irq 19
ata1: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata1: dev 0 ATA, max UDMA7, 312581808 sectors: lba48
ata1: dev 0 configured for UDMA/133
scsi0 : ata_piix
ata2: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3c01 87:4023 88:20ff
ata2: dev 0 ATA, max UDMA7, 312581808 sectors: lba48
ata2: dev 0 configured for UDMA/133
scsi1 : ata_piix
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: SAMSUNG HD160JJ Rev: WU10
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 < sda5 sda6 sda7 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
SCSI device sdb: 312581808 512-byte hdwr sectors (160042 MB)
SCSI device sdb: drive cache: write back
sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 >
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
usbmon: debugs is not available
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 20, io mem 0xd2dffc00
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 20, io base 0x00009880
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x00009c00
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000a000
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000a080
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usb 2-1: new low speed USB device using uhci_hcd and address 2
usb 2-2: new low speed USB device using uhci_hcd and address 3
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Device [CHESEN USB Keyboard] on usb-0000:00:1d.0-1
input: USB HID v1.10 Mouse [Genius NetScroll+Mini Traveler] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
usb 4-1: new full speed USB device using uhci_hcd and address 2
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for Generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
pl2303 4-1:1.0: PL-2303 converter detected
usb 4-1: PL-2303 converter now attached to ttyUSB0
usbcore: registered new driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.12
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: md driver 0.90.2 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 3.38
Advanced Linux Sound Architecture Driver Version 1.0.9b (Thu Jul 28 12:20:13 2005 UTC).
ALSA device list:
No soundcards found.
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ACPI wakeup devices:
P0P1 P0P3 P0P4 P0P5 P0P6 P0P7 USB1 USB2 USB3 USB4 EUSB MC97
ACPI: (supports S0 S1 S3 S4 S5)
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb7 ...
md: adding sdb7 ...
md: sdb6 has different UUID to sdb7
md: sdb5 has different UUID to sdb7
md: sda7 has different UUID to sdb7
md: adding sda6 ...
md: sda5 has different UUID to sdb7
md: created md2
md: bind<sda6>
md: bind<sdb7>
md: running: <sdb7><sda6>
md2: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb7
raid0: comparing sdb7(20000768) with sdb7(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda6
raid0: comparing sda6(20000768) with sdb7(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb6 ...
md: adding sdb6 ...
md: sdb5 has different UUID to sdb6
md: sda7 has different UUID to sdb6
md: adding sda5 ...
md: created md0
md: bind<sda5>
md: bind<sdb6>
md: running: <sdb6><sda5>
md0: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb6
raid0: comparing sdb6(20000768) with sdb6(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda5
raid0: comparing sda5(20000768) with sdb6(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: considering sdb5 ...
md: adding sdb5 ...
md: adding sda7 ...
md: created md1
md: bind<sda7>
md: bind<sdb5>
md: running: <sdb5><sda7>
md1: setting max_sectors to 128, segment boundary to 32767
raid0: looking at sdb5
raid0: comparing sdb5(20000768) with sdb5(20000768)
raid0: END
raid0: ==> UNIQUE
raid0: 1 zones
raid0: looking at sda7
raid0: comparing sda7(20000768) with sdb5(20000768)
raid0: EQUAL
raid0: FINAL 1 zones
raid0: done.
raid0 : md_size is 40001536 blocks.
raid0 : conf->hash_spacing is 40001536 blocks.
raid0 : nb_zone is 1.
raid0 : Allocating 4 bytes for hash.
md: ... autorun DONE.
ReiserFS: md2: found reiserfs format "3.6" with standard journal
ReiserFS: md2: using ordered data mode
ReiserFS: md2: journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: md2: checking transaction log (md2)
ReiserFS: md2: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 192k freed
ReiserFS: sdb1: found reiserfs format "3.6" with standard journal
ReiserFS: sdb1: using ordered data mode
ReiserFS: sdb1: journal params: device sdb1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb1: checking transaction log (sdb1)
ReiserFS: sdb1: Using r5 hash to sort names
eth0: network connection up using port A
speed: 100
autonegotiation: yes
duplex mode: full
flowctrl: symmetric
irq moderation: disabled
tcp offload: enabled
scatter-gather: enabled
tx-checksum: enabled
rx-checksum: enabled
rx-polling: enabled
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1b.0 to 64
hda_codec: Unknown model for ALC880, trying auto-probe from BIOS...
hda_codec: num_steps = 0 for NID=0x8
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:04:00.0 to 64
NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7667 Fri Jun 17 07:01:04 PDT 2005
hda_codec: num_steps = 0 for NID=0x9
hda_codec: num_steps = 0 for NID=0x9
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (9 preceding siblings ...)
2005-07-29 23:05 ` 2.6.13-rc3-mm3 Khalid Aziz
@ 2005-07-30 10:27 ` Richard Purdie
2005-07-30 17:05 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 9:04 ` 2.6.13-rc3-mm3 Manuel Lauss
` (2 subsequent siblings)
13 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-07-30 10:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
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...
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)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 23:17 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-30 15:33 ` Khalid Aziz
2005-07-30 18:02 ` 2.6.13-rc3-mm3 Andrew Morton
2005-08-01 15:36 ` 2.6.13-rc3-mm3 Bjorn Helgaas
1 sibling, 1 reply; 94+ messages in thread
From: Khalid Aziz @ 2005-07-30 15:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Khalid Aziz, LKML, Linux ia64, linux-acpi
[-- Attachment #1: Type: text/plain, Size: 13035 bytes --]
On Fri, 2005-07-29 at 16:17 -0700, Andrew Morton wrote:
> Khalid Aziz <khalid_aziz@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
> -> [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
> --------------------------------
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
[-- Attachment #2: rc3_bootup.log --]
[-- Type: text/x-log, Size: 11046 bytes --]
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
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
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 root=/dev/sdb2 console=ttyS0,115200n8 ro
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour VGA+ 80x25
Memory: 12438928k/12541920k available (6951k code, 116448k reserved, 3697k data, 288k 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 0 cycles, maxerr 433 cycles)
Brought up 2 CPUs
Total of 2 processors activated (2695.16 BogoMIPS).
NET: Registered protocol family 16
ACPI: bus type pci registered
ACPI: Subsystem revision 20050408
ACPI: Interpreter enabled
ACPI: Using IOSAPIC for interrupt routing
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
SCSI subsystem initialized
IOC: zx1 2.2 HPA 0xfed01000 IOVA space 1024Mb at 0x40000000
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
inotify syscall
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
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
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.8-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
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]
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
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-floppy driver 0.99.newide
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
Fusion MPT base driver 3.03.02
Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT SPI Host driver 3.03.02
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={Initiator,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
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
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
[-- Attachment #3: rc3-mm3_bootup.log --]
[-- Type: text/x-log, Size: 5162 bytes --]
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-30 10:27 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-07-30 17:05 ` Andrew Morton
0 siblings, 0 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-30 17:05 UTC (permalink / raw)
To: Richard Purdie; +Cc: linux-kernel, Andi Kleen
Richard Purdie <rpurdie@rpsys.net> wrote:
>
> 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)
_
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-30 15:33 ` 2.6.13-rc3-mm3 Khalid Aziz
@ 2005-07-30 18:02 ` Andrew Morton
0 siblings, 0 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-30 18:02 UTC (permalink / raw)
To: Khalid Aziz; +Cc: khalid_aziz, linux-kernel, linux-ia64, linux-acpi
Khalid Aziz <khalid.aziz@hp.com> wrote:
>
> On Fri, 2005-07-29 at 16:17 -0700, Andrew Morton wrote:
> > Khalid Aziz <khalid_aziz@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.
>
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...
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (10 preceding siblings ...)
2005-07-30 10:27 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-07-31 9:04 ` Manuel Lauss
2005-07-31 9:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 18:25 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-01 1:43 ` 2.6.13-rc3-mm3 Richard Purdie
2005-09-14 14:32 ` 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?) Martin J. Bligh
13 siblings, 2 replies; 94+ messages in thread
From: Manuel Lauss @ 2005-07-31 9:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
Hello,
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 9:04 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-07-31 9:16 ` Andrew Morton
2005-07-31 11:12 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 12:46 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 18:25 ` 2.6.13-rc3-mm3 Linus Torvalds
1 sibling, 2 replies; 94+ messages in thread
From: Andrew Morton @ 2005-07-31 9:16 UTC (permalink / raw)
To: Manuel Lauss; +Cc: linux-kernel, Stelian Pop
Manuel Lauss <mano@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.
From: Dmitry Torokhov <dtor_core@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 <dtor@mail.ru>
Cc: Stelian Pop <stelian@popies.net>
Signed-off-by: Andrew Morton <akpm@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) {
_
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 9:16 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-31 11:12 ` Manuel Lauss
2005-07-31 12:46 ` 2.6.13-rc3-mm3 Manuel Lauss
1 sibling, 0 replies; 94+ messages in thread
From: Manuel Lauss @ 2005-07-31 11:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Stelian Pop
Andrew Morton wrote:
> Manuel Lauss <mano@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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 9:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 11:12 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-07-31 12:46 ` Manuel Lauss
2005-07-31 17:35 ` 2.6.13-rc3-mm3 Andrew Morton
1 sibling, 1 reply; 94+ messages in thread
From: Manuel Lauss @ 2005-07-31 12:46 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Stelian Pop
Andrew Morton wrote:
> Manuel Lauss <mano@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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 12:46 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-07-31 17:35 ` Andrew Morton
2005-07-31 18:21 ` 2.6.13-rc3-mm3 Manuel Lauss
0 siblings, 1 reply; 94+ messages in thread
From: Andrew Morton @ 2005-07-31 17:35 UTC (permalink / raw)
To: Manuel Lauss; +Cc: linux-kernel, stelian, Greg KH
Manuel Lauss <mano@roarinelk.homelinux.net> wrote:
>
> Andrew Morton wrote:
> > Manuel Lauss <mano@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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 17:35 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-31 18:21 ` Manuel Lauss
0 siblings, 0 replies; 94+ messages in thread
From: Manuel Lauss @ 2005-07-31 18:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
On Sun, Jul 31, 2005 at 10:35:28AM -0700, Andrew Morton wrote:
> Manuel Lauss <mano@roarinelk.homelinux.net> wrote:
> >
> > Andrew Morton wrote:
> > > Manuel Lauss <mano@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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 9:04 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 9:16 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-07-31 18:25 ` Linus Torvalds
2005-07-31 18:41 ` 2.6.13-rc3-mm3 Manuel Lauss
` (2 more replies)
1 sibling, 3 replies; 94+ messages in thread
From: Linus Torvalds @ 2005-07-31 18:25 UTC (permalink / raw)
To: Manuel Lauss; +Cc: Andrew Morton, Linux Kernel Mailing List, Stelian Pop
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 18:25 ` 2.6.13-rc3-mm3 Linus Torvalds
@ 2005-07-31 18:41 ` Manuel Lauss
2005-07-31 18:59 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-07-31 21:35 ` 2.6.13-rc3-mm3 Stelian Pop
[not found] ` <Pine.LNX.4.58.0507311125360.29650@g5.osdl.org>
2 siblings, 1 reply; 94+ messages in thread
From: Manuel Lauss @ 2005-07-31 18:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, Linux Kernel Mailing List, Stelian Pop
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.
--
Manuel Lauss
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 18:41 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-07-31 18:59 ` Linus Torvalds
0 siblings, 0 replies; 94+ messages in thread
From: Linus Torvalds @ 2005-07-31 18:59 UTC (permalink / raw)
To: Manuel Lauss; +Cc: Andrew Morton, Linux Kernel Mailing List, Stelian Pop
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-31 18:25 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-07-31 18:41 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-07-31 21:35 ` Stelian Pop
[not found] ` <Pine.LNX.4.58.0507311125360.29650@g5.osdl.org>
2 siblings, 0 replies; 94+ messages in thread
From: Stelian Pop @ 2005-07-31 21:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Manuel Lauss, Andrew Morton, Linux Kernel Mailing List
Le dimanche 31 juillet 2005 à 11:25 -0700, Linus Torvalds a écrit :
> - 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 <stelian@popies.net>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (11 preceding siblings ...)
2005-07-31 9:04 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-08-01 1:43 ` Richard Purdie
2005-08-01 16:10 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-09-14 14:32 ` 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?) Martin J. Bligh
13 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 1:43 UTC (permalink / raw)
To: Christoph Lameter, Andrew Morton; +Cc: linux-kernel
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/
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
[not found] ` <Pine.LNX.4.58.0507311557020.14342@g5.osdl.org>
@ 2005-08-01 14:37 ` Stelian Pop
2005-08-02 9:49 ` 2.6.13-rc3-mm3 Stelian Pop
0 siblings, 1 reply; 94+ messages in thread
From: Stelian Pop @ 2005-08-01 14:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Andrew Morton, Ivan Kokshaysky,
Greg KH, Manuel Lauss, Erik Waling
[Sorry all for the duplicate, LKML slipped somehow from the CC: line so I'm sending this again]
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 <stelian@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 <stelian@popies.net>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 23:17 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-30 15:33 ` 2.6.13-rc3-mm3 Khalid Aziz
@ 2005-08-01 15:36 ` Bjorn Helgaas
1 sibling, 0 replies; 94+ messages in thread
From: Bjorn Helgaas @ 2005-08-01 15:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: Khalid Aziz, linux-kernel, linux-ia64, linux-acpi
On Friday 29 July 2005 5:17 pm, Andrew Morton wrote:
> Khalid Aziz <khalid_aziz@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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 1:43 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-01 16:10 ` Christoph Lameter
2005-08-01 20:02 ` 2.6.13-rc3-mm3 Richard Purdie
0 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 16:10 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
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?
> 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 16:10 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 20:02 ` Richard Purdie
2005-08-01 20:36 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 20:02 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
On Mon, 2005-08-01 at 09:10 -0700, Christoph Lameter wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 20:02 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-01 20:36 ` Christoph Lameter
2005-08-01 21:07 ` 2.6.13-rc3-mm3 Richard Purdie
0 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 20:36 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
On Mon, 1 Aug 2005, Richard Purdie wrote:
> > 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).
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 20:36 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 21:07 ` Richard Purdie
2005-08-01 21:16 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 21:07 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
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...
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 21:07 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-01 21:16 ` Christoph Lameter
2005-08-01 21:27 ` 2.6.13-rc3-mm3 Richard Purdie
0 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 21:16 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
On Mon, 1 Aug 2005, Richard Purdie wrote:
> 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?
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 21:16 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 21:27 ` Richard Purdie
2005-08-01 21:40 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 21:27 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
On Mon, 2005-08-01 at 14:16 -0700, Christoph Lameter wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 21:27 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-01 21:40 ` Christoph Lameter
2005-08-01 21:52 ` 2.6.13-rc3-mm3 Richard Purdie
0 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 21:40 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
On Mon, 1 Aug 2005, Richard Purdie wrote:
> > 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 21:40 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 21:52 ` Richard Purdie
2005-08-01 22:02 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 22:19 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 2 replies; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 21:52 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
On Mon, 2005-08-01 at 14:40 -0700, Christoph Lameter wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 21:52 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-01 22:02 ` Christoph Lameter
2005-08-01 22:19 ` 2.6.13-rc3-mm3 Christoph Lameter
1 sibling, 0 replies; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 22:02 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
On Mon, 1 Aug 2005, Richard Purdie wrote:
> 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);
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 21:52 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 22:02 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 22:19 ` Christoph Lameter
2005-08-01 23:01 ` 2.6.13-rc3-mm3 Richard Purdie
1 sibling, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 22:19 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
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:
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 22:19 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 23:01 ` Richard Purdie
2005-08-01 23:16 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-04 0:19 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 2 replies; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 23:01 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
> 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:
>
> +#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
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 23:01 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-01 23:16 ` Christoph Lameter
2005-08-01 23:32 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-04 0:19 ` 2.6.13-rc3-mm3 Christoph Lameter
1 sibling, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-01 23:16 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel
On Tue, 2 Aug 2005, Richard Purdie wrote:
> > + 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);
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 23:16 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-01 23:32 ` Richard Purdie
0 siblings, 0 replies; 94+ messages in thread
From: Richard Purdie @ 2005-08-01 23:32 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel
On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
> 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).
>
> +#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
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 14:37 ` 2.6.13-rc3-mm3 Stelian Pop
@ 2005-08-02 9:49 ` Stelian Pop
2005-08-02 10:32 ` 2.6.13-rc3-mm3 Manuel Lauss
0 siblings, 1 reply; 94+ messages in thread
From: Stelian Pop @ 2005-08-02 9:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Andrew Morton, Ivan Kokshaysky,
Greg KH, Manuel Lauss, Erik Waling
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).
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 <stelian@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 */
+ 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-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 @@
#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 }
-};
-
-/* 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 @@
}
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 <stelian@popies.net>
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 9:49 ` 2.6.13-rc3-mm3 Stelian Pop
@ 2005-08-02 10:32 ` Manuel Lauss
2005-08-02 11:40 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
0 siblings, 1 reply; 94+ messages in thread
From: Manuel Lauss @ 2005-08-02 10:32 UTC (permalink / raw)
To: Stelian Pop
Cc: Linus Torvalds, Linux Kernel Mailing List, Andrew Morton,
Ivan Kokshaysky, Greg KH, Erik Waling
On Tue, Aug 02, 2005 at 11:49:28AM +0200, Stelian Pop wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 10:32 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-08-02 11:40 ` Ivan Kokshaysky
2005-08-02 14:04 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-08-02 15:48 ` 2.6.13-rc3-mm3 Linus Torvalds
0 siblings, 2 replies; 94+ messages in thread
From: Ivan Kokshaysky @ 2005-08-02 11:40 UTC (permalink / raw)
To: Manuel Lauss
Cc: Stelian Pop, Linus Torvalds, Linux Kernel Mailing List,
Andrew Morton, Greg KH, Erik Waling
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?
Ivan.
----- Forwarded message from Ivan Kokshaysky <ink@jurassic.park.msu.ru> -----
Date: Mon, 1 Aug 2005 11:22:45 +0400
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
To: Andrew Morton <akpm@osdl.org>
Cc: Tero Roponen <teanropo@cc.jyu.fi>, jonsmirl@gmail.com,
gregkh@suse.de, linux-kernel@vger.kernel.org,
Mikael Pettersson <mikpe@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.0950968f.akpm@osdl.org>; from akpm@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 <teanropo@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 -----
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 11:40 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
@ 2005-08-02 14:04 ` Manuel Lauss
2005-08-02 15:48 ` 2.6.13-rc3-mm3 Linus Torvalds
1 sibling, 0 replies; 94+ messages in thread
From: Manuel Lauss @ 2005-08-02 14:04 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Stelian Pop, Linus Torvalds, Linux Kernel Mailing List,
Andrew Morton, Greg KH, Erik Waling
On Tue, Aug 02, 2005 at 03:40:22PM +0400, Ivan Kokshaysky wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 11:40 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 14:04 ` 2.6.13-rc3-mm3 Manuel Lauss
@ 2005-08-02 15:48 ` Linus Torvalds
2005-08-02 16:50 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
1 sibling, 1 reply; 94+ messages in thread
From: Linus Torvalds @ 2005-08-02 15:48 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Greg KH, Erik Waling
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 15:48 ` 2.6.13-rc3-mm3 Linus Torvalds
@ 2005-08-02 16:50 ` Ivan Kokshaysky
2005-08-02 17:11 ` 2.6.13-rc3-mm3 Linus Torvalds
0 siblings, 1 reply; 94+ messages in thread
From: Ivan Kokshaysky @ 2005-08-02 16:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Greg KH, Erik Waling
On Tue, Aug 02, 2005 at 08:48:21AM -0700, Linus Torvalds wrote:
> 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. */
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 16:50 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
@ 2005-08-02 17:11 ` Linus Torvalds
2005-08-02 21:13 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
0 siblings, 1 reply; 94+ messages in thread
From: Linus Torvalds @ 2005-08-02 17:11 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Greg KH, Erik Waling
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;
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 17:11 ` 2.6.13-rc3-mm3 Linus Torvalds
@ 2005-08-02 21:13 ` Ivan Kokshaysky
2005-08-02 21:21 ` 2.6.13-rc3-mm3 Greg KH
0 siblings, 1 reply; 94+ messages in thread
From: Ivan Kokshaysky @ 2005-08-02 21:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Greg KH, Erik Waling
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.
Ivan.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 21:13 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
@ 2005-08-02 21:21 ` Greg KH
2005-08-02 21:47 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
0 siblings, 1 reply; 94+ messages in thread
From: Greg KH @ 2005-08-02 21:21 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Linus Torvalds, Manuel Lauss, Stelian Pop,
Linux Kernel Mailing List, Andrew Morton, Erik Waling
On Wed, Aug 03, 2005 at 01:13:37AM +0400, Ivan Kokshaysky wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 21:21 ` 2.6.13-rc3-mm3 Greg KH
@ 2005-08-02 21:47 ` Ivan Kokshaysky
2005-08-02 21:57 ` 2.6.13-rc3-mm3 Linus Torvalds
0 siblings, 1 reply; 94+ messages in thread
From: Ivan Kokshaysky @ 2005-08-02 21:47 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Manuel Lauss, Stelian Pop,
Linux Kernel Mailing List, Andrew Morton, Erik Waling
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.
Ivan.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-02 21:47 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
@ 2005-08-02 21:57 ` Linus Torvalds
2005-08-02 22:59 ` [patch 1/2] increase PCIBIOS_MIN_IO on x86 Ivan Kokshaysky
2005-08-02 23:09 ` [patch 2/2] ACPI: " Ivan Kokshaysky
0 siblings, 2 replies; 94+ messages in thread
From: Linus Torvalds @ 2005-08-02 21:57 UTC (permalink / raw)
To: Ivan Kokshaysky
Cc: Greg KH, Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Erik Waling
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* [patch 1/2] increase PCIBIOS_MIN_IO on x86
2005-08-02 21:57 ` 2.6.13-rc3-mm3 Linus Torvalds
@ 2005-08-02 22:59 ` Ivan Kokshaysky
2005-08-02 23:09 ` [patch 2/2] ACPI: " Ivan Kokshaysky
1 sibling, 0 replies; 94+ messages in thread
From: Ivan Kokshaysky @ 2005-08-02 22:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Erik Waling, Mikael Pettersson
On Tue, Aug 02, 2005 at 02:57:19PM -0700, Linus Torvalds wrote:
> 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 <ink@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);
^ permalink raw reply [flat|nested] 94+ messages in thread
* [patch 2/2] ACPI: increase PCIBIOS_MIN_IO on x86
2005-08-02 21:57 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 22:59 ` [patch 1/2] increase PCIBIOS_MIN_IO on x86 Ivan Kokshaysky
@ 2005-08-02 23:09 ` Ivan Kokshaysky
1 sibling, 0 replies; 94+ messages in thread
From: Ivan Kokshaysky @ 2005-08-02 23:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Manuel Lauss, Stelian Pop, Linux Kernel Mailing List,
Andrew Morton, Erik Waling, acpi-devel
We have increased PCIBIOS_MIN_IO to 0x4000, but still want
motherboard resources to be allocated properly. So we need
to state 0x1000 (according to the comment) limit explicitely.
Signed-off-by: Ivan Kokshaysky <ink@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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-07-29 6:10 ` 2.6.13-rc3-mm3 Andrew Morton
@ 2005-08-03 1:17 ` Martin J. Bligh
2005-08-03 4:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
0 siblings, 1 reply; 94+ messages in thread
From: Martin J. Bligh @ 2005-08-03 1:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
--Andrew Morton <akpm@osdl.org> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
> "Martin J. Bligh" <mbligh@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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-03 1:17 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-08-03 4:21 ` Martin J. Bligh
2005-08-07 23:23 ` 2.6.13-rc3-mm3 Martin J. Bligh
0 siblings, 1 reply; 94+ messages in thread
From: Martin J. Bligh @ 2005-08-03 4:21 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
--"Martin J. Bligh" <mbligh@mbligh.org> wrote (on Tuesday, August 02, 2005 18:17:33 -0700):
> --Andrew Morton <akpm@osdl.org> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
>
>> "Martin J. Bligh" <mbligh@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.
M.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-01 23:01 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 23:16 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-04 0:19 ` Christoph Lameter
2005-08-04 11:27 ` 2.6.13-rc3-mm3 Richard Purdie
1 sibling, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-04 0:19 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel, nickpiggin
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.
Signed-off-by: Christoph Lameter <christoph@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)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-04 0:19 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-04 11:27 ` Richard Purdie
2005-08-04 14:04 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-04 11:27 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel, nickpiggin
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...
Richard
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-04 11:27 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-04 14:04 ` Christoph Lameter
2005-08-04 14:37 ` 2.6.13-rc3-mm3 Richard Purdie
0 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-04 14:04 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel, nickpiggin
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?
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-04 14:04 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-04 14:37 ` Richard Purdie
2005-08-05 15:17 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-04 14:37 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel, nickpiggin
On Thu, 2005-08-04 at 07:04 -0700, Christoph Lameter wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-04 14:37 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-05 15:17 ` Christoph Lameter
2005-08-07 13:44 ` 2.6.13-rc3-mm3 Richard Purdie
0 siblings, 1 reply; 94+ messages in thread
From: Christoph Lameter @ 2005-08-05 15:17 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel, nickpiggin
On Thu, 4 Aug 2005, Richard Purdie wrote:
> 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);
}
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-05 15:17 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-07 13:44 ` Richard Purdie
2005-08-08 16:48 ` 2.6.13-rc3-mm3 Christoph Lameter
0 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-07 13:44 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, linux-kernel, nickpiggin
On Fri, 2005-08-05 at 08:17 -0700, Christoph Lameter wrote:
> 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.
>
> + 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));
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-03 4:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
@ 2005-08-07 23:23 ` Martin J. Bligh
0 siblings, 0 replies; 94+ messages in thread
From: Martin J. Bligh @ 2005-08-07 23:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
--"Martin J. Bligh" <mbligh@mbligh.org> wrote (on Tuesday, August 02, 2005 21:21:30 -0700):
> --"Martin J. Bligh" <mbligh@mbligh.org> wrote (on Tuesday, August 02, 2005 18:17:33 -0700):
>> --Andrew Morton <akpm@osdl.org> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
>>
>>> "Martin J. Bligh" <mbligh@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,
M.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-07 13:44 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-08 16:48 ` Christoph Lameter
2005-08-08 17:10 ` 2.6.13-rc3-mm3 Russell King
` (2 more replies)
0 siblings, 3 replies; 94+ messages in thread
From: Christoph Lameter @ 2005-08-08 16:48 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, linux-kernel, nickpiggin, linux-arm
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?
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);
}
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-08 16:48 ` 2.6.13-rc3-mm3 Christoph Lameter
@ 2005-08-08 17:10 ` Russell King
2005-08-08 17:15 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 20:40 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-08 22:12 ` 2.6.13-rc3-mm3 Richard Purdie
2 siblings, 1 reply; 94+ messages in thread
From: Russell King @ 2005-08-08 17:10 UTC (permalink / raw)
To: Christoph Lameter
Cc: Richard Purdie, Andrew Morton, linux-kernel, nickpiggin,
linux-arm
On Mon, Aug 08, 2005 at 09:48:22AM -0700, Christoph Lameter wrote:
> 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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-08 17:10 ` 2.6.13-rc3-mm3 Russell King
@ 2005-08-08 17:15 ` Christoph Lameter
0 siblings, 0 replies; 94+ messages in thread
From: Christoph Lameter @ 2005-08-08 17:15 UTC (permalink / raw)
To: Russell King
Cc: Richard Purdie, Andrew Morton, linux-kernel, nickpiggin,
linux-arm
On Mon, 8 Aug 2005, Russell King wrote:
> 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.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-08 16:48 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 17:10 ` 2.6.13-rc3-mm3 Russell King
@ 2005-08-08 20:40 ` Richard Purdie
2005-08-08 22:12 ` 2.6.13-rc3-mm3 Richard Purdie
2 siblings, 0 replies; 94+ messages in thread
From: Richard Purdie @ 2005-08-08 20:40 UTC (permalink / raw)
To: Christoph Lameter
Cc: Russell King, Andrew Morton, linux-kernel, nickpiggin, linux-arm
On Mon, 2005-08-08 at 09:48 -0700, Christoph Lameter wrote:
> 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?
>
> + 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);
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
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-08 16:48 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 17:10 ` 2.6.13-rc3-mm3 Russell King
2005-08-08 20:40 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-08 22:12 ` Richard Purdie
2005-08-09 0:57 ` 2.6.13-rc3-mm3 Christoph Lameter
2 siblings, 1 reply; 94+ messages in thread
From: Richard Purdie @ 2005-08-08 22:12 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Andrew Morton, nickpiggin, linux-kernel
I've done a bit of analysis:
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);
}
/*
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-rc3-mm3
2005-08-08 22:12 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-08-09 0:57 ` Christoph Lameter
0 siblings, 0 replies; 94+ messages in thread
From: Christoph Lameter @ 2005-08-09 0:57 UTC (permalink / raw)
To: Richard Purdie; +Cc: Andrew Morton, nickpiggin, linux-kernel
On Mon, 8 Aug 2005, Richard Purdie wrote:
> 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 <clameter@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);
}
/*
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?)
2005-09-14 14:32 ` 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?) Martin J. Bligh
@ 2005-09-14 14:09 ` Anton Blanchard
0 siblings, 0 replies; 94+ messages in thread
From: Anton Blanchard @ 2005-09-14 14:09 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linux-kernel, SCSI Mailing List
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);
^ permalink raw reply [flat|nested] 94+ messages in thread
* 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?)
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
` (12 preceding siblings ...)
2005-08-01 1:43 ` 2.6.13-rc3-mm3 Richard Purdie
@ 2005-09-14 14:32 ` Martin J. Bligh
2005-09-14 14:09 ` Anton Blanchard
13 siblings, 1 reply; 94+ messages in thread
From: Martin J. Bligh @ 2005-09-14 14:32 UTC (permalink / raw)
To: Andrew Morton, linux-kernel; +Cc: SCSI Mailing List
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)
( ... repeated forever)
2.6.13-git11 worked.
^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2005-09-14 14:41 UTC | newest]
Thread overview: 94+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-28 9:58 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 10:44 ` [-mm patch] fix MTRR compilation with SMP=n Adrian Bunk
2005-07-28 17:11 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-07-28 19:52 ` 2.6.13-rc3-mm3 Russell King
2005-07-28 20:06 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-07-28 19:11 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
2005-07-28 19:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 21:40 ` 2.6.13-rc3-mm3 Rafael J. Wysocki
2005-07-28 23:31 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 7:06 ` 2.6.13-rc3-mm3 Matthias Urlichs
2005-07-29 9:27 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 12:01 ` 2.6.13-rc3-mm3 Matthias Urlichs
2005-07-29 14:12 ` Regression hunting with git (was: Re: 2.6.13-rc3-mm3) Matthias Urlichs
2005-07-28 20:34 ` 2.6.13-rc3-mm3 Adrian Bunk
2005-07-28 22:09 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 20:15 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-28 20:56 ` 2.6.13-rc3-mm3 Nick Sillik
2005-07-28 23:16 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 20:29 ` 2.6.13-rc3-mm3 Adrian Bunk
2005-07-28 23:29 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-28 22:02 ` 2.6.13-rc3-mm3 Dirk
2005-07-28 23:46 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 15:48 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-29 19:33 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-30 0:00 ` 2.6.13-rc3-mm3 Michael Thonke
2005-07-29 5:58 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 6:08 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-29 15:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 16:15 ` 2.6.13-rc3-mm3 Eric W. Biederman
2005-07-29 6:01 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 6:10 ` 2.6.13-rc3-mm3 Andrew Morton
2005-08-03 1:17 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-08-03 4:21 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-08-07 23:23 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 6:02 ` 2.6.13-rc3-mm3 Martin J. Bligh
2005-07-29 23:05 ` 2.6.13-rc3-mm3 Khalid Aziz
2005-07-29 23:17 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-30 15:33 ` 2.6.13-rc3-mm3 Khalid Aziz
2005-07-30 18:02 ` 2.6.13-rc3-mm3 Andrew Morton
2005-08-01 15:36 ` 2.6.13-rc3-mm3 Bjorn Helgaas
2005-07-30 10:27 ` 2.6.13-rc3-mm3 Richard Purdie
2005-07-30 17:05 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 9:04 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 9:16 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 11:12 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 12:46 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 17:35 ` 2.6.13-rc3-mm3 Andrew Morton
2005-07-31 18:21 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 18:25 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-07-31 18:41 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-07-31 18:59 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-07-31 21:35 ` 2.6.13-rc3-mm3 Stelian Pop
[not found] ` <Pine.LNX.4.58.0507311125360.29650@g5.osdl.org>
[not found] ` <1122846072.17880.43.camel@deep-space-9.dsnet>
[not found] ` <Pine.LNX.4.58.0507311557020.14342@g5.osdl.org>
2005-08-01 14:37 ` 2.6.13-rc3-mm3 Stelian Pop
2005-08-02 9:49 ` 2.6.13-rc3-mm3 Stelian Pop
2005-08-02 10:32 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-08-02 11:40 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 14:04 ` 2.6.13-rc3-mm3 Manuel Lauss
2005-08-02 15:48 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 16:50 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 17:11 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 21:13 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 21:21 ` 2.6.13-rc3-mm3 Greg KH
2005-08-02 21:47 ` 2.6.13-rc3-mm3 Ivan Kokshaysky
2005-08-02 21:57 ` 2.6.13-rc3-mm3 Linus Torvalds
2005-08-02 22:59 ` [patch 1/2] increase PCIBIOS_MIN_IO on x86 Ivan Kokshaysky
2005-08-02 23:09 ` [patch 2/2] ACPI: " Ivan Kokshaysky
2005-08-01 1:43 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 16:10 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 20:02 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 20:36 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 21:07 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 21:16 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 21:27 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 21:40 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 21:52 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 22:02 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 22:19 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 23:01 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-01 23:16 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-01 23:32 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-04 0:19 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-04 11:27 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-04 14:04 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-04 14:37 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-05 15:17 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-07 13:44 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-08 16:48 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 17:10 ` 2.6.13-rc3-mm3 Russell King
2005-08-08 17:15 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-08-08 20:40 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-08 22:12 ` 2.6.13-rc3-mm3 Richard Purdie
2005-08-09 0:57 ` 2.6.13-rc3-mm3 Christoph Lameter
2005-09-14 14:32 ` 2.6.13-mm3 and 2.6.14-rc1 both broken (SCSI?) Martin J. Bligh
2005-09-14 14:09 ` Anton Blanchard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox