* Re: 2.6.17-mm6 @ 2006-07-07 14:21 Martin J. Bligh 0 siblings, 0 replies; 111+ messages in thread From: Martin J. Bligh @ 2006-07-07 14:21 UTC (permalink / raw) To: Andrew Morton; +Cc: Linux Kernel Mailing List, Andy Whitcroft Oooh. it actually seems to work across all of our tests. On all the machines (well all the ones that are working). /me dances a little jig. Congrats ;-) M. ^ permalink raw reply [flat|nested] 111+ messages in thread
* 2.6.17-mm6
@ 2006-07-03 10:03 Andrew Morton
2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski
` (10 more replies)
0 siblings, 11 replies; 111+ messages in thread
From: Andrew Morton @ 2006-07-03 10:03 UTC (permalink / raw)
To: linux-kernel
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/
- A major update to the e1000 driver.
- 1394 updates
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail majordomo@vger.kernel.org
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
Changes since 2.6.17-mm5:
origin.patch
git-acpi.patch
git-alsa.patch
git-cpufreq.patch
git-geode.patch
git-gfs2.patch
git-ia64.patch
git-ia64-fixup.patch
git-infiniband.patch
git-jfs.patch
git-kbuild.patch
git-klibc.patch
git-hdrinstall2.patch
git-libata-all.patch
git-mtd.patch
git-netdev-all.patch
git-e1000.patch
git-nfs.patch
git-ocfs2.patch
git-pcmcia-fixup.patch
git-powerpc.patch
git-sas.patch
git-scsi-misc.patch
git-scsi-target.patch
git-supertrak.patch
git-watchdog.patch
git-wireless.patch
git-xfs.patch
git-cryptodev.patch
git trees.
-pi-futex-fix-mm_struct-memory-leak.patch
-irq-use-sa_percpu_irq-not-irq_per_cpu-for-irqactionflags.patch
-irq-warning-message-cleanup.patch
-edac-bug-fix-module-names-quoted-in-sysfs.patch
-pi-futex-futex_wake-lockup-fix.patch
-acpi-identify-which-device-is-not-power-manageable.patch
-pnpacpi-support-shareable-interrupts.patch
-serial-allow-shared-8250_pnp-interrupts.patch
-ib-ipath-name-zero-counter-offsets-so-its-clear.patch
-ib-ipath-update-copyrights-and-other-strings-to.patch
-ib-ipath-share-more-common-code-between-rc-and-uc.patch
-ib-ipath-fix-an-indenting-problem.patch
-ib-ipath-fix-shared-receive-queues-for-rc.patch
-ib-ipath-allow-diags-on-any-unit.patch
-ib-ipath-update-some-comments-and-fix-typos.patch
-ib-ipath-remove-some-duplicate-code.patch
-ib-ipath-dont-allow-resources-to-be-created-with.patch
-ib-ipath-fix-some-memory-leaks-on-failure-paths.patch
-ib-ipath-return-an-error-for-unknown-multicast-gid.patch
-ib-ipath-report-correct-device-identification.patch
-ib-ipath-enforce-device-resource-limits.patch
-ib-ipath-removed-unused-field-ipath_kregvirt-from.patch
-ib-ipath-print-better-debug-info-when-handling.patch
-ib-ipath-enable-freeze-mode-when-shutting-down.patch
-ib-ipath-use-more-appropriate-gfp-flags.patch
-ib-ipath-use-vmalloc-to-allocate-struct.patch
-ib-ipath-memory-management-cleanups.patch
-ib-ipath-reduce-overhead-on-receive-interrupts.patch
-ib-ipath-fixed-bug-9776.patch
-ib-ipath-fix-lost-interrupts-on-ht-400.patch
-ib-ipath-disallow-send-of-invalid-packet-sizes.patch
-ib-ipath-dont-confuse-the-max-message-size-with.patch
-ib-ipath-removed-redundant-statements.patch
-ib-ipath-check-for-valid-lid-and-multicast-lids.patch
-ib-ipath-fixes-to-performance-get-counters-for-ib.patch
-ib-ipath-rc-receive-interrupt-performance-changes.patch
-ib-ipath-purge-sps_lid-and-sps_mlid-arrays.patch
-ib-ipath-drop-the-stats-sysfs-attribute-group.patch
-ib-ipath-support-more-models-of-infinipath-hardware.patch
-ib-ipath-read-write-correct-sizes-through-diag.patch
-ib-ipath-fix-a-bug-that-results-in-addresses-near.patch
-ib-ipath-remove-some-if-0-code-related-to.patch
-ib-ipath-ignore-receive-queue-size-if-srq-is.patch
-ib-ipath-namespace-cleanup-replace-ips-with-ipath.patch
-enhancing-accessibility-of-lxdialog.patch
-mmc-check-sdhci-base-clock.patch
-mmc-print-device-id.patch
-mmc-support-for-multiple-voltages.patch
-mmc-fix-timeout-loops-in-sdhci.patch
-mmc-fix-sdhci-reset-timeout.patch
-mmc-proper-timeout-handling.patch
-mmc-correct-register-order.patch
-mmc-fix-interrupt-handling.patch
-mmc-fix-sdhci-pio-routines.patch
-mmc-avoid-sdhci-dma-boundaries.patch
-mmc-test-for-invalid-block-size.patch
-mmc-check-only-relevant-inhibit-bits.patch
-mmc-check-controller-version.patch
-mmc-reset-sdhci-controller-early.patch
-mmc-more-dma-capabilities-tests.patch
-mmc-support-controller-specific-quirks.patch
-mmc-version-bump-sdhci.patch
-mmc-add-sdhci-controller-ids.patch
-mmc-quirk-for-broken-reset.patch
-mmc-force-dma-on-some-controllers.patch
-mmc-remove-duplicate-error-message.patch
-typo-in-drivers-net-e1000-e1000_hwc.patch
-fix-implicit-declaration-on-cell.patch
-xfs-pass-inode-to-xfs_ioc_space.patch
-smp-alternatives-skip-with-up-kernels.patch
-uml-make-copy__user-atomic.patch
-uml-fix-not_dead_yet-when-directory-is-in-bad-state.patch
-uml-rename-and-improve-actually_do_remove.patch
-binfmt_elf-fix-checks-for-bad-address.patch
-binfmt_elf-fix-checks-for-bad-address-fix.patch
-ufs-truncate-should-allocate-block-for-last-byte.patch
-fix-is_err-threshold-value.patch
-rtc-class-driver-for-samsung-s3c-series-soc.patch
-rtc-class-driver-for-samsung-s3c-series-soc-tidy.patch
-hotcpu_notifier-fixes.patch
-add-___rodata-sections-to-asm-generic-sectionsh.patch
-add-___rodata-sections-to-asm-generic-sectionsh-fix.patch
-s390-put-sys_call_table-into-rodata-section-and-write-protect-it.patch
-reiserfs-update-ctime-and-mtime-on-expanding-truncate.patch
-kernel-doc-consistent-text-man-mode-output.patch
-fix-problem-with-atapi-dma-on-it8212-in-linux.patch
-kernel-doc-make-man-text-mode-function-output-same.patch
-drivers-block-nbdc-compile-fix.patch
-pnp-suppress-request_irq-warning.patch
Merged into mainline or a subsystem tree.
+time-initialisation-fix.patch
+genirq-ia64-cleanup.patch
+lockdep-special-s390-print_symbol-version.patch
+bcm43xx-netlink-deadlock-fix.patch
+uml-build-fix.patch
+pnpacpi-support-shareable-interrupts.patch
+serial-allow-shared-8250_pnp-interrupts.patch
+zvc-zone_reclaim-leave-1%-of-unmapped-pagecache-pages-for-file-i-o.patch
+binfmt_elf-fix-checks-for-bad-address.patch
+kernel-doc-maintainers.patch
+add-mike-isely-as-pvrusb2-maintainer.patch
+fbdev-add-framebuffer-and-display-update-module-support.patch
+vt-decrement-ref-count-of-the-vt-backend-on-deallocation.patch
+make-more-file_operation-structs-static.patch
+sparc-i8042-build-fix.patch
2.6.18-rc1 queue
-lockdep-core-improve-bug-messages.patch
-lockdep-core-add-set_class_and_name.patch
-lockdep-core-add-set_class_and_name-fix.patch
Folded into lockdep-core.patch
+lockdep-allow-read_lock-recursion-of-same-class.patch
Lockdep feature.
-lockdep-annotate-blkdev-nesting-fix.patch
Folded into lockdep-annotate-blkdev-nesting.patch
-lockdep-annotate-sk_locks-fix.patch
Folded into lockdep-annotate-sk_locks.patch
+lockdep-annotate-hostap-netdev-xmit_lock.patch
Lockdep false-positive avoidance.
+sparc-resource-warning-fixes.patch
sparc warning fix
+git-ia64-fixup.patch
Fix rejects in git-ia64.patch
+ieee1394-sbp2-enable-auto-spin-up-for-maxtor-disks.patch
+ieee1394-fix-calculation-of-csr-expire.patch
+ieee1394-fix-cosmetic-problem-in-speed-probe.patch
+ieee1394-skip-dummy-loop-in-build_speed_map.patch
+ieee1394-replace-__inline__-by-inline.patch
+ieee1394-coding-style-and-comment-fixes-in-midlayer.patch
+ieee1394-update-include-directives-in-midlayer-header.patch
+ieee1394-remove-redundant-code-from-ieee1394_hotplugh.patch
+ieee1394-remove-unused-macros-hpsb_panic-and.patch
+ieee1394-clean-up-declarations-of-hpsb__config_rom.patch
+ieee1394-dv1394-sem2mutex-conversion.patch
+ieee1394-raw1394-remove-redundant-counting-semaphore.patch
+ieee1394-nodemgr-remove-unnecessary-includes.patch
+ieee1394-nodemgr-do-not-spawn-kernel_thread-for-sysfs.patch
+ieee1394-nodemgr-make-module-parameter-ignore_drivers.patch
+ieee1394-nodemgr-switch-to-kthread-api-replace-reset.patch
+ieee1394-nodemgr-convert-nodemgr_serialize-semaphore.patch
+ieee1394-fix-kerneldoc-of-hpsb_alloc_host.patch
+ieee1394-shrink-tlabel-pools-remove-tpool-semaphores.patch
1394 updates
-revert-sparc-build-breakage.patch
Unneeded.
+git-e1000-fixup.patch
Fix reject in git-e1000.patch
+e1000-irq-naming-update.patch
Update e1000 to the new IRQ naming scheme.
+net-adduse-poison-defines.patch
+atm-adduse-poison-defines.patch
net cleanups
+revert-gregkh-pci-msi-drop-pci_msi_quirk.patch
+revert-gregkh-pci-msi-stop-inheriting-bus-flags-and-check-root-chipset-bus-flags-instead.patch
+revert-gregkh-pci-msi-factorize-common-msi-detection-code-from-pci_enable_msi-and-msix.patch
+revert-gregkh-pci-msi-blacklist-pci-e-chipsets-depending-on-hypertransport-msi-capabality.patch
+revert-gregkh-pci-msi-rename-pci_cap_id_ht_irqconf-into-pci_cap_id_ht.patch
+revert-gregkh-pci-msi-merge-existing-msi-disabling-quirks.patch
Revert some bad patches from the PCI tree.
+git-scsi-misc-fixup.patch
Fix reject due to git-scsi-misc.patch
-make-drivers-scsi-aic7xxx-aic79xx_coreahd_set_tags-static.patch
Dropped (accidentally, I think).
-my-name-is-ingo-molnar-you-killed-my-make-allyesconfig-prepare-to-die.patch
Ditto.
+x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions.patch
+x86_64-mm-add-abilty-to-enable-disable-nmi-watchdog-from-sysfs.patch
+x86_64-mm-add-abilty-to-enable-disable-nmi-watchdog-from-procfs-update.patch
+x86_64-mm-x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix.patch
+x86_64-mm-x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86-fix-fix.patch
+x86_64-mm-x86_64-mm-remove-un-set_nmi_callback-and-reserve-release_lapic_nmi-functions-x86_64-fix.patch
+x86_64-mm-allow-users-to-force-a-panic-on-nmi.patch
+x86_64-mm-x86-clean-up-nmi-panic-messages.patch
+x86_64-mm-x86-nmi-fix.patch
+x86_64-mm-x86-nmi-fix-2.patch
+x86_64-mm-make-functions-static.patch
+x86_64-mm-kdump-x86_64-nmi-event-notification-fix.patch
+x86_64-mm-kdump-i386-nmi-event-notification-fix.patch
+x86_64-mm-i386-enable-nmi-wdog.patch
+x86_64-mm-add-nmi-watchdog-support-for-new-intel-cpus.patch
x86_64 tree updates
+mm-x86_64-mm-init-rdtscp-warning-fix.patch
Fix it.
+sleazy-fpu-feature-x86_64-support.patch
+sleazy-fpu-feature-x86_64-support-fix.patch
+sleazy-fpu-feature-i386-support.patch
Speed up floating point handling a bit.
+x86_64-fix-calgary-copyright-statements-per-ibm-guidelines.patch
+x86_64-add-a-maintainers-entry-for-calgary.patch
x86_64 updates.
-mm-tracking-shared-dirty-pages-update.patch
Folded into mm-tracking-shared-dirty-pages.patch
-mm-msync-cleanup-fix.patch
Folded into mm-msync-cleanup.patch
+x86-re-enable-generic-numa.patch
Permit x86-on-NUMA
fix-boot-on-efi-32-bit-machines.patch
+ia64-kprobe-invalidate-icache-of-jump-buffer.patch
ia64 kprobes fix
-apple-motion-sensor-driver-update.patch
-apple-motion-sensor-driver-update-2.patch
Folded into apple-motion-sensor-driver.patch
+fat-cleanup-fat_get_blocks.patch
+make-valid_mmap_phys_addr_range-take-a-pfn.patch
+valid_mmap_phys_addr_range-cleanup.patch
+char-rtc-handle-memory-mapped-chips-properly.patch
+char-rtc-handle-memory-mapped-chips-properly-cleanup.patch
+inode_diet-replace-inodeugeneric_ip-with-inodei_private.patch
+inode-diet-move-i_pipe-into-a-union.patch
+inode-diet-move-i_bdev-into-a-union.patch
+inode-diet-move-i_cdev-into-a-union.patch
+inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch
+inode-diet-fix-size-of-i_blkbits-i_version-and-i_dnotify_mask.patch
+reiserfsfix-journaling-issue-regarding-fsync.patch
+x86-microcode-microcode-driver-cleanup.patch
+x86-microcode-microcode-driver-cleanup-tidy.patch
+x86-microcode-using-request_firmware-to-pull-microcode.patch
+x86-microcode-add-sysfs-and-hotplug-support.patch
+x86-microcode-add-sysfs-and-hotplug-support-fix.patch
Misc updates.
-reiserfs-reorganize-bitmap-loading-functions-fix.patch
-reiserfs-reorganize-bitmap-loading-functions-fix2.patch
Folded into reiserfs-reorganize-bitmap-loading-functions.patch
-reiserfs-on-demand-bitmap-loading-fix.patch
Folded into reiserfs-on-demand-bitmap-loading.patch
-per-task-delay-accounting-setup-fix-1.patch
-per-task-delay-accounting-setup-fix-2.patch
Folded into per-task-delay-accounting-setup.patch
-per-task-delay-accounting-sync-block-i-o-and-swapin-delay-collection-fix-1.patch
Folded into per-task-delay-accounting-sync-block-i-o-and-swapin-delay-collection.patch
-per-task-delay-accounting-cpu-delay-collection-via-schedstats-fix-1.patch
Folded into per-task-delay-accounting-cpu-delay-collection-via-schedstats.patch
-per-task-delay-accounting-taskstats-interface-fix-1.patch
-per-task-delay-accounting-taskstats-interface-fix-2.patch
-per-task-delay-accounting-taskstats-interface-tidy.patch
Folded into per-task-delay-accounting-taskstats-interface.patch
-per-task-delay-accounting-proc-export-of-aggregated-block-i-o-delays-warning-fix.patch
Folded into per-task-delay-accounting-proc-export-of-aggregated-block-i-o-delays.patch
-delay-accounting-taskstats-interface-send-tgid-once-fixes.patch
-delay-accounting-taskstats-interface-send-tgid-once-locking.patch
Folded into delay-accounting-taskstats-interface-send-tgid-once.patch
-ecryptfs-fs-makefile-and-fs-kconfig-remove-ecrypt_debug-from-fs-kconfig.patch
Folded into ecryptfs-fs-makefile-and-fs-kconfig.patch
-ecryptfs-main-module-functions-uint16_t-u16.patch
Folded into ecryptfs-main-module-functions.patch
-ecryptfs-header-declarations-update.patch
-ecryptfs-header-declarations-update-convert-signed-data-types-to-unsigned-data-types.patch
-ecryptfs-header-declarations-remove-unnecessary-ifndefs.patch
Folded into ecryptfs-header-declarations.patch
-ecryptfs-superblock-operations-ecryptfs_statfs-api-change.patch
Folded into ecryptfs-superblock-operations.patch
-ecryptfs-file-operations-remove-null-==-syntax.patch
-ecryptfs-file-operations-remove-extraneous-read-of-inode-size-from-header.patch
-ecryptfs-file-operations-fix.patch
-ecryptfs-file-operations-fix-premature-release-of-file_info-memory.patch
Folded into ecryptfs-file-operations.patch
-mark-address_space_operations-const-vs-ecryptfs-mmap-operations.patch
Folded into ecryptfs-mmap-operations.patch
-ecryptfs-crypto-functions-fix-filesize-on-hard-link-creation.patch
Folded into ecryptfs-crypto-functions.patch
-ecryptfs-more-elegant-aes-key-size-manipulation-tidy.patch
Folded into ecryptfs-more-elegant-aes-key-size-manipulation.patch
-ecryptfs-validate-packet-length-prior-to-parsing-add-comments-fix.patch
Folded into ecryptfs-validate-packet-length-prior-to-parsing-add-comments.patch
+inode-diet-move-i_pipe-into-a-union-ecryptfs.patch
+inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-ecryptfs.patch
Fix ecryptfs for the inode-shrinkage patches.
-namespaces-utsname-switch-to-using-uts-namespaces-alpha-fix.patch
-namespaces-utsname-switch-to-using-uts-namespaces-cleanup.patch
Folded into namespaces-utsname-switch-to-using-uts-namespaces.patch
-namespaces-utsname-use-init_utsname-when-appropriate-cifs-update.patch
Folded into namespaces-utsname-use-init_utsname-when-appropriate.patch
-namespaces-utsname-implement-utsname-namespaces-export.patch
-namespaces-utsname-implement-utsname-namespaces-dont-include-compileh.patch
-namespaces-utsname-implement-utsname-namespaces-remove-unused-exit_utsname.patch
Folded into namespaces-utsname-implement-utsname-namespaces.patch
-namespaces-utsname-sysctl-hack-cleanup.patch
-namespaces-utsname-sysctl-hack-cleanup-2.patch
-namespaces-utsname-sysctl-hack-cleanup-2-fix.patch
Folded into namespaces-utsname-sysctl-hack.patch
-namespaces-utsname-implement-clone_newuts-flag-tidy.patch
Folded into namespaces-utsname-implement-clone_newuts-flag.patch
-ipc-namespace-core-fix.patch
-ipc-namespace-core-unshare-fix.patch
Folded into ipc-namespace-core.patch
-ipc-namespace-utils-compilation-fix.patch
Folded into ipc-namespace-utils.patch
-task-watchers-task-watchers-tidy.patch
Folded into task-watchers-task-watchers.patch
-task-watchers-add-support-for-per-task-watchers-warning-fix.patch
Folded into task-watchers-add-support-for-per-task-watchers.patch
-task-watchers-register-semundo-task-watcher-cleanup.patch
Folded into task-watchers-register-semundo-task-watcher.patch
-readahead-kconfig-option-readahead_allow_overheads.patch
Folded into readahead-kconfig-options.patch
-readahead-state-based-method-routines-no-ra_flag_eof-on-single-page-file.patch
Folded into readahead-state-based-method-routines.patch
-readahead-state-based-method-readahead-state-based-method-stand-alone-size-limit-code.patch
-readahead-state-based-method-aging-accounting-readahead-kconfig-option-readahead_smooth_aging.patch
Folded into readahead-state-based-method.patch
-readahead-context-based-method-apply-stream_shift-size-limits-to-contexta-method.patch
-readahead-context-based-method-fix-remain-counting.patch
-readahead-context-based-method-slow-start.patch
Folded into readahead-context-based-method.patch
-readahead-initial-method-guiding-sizes-aggressive-initial-sizes.patch
Folded into readahead-initial-method-guiding-sizes.patch
-readahead-backward-prefetching-method-add-use-case-comment.patch
Folded into readahead-backward-prefetching-method.patch
-readahead-call-scheme-fix-fastcall.patch
-readahead-call-scheme-no-fastcall-for-readahead_cache_hit.patch
-readahead-call-scheme-no-fastcall-for-readahead_cache_hit-kconfig-option-readahead_hit_feedback.patch
Folded into readahead-call-scheme.patch
+inode_diet-replace-inodeugeneric_ip-with-inodei_private-reiser4.patch
+inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default-reiser4.patch
Fix reiser4 for the inode-diet patches
+vt-remove-vt-specific-declarations-and-definitions-from-fix.patch
Fix vt-remove-vt-specific-declarations-and-definitions-from.patch
+tty-remove-include-of-screen_infoh-from-ttyh-fix.patch
+tty-remove-include-of-screen_infoh-from-ttyh-fix-fix.patch
Fix tty-remove-include-of-screen_infoh-from-ttyh.patch
+md-oops-workaround.patch
Work around an oops in MD. (triggered by the now-hopefully-fixed barrier bug).
-statistics-infrastructure-update-1.patch
-statistics-infrastructure-update-2.patch
-statistics-infrastructure-update-3.patch
-statistics-infrastructure-update-4.patch
-statistics-infrastructure-update-5.patch
-statistics-infrastructure-update-6.patch
-statistics-infrastructure-update-7.patch
-statistics-infrastructure-update-8.patch
Folded into Folded into statistics-infrastructure.patch
-genirq-add-chip-eoi-fastack-fasteoi-x86_64.patch
Folded into genirq-convert-the-x86_64-architecture-to-irq-chips.patch
-genirq-convert-the-i386-architecture-to-irq-chips-fix-2.patch
-genirq-add-chip-eoi-fastack-fasteoi-x86.patch
Folded into genirq-convert-the-i386-architecture-to-irq-chips.patch
-genirq-x86_64-irq-reenable-migrating-irqs-to-other-cpus-fix.patch
Folded into genirq-x86_64-irq-reenable-migrating-irqs-to-other-cpus.patch
-genirq-msi-simplify-msi-enable-and-disable-fix.patch
Folded into genirq-msi-simplify-msi-enable-and-disable.patch
-genirq-ia64-irq-dynamic-irq-support-fix.patch
Folded into genirq-ia64-irq-dynamic-irq-support.patch
-genirq-i386-irq-dynamic-irq-support-fix.patch
Folded into genirq-i386-irq-dynamic-irq-support.patch
+genirq-msi-only-build-msi-apicc-on-ia64-fix.patch
Folded into genirq-msi-only-build-msi-apicc-on-ia64.patch
-genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector-fix.patch
-genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector-fix-tidies.patch
Folded into genirq-i386-irq-remove-the-msi-assumption-that-irq-==-vector.patch
-srcu-rcu-variant-permitting-read-side-blocking-fixes.patch
Folded into srcu-rcu-variant-permitting-read-side-blocking.patch
-srcu-add-srcu-operations-to-rcutorture-fix.patch
-srcu-add-srcu-operations-to-rcutorture-tidy-2.patch
Folded into srcu-add-srcu-operations-to-rcutorture.patch
-srcu-2-add-srcu-operations-to-rcutorture-fix.patch
Folded into srcu-2-add-srcu-operations-to-rcutorture.patch
-export_unused_symbolgpl-unregister_die_notifier.patch
Dropped.
All 704 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/patch-list
^ permalink raw reply [flat|nested] 111+ messages in thread* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton @ 2006-07-03 10:50 ` Michal Piotrowski 2006-07-03 10:56 ` 2.6.17-mm6 Andrew Morton 2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly ` (9 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: Michal Piotrowski @ 2006-07-03 10:50 UTC (permalink / raw) To: Andrew Morton; +Cc: Tigran Aivazian, linux-kernel Hi, On 03/07/06, Andrew Morton <akpm@osdl.org> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > Something is missing in drivers/base/firmware_class.c? WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko needs unknown symbol release_firmware WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko needs unknown symbol request_firmware WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko needs unknown symbol release_firmware WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko needs unknown symbol request_firmware Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski @ 2006-07-03 10:56 ` Andrew Morton 2006-07-03 11:36 ` 2.6.17-mm6 Michal Piotrowski 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 10:56 UTC (permalink / raw) To: Michal Piotrowski; +Cc: tigran, linux-kernel On Mon, 3 Jul 2006 12:50:26 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: > Hi, > > On 03/07/06, Andrew Morton <akpm@osdl.org> wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > Something is missing in drivers/base/firmware_class.c? > > WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko > needs unknown symbol release_firmware > WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko > needs unknown symbol request_firmware > WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko > needs unknown symbol release_firmware > WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko > needs unknown symbol request_firmware > Presumably you'll need CONFIG_FW_LOADER? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:56 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 11:36 ` Michal Piotrowski 2006-07-03 12:27 ` 2.6.17-mm6 Michal Piotrowski 0 siblings, 1 reply; 111+ messages in thread From: Michal Piotrowski @ 2006-07-03 11:36 UTC (permalink / raw) To: Andrew Morton; +Cc: tigran, linux-kernel Andrew Morton wrote: > On Mon, 3 Jul 2006 12:50:26 +0200 > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: > >> Hi, >> >> On 03/07/06, Andrew Morton <akpm@osdl.org> wrote: >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ >>> >> Something is missing in drivers/base/firmware_class.c? >> >> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >> needs unknown symbol release_firmware >> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >> needs unknown symbol request_firmware >> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >> needs unknown symbol release_firmware >> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >> needs unknown symbol request_firmware >> > > Presumably you'll need CONFIG_FW_LOADER? > Yes, thanks. How about this patch? Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/arch/i386/Kconfig linux-mm/arch/i386/Kconfig --- linux-mm-clean/arch/i386/Kconfig 2006-07-03 12:35:16.000000000 +0200 +++ linux-mm/arch/i386/Kconfig 2006-07-03 13:26:51.000000000 +0200 @@ -399,6 +399,7 @@ config X86_REBOOTFIXUPS config MICROCODE tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support" + depends on FW_LOADER ---help--- If you say Y here and also to "/dev file system support" in the 'File systems' section, you will be able to update the microcode on ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:36 ` 2.6.17-mm6 Michal Piotrowski @ 2006-07-03 12:27 ` Michal Piotrowski 2006-07-03 13:28 ` 2.6.17-mm6 Dmitry Torokhov 0 siblings, 1 reply; 111+ messages in thread From: Michal Piotrowski @ 2006-07-03 12:27 UTC (permalink / raw) To: Michal Piotrowski; +Cc: Andrew Morton, tigran, linux-kernel, Greg KH > Andrew Morton wrote: >> On Mon, 3 Jul 2006 12:50:26 +0200 >> "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: >> >>> Hi, >>> >>> On 03/07/06, Andrew Morton <akpm@osdl.org> wrote: >>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ >>>> >>> Something is missing in drivers/base/firmware_class.c? >>> >>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >>> needs unknown symbol release_firmware >>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >>> needs unknown symbol request_firmware >>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >>> needs unknown symbol release_firmware >>> WARNING: /lib/modules/2.6.17-mm6/kernel/arch/i386/kernel/microcode.ko >>> needs unknown symbol request_firmware >>> >> Presumably you'll need CONFIG_FW_LOADER? >> > > Yes, thanks. How about this patch? > Here is an updated version of this patch. Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/arch/i386/Kconfig linux-mm/arch/i386/Kconfig --- linux-mm-clean/arch/i386/Kconfig 2006-07-03 12:35:16.000000000 +0200 +++ linux-mm/arch/i386/Kconfig 2006-07-03 14:07:15.000000000 +0200 @@ -399,9 +399,9 @@ config X86_REBOOTFIXUPS config MICROCODE tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support" + depends on FW_LOADER ---help--- - If you say Y here and also to "/dev file system support" in the - 'File systems' section, you will be able to update the microcode on + If you say Y here, you will be able to update the microcode on Intel processors in the IA32 family, e.g. Pentium Pro, Pentium II, Pentium III, Pentium 4, Xeon etc. You will obviously need the actual microcode binary data itself which is not shipped with the ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:27 ` 2.6.17-mm6 Michal Piotrowski @ 2006-07-03 13:28 ` Dmitry Torokhov 0 siblings, 0 replies; 111+ messages in thread From: Dmitry Torokhov @ 2006-07-03 13:28 UTC (permalink / raw) To: Michal Piotrowski; +Cc: Andrew Morton, tigran, linux-kernel, Greg KH On Monday 03 July 2006 08:27, Michal Piotrowski wrote: > diff -uprN -X linux-mm/Documentation/dontdiff linux-mm-clean/arch/i386/Kconfig linux-mm/arch/i386/Kconfig > --- linux-mm-clean/arch/i386/Kconfig 2006-07-03 12:35:16.000000000 +0200 > +++ linux-mm/arch/i386/Kconfig 2006-07-03 14:07:15.000000000 +0200 > @@ -399,9 +399,9 @@ config X86_REBOOTFIXUPS > > config MICROCODE > tristate "/dev/cpu/microcode - Intel IA32 CPU microcode support" > + depends on FW_LOADER Wouldn't "select" be better here? -- Dmitry ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton 2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski @ 2006-07-03 11:00 ` Reuben Farrelly 2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton ` (2 more replies) 2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater ` (8 subsequent siblings) 10 siblings, 3 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-03 11:00 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, greg, brice On 3/07/2006 10:03 p.m., Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > - A major update to the e1000 driver. > > - 1394 updates audit: initializing netlink socket (disabled) audit(1151924044.008:1): initialized SELinux: Registering netfilter hooks Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered (default) PCI: Setting latency timer of device 0000:00:1c.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.0:pcie0] Allocate Port Service[0000:00:1c.0:pcie0] kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [<ffffffff80358298>] kobject_put+0x19/0x21 [<ffffffff80358741>] kobject_add+0x181/0x1ac [<ffffffff803aa378>] device_add+0x88/0x4b9 [<ffffffff803aa7c2>] device_register+0x19/0x27 [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 [<ffffffff803ac162>] __driver_attach+0x0/0xb9 [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 [<ffffffff803abfbc>] driver_attach+0x1c/0x1e [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 [<ffffffff803ac463>] driver_register+0x9f/0xa6 [<ffffffff80361497>] __pci_register_driver+0x59/0x7e [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 [<ffffffff80267f3e>] init+0x14e/0x2d0 [<ffffffff80260a12>] child_rip+0x8/0x12 [<ffffffff80267df0>] init+0x0/0x2d0 [<ffffffff80260a0a>] child_rip+0x0/0x12 The trace shows up 5 times in quick succession, all traces looking the same....... Box otherwise boots up OK. reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly @ 2006-07-03 11:25 ` Andrew Morton 2006-07-03 12:34 ` 2.6.17-mm6 Reuben Farrelly 2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton 2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov 2 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 11:25 UTC (permalink / raw) To: Reuben Farrelly; +Cc: linux-kernel, greg, brice On Mon, 03 Jul 2006 23:00:34 +1200 Reuben Farrelly <reuben-lkml@reub.net> wrote: > > > On 3/07/2006 10:03 p.m., Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > - A major update to the e1000 driver. > > > > - 1394 updates > > > audit: initializing netlink socket (disabled) > audit(1151924044.008:1): initialized > SELinux: Registering netfilter hooks > Initializing Cryptographic API > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered (default) > PCI: Setting latency timer of device 0000:00:1c.0 to 64 > assign_interrupt_mode Found MSI capability > Allocate Port Service[0000:00:1c.0:pcie0] > Allocate Port Service[0000:00:1c.0:pcie0] Looks like the enumeration of the PCIE devices failed to increment something. > kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register > things with the same name in the same directory. > > Call Trace: > [<ffffffff80358298>] kobject_put+0x19/0x21 > [<ffffffff80358741>] kobject_add+0x181/0x1ac > [<ffffffff803aa378>] device_add+0x88/0x4b9 > [<ffffffff803aa7c2>] device_register+0x19/0x27 > [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de > [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 > [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 > [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 > [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 > [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 > [<ffffffff803ac162>] __driver_attach+0x0/0xb9 > [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 > [<ffffffff803abfbc>] driver_attach+0x1c/0x1e > [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 > [<ffffffff803ac463>] driver_register+0x9f/0xa6 > [<ffffffff80361497>] __pci_register_driver+0x59/0x7e > [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 > [<ffffffff80267f3e>] init+0x14e/0x2d0 > [<ffffffff80260a12>] child_rip+0x8/0x12 > [<ffffffff80267df0>] init+0x0/0x2d0 > [<ffffffff80260a0a>] child_rip+0x0/0x12 > > The trace shows up 5 times in quick succession, all traces looking the same....... > > Box otherwise boots up OK. I'd be supecting the changes in drivers/base/core.c. Does 2.6.17-git19 do the same thing? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 12:34 ` Reuben Farrelly 0 siblings, 0 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-03 12:34 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, greg, brice On 3/07/2006 11:25 p.m., Andrew Morton wrote: > On Mon, 03 Jul 2006 23:00:34 +1200 > Reuben Farrelly <reuben-lkml@reub.net> wrote: > >> >> On 3/07/2006 10:03 p.m., Andrew Morton wrote: >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ >>> >>> >>> - A major update to the e1000 driver. >>> >>> - 1394 updates >> >> audit: initializing netlink socket (disabled) >> audit(1151924044.008:1): initialized >> SELinux: Registering netfilter hooks >> Initializing Cryptographic API >> io scheduler noop registered >> io scheduler anticipatory registered >> io scheduler deadline registered (default) >> PCI: Setting latency timer of device 0000:00:1c.0 to 64 >> assign_interrupt_mode Found MSI capability >> Allocate Port Service[0000:00:1c.0:pcie0] >> Allocate Port Service[0000:00:1c.0:pcie0] > > Looks like the enumeration of the PCIE devices failed to increment something. > >> kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register >> things with the same name in the same directory. >> >> Call Trace: >> [<ffffffff80358298>] kobject_put+0x19/0x21 >> [<ffffffff80358741>] kobject_add+0x181/0x1ac >> [<ffffffff803aa378>] device_add+0x88/0x4b9 >> [<ffffffff803aa7c2>] device_register+0x19/0x27 >> [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de >> [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 >> [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 >> [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 >> [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 >> [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 >> [<ffffffff803ac162>] __driver_attach+0x0/0xb9 >> [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 >> [<ffffffff803abfbc>] driver_attach+0x1c/0x1e >> [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 >> [<ffffffff803ac463>] driver_register+0x9f/0xa6 >> [<ffffffff80361497>] __pci_register_driver+0x59/0x7e >> [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 >> [<ffffffff80267f3e>] init+0x14e/0x2d0 >> [<ffffffff80260a12>] child_rip+0x8/0x12 >> [<ffffffff80267df0>] init+0x0/0x2d0 >> [<ffffffff80260a0a>] child_rip+0x0/0x12 >> >> The trace shows up 5 times in quick succession, all traces looking the same....... >> >> Box otherwise boots up OK. > > I'd be supecting the changes in drivers/base/core.c. Does 2.6.17-git19 do > the same thing? No. It seems to be fine. I'll post a dmesg from that too if you like. Reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly 2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 11:39 ` Andrew Morton 2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly 2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov 2 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 11:39 UTC (permalink / raw) To: Reuben Farrelly; +Cc: linux-kernel, greg, brice On Mon, 03 Jul 2006 23:00:34 +1200 Reuben Farrelly <reuben-lkml@reub.net> wrote: > Allocate Port Service[0000:00:1c.0:pcie0] > Allocate Port Service[0000:00:1c.0:pcie0] Could we have the full dmesg please? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 11:41 ` Reuben Farrelly 2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton 2006-07-03 20:21 ` 2.6.17-mm6 Andrew Morton 0 siblings, 2 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-03 11:41 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, greg, brice On 3/07/2006 11:39 p.m., Andrew Morton wrote: > On Mon, 03 Jul 2006 23:00:34 +1200 > Reuben Farrelly <reuben-lkml@reub.net> wrote: > >> Allocate Port Service[0000:00:1c.0:pcie0] >> Allocate Port Service[0000:00:1c.0:pcie0] > > Could we have the full dmesg please? Sure: Bootdata ok (command line is ro root=/dev/md0 panic=60 console=ttyS0,57600) Linux version 2.6.17-mm6 (root@tornado.reub.net) (gcc version 4.1.1 20060629 (Red Hat 4.1.1-6)) #1 SMP Mon Jul 3 22:47:46 NZST 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003f670000 (usable) BIOS-e820: 000000003f670000 - 000000003f6e9000 (ACPI NVS) BIOS-e820: 000000003f6e9000 - 000000003f6ec000 (usable) BIOS-e820: 000000003f6ec000 - 000000003f6ff000 (ACPI data) BIOS-e820: 000000003f6ff000 - 000000003f700000 (usable) DMI 2.3 present. ACPI: RSDP (v000 INTEL ) @ 0x00000000000fe020 ACPI: RSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fde48 ACPI: FADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcf10 ACPI: MADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fce10 ACPI: WDDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f90 ACPI: MCFG (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f10 ACPI: ASF! (v032 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcd10 ACPI: HPET (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6e90 ACPI: SSDT (v001 INTEL CpuPm 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fdc10 ACPI: SSDT (v001 INTEL Cpu0Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fda10 ACPI: SSDT (v001 INTEL Cpu1Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd810 ACPI: SSDT (v001 INTEL Cpu2Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd610 ACPI: SSDT (v001 INTEL Cpu3Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd410 ACPI: TCPA (v001 INTEL TIANO 0x00000002 MSFT 0x01000013) @ 0x000000003f670010 ACPI: DSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x0000000000000000 On node 0 totalpages: 254541 DMA zone: 2433 pages, LIFO batch:0 DMA32 zone: 252108 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed00000 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 40000000 (gap: 3f700000:c0900000) Built 1 zonelists. Total pages: 254541 Kernel command line: ro root=/dev/md0 panic=60 console=ttyS0,57600 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... Memory: 1015020k/1039360k available (2582k kernel code, 22812k reserved, 1666k data, 216k init) Calibrating delay using timer specific routine.. 6006.43 BogoMIPS (lpj=12012875) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM1) Freeing SMP alternatives: 28k freed ACPI: Core revision 20060623 Using local APIC timer interrupts. result 12500448 Detected 12.500 MHz APIC timer. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 6000.21 BogoMIPS (lpj=12000420) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU1: Thermal monitoring enabled (TM1) Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03 Brought up 2 CPUs testing NMI watchdog ... OK. time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 3000.123 MHz processor. migration_cost=5 checking if image is initramfs... it is Freeing initrd memory: 877k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 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] bus is 0 Boot video device is 0000:00:02.0 PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 *9 10 11 12) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT] Intel 82802 RNG detected 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 hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz PCI-GART: No AMD northbridge found. PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 PCI: Bridge: 0000:00:1c.0 IO window: 2000-2fff MEM window: 48000000-480fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.2 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.3 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.4 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.5 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1e.0 IO window: 1000-1fff MEM window: disabled. PREFETCH window: disabled. Device `[PEX0]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1c.0 to 64 Device `[PEX2]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:00:1c.2 to 64 Device `[PEX3]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19 PCI: Setting latency timer of device 0000:00:1c.3 to 64 Device `[PEX4]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17 PCI: Setting latency timer of device 0000:00:1c.4 to 64 Device `[PEX5]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1c.5 to 64 PCI: Setting latency timer of device 0000:00:1e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 6, 262144 bytes) TCP established hash table entries: 131072 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1151924044.008:1): initialized SELinux: Registering netfilter hooks Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered (default) PCI: Setting latency timer of device 0000:00:1c.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.0:pcie0] Allocate Port Service[0000:00:1c.0:pcie0] kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [<ffffffff80358298>] kobject_put+0x19/0x21 [<ffffffff80358741>] kobject_add+0x181/0x1ac [<ffffffff803aa378>] device_add+0x88/0x4b9 [<ffffffff803aa7c2>] device_register+0x19/0x27 [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 [<ffffffff803ac162>] __driver_attach+0x0/0xb9 [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 [<ffffffff803abfbc>] driver_attach+0x1c/0x1e [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 [<ffffffff803ac463>] driver_register+0x9f/0xa6 [<ffffffff80361497>] __pci_register_driver+0x59/0x7e [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 [<ffffffff80267f3e>] init+0x14e/0x2d0 [<ffffffff80260a12>] child_rip+0x8/0x12 [<ffffffff80267df0>] init+0x0/0x2d0 [<ffffffff80260a0a>] child_rip+0x0/0x12 PCI: Setting latency timer of device 0000:00:1c.2 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.2:pcie0] Allocate Port Service[0000:00:1c.2:pcie0] kobject_add failed for 0000:00:1c.2:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [<ffffffff80358298>] kobject_put+0x19/0x21 [<ffffffff80358741>] kobject_add+0x181/0x1ac [<ffffffff803aa378>] device_add+0x88/0x4b9 [<ffffffff803aa7c2>] device_register+0x19/0x27 [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 [<ffffffff803ac162>] __driver_attach+0x0/0xb9 [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 [<ffffffff803abfbc>] driver_attach+0x1c/0x1e [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 [<ffffffff803ac463>] driver_register+0x9f/0xa6 [<ffffffff80361497>] __pci_register_driver+0x59/0x7e [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 [<ffffffff80267f3e>] init+0x14e/0x2d0 [<ffffffff80260a12>] child_rip+0x8/0x12 [<ffffffff80267df0>] init+0x0/0x2d0 [<ffffffff80260a0a>] child_rip+0x0/0x12 PCI: Setting latency timer of device 0000:00:1c.3 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.3:pcie0] Allocate Port Service[0000:00:1c.3:pcie0] kobject_add failed for 0000:00:1c.3:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [<ffffffff80358298>] kobject_put+0x19/0x21 [<ffffffff80358741>] kobject_add+0x181/0x1ac [<ffffffff803aa378>] device_add+0x88/0x4b9 [<ffffffff803aa7c2>] device_register+0x19/0x27 [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 [<ffffffff803ac162>] __driver_attach+0x0/0xb9 [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 [<ffffffff803abfbc>] driver_attach+0x1c/0x1e [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 [<ffffffff803ac463>] driver_register+0x9f/0xa6 [<ffffffff80361497>] __pci_register_driver+0x59/0x7e [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 [<ffffffff80267f3e>] init+0x14e/0x2d0 [<ffffffff80260a12>] child_rip+0x8/0x12 [<ffffffff80267df0>] init+0x0/0x2d0 [<ffffffff80260a0a>] child_rip+0x0/0x12 PCI: Setting latency timer of device 0000:00:1c.4 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.4:pcie0] Allocate Port Service[0000:00:1c.4:pcie0] kobject_add failed for 0000:00:1c.4:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [<ffffffff80358298>] kobject_put+0x19/0x21 [<ffffffff80358741>] kobject_add+0x181/0x1ac [<ffffffff803aa378>] device_add+0x88/0x4b9 [<ffffffff803aa7c2>] device_register+0x19/0x27 [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 [<ffffffff803ac162>] __driver_attach+0x0/0xb9 [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 [<ffffffff803abfbc>] driver_attach+0x1c/0x1e [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 [<ffffffff803ac463>] driver_register+0x9f/0xa6 [<ffffffff80361497>] __pci_register_driver+0x59/0x7e [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 [<ffffffff80267f3e>] init+0x14e/0x2d0 [<ffffffff80260a12>] child_rip+0x8/0x12 [<ffffffff80267df0>] init+0x0/0x2d0 [<ffffffff80260a0a>] child_rip+0x0/0x12 PCI: Setting latency timer of device 0000:00:1c.5 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.5:pcie0] Allocate Port Service[0000:00:1c.5:pcie0] kobject_add failed for 0000:00:1c.5:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. Call Trace: [<ffffffff80358298>] kobject_put+0x19/0x21 [<ffffffff80358741>] kobject_add+0x181/0x1ac [<ffffffff803aa378>] device_add+0x88/0x4b9 [<ffffffff803aa7c2>] device_register+0x19/0x27 [<ffffffff80363e90>] pcie_port_device_register+0x3a0/0x3de [<ffffffff8042fa10>] pcibios_set_master+0x7f/0x86 [<ffffffff80364004>] pcie_portdrv_probe+0x64/0x80 [<ffffffff803612ac>] pci_device_probe+0x4d/0x78 [<ffffffff803ac08f>] driver_probe_device+0x5c/0xb4 [<ffffffff803ac1c9>] __driver_attach+0x67/0xb9 [<ffffffff803ac162>] __driver_attach+0x0/0xb9 [<ffffffff803aba4f>] bus_for_each_dev+0x4f/0x79 [<ffffffff803abfbc>] driver_attach+0x1c/0x1e [<ffffffff803ab61a>] bus_add_driver+0x7a/0x143 [<ffffffff803ac463>] driver_register+0x9f/0xa6 [<ffffffff80361497>] __pci_register_driver+0x59/0x7e [<ffffffff806b7a57>] pcie_portdrv_init+0x1c/0x30 [<ffffffff80267f3e>] init+0x14e/0x2d0 [<ffffffff80260a12>] child_rip+0x8/0x12 [<ffffffff80267df0>] init+0x0/0x2d0 [<ffffffff80260a0a>] child_rip+0x0/0x12 ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Getting cpuindex for acpiid 0x3 ACPI: Getting cpuindex for acpiid 0x4 Real Time Clock Driver v1.12ac hpet_resources: 0xfed00000 is busy Linux agpgart interface v0.101 (c) Dave Jones Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 19 0000:06:03.0: ttyS1 at I/O 0x1000 (irq = 19) is a 16550A 0000:06:03.0: ttyS2 at I/O 0x1008 (irq = 19) is a 16550A Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 4 RAM disks of 16384K size 1024 blocksize Intel(R) PRO/1000 Network Driver - version 7.1.9-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:01:00.0 to 64 e1000: 0000:01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:13:20:60:b4:23 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH7: IDE controller at PCI slot 0000:00:1f.1 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18 ICH7: chipset revision 1 ICH7: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x30b0-0x30b7, BIOS settings: hda:DMA, hdb:pio Probing IDE interface ide0... hda: PIONEER DVD-RW DVR-111D, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 libata version 2.00 loaded. ahci 0000:00:1f.2: version 2.0 Device `[IDES]' is not power manageable<6>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 ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xFFFFC20000016100 ctl 0x0 bmdma 0x0 irq 314 ata2: SATA max UDMA/133 cmd 0xFFFFC20000016180 ctl 0x0 bmdma 0x0 irq 314 ata3: SATA max UDMA/133 cmd 0xFFFFC20000016200 ctl 0x0 bmdma 0x0 irq 314 ata4: SATA max UDMA/133 cmd 0xFFFFC20000016280 ctl 0x0 bmdma 0x0 irq 314 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 Losing some ticks... checking if CPU frequency changed. scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link down (SStatus 0 SControl 300) Vendor: ATA Model: ST380817AS Rev: 3.42 Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST3300622AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST380817AS Rev: 3.42 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 > sd 0:0:0:0: Attached scsi disk sda SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back sdb: sdb1 sdb2 sdb3 sd 1:0:0:0: Attached scsi disk sdb SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 > sd 2:0:0:0: Attached scsi disk sdc sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 2:0:0:0: Attached scsi generic sg2 type 0 Device `[EHCI]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23 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: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: irq 23, io mem 0x481a0400 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: new device found, idVendor=0000, idProduct=0000 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 2.6.17-mm6 ehci_hcd usb usb1: SerialNumber: 0000:00:1d.7 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23 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 23, io base 0x00003080 usb usb2: new device found, idVendor=0000, idProduct=0000 usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: UHCI Host Controller usb usb2: Manufacturer: Linux 2.6.17-mm6 uhci_hcd usb usb2: SerialNumber: 0000:00:1d.0 usb usb2: configuration #1 chosen from 1 choice 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 0x00003060 usb usb3: new device found, idVendor=0000, idProduct=0000 usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: UHCI Host Controller usb usb3: Manufacturer: Linux 2.6.17-mm6 uhci_hcd usb usb3: SerialNumber: 0000:00:1d.1 usb usb3: configuration #1 chosen from 1 choice 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 0x00003040 usb usb4: new device found, idVendor=0000, idProduct=0000 usb usb4: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: UHCI Host Controller usb usb4: Manufacturer: Linux 2.6.17-mm6 uhci_hcd usb usb4: SerialNumber: 0000:00:1d.2 usb usb4: configuration #1 chosen from 1 choice 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 usb 2-1: new full speed USB device using uhci_hcd and address 2 uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5 uhci_hcd 0000:00:1d.3: irq 16, io base 0x00003020 usb usb5: new device found, idVendor=0000, idProduct=0000 usb usb5: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: UHCI Host Controller usb usb5: Manufacturer: Linux 2.6.17-mm6 uhci_hcd usb usb5: SerialNumber: 0000:00:1d.3 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected usb 2-1: new device found, idVendor=0451, idProduct=2046 usb 2-1: new device strings: Mfr=0, Product=0, SerialNumber=0 usb 2-1: configuration #1 chosen from 1 choice hub 2-1:1.0: USB hub found hub 2-1:1.0: 4 ports detected usb 3-2: new full speed USB device using uhci_hcd and address 2 usb 3-2: new device found, idVendor=046d, idProduct=08b0 usb 3-2: new device strings: Mfr=0, Product=0, SerialNumber=1 usb 3-2: SerialNumber: 01402100A5000000 usb 3-2: configuration #1 chosen from 1 choice usb 2-1.1: new low speed USB device using uhci_hcd and address 3 usb 2-1.1: new device found, idVendor=050d, idProduct=0105 usb 2-1.1: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1.1: Product: Belkin OmniView KVM Switch usb 2-1.1: Manufacturer: Belkin Components usb 2-1.1: configuration #1 chosen from 1 choice usbcore: registered new driver libusual usbcore: registered new driver hiddev input: Belkin Components Belkin OmniView KVM Switch as /class/input/input0 input: USB HID v1.00 Keyboard [Belkin Components Belkin OmniView KVM Switch] on usb-0000:00:1d.0-1.1 input: Belkin Components Belkin OmniView KVM Switch as /class/input/input1 input: USB HID v1.00 Mouse [Belkin Components Belkin OmniView KVM Switch] on usb-0000:00:1d.0-1.1 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice md: raid1 personality registered for level 1 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 EDAC MC: Ver: 2.0.1 Jul 3 2006 TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) BIOS EDD facility v0.16 2004-Jun-25, 3 devices found Freeing unused kernel memory: 216k freed md: Autodetecting RAID arrays. md: invalid raid superblock magic on sda10 md: sda10 has invalid sb, not importing! md: invalid raid superblock magic on sdc10 md: sdc10 has invalid sb, not importing! md: autorun ... md: considering sdc11 ... md: adding sdc11 ... md: sdc7 has different UUID to sdc11 md: sdc6 has different UUID to sdc11 md: sdc5 has different UUID to sdc11 md: sdc3 has different UUID to sdc11 md: sdc2 has different UUID to sdc11 md: adding sda11 ... md: sda7 has different UUID to sdc11 md: sda6 has different UUID to sdc11 md: sda5 has different UUID to sdc11 md: sda3 has different UUID to sdc11 md: sda2 has different UUID to sdc11 md: created md5 md: bind<sda11> md: bind<sdc11> md: running: <sdc11><sda11> raid1: raid set md5 active with 2 out of 2 mirrors md5: bitmap initialized from disk: read 10/10 pages, set 7 bits, status: 0 created bitmap (153 pages) for device md5 md: considering sdc7 ... md: adding sdc7 ... md: sdc6 has different UUID to sdc7 md: sdc5 has different UUID to sdc7 md: sdc3 has different UUID to sdc7 md: sdc2 has different UUID to sdc7 md: adding sda7 ... md: sda6 has different UUID to sdc7 md: sda5 has different UUID to sdc7 md: sda3 has different UUID to sdc7 md: sda2 has different UUID to sdc7 md: created md4 md: bind<sda7> md: bind<sdc7> md: running: <sdc7><sda7> raid1: raid set md4 active with 2 out of 2 mirrors md4: bitmap initialized from disk: read 4/4 pages, set 9 bits, status: 0 created bitmap (61 pages) for device md4 md: considering sdc6 ... md: adding sdc6 ... md: sdc5 has different UUID to sdc6 md: sdc3 has different UUID to sdc6 md: sdc2 has different UUID to sdc6 md: adding sda6 ... md: sda5 has different UUID to sdc6 md: sda3 has different UUID to sdc6 md: sda2 has different UUID to sdc6 md: created md3 md: bind<sda6> md: bind<sdc6> md: running: <sdc6><sda6> raid1: raid set md3 active with 2 out of 2 mirrors md3: bitmap initialized from disk: read 1/1 pages, set 1 bits, status: 0 created bitmap (13 pages) for device md3 md: considering sdc5 ... md: adding sdc5 ... md: sdc3 has different UUID to sdc5 md: sdc2 has different UUID to sdc5 md: adding sda5 ... md: sda3 has different UUID to sdc5 md: sda2 has different UUID to sdc5 md: created md2 md: bind<sda5> md: bind<sdc5> md: running: <sdc5><sda5> raid1: raid set md2 active with 2 out of 2 mirrors md2: bitmap initialized from disk: read 10/10 pages, set 54 bits, status: 0 created bitmap (150 pages) for device md2 md: considering sdc3 ... md: adding sdc3 ... md: sdc2 has different UUID to sdc3 md: adding sda3 ... md: sda2 has different UUID to sdc3 md: created md1 md: bind<sda3> md: bind<sdc3> md: running: <sdc3><sda3> raid1: raid set md1 active with 2 out of 2 mirrors md1: bitmap initialized from disk: read 10/10 pages, set 50 bits, status: 0 created bitmap (150 pages) for device md1 md: considering sdc2 ... md: adding sdc2 ... md: adding sda2 ... md: created md0 md: bind<sda2> md: bind<sdc2> md: running: <sdc2><sda2> raid1: raid set md0 active with 2 out of 2 mirrors md0: bitmap initialized from disk: read 12/12 pages, set 41 bits, status: 0 created bitmap (187 pages) for device md0 md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. SELinux: Disabled at runtime. SELinux: Unregistering netfilter hooks audit(1151924056.656:2): selinux=0 auid=4294967295 ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 19 iTCO_wdt: Intel TCO WatchDog Timer Driver v1.00 (18-Jun-2006) iTCO_wdt: Found a ICH7 or ICH7R TCO device (Version=2, TCOBASE=0x0460) iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66) Uniform CD-ROM driver Revision: 3.20 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on md0, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on md1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on md2, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on md3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on md4, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: mounting fs with errors, running e2fsck is recommended EXT3 FS on md5, internal journal EXT3-fs: mounted filesystem with ordered data mode. ReiserFS: sda8: found reiserfs format "3.6" with standard journal ReiserFS: sda8: using ordered data mode ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: sda8: checking transaction log (sda8) ReiserFS: sda8: Using r5 hash to sort names ReiserFS: sdc8: found reiserfs format "3.6" with standard journal ReiserFS: sdc8: using ordered data mode ReiserFS: sdc8: journal params: device sdc8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: sdc8: checking transaction log (sdc8) ReiserFS: sdc8: Using r5 hash to sort names kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on sdb1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on sdb2, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 248968k swap on /dev/sda9. Priority:-1 extents:1 across:248968k Adding 248968k swap on /dev/sdc9. Priority:-2 extents:1 across:248968k ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (4060 buckets, 32480 max) - 288 bytes per conntrack e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex GRE over IPv4 tunneling driver NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver Bluetooth: Core ver 2.8 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.7 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 eth0: no IPv6 routers present [root@tornado linux]# reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly @ 2006-07-03 12:10 ` Andrew Morton 2006-07-03 13:36 ` 2.6.17-mm6 Reuben Farrelly 2006-07-03 20:21 ` 2.6.17-mm6 Andrew Morton 1 sibling, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 12:10 UTC (permalink / raw) To: Reuben Farrelly; +Cc: linux-kernel, greg, brice On Mon, 03 Jul 2006 23:41:42 +1200 Reuben Farrelly <reuben-lkml@reub.net> wrote: > On 3/07/2006 11:39 p.m., Andrew Morton wrote: > > On Mon, 03 Jul 2006 23:00:34 +1200 > > Reuben Farrelly <reuben-lkml@reub.net> wrote: > > > >> Allocate Port Service[0000:00:1c.0:pcie0] > >> Allocate Port Service[0000:00:1c.0:pcie0] > > > > Could we have the full dmesg please? > > Sure: Still stumped. Could we have the dmesg for 2.6.17? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 13:36 ` Reuben Farrelly 0 siblings, 0 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-03 13:36 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, greg, brice On 4/07/2006 12:10 a.m., Andrew Morton wrote: > On Mon, 03 Jul 2006 23:41:42 +1200 > Reuben Farrelly <reuben-lkml@reub.net> wrote: > >> On 3/07/2006 11:39 p.m., Andrew Morton wrote: >>> On Mon, 03 Jul 2006 23:00:34 +1200 >>> Reuben Farrelly <reuben-lkml@reub.net> wrote: >>> >>>> Allocate Port Service[0000:00:1c.0:pcie0] >>>> Allocate Port Service[0000:00:1c.0:pcie0] >>> Could we have the full dmesg please? >> Sure: > > Still stumped. Could we have the dmesg for 2.6.17? Here's the 2.6.17-git19 dmesg and an lspci -v. I'm not sure if you need me to rollback further or not.. [root@tornado ~]# dmesg Bootdata ok (command line is ro root=/dev/md0 panic=60 console=ttyS0,57600) Linux version 2.6.17-git19 (root@tornado.reub.net) (gcc version 4.1.1 20060629 (Red Hat 4.1.1-6)) #1 SMP Mon Jul 3 23:58:06 NZST 2006 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003f670000 (usable) BIOS-e820: 000000003f670000 - 000000003f6e9000 (ACPI NVS) BIOS-e820: 000000003f6e9000 - 000000003f6ec000 (usable) BIOS-e820: 000000003f6ec000 - 000000003f6ff000 (ACPI data) BIOS-e820: 000000003f6ff000 - 000000003f700000 (usable) DMI 2.3 present. ACPI: RSDP (v000 INTEL ) @ 0x00000000000fe020 ACPI: RSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fde48 ACPI: FADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcf10 ACPI: MADT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fce10 ACPI: WDDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f90 ACPI: MCFG (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6f10 ACPI: ASF! (v032 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fcd10 ACPI: HPET (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x000000003f6f6e90 ACPI: SSDT (v001 INTEL CpuPm 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fdc10 ACPI: SSDT (v001 INTEL Cpu0Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fda10 ACPI: SSDT (v001 INTEL Cpu1Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd810 ACPI: SSDT (v001 INTEL Cpu2Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd610 ACPI: SSDT (v001 INTEL Cpu3Ist 0x00000f5a MSFT 0x01000013) @ 0x000000003f6fd410 ACPI: TCPA (v001 INTEL TIANO 0x00000002 MSFT 0x01000013) @ 0x000000003f670010 ACPI: DSDT (v001 INTEL D945GNT 0x00000f5a MSFT 0x01000013) @ 0x0000000000000000 On node 0 totalpages: 254558 DMA zone: 2450 pages, LIFO batch:0 DMA32 zone: 252108 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x408 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x8086a201 base: 0xfed00000 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 40000000 (gap: 3f700000:c0900000) Built 1 zonelists. Total pages: 254558 Kernel command line: ro root=/dev/md0 panic=60 console=ttyS0,57600 Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 3000.118 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... Memory: 1015088k/1039360k available (2552k kernel code, 22744k reserved, 1640k data, 204k init) Calibrating delay using timer specific routine.. 6006.39 BogoMIPS (lpj=12012785) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring enabled (TM1) Freeing SMP alternatives: 28k freed ACPI: Core revision 20060623 Using local APIC timer interrupts. result 12500432 Detected 12.500 MHz APIC timer. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 6000.13 BogoMIPS (lpj=12000263) CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU1: Thermal monitoring enabled (TM1) Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 03 Brought up 2 CPUs testing NMI watchdog ... OK. migration_cost=10 checking if image is initramfs... it is Freeing initrd memory: 877k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: BIOS Bug: MCFG area at f0000000 is not E820-reserved PCI: Not using MMCONFIG. PCI: Using configuration type 1 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] bus is 0 Boot video device is 0000:00:02.0 PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 PCI: Transparent bridge - 0000:00:1e.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 9 10 11 12) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 *9 10 11 12) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX5._PRT] Intel 82802 RNG detected 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 hpet0: at MMIO 0xfed00000 (virtual 0xffffffffff5fe000), IRQs 2, 8, 0 hpet0: 3 64-bit timers, 14318180 Hz PCI-GART: No AMD northbridge found. PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 PCI: Bridge: 0000:00:1c.0 IO window: 2000-2fff MEM window: 48000000-480fffff PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.2 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.3 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.4 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1c.5 IO window: disabled. MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: 0000:00:1e.0 IO window: 1000-1fff MEM window: disabled. PREFETCH window: disabled. Device `[PEX0]' is not power manageable<6>GSI 16 sharing vector 0xA9 and IRQ 16 ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 169 PCI: Setting latency timer of device 0000:00:1c.0 to 64 Device `[PEX2]' is not power manageable<6>GSI 17 sharing vector 0xB1 and IRQ 17 ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 177 PCI: Setting latency timer of device 0000:00:1c.2 to 64 Device `[PEX3]' is not power manageable<6>GSI 18 sharing vector 0xB9 and IRQ 18 ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 185 PCI: Setting latency timer of device 0000:00:1c.3 to 64 Device `[PEX4]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 169 PCI: Setting latency timer of device 0000:00:1c.4 to 64 Device `[PEX5]' is not power manageable<6>GSI 19 sharing vector 0xC1 and IRQ 19 ACPI: PCI Interrupt 0000:00:1c.5[B] -> GSI 16 (level, low) -> IRQ 193 PCI: Setting latency timer of device 0000:00:1c.5 to 64 PCI: Setting latency timer of device 0000:00:1e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 6, 262144 bytes) TCP established hash table entries: 131072 (order: 9, 2097152 bytes) TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1151933576.024:1): initialized SELinux: Registering netfilter hooks Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered (default) PCI: Setting latency timer of device 0000:00:1c.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.0:pcie00] Allocate Port Service[0000:00:1c.0:pcie02] PCI: Setting latency timer of device 0000:00:1c.2 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.2:pcie00] Allocate Port Service[0000:00:1c.2:pcie02] PCI: Setting latency timer of device 0000:00:1c.3 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.3:pcie00] Allocate Port Service[0000:00:1c.3:pcie02] PCI: Setting latency timer of device 0000:00:1c.4 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.4:pcie00] Allocate Port Service[0000:00:1c.4:pcie02] PCI: Setting latency timer of device 0000:00:1c.5 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:1c.5:pcie00] Allocate Port Service[0000:00:1c.5:pcie02] ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Getting cpuindex for acpiid 0x3 ACPI: Getting cpuindex for acpiid 0x4 Real Time Clock Driver v1.12ac hpet_resources: 0xfed00000 is busy Linux agpgart interface v0.101 (c) Dave Jones Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 185 0000:06:03.0: ttyS1 at I/O 0x1000 (irq = 185) is a 16550A 0000:06:03.0: ttyS2 at I/O 0x1008 (irq = 185) is a 16550A Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 4 RAM disks of 16384K size 1024 blocksize Intel(R) PRO/1000 Network Driver - version 7.0.38-k4-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 193 PCI: Setting latency timer of device 0000:01:00.0 to 64 e1000: 0000:01:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:13:20:60:b4:23 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH7: IDE controller at PCI slot 0000:00:1f.1 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 177 ICH7: chipset revision 1 ICH7: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x30b0-0x30b7, BIOS settings: hda:DMA, hdb:pio Probing IDE interface ide0... hda: PIONEER DVD-RW DVR-111D, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 libata version 2.00 loaded. ahci 0000:00:1f.2: version 2.0 Device `[IDES]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 185 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode ahci 0000:00:1f.2: flags: 64bit ncq led clo pio slum part ata1: SATA max UDMA/133 cmd 0xFFFFC20000016100 ctl 0x0 bmdma 0x0 irq 58 ata2: SATA max UDMA/133 cmd 0xFFFFC20000016180 ctl 0x0 bmdma 0x0 irq 58 ata3: SATA max UDMA/133 cmd 0xFFFFC20000016200 ctl 0x0 bmdma 0x0 irq 58 ata4: SATA max UDMA/133 cmd 0xFFFFC20000016280 ctl 0x0 bmdma 0x0 irq 58 scsi0 : ahci ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: configured for UDMA/133 scsi1 : ahci ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/133 scsi3 : ahci ata4: SATA link down (SStatus 0 SControl 300) Losing some ticks... checking if CPU frequency changed. Vendor: ATA Model: ST380817AS Rev: 3.42 Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST3300622AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 Vendor: ATA Model: ST380817AS Rev: 3.42 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 > sd 0:0:0:0: Attached scsi disk sda SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 586072368 512-byte hdwr sectors (300069 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back sdb: sdb1 sdb2 sdb3 sd 1:0:0:0: Attached scsi disk sdb SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156301488 512-byte hdwr sectors (80026 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sdc4 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 sdc11 > sd 2:0:0:0: Attached scsi disk sdc sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 2:0:0:0: Attached scsi generic sg2 type 0 Device `[EHCI]' is not power manageable<6>GSI 20 sharing vector 0x42 and IRQ 20 ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 66 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: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:1d.7: debug port 1 PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: irq 66, io mem 0x481a0400 ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected USB Universal Host Controller Interface driver v3.0 ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 66 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 66, io base 0x00003080 usb usb2: configuration #1 chosen from 1 choice 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 185 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 185, io base 0x00003060 usb usb3: configuration #1 chosen from 1 choice 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 177 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 177, io base 0x00003040 usb usb4: configuration #1 chosen from 1 choice 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 193 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 193, io base 0x00003020 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected usb 2-1: new full speed USB device using uhci_hcd and address 2 usb 2-1: configuration #1 chosen from 1 choice hub 2-1:1.0: USB hub found hub 2-1:1.0: 4 ports detected usb 3-2: new full speed USB device using uhci_hcd and address 2 usb 3-2: configuration #1 chosen from 1 choice usb 2-1.1: new low speed USB device using uhci_hcd and address 3 usb 2-1.1: configuration #1 chosen from 1 choice usbcore: registered new driver libusual usbcore: registered new driver hiddev input: Belkin Components Belkin OmniView KVM Switch as /class/input/input0 input: USB HID v1.00 Keyboard [Belkin Components Belkin OmniView KVM Switch] on usb-0000:00:1d.0-1.1 input: Belkin Components Belkin OmniView KVM Switch as /class/input/input1 input: USB HID v1.00 Mouse [Belkin Components Belkin OmniView KVM Switch] on usb-0000:00:1d.0-1.1 usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 mice: PS/2 mouse device common for all mice md: raid1 personality registered for level 1 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 EDAC MC: Ver: 2.0.0 Jul 3 2006 TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) BIOS EDD facility v0.16 2004-Jun-25, 3 devices found Freeing unused kernel memory: 204k freed md: Autodetecting RAID arrays. md: invalid raid superblock magic on sda10 md: sda10 has invalid sb, not importing! md: invalid raid superblock magic on sdc10 md: sdc10 has invalid sb, not importing! md: autorun ... md: considering sdc11 ... md: adding sdc11 ... md: sdc7 has different UUID to sdc11 md: sdc6 has different UUID to sdc11 md: sdc5 has different UUID to sdc11 md: sdc3 has different UUID to sdc11 md: sdc2 has different UUID to sdc11 md: adding sda11 ... md: sda7 has different UUID to sdc11 md: sda6 has different UUID to sdc11 md: sda5 has different UUID to sdc11 md: sda3 has different UUID to sdc11 md: sda2 has different UUID to sdc11 md: created md5 md: bind<sda11> md: bind<sdc11> md: running: <sdc11><sda11> raid1: raid set md5 active with 2 out of 2 mirrors md5: bitmap initialized from disk: read 10/10 pages, set 9 bits, status: 0 created bitmap (153 pages) for device md5 md: considering sdc7 ... md: adding sdc7 ... md: sdc6 has different UUID to sdc7 md: sdc5 has different UUID to sdc7 md: sdc3 has different UUID to sdc7 md: sdc2 has different UUID to sdc7 md: adding sda7 ... md: sda6 has different UUID to sdc7 md: sda5 has different UUID to sdc7 md: sda3 has different UUID to sdc7 md: sda2 has different UUID to sdc7 md: created md4 md: bind<sda7> md: bind<sdc7> md: running: <sdc7><sda7> raid1: raid set md4 active with 2 out of 2 mirrors md4: bitmap initialized from disk: read 4/4 pages, set 6 bits, status: 0 created bitmap (61 pages) for device md4 md: considering sdc6 ... md: adding sdc6 ... md: sdc5 has different UUID to sdc6 md: sdc3 has different UUID to sdc6 md: sdc2 has different UUID to sdc6 md: adding sda6 ... md: sda5 has different UUID to sdc6 md: sda3 has different UUID to sdc6 md: sda2 has different UUID to sdc6 md: created md3 md: bind<sda6> md: bind<sdc6> md: running: <sdc6><sda6> raid1: raid set md3 active with 2 out of 2 mirrors md3: bitmap initialized from disk: read 1/1 pages, set 2 bits, status: 0 created bitmap (13 pages) for device md3 md: considering sdc5 ... md: adding sdc5 ... md: sdc3 has different UUID to sdc5 md: sdc2 has different UUID to sdc5 md: adding sda5 ... md: sda3 has different UUID to sdc5 md: sda2 has different UUID to sdc5 md: created md2 md: bind<sda5> md: bind<sdc5> md: running: <sdc5><sda5> raid1: raid set md2 active with 2 out of 2 mirrors md2: bitmap initialized from disk: read 10/10 pages, set 49 bits, status: 0 created bitmap (150 pages) for device md2 md: considering sdc3 ... md: adding sdc3 ... md: sdc2 has different UUID to sdc3 md: adding sda3 ... md: sda2 has different UUID to sdc3 md: created md1 md: bind<sda3> md: bind<sdc3> md: running: <sdc3><sda3> raid1: raid set md1 active with 2 out of 2 mirrors md1: bitmap initialized from disk: read 10/10 pages, set 54 bits, status: 0 created bitmap (150 pages) for device md1 md: considering sdc2 ... md: adding sdc2 ... md: adding sda2 ... md: created md0 md: bind<sda2> md: bind<sdc2> md: running: <sdc2><sda2> raid1: raid set md0 active with 2 out of 2 mirrors md0: bitmap initialized from disk: read 12/12 pages, set 44 bits, status: 0 created bitmap (187 pages) for device md0 md: ... autorun DONE. kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. SELinux: Disabled at runtime. SELinux: Unregistering netfilter hooks audit(1151933587.676:2): selinux=0 auid=4294967295 ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 185 hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 2000kB Cache, UDMA(66) Uniform CD-ROM driver Revision: 3.20 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. EXT3 FS on md0, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md2, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md3, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md4, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on md5, internal journal EXT3-fs: mounted filesystem with ordered data mode. ReiserFS: sda8: found reiserfs format "3.6" with standard journal ReiserFS: sda8: using ordered data mode ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: sda8: checking transaction log (sda8) ReiserFS: sda8: Using r5 hash to sort names ReiserFS: sdc8: found reiserfs format "3.6" with standard journal ReiserFS: sdc8: using ordered data mode ReiserFS: sdc8: journal params: device sdc8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: sdc8: checking transaction log (sdc8) ReiserFS: sdc8: Using r5 hash to sort names kjournald starting. Commit interval 5 seconds EXT3 FS on sdb1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS on sdb2, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 248968k swap on /dev/sda9. Priority:-1 extents:1 across:248968k Adding 248968k swap on /dev/sdc9. Priority:-2 extents:1 across:248968k ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (4060 buckets, 32480 max) - 288 bytes per conntrack e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex GRE over IPv4 tunneling driver NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver Bluetooth: Core ver 2.8 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.7 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 eth0: no IPv6 routers present [root@tornado ~]# [root@tornado ~]# lspci -v 00:00.0 Host bridge: Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub (rev 02) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:02.0 VGA compatible controller: Intel Corporation 945G/GZ Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at 48100000 (32-bit, non-prefetchable) [size=512K] I/O ports at 30e0 [size=8] Memory at 40000000 (32-bit, prefetchable) [size=128M] Memory at 48180000 (32-bit, non-prefetchable) [size=128K] Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00002000-00002fff Memory behind bridge: 48000000-480fffff Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [0000] Capabilities: [a0] Power Management version 2 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0, IRQ 66 I/O ports at 3080 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0, IRQ 185 I/O ports at 3060 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0, IRQ 177 I/O ports at 3040 [size=32] 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) (prog-if 00 [UHCI]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0, IRQ 193 I/O ports at 3020 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0, IRQ 66 Memory at 481a0400 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01 [Subtractive decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=06, subordinate=06, sec-latency=32 I/O behind bridge: 00001000-00001fff Capabilities: [50] #0d [0000] 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: bus master, medium devsel, latency 0, IRQ 177 I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at <unassigned> I/O ports at 30b0 [size=16] 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) (prog-if 01 [AHCI 1.0]) Subsystem: Intel Corporation Unknown device 544e Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58 I/O ports at 30c8 [size=8] I/O ports at 30ec [size=4] I/O ports at 30c0 [size=8] I/O ports at 30e8 [size=4] I/O ports at 30a0 [size=16] Memory at 481a0000 (32-bit, non-prefetchable) [size=1K] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [70] Power Management version 2 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) Subsystem: Intel Corporation DeskTop Board D945GTP Flags: medium devsel, IRQ 185 I/O ports at 3000 [size=32] 01:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03) Subsystem: Intel Corporation Unknown device 3094 Flags: bus master, fast devsel, latency 0, IRQ 74 Memory at 48000000 (32-bit, non-prefetchable) [size=128K] I/O ports at 2000 [size=32] Capabilities: [c8] Power Management version 2 Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Capabilities: [e0] Express Endpoint IRQ 0 06:03.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01) (prog-if 02 [16550]) Subsystem: Timedia Technology Co Ltd Unknown device 0002 Flags: stepping, medium devsel, IRQ 185 I/O ports at 1000 [size=32] [root@tornado ~]# Reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly 2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 20:21 ` Andrew Morton 2006-07-03 20:31 ` 2.6.17-mm6 Reuben Farrelly 1 sibling, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 20:21 UTC (permalink / raw) To: Reuben Farrelly; +Cc: linux-kernel, greg, brice On Mon, 03 Jul 2006 23:41:42 +1200 Reuben Farrelly <reuben-lkml@reub.net> wrote: > Allocate Port Service[0000:00:1c.0:pcie0] > Allocate Port Service[0000:00:1c.0:pcie0] Turns out that we have a rogue patch coming in from the powerpc tree. This should fix it, thanks. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/hot-fixes/git-powerpc-revert-bogus-vsnprintf-change.patch --- a/lib/vsprintf.c~git-powerpc-revert-bogus-vsnprintf-change +++ a/lib/vsprintf.c @@ -283,12 +283,12 @@ int vsnprintf(char *buf, size_t size, co } str = buf; - end = buf + size - 1; + end = buf + size; /* Make sure end is always >= buf */ - if (end < buf - 1) { + if (end < buf) { end = ((void *)-1); - size = end - buf + 1; + size = end - buf; } for (; *fmt ; ++fmt) { _ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 20:21 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 20:31 ` Reuben Farrelly 0 siblings, 0 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-03 20:31 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, greg, brice On 4/07/2006 8:21 a.m., Andrew Morton wrote: > On Mon, 03 Jul 2006 23:41:42 +1200 > Reuben Farrelly <reuben-lkml@reub.net> wrote: > >> Allocate Port Service[0000:00:1c.0:pcie0] >> Allocate Port Service[0000:00:1c.0:pcie0] > > Turns out that we have a rogue patch coming in from the powerpc tree. This > should fix it, thanks. > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/hot-fixes/git-powerpc-revert-bogus-vsnprintf-change.patch That has fixed it. All looking fine now.. reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly 2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton 2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 12:29 ` Sergey Vlasov 2006-07-03 17:25 ` 2.6.17-mm6 Jeremy Fitzhardinge 2 siblings, 1 reply; 111+ messages in thread From: Sergey Vlasov @ 2006-07-03 12:29 UTC (permalink / raw) To: Reuben Farrelly; +Cc: Andrew Morton, linux-kernel, greg, brice [-- Attachment #1: Type: text/plain, Size: 1954 bytes --] On Mon, 03 Jul 2006 23:00:34 +1200 Reuben Farrelly wrote: > Allocate Port Service[0000:00:1c.0:pcie0] > Allocate Port Service[0000:00:1c.0:pcie0] > kobject_add failed for 0000:00:1c.0:pcie0 with -EEXIST, don't try to register > things with the same name in the same directory. These names are truncated - they should end with two hex digits: snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x", pci_name(parent), get_descriptor_id(port_type, service_type)); Names were truncated at 18 characters, but sizeof(device->bus_id) is 20 currently, so these names should just fit there. I see that snprintf() was changed recently - maybe there is some off-by-one bug there? And if you want, you can blame me for such long names: commit 8c9ad508c8737ca46a4c55b1062d159b86f7cee2 Author: Sergey Vlasov <vsu@altlinux.ru> Date: Mon Nov 14 20:30:50 2005 +0300 [PATCH] PCIE: make bus_id for PCI Express devices unique The bus_id string must be unique for all devices of that bus in the system, not just for devices with the same parent - otherwise multiple symlinks with identical names appear in /sys/bus/pci_express/devices. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c index 467a4ce..e4e5f1e 100644 --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -238,8 +238,8 @@ static void pcie_device_init(struct pci_ device->driver = NULL; device->driver_data = NULL; device->release = release_pcie_device; /* callback to free pcie dev */ - sprintf(&device->bus_id[0], "pcie%02x", - get_descriptor_id(port_type, service_type)); + snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x", + pci_name(parent), get_descriptor_id(port_type, service_type)); device->parent = &parent->dev; } [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --] ^ permalink raw reply related [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov @ 2006-07-03 17:25 ` Jeremy Fitzhardinge 2006-07-03 19:01 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Jeremy Fitzhardinge @ 2006-07-03 17:25 UTC (permalink / raw) To: Sergey Vlasov; +Cc: Reuben Farrelly, Andrew Morton, linux-kernel, greg, brice Sergey Vlasov wrote: > These names are truncated - they should end with two hex digits: > > snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x", > pci_name(parent), get_descriptor_id(port_type, service_type)); > > Names were truncated at 18 characters, but sizeof(device->bus_id) is 20 > currently, so these names should just fit there. I see that snprintf() > was changed recently - maybe there is some off-by-one bug there? > There was for a while, but it should be OK in -mm6. Perhaps there's a stray patch hanging around in this kernel? J ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 17:25 ` 2.6.17-mm6 Jeremy Fitzhardinge @ 2006-07-03 19:01 ` Andrew Morton 0 siblings, 0 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-03 19:01 UTC (permalink / raw) To: Jeremy Fitzhardinge; +Cc: vsu, reuben-lkml, linux-kernel, greg, brice On Mon, 03 Jul 2006 10:25:45 -0700 Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Sergey Vlasov wrote: > > These names are truncated - they should end with two hex digits: > > > > snprintf(device->bus_id, sizeof(device->bus_id), "%s:pcie%02x", > > pci_name(parent), get_descriptor_id(port_type, service_type)); > > > > Names were truncated at 18 characters, but sizeof(device->bus_id) is 20 > > currently, so these names should just fit there. I see that snprintf() > > was changed recently - maybe there is some off-by-one bug there? > > Darnit, I was staring at the wrong code so much that I never even noticed that. > There was for a while, but it should be OK in -mm6. Perhaps there's a > stray patch hanging around in this kernel? > No, it's still wrong. end = buf + size - 1; ... end[-1] = '\0'; ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton 2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski 2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly @ 2006-07-03 12:15 ` Cedric Le Goater 2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens 2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater ` (7 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: Cedric Le Goater @ 2006-07-03 12:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Martin Peschke Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ the statistic infrastructure is required when compiling the ZFCP driver on zSeries. thanks, C. From: Cedric Le Goater <clg@fr.ibm.com> Subject: [statistics infrastructure] exploitation zfcp fix Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Cc: Martin Peschke <mp3@de.ibm.com> --- drivers/scsi/Kconfig | 1 + 1 file changed, 1 insertion(+) Index: 2.6.17-mm6/drivers/scsi/Kconfig =================================================================== --- 2.6.17-mm6.orig/drivers/scsi/Kconfig +++ 2.6.17-mm6/drivers/scsi/Kconfig @@ -2200,6 +2200,7 @@ config ZFCP tristate "FCP host bus adapter driver for IBM eServer zSeries" depends on S390 && QDIO && SCSI select SCSI_FC_ATTRS + select STATISTICS help If you want to access SCSI devices attached to your IBM eServer zSeries by means of Fibre Channel interfaces say Y. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater @ 2006-07-03 12:17 ` Heiko Carstens 2006-07-03 13:08 ` 2.6.17-mm6 Martin Peschke 2006-07-03 13:12 ` 2.6.17-mm6 Cedric Le Goater 0 siblings, 2 replies; 111+ messages in thread From: Heiko Carstens @ 2006-07-03 12:17 UTC (permalink / raw) To: Cedric Le Goater; +Cc: Andrew Morton, linux-kernel, Martin Peschke > the statistic infrastructure is required when compiling the ZFCP driver on > zSeries. > --- > drivers/scsi/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > Index: 2.6.17-mm6/drivers/scsi/Kconfig > =================================================================== > --- 2.6.17-mm6.orig/drivers/scsi/Kconfig > +++ 2.6.17-mm6/drivers/scsi/Kconfig > @@ -2200,6 +2200,7 @@ config ZFCP > tristate "FCP host bus adapter driver for IBM eServer zSeries" > depends on S390 && QDIO && SCSI > select SCSI_FC_ATTRS > + select STATISTICS > help > If you want to access SCSI devices attached to your IBM eServer > zSeries by means of Fibre Channel interfaces say Y. That's the wrong approach. We rather need some no-op defines that make this compile for !CONFIG_STATISTICS. Martin is working on it, I think. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens @ 2006-07-03 13:08 ` Martin Peschke 2006-07-03 13:12 ` 2.6.17-mm6 Cedric Le Goater 1 sibling, 0 replies; 111+ messages in thread From: Martin Peschke @ 2006-07-03 13:08 UTC (permalink / raw) To: Heiko Carstens; +Cc: Cedric Le Goater, Andrew Morton, linux-kernel Heiko Carstens wrote: >> the statistic infrastructure is required when compiling the ZFCP driver on >> zSeries. >> --- >> drivers/scsi/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> Index: 2.6.17-mm6/drivers/scsi/Kconfig >> =================================================================== >> --- 2.6.17-mm6.orig/drivers/scsi/Kconfig >> +++ 2.6.17-mm6/drivers/scsi/Kconfig >> @@ -2200,6 +2200,7 @@ config ZFCP >> tristate "FCP host bus adapter driver for IBM eServer zSeries" >> depends on S390 && QDIO && SCSI >> select SCSI_FC_ATTRS >> + select STATISTICS >> help >> If you want to access SCSI devices attached to your IBM eServer >> zSeries by means of Fibre Channel interfaces say Y. > > That's the wrong approach. We rather need some no-op defines that make > this compile for !CONFIG_STATISTICS. Martin is working on it, I think. My fault, sorry. Heiko is right. I need to fix include/linux/statistic.h. I will post the fix tonight. Martin ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens 2006-07-03 13:08 ` 2.6.17-mm6 Martin Peschke @ 2006-07-03 13:12 ` Cedric Le Goater 1 sibling, 0 replies; 111+ messages in thread From: Cedric Le Goater @ 2006-07-03 13:12 UTC (permalink / raw) To: Heiko Carstens; +Cc: Andrew Morton, linux-kernel, Martin Peschke Heiko Carstens wrote: >> the statistic infrastructure is required when compiling the ZFCP driver on >> zSeries. >> --- >> drivers/scsi/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> Index: 2.6.17-mm6/drivers/scsi/Kconfig >> =================================================================== >> --- 2.6.17-mm6.orig/drivers/scsi/Kconfig >> +++ 2.6.17-mm6/drivers/scsi/Kconfig >> @@ -2200,6 +2200,7 @@ config ZFCP >> tristate "FCP host bus adapter driver for IBM eServer zSeries" >> depends on S390 && QDIO && SCSI >> select SCSI_FC_ATTRS >> + select STATISTICS >> help >> If you want to access SCSI devices attached to your IBM eServer >> zSeries by means of Fibre Channel interfaces say Y. > > That's the wrong approach. We rather need some no-op defines that make > this compile for !CONFIG_STATISTICS. Martin is working on it, I think. yes, you're right. My approach is the shortest path to fix this -mm6 : statistics-infrastructure-exploitation-zfcp.patch thanks, C. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (2 preceding siblings ...) 2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater @ 2006-07-03 12:15 ` Cedric Le Goater 2006-07-03 14:09 ` 2.6.17-mm6 Theodore Tso 2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan ` (6 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: Cedric Le Goater @ 2006-07-03 12:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Martin Peschke, Theodore Ts'o Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ This patch fixes a minor issue between the statistic infrastructure patchset and the inode diet patchset. thanks, C. From: Cedric Le Goater <clg@fr.ibm.com> Subject: [statistics infrastructure] replace inode u.generic_ip with i_private Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> Cc: Martin Peschke <mp3@de.ibm.com> Cc: "Theodore Ts'o" <tytso@mit.edu> --- lib/statistic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.17-mm6/lib/statistic.c =================================================================== --- 2.6.17-mm6.orig/lib/statistic.c +++ 2.6.17-mm6/lib/statistic.c @@ -666,7 +666,7 @@ static int statistic_generic_open(struct struct file *file, struct statistic_interface **interface, struct statistic_file_private **private) { - *interface = inode->u.generic_ip; + *interface = inode->i_private; BUG_ON(!interface); *private = kzalloc(sizeof(struct statistic_file_private), GFP_KERNEL); if (unlikely(!*private)) @@ -749,7 +749,7 @@ static ssize_t statistic_generic_write(s static int statistic_def_close(struct inode *inode, struct file *file) { - struct statistic_interface *interface = inode->u.generic_ip; + struct statistic_interface *interface = inode->i_private; struct statistic_file_private *private = file->private_data; struct sgrb_seg *seg, *seg_nl; int offset; ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater @ 2006-07-03 14:09 ` Theodore Tso 0 siblings, 0 replies; 111+ messages in thread From: Theodore Tso @ 2006-07-03 14:09 UTC (permalink / raw) To: Cedric Le Goater; +Cc: Andrew Morton, linux-kernel, Martin Peschke On Mon, Jul 03, 2006 at 02:15:57PM +0200, Cedric Le Goater wrote: > Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > This patch fixes a minor issue between the statistic infrastructure > patchset and the inode diet patchset. Acked-by: "Theodore Ts'o" <tytso@mit.edu> Sorry, I missed this one. - Ted ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (3 preceding siblings ...) 2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater @ 2006-07-03 19:07 ` Alistair John Strachan 2006-07-03 19:37 ` 2.6.17-mm6 Andrew Morton 2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan ` (5 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-03 19:07 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 11:03, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17 >-mm6/ Haven't tried an -mm kernel for a while, but I'm getting some linker warnings (buggy linker)? [alistair] 20:02 [~] as --version GNU assembler 2.16.91.0.7 20060317 [alistair] 20:02 [~] gcc --version gcc (GCC) 4.1.1 SYSCALL arch/x86_64/ia32/vsyscall-sysenter.so /usr/bin/ld: warning: i386 architecture of input file `arch/x86_64/ia32/vsyscall-sysenter.o' is incompatible with i386:x86-64 output SYSCALL arch/x86_64/ia32/vsyscall-syscall.so /usr/bin/ld: warning: i386 architecture of input file `arch/x86_64/ia32/vsyscall-syscall.o' is incompatible with i386:x86-64 output CC kernel/lockdep.o {standard input}: Assembler messages: {standard input}:6223: Warning: .space or .fill with negative value, ignored {standard input}:6682: Warning: .space or .fill with negative value, ignored {standard input}:7332: Warning: .space or .fill with negative value, ignored {standard input}:8134: Warning: .space or .fill with negative value, ignored {standard input}:8305: Warning: .space or .fill with negative value, ignored LD arch/x86_64/boot/compressed/vmlinux ld: warning: i386:x86-64 architecture of input file `arch/x86_64/boot/compressed/head.o' is incompatible with i386 output I get this last one on mainline too. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 19:37 ` Andrew Morton 2006-07-03 19:43 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 19:37 UTC (permalink / raw) To: Alistair John Strachan; +Cc: linux-kernel On Mon, 3 Jul 2006 20:07:11 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > On Monday 03 July 2006 11:03, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17 > >-mm6/ > > Haven't tried an -mm kernel for a while, but I'm getting some linker warnings > (buggy linker)? > > [alistair] 20:02 [~] as --version > GNU assembler 2.16.91.0.7 20060317 > > [alistair] 20:02 [~] gcc --version > gcc (GCC) 4.1.1 > > SYSCALL arch/x86_64/ia32/vsyscall-sysenter.so > /usr/bin/ld: warning: i386 architecture of input file > `arch/x86_64/ia32/vsyscall-sysenter.o' is incompatible with i386:x86-64 > output > > SYSCALL arch/x86_64/ia32/vsyscall-syscall.so > /usr/bin/ld: warning: i386 architecture of input file > `arch/x86_64/ia32/vsyscall-syscall.o' is incompatible with i386:x86-64 output > > CC kernel/lockdep.o > {standard input}: Assembler messages: > {standard input}:6223: Warning: .space or .fill with negative value, ignored > {standard input}:6682: Warning: .space or .fill with negative value, ignored > {standard input}:7332: Warning: .space or .fill with negative value, ignored > {standard input}:8134: Warning: .space or .fill with negative value, ignored > {standard input}:8305: Warning: .space or .fill with negative value, ignored > > LD arch/x86_64/boot/compressed/vmlinux > ld: warning: i386:x86-64 architecture of input file > `arch/x86_64/boot/compressed/head.o' is incompatible with i386 output > > I get this last one on mainline too. Perhaps a `make mrproper' is needed? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 19:37 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 19:43 ` Alistair John Strachan 0 siblings, 0 replies; 111+ messages in thread From: Alistair John Strachan @ 2006-07-03 19:43 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 20:37, Andrew Morton wrote: [snip] > > LD arch/x86_64/boot/compressed/vmlinux > > ld: warning: i386:x86-64 architecture of input file > > `arch/x86_64/boot/compressed/head.o' is incompatible with i386 output > > > > I get this last one on mainline too. > > Perhaps a `make mrproper' is needed? Nah, this was a fresh tree. Did it, tried again, still happening. It's possible the linker is broken in some way, but I only see this with the kernel. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (4 preceding siblings ...) 2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 19:27 ` Alistair John Strachan 2006-07-03 19:39 ` 2.6.17-mm6 Andrew Morton 2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki ` (4 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-03 19:27 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 11:03, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17 >-mm6/ Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it oopses horribly. Is there some way to supress an oops flood so I can get a decent picture of it with vga=extended? Right now I get two useless oopses after the first (probably useful) one. The one time I did get it to boot, I get a lockdep problem (possibly already reported, if so I'm sorry); ============================================= [ INFO: possible recursive locking detected ] --------------------------------------------- mount/1095 is trying to acquire lock: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0 but task is already holding lock: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0 other info that might help us debug this: 2 locks held by mount/1095: #0: (&inode->i_mutex){--..}, at: [<ffffffff8026ead5>] mutex_lock+0x25/0x30 #1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0 stack backtrace: Call Trace: [<ffffffff8027479e>] show_trace+0xae/0x280 [<ffffffff80274985>] dump_stack+0x15/0x20 [<ffffffff802afa06>] __lock_acquire+0x936/0xcd0 [<ffffffff802afe28>] lock_acquire+0x88/0xc0 [<ffffffff802abe49>] down_write+0x39/0x50 [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0 [<ffffffff80329b3a>] xfs_iget+0x2da/0x760 [<ffffffff80341804>] xfs_trans_iget+0xc4/0x150 [<ffffffff8032df8e>] xfs_ialloc+0x9e/0x4d0 [<ffffffff803423df>] xfs_dir_ialloc+0x7f/0x2d0 [<ffffffff80348e24>] xfs_create+0x364/0x6d0 [<ffffffff80352e9a>] xfs_vn_mknod+0x16a/0x300 [<ffffffff8035304b>] xfs_vn_create+0xb/0x10 [<ffffffff8023f92d>] vfs_create+0x8d/0xf0 [<ffffffff8021cd42>] open_namei+0x1c2/0x700 [<ffffffff80229e32>] do_filp_open+0x22/0x50 [<ffffffff8021b78a>] do_sys_open+0x5a/0xf0 [<ffffffff80235e5b>] sys_open+0x1b/0x20 [<ffffffff8026894e>] system_call+0x7e/0x83 [<000000337b1ac6e2>] XFS mounting filesystem sdb1 I'm also getting the same: kobject_add failed for 0000:00:0b.0:pcie0 with -EEXIST, don't try to register things with the same name in the same directory. ..that Reuben reported, multiple times. Otherwise it's all good. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 19:39 ` Andrew Morton 2006-07-03 19:56 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 19:39 UTC (permalink / raw) To: Alistair John Strachan; +Cc: linux-kernel, Nathan Scott On Mon, 3 Jul 2006 20:27:21 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > On Monday 03 July 2006 11:03, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17 > >-mm6/ > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it oopses > horribly. Is there some way to supress an oops flood so I can get a decent > picture of it with vga=extended? Right now I get two useless oopses after the > first (probably useful) one. Try adding `pause_on_oops=100000' to the kernel boot command line. > The one time I did get it to boot, I get a lockdep problem (possibly already > reported, if so I'm sorry); > > ============================================= > [ INFO: possible recursive locking detected ] > --------------------------------------------- > mount/1095 is trying to acquire lock: > (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>] > xfs_ilock+0x67/0xa0 > > but task is already holding lock: > (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>] > xfs_ilock+0x67/0xa0 > > other info that might help us debug this: > 2 locks held by mount/1095: > #0: (&inode->i_mutex){--..}, at: [<ffffffff8026ead5>] mutex_lock+0x25/0x30 > #1: (&(&ip->i_lock)->mr_lock){----}, at: [<ffffffff80328ef7>] > xfs_ilock+0x67/0xa0 > > stack backtrace: > > Call Trace: > [<ffffffff8027479e>] show_trace+0xae/0x280 > [<ffffffff80274985>] dump_stack+0x15/0x20 > [<ffffffff802afa06>] __lock_acquire+0x936/0xcd0 > [<ffffffff802afe28>] lock_acquire+0x88/0xc0 > [<ffffffff802abe49>] down_write+0x39/0x50 > [<ffffffff80328ef7>] xfs_ilock+0x67/0xa0 > [<ffffffff80329b3a>] xfs_iget+0x2da/0x760 > [<ffffffff80341804>] xfs_trans_iget+0xc4/0x150 > [<ffffffff8032df8e>] xfs_ialloc+0x9e/0x4d0 > [<ffffffff803423df>] xfs_dir_ialloc+0x7f/0x2d0 > [<ffffffff80348e24>] xfs_create+0x364/0x6d0 > [<ffffffff80352e9a>] xfs_vn_mknod+0x16a/0x300 > [<ffffffff8035304b>] xfs_vn_create+0xb/0x10 > [<ffffffff8023f92d>] vfs_create+0x8d/0xf0 > [<ffffffff8021cd42>] open_namei+0x1c2/0x700 > [<ffffffff80229e32>] do_filp_open+0x22/0x50 > [<ffffffff8021b78a>] do_sys_open+0x5a/0xf0 > [<ffffffff80235e5b>] sys_open+0x1b/0x20 > [<ffffffff8026894e>] system_call+0x7e/0x83 > [<000000337b1ac6e2>] > XFS mounting filesystem sdb1 That could be deliberate nesting of the same lock in XFS. Or it could be a false-positive due to an earlier oops. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 19:39 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 19:56 ` Alistair John Strachan 2006-07-03 20:17 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-03 19:56 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 20:39, Andrew Morton wrote: > On Mon, 3 Jul 2006 20:27:21 +0100 > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > On Monday 03 July 2006 11:03, Andrew Morton wrote: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2. > > >6.17 -mm6/ > > > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it > > oopses horribly. Is there some way to supress an oops flood so I can get > > a decent picture of it with vga=extended? Right now I get two useless > > oopses after the first (probably useful) one. > > Try adding `pause_on_oops=100000' to the kernel boot command line. (Trimmed Nathan) Helped somewhat, but I'm still missing a bit at the top. http://devzero.co.uk/~alistair/oops-20060703/ Apologies for the poor quality photos. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 19:56 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 20:17 ` Andrew Morton 2006-07-03 20:36 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 20:17 UTC (permalink / raw) To: Alistair John Strachan; +Cc: linux-kernel On Mon, 3 Jul 2006 20:56:28 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > On Monday 03 July 2006 20:39, Andrew Morton wrote: > > On Mon, 3 Jul 2006 20:27:21 +0100 > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > On Monday 03 July 2006 11:03, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2. > > > >6.17 -mm6/ > > > > > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times it > > > oopses horribly. Is there some way to supress an oops flood so I can get > > > a decent picture of it with vga=extended? Right now I get two useless > > > oopses after the first (probably useful) one. > > > > Try adding `pause_on_oops=100000' to the kernel boot command line. > > (Trimmed Nathan) > > Helped somewhat, but I'm still missing a bit at the top. > > http://devzero.co.uk/~alistair/oops-20060703/ > That is irritating. This should get us more info: --- a/arch/x86_64/kernel/traps.c~a +++ a/arch/x86_64/kernel/traps.c @@ -122,12 +122,12 @@ void printk_address(unsigned long addres symname = kallsyms_lookup(address, &symsize, &offset, &modname, namebuf); if (!symname) { - printk(" [<%016lx>]\n", address); + printk(" [<%016lx>] ", address); return; } if (!modname) modname = delim = ""; - printk(" [<%016lx>] %s%s%s%s+0x%lx/0x%lx\n", + printk(" [<%016lx>] %s%s%s%s+0x%lx/0x%lx ", address, delim, modname, delim, symname, offset, symsize); } #else _ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 20:17 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 20:36 ` Alistair John Strachan 2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-03 20:36 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 21:17, Andrew Morton wrote: > On Mon, 3 Jul 2006 20:56:28 +0100 > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > On Monday 03 July 2006 20:39, Andrew Morton wrote: > > > On Mon, 3 Jul 2006 20:27:21 +0100 > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > On Monday 03 July 2006 11:03, Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 > > > > >7/2. 6.17 -mm6/ > > > > > > > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times > > > > it oopses horribly. Is there some way to supress an oops flood so I > > > > can get a decent picture of it with vga=extended? Right now I get two > > > > useless oopses after the first (probably useful) one. > > > > > > Try adding `pause_on_oops=100000' to the kernel boot command line. > > > > (Trimmed Nathan) > > > > Helped somewhat, but I'm still missing a bit at the top. > > > > http://devzero.co.uk/~alistair/oops-20060703/ > > That is irritating. This should get us more info: Indeed, thanks. Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I still think I'm missing something at the top, but 3 is the earliest I could snap. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 20:36 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 20:54 ` Andrew Morton 2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan 2006-07-03 22:10 ` 2.6.17-mm6 Anton Blanchard 0 siblings, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-03 20:54 UTC (permalink / raw) To: Alistair John Strachan; +Cc: linux-kernel On Mon, 3 Jul 2006 21:36:55 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > On Monday 03 July 2006 21:17, Andrew Morton wrote: > > On Mon, 3 Jul 2006 20:56:28 +0100 > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > On Monday 03 July 2006 20:39, Andrew Morton wrote: > > > > On Mon, 3 Jul 2006 20:27:21 +0100 > > > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > On Monday 03 July 2006 11:03, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 > > > > > >7/2. 6.17 -mm6/ > > > > > > > > > > Doesn't boot reliably as an x86-64 kernel on my X2 system, 3/4 times > > > > > it oopses horribly. Is there some way to supress an oops flood so I > > > > > can get a decent picture of it with vga=extended? Right now I get two > > > > > useless oopses after the first (probably useful) one. > > > > > > > > Try adding `pause_on_oops=100000' to the kernel boot command line. > > > > > > (Trimmed Nathan) > > > > > > Helped somewhat, but I'm still missing a bit at the top. > > > > > > http://devzero.co.uk/~alistair/oops-20060703/ > > > > That is irritating. This should get us more info: > > Indeed, thanks. > > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I still > think I'm missing something at the top, but 3 is the earliest I could snap. > Getting better. It would kinda help if pause_on_oops() was actually implemented on x86_64.. --- a/arch/x86_64/kernel/traps.c~x86_64-wire-up-oops_enter-oops_exit +++ a/arch/x86_64/kernel/traps.c @@ -551,11 +551,14 @@ void __kprobes __die(const char * str, s void die(const char * str, struct pt_regs * regs, long err) { - unsigned long flags = oops_begin(); + unsigned long flags; + oops_enter(); + flags = oops_begin(); handle_BUG(regs); __die(str, regs, err); oops_end(flags); + oops_exit(); do_exit(SIGSEGV); } _ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton @ 2006-07-03 21:50 ` Alistair John Strachan 2006-07-03 23:31 ` 2.6.17-mm6 Andrew Morton 2006-07-03 22:10 ` 2.6.17-mm6 Anton Blanchard 1 sibling, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-03 21:50 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 21:54, Andrew Morton wrote: > On Mon, 3 Jul 2006 21:36:55 +0100 > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > On Monday 03 July 2006 21:17, Andrew Morton wrote: > > > On Mon, 3 Jul 2006 20:56:28 +0100 > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > On Monday 03 July 2006 20:39, Andrew Morton wrote: [snip] > > > > > Try adding `pause_on_oops=100000' to the kernel boot command line. > > > > > > > > (Trimmed Nathan) > > > > > > > > Helped somewhat, but I'm still missing a bit at the top. > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/ > > > > > > That is irritating. This should get us more info: > > > > Indeed, thanks. > > > > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I > > still think I'm missing something at the top, but 3 is the earliest I > > could snap. > > Getting better. > > It would kinda help if pause_on_oops() was actually implemented on x86_64.. Doesn't help (work?). [alistair] 22:47 [~] strings /boot/vmlinuz-2.6.17-mm6 | grep 2.6.17-mm6 2.6.17-mm6 (alistair@damocles) #3 SMP PREEMPT Mon Jul 3 22:39:54 BST 2006 [alistair] 22:48 [~] cat /boot/grub/menu.lst | grep -C1 mm6 # testing title Linux 2.6.17-mm6 root (hd0,0) kernel /boot/vmlinuz-2.6.17-mm6 vga=extended root=/dev/sda1 pause_on_oops=100000 I'm fairly sure I booted a kernel with your patch and that should be the right cmdline flag. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 23:31 ` Andrew Morton 2006-07-04 8:34 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-03 23:31 UTC (permalink / raw) To: Alistair John Strachan; +Cc: linux-kernel On Mon, 3 Jul 2006 22:50:02 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > On Monday 03 July 2006 21:54, Andrew Morton wrote: > > On Mon, 3 Jul 2006 21:36:55 +0100 > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > On Monday 03 July 2006 21:17, Andrew Morton wrote: > > > > On Mon, 3 Jul 2006 20:56:28 +0100 > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > On Monday 03 July 2006 20:39, Andrew Morton wrote: > [snip] > > > > > > Try adding `pause_on_oops=100000' to the kernel boot command line. > > > > > > > > > > (Trimmed Nathan) > > > > > > > > > > Helped somewhat, but I'm still missing a bit at the top. > > > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/ > > > > > > > > That is irritating. This should get us more info: > > > > > > Indeed, thanks. > > > > > > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. I > > > still think I'm missing something at the top, but 3 is the earliest I > > > could snap. > > > > Getting better. > > > > It would kinda help if pause_on_oops() was actually implemented on x86_64.. > > Doesn't help (work?). > > [alistair] 22:47 [~] strings /boot/vmlinuz-2.6.17-mm6 | grep 2.6.17-mm6 > 2.6.17-mm6 (alistair@damocles) #3 SMP PREEMPT Mon Jul 3 22:39:54 BST 2006 > > [alistair] 22:48 [~] cat /boot/grub/menu.lst | grep -C1 mm6 > # testing > title Linux 2.6.17-mm6 > root (hd0,0) > kernel /boot/vmlinuz-2.6.17-mm6 vga=extended root=/dev/sda1 > pause_on_oops=100000 > > I'm fairly sure I booted a kernel with your patch and that should be the right > cmdline flag. > OK, x86_64 is significantly different from x86 in that area (better). Have a tested version... diff -puN arch/x86_64/kernel/traps.c~x86_64-wire-up-oops_enter-oops_exit arch/x86_64/kernel/traps.c --- a/arch/x86_64/kernel/traps.c~x86_64-wire-up-oops_enter-oops_exit +++ a/arch/x86_64/kernel/traps.c @@ -551,11 +551,14 @@ void __kprobes __die(const char * str, s void die(const char * str, struct pt_regs * regs, long err) { - unsigned long flags = oops_begin(); + unsigned long flags; + oops_enter(); + flags = oops_begin(); handle_BUG(regs); __die(str, regs, err); oops_end(flags); + oops_exit(); do_exit(SIGSEGV); } diff -puN arch/x86_64/mm/fault.c~x86_64-wire-up-oops_enter-oops_exit arch/x86_64/mm/fault.c --- a/arch/x86_64/mm/fault.c~x86_64-wire-up-oops_enter-oops_exit +++ a/arch/x86_64/mm/fault.c @@ -261,9 +261,11 @@ int unhandled_signal(struct task_struct static noinline void pgtable_bad(unsigned long address, struct pt_regs *regs, unsigned long error_code) { - unsigned long flags = oops_begin(); + unsigned long flags; struct task_struct *tsk; + oops_enter(); + flags = oops_begin(); printk(KERN_ALERT "%s: Corrupted page table at address %lx\n", current->comm, address); dump_pagetable(address); @@ -273,6 +275,7 @@ static noinline void pgtable_bad(unsigne tsk->thread.error_code = error_code; __die("Bad pagetable", regs, error_code); oops_end(flags); + oops_exit(); do_exit(SIGKILL); } @@ -562,6 +565,7 @@ no_context: * terminate things with extreme prejudice. */ + oops_enter(); flags = oops_begin(); if (address < PAGE_SIZE) @@ -578,6 +582,7 @@ no_context: /* Executive summary in case the body of the oops scrolled away */ printk(KERN_EMERG "CR2: %016lx\n", address); oops_end(flags); + oops_exit(); do_exit(SIGKILL); /* _ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 23:31 ` 2.6.17-mm6 Andrew Morton @ 2006-07-04 8:34 ` Alistair John Strachan 2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-04 8:34 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Tuesday 04 July 2006 00:31, Andrew Morton wrote: [snip] > > > > > > Helped somewhat, but I'm still missing a bit at the top. > > > > > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/ > > > > > > > > > > That is irritating. This should get us more info: > > > > > > > > Indeed, thanks. > > > > > > > > Try the same URL again, I've uploaded 3,4,5 from a couple of reboots. > > > > I still think I'm missing something at the top, but 3 is the earliest > > > > I could snap. > > > > > > Getting better. > > > > > > It would kinda help if pause_on_oops() was actually implemented on > > > x86_64.. > > > > Doesn't help (work?). > > > > [alistair] 22:47 [~] strings /boot/vmlinuz-2.6.17-mm6 | grep 2.6.17-mm6 > > 2.6.17-mm6 (alistair@damocles) #3 SMP PREEMPT Mon Jul 3 22:39:54 BST 2006 > > > > [alistair] 22:48 [~] cat /boot/grub/menu.lst | grep -C1 mm6 > > # testing > > title Linux 2.6.17-mm6 > > root (hd0,0) > > kernel /boot/vmlinuz-2.6.17-mm6 vga=extended root=/dev/sda1 > > pause_on_oops=100000 > > > > I'm fairly sure I booted a kernel with your patch and that should be the > > right cmdline flag. > > OK, x86_64 is significantly different from x86 in that area (better). Have > a tested version... This one worked, thanks. Try the same URL again, I've uploaded two better shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses that interchange every couple of boots, so I've included both ;-) I suggest Andi picks up that debugging patch, it worked for me. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-04 8:34 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-04 8:49 ` Andrew Morton 2006-07-04 16:28 ` 2.6.17-mm6 Alistair John Strachan 2006-07-05 20:37 ` 2.6.17-mm6 john stultz 0 siblings, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-04 8:49 UTC (permalink / raw) To: Alistair John Strachan; +Cc: linux-kernel, Greg KH, john stultz On Tue, 4 Jul 2006 09:34:14 +0100 Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > a tested version... > > This one worked, thanks. Try the same URL again, I've uploaded two better > shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses > that interchange every couple of boots, so I've included both ;-) OK, that's more like it. Thanks again. http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg People cc'ed. Help! Can you send the .config please? > I suggest Andi picks up that debugging patch, it worked for me. He'll be hearing from me ;) ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton @ 2006-07-04 16:28 ` Alistair John Strachan 2006-07-05 20:37 ` 2.6.17-mm6 john stultz 1 sibling, 0 replies; 111+ messages in thread From: Alistair John Strachan @ 2006-07-04 16:28 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Greg KH, john stultz On Tuesday 04 July 2006 09:49, Andrew Morton wrote: [snip] > Can you send the .config please? Uploaded dmesg from a successful boot (slightly chopped, sorry), and the config for this kernel: http://devzero.co.uk/~alistair/oops-20060703/config-2.6.17-mm6 http://devzero.co.uk/~alistair/oops-20060703/dmesg -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton 2006-07-04 16:28 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-05 20:37 ` john stultz 2006-07-05 20:46 ` 2.6.17-mm6 Greg KH 1 sibling, 1 reply; 111+ messages in thread From: john stultz @ 2006-07-05 20:37 UTC (permalink / raw) To: Andrew Morton; +Cc: Alistair John Strachan, linux-kernel, Greg KH On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > On Tue, 4 Jul 2006 09:34:14 +0100 > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > a tested version... > > > > This one worked, thanks. Try the same URL again, I've uploaded two better > > shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses > > that interchange every couple of boots, so I've included both ;-) > > OK, that's more like it. Thanks again. > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > People cc'ed. Help! Hmmm. No clue on this one from just looking at it. Greg, do you see anything wrong with the way I'm registering the timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()? It looks the same as the other users to me. I'll look over the config and see if anything sticks out. thanks -john ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 20:37 ` 2.6.17-mm6 john stultz @ 2006-07-05 20:46 ` Greg KH 2006-07-05 22:32 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Greg KH @ 2006-07-05 20:46 UTC (permalink / raw) To: john stultz; +Cc: Andrew Morton, Alistair John Strachan, linux-kernel On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > On Tue, 4 Jul 2006 09:34:14 +0100 > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > a tested version... > > > > > > This one worked, thanks. Try the same URL again, I've uploaded two better > > > shots 6,7 that capture the first oops. Unfortunately, I have a pair of oopses > > > that interchange every couple of boots, so I've included both ;-) > > > > OK, that's more like it. Thanks again. > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > People cc'ed. Help! > > Hmmm. No clue on this one from just looking at it. > > Greg, do you see anything wrong with the way I'm registering the > timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()? > It looks the same as the other users to me. At first glance, no, it looks sane to me. Are you sure you aren't registering two things with the same name somehow? thanks, greg k-h ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 20:46 ` 2.6.17-mm6 Greg KH @ 2006-07-05 22:32 ` Alistair John Strachan 2006-07-06 17:31 ` 2.6.17-mm6 john stultz 0 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-05 22:32 UTC (permalink / raw) To: Greg KH; +Cc: john stultz, Andrew Morton, linux-kernel On Wednesday 05 July 2006 21:46, Greg KH wrote: > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > > On Tue, 4 Jul 2006 09:34:14 +0100 > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > a tested version... > > > > > > > > This one worked, thanks. Try the same URL again, I've uploaded two > > > > better shots 6,7 that capture the first oops. Unfortunately, I have a > > > > pair of oopses that interchange every couple of boots, so I've > > > > included both ;-) > > > > > > OK, that's more like it. Thanks again. > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > > > People cc'ed. Help! > > > > Hmmm. No clue on this one from just looking at it. > > > > Greg, do you see anything wrong with the way I'm registering the > > timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()? > > It looks the same as the other users to me. > > At first glance, no, it looks sane to me. > > Are you sure you aren't registering two things with the same name > somehow? Whatever it is, it doesn't happen every time. Sometimes the kernel boots. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 22:32 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-06 17:31 ` john stultz 2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan 2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 2 replies; 111+ messages in thread From: john stultz @ 2006-07-06 17:31 UTC (permalink / raw) To: Alistair John Strachan; +Cc: Greg KH, Andrew Morton, linux-kernel On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote: > On Wednesday 05 July 2006 21:46, Greg KH wrote: > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > > > On Tue, 4 Jul 2006 09:34:14 +0100 > > > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > > a tested version... > > > > > > > > > > This one worked, thanks. Try the same URL again, I've uploaded two > > > > > better shots 6,7 that capture the first oops. Unfortunately, I have a > > > > > pair of oopses that interchange every couple of boots, so I've > > > > > included both ;-) > > > > > > > > OK, that's more like it. Thanks again. > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > > > > > People cc'ed. Help! > > > > > > Hmmm. No clue on this one from just looking at it. > > > > > > Greg, do you see anything wrong with the way I'm registering the > > > timekeeping .resume hook in kernel/timer.c::timekeeping_init_device()? > > > It looks the same as the other users to me. > > > > At first glance, no, it looks sane to me. > > > > Are you sure you aren't registering two things with the same name > > somehow? Looking at it, I don't see how that could happen. > Whatever it is, it doesn't happen every time. Sometimes the kernel boots. Odd. Does this happen w/ 2.6.18-rc1? thanks -john ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 17:31 ` 2.6.17-mm6 john stultz @ 2006-07-06 19:06 ` Alistair John Strachan 2006-07-06 19:16 ` 2.6.17-mm6 Alistair John Strachan 2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan 1 sibling, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-06 19:06 UTC (permalink / raw) To: john stultz; +Cc: Greg KH, Andrew Morton, linux-kernel On Thursday 06 July 2006 18:31, john stultz wrote: > On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote: > > On Wednesday 05 July 2006 21:46, Greg KH wrote: > > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > > > > On Tue, 4 Jul 2006 09:34:14 +0100 > > > > > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > > > a tested version... > > > > > > > > > > > > This one worked, thanks. Try the same URL again, I've uploaded > > > > > > two better shots 6,7 that capture the first oops. Unfortunately, > > > > > > I have a pair of oopses that interchange every couple of boots, > > > > > > so I've included both ;-) > > > > > > > > > > OK, that's more like it. Thanks again. > > > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > > > > > > > People cc'ed. Help! > > > > > > > > Hmmm. No clue on this one from just looking at it. > > > > > > > > Greg, do you see anything wrong with the way I'm registering the > > > > timekeeping .resume hook in > > > > kernel/timer.c::timekeeping_init_device()? It looks the same as the > > > > other users to me. > > > > > > At first glance, no, it looks sane to me. > > > > > > Are you sure you aren't registering two things with the same name > > > somehow? > > Looking at it, I don't see how that could happen. > > > Whatever it is, it doesn't happen every time. Sometimes the kernel boots. > > Odd. Does this happen w/ 2.6.18-rc1? Seems to. First time it booted okay, but wouldn't let me log in (worse than -mm), I got the following: http://devzero.co.uk/~alistair/oops-20060703/lockup1.jpg Second time it didn't boot properly, with a similar oops to the others. I used the following config for 2.6.18-rc1, which should be very similar, but not identical. http://devzero.co.uk/~alistair/oops-20060703/config-2.6.18-rc1 I'm about to try a kernel without the lockdep stuff, then I'm going to start bisection pain. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-06 19:16 ` Alistair John Strachan 0 siblings, 0 replies; 111+ messages in thread From: Alistair John Strachan @ 2006-07-06 19:16 UTC (permalink / raw) To: john stultz; +Cc: Greg KH, Andrew Morton, linux-kernel On Thursday 06 July 2006 20:06, Alistair John Strachan wrote: > I'm about to try a kernel without the lockdep stuff, then I'm going to > start bisection pain. And it doesn't make any difference; it really does look like a bug in something else. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 17:31 ` 2.6.17-mm6 john stultz 2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-06 20:02 ` Alistair John Strachan 2006-07-06 20:11 ` 2.6.17-mm6 Greg KH 1 sibling, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-06 20:02 UTC (permalink / raw) To: john stultz; +Cc: Greg KH, Andrew Morton, linux-kernel On Thursday 06 July 2006 18:31, john stultz wrote: > On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote: > > On Wednesday 05 July 2006 21:46, Greg KH wrote: > > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > > > > On Tue, 4 Jul 2006 09:34:14 +0100 > > > > > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > > > a tested version... > > > > > > > > > > > > This one worked, thanks. Try the same URL again, I've uploaded > > > > > > two better shots 6,7 that capture the first oops. Unfortunately, > > > > > > I have a pair of oopses that interchange every couple of boots, > > > > > > so I've included both ;-) > > > > > > > > > > OK, that's more like it. Thanks again. > > > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > > > > > > > People cc'ed. Help! > > > > > > > > Hmmm. No clue on this one from just looking at it. > > > > > > > > Greg, do you see anything wrong with the way I'm registering the > > > > timekeeping .resume hook in > > > > kernel/timer.c::timekeeping_init_device()? It looks the same as the > > > > other users to me. > > > > > > At first glance, no, it looks sane to me. > > > > > > Are you sure you aren't registering two things with the same name > > > somehow? > > Looking at it, I don't see how that could happen. I don't think it's John's code. I commented out the sysfs registration code from timekeeping_init_device() and the kernel gets further, where it crashes on kmem_cache_create. SLAB also complains about "losing its name" and being "of size 0". This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it be anything you've changed recently? I considered bisectioning -mm, but there's been a lot of RAID problems and I'm using RAID5. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-06 20:11 ` Greg KH 2006-07-07 20:48 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Greg KH @ 2006-07-06 20:11 UTC (permalink / raw) To: Alistair John Strachan; +Cc: john stultz, Andrew Morton, linux-kernel On Thu, Jul 06, 2006 at 09:02:50PM +0100, Alistair John Strachan wrote: > On Thursday 06 July 2006 18:31, john stultz wrote: > > On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote: > > > On Wednesday 05 July 2006 21:46, Greg KH wrote: > > > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > > > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > > > > > On Tue, 4 Jul 2006 09:34:14 +0100 > > > > > > > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > > > > a tested version... > > > > > > > > > > > > > > This one worked, thanks. Try the same URL again, I've uploaded > > > > > > > two better shots 6,7 that capture the first oops. Unfortunately, > > > > > > > I have a pair of oopses that interchange every couple of boots, > > > > > > > so I've included both ;-) > > > > > > > > > > > > OK, that's more like it. Thanks again. > > > > > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > > > > > > > > > People cc'ed. Help! > > > > > > > > > > Hmmm. No clue on this one from just looking at it. > > > > > > > > > > Greg, do you see anything wrong with the way I'm registering the > > > > > timekeeping .resume hook in > > > > > kernel/timer.c::timekeeping_init_device()? It looks the same as the > > > > > other users to me. > > > > > > > > At first glance, no, it looks sane to me. > > > > > > > > Are you sure you aren't registering two things with the same name > > > > somehow? > > > > Looking at it, I don't see how that could happen. > > I don't think it's John's code. I commented out the sysfs registration code > from timekeeping_init_device() and the kernel gets further, where it crashes > on kmem_cache_create. SLAB also complains about "losing its name" and > being "of size 0". > > This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it be > anything you've changed recently? I considered bisectioning -mm, but there's > been a lot of RAID problems and I'm using RAID5. Please bisect 2.6.18-rc1 if you have git, as the problem is there, and would be good to track down. thanks, greg k-h ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 20:11 ` 2.6.17-mm6 Greg KH @ 2006-07-07 20:48 ` Alistair John Strachan 2006-07-08 16:02 ` 2.6.17-mm6 Alistair John Strachan 0 siblings, 1 reply; 111+ messages in thread From: Alistair John Strachan @ 2006-07-07 20:48 UTC (permalink / raw) To: Greg KH; +Cc: john stultz, Andrew Morton, linux-kernel On Thursday 06 July 2006 21:11, Greg KH wrote: > On Thu, Jul 06, 2006 at 09:02:50PM +0100, Alistair John Strachan wrote: > > On Thursday 06 July 2006 18:31, john stultz wrote: > > > On Wed, 2006-07-05 at 23:32 +0100, Alistair John Strachan wrote: > > > > On Wednesday 05 July 2006 21:46, Greg KH wrote: > > > > > On Wed, Jul 05, 2006 at 01:37:13PM -0700, john stultz wrote: > > > > > > On Tue, 2006-07-04 at 01:49 -0700, Andrew Morton wrote: > > > > > > > On Tue, 4 Jul 2006 09:34:14 +0100 > > > > > > > > > > > > > > Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote: > > > > > > > > > a tested version... > > > > > > > > > > > > > > > > This one worked, thanks. Try the same URL again, I've > > > > > > > > uploaded two better shots 6,7 that capture the first oops. > > > > > > > > Unfortunately, I have a pair of oopses that interchange every > > > > > > > > couple of boots, so I've included both ;-) > > > > > > > > > > > > > > OK, that's more like it. Thanks again. > > > > > > > > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops6.jpg > > > > > > > http://devzero.co.uk/~alistair/oops-20060703/oops7.jpg > > > > > > > > > > > > > > People cc'ed. Help! > > > > > > > > > > > > Hmmm. No clue on this one from just looking at it. > > > > > > > > > > > > Greg, do you see anything wrong with the way I'm registering the > > > > > > timekeeping .resume hook in > > > > > > kernel/timer.c::timekeeping_init_device()? It looks the same as > > > > > > the other users to me. > > > > > > > > > > At first glance, no, it looks sane to me. > > > > > > > > > > Are you sure you aren't registering two things with the same name > > > > > somehow? > > > > > > Looking at it, I don't see how that could happen. > > > > I don't think it's John's code. I commented out the sysfs registration > > code from timekeeping_init_device() and the kernel gets further, where it > > crashes on kmem_cache_create. SLAB also complains about "losing its name" > > and being "of size 0". > > > > This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it be > > anything you've changed recently? I considered bisectioning -mm, but > > there's been a lot of RAID problems and I'm using RAID5. > > Please bisect 2.6.18-rc1 if you have git, as the problem is there, and > would be good to track down. I tried this, but it's extremely difficult when the kernel boots successfully one every four times. I've already been thrown off the scent twice, bringing my bisection count to 25.. I think I'll try an allnoconfig on this machine, hopefully that will boot, then I just start enabling things again until it breaks. -- Cheers, Alistair. Third year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 20:48 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-08 16:02 ` Alistair John Strachan 0 siblings, 0 replies; 111+ messages in thread From: Alistair John Strachan @ 2006-07-08 16:02 UTC (permalink / raw) To: Greg KH; +Cc: john stultz, Andrew Morton, linux-kernel On Friday 07 July 2006 21:48, Alistair John Strachan wrote: [snip] > > > I don't think it's John's code. I commented out the sysfs registration > > > code from timekeeping_init_device() and the kernel gets further, where > > > it crashes on kmem_cache_create. SLAB also complains about "losing its > > > name" and being "of size 0". > > > > > > This happens identically on 2.6.18-rc1, and 2.6.17-mm6. Greg, could it > > > be anything you've changed recently? I considered bisectioning -mm, but > > > there's been a lot of RAID problems and I'm using RAID5. > > > > Please bisect 2.6.18-rc1 if you have git, as the problem is there, and > > would be good to track down. > > I tried this, but it's extremely difficult when the kernel boots > successfully one every four times. I've already been thrown off the scent > twice, bringing my bisection count to 25.. > > I think I'll try an allnoconfig on this machine, hopefully that will boot, > then I just start enabling things again until it breaks. Sorry, this turned out to be my fault. GCC had just recently been upgraded to 4.1.1, which apparently silently generates bad kernels with the version of H. J. Lu's binutils I had installed. I figured it out when going back to 2.6.17 didn't help. Why the crashes were sporadic I will never truly understand. Going back to GNU binutils 2.17 and rebuilding GCC 4.1.1 fixed it. At least I learnt how to use Git, which is a truly superb tool. I'm now happily running -mm6. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton 2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-03 22:10 ` Anton Blanchard 1 sibling, 0 replies; 111+ messages in thread From: Anton Blanchard @ 2006-07-03 22:10 UTC (permalink / raw) To: Andrew Morton; +Cc: Alistair John Strachan, linux-kernel > Getting better. > > It would kinda help if pause_on_oops() was actually implemented on x86_64.. Now you've made me look, it seems x86 has undergone major surgery to its oops path that most other architectures havent picked up yet. Anton ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (5 preceding siblings ...) 2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan @ 2006-07-04 19:53 ` Rafael J. Wysocki 2006-07-04 20:01 ` 2.6.17-mm6 Arjan van de Ven 2006-07-05 21:43 ` 2.6.17-mm6 J.A. Magallón ` (3 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: Rafael J. Wysocki @ 2006-07-04 19:53 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Monday 03 July 2006 12:03, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > - A major update to the e1000 driver. > > - 1394 updates Just found this in dmesg: ================================= [ INFO: inconsistent lock state ] --------------------------------- inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes: (&skb_queue_lock_key){++..}, at: [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0 {in-hardirq-W} state was registered at: [<ffffffff8024b4fa>] lock_acquire+0x8a/0xc0 [<ffffffff80476e3f>] _spin_lock_irqsave+0x3f/0x60 [<ffffffff80408c25>] skb_queue_tail+0x25/0x60 [<ffffffff881c9517>] queue_packet_complete+0x27/0x40 [ieee1394] [<ffffffff881c9d6b>] hpsb_packet_sent+0xab/0x100 [ieee1394] [<ffffffff8822a4b5>] dma_trm_reset+0x115/0x140 [ohci1394] [<ffffffff8822c512>] ohci_devctl+0x1c2/0x540 [ohci1394] [<ffffffff881c9673>] hpsb_bus_reset+0x43/0xb0 [ieee1394] [<ffffffff8822d7f6>] ohci_irq_handler+0x416/0x830 [ohci1394] [<ffffffff802631ab>] handle_IRQ_event+0x2b/0x70 [<ffffffff80264dd4>] handle_level_irq+0xc4/0x130 [<ffffffff8020c762>] do_IRQ+0x112/0x130 [<ffffffff80209d90>] common_interrupt+0x64/0x65 irq event stamp: 4280 hardirqs last enabled at (4279): [<ffffffff8047606a>] trace_hardirqs_on_thunk+0x35/0x37 hardirqs last disabled at (4278): [<ffffffff804760a1>] trace_hardirqs_off_thunk+0x35/0x67 softirqs last enabled at (4258): [<ffffffff804065b5>] release_sock+0xd5/0xe0 softirqs last disabled at (4280): [<ffffffff804764d1>] _spin_lock_bh+0x11/0x50 other info that might help us debug this: no locks held by nscd/4929. stack backtrace: Call Trace: [<ffffffff8020ab9f>] show_trace+0x9f/0x240 [<ffffffff8020af75>] dump_stack+0x15/0x20 [<ffffffff80249e52>] print_usage_bug+0x272/0x290 [<ffffffff8024a0d7>] mark_lock+0x267/0x5f0 [<ffffffff8024a9a6>] __lock_acquire+0x546/0xd10 [<ffffffff8024b4fb>] lock_acquire+0x8b/0xc0 [<ffffffff804764f4>] _spin_lock_bh+0x34/0x50 [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0 [<ffffffff80457359>] inet_ioctl+0x69/0x70 [<ffffffff804033ac>] sock_ioctl+0x22c/0x270 [<ffffffff802a32b1>] do_ioctl+0x31/0xa0 [<ffffffff802a35db>] vfs_ioctl+0x2bb/0x2e0 [<ffffffff802a366a>] sys_ioctl+0x6a/0xa0 [<ffffffff8020985a>] system_call+0x7e/0x83 [<00002b2d76ab98a9>] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki @ 2006-07-04 20:01 ` Arjan van de Ven 2006-07-05 10:27 ` 2.6.17-mm6 Stefan Richter 0 siblings, 1 reply; 111+ messages in thread From: Arjan van de Ven @ 2006-07-04 20:01 UTC (permalink / raw) To: netdev, Rafael J. Wysocki; +Cc: Andrew Morton, linux-kernel this is one for the networking people, and thus netdev On Tue, 2006-07-04 at 21:53 +0200, Rafael J. Wysocki wrote: > On Monday 03 July 2006 12:03, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > - A major update to the e1000 driver. > > > > - 1394 updates > > Just found this in dmesg: > > ================================= > [ INFO: inconsistent lock state ] > --------------------------------- > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes: > (&skb_queue_lock_key){++..}, at: [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0 > {in-hardirq-W} state was registered at: > [<ffffffff8024b4fa>] lock_acquire+0x8a/0xc0 > [<ffffffff80476e3f>] _spin_lock_irqsave+0x3f/0x60 > [<ffffffff80408c25>] skb_queue_tail+0x25/0x60 ok so skb_queue_lock is used in a hardirq context > [<ffffffff881c9517>] queue_packet_complete+0x27/0x40 [ieee1394] > [<ffffffff881c9d6b>] hpsb_packet_sent+0xab/0x100 [ieee1394] > [<ffffffff8822a4b5>] dma_trm_reset+0x115/0x140 [ohci1394] > [<ffffffff8822c512>] ohci_devctl+0x1c2/0x540 [ohci1394] > [<ffffffff881c9673>] hpsb_bus_reset+0x43/0xb0 [ieee1394] > [<ffffffff8822d7f6>] ohci_irq_handler+0x416/0x830 [ohci1394] > [<ffffffff802631ab>] handle_IRQ_event+0x2b/0x70 > [<ffffffff80264dd4>] handle_level_irq+0xc4/0x130 > [<ffffffff8020c762>] do_IRQ+0x112/0x130 > [<ffffffff80209d90>] common_interrupt+0x64/0x65 > irq event stamp: 4280 > hardirqs last enabled at (4279): [<ffffffff8047606a>] trace_hardirqs_on_thunk+0x35/0x37 > hardirqs last disabled at (4278): [<ffffffff804760a1>] trace_hardirqs_off_thunk+0x35/0x67 > softirqs last enabled at (4258): [<ffffffff804065b5>] release_sock+0xd5/0xe0 > softirqs last disabled at (4280): [<ffffffff804764d1>] _spin_lock_bh+0x11/0x50 > > other info that might help us debug this: > no locks held by nscd/4929. > > stack backtrace: > > Call Trace: > [<ffffffff8020ab9f>] show_trace+0x9f/0x240 > [<ffffffff8020af75>] dump_stack+0x15/0x20 > [<ffffffff80249e52>] print_usage_bug+0x272/0x290 > [<ffffffff8024a0d7>] mark_lock+0x267/0x5f0 > [<ffffffff8024a9a6>] __lock_acquire+0x546/0xd10 > [<ffffffff8024b4fb>] lock_acquire+0x8b/0xc0 > [<ffffffff804764f4>] _spin_lock_bh+0x34/0x50 > [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0 yet udp_ioctl takes it only for _bh > [<ffffffff80457359>] inet_ioctl+0x69/0x70 > [<ffffffff804033ac>] sock_ioctl+0x22c/0x270 > [<ffffffff802a32b1>] do_ioctl+0x31/0xa0 > [<ffffffff802a35db>] vfs_ioctl+0x2bb/0x2e0 > [<ffffffff802a366a>] sys_ioctl+0x6a/0xa0 > [<ffffffff8020985a>] system_call+0x7e/0x83 > [<00002b2d76ab98a9>] is this a real scenario, or is this a case of "firewire is special and needs it's own rules"? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-04 20:01 ` 2.6.17-mm6 Arjan van de Ven @ 2006-07-05 10:27 ` Stefan Richter 2006-07-05 10:36 ` 2.6.17-mm6 Stefan Richter 0 siblings, 1 reply; 111+ messages in thread From: Stefan Richter @ 2006-07-05 10:27 UTC (permalink / raw) To: Arjan van de Ven Cc: netdev, Rafael J. Wysocki, Andrew Morton, linux-kernel, Ingo Molnar On 7/4/2006 10:01 PM, Arjan van de Ven wrote: > this is one for the networking people, and thus netdev It's actually ieee1394 using net infrastructure for purposes which ar unrelated to networking. Furthermore... > On Tue, 2006-07-04 at 21:53 +0200, Rafael J. Wysocki wrote: >> On Monday 03 July 2006 12:03, Andrew Morton wrote: >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ >> > >> > - A major update to the e1000 driver. >> > - 1394 updates ...I believe it is unrelated to the 1394 updates new to -mm6. >> Just found this in dmesg: >> >> ================================= >> [ INFO: inconsistent lock state ] >> --------------------------------- >> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. >> nscd/4929 [HC0[0]:SC0[1]:HE1:SE0] takes: >> (&skb_queue_lock_key){++..}, at: [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0 >> {in-hardirq-W} state was registered at: >> [<ffffffff8024b4fa>] lock_acquire+0x8a/0xc0 >> [<ffffffff80476e3f>] _spin_lock_irqsave+0x3f/0x60 >> [<ffffffff80408c25>] skb_queue_tail+0x25/0x60 > > ok so skb_queue_lock is used in a hardirq context > >> [<ffffffff881c9517>] queue_packet_complete+0x27/0x40 [ieee1394] >> [<ffffffff881c9d6b>] hpsb_packet_sent+0xab/0x100 [ieee1394] >> [<ffffffff8822a4b5>] dma_trm_reset+0x115/0x140 [ohci1394] >> [<ffffffff8822c512>] ohci_devctl+0x1c2/0x540 [ohci1394] >> [<ffffffff881c9673>] hpsb_bus_reset+0x43/0xb0 [ieee1394] >> [<ffffffff8822d7f6>] ohci_irq_handler+0x416/0x830 [ohci1394] >> [<ffffffff802631ab>] handle_IRQ_event+0x2b/0x70 >> [<ffffffff80264dd4>] handle_level_irq+0xc4/0x130 >> [<ffffffff8020c762>] do_IRQ+0x112/0x130 >> [<ffffffff80209d90>] common_interrupt+0x64/0x65 >> irq event stamp: 4280 >> hardirqs last enabled at (4279): [<ffffffff8047606a>] trace_hardirqs_on_thunk+0x35/0x37 >> hardirqs last disabled at (4278): [<ffffffff804760a1>] trace_hardirqs_off_thunk+0x35/0x67 >> softirqs last enabled at (4258): [<ffffffff804065b5>] release_sock+0xd5/0xe0 >> softirqs last disabled at (4280): [<ffffffff804764d1>] _spin_lock_bh+0x11/0x50 >> >> other info that might help us debug this: >> no locks held by nscd/4929. >> >> stack backtrace: >> >> Call Trace: >> [<ffffffff8020ab9f>] show_trace+0x9f/0x240 >> [<ffffffff8020af75>] dump_stack+0x15/0x20 >> [<ffffffff80249e52>] print_usage_bug+0x272/0x290 >> [<ffffffff8024a0d7>] mark_lock+0x267/0x5f0 >> [<ffffffff8024a9a6>] __lock_acquire+0x546/0xd10 >> [<ffffffff8024b4fb>] lock_acquire+0x8b/0xc0 >> [<ffffffff804764f4>] _spin_lock_bh+0x34/0x50 >> [<ffffffff8044fe40>] udp_ioctl+0x50/0xa0 > > yet udp_ioctl takes it only for _bh > >> [<ffffffff80457359>] inet_ioctl+0x69/0x70 >> [<ffffffff804033ac>] sock_ioctl+0x22c/0x270 >> [<ffffffff802a32b1>] do_ioctl+0x31/0xa0 >> [<ffffffff802a35db>] vfs_ioctl+0x2bb/0x2e0 >> [<ffffffff802a366a>] sys_ioctl+0x6a/0xa0 >> [<ffffffff8020985a>] system_call+0x7e/0x83 >> [<00002b2d76ab98a9>] > > is this a real scenario, or is this a case of "firewire is special and > needs it's own rules"? Well, firewire is special, but that should already be addressed by this patch: "lockdep: annotate ieee1394 skb-queue-head locking" http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=d378834840907326ac9d448056d957d13cc3718f Why is there still a lockdep warning? (Ieee1394 core's usage of the skb_* API is entirely unrelated to networking; even if eth1394 was used.) -- Stefan Richter -=====-=-==- -=== --=-= http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 10:27 ` 2.6.17-mm6 Stefan Richter @ 2006-07-05 10:36 ` Stefan Richter 2006-07-05 11:13 ` 2.6.17-mm6 Ingo Molnar 0 siblings, 1 reply; 111+ messages in thread From: Stefan Richter @ 2006-07-05 10:36 UTC (permalink / raw) To: Arjan van de Ven Cc: netdev, Rafael J. Wysocki, Andrew Morton, linux-kernel, Ingo Molnar I wrote: > (Ieee1394 core's usage of the skb_* API is entirely unrelated to > networking; even if eth1394 was used.) PS: I wonder if it wouldn't be better to migrate ieee1394 core away from skb_*. I didn't look thoroughly at it yet but the benefit of using this API appears quite low to me. We use it to keep track of IEEE 1394 transactions [ = outgoing request && (incoming response || expiry)], with completion of transactions often in-order due to mostly single-threaded usage, but sometimes out-of-order (may happen regardless of multithreaded or single-threaded usage). -- Stefan Richter -=====-=-==- -=== --=-= http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 10:36 ` 2.6.17-mm6 Stefan Richter @ 2006-07-05 11:13 ` Ingo Molnar 0 siblings, 0 replies; 111+ messages in thread From: Ingo Molnar @ 2006-07-05 11:13 UTC (permalink / raw) To: Stefan Richter Cc: Arjan van de Ven, netdev, Rafael J. Wysocki, Andrew Morton, linux-kernel * Stefan Richter <stefanr@s5r6.in-berlin.de> wrote: > I wrote: > > (Ieee1394 core's usage of the skb_* API is entirely unrelated to > > networking; even if eth1394 was used.) > > PS: > I wonder if it wouldn't be better to migrate ieee1394 core away from > skb_*. I didn't look thoroughly at it yet but the benefit of using > this API appears quite low to me. yeah, it seems to be the wrong abstraction to use. It's also more expensive than necessary: e.g. skb-heads have a qlen field that is maintained in every list op - but the ieee1394 code does not make use of the queue-length information. Using list.h plus a spinlock should do the trick? Ingo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (6 preceding siblings ...) 2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki @ 2006-07-05 21:43 ` J.A. Magallón 2006-07-05 22:56 ` 2.6.17-mm6 Andrew Morton [not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com> ` (2 subsequent siblings) 10 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-05 21:43 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Mon, 3 Jul 2006 03:03:55 -0700, Andrew Morton <akpm@osdl.org> wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > - A major update to the e1000 driver. > Doesn't find my root drive :(. Its a SATA drive, on PIIX. Last -mm I tried ('cause of the raid problems) was -mm1, so I don't know when did this broke. Under -mm1, the disk is this: libata version 1.30 loaded. ata_piix 0000:00:1f.2: version 1.10tj1ac3 ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 scsi0 : ata_piix ata1: ENTER, pcs=0x13 base=0 ata1: LEAVE, pcs=0x13 present_mask=0x1 ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 ata1.00: configured for UDMA/133 scsi1 : ata_piix ata2: ENTER, pcs=0x13 base=2 ata2: LEAVE, pcs=0x11 present_mask=0x0 ata2: SATA port has no device. Vendor: ATA Model: ST3200822AS Rev: 3.01 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda With -mm6, the kernel doesn't find it. I get this on boot: kinit: try_name sda,1 = dev(8,1) kinit: name_to_dev_t(/dev/sda1) = dev(8.1) kinit: root_dev = dev(8,1) kinit: failed to identify filesystem /dev/root, trying all kinit: trying to mount /dev/root on /root with type ext3 kinit: Cannot open root device dev(8,1) I have tried to get this message from -mm1, but could not get it in any log. But... I remember to see that the boot message is like: kinit: try_name sda,1 = sda1(8,1) ^^^^ I have verified I built -mm6 with ext3,sata-piix and so on, all builtin. Any ideas ? TIA -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 21:43 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-05 22:56 ` Andrew Morton 2006-07-05 23:57 ` 2.6.17-mm6 J.A. Magallón 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-05 22:56 UTC (permalink / raw) To: J.A. Magallón ; +Cc: linux-kernel "J.A. Magallón" <jamagallon@ono.com> wrote: > > On Mon, 3 Jul 2006 03:03:55 -0700, Andrew Morton <akpm@osdl.org> wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > - A major update to the e1000 driver. > > > > Doesn't find my root drive :(. > > Its a SATA drive, on PIIX. > Last -mm I tried ('cause of the raid problems) was -mm1, so I don't know > when did this broke. Under -mm1, the disk is this: > > libata version 1.30 loaded. > ata_piix 0000:00:1f.2: version 1.10tj1ac3 > ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] > ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 > PCI: Setting latency timer of device 0000:00:1f.2 to 64 > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > scsi0 : ata_piix > ata1: ENTER, pcs=0x13 base=0 > ata1: LEAVE, pcs=0x13 present_mask=0x1 > ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f > ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 > ata1.00: configured for UDMA/133 > scsi1 : ata_piix > ata2: ENTER, pcs=0x13 base=2 > ata2: LEAVE, pcs=0x11 present_mask=0x0 > ata2: SATA port has no device. > Vendor: ATA Model: ST3200822AS Rev: 3.01 > Type: Direct-Access ANSI SCSI revision: 05 > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: drive cache: write back > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: drive cache: write back > sda: sda1 sda2 sda3 > sd 0:0:0:0: Attached scsi disk sda > > With -mm6, the kernel doesn't find it. I get this on boot: > > kinit: try_name sda,1 = dev(8,1) > kinit: name_to_dev_t(/dev/sda1) = dev(8.1) > kinit: root_dev = dev(8,1) > kinit: failed to identify filesystem /dev/root, trying all > kinit: trying to mount /dev/root on /root with type ext3 > kinit: Cannot open root device dev(8,1) > > I have tried to get this message from -mm1, but could not get it in any log. > But... I remember to see that the boot message is like: > > kinit: try_name sda,1 = sda1(8,1) > ^^^^ > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin. > Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch? Also, the full dmesg from 2.6.17-mm6 would help, thanks. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 22:56 ` 2.6.17-mm6 Andrew Morton @ 2006-07-05 23:57 ` J.A. Magallón 2006-07-06 0:02 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-05 23:57 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Wed, 5 Jul 2006 15:56:02 -0700, Andrew Morton <akpm@osdl.org> wrote: > "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > On Mon, 3 Jul 2006 03:03:55 -0700, Andrew Morton <akpm@osdl.org> wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > > > > - A major update to the e1000 driver. > > > > > > > Doesn't find my root drive :(. > > > > Its a SATA drive, on PIIX. > > Last -mm I tried ('cause of the raid problems) was -mm1, so I don't know > > when did this broke. Under -mm1, the disk is this: > > > > libata version 1.30 loaded. > > ata_piix 0000:00:1f.2: version 1.10tj1ac3 > > ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] > > ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 > > PCI: Setting latency timer of device 0000:00:1f.2 to 64 > > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > > scsi0 : ata_piix > > ata1: ENTER, pcs=0x13 base=0 > > ata1: LEAVE, pcs=0x13 present_mask=0x1 > > ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f > > ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 > > ata1.00: configured for UDMA/133 > > scsi1 : ata_piix > > ata2: ENTER, pcs=0x13 base=2 > > ata2: LEAVE, pcs=0x11 present_mask=0x0 > > ata2: SATA port has no device. > > Vendor: ATA Model: ST3200822AS Rev: 3.01 > > Type: Direct-Access ANSI SCSI revision: 05 > > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) > > sda: Write Protect is off > > sda: Mode Sense: 00 3a 00 00 > > SCSI device sda: drive cache: write back > > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) > > sda: Write Protect is off > > sda: Mode Sense: 00 3a 00 00 > > SCSI device sda: drive cache: write back > > sda: sda1 sda2 sda3 > > sd 0:0:0:0: Attached scsi disk sda > > > > With -mm6, the kernel doesn't find it. I get this on boot: > > > > kinit: try_name sda,1 = dev(8,1) > > kinit: name_to_dev_t(/dev/sda1) = dev(8.1) > > kinit: root_dev = dev(8,1) > > kinit: failed to identify filesystem /dev/root, trying all > > kinit: trying to mount /dev/root on /root with type ext3 > > kinit: Cannot open root device dev(8,1) > > > > I have tried to get this message from -mm1, but could not get it in any log. > > But... I remember to see that the boot message is like: > > > > kinit: try_name sda,1 = sda1(8,1) > > ^^^^ > > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin. > > > > Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch? > > Also, the full dmesg from 2.6.17-mm6 would help, thanks. > It does not reach a point to save the dmesg.... I can pick my digital camera. Is there a netconsole version for OSX (to attach my ibook and dump dmesg...) ? -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 23:57 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-06 0:02 ` Andrew Morton 2006-07-06 14:36 ` 2.6.17-mm6 J.A. Magallón 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-06 0:02 UTC (permalink / raw) To: "J.A. =?ISO-8859-1?B?TWFnYWxs824i?= <jamagallon; +Cc: linux-kernel On Thu, 6 Jul 2006 01:57:06 +0200 "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > > > > With -mm6, the kernel doesn't find it. I get this on boot: > > > > > > kinit: try_name sda,1 = dev(8,1) > > > kinit: name_to_dev_t(/dev/sda1) = dev(8.1) > > > kinit: root_dev = dev(8,1) > > > kinit: failed to identify filesystem /dev/root, trying all > > > kinit: trying to mount /dev/root on /root with type ext3 > > > kinit: Cannot open root device dev(8,1) > > > > > > I have tried to get this message from -mm1, but could not get it in any log. > > > But... I remember to see that the boot message is like: > > > > > > kinit: try_name sda,1 = sda1(8,1) > > > ^^^^ > > > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin. > > > > > > > Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch? > > > > Also, the full dmesg from 2.6.17-mm6 would help, thanks. > > > > It does not reach a point to save the dmesg.... > I can pick my digital camera. Full dmesg would be better for this one, please. > Is there a netconsole version for OSX (to attach my ibook and dump dmesg...) ? All you need is netcat. google(netcat os-x) looks promising. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 0:02 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 14:36 ` J.A. Magallón 2006-07-06 14:48 ` 2.6.17-mm6 J.A. Magallón 0 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-06 14:36 UTC (permalink / raw) To: linux-kernel On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote: > On Thu, 6 Jul 2006 01:57:06 +0200 > "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > > > > > > > With -mm6, the kernel doesn't find it. I get this on boot: > > > > > > > > kinit: try_name sda,1 = dev(8,1) > > > > kinit: name_to_dev_t(/dev/sda1) = dev(8.1) > > > > kinit: root_dev = dev(8,1) > > > > kinit: failed to identify filesystem /dev/root, trying all > > > > kinit: trying to mount /dev/root on /root with type ext3 > > > > kinit: Cannot open root device dev(8,1) > > > > > > > > I have tried to get this message from -mm1, but could not get it in any log. > > > > But... I remember to see that the boot message is like: > > > > > > > > kinit: try_name sda,1 = sda1(8,1) > > > > ^^^^ > > > > I have verified I built -mm6 with ext3,sata-piix and so on, all builtin. > > > > > > > > > > Are you able to test just 2.6.17 + origin.patch + git-libata-all.patch? > > > > > > Also, the full dmesg from 2.6.17-mm6 would help, thanks. > > > > > > > It does not reach a point to save the dmesg.... > > I can pick my digital camera. > > Full dmesg would be better for this one, please. > This a shot till I can try to get a full dmesg. http://belly.cps.unizar.es/~magallon/tmp/shot.jpg Anyways, what I wanted to point above was that previous kernels talk about 'sda1(8,1)', and newer use 'dev(8,19)'. Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ? -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 14:36 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-06 14:48 ` J.A. Magallón 2006-07-06 21:44 ` 2.6.17-mm6 J.A. Magallón 0 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-06 14:48 UTC (permalink / raw) To: linux-kernel On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote: > > > This a shot till I can try to get a full dmesg. > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg > > Anyways, what I wanted to point above was that previous kernels talk > about 'sda1(8,1)', and newer use 'dev(8,19)'. > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ? > Hey !!. I disabled md and usb to get more useful messages in my screen, and now I have realized that libata is managing my IDE drive !! And I did not boot with any 'libata.atapi_enable'.... In -mm1, sda -> 200Gb sata hda -> HL-DT-ST DVDRAM GSA-4120B hdb -> (zip drive) hdc -> 120Gb ide hdd -> DVD-ROM In -mm6, sda -> (zip drive) ? sdb -> 120Gb sdc -> 200Gb -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 14:48 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-06 21:44 ` J.A. Magallón 2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-06 21:44 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote: > > > > > > This a shot till I can try to get a full dmesg. > > > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg > > > > Anyways, what I wanted to point above was that previous kernels talk > > about 'sda1(8,1)', and newer use 'dev(8,19)'. > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ? > > > > Hey !!. I disabled md and usb to get more useful messages in my screen, and > now I have realized that libata is managing my IDE drive !! And I did not > boot with any 'libata.atapi_enable'.... > > In -mm1, > sda -> 200Gb sata > hda -> HL-DT-ST DVDRAM GSA-4120B > hdb -> (zip drive) > hdc -> 120Gb ide > hdd -> DVD-ROM > > In -mm6, > > sda -> (zip drive) ? > sdb -> 120Gb > sdc -> 200Gb > Well, booting onto sdc1 let me get to single user mode at least so I got a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it full I can provide). Basically it looks like libata 2.0 by default handles PATA drives. This can break a lot of systems. In my opinion, PATA hosts should be detected _after_ real sata hosts in the same chipset (now it looks like its done _before_). What is handled by IDE will break anyways, but this way at least real SATA will stay at the same /dev/sdX devices. -mm1: ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 ICH5: IDE controller at PCI slot 0000:00:1f.1 ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio -mm6: ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 dmesg-mm1: libata version 1.30 loaded. ata_piix 0000:00:1f.2: version 1.10tj1ac3 ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 scsi0 : ata_piix ata1: ENTER, pcs=0x13 base=0 ata1: LEAVE, pcs=0x13 present_mask=0x1 ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 ata1.00: configured for UDMA/133 scsi1 : ata_piix ata2: ENTER, pcs=0x13 base=2 ata2: LEAVE, pcs=0x11 present_mask=0x0 ata2: SATA port has no device. Vendor: ATA Model: ST3200822AS Rev: 3.01 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sd 0:0:0:0: Attached scsi disk sda ... Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH5: IDE controller at PCI slot 0000:00:1f.1 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16 ICH5: chipset revision 2 ICH5: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: HL-DT-ST DVDRAM GSA-4120B, ATAPI CD/DVD-ROM drive hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... ide-floppy driver 0.99.newide hdb: No disk in drive hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm hdb: No disk in drive hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 hdc: ST3120022A, ATA DISK drive hdd: TOSHIBA DVD-ROM SD-M1712, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hdd: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33) hdc: max request size: 512KiB hdc: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100) hdc: cache flushes supported hdc: hdc1 EXT3 FS on sda1, internal journal Adding 2112536k swap on /dev/sda3. Priority:-1 extents:1 across:2112536k kjournald starting. Commit interval 5 seconds EXT3 FS on sda2, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on hdc1, internal journal EXT3-fs: mounted filesystem with ordered data mode. dmesg-mm6: libata version 2.00 loaded. ata_piix 0000:00:1f.1: version 2.00tj1ac5 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.1 to 64 ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 scsi0 : ata_piix ata1.00: configured for PIO3 ata1.01: configured for PIO3 Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111 Type: CD-ROM ANSI SCSI revision: 05 Vendor: IOMEGA Model: ZIP 250 Rev: 51.G Type: Direct-Access ANSI SCSI revision: 05 ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi1 : ata_piix ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 Vendor: ATA Model: ST3120022A Rev: 3.06 Type: Direct-Access ANSI SCSI revision: 05 Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004 Type: CD-ROM ANSI SCSI revision: 05 ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 scsi2 : ata_piix ata3: ENTER, pcs=0x13 base=0 ata3: LEAVE, pcs=0x13 present_mask=0x1 ata3.00: configured for UDMA/133 scsi3 : ata_piix ata4: ENTER, pcs=0x13 base=2 ata4: LEAVE, pcs=0x11 present_mask=0x0 ata4: SATA port has no device. ATA: abnormal status 0x7F on port 0xC807 Vendor: ATA Model: ST3200822AS Rev: 3.01 Type: Direct-Access ANSI SCSI revision: 05 sd 0:0:1:0: Attached scsi removable disk sda SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back sdb: sdb1 sd 1:0:0:0: Attached scsi disk sdb SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sd 2:0:0:0: Attached scsi disk sdc ... sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 0:0:0:0: Attached scsi CD-ROM sr0 sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray sr 1:0:1:0: Attached scsi CD-ROM sr1 ... Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide-floppy driver 0.99.newide EXT3 FS on sdc1, internal journal -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 21:44 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-06 21:57 ` Andrew Morton 2006-07-07 15:38 ` 2.6.17-mm6 J.A. Magallón 2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox 0 siblings, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-06 21:57 UTC (permalink / raw) To: J.A. Magallón ; +Cc: linux-kernel, Alan Cox "J.A. Magallón" <jamagallon@ono.com> wrote: > > On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > > > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote: > > > > > > > > > This a shot till I can try to get a full dmesg. > > > > > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg > > > > > > Anyways, what I wanted to point above was that previous kernels talk > > > about 'sda1(8,1)', and newer use 'dev(8,19)'. > > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ? > > > > > > > Hey !!. I disabled md and usb to get more useful messages in my screen, and > > now I have realized that libata is managing my IDE drive !! And I did not > > boot with any 'libata.atapi_enable'.... > > > > In -mm1, > > sda -> 200Gb sata > > hda -> HL-DT-ST DVDRAM GSA-4120B > > hdb -> (zip drive) > > hdc -> 120Gb ide > > hdd -> DVD-ROM > > > > In -mm6, > > > > sda -> (zip drive) ? > > sdb -> 120Gb > > sdc -> 200Gb > > > > Well, booting onto sdc1 let me get to single user mode at least so I got > a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it > full I can provide). Basically it looks like libata 2.0 by default handles > PATA drives. This can break a lot of systems. In my opinion, PATA hosts > should be detected _after_ real sata hosts in the same chipset (now it > looks like its done _before_). What is handled by IDE will break anyways, > but this way at least real SATA will stay at the same /dev/sdX devices. > > -mm1: > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > ICH5: IDE controller at PCI slot 0000:00:1f.1 > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio > > -mm6: > > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer. Alan's the man. > dmesg-mm1: > > libata version 1.30 loaded. > ata_piix 0000:00:1f.2: version 1.10tj1ac3 > ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] > ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 > PCI: Setting latency timer of device 0000:00:1f.2 to 64 > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > scsi0 : ata_piix > ata1: ENTER, pcs=0x13 base=0 > ata1: LEAVE, pcs=0x13 present_mask=0x1 > ata1.00: cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:407f > ata1.00: ATA-6, max UDMA/133, 390721968 sectors: LBA48 > ata1.00: configured for UDMA/133 > scsi1 : ata_piix > ata2: ENTER, pcs=0x13 base=2 > ata2: LEAVE, pcs=0x11 present_mask=0x0 > ata2: SATA port has no device. > Vendor: ATA Model: ST3200822AS Rev: 3.01 > Type: Direct-Access ANSI SCSI revision: 05 > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: drive cache: write back > SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) > sda: Write Protect is off > sda: Mode Sense: 00 3a 00 00 > SCSI device sda: drive cache: write back > sda: sda1 sda2 sda3 > sd 0:0:0:0: Attached scsi disk sda > ... > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ICH5: IDE controller at PCI slot 0000:00:1f.1 > ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16 > ICH5: chipset revision 2 > ICH5: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio > Probing IDE interface ide0... > hda: HL-DT-ST DVDRAM GSA-4120B, ATAPI CD/DVD-ROM drive > hdb: IOMEGA ZIP 250 ATAPI, ATAPI FLOPPY drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > ide-floppy driver 0.99.newide > hdb: No disk in drive > hdb: 244736kB, 239/64/32 CHS, 4096 kBps, 512 sector size, 2941 rpm > hdb: No disk in drive > hda: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) > Uniform CD-ROM driver Revision: 3.20 > hdc: ST3120022A, ATA DISK drive > hdd: TOSHIBA DVD-ROM SD-M1712, ATAPI CD/DVD-ROM drive > ide1 at 0x170-0x177,0x376 on irq 15 > hdd: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33) > hdc: max request size: 512KiB > hdc: 234441648 sectors (120034 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100) > hdc: cache flushes supported > hdc: hdc1 > EXT3 FS on sda1, internal journal > Adding 2112536k swap on /dev/sda3. Priority:-1 extents:1 across:2112536k > kjournald starting. Commit interval 5 seconds > EXT3 FS on sda2, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > kjournald starting. Commit interval 5 seconds > EXT3-fs warning: maximal mount count reached, running e2fsck is recommended > EXT3 FS on hdc1, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > > dmesg-mm6: > > libata version 2.00 loaded. > ata_piix 0000:00:1f.1: version 2.00tj1ac5 > ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16 > PCI: Setting latency timer of device 0000:00:1f.1 to 64 > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 > scsi0 : ata_piix > ata1.00: configured for PIO3 > ata1.01: configured for PIO3 > Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A111 > Type: CD-ROM ANSI SCSI revision: 05 > Vendor: IOMEGA Model: ZIP 250 Rev: 51.G > Type: Direct-Access ANSI SCSI revision: 05 > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 > scsi1 : ata_piix > ata2.00: configured for UDMA/33 > ata2.01: configured for UDMA/33 > Vendor: ATA Model: ST3120022A Rev: 3.06 > Type: Direct-Access ANSI SCSI revision: 05 > Vendor: TOSHIBA Model: DVD-ROM SD-M1712 Rev: 1004 > Type: CD-ROM ANSI SCSI revision: 05 > ata_piix 0000:00:1f.2: MAP [ P0 -- P1 -- ] > ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 > PCI: Setting latency timer of device 0000:00:1f.2 to 64 > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > scsi2 : ata_piix > ata3: ENTER, pcs=0x13 base=0 > ata3: LEAVE, pcs=0x13 present_mask=0x1 > ata3.00: configured for UDMA/133 > scsi3 : ata_piix > ata4: ENTER, pcs=0x13 base=2 > ata4: LEAVE, pcs=0x11 present_mask=0x0 > ata4: SATA port has no device. > ATA: abnormal status 0x7F on port 0xC807 > Vendor: ATA Model: ST3200822AS Rev: 3.01 > Type: Direct-Access ANSI SCSI revision: 05 > sd 0:0:1:0: Attached scsi removable disk sda > SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) > sdb: Write Protect is off > sdb: Mode Sense: 00 3a 00 00 > SCSI device sdb: drive cache: write back > SCSI device sdb: 234441648 512-byte hdwr sectors (120034 MB) > sdb: Write Protect is off > sdb: Mode Sense: 00 3a 00 00 > SCSI device sdb: drive cache: write back > sdb: sdb1 > sd 1:0:0:0: Attached scsi disk sdb > SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB) > sdc: Write Protect is off > sdc: Mode Sense: 00 3a 00 00 > SCSI device sdc: drive cache: write back > SCSI device sdc: 390721968 512-byte hdwr sectors (200050 MB) > sdc: Write Protect is off > sdc: Mode Sense: 00 3a 00 00 > SCSI device sdc: drive cache: write back > sdc: sdc1 sdc2 sdc3 > sd 2:0:0:0: Attached scsi disk sdc > ... > sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray > Uniform CD-ROM driver Revision: 3.20 > sr 0:0:0:0: Attached scsi CD-ROM sr0 > sr1: scsi3-mmc drive: 48x/48x cd/rw xa/form2 cdda tray > sr 1:0:1:0: Attached scsi CD-ROM sr1 > ... > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ide-floppy driver 0.99.newide > EXT3 FS on sdc1, internal journal > > -- > J.A. Magallon <jamagallon()ono!com> \ Software is like sex: > \ It's better when it's free > Mandriva Linux release 2007.0 (Cooker) for i586 > Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton @ 2006-07-07 15:38 ` J.A. Magallón 2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox 1 sibling, 0 replies; 111+ messages in thread From: J.A. Magallón @ 2006-07-07 15:38 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Alan Cox On Thu, 6 Jul 2006 14:57:52 -0700, Andrew Morton <akpm@osdl.org> wrote: > "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > On Thu, 6 Jul 2006 16:48:02 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > > On Thu, 6 Jul 2006 16:36:46 +0200, "J.A. Magallón" <jamagallon@ono.com> wrote: > > > > > > > On Wed, 5 Jul 2006 17:02:28 -0700, Andrew Morton <akpm@osdl.org> wrote: > > > > > > > > > > > > This a shot till I can try to get a full dmesg. > > > > > > > > http://belly.cps.unizar.es/~magallon/tmp/shot.jpg > > > > > > > > Anyways, what I wanted to point above was that previous kernels talk > > > > about 'sda1(8,1)', and newer use 'dev(8,19)'. > > > > Perhaps somebedy did a strcpy( ... , "dev" ), instead of strcpy( ... , dev ) ? > > > > > > > > > > Hey !!. I disabled md and usb to get more useful messages in my screen, and > > > now I have realized that libata is managing my IDE drive !! And I did not > > > boot with any 'libata.atapi_enable'.... > > > > > > In -mm1, > > > sda -> 200Gb sata > > > hda -> HL-DT-ST DVDRAM GSA-4120B > > > hdb -> (zip drive) > > > hdc -> 120Gb ide > > > hdd -> DVD-ROM > > > > > > In -mm6, > > > > > > sda -> (zip drive) ? > > > sdb -> 120Gb > > > sdc -> 200Gb > > > > > > > Well, booting onto sdc1 let me get to single user mode at least so I got > > a full dmesg. Relevant parts for -mm1 and -mm6 are below (if you want it > > full I can provide). Basically it looks like libata 2.0 by default handles > > PATA drives. This can break a lot of systems. In my opinion, PATA hosts > > should be detected _after_ real sata hosts in the same chipset (now it > > looks like its done _before_). What is handled by IDE will break anyways, > > but this way at least real SATA will stay at the same /dev/sdX devices. > > > > -mm1: > > ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > > ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > > ICH5: IDE controller at PCI slot 0000:00:1f.1 > > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio > > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio > > > > -mm6: > > > > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 > > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 > > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > > > > Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer. > Alan's the man. > I thought libata.atapi_enabled=0 could make things like before, but: libata version 2.00 loaded. ata_piix 0000:00:1f.1: version 2.00tj1ac5 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.1 to 64 ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 scsi0 : ata_piix ata1.00: configured for PIO3 ata1.01: configured for PIO3 ata1.00: WARNING: ATAPI is disabled, device ignored. ata1.01: WARNING: ATAPI is disabled, device ignored. ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi1 : ata_piix ata2.00: configured for UDMA/33 ata2.01: configured for UDMA/33 Vendor: ATA Model: ST3120022A Rev: 3.06 Type: Direct-Access ANSI SCSI revision: 05 ata2.01: WARNING: ATAPI is disabled, device ignored. ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 scsi2 : ata_piix ata3: ENTER, pcs=0x13 base=0 ata3: LEAVE, pcs=0x13 present_mask=0x1 ata3.00: configured for UDMA/133 scsi3 : ata_piix ata4: ENTER, pcs=0x13 base=2 ata4: LEAVE, pcs=0x11 present_mask=0x0 ata4: SATA port has no device. ATA: abnormal status 0x7F on port 0xC807 Vendor: ATA Model: ST3200822AS Rev: 3.01 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 234441648 512-byte hdwr sectors (120034 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sd 1:0:0:0: Attached scsi disk sda SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB) Buses are still there, disks named, but ignored. So old hda becomes sda, and old sda becomes sdb. -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton 2006-07-07 15:38 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-07 16:02 ` Alan Cox 2006-07-07 15:55 ` 2.6.17-mm6 J.A. Magallón 1 sibling, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 16:02 UTC (permalink / raw) To: Andrew Morton; +Cc: J.A. Magallón , linux-kernel Ar Iau, 2006-07-06 am 14:57 -0700, ysgrifennodd Andrew Morton: > > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 > > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 > > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > > > > Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer. > Alan's the man. The "mixed" drivers/ide and drivers/scsi setup for the ICH is really ugly (look at the pci/quirks.c code for it to see just *how* ugly). It is still present but the default behaviour at the moment is to assume that you want to use libata for your drives. For most distros I've tried this doesn't seem to break anything. Some older distros don't use labels for root searching so need root= passing the first time to fix it. That bit of code is really Jeff code but I can certainly put a Kconfig line and submit a diff to allow users to pick whether their PIIX/ICH should be handled half and half if Andrew or Jeff think that is wise. Alan ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 15:55 ` J.A. Magallón 2006-07-07 16:44 ` 2.6.17-mm6 Alan Cox 0 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-07 15:55 UTC (permalink / raw) To: Alan Cox; +Cc: Andrew Morton, linux-kernel On Fri, 07 Jul 2006 17:02:48 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > Ar Iau, 2006-07-06 am 14:57 -0700, ysgrifennodd Andrew Morton: > > > ata1: PATA max UDMA/100 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 > > > ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 > > > ata3: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > > > ata4: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > > > > > > > Ah-hah, thanks. I think this is a relatively-FAQ, but I forget the answer. > > Alan's the man. > > The "mixed" drivers/ide and drivers/scsi setup for the ICH is really > ugly (look at the pci/quirks.c code for it to see just *how* ugly). It > is still present but the default behaviour at the moment is to assume > that you want to use libata for your drives. > > For most distros I've tried this doesn't seem to break anything. Some > older distros don't use labels for root searching so need root= passing > the first time to fix it. > > That bit of code is really Jeff code but I can certainly put a Kconfig > line and submit a diff to allow users to pick whether their PIIX/ICH > should be handled half and half if Andrew or Jeff think that is wise. > > Alan > I think it is enough to change the detection order, first real SATA and then PATA, so the only drives that change names are the PATA ones. (it that's easy enough...) Mmm, I have thought on another thing. RAID devices do not store the /dev node of pieces on the superblock, just drive IDs, isn't it ? -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 15:55 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-07 16:44 ` Alan Cox 2006-07-07 16:34 ` 2.6.17-mm6 Randy.Dunlap 0 siblings, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 16:44 UTC (permalink / raw) To: J.A. Magallón; +Cc: Andrew Morton, linux-kernel Ar Gwe, 2006-07-07 am 17:55 +0200, ysgrifennodd J.A. Magallón: > I think it is enough to change the detection order, first real SATA and then > PATA, so the only drives that change names are the PATA ones. > (it that's easy enough...) The order is determined by the PCI layer code, and of course by what order you load the modules. Rigidly defined certainities about driver ordering went out with hotplug. > Mmm, I have thought on another thing. RAID devices do not store the /dev > node of pieces on the superblock, just drive IDs, isn't it ? RAID just works and LVM. I flip Fedora boxes between drivers on a regular basis without a glitch. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 16:44 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 16:34 ` Randy.Dunlap 2006-07-07 17:09 ` 2.6.17-mm6 Alan Cox 0 siblings, 1 reply; 111+ messages in thread From: Randy.Dunlap @ 2006-07-07 16:34 UTC (permalink / raw) To: Alan Cox; +Cc: jamagallon, akpm, linux-kernel On Fri, 07 Jul 2006 17:44:03 +0100 Alan Cox wrote: > Ar Gwe, 2006-07-07 am 17:55 +0200, ysgrifennodd J.A. Magallón: > > I think it is enough to change the detection order, first real SATA and then > > PATA, so the only drives that change names are the PATA ones. > > (it that's easy enough...) > > The order is determined by the PCI layer code, and of course by what > order you load the modules. Rigidly defined certainities about driver > ordering went out with hotplug. For built-in drivers, the link order matters. The the libata PATA drivers are sort of "randomly" mixed in with the SATA drivers. > > Mmm, I have thought on another thing. RAID devices do not store the /dev > > node of pieces on the superblock, just drive IDs, isn't it ? > > RAID just works and LVM. I flip Fedora boxes between drivers on a > regular basis without a glitch. --- ~Randy ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 16:34 ` 2.6.17-mm6 Randy.Dunlap @ 2006-07-07 17:09 ` Alan Cox 2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik 0 siblings, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 17:09 UTC (permalink / raw) To: Randy.Dunlap; +Cc: jamagallon, akpm, linux-kernel Ar Gwe, 2006-07-07 am 09:34 -0700, ysgrifennodd Randy.Dunlap: > For built-in drivers, the link order matters. > The the libata PATA drivers are sort of "randomly" mixed in > with the SATA drivers. Mine are in alphabetical order but some of the early merges shuffled stuff a bit. The only case the link order matters here is with the generic and legacy drivers. No chip specific libata PATA/SATA driver has overlapping PCI identifiers between two drivers except for Jmicron, and that distinguishes precisely by the function number. Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA with a bridge chip, and in some cases like the ATI this is quite common. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 17:09 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 17:14 ` Jeff Garzik 2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd 2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox 0 siblings, 2 replies; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 17:14 UTC (permalink / raw) To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Alan Cox wrote: > Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA > with a bridge chip, and in some cases like the ATI this is quite common. Incorrect; what you describe is the core assumption underlying the "ata_", "pata_", and "sata_" prefixes. If the user can attached PATA and SATA devices to a controller, its prefix is ata_ If the user can only attach PATA devices, its prefix is pata_ If the user can only attach SATA devices, its prefix is sata_ For the purposes of this convention, user-attached bridges such as PATA<->SATA bridges, are ignored. Most older controllers always fall into pata_, most newer into sata_, and an odd few ata_ Its a bug if you don't help maintain these assumptions :) Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik @ 2006-07-07 17:22 ` David Lloyd 2006-07-07 17:23 ` 2.6.17-mm6 Jeff Garzik 2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox 1 sibling, 1 reply; 111+ messages in thread From: David Lloyd @ 2006-07-07 17:22 UTC (permalink / raw) To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, jamagallon, akpm, linux-kernel On Fri, 7 Jul 2006, Jeff Garzik wrote: > Alan Cox wrote: >> Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA >> with a bridge chip, and in some cases like the ATI this is quite common. > > Incorrect; what you describe is the core assumption underlying the "ata_", > "pata_", and "sata_" prefixes. > > If the user can attached PATA and SATA devices to a controller, its prefix is > ata_ So sata_promise will change to ata_promise at some point? - DML ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd @ 2006-07-07 17:23 ` Jeff Garzik 0 siblings, 0 replies; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 17:23 UTC (permalink / raw) To: David Lloyd; +Cc: Alan Cox, Randy.Dunlap, jamagallon, akpm, linux-kernel David Lloyd wrote: > On Fri, 7 Jul 2006, Jeff Garzik wrote: > >> Alan Cox wrote: >>> Also its dangerous to assume "pata_*" is a PATA driver, it may be SATA >>> with a bridge chip, and in some cases like the ATI this is quite >>> common. >> >> Incorrect; what you describe is the core assumption underlying the >> "ata_", "pata_", and "sata_" prefixes. >> >> If the user can attached PATA and SATA devices to a controller, its >> prefix is ata_ > > So sata_promise will change to ata_promise at some point? Yes, if breakage can be minimized. Internal symbols have already changed... Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik 2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd @ 2006-07-07 17:44 ` Alan Cox 2006-07-07 17:39 ` 2.6.17-mm6 Jeff Garzik 1 sibling, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 17:44 UTC (permalink / raw) To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Ar Gwe, 2006-07-07 am 13:14 -0400, ysgrifennodd Jeff Garzik: > Most older controllers always fall into pata_, most newer into sata_, > and an odd few ata_ > > Its a bug if you don't help maintain these assumptions :) It would be very hard to do so. Almost anything can and (alas) did have sata bridges nailed to it early on. Almost every later highpoint, promise and ati chip has been found with SATA bridges attached. I've tried to follow the convention on the basis of "not usually found nailed to a SATA bridge chip". If we want to be strict then most of pata_ is ata_ and the prefix really isn't useful. Easy move to make and submit but is it actually useful to do so ? And what about IDE/SATA convertor boards ? Alan ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 17:39 ` Jeff Garzik 2006-07-07 20:03 ` 2.6.17-mm6 Alan Cox 0 siblings, 1 reply; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 17:39 UTC (permalink / raw) To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Alan Cox wrote: > Ar Gwe, 2006-07-07 am 13:14 -0400, ysgrifennodd Jeff Garzik: >> Most older controllers always fall into pata_, most newer into sata_, >> and an odd few ata_ >> >> Its a bug if you don't help maintain these assumptions :) > > It would be very hard to do so. Almost anything can and (alas) did have > sata bridges nailed to it early on. Almost every later highpoint, > promise and ati chip has been found with SATA bridges attached. > > I've tried to follow the convention on the basis of "not usually found > nailed to a SATA bridge chip". If we want to be strict then most of > pata_ is ata_ and the prefix really isn't useful. If there is a SATA receptable -- for plugging in SATA cables -- hardwired onto the controller, it should not be called pata_ Its about what the _user_ knows, and sees. The user doesn't know about soldered bridge chips. The user knows if he is plugging a PATA or SATA cable into his controller. > And what about IDE/SATA convertor boards ? Covered, in the "for the purposes of" sentence. Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 17:39 ` 2.6.17-mm6 Jeff Garzik @ 2006-07-07 20:03 ` Alan Cox 2006-07-07 19:59 ` 2.6.17-mm6 Jeff Garzik 0 siblings, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 20:03 UTC (permalink / raw) To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Ar Gwe, 2006-07-07 am 13:39 -0400, ysgrifennodd Jeff Garzik: > The user doesn't know about soldered bridge chips. The user knows if he > is plugging a PATA or SATA cable into his controller. In which case the pata_ prefix isnt much use because people soldered bridge chips onto just about everything in the first SATA rush, before they all switched to chips that actually did SATA. Alan ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 20:03 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 19:59 ` Jeff Garzik 2006-07-07 20:23 ` 2.6.17-mm6 Alan Cox 0 siblings, 1 reply; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 19:59 UTC (permalink / raw) To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Alan Cox wrote: > Ar Gwe, 2006-07-07 am 13:39 -0400, ysgrifennodd Jeff Garzik: >> The user doesn't know about soldered bridge chips. The user knows if he >> is plugging a PATA or SATA cable into his controller. > > In which case the pata_ prefix isnt much use because people soldered > bridge chips onto just about everything in the first SATA rush, before > they all switched to chips that actually did SATA. An easy look at pata_*.c seemed to indicate that at least 20 would almost certainly remain pata_*.c, maybe even as many as 30. The circumstances you cite happened, yes, but I think you exaggerate the renaming. Several soldered bridge solutions are already supported by libata. Several do need to be renamed to ata_*.c, though. Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 19:59 ` 2.6.17-mm6 Jeff Garzik @ 2006-07-07 20:23 ` Alan Cox 2006-07-07 20:14 ` 2.6.17-mm6 Jeff Garzik 0 siblings, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 20:23 UTC (permalink / raw) To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Ar Gwe, 2006-07-07 am 15:59 -0400, ysgrifennodd Jeff Garzik: > The circumstances you cite happened, yes, but I think you exaggerate the > renaming. Several soldered bridge solutions are already supported by > libata. > > Several do need to be renamed to ata_*.c, though. If we work on the "commonly found" basis then it would be pata_atiixp pata_hpt37x pata_hpt3x2n pata_pdc2027x All four commonly are found with SATA bridges, ATIIXP especially. On the "almost any obscure case basis" would add pata_ali pata_sis pata_via and depending how far pushed pata_sil680 and one or two others Which do you want renamed ? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 20:23 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 20:14 ` Jeff Garzik 2006-07-07 20:42 ` 2.6.17-mm6 Alan Cox 0 siblings, 1 reply; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 20:14 UTC (permalink / raw) To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Alan Cox wrote: > Ar Gwe, 2006-07-07 am 15:59 -0400, ysgrifennodd Jeff Garzik: >> The circumstances you cite happened, yes, but I think you exaggerate the >> renaming. Several soldered bridge solutions are already supported by >> libata. >> >> Several do need to be renamed to ata_*.c, though. > > If we work on the "commonly found" basis then it would be > > pata_atiixp > pata_hpt37x > pata_hpt3x2n > pata_pdc2027x > > All four commonly are found with SATA bridges, ATIIXP especially. > > On the "almost any obscure case basis" would add > > pata_ali > pata_sis > pata_via > > and depending how far pushed > > pata_sil680 > > and one or two others > > Which do you want renamed ? See, out of 37 pata_*.c files, you still have 25+ with pata_ prefix. Use your judgement, based on the guidelines described: outside of weirdo pre-production cases, are users going to be plugging PATA cables or SATA cables into the hardware in question? I'm a bit surprised to see pata_sis and pata_via: are you certain there is not confusion based on the fact that newer SiS, ULi and VIA controllers provide both SATA and PATA on the same controller? That's a common __known painful__ area of libata. The libata API needs to be fixed such that port_operations can be vastly different. Right now, probe_ent requires some attributes to be common across all ports, when they are not in real life. This leads to improper creation of if (this port is sata) ... else ... code inside hooks, when the libata-with-fixed-API solution looks like static void pata_doit() { ... } static void sata_doit() { ... } static struct ata_port_operations pata_ops = {...}; static struct ata_port_operations sata_ops = {...}; For such cases, PATA support for these _new_ controllers needs to be added to sata_via.c, sata_uli.c, sata_sis.c, and they should then be renamed. Or whatever similar renaming/code-shuffle solution brings about the same end result. Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 20:14 ` 2.6.17-mm6 Jeff Garzik @ 2006-07-07 20:42 ` Alan Cox 2006-07-07 20:37 ` 2.6.17-mm6 Jeff Garzik 0 siblings, 1 reply; 111+ messages in thread From: Alan Cox @ 2006-07-07 20:42 UTC (permalink / raw) To: Jeff Garzik; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Ar Gwe, 2006-07-07 am 16:14 -0400, ysgrifennodd Jeff Garzik: > I'm a bit surprised to see pata_sis and pata_via: are you certain there > is not confusion based on the fact that newer SiS, ULi and VIA > controllers provide both SATA and PATA on the same controller? Hard to be sure but it looks like some vendors briefly used marvell bridges of some form with a few generic PATA chipsets. Alan ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 20:42 ` 2.6.17-mm6 Alan Cox @ 2006-07-07 20:37 ` Jeff Garzik 2006-07-07 21:09 ` 2.6.17-mm6 J.A. Magallón 0 siblings, 1 reply; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 20:37 UTC (permalink / raw) To: Alan Cox; +Cc: Randy.Dunlap, jamagallon, akpm, linux-kernel Alan Cox wrote: > Ar Gwe, 2006-07-07 am 16:14 -0400, ysgrifennodd Jeff Garzik: >> I'm a bit surprised to see pata_sis and pata_via: are you certain there >> is not confusion based on the fact that newer SiS, ULi and VIA >> controllers provide both SATA and PATA on the same controller? > > Hard to be sure but it looks like some vendors briefly used marvell > bridges of some form with a few generic PATA chipsets. Yep. The sata_xxx should cover most of the Marvell-SATA-bridge + PATA chip controllers already. Pretty much everybody except Silicon Image used the Marvell bridge for their first generation SATA. I've tried hard to make sure that most of these made it into sata_xxx already. Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 20:37 ` 2.6.17-mm6 Jeff Garzik @ 2006-07-07 21:09 ` J.A. Magallón 2006-07-07 21:11 ` 2.6.17-mm6 Jeff Garzik 0 siblings, 1 reply; 111+ messages in thread From: J.A. Magallón @ 2006-07-07 21:09 UTC (permalink / raw) To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel On Fri, 07 Jul 2006 16:37:44 -0400, Jeff Garzik <jeff@garzik.org> wrote: > Alan Cox wrote: > > Ar Gwe, 2006-07-07 am 16:14 -0400, ysgrifennodd Jeff Garzik: > >> I'm a bit surprised to see pata_sis and pata_via: are you certain there > >> is not confusion based on the fact that newer SiS, ULi and VIA > >> controllers provide both SATA and PATA on the same controller? > > > > Hard to be sure but it looks like some vendors briefly used marvell > > bridges of some form with a few generic PATA chipsets. > > Yep. The sata_xxx should cover most of the Marvell-SATA-bridge + PATA > chip controllers already. > > Pretty much everybody except Silicon Image used the Marvell bridge for > their first generation SATA. > Dumb view from outside the ATA world: why dont assume all controllers can do both SATA and PATA, require some {p,s}ata_init(), {p,s}ata_enumerate_drives() and so on, and provide no-ops as default for them ? So SATA only can override sata_ ones, same for PATA and the weird (really ICH5 is so strange ?) ones override both. So you can decide later about doing for each controller pata_init sata_init or for each controller sata_init pata_init or for each controller sata_init for each controller pata_init Just an idea. Good designed inheritance is good ;). AH, and all the drivers could be named as 'ata_xxxx'. Nice. -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:09 ` 2.6.17-mm6 J.A. Magallón @ 2006-07-07 21:11 ` Jeff Garzik 2006-07-07 21:40 ` 2.6.17-mm6 J.A. Magallón 0 siblings, 1 reply; 111+ messages in thread From: Jeff Garzik @ 2006-07-07 21:11 UTC (permalink / raw) To: "J.A. Magallón"; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel J.A. Magallón wrote: > for each controller > sata_init > for each controller > pata_init There is never a 'for each controller' operation. The current layering is as it should be. Jeff ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:11 ` 2.6.17-mm6 Jeff Garzik @ 2006-07-07 21:40 ` J.A. Magallón 0 siblings, 0 replies; 111+ messages in thread From: J.A. Magallón @ 2006-07-07 21:40 UTC (permalink / raw) To: Jeff Garzik; +Cc: Alan Cox, Randy.Dunlap, akpm, linux-kernel On Fri, 07 Jul 2006 17:11:55 -0400, Jeff Garzik <jeff@garzik.org> wrote: > J.A. Magallón wrote: > > for each controller > > sata_init > > for each controller > > pata_init > > > There is never a 'for each controller' operation. > I know, what would happen when a module loads ? But you could always do something like ata_piix_init() { if (libata.pata_first) pata_init() sata_init() else sata_init() pata_init() } > The current layering is as it should be. > This is what I like of many developers. It's like it is and it's the best. Until 2.8 opens. -- J.A. Magallon <jamagallon()ono!com> \ Software is like sex: \ It's better when it's free Mandriva Linux release 2007.0 (Cooker) for i586 Linux 2.6.17-jam01 (gcc 4.1.1 20060518 (prerelease)) #2 SMP PREEMPT Wed ^ permalink raw reply [flat|nested] 111+ messages in thread
[parent not found: <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com>]
* Re: 2.6.17-mm6 [not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com> @ 2006-07-05 22:50 ` Andrew Morton 2006-07-05 23:28 ` 2.6.17-mm6 Keith Mannthey 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-05 22:50 UTC (permalink / raw) To: Keith Mannthey; +Cc: linux-kernel "Keith Mannthey" <kmannth@gmail.com> wrote: > > On 7/3/06, Andrew Morton <akpm@osdl.org> wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > Moving from -mm4 to -mm6 I ran into this while trying to boot.... > <snip> > Could not allocate 16 bytes percpu data > Could not allocate 16 bytes percpu data > sd_mod: Unknown symbol scsi_print_sense_hdr > sd_mod: Unknown symbol scsi_mode_sense > sd_mod: Unknown symbol scsi_device_get > sd_mod: Unknown symbol scsi_get_sense_info_fld > <snip> > > sd_mod (and later aacraid) are built into my initrd and loaded during boot. > > I doubled PERCPU_ENOUGH_ROOM to 65536 and was able to boot. I am not > sure what is eating all the percpu room on the system. I was using > this config with -mm4 just fine. > > I attached the dmesg and .config > Looks like we simply ran out. Why?... patches/genirq-x86_64-irq-make-vector_irq-per-cpu.patch:+DEFINE_PER_CPU(vector_irq_t, vector_irq) = { patches/mm-implement-swap-prefetching.patch:+static DEFINE_PER_CPU(struct pagevec, lru_add_tail_pvecs) = { 0, }; patches/origin.patch:+static DEFINE_PER_CPU(u64 *, tce_page) = NULL; patches/origin.patch:+DEFINE_PER_CPU(struct sys_device, device_mce); patches/origin.patch:+static DEFINE_PER_CPU(struct threshold_bank *, threshold_banks[NR_BANKS]); patches/origin.patch:+static DEFINE_PER_CPU(struct rq, runqueues); patches/origin.patch:+DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{0}}; patches/per-task-delay-accounting-taskstats-interface.patch:+static DEFINE_PER_CPU(__u32, taskstats_seqnum) = { 0 }; patches/readahead-state-based-method-aging-accounting.patch:+DEFINE_PER_CPU(unsigned long, readahead_aging); patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner); patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]); patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner); patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]); patches/x86_64-mm-add-smp-support-on-i386-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk); patches/x86_64-mm-add-smp-support-on-x86_64-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk); Per-cpuifying the 2.5 kbyte runqueue struct will have hurt. [does readelf --section-headers drivers/scsi/sd_mod.ko, wonders why .data.percpu isn't there] Are you able to add this, see if we can work out where it all went? --- a/kernel/module.c~a +++ a/kernel/module.c @@ -340,6 +340,9 @@ static void *percpu_modalloc(unsigned lo unsigned int i; void *ptr; + printk("%s: allocating %lu bytes for module %s (vmlinux:%lu)\n", + __FUNCTION__, size, name, block_size(pcpu_size[0])); + if (align > SMP_CACHE_BYTES) { printk(KERN_WARNING "%s: per-cpu alignment %li > %i\n", name, align, SMP_CACHE_BYTES); _ ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 22:50 ` 2.6.17-mm6 Andrew Morton @ 2006-07-05 23:28 ` Keith Mannthey 2006-07-05 23:44 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Keith Mannthey @ 2006-07-05 23:28 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: > "Keith Mannthey" <kmannth@gmail.com> wrote: > > > > On 7/3/06, Andrew Morton <akpm@osdl.org> wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > > > > > Moving from -mm4 to -mm6 I ran into this while trying to boot.... > > <snip> > > Could not allocate 16 bytes percpu data > > Could not allocate 16 bytes percpu data > > sd_mod: Unknown symbol scsi_print_sense_hdr > > sd_mod: Unknown symbol scsi_mode_sense > > sd_mod: Unknown symbol scsi_device_get > > sd_mod: Unknown symbol scsi_get_sense_info_fld > > <snip> > > > > sd_mod (and later aacraid) are built into my initrd and loaded during boot. > > > > I doubled PERCPU_ENOUGH_ROOM to 65536 and was able to boot. I am not > > sure what is eating all the percpu room on the system. I was using > > this config with -mm4 just fine. > > > > I attached the dmesg and .config > > > > Looks like we simply ran out. Why?... > > patches/genirq-x86_64-irq-make-vector_irq-per-cpu.patch:+DEFINE_PER_CPU(vector_irq_t, vector_irq) = { > patches/mm-implement-swap-prefetching.patch:+static DEFINE_PER_CPU(struct pagevec, lru_add_tail_pvecs) = { 0, }; > patches/origin.patch:+static DEFINE_PER_CPU(u64 *, tce_page) = NULL; > patches/origin.patch:+DEFINE_PER_CPU(struct sys_device, device_mce); > patches/origin.patch:+static DEFINE_PER_CPU(struct threshold_bank *, threshold_banks[NR_BANKS]); > patches/origin.patch:+static DEFINE_PER_CPU(struct rq, runqueues); > patches/origin.patch:+DEFINE_PER_CPU(struct vm_event_state, vm_event_states) = {{0}}; > patches/per-task-delay-accounting-taskstats-interface.patch:+static DEFINE_PER_CPU(__u32, taskstats_seqnum) = { 0 }; > patches/readahead-state-based-method-aging-accounting.patch:+DEFINE_PER_CPU(unsigned long, readahead_aging); > patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, perfctr_nmi_owner); > patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned long, evntsel_nmi_owner[3]); > patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, perfctr_nmi_owner); > patches/x86_64-mm-add-performance-counter-reservation-framework-for-up-kernels.patch:+static DEFINE_PER_CPU(unsigned, evntsel_nmi_owner[2]); > patches/x86_64-mm-add-smp-support-on-i386-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk); > patches/x86_64-mm-add-smp-support-on-x86_64-to-reservation-framework.patch:+static DEFINE_PER_CPU(struct nmi_watchdog_ctlblk, nmi_watchdog_ctlblk); > > Per-cpuifying the 2.5 kbyte runqueue struct will have hurt. > > [does readelf --section-headers drivers/scsi/sd_mod.ko, wonders why > .data.percpu isn't there] hmm. There is no message from the readelf command but there it dosen't report any .data.percpu area. The only sections for data are just .data and .rela.data > Are you able to add this, see if we can work out where it all went? I am still booting with the larger percpu size but I see percpu_modalloc: allocating 16 bytes for module scsi_mod (vmlinux:41600) percpu_modalloc: allocating 8 bytes for module ipv6 (vmlinux:41600) from the log. Something built in is eating it. I am turing off the readhead to see if that helps. Thanks, Keith ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 23:28 ` 2.6.17-mm6 Keith Mannthey @ 2006-07-05 23:44 ` Andrew Morton 2006-07-05 23:48 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-05 23:44 UTC (permalink / raw) To: Keith Mannthey; +Cc: linux-kernel On Wed, 5 Jul 2006 16:28:39 -0700 "Keith Mannthey" <kmannth@gmail.com> wrote: > > Per-cpuifying the 2.5 kbyte runqueue struct will have hurt. > > > > [does readelf --section-headers drivers/scsi/sd_mod.ko, wonders why > > .data.percpu isn't there] > > hmm. There is no message from the readelf command but there it dosen't > report any .data.percpu area. The only sections for data are just .data and > .rela.data hm. > > Are you able to add this, see if we can work out where it all went? > > I am still booting with the larger percpu size but I see > > percpu_modalloc: allocating 16 bytes for module scsi_mod (vmlinux:41600) > percpu_modalloc: allocating 8 bytes for module ipv6 (vmlinux:41600) > > from the log. Something built in is eating it. Yes, vmlinux got it all. > I am turing off the readhead to see if that helps. Use nm -n vmlinux | grep per_cpu I get: 00000000c0425780 A __per_cpu_start 00000000c0427980 d per_cpu__cpu_idle_state 00000000c0427a00 D per_cpu__irq_stat 00000000c0427a80 D per_cpu__cpu_16bit_stack 00000000c0427e80 D per_cpu__cpu_gdt_descr 00000000c0427f00 D per_cpu__cpu_tlbstate 00000000c0427f80 D per_cpu__cpu_state 00000000c0427f84 d per_cpu__perfctr_nmi_owner 00000000c0427f88 d per_cpu__evntsel_nmi_owner 00000000c0427f94 d per_cpu__nmi_watchdog_ctlblk 00000000c0427fc0 D per_cpu__current_kprobe 00000000c0427fe0 D per_cpu__kprobe_ctlblk 00000000c0428080 D per_cpu__mmu_gathers 00000000c0428880 d per_cpu__runqueues 00000000c0429240 d per_cpu__cpu_domains 00000000c0429320 d per_cpu__core_domains 00000000c0429400 d per_cpu__phys_domains 00000000c04294e0 D per_cpu__kstat 00000000c04298dc D per_cpu__process_counts 00000000c04298e0 d per_cpu__cpu_profile_hits 00000000c04298e8 d per_cpu__cpu_profile_flip 00000000c04298ec d per_cpu__tasklet_vec 00000000c04298f0 d per_cpu__tasklet_hi_vec 00000000c04298f4 d per_cpu__ksoftirqd 00000000c04298f8 d per_cpu__tvec_bases 00000000c0429900 D per_cpu__rcu_data 00000000c0429940 D per_cpu__rcu_bh_data 00000000c0429980 d per_cpu__rcu_tasklet 00000000c04299a0 d per_cpu__hrtimer_bases 00000000c0429a38 d per_cpu__kprobe_instance 00000000c0429a3c d per_cpu__touch_timestamp 00000000c0429a40 d per_cpu__print_timestamp 00000000c0429a44 d per_cpu__watchdog_task 00000000c0429a60 d per_cpu__ratelimits.18951 00000000c0429a80 d per_cpu__committed_space 00000000c0429aa0 d per_cpu__lru_add_pvecs 00000000c0429ae0 d per_cpu__lru_add_active_pvecs 00000000c0429b20 D per_cpu__vm_event_states 00000000c0429bc0 d per_cpu__reap_work 00000000c0429c00 d per_cpu__bh_lrus 00000000c0429c20 d per_cpu__bh_accounting 00000000c0429c40 d per_cpu__fdtable_defer_list 00000000c0429ca8 D per_cpu__avc_cache_stats 00000000c0429cc0 d per_cpu__blk_cpu_done 00000000c0429cc8 d per_cpu__blk_trace_cpu_offset 00000000c0429ce0 D per_cpu__radix_tree_preloads 00000000c0429d00 d per_cpu__trickle_count 00000000c0429d04 d per_cpu__proc_event_counts 00000000c0429d20 d per_cpu__loopback_stats 00000000c0429d80 d per_cpu__sockets_in_use 00000000c0429e00 D per_cpu__softnet_data 00000000c042a300 D per_cpu__netdev_rx_stat 00000000c042a310 d per_cpu__net_rand_state 00000000c042a380 d per_cpu__flow_tables 00000000c042a400 d per_cpu__flow_hash_info 00000000c042a480 d per_cpu__flow_flush_tasklets 00000000c042a4a0 d per_cpu__rt_cache_stat 00000000c042a4e0 d per_cpu____icmp_socket 00000000c042a4e4 A __per_cpu_end Which is 19k. <wonders what happened to the first 8.5k> If we have any 2-D arrays in there (something dimensioned by NR_CPUS) then we'll have a big problem. I guess a medium-term fix would be to add a boot parameter to override PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just for the benefit of the tiny minority of kernels which are hand-built with lots of drivers in vmlinux. But first let's find out where it all went. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 23:44 ` 2.6.17-mm6 Andrew Morton @ 2006-07-05 23:48 ` Andrew Morton 2006-07-06 0:05 ` 2.6.17-mm6 Keith Mannthey 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-05 23:48 UTC (permalink / raw) To: kmannth, linux-kernel On Wed, 5 Jul 2006 16:44:57 -0700 Andrew Morton <akpm@osdl.org> wrote: > I guess a medium-term fix would be to add a boot parameter to override > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just > for the benefit of the tiny minority of kernels which are hand-built with > lots of drivers in vmlinux. > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded modules, so if vmlinux blows it all then `modprobe the-same-stuff' will blow it as well. > But first let's find out where it all went. I agree with that person. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-05 23:48 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 0:05 ` Keith Mannthey 2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Keith Mannthey @ 2006-07-06 0:05 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: > On Wed, 5 Jul 2006 16:44:57 -0700 > Andrew Morton <akpm@osdl.org> wrote: > > > I guess a medium-term fix would be to add a boot parameter to override > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just > > for the benefit of the tiny minority of kernels which are hand-built with > > lots of drivers in vmlinux. I am not really loading alot of drivers. I am building with a ton of driver. > > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will > blow it as well. > > > But first let's find out where it all went. > > I agree with that person. :) This is what I get it is diffrent that yours for sure. I am a little confused by the large offset change near the start.....? elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu 000000000c5ef91b A __crc_per_cpu__vm_event_states 0000000023898563 A __crc_per_cpu__softnet_data 0000000026d8eb30 A __crc_per_cpu__kstat ffffffff802645ae t lru_add_drain_per_cpu ffffffff80386818 t flow_cache_flush_per_cpu ffffffff8041e010 r __ksymtab_per_cpu__kstat ffffffff8041f6f0 r __ksymtab_per_cpu__vm_event_states ffffffff80424e80 r __ksymtab_per_cpu__softnet_data ffffffff804288f0 r __kcrctab_per_cpu__kstat ffffffff80429460 r __kcrctab_per_cpu__vm_event_states ffffffff8042c028 r __kcrctab_per_cpu__softnet_data ffffffff8042e550 r __kstrtab_per_cpu__kstat ffffffff80430f10 r __kstrtab_per_cpu__vm_event_states ffffffff8043a3b0 r __kstrtab_per_cpu__softnet_data ffffffff8062b91c T setup_per_cpu_areas ffffffff80636921 T setup_per_cpu_pageset ffffffff80658000 A __per_cpu_start ffffffff80658000 D per_cpu__init_tss ffffffff8065a080 d per_cpu__idle_state ffffffff8065a084 d per_cpu__cpu_idle_state ffffffff8065a0a0 D per_cpu__vector_irq ffffffff8065a4a0 D per_cpu__device_mce ffffffff8065a518 d per_cpu__next_check ffffffff8065a520 d per_cpu__threshold_banks ffffffff8065a550 d per_cpu__bank_map ffffffff8065a580 d per_cpu__flush_state ffffffff8065a600 D per_cpu__cpu_state ffffffff8065a620 d per_cpu__perfctr_nmi_owner ffffffff8065a624 d per_cpu__evntsel_nmi_owner ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk ffffffff8065a660 d per_cpu__last_irq_sum ffffffff8065a668 d per_cpu__alert_counter ffffffff8065a670 d per_cpu__nmi_touch ffffffff8065a680 D per_cpu__current_kprobe ffffffff8065a6a0 D per_cpu__kprobe_ctlblk ffffffff8065a7e0 D per_cpu__mmu_gathers ffffffff8065b7e0 d per_cpu__runqueues ffffffff8065ca60 d per_cpu__cpu_domains ffffffff8065cae0 d per_cpu__core_domains ffffffff8065cb60 d per_cpu__phys_domains ffffffff8065cbe0 d per_cpu__node_domains ffffffff8065cc60 d per_cpu__allnodes_domains ffffffff8065cce0 D per_cpu__kstat ffffffff80661120 D per_cpu__process_counts ffffffff80661130 d per_cpu__cpu_profile_hits ffffffff80661140 d per_cpu__cpu_profile_flip ffffffff80661148 d per_cpu__tasklet_vec ffffffff80661150 d per_cpu__tasklet_hi_vec ffffffff80661158 d per_cpu__ksoftirqd ffffffff80661160 d per_cpu__tvec_bases ffffffff80661180 D per_cpu__rcu_data ffffffff80661200 D per_cpu__rcu_bh_data ffffffff80661280 d per_cpu__rcu_tasklet ffffffff806612c0 d per_cpu__hrtimer_bases ffffffff80661340 d per_cpu__kprobe_instance ffffffff80661348 d per_cpu__taskstats_seqnum ffffffff80661360 d per_cpu__ratelimits.18857 ffffffff80661380 d per_cpu__committed_space ffffffff806613a0 d per_cpu__lru_add_pvecs ffffffff80661420 d per_cpu__lru_add_active_pvecs ffffffff806614a0 d per_cpu__lru_add_tail_pvecs ffffffff80661520 D per_cpu__vm_event_states ffffffff80661640 d per_cpu__reap_work ffffffff806616a0 d per_cpu__reap_node ffffffff806616c0 d per_cpu__bh_lrus ffffffff80661700 d per_cpu__bh_accounting ffffffff80661720 d per_cpu__fdtable_defer_list ffffffff806617c0 d per_cpu__blk_cpu_done ffffffff806617e0 D per_cpu__radix_tree_preloads ffffffff80661860 d per_cpu__trickle_count ffffffff80661864 d per_cpu__proc_event_counts ffffffff80661880 d per_cpu__loopback_stats ffffffff80661980 d per_cpu__sockets_in_use ffffffff80661a00 D per_cpu__softnet_data ffffffff80662000 D per_cpu__netdev_rx_stat ffffffff80662010 d per_cpu__net_rand_state ffffffff80662080 d per_cpu__flow_tables ffffffff80662100 d per_cpu__flow_hash_info ffffffff80662180 d per_cpu__flow_flush_tasklets ffffffff806621c0 d per_cpu__rt_cache_stat ffffffff80662200 d per_cpu____icmp_socket ffffffff80662208 A __per_cpu_end Thanks, Keith ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 0:05 ` 2.6.17-mm6 Keith Mannthey @ 2006-07-06 0:25 ` Andrew Morton 2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman 2006-07-12 3:55 ` 2.6.17-mm6 Steven Rostedt 0 siblings, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-06 0:25 UTC (permalink / raw) To: Keith Mannthey Cc: linux-kernel, Ingo Molnar, Thomas Gleixner, Eric W. Biederman On Wed, 5 Jul 2006 17:05:49 -0700 "Keith Mannthey" <kmannth@gmail.com> wrote: > On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: > > On Wed, 5 Jul 2006 16:44:57 -0700 > > Andrew Morton <akpm@osdl.org> wrote: > > > > > I guess a medium-term fix would be to add a boot parameter to override > > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just > > > for the benefit of the tiny minority of kernels which are hand-built with > > > lots of drivers in vmlinux. > > I am not really loading alot of drivers. I am building with a ton of driver. > > > > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded > > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will > > blow it as well. > > > > > But first let's find out where it all went. > > > > I agree with that person. > :) > > This is what I get it is diffrent that yours for sure. I am a little > confused by the large offset change near the start.....? Yes, I had an unexplained 8k hole. That was i386. Your x86_64 output looks OK though. > elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu >... > ffffffff80658000 A __per_cpu_start It starts here > ffffffff80658000 D per_cpu__init_tss 8k > ffffffff8065a080 d per_cpu__idle_state > ffffffff8065a084 d per_cpu__cpu_idle_state > ffffffff8065a0a0 D per_cpu__vector_irq > ffffffff8065a4a0 D per_cpu__device_mce > ffffffff8065a518 d per_cpu__next_check > ffffffff8065a520 d per_cpu__threshold_banks > ffffffff8065a550 d per_cpu__bank_map > ffffffff8065a580 d per_cpu__flush_state > ffffffff8065a600 D per_cpu__cpu_state > ffffffff8065a620 d per_cpu__perfctr_nmi_owner > ffffffff8065a624 d per_cpu__evntsel_nmi_owner > ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk > ffffffff8065a660 d per_cpu__last_irq_sum > ffffffff8065a668 d per_cpu__alert_counter > ffffffff8065a670 d per_cpu__nmi_touch > ffffffff8065a680 D per_cpu__current_kprobe > ffffffff8065a6a0 D per_cpu__kprobe_ctlblk > ffffffff8065a7e0 D per_cpu__mmu_gathers 4k > ffffffff8065b7e0 d per_cpu__runqueues 5k > ffffffff8065ca60 d per_cpu__cpu_domains > ffffffff8065cae0 d per_cpu__core_domains > ffffffff8065cb60 d per_cpu__phys_domains > ffffffff8065cbe0 d per_cpu__node_domains > ffffffff8065cc60 d per_cpu__allnodes_domains > ffffffff8065cce0 D per_cpu__kstat wham - 17.5k > ffffffff80661120 D per_cpu__process_counts > ffffffff80661130 d per_cpu__cpu_profile_hits > ffffffff80661140 d per_cpu__cpu_profile_flip > ffffffff80661148 d per_cpu__tasklet_vec > ffffffff80661150 d per_cpu__tasklet_hi_vec > ffffffff80661158 d per_cpu__ksoftirqd > ffffffff80661160 d per_cpu__tvec_bases > ffffffff80661180 D per_cpu__rcu_data > ffffffff80661200 D per_cpu__rcu_bh_data > ffffffff80661280 d per_cpu__rcu_tasklet > ffffffff806612c0 d per_cpu__hrtimer_bases > ffffffff80661340 d per_cpu__kprobe_instance > ffffffff80661348 d per_cpu__taskstats_seqnum > ffffffff80661360 d per_cpu__ratelimits.18857 > ffffffff80661380 d per_cpu__committed_space > ffffffff806613a0 d per_cpu__lru_add_pvecs > ffffffff80661420 d per_cpu__lru_add_active_pvecs > ffffffff806614a0 d per_cpu__lru_add_tail_pvecs > ffffffff80661520 D per_cpu__vm_event_states > ffffffff80661640 d per_cpu__reap_work > ffffffff806616a0 d per_cpu__reap_node > ffffffff806616c0 d per_cpu__bh_lrus > ffffffff80661700 d per_cpu__bh_accounting > ffffffff80661720 d per_cpu__fdtable_defer_list > ffffffff806617c0 d per_cpu__blk_cpu_done > ffffffff806617e0 D per_cpu__radix_tree_preloads > ffffffff80661860 d per_cpu__trickle_count > ffffffff80661864 d per_cpu__proc_event_counts > ffffffff80661880 d per_cpu__loopback_stats > ffffffff80661980 d per_cpu__sockets_in_use > ffffffff80661a00 D per_cpu__softnet_data > ffffffff80662000 D per_cpu__netdev_rx_stat > ffffffff80662010 d per_cpu__net_rand_state > ffffffff80662080 d per_cpu__flow_tables > ffffffff80662100 d per_cpu__flow_hash_info > ffffffff80662180 d per_cpu__flow_flush_tasklets > ffffffff806621c0 d per_cpu__rt_cache_stat > ffffffff80662200 d per_cpu____icmp_socket > ffffffff80662208 A __per_cpu_end So you've been hit by the expansion of NR_IRQS which bloats kernel_stat which gobbles per-cpu data. In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion) NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became two-dimensional. It's now O(NR_CPUS^2). I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a showstopper if the ia64 guys try the same trick. I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or dynamically allocate it with alloc_percpu(). (cc's people, runs away) ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 5:42 ` Eric W. Biederman 2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton 2006-07-06 17:16 ` 2.6.17-mm6 Andi Kleen 2006-07-12 3:55 ` 2.6.17-mm6 Steven Rostedt 1 sibling, 2 replies; 111+ messages in thread From: Eric W. Biederman @ 2006-07-06 5:42 UTC (permalink / raw) To: Andrew Morton Cc: Keith Mannthey, linux-kernel, Ingo Molnar, Thomas Gleixner, Protasevich, Natalie Andrew Morton <akpm@osdl.org> writes: > On Wed, 5 Jul 2006 17:05:49 -0700 > "Keith Mannthey" <kmannth@gmail.com> wrote: > >> On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: >> > On Wed, 5 Jul 2006 16:44:57 -0700 >> > Andrew Morton <akpm@osdl.org> wrote: >> > >> > > I guess a medium-term fix would be to add a boot parameter to override >> > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just >> > > for the benefit of the tiny minority of kernels which are hand-built with >> > > lots of drivers in vmlinux. >> >> I am not really loading alot of drivers. I am building with a ton of driver. >> > >> > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded >> > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will >> > blow it as well. >> > >> > > But first let's find out where it all went. >> > >> > I agree with that person. >> :) >> >> This is what I get it is diffrent that yours for sure. I am a little >> confused by the large offset change near the start.....? > > Yes, I had an unexplained 8k hole. That was i386. Your x86_64 output > looks OK though. > >> elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu >>... >> ffffffff80658000 A __per_cpu_start It starts here >> ffffffff80658000 D per_cpu__init_tss 8k >> ffffffff8065a080 d per_cpu__idle_state >> ffffffff8065a084 d per_cpu__cpu_idle_state >> ffffffff8065a0a0 D per_cpu__vector_irq >> ffffffff8065a4a0 D per_cpu__device_mce >> ffffffff8065a518 d per_cpu__next_check >> ffffffff8065a520 d per_cpu__threshold_banks >> ffffffff8065a550 d per_cpu__bank_map >> ffffffff8065a580 d per_cpu__flush_state >> ffffffff8065a600 D per_cpu__cpu_state >> ffffffff8065a620 d per_cpu__perfctr_nmi_owner >> ffffffff8065a624 d per_cpu__evntsel_nmi_owner >> ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk >> ffffffff8065a660 d per_cpu__last_irq_sum >> ffffffff8065a668 d per_cpu__alert_counter >> ffffffff8065a670 d per_cpu__nmi_touch >> ffffffff8065a680 D per_cpu__current_kprobe >> ffffffff8065a6a0 D per_cpu__kprobe_ctlblk >> ffffffff8065a7e0 D per_cpu__mmu_gathers 4k >> ffffffff8065b7e0 d per_cpu__runqueues 5k >> ffffffff8065ca60 d per_cpu__cpu_domains >> ffffffff8065cae0 d per_cpu__core_domains >> ffffffff8065cb60 d per_cpu__phys_domains >> ffffffff8065cbe0 d per_cpu__node_domains >> ffffffff8065cc60 d per_cpu__allnodes_domains >> ffffffff8065cce0 D per_cpu__kstat wham - 17.5k >> ffffffff80661120 D per_cpu__process_counts >> ffffffff80661130 d per_cpu__cpu_profile_hits >> ffffffff80661140 d per_cpu__cpu_profile_flip >> ffffffff80661148 d per_cpu__tasklet_vec >> ffffffff80661150 d per_cpu__tasklet_hi_vec >> ffffffff80661158 d per_cpu__ksoftirqd >> ffffffff80661160 d per_cpu__tvec_bases >> ffffffff80661180 D per_cpu__rcu_data >> ffffffff80661200 D per_cpu__rcu_bh_data >> ffffffff80661280 d per_cpu__rcu_tasklet >> ffffffff806612c0 d per_cpu__hrtimer_bases >> ffffffff80661340 d per_cpu__kprobe_instance >> ffffffff80661348 d per_cpu__taskstats_seqnum >> ffffffff80661360 d per_cpu__ratelimits.18857 >> ffffffff80661380 d per_cpu__committed_space >> ffffffff806613a0 d per_cpu__lru_add_pvecs >> ffffffff80661420 d per_cpu__lru_add_active_pvecs >> ffffffff806614a0 d per_cpu__lru_add_tail_pvecs >> ffffffff80661520 D per_cpu__vm_event_states >> ffffffff80661640 d per_cpu__reap_work >> ffffffff806616a0 d per_cpu__reap_node >> ffffffff806616c0 d per_cpu__bh_lrus >> ffffffff80661700 d per_cpu__bh_accounting >> ffffffff80661720 d per_cpu__fdtable_defer_list >> ffffffff806617c0 d per_cpu__blk_cpu_done >> ffffffff806617e0 D per_cpu__radix_tree_preloads >> ffffffff80661860 d per_cpu__trickle_count >> ffffffff80661864 d per_cpu__proc_event_counts >> ffffffff80661880 d per_cpu__loopback_stats >> ffffffff80661980 d per_cpu__sockets_in_use >> ffffffff80661a00 D per_cpu__softnet_data >> ffffffff80662000 D per_cpu__netdev_rx_stat >> ffffffff80662010 d per_cpu__net_rand_state >> ffffffff80662080 d per_cpu__flow_tables >> ffffffff80662100 d per_cpu__flow_hash_info >> ffffffff80662180 d per_cpu__flow_flush_tasklets >> ffffffff806621c0 d per_cpu__rt_cache_stat >> ffffffff80662200 d per_cpu____icmp_socket >> ffffffff80662208 A __per_cpu_end > > So you've been hit by the expansion of NR_IRQS which bloats kernel_stat > which gobbles per-cpu data. > > In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion) > NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became > two-dimensional. It's now O(NR_CPUS^2). Hmm. Perhaps it is a good thing I didn't push it to it's limit of 244*NR_CPUS. > I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a > showstopper if the ia64 guys try the same trick. I think the unisys boxes are about 128 sockets. So 128 or 256 is the max at the moment. I'm not certain where things are heading. Big specialized boxes seem to be giving way to smaller systems. Yet the amount that you can do with commodity hardware is getting larger, so I suspect it will likely be a wash. The worst case scenario is that sgi will build a chipset supporting 32K cpus that works with both Xeons and Itaniums. > I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or > dynamically allocate it with alloc_percpu(). Hmm. It might make sense to have a NR_CPUS array in each irq_desc. We already have a per cpu bit map so that should only make the irq array about 32 times bigger, but it would take it out of the per_cpu area. To get to 17k that took a 128 cpu build. 128 cpus looks reasonable for a build for the maximum number of cpus. On x86_64 when we have more than 8 cpus (aka cores) all of the moving between cpus is done is software which means we are not too likely to move between cpus. In any sane configuration an irq will stay on the same cpu or the same couple of cpus so we get good locality effects (especially NUMA locality), so there might be something we can take advantage of there. Possibly we might want to just live with this for now. But a data structure that ultimately consumes 244*NR_CPUS*NR_CPUS*4 bytes looks excessive. 32*NR_CPUS has been the expected number of irq sources for a long time but previously we forced sharing of the irq number after a point. So I think that is a fairly reasonable number. Although 8*NR_CPUS may be more reasonable. But the bottom line is that the more cpus we have the interrupts we can handle and quite likely the more interrupts we will need to handle to keep the system busy. So NR_IRQS should scale with the number of cpus. So I suspect that we need to de-percpuify kernel_stat.irqs. Possibly setup a set of counters that hold the count on the current cpu and the total count across also cpus, and we update the count whenever we migrate the cpu. Possibly we could hold counts for the last 2 or 3 cpus. I don't know how realistic it is to assume that an irq will be bound to a cpu on all architectures. So we might have to do it dynamically. I'm tempted to suggest adding the following to irq_desc. unsigned int last_cpu_count; unsigned int last_cpu; And just rely on those and the total irq count we already seem to have in the irq_count field of struct irq_desc, for the statistics. That would allow us to see where an irq is occurring and how frequently without bloating things up. Of course that is lossy. > (cc's people, runs away) (throws out ideas, runs after Andrew) Eric ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman @ 2006-07-06 5:59 ` Andrew Morton 2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton 2006-07-06 6:40 ` 2.6.17-mm6 Eric W. Biederman 2006-07-06 17:16 ` 2.6.17-mm6 Andi Kleen 1 sibling, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-06 5:59 UTC (permalink / raw) To: Eric W. Biederman; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich On Wed, 05 Jul 2006 23:42:00 -0600 ebiederm@xmission.com (Eric W. Biederman) wrote: > So I suspect that we need to de-percpuify kernel_stat.irqs. I think so. We do: struct irq_desc *desc = irq_desc + irq; kstat_this_cpu.irqs[irq]++; followed immediately by spin_lock(&desc->lock); false optimisation, or what? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 6:31 ` Andrew Morton 2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman 2006-07-06 16:49 ` 2.6.17-mm6 Eric W. Biederman 2006-07-06 6:40 ` 2.6.17-mm6 Eric W. Biederman 1 sibling, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-06 6:31 UTC (permalink / raw) To: ebiederm, kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich On Wed, 5 Jul 2006 22:59:05 -0700 Andrew Morton <akpm@osdl.org> wrote: > On Wed, 05 Jul 2006 23:42:00 -0600 > ebiederm@xmission.com (Eric W. Biederman) wrote: > > > So I suspect that we need to de-percpuify kernel_stat.irqs. > > I think so. Maybe not. If we do this, we lose the pretty CPUn columns in /proc/interrupts. That /proc/interrupts display requires that we maintain NR_CPUS*NR_IRQS counters. Given that a large NR_IRQs space will be sparsely populated, we should dynamically allocate the NR_CPUS storage for each active IRQ, as you say. That involves putting it into the irq_desc (as good a place as any). And a rather large number of trivial edits. I guess we do this only for genirq? ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 7:18 ` Eric W. Biederman 2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar 2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven 2006-07-06 16:49 ` 2.6.17-mm6 Eric W. Biederman 1 sibling, 2 replies; 111+ messages in thread From: Eric W. Biederman @ 2006-07-06 7:18 UTC (permalink / raw) To: Andrew Morton; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich Andrew Morton <akpm@osdl.org> writes: > On Wed, 5 Jul 2006 22:59:05 -0700 > Andrew Morton <akpm@osdl.org> wrote: > >> On Wed, 05 Jul 2006 23:42:00 -0600 >> ebiederm@xmission.com (Eric W. Biederman) wrote: >> >> > So I suspect that we need to de-percpuify kernel_stat.irqs. >> >> I think so. > > Maybe not. If we do this, we lose the pretty CPUn columns in > /proc/interrupts. That /proc/interrupts display requires that we maintain > NR_CPUS*NR_IRQS counters. Yes. Although at least part of that display is per architecture so we may be able to get away with a little more. > Given that a large NR_IRQs space will be sparsely populated, we should > dynamically allocate the NR_CPUS storage for each active IRQ, as you say. To some extent. Although with MSI-X there is the potential we could use all of them. (But probably not). Natalie has a firmer grasp on what is common that I do. But I think the big Unisys boxes were running 1-2 active irqs per cpu, and I believe some large IBM boxes were worse. What is scary is that at 1K cpus if we wind up using all of the irqs we start consuming 1Gig of RAM. At only 128 cpus we are still in the 2M-15M territory, so that isn't too scary. The point is that after a certain put the memory usage for all of those counters goes insane. So I'm not certain how safe it is to leave something that explodes that badly in there. We at least need a big fat scary comment and probably something like #if (NR_IRQS*NR_CPUS) > 1000000 #error ouch! NR_IRQS*NR_CPUS too large. #endif > That involves putting it into the irq_desc (as good a place as any). And a > rather large number of trivial edits. I guess we do this only for genirq? Probably. The potential has always been there, but it clearly wasn't unlocked until just recently. If we find a cheap solution then we can do something. As a short term thing I am tempted to say just: #define NR_IRQS (256 + (NR_CPUS*8)) Which would reduce kstat_irqs to 5k, and would relieve the immediate symptoms. Eric ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman @ 2006-07-06 7:25 ` Ingo Molnar 2006-07-06 8:21 ` 2.6.17-mm6 Eric W. Biederman 2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven 1 sibling, 1 reply; 111+ messages in thread From: Ingo Molnar @ 2006-07-06 7:25 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, kmannth, linux-kernel, tglx, Natalie.Protasevich * Eric W. Biederman <ebiederm@xmission.com> wrote: > What is scary is that at 1K cpus if we wind up using all of the irqs > we start consuming 1Gig of RAM. At only 128 cpus we are still in the > 2M-15M territory, so that isn't too scary. The point is that after a > certain put the memory usage for all of those counters goes insane. we just need to move kernel_stat.irqs out of the per-cpu area and alloc_percpu() a counter pointer for each IRQ that is truly set up. If someone ends up using more than say 10,000 irqs we can reconsider. With 10K irqs we'd have 10MB of stat counter footprint - that's reasonable. Ingo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar @ 2006-07-06 8:21 ` Eric W. Biederman 2006-07-06 8:26 ` 2.6.17-mm6 Ingo Molnar 0 siblings, 1 reply; 111+ messages in thread From: Eric W. Biederman @ 2006-07-06 8:21 UTC (permalink / raw) To: Ingo Molnar Cc: Andrew Morton, kmannth, linux-kernel, tglx, Natalie.Protasevich Ingo Molnar <mingo@elte.hu> writes: > * Eric W. Biederman <ebiederm@xmission.com> wrote: > >> What is scary is that at 1K cpus if we wind up using all of the irqs >> we start consuming 1Gig of RAM. At only 128 cpus we are still in the >> 2M-15M territory, so that isn't too scary. The point is that after a >> certain put the memory usage for all of those counters goes insane. > > we just need to move kernel_stat.irqs out of the per-cpu area and > alloc_percpu() a counter pointer for each IRQ that is truly set up. If > someone ends up using more than say 10,000 irqs we can reconsider. With > 10K irqs we'd have 10MB of stat counter footprint - that's reasonable. Hmm. at 10,000 IRQs and 128 cpus I got about 5MB. But close enough. I'm convinced at least for now. The case I have seen are sparsely populated irqs. And we really do need the high IRQ counts because the potential irqs really do go up at 15 or so IRQs per cpu. Still if we are doing this generically let's please put in a big fat comment describing the situation, and maybe a compile warning, if things get too big. Eric ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 8:21 ` 2.6.17-mm6 Eric W. Biederman @ 2006-07-06 8:26 ` Ingo Molnar 0 siblings, 0 replies; 111+ messages in thread From: Ingo Molnar @ 2006-07-06 8:26 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, kmannth, linux-kernel, tglx, Natalie.Protasevich * Eric W. Biederman <ebiederm@xmission.com> wrote: > Still if we are doing this generically let's please put in a big fat > comment describing the situation, and maybe a compile warning, if > things get too big. sure, feel free! :) Ingo ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman 2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar @ 2006-07-06 7:31 ` Arjan van de Ven 2006-07-06 16:37 ` 2.6.17-mm6 Valdis.Kletnieks 1 sibling, 1 reply; 111+ messages in thread From: Arjan van de Ven @ 2006-07-06 7:31 UTC (permalink / raw) To: Eric W. Biederman Cc: Andrew Morton, kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich On Thu, 2006-07-06 at 01:18 -0600, Eric W. Biederman wrote: Hi, > Andrew Morton <akpm@osdl.org> writes: > > > On Wed, 5 Jul 2006 22:59:05 -0700 > > Andrew Morton <akpm@osdl.org> wrote: > > > >> On Wed, 05 Jul 2006 23:42:00 -0600 > >> ebiederm@xmission.com (Eric W. Biederman) wrote: > >> > >> > So I suspect that we need to de-percpuify kernel_stat.irqs. > >> > >> I think so. > > > > Maybe not. If we do this, we lose the pretty CPUn columns in > > /proc/interrupts. That /proc/interrupts display requires that we maintain > > NR_CPUS*NR_IRQS counters. > > Yes. Although at least part of that display is per architecture > so we may be able to get away with a little more. irqbalance uses the per column data for it's work.. please don't kill the information or format. Also if you have 1 number per irq, you keep bouncing that cacheline around *all the time* if your irq policy is set to rotating (as many chipsets do by default unless the OS overrides it) Greetings, Arjan van de Ven ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven @ 2006-07-06 16:37 ` Valdis.Kletnieks 0 siblings, 0 replies; 111+ messages in thread From: Valdis.Kletnieks @ 2006-07-06 16:37 UTC (permalink / raw) To: Arjan van de Ven Cc: Eric W. Biederman, Andrew Morton, kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich [-- Attachment #1: Type: text/plain, Size: 527 bytes --] On Thu, 06 Jul 2006 09:31:15 +0200, Arjan van de Ven said: > On Thu, 2006-07-06 at 01:18 -0600, Eric W. Biederman wrote: w > > Yes. Although at least part of that display is per architecture > > so we may be able to get away with a little more. > > irqbalance uses the per column data for it's work.. please don't kill > the information or format. Does irqbalance have a snowball's chance of doing anything sane on the moby-CPU moby-IRQ boxes under discussion here? How well does it do when faced with 10K IRQs on 1K CPUs? [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton 2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman @ 2006-07-06 16:49 ` Eric W. Biederman 1 sibling, 0 replies; 111+ messages in thread From: Eric W. Biederman @ 2006-07-06 16:49 UTC (permalink / raw) To: Andrew Morton; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich Andrew Morton <akpm@osdl.org> writes: > Maybe not. If we do this, we lose the pretty CPUn columns in > /proc/interrupts. That /proc/interrupts display requires that we maintain > NR_CPUS*NR_IRQS counters. > > Given that a large NR_IRQs space will be sparsely populated, we should > dynamically allocate the NR_CPUS storage for each active IRQ, as you say. > > That involves putting it into the irq_desc (as good a place as any). And a > rather large number of trivial edits. I guess we do this only for genirq? Actually I rechecked. There is one alpha box that defines NR_IRQS to be 32K. Which should hit this same problem if anyone ever compiles it. So this may actually seems to be an issue independent of genirq. Eric ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton 2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 6:40 ` Eric W. Biederman 1 sibling, 0 replies; 111+ messages in thread From: Eric W. Biederman @ 2006-07-06 6:40 UTC (permalink / raw) To: Andrew Morton; +Cc: kmannth, linux-kernel, mingo, tglx, Natalie.Protasevich Andrew Morton <akpm@osdl.org> writes: > On Wed, 05 Jul 2006 23:42:00 -0600 > ebiederm@xmission.com (Eric W. Biederman) wrote: > >> So I suspect that we need to de-percpuify kernel_stat.irqs. > > I think so. We do: > > struct irq_desc *desc = irq_desc + irq; > > kstat_this_cpu.irqs[irq]++; > > followed immediately by > > spin_lock(&desc->lock); > > false optimisation, or what? As an optimization I can't think of a reason. It is kind of interesting to report that information by cpu. in /proc/interrupts (see show_interrupts). But except for understanding system behavior I can't think of a reason for reporting that information. It was useful information to have when debugging the irq migration code. Eric ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman 2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton @ 2006-07-06 17:16 ` Andi Kleen 1 sibling, 0 replies; 111+ messages in thread From: Andi Kleen @ 2006-07-06 17:16 UTC (permalink / raw) To: Eric W. Biederman Cc: Keith Mannthey, linux-kernel, Ingo Molnar, Thomas Gleixner, Protasevich, Natalie, akpm ebiederm@xmission.com (Eric W. Biederman) writes: > Andrew Morton <akpm@osdl.org> writes: > > > On Wed, 5 Jul 2006 17:05:49 -0700 > > "Keith Mannthey" <kmannth@gmail.com> wrote: > > > >> On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: > >> > On Wed, 5 Jul 2006 16:44:57 -0700 > >> > Andrew Morton <akpm@osdl.org> wrote: > >> > > >> > > I guess a medium-term fix would be to add a boot parameter to override > >> > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just > >> > > for the benefit of the tiny minority of kernels which are hand-built with > >> > > lots of drivers in vmlinux. > >> > >> I am not really loading alot of drivers. I am building with a ton of driver. > >> > > >> > That's not right, is it. PERCPU_ENOUGH_ROOM covers vmlinux and all loaded > >> > modules, so if vmlinux blows it all then `modprobe the-same-stuff' will > >> > blow it as well. > >> > > >> > > But first let's find out where it all went. > >> > > >> > I agree with that person. > >> :) > >> > >> This is what I get it is diffrent that yours for sure. I am a little > >> confused by the large offset change near the start.....? > > > > Yes, I had an unexplained 8k hole. That was i386. Your x86_64 output > > looks OK though. > > > >> elm3a153:/home/keith/linux-2.6.17-mm6-orig # nm -n vmlinux | grep per_cpu > >>... > >> ffffffff80658000 A __per_cpu_start It starts here > >> ffffffff80658000 D per_cpu__init_tss 8k > >> ffffffff8065a080 d per_cpu__idle_state > >> ffffffff8065a084 d per_cpu__cpu_idle_state > >> ffffffff8065a0a0 D per_cpu__vector_irq > >> ffffffff8065a4a0 D per_cpu__device_mce > >> ffffffff8065a518 d per_cpu__next_check > >> ffffffff8065a520 d per_cpu__threshold_banks > >> ffffffff8065a550 d per_cpu__bank_map > >> ffffffff8065a580 d per_cpu__flush_state > >> ffffffff8065a600 D per_cpu__cpu_state > >> ffffffff8065a620 d per_cpu__perfctr_nmi_owner > >> ffffffff8065a624 d per_cpu__evntsel_nmi_owner > >> ffffffff8065a640 d per_cpu__nmi_watchdog_ctlblk > >> ffffffff8065a660 d per_cpu__last_irq_sum > >> ffffffff8065a668 d per_cpu__alert_counter > >> ffffffff8065a670 d per_cpu__nmi_touch > >> ffffffff8065a680 D per_cpu__current_kprobe > >> ffffffff8065a6a0 D per_cpu__kprobe_ctlblk > >> ffffffff8065a7e0 D per_cpu__mmu_gathers 4k > >> ffffffff8065b7e0 d per_cpu__runqueues 5k > >> ffffffff8065ca60 d per_cpu__cpu_domains > >> ffffffff8065cae0 d per_cpu__core_domains > >> ffffffff8065cb60 d per_cpu__phys_domains > >> ffffffff8065cbe0 d per_cpu__node_domains > >> ffffffff8065cc60 d per_cpu__allnodes_domains > >> ffffffff8065cce0 D per_cpu__kstat wham - 17.5k > >> ffffffff80661120 D per_cpu__process_counts > >> ffffffff80661130 d per_cpu__cpu_profile_hits > >> ffffffff80661140 d per_cpu__cpu_profile_flip > >> ffffffff80661148 d per_cpu__tasklet_vec > >> ffffffff80661150 d per_cpu__tasklet_hi_vec > >> ffffffff80661158 d per_cpu__ksoftirqd > >> ffffffff80661160 d per_cpu__tvec_bases > >> ffffffff80661180 D per_cpu__rcu_data > >> ffffffff80661200 D per_cpu__rcu_bh_data > >> ffffffff80661280 d per_cpu__rcu_tasklet > >> ffffffff806612c0 d per_cpu__hrtimer_bases > >> ffffffff80661340 d per_cpu__kprobe_instance > >> ffffffff80661348 d per_cpu__taskstats_seqnum > >> ffffffff80661360 d per_cpu__ratelimits.18857 > >> ffffffff80661380 d per_cpu__committed_space > >> ffffffff806613a0 d per_cpu__lru_add_pvecs > >> ffffffff80661420 d per_cpu__lru_add_active_pvecs > >> ffffffff806614a0 d per_cpu__lru_add_tail_pvecs > >> ffffffff80661520 D per_cpu__vm_event_states > >> ffffffff80661640 d per_cpu__reap_work > >> ffffffff806616a0 d per_cpu__reap_node > >> ffffffff806616c0 d per_cpu__bh_lrus > >> ffffffff80661700 d per_cpu__bh_accounting > >> ffffffff80661720 d per_cpu__fdtable_defer_list > >> ffffffff806617c0 d per_cpu__blk_cpu_done > >> ffffffff806617e0 D per_cpu__radix_tree_preloads > >> ffffffff80661860 d per_cpu__trickle_count > >> ffffffff80661864 d per_cpu__proc_event_counts > >> ffffffff80661880 d per_cpu__loopback_stats > >> ffffffff80661980 d per_cpu__sockets_in_use > >> ffffffff80661a00 D per_cpu__softnet_data > >> ffffffff80662000 D per_cpu__netdev_rx_stat > >> ffffffff80662010 d per_cpu__net_rand_state > >> ffffffff80662080 d per_cpu__flow_tables > >> ffffffff80662100 d per_cpu__flow_hash_info > >> ffffffff80662180 d per_cpu__flow_flush_tasklets > >> ffffffff806621c0 d per_cpu__rt_cache_stat > >> ffffffff80662200 d per_cpu____icmp_socket > >> ffffffff80662208 A __per_cpu_end > > > > So you've been hit by the expansion of NR_IRQS which bloats kernel_stat > > which gobbles per-cpu data. > > > > In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion) > > NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became > > two-dimensional. It's now O(NR_CPUS^2). > > Hmm. Perhaps it is a good thing I didn't push it to it's limit > of 244*NR_CPUS. Clearly it just needs to be dynamically allocated and only for interrupts that are actually used. e.g. a 2 level array scheme? Just need to make sure the memory overhead for small systems stays reasonable. > > > I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a > > showstopper if the ia64 guys try the same trick. > > I think the unisys boxes are about 128 sockets. 64 I thought. Newisys also plans 64 socket boxes. > So 128 or 256 is the > max at the moment. I'm not certain where things are heading. Big > specialized boxes seem to be giving way to smaller systems. Yet the > amount that you can do with commodity hardware is getting larger, > so I suspect it will likely be a wash. The worst case scenario > is that sgi will build a chipset supporting 32K cpus that works with > both Xeons and Itaniums. Currently x86 has a 8 bit APIC limit. So 255 is max. But at some point I expect it will be broken, not with sockets but with multicores and threads. On the other hand it might be reasonable to size the NR_CPUs only by sockets. The would lower the memory requirements. > > I'm tempted to suggest adding the following to irq_desc. > unsigned int last_cpu_count; > unsigned int last_cpu; Add all the statistics to irq_desc? -Andi ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton 2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman @ 2006-07-12 3:55 ` Steven Rostedt 1 sibling, 0 replies; 111+ messages in thread From: Steven Rostedt @ 2006-07-12 3:55 UTC (permalink / raw) To: Andrew Morton Cc: Keith Mannthey, linux-kernel, Ingo Molnar, Thomas Gleixner, Eric W. Biederman On Wed, 2006-07-05 at 17:25 -0700, Andrew Morton wrote: > On Wed, 5 Jul 2006 17:05:49 -0700 > "Keith Mannthey" <kmannth@gmail.com> wrote: > > > On 7/5/06, Andrew Morton <akpm@osdl.org> wrote: > > > On Wed, 5 Jul 2006 16:44:57 -0700 > > > Andrew Morton <akpm@osdl.org> wrote: > > > > > > > I guess a medium-term fix would be to add a boot parameter to override > > > > PERCPU_ENOUGH_ROOM - it's hard to justify increasing it permanently just > > > > for the benefit of the tiny minority of kernels which are hand-built with > > > > lots of drivers in vmlinux. > > [snip] > > So you've been hit by the expansion of NR_IRQS which bloats kernel_stat > which gobbles per-cpu data. > > In 2.6.17 NR_IRQS is 244. In -mm (due to the x86_64 genirq conversion) > NR_IRQS became (256 + 32 * NR_CPUS). Hence the kstat "array" became > two-dimensional. It's now O(NR_CPUS^2). > > I don't know what's a sane max for NR_CPUS on x86_64, but that'll sure be a > showstopper if the ia64 guys try the same trick. > > I guess one fix would be to de-percpuify kernel_stat.irqs[]. Or > dynamically allocate it with alloc_percpu(). And people wondered why I'm fighting for the robust per_cpu variables. http://marc.theaimsgroup.com/?l=linux-kernel&m=114785997413023&w=2 Yes there's still problems with this. But if I ever get some more time to work on it, I would like to solve those issues. Having that PERCPU_ENOUGH_ROOM laying around in the kernel is just disgusting ;) Sorry, for the noise, I have another 2288 more LKML emails to read :) -- Steve ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (8 preceding siblings ...) [not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com> @ 2006-07-07 9:17 ` Reuben Farrelly 2006-07-07 9:35 ` 2.6.17-mm6 Andrew Morton 2006-07-07 15:24 ` 2.6.17-mm6 Reuben Farrelly 10 siblings, 1 reply; 111+ messages in thread From: Reuben Farrelly @ 2006-07-07 9:17 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Neil Brown On 3/07/2006 10:03 p.m., Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > - A major update to the e1000 driver. > > - 1394 updates This release has been working quite well after some initial hiccups (see -mm hotfix), but a couple of hours ago another bad thing (tm) happened. At the time I was moving 100G of data from one partition on a non-raid partition to a new RAID-1 md that I had created earlier. Both are ext3 partitions. The word "barrier" of course comes to mind again, I'm not sure NeilB is the culprit this time either but I've cc'd him in just in case. The file copy went on happily for quite a while (maybe 10 mins or so) under very high IO load before blowing up as below. The terminal was spewing out constant traces but hopefully the right ones are here as these are the first few (if not, I have copied a bit more). sh-3.1# mv /store-old/* /store/ Unable to handle kernel paging request at ffff81043e345490 RIP: [<ffffffff802620f2>] memcpy+0x12/0xb0 PGD 8063 PUD 0 Oops: 0000 [1] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff802620f2>] [<ffffffff802620f2>] memcpy+0x12/0xb0 RSP: 0018:ffff81003ed31828 EFLAGS: 00010002 RAX: ffff810001faec18 RBX: 0000000000000010 RCX: 0000000000000001 RDX: 0000000000000080 RSI: ffff81043e345490 RDI: ffff810001faec18 RBP: ffff81003ed31898 R08: ffff81003f66a800 R09: 0000000000000000 R10: ffff810029b364b0 R11: 0000000000000000 R12: ffff810001faec00 R13: ffff81003f6ff140 R14: ffff81003f6ea240 R15: 0000000000000010 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 0000000000000010 ffffffff8025e9f0 ffff81003f66a800 0001120000000000 0000000000011200 000112003f650080 ffff81003eca39f0 ffff81003ed318c8 ffff81003ed31898 0000000000000246 ffff81003f6ff140 0000000000011200 Call Trace: [<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538 [<ffffffff802b96c6>] __kmalloc+0x86/0x96 [<ffffffff802ae460>] __kzalloc+0xf/0x2f [<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a [<ffffffff802230e4>] mempool_alloc+0x44/0xfb [<ffffffff8041d1c4>] wait_barrier+0x20/0xfc [<ffffffff802bd143>] __bio_clone+0x84/0xa2 [<ffffffff8041e072>] make_request+0xf2/0x611 [<ffffffff802a97d8>] mempool_alloc_slab+0x11/0x13 [<ffffffff8021c387>] generic_make_request+0x20d/0x256 [<ffffffff8027f831>] __wake_up_common+0x41/0x71 [<ffffffff80234c11>] submit_bio+0xd7/0xe6 [<ffffffff8021aa6c>] submit_bh+0x100/0x126 [<ffffffff8021c5ad>] __block_write_full_page+0x1dd/0x2ea [<ffffffff80310550>] ext3_get_block+0x0/0xf0 [<ffffffff80310550>] ext3_get_block+0x0/0xf0 [<ffffffff80217007>] block_write_full_page+0xa7/0xb0 [<ffffffff80311df2>] ext3_ordered_writepage+0xfa/0x1aa [<ffffffff8021cdc6>] mpage_writepages+0x1f6/0x3ce [<ffffffff80311cf8>] ext3_ordered_writepage+0x0/0x1aa [<ffffffff80262fb5>] thread_return+0x0/0xcc [<ffffffff8025e345>] do_writepages+0x35/0x40 [<ffffffff80231264>] __writeback_single_inode+0x1d4/0x3b0 [<ffffffff802ccbbb>] generic_sync_sb_inodes+0x20b/0x300 [<ffffffff80220cf5>] sync_sb_inodes+0x25/0x30 [<ffffffff8025312d>] writeback_inodes+0x8d/0xd9 [<ffffffff802ab723>] background_writeout+0x8f/0xc7 [<ffffffff80259370>] pdflush+0x0/0x1e2 [<ffffffff802594a7>] pdflush+0x137/0x1e2 [<ffffffff802ab694>] background_writeout+0x0/0xc7 [<ffffffff80259370>] pdflush+0x0/0x1e2 [<ffffffff80234163>] kthread+0xd3/0x100 [<ffffffff80260a02>] child_rip+0x8/0x12 [<ffffffff80234090>] kthread+0x0/0x100 [<ffffffff802609fa>] child_rip+0x0/0x12 Code: 4c 8b 1e 4c 8b 46 08 4c 89 1f 4c 89 47 08 4c 8b 4e 10 4c 8b RIP [<ffffffff802620f2>] memcpy+0x12/0xb0 RSP <ffff81003ed31828> CR2: ffff81043e345490 <1>Unable to handle kernel paging request at ffff81003f800000 RIP: [<ffffffff80262114>] memcpy+0x34/0xb0 PGD 8063 PUD 9063 PMD 0 Oops: 0000 [2] SMP last sysfs file: /kernel/uevent_seqnum CPU 0 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 6, comm: events/0 Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80262114>] [<ffffffff80262114>] memcpy+0x34/0xb0 RSP: 0018:ffff810037f51db8 EFLAGS: 00010003 RAX: ffff81003f660018 RBX: ffff81003f660018 RCX: 0000000003ff9807 RDX: 00000007fffffee0 RSI: ffff81003f7fffd8 RDI: ffff81003f7ffcd8 RBP: ffff810037f51dc8 R08: ffffffffffffffff R09: ffffffffffffffff R10: ffffffffffffffff R11: ffffffffffffffff R12: ffff81003f660000 R13: 0000000000000060 R14: 0000000000000000 R15: ffff81003f6eadc0 FS: 0000000000000000(0000) GS:ffffffff8068a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff81003f800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process events/0 (pid: 6, threadinfo ffff810037f50000, task ffff810037fef800) Stack: ffff81003f660018 ffffffff80222b5e ffff810037f51e08 ffffffff802b93b8 ffff81003f6ff140 ffff81003f6eadc0 ffff81003f6ff140 ffff810037ffe3c0 0000000000000000 0000000000000292 ffff810037f51e28 ffffffff802b9d83 Call Trace: [<ffffffff80222b5e>] memmove+0xe/0x3f [<ffffffff802b93b8>] drain_array+0xe8/0x100 [<ffffffff802b9d83>] cache_reap+0xb2/0x12f [<ffffffff8024f488>] run_workqueue+0xb7/0x109 [<ffffffff802b9cd1>] cache_reap+0x0/0x12f [<ffffffff8024bab0>] worker_thread+0x120/0x159 [<ffffffff80280dbb>] default_wake_function+0x0/0xf [<ffffffff8024b990>] worker_thread+0x0/0x159 [<ffffffff80234163>] kthread+0xd3/0x100 [<ffffffff80260a02>] child_rip+0x8/0x12 [<ffffffff80234090>] kthread+0x0/0x100 [<ffffffff802609fa>] child_rip+0x0/0x12 Code: 4c 8b 46 28 4c 89 5f 20 4c 89 47 28 4c 8b 4e 30 4c 8b 56 38 RIP [<ffffffff80262114>] memcpy+0x34/0xb0 RSP <ffff810037f51db8> CR2: ffff81003f800000 <0>general protection fault: 0000 [3] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff802b8f37>] [<ffffffff802b8f37>] __cache_free+0x25/0x118 RSP: 0018:ffff81003ed31568 EFLAGS: 00010092 RAX: 0000000000000001 RBX: ffff81003f6e9cc0 RCX: ffff810037f98238 RDX: 0000000000000000 RSI: ffff81003f25e140 RDI: ffff81003f6e9cc0 RBP: ffff81003ed315a8 R08: ffff810001fa62d0 R09: ffff810001fa62e0 R10: ffff810001fa62d0 R11: 000000000000137b R12: ffd9fe7e6ffffebb R13: ffff81003f25e140 R14: ffff810037f2b8f0 R15: ffff810037f2b968 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 00000000000000a5 0000000000000009 0000000000000000 0000000000000046 ffff810037f2b840 ffff81003f25e140 ffff810037f2b8f0 ffff810037f2b968 ffff81003ed315c8 ffffffff80207527 0000000000000000 ffff810001fa6080 Call Trace: [<ffffffff80207527>] kmem_cache_free+0x7f/0x88 [<ffffffff80283573>] __cleanup_sighand+0x20/0x22 [<ffffffff80217bb1>] release_task+0x241/0x315 [<ffffffff80215c5b>] do_exit+0x8ba/0x94b [<ffffffff8039a6f2>] unblank_screen+0xb/0xd [<ffffffff8020ac17>] do_page_fault+0x7a7/0x893 [<ffffffff80294909>] autoremove_wake_function+0x11/0x48 [<ffffffff8027f831>] __wake_up_common+0x41/0x71 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff802620f2>] memcpy+0x12/0xb0 [<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538 [<ffffffff802b96c6>] __kmalloc+0x86/0x96 [<ffffffff802ae460>] __kzalloc+0xf/0x2f [<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a [<ffffffff802230e4>] mempool_alloc+0x44/0xfb [<ffffffff8041d1c4>] wait_barrier+0x20/0xfc [<ffffffff802bd143>] __bio_clone+0x84/0xa2 [<ffffffff8041e072>] make_request+0xf2/0x611 [<ffffffff802a97d8>] mempool_alloc_slab+0x11/0x13 [<ffffffff8021c387>] generic_make_request+0x20d/0x256 [<ffffffff8027f831>] __wake_up_common+0x41/0x71 [<ffffffff80234c11>] submit_bio+0xd7/0xe6 [<ffffffff8021aa6c>] submit_bh+0x100/0x126 [<ffffffff8021c5ad>] __block_write_full_page+0x1dd/0x2ea [<ffffffff80310550>] ext3_get_block+0x0/0xf0 [<ffffffff80310550>] ext3_get_block+0x0/0xf0 [<ffffffff80217007>] block_write_full_page+0xa7/0xb0 [<ffffffff80311df2>] ext3_ordered_writepage+0xfa/0x1aa [<ffffffff8021cdc6>] mpage_writepages+0x1f6/0x3ce [<ffffffff80311cf8>] ext3_ordered_writepage+0x0/0x1aa [<ffffffff80262fb5>] thread_return+0x0/0xcc [<ffffffff8025e345>] do_writepages+0x35/0x40 [<ffffffff80231264>] __writeback_single_inode+0x1d4/0x3b0 [<ffffffff802ccbbb>] generic_sync_sb_inodes+0x20b/0x300 [<ffffffff80220cf5>] sync_sb_inodes+0x25/0x30 [<ffffffff8025312d>] writeback_inodes+0x8d/0xd9 [<ffffffff802ab723>] background_writeout+0x8f/0xc7 [<ffffffff80259370>] pdflush+0x0/0x1e2 [<ffffffff802594a7>] pdflush+0x137/0x1e2 [<ffffffff802ab694>] background_writeout+0x0/0xc7 [<ffffffff80259370>] pdflush+0x0/0x1e2 [<ffffffff80234163>] kthread+0xd3/0x100 [<ffffffff80260a02>] child_rip+0x8/0x12 [<ffffffff80234090>] kthread+0x0/0x100 [<ffffffff802609fa>] child_rip+0x0/0x12 Code: 41 8b 14 24 41 3b 54 24 04 73 13 89 d0 49 89 74 c4 18 8d 42 RIP [<ffffffff802b8f37>] __cache_free+0x25/0x118 RSP <ffff81003ed31568> <1>Unable to handle kernel paging request at ffffffffffff4e87 RIP: [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 PGD 203027 PUD 1deb067 PMD 0 Oops: 0000 [4] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff8029144a>] [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 RSP: 0018:ffff81003f617ed0 EFLAGS: 00010216 RAX: ffffffffffff4e7f RBX: ffff81003f60c000 RCX: ffff81003f6eb780 RDX: 0000000000000001 RSI: ffff810001dfa440 RDI: ffff810001dfa440 RBP: ffff81003f617ed0 R08: ffff810001dfa0e0 R09: ffff810001df9900 R10: 0000000000000000 R11: 00000000ffffffff R12: ffff81003f617ee0 R13: 0000000000000100 R14: ffffffff8029141e R15: 000000000000000a FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffffffff4e87 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: ffff81003f617f10 ffffffff8028afd9 ffff81003f617ee0 ffff81003f617ee0 0000000000000001 ffffffff8068a410 ffffffff806dd020 0000000000000001 ffff81003f617f50 ffffffff80211f6e 0000000000000001 0000000000000046 Call Trace: <IRQ> [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [5] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f617c18 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f617c58 R08: 0000000000009bb3 R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 0000000000009951 0000000000000001 000000003f617c58 ffff81003f617f28 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f617ca8 ffffffff80269049 ffffffff805759c7 ffff81003f617e28 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [6] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f617958 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f617998 R08: 000000000000a46d R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 000000000000a00f 0000000000000001 000000003f617998 ffff81003f617c70 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f6179e8 ffffffff80269049 ffffffff805759c7 ffff81003f617b68 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [7] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f617698 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f6176d8 R08: 000000000000af1b R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 000000000000a8c9 0000000000000001 000000003f6176d8 ffff81003f6179b0 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f617728 ffffffff80269049 ffffffff805759c7 ffff81003f6178a8 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [8] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f6173d8 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f617418 R08: 000000000000bbbd R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 000000000000b377 0000000000000001 000000003f617418 ffff81003f6176f0 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f617468 ffffffff80269049 ffffffff805759c7 ffff81003f6175e8 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [9] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f617118 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f617158 R08: 000000000000ca53 R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 000000000000c019 0000000000000001 000000003f617158 ffff81003f617430 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f6171a8 ffffffff80269049 ffffffff805759c7 ffff81003f617328 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [10] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f616e58 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f616e98 R08: 000000000000dadd R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 000000000000ceaf 0000000000000001 000000003f616e98 ffff81003f617170 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f616ee8 ffffffff80269049 ffffffff805759c7 ffff81003f617068 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 PGD 203027 PUD 205027 PMD 0 Oops: 0000 [11] SMP last sysfs file: /kernel/uevent_seqnum CPU 1 Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 RIP: 0010:[<ffffffff80268f00>] [<ffffffff80268f00>] show_trace+0x180/0x1c2 RSP: 0018:ffff81003f616b98 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 5fd7539830a2b4e5 RCX: ffffffff88029988 RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff8057db08 RBP: ffff81003f616bd8 R08: 000000000000ed5c R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000fffffffb R12: ffffffff827ffffd R13: 0000000000000000 R14: ffffffff806d8000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: ffffffff82800000 CR3: 000000003dc32000 CR4: 00000000000006e0 Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) Stack: 000000000000df3a 0000000000000001 000000003f616bd8 ffff81003f616eb0 000000000000000c ffff81003f613fc0 ffff81003f617fc0 0000000000000000 ffff81003f616c28 ffffffff80269049 ffffffff805759c7 ffff81003f616da8 Call Trace: <IRQ> [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff80217237>] release_console_sem+0x1e7/0x23f [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff80268f00>] show_trace+0x180/0x1c2 [<ffffffff80268f0c>] show_trace+0x18c/0x1c2 [<ffffffff80269049>] _show_stack+0xe9/0xf8 [<ffffffff802690e4>] show_registers+0x8c/0x101 [<ffffffff802691f9>] __die+0xa0/0xe3 [<ffffffff8020abf0>] do_page_fault+0x780/0x893 [<ffffffff8027fe48>] task_rq_lock+0x3c/0x71 [<ffffffff80280480>] find_busiest_group+0x260/0x6e0 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff80260849>] error_exit+0x0/0x84 [<ffffffff8029141e>] delayed_work_timer_fn+0x0/0x37 [<ffffffff8029144a>] delayed_work_timer_fn+0x2c/0x37 [<ffffffff8028afd9>] run_timer_softirq+0x149/0x1d0 [<ffffffff80211f6e>] __do_softirq+0x63/0xe5 [<ffffffff80260d52>] call_softirq+0x1e/0x28 [<ffffffff8026a723>] do_softirq+0x34/0x8b [<ffffffff80287418>] irq_exit+0x48/0x4a [<ffffffff80271b72>] smp_apic_timer_interrupt+0x4e/0x55 [<ffffffff802606ed>] apic_timer_interrupt+0x65/0x6c <EOI><1>Unable to handle kernel paging request at ffffffff82800000 RIP: [<ffffffff80268f00>] show_trace+0x180/0x1c2 reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 9:17 ` 2.6.17-mm6 Reuben Farrelly @ 2006-07-07 9:35 ` Andrew Morton 2006-07-07 21:15 ` 2.6.17-mm6 Reuben Farrelly 0 siblings, 1 reply; 111+ messages in thread From: Andrew Morton @ 2006-07-07 9:35 UTC (permalink / raw) To: Reuben Farrelly; +Cc: linux-kernel, neilb On Fri, 07 Jul 2006 21:17:03 +1200 Reuben Farrelly <reuben-lkml@reub.net> wrote: > > > On 3/07/2006 10:03 p.m., Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > > > > - A major update to the e1000 driver. > > > > - 1394 updates > > This release has been working quite well after some initial hiccups (see -mm > hotfix), but a couple of hours ago another bad thing (tm) happened. > > At the time I was moving 100G of data from one partition on a non-raid partition > to a new RAID-1 md that I had created earlier. Both are ext3 partitions. > > The word "barrier" of course comes to mind again, I'm not sure NeilB is the > culprit this time either but I've cc'd him in just in case. > > The file copy went on happily for quite a while (maybe 10 mins or so) under very > high IO load before blowing up as below. The terminal was spewing out constant > traces but hopefully the right ones are here as these are the first few (if not, > I have copied a bit more). > Yes, the very first oops is by far the most important to capture. You can add pause_on_oops=100000 to the kernel boot command line to make the machine freeze after outputting the first oops. That'll certainly prevent the oops messages from getting to the log files, but it will also prevent it from scolling away or swamping your log device. > sh-3.1# mv /store-old/* /store/ > Unable to handle kernel paging request at ffff81043e345490 RIP: > [<ffffffff802620f2>] memcpy+0x12/0xb0 > PGD 8063 PUD 0 > Oops: 0000 [1] SMP > last sysfs file: /kernel/uevent_seqnum > CPU 1 > Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk > Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 > RIP: 0010:[<ffffffff802620f2>] [<ffffffff802620f2>] memcpy+0x12/0xb0 > RSP: 0018:ffff81003ed31828 EFLAGS: 00010002 > RAX: ffff810001faec18 RBX: 0000000000000010 RCX: 0000000000000001 > RDX: 0000000000000080 RSI: ffff81043e345490 RDI: ffff810001faec18 > RBP: ffff81003ed31898 R08: ffff81003f66a800 R09: 0000000000000000 > R10: ffff810029b364b0 R11: 0000000000000000 R12: ffff810001faec00 > R13: ffff81003f6ff140 R14: ffff81003f6ea240 R15: 0000000000000010 > FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0 > Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) > Stack: 0000000000000010 ffffffff8025e9f0 ffff81003f66a800 0001120000000000 > 0000000000011200 000112003f650080 ffff81003eca39f0 ffff81003ed318c8 > ffff81003ed31898 0000000000000246 ffff81003f6ff140 0000000000011200 > Call Trace: > [<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538 > [<ffffffff802b96c6>] __kmalloc+0x86/0x96 > [<ffffffff802ae460>] __kzalloc+0xf/0x2f > [<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a > [<ffffffff802230e4>] mempool_alloc+0x44/0xfb The core slab data structures were wrecked. For kmalloc(), no less. Something secretly destroyed your kernel, and it could be anything. Nice. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 9:35 ` 2.6.17-mm6 Andrew Morton @ 2006-07-07 21:15 ` Reuben Farrelly 2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton 0 siblings, 1 reply; 111+ messages in thread From: Reuben Farrelly @ 2006-07-07 21:15 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On 7/07/2006 9:35 p.m., Andrew Morton wrote: > On Fri, 07 Jul 2006 21:17:03 +1200 > Reuben Farrelly <reuben-lkml@reub.net> wrote: > >> >> On 3/07/2006 10:03 p.m., Andrew Morton wrote: >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ >>> >>> >>> - A major update to the e1000 driver. >>> >>> - 1394 updates >> This release has been working quite well after some initial hiccups (see -mm >> hotfix), but a couple of hours ago another bad thing (tm) happened. >> >> At the time I was moving 100G of data from one partition on a non-raid partition >> to a new RAID-1 md that I had created earlier. Both are ext3 partitions. >> >> The word "barrier" of course comes to mind again, I'm not sure NeilB is the >> culprit this time either but I've cc'd him in just in case. >> >> The file copy went on happily for quite a while (maybe 10 mins or so) under very >> high IO load before blowing up as below. The terminal was spewing out constant >> traces but hopefully the right ones are here as these are the first few (if not, >> I have copied a bit more). >> > > Yes, the very first oops is by far the most important to capture. > > You can add pause_on_oops=100000 to the kernel boot command line to make > the machine freeze after outputting the first oops. That'll certainly > prevent the oops messages from getting to the log files, but it will also > prevent it from scolling away or swamping your log device. > > >> sh-3.1# mv /store-old/* /store/ >> Unable to handle kernel paging request at ffff81043e345490 RIP: >> [<ffffffff802620f2>] memcpy+0x12/0xb0 >> PGD 8063 PUD 0 >> Oops: 0000 [1] SMP >> last sysfs file: /kernel/uevent_seqnum >> CPU 1 >> Modules linked in: binfmt_misc ide_cd iTCO_wdt i2c_i801 cdrom serio_raw ide_disk >> Pid: 165, comm: pdflush Not tainted 2.6.17-mm6 #2 >> RIP: 0010:[<ffffffff802620f2>] [<ffffffff802620f2>] memcpy+0x12/0xb0 >> RSP: 0018:ffff81003ed31828 EFLAGS: 00010002 >> RAX: ffff810001faec18 RBX: 0000000000000010 RCX: 0000000000000001 >> RDX: 0000000000000080 RSI: ffff81043e345490 RDI: ffff810001faec18 >> RBP: ffff81003ed31898 R08: ffff81003f66a800 R09: 0000000000000000 >> R10: ffff810029b364b0 R11: 0000000000000000 R12: ffff810001faec00 >> R13: ffff81003f6ff140 R14: ffff81003f6ea240 R15: 0000000000000010 >> FS: 0000000000000000(0000) GS:ffff810037ffe440(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b >> CR2: ffff81043e345490 CR3: 000000003dc32000 CR4: 00000000000006e0 >> Process pdflush (pid: 165, threadinfo ffff81003ed30000, task ffff810037f2b840) >> Stack: 0000000000000010 ffffffff8025e9f0 ffff81003f66a800 0001120000000000 >> 0000000000011200 000112003f650080 ffff81003eca39f0 ffff81003ed318c8 >> ffff81003ed31898 0000000000000246 ffff81003f6ff140 0000000000011200 >> Call Trace: >> [<ffffffff8025e9f0>] cache_alloc_refill+0xc9/0x538 >> [<ffffffff802b96c6>] __kmalloc+0x86/0x96 >> [<ffffffff802ae460>] __kzalloc+0xf/0x2f >> [<ffffffff8041d598>] r1bio_pool_alloc+0x21/0x3a >> [<ffffffff802230e4>] mempool_alloc+0x44/0xfb > > The core slab data structures were wrecked. For kmalloc(), no less. > Something secretly destroyed your kernel, and it could be anything. Nice. Having now turned on slab debugging, is it possibly related to this message which appeared in my log when I booting up earlier? Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode. Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1 extents:1 across:497972k Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30. Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480 max) - 288 bytes per conntrack Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096 Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:15 ` 2.6.17-mm6 Reuben Farrelly @ 2006-07-07 21:38 ` Andrew Morton 2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh 2006-07-07 23:08 ` 2.6.17-mm6 Reuben Farrelly 0 siblings, 2 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-07 21:38 UTC (permalink / raw) To: Reuben Farrelly; +Cc: linux-kernel Reuben Farrelly <reuben-lkml@reub.net> wrote: > > > > > > The core slab data structures were wrecked. For kmalloc(), no less. > > Something secretly destroyed your kernel, and it could be anything. Nice. > > Having now turned on slab debugging, is it possibly related to this message > which appeared in my log when I booting up earlier? > > Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode. > Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1 > extents:1 across:497972k > Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team > Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30. > Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480 > max) - 288 bytes per conntrack > Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096 > Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b > Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 > Mbps Full Duplex > Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver > Yikes! Until we fix that there's no point in looking at anything else. CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't implement the damn thing :( So if this is repeatable it would be of some value if you can work out what causes it - start by disabling netfilter. But to fix it for real we'll probably need to twiddle thumbs until an x86 person can hit it. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton @ 2006-07-07 21:42 ` Martin Bligh 2006-07-07 23:06 ` 2.6.17-mm6 Andrew Morton 2006-07-08 3:46 ` 2.6.17-mm6 Badari Pulavarty 2006-07-07 23:08 ` 2.6.17-mm6 Reuben Farrelly 1 sibling, 2 replies; 111+ messages in thread From: Martin Bligh @ 2006-07-07 21:42 UTC (permalink / raw) To: Andrew Morton; +Cc: Reuben Farrelly, linux-kernel > Yikes! Until we fix that there's no point in looking at anything else. > > CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't > implement the damn thing :( I have an implementation, but there's some bug in it I never fixed. If you want it, I'll update it and send it out ... maybe you can spot the bug ;-( M. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh @ 2006-07-07 23:06 ` Andrew Morton 2006-07-08 3:46 ` 2.6.17-mm6 Badari Pulavarty 1 sibling, 0 replies; 111+ messages in thread From: Andrew Morton @ 2006-07-07 23:06 UTC (permalink / raw) To: Martin Bligh; +Cc: reuben-lkml, linux-kernel Martin Bligh <mbligh@mbligh.org> wrote: > > > > Yikes! Until we fix that there's no point in looking at anything else. > > > > CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't > > implement the damn thing :( > > I have an implementation, but there's some bug in it I never fixed. If > you want it, I'll update it and send it out ... maybe you can spot the > bug ;-( > My bug-spotting rate doesn't seem so good lately. But if the thing doesn't break the kernel when configged off then sure, let's put it in -mm with a big doesnt-work-yet warning on it and hopefully some clever person like Chuck will come along and fix it. That being said, we don't seem to be getting a lot of value from DEBUG_PAGEALLOC any more. I guess we fixed a pile of long-standing problems when it first went in and the reintroduction rate is low. ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh 2006-07-07 23:06 ` 2.6.17-mm6 Andrew Morton @ 2006-07-08 3:46 ` Badari Pulavarty 1 sibling, 0 replies; 111+ messages in thread From: Badari Pulavarty @ 2006-07-08 3:46 UTC (permalink / raw) To: Martin Bligh; +Cc: Andrew Morton, Reuben Farrelly, linux-kernel Martin Bligh wrote: > >> Yikes! Until we fix that there's no point in looking at anything else. >> >> CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 >> doesn't >> implement the damn thing :( > > I have an implementation, but there's some bug in it I never fixed. If > you want it, I'll update it and send it out ... maybe you can spot the > bug ;-( > Please send it out. I will take a look (not that I can fix it :) Thanks, Badari ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton 2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh @ 2006-07-07 23:08 ` Reuben Farrelly 1 sibling, 0 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-07 23:08 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel On 8/07/2006 9:38 a.m., Andrew Morton wrote: > Reuben Farrelly <reuben-lkml@reub.net> wrote: >> >>> The core slab data structures were wrecked. For kmalloc(), no less. >>> Something secretly destroyed your kernel, and it could be anything. Nice. >> Having now turned on slab debugging, is it possibly related to this message >> which appeared in my log when I booting up earlier? >> >> Jul 8 02:49:39 tornado kernel: EXT3-fs: mounted filesystem with ordered data mode. >> Jul 8 02:49:39 tornado kernel: Adding 497972k swap on /dev/sdc9. Priority:-1 >> extents:1 across:497972k >> Jul 8 02:49:40 tornado kernel: ip_tables: (C) 2000-2006 Netfilter Core Team >> Jul 8 02:49:40 tornado kernel: Netfilter messages via NETLINK v0.30. >> Jul 8 02:49:40 tornado kernel: ip_conntrack version 2.4 (4060 buckets, 32480 >> max) - 288 bytes per conntrack >> Jul 8 02:49:40 tornado kernel: Slab corruption: start=ffff81003efd7000, len=4096 >> Jul 8 02:49:40 tornado kernel: 170: ff ff ff ff 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b >> Jul 8 02:49:40 tornado kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 1000 >> Mbps Full Duplex >> Jul 8 02:49:40 tornado kernel: GRE over IPv4 tunneling driver >> > > Yikes! Until we fix that there's no point in looking at anything else. > > CONFIG_DEBUG_PAGEALLOC would nail this bug in a flash, but x86_64 doesn't > implement the damn thing :( > > So if this is repeatable it would be of some value if you can work out what > causes it - start by disabling netfilter. It hasn't come back after a quick reboot, but I'll be more vigilant than usual for it. With that warning above and the nasty crash before that which maybe related, I'm thinking that it's not just a one-off thing. reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
* Re: 2.6.17-mm6 2006-07-03 10:03 2.6.17-mm6 Andrew Morton ` (9 preceding siblings ...) 2006-07-07 9:17 ` 2.6.17-mm6 Reuben Farrelly @ 2006-07-07 15:24 ` Reuben Farrelly 10 siblings, 0 replies; 111+ messages in thread From: Reuben Farrelly @ 2006-07-07 15:24 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, netdev On 3/07/2006 10:03 p.m., Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ > > > - A major update to the e1000 driver. > > - 1394 updates Some minor breakage in the e1000... Fedora Core release 5.90 (Test) Kernel 2.6.17-mm6 on an x86_64 tornado.reub.net login: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue <0> TDH <a> TDT <1c> next_to_use <1c> next_to_clean <8> buffer_info[next_to_clean] time_stamp <100027f1a> next_to_watch <a> jiffies <1000281d4> next_to_watch.status <0> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue <0> TDH <a> TDT <1c> next_to_use <1c> next_to_clean <8> buffer_info[next_to_clean] time_stamp <100027f1a> next_to_watch <a> jiffies <1000283c8> next_to_watch.status <0> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue <0> TDH <a> TDT <1c> next_to_use <1c> next_to_clean <8> buffer_info[next_to_clean] time_stamp <100027f1a> next_to_watch <a> jiffies <1000285bc> next_to_watch.status <0> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue <0> TDH <a> TDT <1c> next_to_use <1c> next_to_clean <8> buffer_info[next_to_clean] time_stamp <100027f1a> next_to_watch <a> jiffies <1000287b0> next_to_watch.status <0> e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue <0> TDH <a> TDT <1c> next_to_use <1c> next_to_clean <8> buffer_info[next_to_clean] time_stamp <100027f1a> next_to_watch <a> jiffies <1000289a4> next_to_watch.status <0> A look through my switch logs and kernel logs over the last few days shows these messages and layer 2/link down disconnections every few hours or so, but of very short duration (I hadn't noticed until now). This output above was under virtually no load. Both the e1000 and switch port on the other end are doing RX and TX flow control. The controller is a built in chip on an Intel D945GNT board. 01:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03) Subsystem: Intel Corporation Unknown device 3094 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 313 Region 0: Memory at 48000000 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 2000 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Address: 00000000fee0100c Data: 4142 Capabilities: [e0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <512ns, L1 <64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0 Link: Latency L0s <128ns, L1 <64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 [root@tornado log]# ethtool -i eth0 driver: e1000 version: 7.1.9-k2-NAPI firmware-version: 1.0-5 bus-info: 0000:01:00.0 [root@tornado log]# Where can I go from here to help debug this further? reuben ^ permalink raw reply [flat|nested] 111+ messages in thread
end of thread, other threads:[~2006-07-12 3:56 UTC | newest]
Thread overview: 111+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-07 14:21 2.6.17-mm6 Martin J. Bligh
-- strict thread matches above, loose matches on Subject: below --
2006-07-03 10:03 2.6.17-mm6 Andrew Morton
2006-07-03 10:50 ` 2.6.17-mm6 Michal Piotrowski
2006-07-03 10:56 ` 2.6.17-mm6 Andrew Morton
2006-07-03 11:36 ` 2.6.17-mm6 Michal Piotrowski
2006-07-03 12:27 ` 2.6.17-mm6 Michal Piotrowski
2006-07-03 13:28 ` 2.6.17-mm6 Dmitry Torokhov
2006-07-03 11:00 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 11:25 ` 2.6.17-mm6 Andrew Morton
2006-07-03 12:34 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 11:39 ` 2.6.17-mm6 Andrew Morton
2006-07-03 11:41 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 12:10 ` 2.6.17-mm6 Andrew Morton
2006-07-03 13:36 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 20:21 ` 2.6.17-mm6 Andrew Morton
2006-07-03 20:31 ` 2.6.17-mm6 Reuben Farrelly
2006-07-03 12:29 ` 2.6.17-mm6 Sergey Vlasov
2006-07-03 17:25 ` 2.6.17-mm6 Jeremy Fitzhardinge
2006-07-03 19:01 ` 2.6.17-mm6 Andrew Morton
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
2006-07-03 12:17 ` 2.6.17-mm6 Heiko Carstens
2006-07-03 13:08 ` 2.6.17-mm6 Martin Peschke
2006-07-03 13:12 ` 2.6.17-mm6 Cedric Le Goater
2006-07-03 12:15 ` 2.6.17-mm6 Cedric Le Goater
2006-07-03 14:09 ` 2.6.17-mm6 Theodore Tso
2006-07-03 19:07 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 19:37 ` 2.6.17-mm6 Andrew Morton
2006-07-03 19:43 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 19:27 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 19:39 ` 2.6.17-mm6 Andrew Morton
2006-07-03 19:56 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 20:17 ` 2.6.17-mm6 Andrew Morton
2006-07-03 20:36 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 20:54 ` 2.6.17-mm6 Andrew Morton
2006-07-03 21:50 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 23:31 ` 2.6.17-mm6 Andrew Morton
2006-07-04 8:34 ` 2.6.17-mm6 Alistair John Strachan
2006-07-04 8:49 ` 2.6.17-mm6 Andrew Morton
2006-07-04 16:28 ` 2.6.17-mm6 Alistair John Strachan
2006-07-05 20:37 ` 2.6.17-mm6 john stultz
2006-07-05 20:46 ` 2.6.17-mm6 Greg KH
2006-07-05 22:32 ` 2.6.17-mm6 Alistair John Strachan
2006-07-06 17:31 ` 2.6.17-mm6 john stultz
2006-07-06 19:06 ` 2.6.17-mm6 Alistair John Strachan
2006-07-06 19:16 ` 2.6.17-mm6 Alistair John Strachan
2006-07-06 20:02 ` 2.6.17-mm6 Alistair John Strachan
2006-07-06 20:11 ` 2.6.17-mm6 Greg KH
2006-07-07 20:48 ` 2.6.17-mm6 Alistair John Strachan
2006-07-08 16:02 ` 2.6.17-mm6 Alistair John Strachan
2006-07-03 22:10 ` 2.6.17-mm6 Anton Blanchard
2006-07-04 19:53 ` 2.6.17-mm6 Rafael J. Wysocki
2006-07-04 20:01 ` 2.6.17-mm6 Arjan van de Ven
2006-07-05 10:27 ` 2.6.17-mm6 Stefan Richter
2006-07-05 10:36 ` 2.6.17-mm6 Stefan Richter
2006-07-05 11:13 ` 2.6.17-mm6 Ingo Molnar
2006-07-05 21:43 ` 2.6.17-mm6 J.A. Magallón
2006-07-05 22:56 ` 2.6.17-mm6 Andrew Morton
2006-07-05 23:57 ` 2.6.17-mm6 J.A. Magallón
2006-07-06 0:02 ` 2.6.17-mm6 Andrew Morton
2006-07-06 14:36 ` 2.6.17-mm6 J.A. Magallón
2006-07-06 14:48 ` 2.6.17-mm6 J.A. Magallón
2006-07-06 21:44 ` 2.6.17-mm6 J.A. Magallón
2006-07-06 21:57 ` 2.6.17-mm6 Andrew Morton
2006-07-07 15:38 ` 2.6.17-mm6 J.A. Magallón
2006-07-07 16:02 ` 2.6.17-mm6 Alan Cox
2006-07-07 15:55 ` 2.6.17-mm6 J.A. Magallón
2006-07-07 16:44 ` 2.6.17-mm6 Alan Cox
2006-07-07 16:34 ` 2.6.17-mm6 Randy.Dunlap
2006-07-07 17:09 ` 2.6.17-mm6 Alan Cox
2006-07-07 17:14 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 17:22 ` 2.6.17-mm6 David Lloyd
2006-07-07 17:23 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 17:44 ` 2.6.17-mm6 Alan Cox
2006-07-07 17:39 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 20:03 ` 2.6.17-mm6 Alan Cox
2006-07-07 19:59 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 20:23 ` 2.6.17-mm6 Alan Cox
2006-07-07 20:14 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 20:42 ` 2.6.17-mm6 Alan Cox
2006-07-07 20:37 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 21:09 ` 2.6.17-mm6 J.A. Magallón
2006-07-07 21:11 ` 2.6.17-mm6 Jeff Garzik
2006-07-07 21:40 ` 2.6.17-mm6 J.A. Magallón
[not found] ` <a762e240607051447x3c3c6e15k9cdb38804cf13f35@mail.gmail.com>
2006-07-05 22:50 ` 2.6.17-mm6 Andrew Morton
2006-07-05 23:28 ` 2.6.17-mm6 Keith Mannthey
2006-07-05 23:44 ` 2.6.17-mm6 Andrew Morton
2006-07-05 23:48 ` 2.6.17-mm6 Andrew Morton
2006-07-06 0:05 ` 2.6.17-mm6 Keith Mannthey
2006-07-06 0:25 ` 2.6.17-mm6 Andrew Morton
2006-07-06 5:42 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 5:59 ` 2.6.17-mm6 Andrew Morton
2006-07-06 6:31 ` 2.6.17-mm6 Andrew Morton
2006-07-06 7:18 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 7:25 ` 2.6.17-mm6 Ingo Molnar
2006-07-06 8:21 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 8:26 ` 2.6.17-mm6 Ingo Molnar
2006-07-06 7:31 ` 2.6.17-mm6 Arjan van de Ven
2006-07-06 16:37 ` 2.6.17-mm6 Valdis.Kletnieks
2006-07-06 16:49 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 6:40 ` 2.6.17-mm6 Eric W. Biederman
2006-07-06 17:16 ` 2.6.17-mm6 Andi Kleen
2006-07-12 3:55 ` 2.6.17-mm6 Steven Rostedt
2006-07-07 9:17 ` 2.6.17-mm6 Reuben Farrelly
2006-07-07 9:35 ` 2.6.17-mm6 Andrew Morton
2006-07-07 21:15 ` 2.6.17-mm6 Reuben Farrelly
2006-07-07 21:38 ` 2.6.17-mm6 Andrew Morton
2006-07-07 21:42 ` 2.6.17-mm6 Martin Bligh
2006-07-07 23:06 ` 2.6.17-mm6 Andrew Morton
2006-07-08 3:46 ` 2.6.17-mm6 Badari Pulavarty
2006-07-07 23:08 ` 2.6.17-mm6 Reuben Farrelly
2006-07-07 15:24 ` 2.6.17-mm6 Reuben Farrelly
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox